Autenticazione di sistemi Linux verso un dominio Active Directory con SSSD

Abbiamo visto in questo articolo Autenticazione di sistemi Linux verso un dominio Active Directory con Winbind le modalità in cui può essere integrato un sistema Linux all’interno di un dominio Active Directory, e le possibilità offerte nativamente in ambiente Open Source.

La soluzione proposta prendeva in considerazione il provider di autenticazione Winbind che come già detto nelle ultime versioni di sistema operativo non è più utilizzato.

Vedremo ora in questo secondo articolo le possibilità offerte dal demone SSSD che è diventata la soluzione disponibile di default sulle versioni Linux più recenti

Lo schema qui sotto riporta le entità che sono coinvolte nel processo di autenticazione ed identificazione di un utente all’atto del login su un sistema Linux che utilizza Active Directory per la gestione centralizzata degli utenti.

Figura 1 Schema del processo di autenticazione con SSSD

Demone SSSD

Configurazione per l’autenticazione verso AD

Come abbiamo detto in precedenza il demone SSSD è il provider di autenticazione utilizzato dalle versioni 7 in poi delle distribuzioni RedHat e delle sue derivate.

Per analogia con la descrizione precedente, relativa al modulo Winbind, vediamo quali pacchetti sono necessari per poter utilizzare SSSD

  • Oddjob
  • Oddjob-mkhomedir
  • SSSD
  • Samba-common-tools
  • Adcli

Per installare i vari pacchetti e le loro dipendenze, come visto per Winbind, è importante utilizzare Yum in modo da automatizzare l’installazione.

Terminata l’installazione dei pacchetti richiesti con il comando realm è possibile effettuare l’intera configurazione di Linux.

Realm è un tool a riga di comando che configura l’enrollment di un sistema all’interno di un REALM Kerberos come è Active Directory, se il sistema Linux è configurato correttamente, con questo comando si può effettuare il discovery in modo da ottenere informazioni preliminari utili alla successiva integrazione.

Questa funzione utilizza il DNS di Active Directory per fornire e/o recuperare le informazioni relative a Kerberos.

realm discover -v test.local ( dove test.local è il dominio di riferimento)

Figura 2 discover del Realm

Viene effettuata una ricerca DNS su _ldap.tcp.test.local in riferimento al dominio DNS di default specificato nella configurazione di rete del sistema Linux.

A questo punto siamo ragionevolmente sicuri che il Dominio AD è raggiungibile, o meglio il DNS è configurato in modo da fornirne le informazioni.

Il passo successivo è quello di effettuare il join al dominio sempre tramite il comando realm

realm join -v TEST.LOCAL

questo è il comando con le opzioni minime per effettuare il join al dominio

Durante il join è possibile collocare il l’account macchina relativo server direttamente in una Organizational Unit definita sull’albero AD:

realm join --user=utente –computer-ou=OU=Linux,OU=Server,DC=test,DC=local TEST.LOCAL -v

Figura 3 join della macchina Linux al Dominio

Su Active Directory l’account è creato nella Organizational Unit specificata nel comando

Figura 4 Account Macchina creato nella OU specificata in fase di Join

Nota: è bene, se possibile, pima di procedere con la configurazione, effettuare un Update generale del sistema tramite il comando yum update, questo per evitare problemi che alcune versioni possono presentare all’atto della configurazione.

La versione 7.1 di Oracle Linux se installata senza effettuare un Update tramite YUM, all’atto del join al dominio con il comando realm, presenta un errore relativo al comando /usr/bin/net questo errore viene risolto effettuando un update completo.

Configurare gli utenti autorizzati ad effettuare Logon al server

Per analogia con la configurazione vista in precedenza con Winbind è necessario definire quali utenti o gruppi di AD possono effettuare accesso al sistema questa impostazione è configurabile sempre tramite il comando realm, supponendo di concedere al gruppo admin-server il permesso di accesso dovremo eseguire questo comando

realm permit -g admin-server@test.local

l’esecuzione del commando imposta il file /etc/sssd/sssd.conf in modo da consentire solo l’accesso a questo gruppo

se invece si dovesse attribuire il permesso di login all’utente adminserver anziché ad un gruppo il comando dovrà essere:

realm permit adminserver@test.local

il file /etc/sssd/sssd.conf verrà così modificato e verranno aggiunte le righe simple_allow_user e simple_allow_group, qualora vengano specificati più di un gruppo o più di un utente questi saranno separati da virgola.

Figura 6 dichiarazione degli utenti e gruppi di accesso

La rimozione di un gruppo può essere effettuata con il comando

realm permit –withdraw -g admin-server@test.local

Mentre per rimuovere un utente si dovrà digitare

realm permit –withdraw adminserver@test.local

Concessione dei diritti di Sudoer

Anche in questo caso come visto per Winbind è possibile specificare quali utenti possono avere i diritti di Sudoer, la modalità è analoga alla precedente, ossia l’utilizzo di visudo, la differenza è nel modo in cui questi vengono dichiarati

Per consentire l’accesso al gruppo admin-server sarà necessario inserire la riga seguente nel file sudoers

%admin-server@test.local ALL=(ALL) ALL

Figura 7 Dichiarazione dei Sudoer

Anche in questo caso se I diritti di Sudoer dovranno essere attribuiti ad un utente anziché ad un gruppo bisognerà omettere il % ad inizio riga.

La configurazione di Linux sul dominio è terminata e come nel caso visto in precedenza gli utenti a cui è stato concesso il permesso di logon possono accedere ed operare con il diritto di Sudoer

Personalizzazioni dell’ambiente di accesso

In alcuni casi per regole Aziendali può essere richiesto che all’accesso dell’utente venga presentato un messaggio informativo, in ambiente Windows è possibile la gestione tramite GPO, in Linux è necessario effettuare questa impostazione da un lato sulla configurazione del demone SSH e dall’altro sull’accesso in console.

Modifica del messaggio di login utente

Il file /etc/issue viene presentato come pre-login a tutti gli utenti che “affacciano” localmente al sistema, il suo contenuto è presentato direttamente all’utente al momento dell’accesso.

Nel caso in cui il server Linux sia utilizzato tramite postazioni remote in SSH è possibile visualizzare anche a questi utenti il contenuto dello stesso file.

Questo comportamento del login tramite SSH è gestibile modificando la riga banner in /etc/ssh/sshd_config ed impostandola come riportato qui sotto

Banner /etc/issue rimuovendo il commento iniziale

Dopo aver effettuato questa modifica è necessario riavviare il servizio SSH

considerazioni generali

Le configurazioni viste in questa guida utilizzano Kerberos e quindi in questo ambiente è determinante che sia la configurazione DNS che la configurazione NTP relativa al demone di sincronizzazione oraria in Linux siano correttamente configurate analogamente a quanto avviene normalmente per i sistemi Windows

Riferimenti:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/sssd-ad-integration.html