Sa kasaysayan, ang mga karapatan ng sudo ay pinamamahalaan ng mga nilalaman ng mga file mula sa /etc/sudoers.d ΠΈ visudo, at ang awtorisasyon sa pamamagitan ng mga susi ay isinagawa gamit ang ~/.ssh/authorized_keys. Gayunpaman, sa paglago ng imprastraktura, may pagnanais na pamahalaan ang mga karapatang ito sa gitna. Sa kasalukuyan, may ilang posibleng solusyon:
- Sistema ng Pamamahala ng Configuration - Punong tagapagluto, Puppet, Ansible, Asin
- Active Directory + ssd
- Iba't ibang mga perversion sa anyo ng mga script at manu-manong pag-edit ng mga file
Sa aking pansariling opinyon, ang pinakamagandang opsyon para sa sentralisadong pamamahala ay marami pa rin Active Directory + ssd. Ang mga bentahe ng diskarteng ito ay:
- Talagang ang Uniform na sentralisadong direktoryo ng mga gumagamit.
- Pamamahagi ng mga karapatan sudo bumababa sa pagdaragdag ng user sa isang partikular na pangkat ng seguridad.
- Sa kaso ng iba't ibang mga sistema ng Linux, kinakailangan na magpakilala ng mga karagdagang pagsusuri upang matukoy ang OS kapag gumagamit ng mga sistema ng pagsasaayos.
Ang suite ngayon ay ilalaan sa bundle Active Directory + ssd para sa pamamahala ng mga karapatan sudo at imbakan SSH mga susi sa iisang repositoryo.
Kaya, ang bulwagan ay nagyelo sa maigting na katahimikan, itinaas ng konduktor ang kanyang baton, naghanda ang orkestra.
Umalis na tayo.
Ibinigay:
- Domain ng Active Directory testopf.lokal sa Windows Server 2012 R2.
- Linux host na nagpapatakbo ng Centos 7
- Customized na awtorisasyon gamit ssd
Ang parehong mga solusyon ay gumagawa ng mga pagbabago sa schema Active Directory, kaya sinusuri namin ang lahat sa isang pagsubok na kapaligiran at pagkatapos lamang gumawa ng mga pagbabago sa gumaganang imprastraktura. Gusto kong tandaan na ang lahat ng mga pagbabago ay point-wise at, sa katunayan, idagdag lamang ang mga kinakailangang katangian at klase.
Aksyon 1: pamamahala sudo mga tungkulin sa pamamagitan ng Active Directory.
Upang palawigin ang schema Active Directory kailangan mong i-download ang pinakabagong release β 1.8.27 ngayon. I-unpack, kopyahin ang file schema.ActiveDirectory mula sa ./doc na direktoryo hanggang sa isang domain controller. Mula sa command line na may mga karapatan ng administrator mula sa direktoryo kung saan kinopya ang file, patakbuhin ang:
ldifde -i -f schema.ActiveDirectory -c dc=X dc=testopf,dc=local
(Huwag kalimutang palitan ang iyong mga halaga)
Buksan adsiedit.msc at kumonekta sa default na konteksto:
Gumawa ng subdivision sa ugat ng domain sudoers. (Matigas na sinasabi ng burges na nasa yunit na ito ang demonyo ssd naghahanap ng isang item sudoRole mga bagay. Gayunpaman, pagkatapos i-on ang detalyadong pag-debug at suriin ang mga log, nalaman na ang paghahanap ay ginagawa sa buong puno ng direktoryo.)
Lumikha ng unang bagay sa dibisyon na kabilang sa klase sudoRole. Ang pangalan ay maaaring mapili ng ganap na arbitraryo, dahil ito ay nagsisilbi lamang para sa maginhawang pagkakakilanlan.
Kabilang sa mga posibleng attribute na makukuha mula sa isang extension ng schema, ang mga pangunahing ay:
- sudoCommand - tinutukoy kung aling mga utos ang pinapayagang isagawa sa host.
- sudoHost - tinutukoy kung aling mga host ang inilapat ang tungkuling ito. Maaaring ibigay bilang LAHAT, at para sa isang hiwalay na host ayon sa pangalan. Posible ring gumamit ng maskara.
- sudoUser - tukuyin kung aling mga user ang pinapayagang magsagawa sudo.
Kung may tinukoy na grupo ng seguridad, magdagdag ng β%β sign sa simula ng pangalan. Kung may mga puwang sa pangalan ng grupo, walang dapat ikabahala. Sa paghusga sa pamamagitan ng mga log, ang gawain ng pagtakas sa mga puwang ay kinuha ng mekanismo ssd.
Figure 1 sudoRole object sa sudoers subdivision sa ugat ng direktoryo
Fig 2. Membership sa mga grupo ng seguridad na tinukoy sa sudoRole object.
Ang sumusunod na setup ay ginagawa sa gilid ng Linux.
Nasa file /etc/nsswitch.conf idagdag ang sumusunod na linya sa dulo ng file:
sudoers: files sssNasa file /etc/sssd/sssd.conf sa seksyon [sssd] idagdag sa mga serbisyo sudo
cat /etc/sssd/sssd.conf | grep services
services = nss, pam, sudo
Pagkatapos ng lahat ng mga operasyon, kailangan mong i-clear ang cache ng sssd daemon. Ang mga awtomatikong pag-update ay ginagawa tuwing 6 na oras, ngunit bakit tayo maghihintay nang napakatagal kung gusto natin ngayon.
sss_cache -EMadalas na nangyayari na ang pag-clear ng cache ay hindi makakatulong. Pagkatapos ay itinigil namin ang serbisyo, linisin ang database, simulan ang serbisyo.
service sssd stop
rm -rf /var/lib/sss/db/*
service sssd start
Kumonekta kami bilang unang gumagamit at suriin kung ano ang magagamit sa kanya mula sa ilalim ng sudo:
su user1
[user1@testsshad log]$ id
uid=1109801141(user1) gid=1109800513(domain users) groups=1109800513(domain users),1109801132(admins_)
[user1@testsshad log]$ sudo -l
[sudo] password for user1:
Matching Defaults entries for user1 on testsshad:
!visiblepw, always_set_home, match_group_by_gid, always_query_group_plugin,
env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS",
env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE",
env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES",
env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE",
env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY",
secure_path=/sbin:/bin:/usr/sbin:/usr/bin
User user1 may run the following commands on testsshad:
(root) /usr/bin/ls, /usr/bin/catGinagawa namin ang parehong sa aming pangalawang gumagamit:
su user2
[user2@testsshad log]$ id
uid=1109801142(user2) gid=1109800513(domain users) groups=1109800513(domain users),1109801138(sudo_root)
[user2@testsshad log]$ sudo -l
Matching Defaults entries for user2 on testsshad:
!visiblepw, always_set_home, match_group_by_gid, always_query_group_plugin,
env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS",
env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE",
env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES",
env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE",
env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY",
secure_path=/sbin:/bin:/usr/sbin:/usr/bin
User user2 may run the following commands on testsshad:
(root) ALL
Binibigyang-daan ka ng diskarteng ito na sentral na tukuyin ang mga tungkulin ng sudo para sa iba't ibang pangkat ng user.
Pag-iimbak at paggamit ng mga ssh key sa Active Directory
Sa bahagyang pagpapalawak ng scheme, posibleng mag-imbak ng mga ssh key sa mga attribute ng user ng Active Directory at gamitin ang mga ito kapag pinahihintulutan ang mga host ng Linux.
Ang pahintulot sa pamamagitan ng sssd ay dapat na i-configure.
Idinaragdag namin ang kinakailangang katangian gamit ang PowerShell script.
AddsshPublicKeyAttribute.ps1Function New-AttributeID {
$Prefix="1.2.840.113556.1.8000.2554"
$GUID=[System.Guid]::NewGuid().ToString()
$parts=@()
$Parts+=[UInt64]::Parse($guid.SubString(0,4),"AllowHexSpecifier")
$Parts+=[UInt64]::Parse($guid.SubString(4,4),"AllowHexSpecifier")
$Parts+=[UInt64]::Parse($guid.SubString(9,4),"AllowHexSpecifier")
$Parts+=[UInt64]::Parse($guid.SubString(14,4),"AllowHexSpecifier")
$Parts+=[UInt64]::Parse($guid.SubString(19,4),"AllowHexSpecifier")
$Parts+=[UInt64]::Parse($guid.SubString(24,6),"AllowHexSpecifier")
$Parts+=[UInt64]::Parse($guid.SubString(30,6),"AllowHexSpecifier")
$oid=[String]::Format(Β«{0}.{1}.{2}.{3}.{4}.{5}.{6}.{7}Β»,$prefix,$Parts[0],
$Parts[1],$Parts[2],$Parts[3],$Parts[4],$Parts[5],$Parts[6])
$oid
}
$schemaPath = (Get-ADRootDSE).schemaNamingContext
$oid = New-AttributeID
$attributes = @{
lDAPDisplayName = 'sshPublicKey';
attributeId = $id;
oMSyntax = 22;
attributeSyntax="2.5.5.5";
isSingleValued = $true;
adminDescription = 'User Public key para sa SSH login';
}
New-ADObject -Pangalan sshPublicKey -Type attributeSchema -Path $schemapath -OtherAttributes $attributes
$userSchema = get-adobject -SearchBase $schemapath -Filter 'name -eq "user"'
$userSchema | Set-ADObject -Add @{mayContain = 'sshPublicKey'}
Pagkatapos idagdag ang attribute, dapat mong i-restart ang Active Directory Domain Services.
Lumipat tayo sa mga user ng Active Directory. Sa anumang paraan na maginhawa para sa iyo, bumubuo kami ng isang pares ng mga susi para sa ssh na koneksyon.
Inilunsad namin ang PuttyGen, pindutin ang pindutan ng "Bumuo" at galit na galit na i-crawl ang mouse sa loob ng walang laman na lugar.
Sa pagkumpleto ng proseso, maaari naming i-save ang pampubliko at pribadong mga susi, i-upload ang pampublikong susi sa katangian ng gumagamit ng Active Directory at tamasahin ang proseso. Gayunpaman, ang pampublikong susi ay dapat gamitin mula sa "Pampublikong key para sa pag-paste sa OpenSSH authorized_keys file:".
Idagdag ang susi sa katangian ng user.
Opsyon 1 - GUI:
Opsyon 2 - PowerShell:
get-aduser user1 | set-aduser -add @{sshPublicKey = 'AAAAB...XAVnX9ZRJJ0p/Q=='}
Kaya, sa sandaling mayroon kami: isang user na may sshPublicKey attribute na napunan, isang naka-configure na Putty client para sa awtorisasyon sa pamamagitan ng mga key. May nananatiling isang maliit na punto, kung paano pilitin ang sshd daemon na hilahin ang pampublikong key na kailangan namin mula sa mga katangian ng user. Ang isang maliit na script na matatagpuan sa mga bukas na espasyo ng burges na Internet ay matagumpay na nakayanan ito.
cat /usr/local/bin/fetchSSHKeysFromLDAP
#!/bin/sh
ldapsearch -h testmdt.testopf.local -xb "dc=testopf,dc=local" '(sAMAccountName='"${1%@*}"')' -D [email protected] -w superSecretPassword 'sshPublicKey' | sed -n '/^ /{H;d};/sshPublicKey:/x;$g;s/n *//g;s/sshPublicKey: //gp'Itinakda namin ang mga karapatan dito 0500 para sa ugat.
chmod 0500 /usr/local/bin/fetchSSHKeysFromLDAP
Sa halimbawang ito, ang administrator account ay ginagamit upang sumailalim sa direktoryo. Sa mga kondisyon ng labanan, dapat mayroong isang hiwalay na account na may pinakamababang hanay ng mga karapatan.
Sa personal, labis akong napahiya sa sandali ng password sa dalisay nitong anyo sa script, sa kabila ng mga itinakdang karapatan.
Pagpipilian sa solusyon:
- I-save ko ang password sa isang hiwalay na file:
echo -n Supersecretpassword > /usr/local/etc/secretpass - Itinakda ko ang mga karapatan sa file 0500 para sa root
chmod 0500 /usr/local/etc/secretpass - Baguhin ang mga opsyon sa pagsisimula ng ldapsearch: parameter -w superSecretPassword baguhin sa -y /usr/local/etc/secretpass
Ang huling chord sa suite ngayon ay ang pag-edit ng sshd_config
cat /etc/ssh/sshd_config | egrep -v -E "#|^$" | grep -E "AuthorizedKeysCommand|PubkeyAuthe"
PubkeyAuthentication yes
AuthorizedKeysCommand /usr/local/bin/fetchSSHKeysFromLDAP
AuthorizedKeysCommandUser root
Bilang resulta, nakukuha namin ang sumusunod na pagkakasunud-sunod na may naka-configure na awtorisasyon ng mga susi sa ssh client:
- Kumokonekta ang user sa server sa pamamagitan ng pagtukoy sa kanyang login.
- Kinukuha ng sshd daemon ang halaga ng public key mula sa attribute ng user sa Active Directory sa pamamagitan ng isang script at nagsasagawa ng awtorisasyon sa pamamagitan ng mga key.
- Ang sssd daemon ay nagsasagawa ng karagdagang pagpapatunay ng user batay sa membership ng grupo. Pansin! Kung hindi na-configure, magkakaroon ng access ang sinumang domain user sa host.
- Kapag sinubukan mong sudo, hahanapin ng sssd daemon ang Active Directory para sa mga tungkulin. Kung may mga tungkulin, susuriin ang mga katangian at membership ng grupo ng user (kung naka-configure ang sudoRoles na gumamit ng mga grupo ng user)
Buod.
Kaya, ang mga susi ay naka-imbak sa mga katangian ng gumagamit ng Active Directory, mga pahintulot ng sudo - katulad din, ang pag-access sa mga host ng Linux gamit ang mga domain account ay isinasagawa sa pamamagitan ng pagsuri sa pagiging miyembro sa isang pangkat ng Active Directory.
Ang huling alon ng baton ng konduktor - at ang bulwagan ay nag-freeze sa magalang na katahimikan.
Mga mapagkukunang ginamit sa pagsulat:
Pinagmulan: www.habr.com