ProHoster > Bloc > Administració > Els guanyadors dels concursos internacionals SSH i sudo tornen a pujar a l'escenari. Dirigit per Distinguited Active Directory Conductor

Els guanyadors dels concursos internacionals SSH i sudo tornen a pujar a l'escenari. Dirigit per Distinguited Active Directory Conductor

Històricament, els permisos sudo es regien pel contingut dels fitxers de /etc/sudoers.d и visut, i l'autorització de clau es va dur a terme mitjançant ~/.ssh/authorized_keys. Tanmateix, a mesura que la infraestructura creix, hi ha la voluntat de gestionar aquests drets de manera centralitzada. Avui dia hi pot haver diverses opcions de solució:

  • Sistema de gestió de la configuració - Cuiner, titella, Ansible, Sal
  • Active Directory + sssd
  • Diverses perversions en forma de scripts i edició manual de fitxers

En la meva opinió subjectiva, la millor opció per a la gestió centralitzada segueix sent una combinació Active Directory + sssd. Els avantatges d'aquest enfocament són:

  • Veritablement un únic directori d'usuaris centralitzat.
  • Distribució de drets suo es redueix a afegir un usuari a un grup de seguretat específic.
  • En el cas de diversos sistemes Linux, es fa necessari introduir comprovacions addicionals per determinar el sistema operatiu quan s'utilitzen sistemes de configuració.

La suite d'avui estarà dedicada específicament a la connexió Active Directory + sssd per a la gestió dels drets suo i emmagatzematge ssh claus en un únic repositori.
Així, la sala es va congelar en un silenci tens, el director va aixecar la batuta i l'orquestra es va preparar.
Vaja.

Donat:
— Domini Active Directory testopf.local a Windows Server 2012 R2.
— Amfitrió Linux amb Centos 7
— Autorització configurada utilitzant sssd
Ambdues solucions fan canvis a l'esquema Active Directory, de manera que ho comprovem tot en un entorn de prova i només després fem canvis a la infraestructura de treball. M'agradaria assenyalar que tots els canvis estan orientats i, de fet, només afegeixen els atributs i les classes necessaris.

Acció 1: control suo rols a través Active Directory.

Per ampliar el circuit Active Directory heu de descarregar l'última versió suo — 1.8.27 a partir d'avui. Descomprimiu i copieu el fitxer schema.ActiveDirectory des del directori ./doc al controlador de domini. Des de la línia d'ordres amb drets d'administrador del directori on es va copiar el fitxer, executeu:
ldifde -i -f schema.ActiveDirectory -c dc=X dc=testopf,dc=local
(No us oblideu de substituir els vostres valors)
Obert adsiedit.msc i connecteu-vos al context predeterminat:
Creeu una divisió a l'arrel del domini suoers. (La burgesia afirma amb tossuda que és en aquesta unitat on el dimoni sssd cerca un element sudoRole objectes. Tanmateix, després d'activar la depuració detallada i estudiar els registres, es va revelar que la cerca es va realitzar a tot l'arbre de directoris.)
Creem el primer objecte que pertany a la classe de la divisió sudoRole. El nom es pot triar de manera absolutament arbitrària, ja que només serveix per a una identificació còmoda.
Entre els possibles atributs disponibles de l'extensió d'esquema, els principals són els següents:

  • sudoCommand — determina quines ordres es permeten executar a l'amfitrió.
  • sudoHost — determina a quins amfitrions s'aplica aquesta funció. Es pot especificar com ALL, i per a un host individual pel seu nom. També és possible utilitzar una màscara.
  • sudoUser — indiqueu quins usuaris poden executar suo.
    Si especifiqueu un grup de seguretat, afegiu un signe "%" al començament del nom. Si hi ha espais al nom del grup, no hi ha res de què preocupar-se. A jutjar pels registres, la tasca d'escapar dels espais és assumida pel mecanisme sssd.

Els guanyadors dels concursos internacionals SSH i sudo tornen a pujar a l'escenari. Dirigit per Distinguited Active Directory Conductor
Fig 1. Objectes sudoRole a la subdivisió sudoers a l'arrel del directori

Els guanyadors dels concursos internacionals SSH i sudo tornen a pujar a l'escenari. Dirigit per Distinguited Active Directory Conductor
Figura 2. Pertinença a grups de seguretat especificats als objectes sudoRole.

La configuració següent es fa al costat de Linux.
A l'arxiu /etc/nsswitch.conf afegiu la línia al final del fitxer:

sudoers: files sss

A l'arxiu /etc/sssd/sssd.conf a la secció [sssd] afegir als serveis suo

cat /etc/sssd/sssd.conf | grep services
services = nss, pam, sudo

Després de totes les operacions, cal esborrar la memòria cau del dimoni sssd. Les actualitzacions automàtiques es produeixen cada 6 hores, però per què hem d'esperar tant quan ho volem ara?

sss_cache -E

Sovint passa que esborrar la memòria cau no ajuda. Aleshores aturem el servei, netegem la base de dades i iniciem el servei.

