Din punct de vedere istoric, permisiunile sudo au fost guvernate de conținutul fișierelor din /etc/sudoers.d и visado, iar autorizarea cheii a fost efectuată folosind ~/.ssh/authorized_keys. Cu toate acestea, pe măsură ce infrastructura crește, există dorința de a gestiona aceste drepturi la nivel central. Astăzi pot exista mai multe opțiuni de soluție:
- Sistem de management al configurației - bucătar-șef, Marionetă, ansiblu, Sare
- Active Directory + ssd
- Diverse perversiuni sub formă de scripturi și editare manuală a fișierelor
În opinia mea subiectivă, cea mai bună opțiune pentru managementul centralizat este încă o combinație Active Directory + ssd. Avantajele acestei abordări sunt:
- Într-adevăr, un singur director de utilizatori centralizat.
- Repartizarea drepturilor sudo se reduce la adăugarea unui utilizator la un anumit grup de securitate.
- În cazul diferitelor sisteme Linux, devine necesar să se introducă verificări suplimentare pentru a determina sistemul de operare atunci când se utilizează sisteme de configurare.
Suita de astăzi va fi dedicată special conexiunii Active Directory + ssd pentru gestionarea drepturilor sudo si depozitare ssh chei într-un singur depozit.
Așadar, sala a înghețat într-o tăcere tensionată, dirijorul a ridicat bagheta, iar orchestra s-a pregătit.
Hai să mergem.
Dat:
— domeniu Active Directory testopf.local pe Windows Server 2012 R2.
— Gazdă Linux care rulează Centos 7
— Autorizare configurată folosind ssd
Ambele soluții fac modificări schemei Active Directory, așa că verificăm totul într-un mediu de testare și abia apoi facem modificări la infrastructura de lucru. Aș dori să remarc că toate modificările sunt vizate și, de fapt, adaugă doar atributele și clasele necesare.
Acțiunea 1: control sudo roluri prin Active Directory.
Pentru a extinde circuitul Active Directory trebuie să descărcați cea mai recentă versiune — 1.8.27 de astăzi. Despachetați și copiați fișierul schema.ActiveDirectory din directorul ./doc la controlerul de domeniu. Din linia de comandă cu drepturi de administrator din directorul în care a fost copiat fișierul, rulați:
ldifde -i -f schema.ActiveDirectory -c dc=X dc=testopf,dc=local
(Nu uitați să vă înlocuiți valorile)
Deschidem adsiedit.msc și conectați-vă la contextul implicit:
Creați o diviziune la rădăcina domeniului pulovere. (Burghezia susține cu încăpățânare că demonul este în această unitate ssd caută un articol sudoRole obiecte. Cu toate acestea, după activarea depanării detaliate și studierea jurnalelor, a fost dezvăluit că căutarea a fost efectuată în întregul arbore de directoare.)
Creăm primul obiect aparținând clasei din diviziune sudoRole. Numele poate fi ales absolut arbitrar, deoarece servește numai pentru o identificare convenabilă.
Printre posibilele atribute disponibile din extensia de schemă, principalele sunt următoarele:
- sudoCommand — determină ce comenzi pot fi executate pe gazdă.
- sudoHost — determină gazdele cărora li se aplică acest rol. Poate fi specificat ca Toate colectiileși pentru o gazdă individuală după nume. De asemenea, este posibil să folosiți o mască.
- sudoUser — indicați ce utilizatori au voie să execute sudo.
Dacă specificați un grup de securitate, adăugați un semn „%” la începutul numelui. Dacă există spații în numele grupului, nu trebuie să vă faceți griji. Judecând după bușteni, sarcina de a scăpa de spații este preluată de mecanism ssd.
Fig 1. obiecte sudoRole din subdiviziunea sudoers din rădăcina directorului
Figura 2. Apartenența la grupurile de securitate specificate în obiectele sudoRole.
Următoarea configurare se face pe partea Linux.
În dosar /etc/nsswitch.conf adăugați linia la sfârșitul fișierului:
sudoers: files sssÎn dosar /etc/sssd/sssd.conf in sectiune [sssd] adăugați la servicii sudo
cat /etc/sssd/sssd.conf | grep services
services = nss, pam, sudo
După toate operațiunile, trebuie să ștergeți memoria cache a demonului sssd. Actualizările automate apar la fiecare 6 ore, dar de ce ar trebui să așteptăm atât de mult când ne dorim acum?
sss_cache -ESe întâmplă adesea ca ștergerea memoriei cache să nu ajute. Apoi oprim serviciul, curățăm baza de date și pornim serviciul.
service sssd stop
rm -rf /var/lib/sss/db/*
service sssd start
Ne conectăm ca prim utilizator și verificăm ce este disponibil pentru el sub 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/catFacem același lucru cu al doilea utilizator:
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
Această abordare vă permite să definiți central rolurile sudo pentru diferite grupuri de utilizatori.
Stocarea și utilizarea cheilor ssh în Active Directory
Cu o ușoară extindere a schemei, este posibil să stocați chei ssh în atributele utilizatorului Active Directory și să le folosiți atunci când autorizați pe gazde Linux.
Autorizarea prin sssd trebuie configurată.
Adăugați atributul necesar folosind un script PowerShell.
AddsshPublicKeyAttribute.ps1Funcția 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
$atribute = @{
lDAPDisplayName = 'sshPublicKey';
attributeId = $oid;
oMSyntax = 22;
attributeSyntax = "2.5.5.5";
isSingleValued = $adevărat;
adminDescription = 'Cheie publică utilizator pentru autentificare SSH';
}
New-ADObject -Name sshPublicKey -Type attributeSchema -Path $schemapath -OtherAttributes $attributes
$userSchema = get-adobject -SearchBase $schemapath -Filter 'nume -eq "utilizator"'
$userSchema | Set-ADObject -Add @{mayContain = 'sshPublicKey'}
După adăugarea atributului, trebuie să reporniți Active Directory Domain Services.
Să trecem la utilizatorii Active Directory. Vom genera o pereche de chei pentru conexiunea ssh folosind orice metodă convenabilă pentru dvs.
Lansăm PuttyGen, apăsăm butonul „Generează” și mișcăm frenetic mouse-ul în zona goală.
La finalizarea procesului, putem salva cheile publice și private, putem încărca cheia publică în atributul de utilizator Active Directory și ne putem bucura de proces. Cu toate acestea, cheia publică trebuie utilizată din "Cheie publică pentru lipire în fișierul authorized_keys OpenSSH:“.
Adăugați cheia la atributul utilizatorului.
Opțiunea 1 - GUI:
Opțiunea 2 - PowerShell:
get-aduser user1 | set-aduser -add @{sshPublicKey = 'AAAAB...XAVnX9ZRJJ0p/Q=='}
Deci, avem în prezent: un utilizator cu atributul sshPublicKey completat, un client Putty configurat pentru autorizare folosind chei. Mai rămâne un mic punct: cum să forțăm demonul sshd să extragă cheia publică de care avem nevoie din atributele utilizatorului. Un mic scenariu găsit pe internetul burghez poate face față cu succes acestui lucru.
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'Am setat permisiunile la 0500 pentru root.
chmod 0500 /usr/local/bin/fetchSSHKeysFromLDAP
În acest exemplu, un cont de administrator este utilizat pentru a lega directorul. În condiții de luptă trebuie să existe un cont separat cu un set minim de drepturi.
Personal am fost foarte confuz de momentul parolei în forma sa pură din script, în ciuda drepturilor setate.
Opțiunea soluției:
- Salvez parola într-un fișier separat:
echo -n Supersecretpassword > /usr/local/etc/secretpass - Am setat permisiunile fișierelor la 0500 pentru root
chmod 0500 /usr/local/etc/secretpass - Modificarea parametrilor de lansare ldapsearch: parametru -w superSecretPassword îl schimb în -y /usr/local/etc/secretpass
Acordul final din suita de astăzi este editarea sshd_config
cat /etc/ssh/sshd_config | egrep -v -E "#|^$" | grep -E "AuthorizedKeysCommand|PubkeyAuthe"
PubkeyAuthentication yes
AuthorizedKeysCommand /usr/local/bin/fetchSSHKeysFromLDAP
AuthorizedKeysCommandUser root
Ca rezultat, obținem următoarea secvență cu autorizarea cheii configurată în clientul ssh:
- Utilizatorul se conectează la server indicând login-ul său.
- Daemonul sshd, printr-un script, extrage valoarea cheii publice dintr-un atribut de utilizator din Active Directory și efectuează autorizarea folosind cheile.
- Daemonul sssd autentifică în continuare utilizatorul pe baza apartenenței la grup. Atenţie! Dacă aceasta nu este configurată, atunci orice utilizator de domeniu va avea acces la gazdă.
- Când încercați să faceți sudo, demonul sssd caută roluri în Active Directory. Dacă sunt prezente roluri, atributele utilizatorului și apartenența la grup sunt verificate (dacă sudoRoles este configurat pentru a utiliza grupuri de utilizatori)
Rezumat.
Astfel, cheile sunt stocate în atributele utilizatorului Active Directory, permisiunile sudo - în mod similar, accesul la gazdele Linux prin conturile de domeniu se realizează prin verificarea apartenenței la grupul Active Directory.
Valul final al baghetei dirijorului - și sala îngheață într-o tăcere reverentă.
Resurse folosite în scris:
Sursa: www.habr.com