Integrare SLES 15 con Active Directory tramite SSSD in YaST

Per una tipica workstation o server SLES 15 che necessita di utenti e accessi basati su Active Directory, utilizzare User Logon Managementil modulo di YaST e selezionare Microsoft Active Directory sia per l'identità che per l'autenticazione; questo è il percorso basato su SSSD di SUSE. Ad esempio, questa procedura utilizza un host fittizio denominato linux01e un dominio ad.example.com. Si applica quando il client può raggiungere i servizi DNS e di sincronizzazione oraria di Active Directory e si dispone di credenziali di registrazione computer autorizzate.

Questa procedura segue la Guida alla sicurezza e alla protezione di SLES 15 SP7 di SUSE. I Service Pack precedenti potrebbero avere schermate YaST o dettagli del pacchetto diversi, quindi utilizzare la guida corrispondente al Service Pack installato. Se le vostre esigenze specifiche richiedono il supporto NTLM o trust tra foreste, SUSE indica il modulo separato di appartenenza al dominio Windows, basato su Winbind, come la soluzione più adatta.

Prima di connettersi: verificare DNS, ora e identità dell'host

Il rilevamento di Active Directory si basa sui record DNS e l'autenticazione Kerberos dipende da un orologio preciso. Configura il client SLES in modo che utilizzi un server DNS in grado di risolvere il dominio Active Directory e i relativi controller di dominio; in una configurazione comune, ciò significa utilizzare il server DNS di Active Directory anziché un resolver pubblico. Sincronizza il client con l'origine oraria approvata per il tuo dominio.

In YaST, apri Network Settings, seleziona Hostname/DNSe imposta Name Server 1sull'indirizzo del server DNS di AD. L'indirizzo nell'illustrazione è solo un segnaposto. Quindi verifica il nome host locale e lo stato dell'ora:

hostname
timedatectl status

Confronta il nome del computer con il nome registrato in Active Directory. Se differiscono, la finestra di dialogo di aggiunta di SUSE fornisce un AD hostnamecampo. Non disabilitare il firewall come scorciatoia per il rilevamento; chiedi al team di rete di consentire il traffico client-controller di dominio necessario in base alle regole della tua organizzazione. SUSE avverte inoltre che i nomi che terminano con .sudo .localpossono entrare in conflitto con il DNS multicast, quindi controlla la configurazione DNS se questo è il suffisso del tuo dominio.

Seleziona il modulo SSSD e aggiungi il dominio AD

In YaST, apri User Logon Management. Non scegliere Windows Domain Membershipper questa procedura: SUSE documenta quel modulo come basato su Winbind, mentre User Logon Management è l'opzione basata su SSSD ed è generalmente preferita per l'autenticazione AD.

Apri Change Settings, seleziona Add Domain, e inserisci il nome DNS del dominio, ad esempio ad.example.com. Imposta sia il servizio di identità che il servizio di autenticazione su Microsoft Active Directory, e assicurati Enable the domainche sia selezionato.

Mantieni le altre impostazioni predefinite a meno che il tuo ambiente non richieda un nome host AD specifico o un elenco fisso di controller di dominio. Se il rilevamento automatico DNS non è appropriato, inserisci i nomi host dei controller di dominio forniti dal tuo team AD. Seleziona OKquesta opzione affinché YaST possa installare il software mancante e verificare se un controller è raggiungibile.

Registra l'host e abilita gli accessi al dominio.

Quando YaST segnala di aver rilevato un server AD ma il computer non è ancora registrato, immettere l'account di registrazione autorizzato e la password. La finestra di dialogo documentata da SUSE utilizza un account amministratore di AD; seguire la procedura approvata dal team di directory per la registrazione dei computer e non inserire mai la password in uno script o in un articolo. Se la finestra di dialogo non riesce a rilevare un server, tornare alla verifica DNS e del nome host prima di riprovare.

Dopo la registrazione, abilita Allow Domain User Logon. Decidi se abilitarlo Create Home Directoriesin base ai criteri dei dati utente del server. Questo crea directory home locali per gli utenti di AD al primo accesso; è utile per una macchina che deve conservare i dati home locali, ma non crea né gestisce l'account utente in AD.

Se AD fornisce già l'attributo per ciascun utente UnixHomeDirectory, verificare che sia popolato e disponibile come richiesto dalla progettazione della directory. Quando il client necessita di un percorso di fallback, utilizzare Service Options> Name switch> Extended Optionsper configurarlo fallback_homedir, ad esempio /home/%u. SUSE documenta che viene utilizzato un percorso di fallback quando non viene fornito un percorso AD; override_homedirin tal caso, il valore del client ha la precedenza. Scegliere un'opzione solo dopo aver verificato i criteri della directory home.

Salva le impostazioni e rivedi il riepilogo della configurazione risultante. Se il sistema utilizza anche Samba, seleziona l'opzione per sovrascrivere la configurazione di Samba solo se si intende integrare tale sistema; questa operazione è separata dall'abilitazione dell'accesso utente basato su SSSD.

Verifica SSSD, ricerca utente e accesso Kerberos.

Verifica che SSSD sia attivo, quindi interroga un account di dominio reale utilizzando il formato del nome approvato per il tuo dominio. In questo esempio, sostituisci EXAMPLEe alicecon il nome di dominio breve e un account di prova esistente:

systemctl status sssd
getent passwd 'EXAMPLE\alice'

La presenza di una voce passwd conferma che NSS è in grado di risolvere l'account; tuttavia, non è sufficiente a dimostrare che l'utente possa autenticarsi o accedere alle applicazioni. Eseguire un test di accesso interattivo con le credenziali di dominio, utilizzando il modulo documentato DOMAIN_NAME\USER_NAMEnella console o nel display manager. Dopo l'accesso, eseguire un controllo klistper verificare se la sessione dispone di un ticket Kerberos.

Se SSSD è in esecuzione ma la ricerca dell'utente non riesce, ricontrollare il nome di dominio completo, il server DNS, il nome host e le selezioni di identità e autenticazione in YaST. Se la ricerca funziona ma l'accesso non riesce, verificare che l'account sia abilitato, che la password sia valida e che il client possa raggiungere il controller di dominio. Terminare solo dopo che un utente di test autorizzato è riuscito ad accedere, che il comportamento previsto della directory home è confermato e che i servizi richiesti dal server funzionano correttamente.

Fonti

• Guida alla sicurezza e alla protezione di SUSE SLES 15 SP7: supporto per Active Directory
• Guida alla sicurezza e alla protezione di SUSE SLES 15 SP7: SSSD e client di autenticazione
• Indice della documentazione di SUSE SLES 15 SP7