Aggiungere macchine RHEL o di qualsiasi altro sistema Linux direttamente in Microsoft Active Directory

A volte, la gestione dell'accesso ai sistemi della rete è un'attività complessa. Ho visto amministratori creare tutti gli utenti su tutti i computer, altri che condividono gli account utilizzando chiavi SSH o addirittura password e altri ancora che applicano il binding LDAP (a volte tramite l'infrastruttura Active Directory esistente oppure tramite un dominio diverso), nel qual caso devono scrivere query LDAP per filtrare l'accesso.

Questi metodi complicano la gestione dell'accesso ai computer e impongono agli amministratori di essere informati ogni volta che un utente abbandona o aderisce a un team. Gli account condivisi possono rendere inutile il login, poiché tutti avranno lo stesso nome utente. Molto probabilmente non sono il solo ad avere avuto una brutta esperienza con un reparto delle risorse umane che ha comunicato ai team tecnici una modifica apportata a un team. Ma c'è una soluzione che funziona bene e si integra con le configurazioni aziendali più diffuse.

La maggior parte delle aziende che conosco dispone di un sistema ERP che crea, disabilita o elimina automaticamente gli account utente in Microsoft Active Directory (AD), consentendo di trarre vantaggio dal lavoro svolto dagli altri. Ad esempio, il servizio SSSD può connettersi direttamente ad AD.

Se hai configurato un server di autenticazione per Linux che aveva una relazione di trust con AD, hai messo in comunicazione SSSD con i server AD. Ecco come funziona un trust: il server di autenticazione che hai configurato restituisce un riferimento ai server AD, in modo che SSSD possa inviare direttamente le query a questi. La configurazione seguente elimina la necessità di un server di autenticazione aggiuntivo e configura SSSD in modo che passi direttamente ad AD.

Ora dobbiamo chiederci come controllare l'accesso. È qui che entra in gioco il controllo degli accessi basato sui ruoli (RBAC). Con RBAC puoi evitare di assegnare l'accesso agli utenti e iniziare ad assegnare l'accesso ai ruoli. Una volta definiti i gruppi, potrai aggiungere un nuovo membro a un team, a cui è già assegnato un ruolo e che dispone dell'accesso appropriato a un gruppo di server. Ciò consente di evitare richieste come: "Sono appena stato assunto e ho bisogno dello stesso tipo di accesso di X", in cui X è una persona che ha lasciato l'azienda mesi fa, e per la quale sono stati eliminati tutti gli accessi.

Dopo essere stato aggiunto al gruppo del suo team, il nuovo utente avrà l'accesso richiesto. Ti evita anche di scoprire che qualcuno che ha lasciato l'azienda più di un anno fa ha ancora accesso a tutti i server, perché nessuno ha comunicato le dimissioni agli amministratori. Quando il sistema ERP aggiorna automaticamente gli account AD, elimina anche tutti gli accessi del collaboratore.

Fino a qualche tempo fa, era complicato gestire AD da sistemi operativi diversi da Windows. Da quando Microsoft ha rilasciato Windows Admin Center è possibile accedere alla console Utenti e computer di Active Directory da qualsiasi browser eseguito su qualsiasi sistema operativo. Permette inoltre di utilizzare diversi altri strumenti di gestione di Windows. Installandolo su un server Windows non dovrai più preoccuparti dei limiti delle sessioni o delle difficoltà con RemoteApp. Sarà sufficiente aprire un browser e accedere all'interfaccia web.

Configura i gruppi AD per il controllo degli accessi basato sui ruoli

Lo schema di denominazione della tua azienda potrebbe differire dagli esempi riportati in questo articolo, ma i nomi dei gruppi non sono importanti, mentre è fondamentale l'utilizzo previsto di ciascun gruppo.

Poiché SSSD non esegue la sincronizzazione dei gruppi di Active Directory e si limita a ottenere un elenco di gruppi di cui l'utente è membro durante la procedura di accesso, i gruppi che mancano non impediranno il funzionamento di questa configurazione. Se però all'interno di AD sono presenti più team con autorizzazioni delegate, è preferibile creare tutti i gruppi, in modo che non siano creati nell'unità organizzativa errata o che l'accesso sia sotto il controllo del team sbagliato.

Accesso a macchine specifiche

In Active Directory, crea due gruppi per ogni macchina. Entrambi i gruppi devono includere il nome breve della macchina. 

Un gruppo fornisce l'accesso SSH specifico per macchina (indicato come Machine_SSH_Access da qui in avanti).

L'altro fornisce l'accesso sudo specifico per macchina (indicato come Machine_SUDO_Access da qui in avanti).

Esempi di formati di gruppo:

<DOMAIN> Linux <hostname> ssh access
<DOMAIN> Linux <hostname> sudo access

• <hostname> è il nome breve della macchina
• <DOMAIN> è il nome breve del dominio ed è facoltativo

Accesso a tutte le macchine

In Active Directory crea due gruppi per l'accesso globale.

Uno dei gruppi fornisce l'accesso SSH (indicato come Global_SSH_Access da qui in avanti) a tutte le macchine.

L'altro fornisce l'accesso sudo (indicato come Global_SUDO_Access da qui in avanti) a tutte le macchine.

Esempi di formati di gruppo:

<DOMAIN> Linux ssh access
<DOMAIN> Linux sudo access

<DOMAIN> è il nome breve del dominio ed è facoltativo.

Nidificazione

È consentita la nidificazione all'interno dei gruppi AD. Per creare un gruppo con accesso a più macchine, non è necessario modificare la configurazione sulle macchine RHEL. Puoi invece configurare il nuovo gruppo come membro del gruppo di accesso per le macchine specifiche. Questo approccio consente di controllare l'accesso direttamente da AD.

Esempio di nidificazione:

• CONTOSO Linux Webserver1 ssh access
  • CONTOSO Linux Webservers ssh access
    • CONTOSO Web Developers
      • User1
      • User2

Questa nidificazione consente di assegnare ruoli (CONTOSO Web Developers) a gruppi di macchine (CONTOSO Linux Webservers ssh access) anziché utenti a sistemi specifici.

Aggiunta di una macchina Linux a un dominio

Se nell'ambiente in uso è abilitato RC4, leggi la procedura illustrata in questo Avviso di sicurezza Microsoft e disabilitalo.

Per aggiungere una macchina Linux a un dominio:

1. Installa i pacchetti richiesti:

$ sudo dnf install -y chrony krb5-workstation \
samba-common-tools oddjob-mkhomedir samba-common \
sssd authselect

2. Aggiungi la catena CA del dominio creando /etc/sssd/pki/sssd_auth_ca_db.pem e scrivendo la catena del dominio, che non deve necessariamente includere il certificato per i controller di dominio, ma può iniziare con il certificato che ha firmato i relativi certificati.
3. Aggiungi la catena CA ai trust anchor del sistema:

$ sudo trust anchor /etc/sssd/pki/sssd_auth_ca_db.pem

4. Configura SSSD modificando /etc/sssd/sssd.conf o /etc/sssd/conf.d/<DOMAIN>.conf in modo che corrisponda alle righe seguenti.

La modifica di /etc/sssd/conf.d/<DOMAIN>.conf è il metodo più recente e preferito, ma è valida anche la modifica di /etc/sssd/sssd.conf.

[domain/<DOMAIN>]
access_provider = simple
auth_provider = ad
chpass_provider = ad
id_provider = ad
dyndns_update = true
override_homedir = /home/%u
override_shell = /bin/bash
default_shell = /bin/bash
ldap_idmap_range_size = 4000000
cache_credentials = true
simple_allow_groups = Global_SSH_Access, Global_SUDO_Access, Machine_SSH_Access, Machine_SUDO_Access
ignore_group_members = true
ad_gpo_access_control = disabled
ad_enable_gc = false
ad_use_ldaps = true
[sssd]
services = nss, pam
config_file_version = 2
domains = <DOMAIN>

• <DOMAIN> è il nome di dominio completo del tuo dominio, TUTTO MAIUSCOLO. Non utilizzando tutte le lettere maiuscole, potrebbero verificarsi problemi di autenticazione.
• ldap_idmap_range_size è facoltativo, ma necessario se si lavora in ambiente AD di grandi dimensioni. La modifica di questo valore comporta la modifica dell'hash UID, quindi non modificarlo una volta che la macchina è stata aggiunta al dominio e assicurati di utilizzare lo stesso valore su tutte le macchine.
• Global_SSH_Access, Global_SUDO_Access, Machine_SSH_Access e Machine_SUDO_Access sono i gruppi AD creati in precedenza per il controllo degli accessi basato sui ruoli.

5. Imposta le autorizzazioni per il file appena scritto: /etc/sssd/sssd.conf o /etc/sssd/conf.d/<DOMAIN>.conf:

$ sudo chmod 400 /etc/sssd/sssd.conf

oppure

$ sudo chmod 400 /etc/sssd/conf.d/*.conf

6. Configura KRB5 modificando /etc/krb5.conf in modo che corrisponda alle righe seguenti:

[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log

[libdefaults]
dns_lookup_realm = true
dns_lookup_kdc = true
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true
rdns = true
default_ccache_name = KEYRING:persistent:%{uid}
default_realm = <DOMAIN>

[realms]

[domain_realm]

Non è necessario specificare nulla in [realms] né in [domain_realm]. SSSD rileva automaticamente queste informazioni dal DNS.

7. Configura l'accesso SUDO creando un file in /etc/sudoers.d:

$ sudo visudo -f /etc/sudoers.d/<DOMAIN>

Specifica l'accesso sudo predefinito per i membri dei gruppi sudo di AD. Puoi utilizzare qualsiasi nome file desiderato, e non deve necessariamente essere chiamato DOMAIN.

È necessario che ogni spazio sia preceduto da una barra rovesciata (\). Ad esempio: "Linux sudo access" deve essere scritto come "Linux\ sudo\ access".

%Global_SUDO_Access  ALL=(ALL) ALL
%Machine_SUDO_Access  ALL=(ALL) ALL

Global_SUDO_Access e Machine_SUDO_Access sono i gruppi AD creati in precedenza per il controllo degli accessi basato sui ruoli. Il segno di percentuale (%) prima del nome del gruppo indica che si tratta di un gruppo.

Puoi definire nello stesso modo, in file separati o nello stesso file, qualsiasi altro accesso sudo da concedere ai gruppi AD.

8. Verifica che il nome host della macchina sia impostato sul nome di dominio completo. Il nome host della macchina non può corrispondere al nome breve:

$ sudo hostnamectl set-hostname $(hostname -f)

9. Aggiungi la macchina con uno dei seguenti comandi (adcli è compatibile con SMBv1 e SMBv2). Per impostare le informazioni sul sistema operativo in AD durante l'aggiunta, utilizza il comando seguente:

$ source /etc/os-release
$ sudo adcli join -U <join_user> --os-name="${NAME}" \
--os-version="${VERSION}" --os-service-pack="${VERSION_ID}"

In alternativa, puoi aggiungere la macchina senza impostare le informazioni sul sistema operativo:

$ sudo adcli join -U <join_user>

<join_user> è l'account AD che verrà utilizzato per aggiungere la macchina al dominio. La password richiesta da adcli non viene memorizzata. Nell'articolo Delegated Permissions vengono descritte le autorizzazioni necessarie per l'aggiunta.

10. Abilita e avvia SSSD e oddjobd:

$ sudo systemctl enable sssd oddjobd
$ sudo systemctl restart sssd oddjobd

11. Abilita l'accesso con AD:

$ sudo authselect select sssd with-mkhomedir --force

A condizione che il tuo account sia membro di uno dei gruppi che hai creato, ora potrai accedere alla macchina. Non è necessario specificare il dominio. Viene utilizzato il dominio specificato come default_realm in /etc/krb5.conf. GNOME potrebbe richiedere il riavvio, mentre in genere sshd accetta le modifiche senza chiedere il riavvio.

Aggiorna costantemente le informazioni sul sistema operativo

Per impostazione predefinita, l'oggetto computer non è autorizzato ad aggiornare le proprie informazioni sul sistema operativo. Assicurati di accedere a Utenti e computer di Active Directory e di autorizzare SELF a scrivere in ogni campo del sistema operativo negli oggetti del computer (puoi farlo a livello di unità organizzativa). Al termine, aggiorna l'oggetto AD con le informazioni più recenti sul sistema operativo:

$ source /etc/os-release
$ sudo /usr/sbin/adcli update --os-name="${NAME}" \
--os-version="${VERSION}" --os-service-pack="${VERSION_ID}"

Queste informazioni possono essere aggiunte come processo cron o come servizio systemd. Ad esempio:

[Unit]
Description=Updates AD with current OS information
After=sssd.service

[Service]
Type=oneshot
EnvironmentFile=/etc/os-release
ExecStart=/usr/sbin/adcli update --os-name="${NAME}" --os-version="${VERSION}" --os-service-pack="${VERSION_ID}"

[Install]
WantedBy=multi-user.target

Abilita l'autenticazione tramite smart card

Questa sezione presuppone che l'autenticazione tramite smart card sia già stata configurata sui computer Windows. In caso contrario, configurare l'autenticazione tramite smart card su un computer Windows prima di procedere.

1. Scrivi la catena di certificati per il tuo dominio in /etc/sssd/pki/sssd_auth_ca_db.pem. che non deve necessariamente includere il certificato per i controller di dominio, ma può iniziare con il certificato che ha firmato i relativi certificati.
2. Aggiungi il certificato all'elenco delle CA attendibili della macchina:

$ sudo trust anchor /etc/sssd/pki/sssd_auth_ca_db.pem

3. Modifica /etc/sssd/sssd.conf o /etc/sssd/conf.d/<DOMAIN>.conf, in base al file utilizzato quando il dominio è stato aggiunto al sistema, quindi aggiungi la riga seguente nella sezione [domain/<DOMAIN>]. Questa voce indica a SSSD dove cercare il certificato utente. Poiché Windows utilizza l'attributo userCertificate, se si utilizza lo stesso attributo, la smart card funzionerà sia su Linux che su Windows.

ldap_user_certificate = userCertificate;binary

Aggiungi queste righe alla fine dello stesso file di configurazione:

[pam]
pam_cert_auth = true

4. Modifica /etc/krb5.conf e aggiungi le seguenti righe in [realms], sostituendo <DOMAIN> con il nome di dominio completo del tuo dominio, scritto in LETTERE MAIUSCOLE. In questo modo vengono risolte le mancate corrispondenze che possono verificarsi perché Windows non distingue tra maiuscole e minuscole, al contrario di Linux.

<DOMAIN> = {
pkinit_anchors = DIR:/etc/sssd/pki
  pkinit_kdc_hostname = <DOMAIN>
}

5. Utilizza uno dei seguenti comandi per abilitare l'autenticazione tramite smart card in PAM:

• authselect enable-feature with-smartcard: abilita l'opzione per l'autenticazione tramite smart card.
• authselect enable-feature with-smartcard-required: richiede l'autenticazione tramite smart card. Per impostazione predefinita, sshd non invia una chiamata a PAM durante l'autenticazione con chiavi SSH.
• authselect enable-feature with-smartcard-lock-on-removal: richiede l'autenticazione tramite smart card e blocca la macchina quando la smart card viene rimossa.

Abilita l'accesso SSH utilizzando il certificato della smart card

In RHEL 8 e versioni successive, è possibile abilitare l'accesso SSH utilizzando una smart card.

1. Verifica che il certificato della smart card venga letto correttamente da AD:

sss_ssh_authorizedkeys ${USER}

Se non viene restituita una chiave pubblica, verifica che l'autenticazione tramite smart card sia configurata correttamente.

2. Modifica /etc/ssh/sshd_config aggiungendo queste righe:

AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys
AuthorizedKeysCommandUser nobody

3. Riavvia sshd:

$ sudo systemctl restart sshd

Per accedere da un client tramite SSH, utilizza l'opzione PKCS11Provider=/usr/lib64/opensc-pkcs11.so. A condizione che la smart card corrisponda a una chiave pubblica dell'utente, verrà richiesto di inserire il PIN o la password della smart card:

$ ssh -o PKCS11Provider=/usr/lib64/opensc-pkcs11.so <host>

Ulteriori informazioni

Hai aggiunto al dominio una macchina dotata del controllo degli accessi basato sui ruoli che consente di stabilire chi può accedere o eseguire comandi con privilegi. La gestione diventa più semplice perché puoi trarre vantaggio dal lavoro già compiuto da altri. Ecco alcuni aspetti di cui tenere conto:

• La disattivazione di un utente in AD blocca immediatamente l'accesso dell'utente al computer. Proprio come con Windows, chiunque abbia già effettuato l'accesso rimane connesso.
• Le modifiche ai gruppi dell'utente vengono aggiornate durante l'accesso, proprio come avviene con Windows. Questa operazione viene eseguita prima di verificare se sono autorizzati ad accedere.
• SSSD riconosce i siti. Se configuri i siti nella console Siti e servizi di Active Directory, SSSD si connette al controller di dominio appropriato.
• SSSD abilita la rotazione automatica della password della macchina.
• SSSD crea e gestisce automaticamente i record DNS di una macchina, purché siano abilitati gli aggiornamenti dinamici (protetti o non protetti).

In genere sconsiglio di utilizzare gli strumenti Windows per gestire i sistemi Linux e viceversa, perché possono verificarsi perdite di funzionalità importanti o problemi di sicurezza, oppure perché è più semplice eseguire la stessa attività con uno strumento nativo. Con Active Directory però è diverso. Gli sviluppatori di SSSD si sono impegnati molto per garantirne la compatibilità con AD, semplificando così il tuo lavoro.