Histoarysk waarden sudo tagongsrjochten regele troch de ynhâld fan bestannen fan /etc/sudoers.d и visado, en kaai autorisaasje waard útfierd mei help fan ~/.ssh/authorized_keys. As ynfrastruktuer groeit, is d'r lykwols in winsk om dizze rjochten sintraal te behearjen. Hjoed kinne d'r ferskate oplossingsopsjes wêze:
- Konfiguraasjebehearsysteem - holle, Poppe, Sible, Sâlt
- Active Directory + ssd
- Ferskate perversions yn 'e foarm fan skripts en hânmjittich bewurkjen fan bestân
Yn myn subjektive miening is de bêste opsje foar sintralisearre behear noch in kombinaasje Active Directory + ssd. De foardielen fan dizze oanpak binne:
- Wierlik ien sintralisearre brûkersmap.
- Ferdieling fan rjochten sudo komt del op it tafoegjen fan in brûker oan in spesifike feiligensgroep.
- Yn it gefal fan ferskate Linux-systemen is it nedich om ekstra kontrôles yn te fieren om it OS te bepalen by it brûken fan konfiguraasjesystemen.
De suite fan hjoed sil spesifyk wijd wurde oan de ferbining Active Directory + ssd foar rjochten behear sudo en opslach ssh kaaien yn ien repository.
Dat, de seal befrieze yn spannende stilte, de dirigint tilde syn stokje op en it orkest makke him klear.
Gean.
Jûn:
- Active Directory-domein testopf.local op Windows Server 2012 R2.
- Linux-host mei Centos 7
- Konfigureare autorisaasje mei help fan ssd
Beide oplossingen meitsje feroarings oan it skema Active Directory, dus kontrolearje wy alles yn in testomjouwing en meitsje pas dan wizigingen yn 'e wurkynfrastruktuer. Ik soe graach opmerke dat alle feroarings binne rjochte en, yn feite, tafoegje allinnich de nedige attributen en klassen.
Aksje 1: kontrôle sudo rollen troch Active Directory.
Om it circuit út te wreidzjen Active Directory jo moatte de lêste release downloade -1.8.27 hjoed. Utpakke en kopiearje it bestân schema.ActiveDirectory fan de ./doc-map nei de domeincontroller. Fanút de kommandorigel mei administratorrjochten fan 'e map wêr't it bestân kopiearre is, útfiere:
ldifde -i -f schema.ActiveDirectory -c dc=X dc=testopf,dc=local
(Ferjit net jo wearden te ferfangen)
Iepenje adsiedit.msc en ferbine mei de standertkontekst:
Meitsje in divyzje oan 'e woartel fan it domein swit. (De boargerij beweart koppich dat it yn dizze ienheid is dat de demon ssd siket nei in item sudoRole objekten. Nei it ynskeakeljen fan detaillearre debuggen en it bestudearjen fan de logs, waard lykwols iepenbiere dat it sykjen waard útfierd troch de heule mapbeam.)
Wy meitsje it earste objekt dat heart ta de klasse yn 'e divyzje sudoRole. De namme kin absolút willekeurich keazen wurde, om't it allinnich tsjinnet foar handige identifikaasje.
Under de mooglike beskikbere attributen fan 'e skema-útwreiding binne de wichtichste de folgjende:
- sudoCommand - bepaalt hokker kommando's kinne wurde útfierd op 'e host.
- sudoHost - bepaalt hokker hosts dizze rol jildt. Kin oantsjutte as ALLE, en foar in yndividuele host by namme. It is ek mooglik om in masker te brûken.
- sudoUser - oanjaan hokker brûkers meie útfiere sudo.
As jo in befeiligingsgroep oantsjutte, foegje dan in teken "%" ta oan it begjin fan de namme. As der spaasjes yn 'e groepsnamme binne, is d'r neat te soargen oer. Troch de logs te oardieljen, wurdt de taak om romten te ûntkommen oernommen troch it meganisme ssd.
Fig 1. sudoRole foarwerpen yn de sudoers ûnderferdieling yn de woartel fan de map
figuer 2. Lidmaatskip yn feiligens groepen oantsjutte yn sudoRole objekten.
De folgjende opset wurdt dien oan 'e Linux-kant.
Yn triem /etc/nsswitch.conf foegje de rigel ta oan it ein fan it bestân:
sudoers: files sssYn triem /etc/sssd/sssd.conf yn seksje [sssd] tafoegje oan tsjinsten sudo
cat /etc/sssd/sssd.conf | grep services
services = nss, pam, sudo
Nei alle operaasjes moatte jo de sssd daemon-cache wiskje. Automatyske fernijings komme elke 6 oeren foar, mar wêrom moatte wy sa lang wachtsje as wy it no wolle?
sss_cache -EIt bart faak dat it leegjen fan de cache net helpt. Dan stopje wy de tsjinst, skjinje de database, en begjinne de tsjinst.
service sssd stop
rm -rf /var/lib/sss/db/*
service sssd start
Wy ferbine as de earste brûker en kontrolearje wat foar him beskikber is ûnder 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/catWy dogge itselde mei ús twadde brûker:
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
Dizze oanpak lit jo sudo-rollen sintraal definiearje foar ferskate brûkersgroepen.
Ssh-kaaien opslaan en brûke yn Active Directory
Mei in lichte útwreiding fan it skema is it mooglik om ssh-kaaien yn Active Directory-brûkersattributen op te slaan en se te brûken by it autorisearjen op Linux-hosts.
Autorisaasje fia sssd moat ynsteld wurde.
Foegje it fereaske attribút ta mei in PowerShell-skript.
AddsshPublicKeyAttribute.ps1Funksje 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 = $oid;
oMSyntaksis = 22;
attributeSyntax = "2.5.5.5";
isSingleValued = $true;
adminDescription = 'Iepenbiere kaai fan brûkers foar SSH-oanmelding';
}
New-ADObject -Name sshPublicKey -Type attributeSchema -Path $schemapath -OtherAttributes $attributes
$userSchema = get-adobject -SearchBase $schemapath -Filter 'name -eq "user"'
$userSchema | Set-ADObject -Add @{mayContain = 'sshPublicKey'}
Nei it tafoegjen fan it attribút moatte jo Active Directory Domain Services opnij starte.
Litte wy trochgean nei Active Directory-brûkers. Wy sille in kaaipaar generearje foar ssh-ferbining mei elke metoade dy't jo handich is.
Wy lansearje PuttyGen, drukke op de knop "Generearje" en ferpleatse de mûs frantysk binnen it lege gebiet.
Nei it foltôgjen fan it proses kinne wy de publike en partikuliere kaaien bewarje, de iepenbiere kaai oplade nei it Active Directory-brûkersattribuut en genietsje fan it proses. De iepenbiere kaai moat lykwols brûkt wurde fan 'e "Iepenbiere kaai foar plakken yn OpenSSH authorized_keys-bestân:".
Foegje de kaai ta oan it brûker attribút.
Opsje 1 - GUI:
Opsje 2 - PowerShell:
get-aduser user1 | set-aduser -add @{sshPublicKey = 'AAAAB...XAVnX9ZRJJ0p/Q=='}
Dat, wy hawwe op it stuit: in brûker mei it sshPublicKey-attribút ynfold, in konfigureare Putty-kliïnt foar autorisaasje mei kaaien. D'r bliuwt ien lyts punt: hoe kinne jo de sshd-daemon twinge om de iepenbiere kaai te ekstrahearjen dy't wy nedich binne út 'e attributen fan 'e brûker. In lyts skript fûn op it boargerlike ynternet kin dit mei súkses oan.
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'Wy sette de tagongsrjochten derop op 0500 foar root.
chmod 0500 /usr/local/bin/fetchSSHKeysFromLDAP
Yn dit foarbyld wurdt in administrator akkount brûkt om te binen oan de map. Yn fjochtsomstannichheden moat d'r in apart akkount wêze mei in minimum set rjochten.
Ik persoanlik wie tige yn 'e war troch it momint fan it wachtwurd yn syn suvere foarm yn it skript, nettsjinsteande de rjochten set.
Oplossingsopsje:
- Ik bewarje it wachtwurd yn in apart bestân:
echo -n Supersecretpassword > /usr/local/etc/secretpass - Ik set triemrjochten op 0500 foar root
chmod 0500 /usr/local/etc/secretpass - Lapsearch-startparameters feroarje: parameter -w superSecretPassword Ik feroarje it nei -y /usr/local/etc/secretpass
It lêste akkoard yn de hjoeddeiske suite is it bewurkjen fan sshd_config
cat /etc/ssh/sshd_config | egrep -v -E "#|^$" | grep -E "AuthorizedKeysCommand|PubkeyAuthe"
PubkeyAuthentication yes
AuthorizedKeysCommand /usr/local/bin/fetchSSHKeysFromLDAP
AuthorizedKeysCommandUser root
As gefolch krije wy de folgjende folchoarder mei kaaiautorisaasje konfigureare yn 'e ssh-client:
- De brûker makket ferbining mei de tsjinner troch syn oanmelding oan te jaan.
- De sshd-daemon, troch in skript, ekstrakt de publike kaaiwearde út in brûkersattribút yn Active Directory en fiert autorisaasje út mei de kaaien.
- De sssd-daemon ferifiearret de brûker fierder op basis fan groepslidmaatskip. Oandacht! As dit net ynsteld is, dan sil elke domeinbrûker tagong hawwe ta de host.
- As jo besykje te sudo, siket de sssd-daemon de Active Directory foar rollen. As rollen oanwêzich binne, wurde de attributen en groepslidmaatskip fan de brûker kontrolearre (as sudoRoles is ynsteld om brûkersgroepen te brûken)
It resultaat.
Sa wurde de kaaien opslein yn Active Directory brûkersattributen, sudo tagongsrjochten - op deselde manier wurdt tagong ta Linux-hosts troch domeinakkounts útfierd troch it kontrolearjen fan lidmaatskip yn 'e Active Directory-groep.
De lêste weach fan it stokje fan de dirigint - en de seal befriest yn earbiedige stilte.
Skriftlike boarnen brûkt:
Boarne: www.habr.com