service sssd stop
rm -rf /var/lib/sss/db/*
service sssd start

Ens connectem com a primer usuari i comprovem què està disponible a 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/cat

Fem el mateix amb el nostre segon usuari:

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

Aquest enfocament us permet definir de manera centralitzada rols sudo per a diferents grups d'usuaris.

Emmagatzematge i ús de claus ssh a Active Directory

Amb una lleugera expansió de l'esquema, és possible emmagatzemar claus ssh als atributs d'usuari d'Active Directory i utilitzar-les quan s'autoritzen als amfitrions Linux.

S'ha de configurar l'autorització mitjançant sssd.
Afegiu l'atribut necessari mitjançant un script de PowerShell.
AddsshPublicKeyAttribute.ps1Funció 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
$atributs = @{
lDAPDisplayName = 'sshPublicKey';
attributeId = $oid;
oMSyntax = 22;
attributeSyntax = "2.5.5.5";
isSingleValued = $true;
adminDescription = 'Clau pública d'usuari per a l'inici de sessió SSH';
}

Nou-ADObject -Name sshPublicKey -Type attributeSchema -Path $schemapath -OtherAttributes $attributes
$userSchema = get-adobject -SearchBase $schemapath -Filter 'nom -eq "usuari"'
$userSchema | Set-ADObject -Add @{mayContain = 'sshPublicKey'}

Després d'afegir l'atribut, heu de reiniciar els serveis de domini d'Active Directory.
Passem als usuaris d'Active Directory. Generarem un parell de claus per a la connexió ssh mitjançant qualsevol mètode que us convingui.
Llencem PuttyGen, premem el botó "Genera" i movem frenèticament el ratolí dins de l'àrea buida.
Un cop finalitzat el procés, podem desar les claus públiques i privades, pujar la clau pública a l'atribut d'usuari de l'Active Directory i gaudir del procés. Tanmateix, la clau pública s'ha d'utilitzar des del "Clau pública per enganxar al fitxer authorized_keys d'OpenSSH:".
Els guanyadors dels concursos internacionals SSH i sudo tornen a pujar a l'escenari. Dirigit per Distinguited Active Directory Conductor
Afegiu la clau a l'atribut d'usuari.
Opció 1 - GUI:
Els guanyadors dels concursos internacionals SSH i sudo tornen a pujar a l'escenari. Dirigit per Distinguited Active Directory Conductor
Opció 2: PowerShell:
get-aduser user1 | set-aduser -add @{sshPublicKey = 'AAAAB...XAVnX9ZRJJ0p/Q=='}
Per tant, actualment tenim: un usuari amb l'atribut sshPublicKey emplenat, un client Putty configurat per a l'autorització mitjançant claus. Queda un petit punt: com forçar el dimoni sshd a extreure la clau pública que necessitem dels atributs de l'usuari. Un petit guió que es troba a Internet burgesa pot fer front a això amb èxit.

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'

Hem establert els permisos en 0500 per a root.

chmod 0500  /usr/local/bin/fetchSSHKeysFromLDAP

En aquest exemple, s'utilitza un compte d'administrador per vincular-se al directori. En condicions de combat hi ha d'haver un compte separat amb un conjunt mínim de drets.
Personalment, vaig quedar molt confós pel moment de la contrasenya en la seva forma pura al guió, malgrat els drets establerts.
Opció de solució:

  • Deso la contrasenya en un fitxer a part: 
    echo -n Supersecretpassword > /usr/local/etc/secretpass

  • He establert els permisos dels fitxers a 0500 per a root 
    chmod 0500 /usr/local/etc/secretpass

  • Canviar els paràmetres d'inici de ldapsearch: paràmetre -w SuperSecretPassword Ho canvio per -y /usr/local/etc/secretpass

L'acord final de la suite d'avui és editar sshd_config

cat /etc/ssh/sshd_config | egrep -v -E "#|^$" | grep -E "AuthorizedKeysCommand|PubkeyAuthe"
PubkeyAuthentication yes
AuthorizedKeysCommand /usr/local/bin/fetchSSHKeysFromLDAP
AuthorizedKeysCommandUser root

Com a resultat, obtenim la següent seqüència amb l'autorització de clau configurada al client ssh:

  1. L'usuari es connecta al servidor indicant el seu inici de sessió.
  2. El dimoni sshd, mitjançant un script, extreu el valor de la clau pública d'un atribut d'usuari a Active Directory i realitza l'autorització mitjançant les claus.
  3. El dimoni sssd autentica encara més l'usuari en funció de la pertinença al grup. Atenció! Si això no està configurat, qualsevol usuari del domini tindrà accés a l'amfitrió.
  4. Quan proveu de sudo, el dimoni sssd cerca rols a l'Active Directory. Si hi ha rols, es comproven els atributs de l'usuari i la pertinença al grup (si sudoRoles està configurat per utilitzar grups d'usuaris)

Resum.

Així, les claus s'emmagatzemen als atributs d'usuari d'Active Directory, permisos sudo; de la mateixa manera, l'accés als amfitrions Linux per comptes de domini es realitza comprovant la pertinença al grup Active Directory.
L'onada final de la batuta del director i la sala es congela en un silenci reverent.

Recursos utilitzats per escrit:

Sudo mitjançant Active Directory
Claus Ssh mitjançant Active Directory
Script Powershell, afegint un atribut a l'esquema d'Active Directory
sudo llançament estable

Font: www.habr.com

Afegeix comentari