Storicamente, le autorizzazioni sudo erano regolate dal contenuto dei file da /etc/sudoers.d и vistoe l'autorizzazione della chiave è stata eseguita utilizzando ~ / .ssh / authorized_keys. Tuttavia, con la crescita delle infrastrutture, vi è il desiderio di gestire questi diritti a livello centrale. Oggi potrebbero esserci diverse opzioni di soluzione:
- Sistema di gestione della configurazione - Chef, Fantoccio, ansible, Sale
- Active Directory + sss
- Varie perversioni sotto forma di script e modifica manuale dei file
Secondo la mia opinione soggettiva, l’opzione migliore per la gestione centralizzata rimane ancora una combinazione Active Directory + sss. I vantaggi di questo approccio sono:
- Veramente un'unica directory utente centralizzata.
- Distribuzione dei diritti sudo si tratta di aggiungere un utente a uno specifico gruppo di sicurezza.
- Nel caso di diversi sistemi Linux diventa necessario introdurre ulteriori controlli per determinare il sistema operativo quando si utilizzano sistemi di configurazione.
La suite di oggi sarà dedicata specificatamente alla connessione Active Directory + sss per la gestione dei diritti sudo e stoccaggio SSH chiavi in un unico repository.
Quindi, la sala si è gelata in un silenzio teso, il direttore ha alzato la bacchetta e l'orchestra si è preparata.
Andiamo.
data:
— Dominio di Active Directory testopf.local su Windows Server 2012 R2.
— Host Linux che esegue Centos 7
— Autorizzazione configurata utilizzando sss
Entrambe le soluzioni apportano modifiche allo schema Active Directory, quindi controlliamo tutto in un ambiente di test e solo successivamente apportiamo modifiche all'infrastruttura funzionante. Vorrei sottolineare che tutte le modifiche sono mirate e, di fatto, aggiungono solo gli attributi e le classi necessarie.
Azione 1: controllo sudo ruoli attraverso Active Directory.
Per espandere il circuito Active Directory è necessario scaricare l'ultima versione — 1.8.27 ad oggi. Decomprimere e copiare il file schema.ActiveDirectory dalla directory ./doc al controller di dominio. Dalla riga di comando con diritti di amministratore dalla directory in cui è stato copiato il file, eseguire:
ldifde -i -f schema.ActiveDirectory -c dc=X dc=testopf,dc=local
(Non dimenticare di sostituire i tuoi valori)
aprire la adsiedit.msc e connettersi al contesto predefinito:
Crea una divisione alla radice del dominio maglioni. (La borghesia sostiene ostinatamente che è in questa unità che si trova il demone sss cerca un elemento sudoRole oggetti. Tuttavia, dopo aver attivato il debug dettagliato e studiato i log, è stato rivelato che la ricerca è stata eseguita nell'intero albero delle directory.)
Creiamo il primo oggetto appartenente alla classe nella divisione sudoRole. Il nome può essere scelto in modo assolutamente arbitrario, poiché serve esclusivamente per una comoda identificazione.
Tra i possibili attributi disponibili dall'estensione dello schema, i principali sono i seguenti:
- sudoCommand — determina quali comandi possono essere eseguiti sull'host.
- sudoHost — determina a quali host si applica questo ruolo. Può essere specificato come TUTTOe per un singolo host per nome. È anche possibile utilizzare una maschera.
- sudoUser — indicare quali utenti sono autorizzati a eseguire sudo.
Se specifichi un gruppo di sicurezza, aggiungi un segno "%" all'inizio del nome. Se nel nome del gruppo sono presenti spazi, non c'è nulla di cui preoccuparsi. A giudicare dai registri, il compito di sfuggire agli spazi è assunto dal meccanismo sss.
Fig 1. Oggetti sudoRole nella suddivisione sudoers nella radice della directory
Figura 2. Appartenenza ai gruppi di sicurezza specificati negli oggetti sudoRole.
La seguente configurazione viene eseguita sul lato Linux.
In archivio /etc/nsswitch.conf aggiungi la riga alla fine del file:
sudoers: files sssIn archivio /etc/sssd/sssd.conf nella sezione [ssd] aggiungere ai servizi sudo
cat /etc/sssd/sssd.conf | grep services
services = nss, pam, sudo
Dopo tutte le operazioni, è necessario svuotare la cache del demone sssd. Gli aggiornamenti automatici avvengono ogni 6 ore, ma perché dovremmo aspettare così a lungo quando lo vogliamo adesso?
sss_cache -EAccade spesso che svuotare la cache non aiuti. Quindi interrompiamo il servizio, puliamo il database e avviamo il servizio.
service sssd stop
rm -rf /var/lib/sss/db/*
service sssd start
Ci colleghiamo come primo utente e controlliamo cosa è a sua disposizione sotto 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/catFacciamo lo stesso con il nostro secondo utente:
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
Questo approccio consente di definire centralmente i ruoli sudo per diversi gruppi di utenti.
Archiviazione e utilizzo delle chiavi ssh in Active Directory
Con una leggera espansione dello schema, è possibile memorizzare le chiavi ssh negli attributi utente di Active Directory e utilizzarle durante l'autorizzazione su host Linux.
L'autorizzazione tramite sssd deve essere configurata.
Aggiungi l'attributo richiesto utilizzando uno script PowerShell.
AggiungeshPublicKeyAttribute.ps1Funzione ID attributo nuovo {
$Prefisso="1.2.840.113556.1.8000.2554"
$GUID=[System.Guid]::NewGuid().ToString()
$Parti=@()
$Parti+=[UInt64]::Parse($guid.SubString(0,4),"AllowHexSpecifier")
$Parti+=[UInt64]::Parse($guid.SubString(4,4),"AllowHexSpecifier")
$Parti+=[UInt64]::Parse($guid.SubString(9,4),"AllowHexSpecifier")
$Parti+=[UInt64]::Parse($guid.SubString(14,4),"AllowHexSpecifier")
$Parti+=[UInt64]::Parse($guid.SubString(19,4),"AllowHexSpecifier")
$Parti+=[UInt64]::Parse($guid.SubString(24,6),"AllowHexSpecifier")
$Parti+=[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 = Nuovo ID attributo
$attributi = @{
lDAPDisplayName = 'sshPublicKey';
attributoId = $oid;
oMSintassi = 22;
attributoSyntax = "2.5.5.5";
isSingleValued = $true;
adminDescription = 'Chiave pubblica utente per accesso SSH';
}
New-ADObject -Name sshPublicKey -Tipo attributoSchema -Path $schemapath -OtherAttributes $attributes
$userSchema = get-adobject -SearchBase $schemapath -Filter 'nome -eq "utente"'
$schemautente | Set-ADObject -Add @{mayContain = 'sshPublicKey'}
Dopo aver aggiunto l'attributo, è necessario riavviare Servizi di dominio Active Directory.
Passiamo agli utenti di Active Directory. Genereremo una coppia di chiavi per la connessione ssh utilizzando qualsiasi metodo conveniente per te.
Lanciamo PuttyGen, premiamo il pulsante “Genera” e spostiamo freneticamente il mouse all'interno dell'area vuota.
Al completamento del processo, possiamo salvare le chiavi pubblica e privata, caricare la chiave pubblica nell'attributo utente di Active Directory e goderci il processo. Tuttavia, la chiave pubblica deve essere utilizzata dal "Chiave pubblica da incollare nel file Authorized_keys di OpenSSH:«.
Aggiungi la chiave all'attributo utente.
Opzione 1 - GUI:
Opzione 2 - PowerShell:
get-aduser user1 | set-aduser -add @{sshPublicKey = 'AAAAB...XAVnX9ZRJJ0p/Q=='}
Quindi, attualmente abbiamo: un utente con l'attributo sshPublicKey compilato, un client Putty configurato per l'autorizzazione tramite chiavi. Resta un piccolo punto: come forzare il demone sshd ad estrarre la chiave pubblica di cui abbiamo bisogno dagli attributi dell’utente. Un piccolo script trovato sull'Internet borghese può farcela con successo.
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'Impostiamo i permessi su 0500 per root.
chmod 0500 /usr/local/bin/fetchSSHKeysFromLDAP
In questo esempio viene utilizzato un account amministratore per eseguire il collegamento alla directory. In condizioni di combattimento deve esserci un conto separato con un insieme minimo di diritti.
Personalmente sono rimasto molto confuso dal momento della password nella sua forma pura nella sceneggiatura, nonostante i diritti impostati.
Opzione soluzione:
- Salvo la password in un file separato:
echo -n Supersecretpassword > /usr/local/etc/secretpass - Ho impostato i permessi dei file su 0500 per root
chmod 0500 /usr/local/etc/secretpass - Modifica dei parametri di avvio di ldapsearch: parametro -w password supersegreta Lo cambio in -y /usr/local/etc/secretpass
L'accordo finale nella suite di oggi è la modifica di sshd_config
cat /etc/ssh/sshd_config | egrep -v -E "#|^$" | grep -E "AuthorizedKeysCommand|PubkeyAuthe"
PubkeyAuthentication yes
AuthorizedKeysCommand /usr/local/bin/fetchSSHKeysFromLDAP
AuthorizedKeysCommandUser root
Di conseguenza, otteniamo la seguente sequenza con l'autorizzazione della chiave configurata nel client ssh:
- L'utente si connette al server indicando il proprio login.
- Il demone sshd, tramite uno script, estrae il valore della chiave pubblica da un attributo utente in Active Directory ed esegue l'autorizzazione utilizzando le chiavi.
- Il demone sssd autentica ulteriormente l'utente in base all'appartenenza al gruppo. Attenzione! Se questo non è configurato, qualsiasi utente del dominio avrà accesso all'host.
- Quando provi a eseguire sudo, il demone sssd cerca i ruoli in Active Directory. Se sono presenti ruoli, vengono controllati gli attributi dell'utente e l'appartenenza al gruppo (se sudoRoles è configurato per utilizzare i gruppi di utenti)
Riepilogo.
Pertanto, le chiavi vengono archiviate negli attributi utente di Active Directory, autorizzazioni sudo: allo stesso modo, l'accesso agli host Linux da parte degli account di dominio viene effettuato verificando l'appartenenza al gruppo Active Directory.
L'ultimo movimento della bacchetta del direttore d'orchestra - e la sala si congela in un silenzio riverente.
Risorse utilizzate per iscritto:
Fonte: habr.com