• Guide, Open Source
• 21 Gennaio 2017

A partire dal suo primo rilascio nel 1991 Linux prevedeva esclusivamente autenticazioni locali o verso sistemi NIS, successivamente sono state sviluppate le integrazioni dapprima con i sistemi di directory disponibili sul mercato a quel tempo, e successivamente, intorno agli anni 2000, verso Windows.

Con l’evoluzione di Linux da un lato e Windows dall’altro le integrazioni tra i due sistemi sono diventate via via più strette, diventando possibile integrare completamente l’autenticazione di Linux in Active Directory.

Quando si parla di integrazione verso Active Directory normalmente si considerano le risorse che sono messe reciprocamente in comune tra le due famiglie di sistemi.

In uno scenario di questo tipo il dominio AD è usato come sorgente di autenticazione a cui Linux e Windows si riferiscono per consentire l’accesso alle rispettive risorse.

Le funzioni di autenticazione sono parte di uno scenario più ampio di integrazione, l’evoluzione di queste possibilità, all’inizio molto rigide, ha portato allo sviluppo di moduli di autenticazione aperti, quali sono i Pluggable Authentication Module (PAM) questo fa sì che non solo il sistema operativo, ma qualunque servizio in grado di interfacciarsi con questi moduli possa autenticare i propri utenti verso AD.

Un server Linux può mettere a disposizione il proprio spazio dischi, le proprie stampanti etc. tramite Samba in modo del tutto simile a Windows, il controllo di accesso è comunque assoggettato ad Active Directory per entrambe gli ambienti.

In questo articolo non ci occuperemo di come possono essere condivise le risorse in Linux, ma della modalità in cui questo può utilizzare il dominio Active Directory per effettuare l’autenticazione degli utenti, vedremo anche come è possibile discriminarne l’accesso secondo l’appartenenza a gruppi in modo da consentire il login esclusivamente ad un gruppo di utenti. Un passo ulteriore sarà quello di concedere, sempre sulla base dell’appartenenza ad un gruppo, i diritti di Sudoer.

In questo modo gli amministratori di sistema potranno garantire in sicurezza l’accesso ai propri sistemi, potendo differenziare ulteriormente chi dovrà operare come Sudoer e chi no.

Premessa:

Linux è una galassia molto varia di distribuzioni e versioni, in un solo articolo, comprendere tutte le differenze di implementazione che contraddistinguono le varie release non sarebbe possibile, ci soffermeremo sulle distribuzioni RedHat, Oracle Linux e Centos che sono praticamente identiche da questo punto di vista.

Altre distribuzioni presentano la stessa logica di implementazione KerberosWinbind (Samba) ma con alcune differenze di configurazione

Provider di autenticazione Winbind e SSSD

Come detto in precedenza, nel corso del tempo le soluzioni di autenticazione sono cambiate, tra queste, in modo nativo su Linux sono disponibili Winbind e SSSD.

Winbind è un ambiente integrato all’interno di Samba e viene utilizzato come provider di autenticazione su Linux è disponibile al sistema come Modulo PAM (Pluggable Authentication Module) e quindi può essere usato da diversi servizi per poter effettuare autenticazioni verso Active Directory.

L’evoluzione del modulo Winbind ha seguito l’evolversi di Windows integrandosi dapprima con NTLM e successivamente con AD per mezzo di Kerberos.

È bene anche specificare che Winbind è stata (ed è) la soluzione privilegiata fino alla versione 6.8 del sistema operativo.

Dalla versione 7 questa modalità di autenticazione è stata “dismessa” e SSSD (System Security Services Daemon) è diventato il modello di autenticazione di riferimento.

SSSD è nato come derivazione del progetto FreeIPA e può sostituire Winbind nei processi di autenticazione verso sistemi centralizzati quali AD, Ldap ed altri.

È un servizio che nasce come progetto a sé stante a differenza di Winbind che è compreso all’interno di SAMBA. SSSD presenta le seguenti differenze rispetto a Winbind:

• consente più connettori verso sorgenti diverse, AD, LDAP FreeIPA etc.
• mantiene in cache le credenziali utilizzate in modo da ridurre il traffico di autenticazione e permette l’accesso anche se il domain controller non è disponibile
• consente un debug più semplice rispetto a Winbind

• non supporta NTLM come protocollo di autenticazione
• non supporta TRUST di Active directory di tipo Cross Forest, in questo caso è necessario che vengano utilizzati sistemi IDM per l’autenticazione.

Per approfondire potete leggere l’articolo Autenticazione di sistemi Linux verso un dominio Active Directory con SSSD.

Questo in estrema sintesi il panorama in cui ci possiamo muovere se dobbiamo utilizzare sistemi OpenSource in ambienti in cui Active Directory è la sorgente di autenticazione.

Sebbene questi due provider di autenticazione sono diventati il default rispettivamente per le versioni 6 e 7 del sistema operativo, è comunque possibile installare SSSD sulle versioni 6 e Winbind sulle versioni 7.

WINBIND

Configurazione per l’autenticazione verso AD

Per poter configurare correttamente Winbind occorre verificare che sul sistema siano presenti i seguenti pacchetti, alcuni utilizzati da Kerberos ed i rimanenti utilizzati da Winbind, e come vediamo anche alcuni componenti di Samba

Modulo Kerberos pacchetti richiesti

• krb5-workstation
• pam_krb5
• krb5-auth
• krb5-libs

Modulo Samba/ Winbind pacchetti richiesti

• samba-common
• samba-client

Nota:

(è consigliabile utilizzare Yum per l’installazione, questo ci permette di essere certi di utilizzare versioni corrette e soprattutto di installare anche le eventuali dipendenze richieste)

terminata l’installazione è sufficiente lanciare il comando authconfig-tui da prompt di sistema.

Authconfig-tui richiede una serie di informazioni, prepara le configurazioni ed effettua il joinig al dominio della macchina Linux gestendo e modificando i vari file di configurazione in autonomia.

Siccome la configurazione di default non prevede che siano “filtrati” gli accessi e quindi ogni utente del dominio può effettuare il logon, si dovranno modificare altre impostazioni per consentire l’accesso ad utenti di particolari gruppi definiti in AD.

Obiettivo di questa configurazione è di fare sì che l’amministratore possa delegare ad utenti o gruppi la gestione dei sistemi senza dover necessariamente utilizzare l’utente root

Figura 1 authconfig-tui

Questa è la prima videata del tool di configurazione, sono cerchiate in rosso le scelte utilizzate per questa configurazione “use Winbind“, “Use MD5 Passwords“,” Use Shadow Passwords” e “Use Winbind Authentication”

Nella videata successiva, procedendo con Next dovremo fornire le impostazioni relative al dominio verso il quale effettuare il join

Figura 2 Impostazioni di riferimento per il dominio

1. security model “ads“
2. Domain impostare il nome NETBIOS del Dominio
3. Impostare i nomi dei Domain Controller ognuno separato da virgola
4. ADS REALM verrà utilizzato per la compilazione del file krb5.conf e per il riferimento a Kerberos
5. Definire la Shell con cui l’utente opererà quando connesso sul server Linux

Una volta impostati questi parametri proseguire con “Join Domain” ed ok sulla scelta successiva

Qui verrà richiesto di impostare la password dell’utente Administrator di Active Directory potremo anche utilizzare le credenziali di un qualunque altro utente con permessi di “aggiunta Workstation al dominio”

Figura 3 Impostazione delle Credenziali per il Join

Confermando ulteriormente con Ok viene completata la procedura ed una volta usciti dalla configurazione è possibile controllare con il comando net ads testjoin se il server è realmente membro del dominio AD

Figura 4 Controllo del Join

Se la procedura è andata a buon fine compare il messaggio Join is OK, i comandi successivi possono essere utili per una ulteriore diagnostica dell’ambiente

• net ads info (visualizza informazioni sul dominio AD)
• wbinfo -g (elenca gli utenti del dominio)
• wbinfo -u (elenca i gruppi del dominio)

Modifiche apportate al sistema da authconfig-tui

Il comando Authconfig-tui configura una serie di file che sono necessari per l’impostazione dell’ambiente

il file /etc/krb5.conf viene impostato in modo da utilizzare il REALM Kerberos di AD

Figura 5 Impostazioni nel file krb5.conf

È anche modificato il file /etc/samba/smb.conf

Figura 6 Impostazione del file smb.conf

Ed infine viene impostato il file /etc/nsswitch.conf in modo da utilizzare per l’autenticazione, la mappatura degli utenti e dei gruppi, le risorse locali e quelle fornite dal Winbind

Figura 7 Impostazione del file nsswitch.conf

A questo punto il server è collegato in join al dominio AD e lo si vedrà visualizzato anche nel container in Active Directory tramite ADUC

Figura 8

Gli utenti del dominio (TUTTI) possono quindi effettuare il logon al server Linux autenticandosi nel formato [email protected]

A tutti gli effetti l’utente che si connette è un utente di dominio e può autonomamente gestire la propria password come se fosse connesso ad una postazione Windows per effettuare il cambio password si potrà utilizzare il comando Passwd:

Se è necessario definire in modo puntuale chi deve poter accedere ed eventualmente chi deve operare come amministratore, cioè diventare “Sudoer”, si dovranno modificare manualmente alcuni file.

Configurare gli utenti autorizzati ad effettuare Logon al server

Per prima cosa è necessario configurare Winbind in modo che controlli quali utenti o gruppi di dominio possono effettuare il logon, le impostazioni sono contenute nel file

• /etc/security/pam_winbind.conf
  

all’interno sono definite alcune sezioni con le impostazioni commentate da punto e virgola (;) per attivare le varie impostazioni è necessario rimuovere il (;) ad inizio riga e definire le configurazioni nel modo voluto

Le sezioni che interessano la nostra configurazione sono:

• require_membership_of =
  
• warn_pwd_expire =
  

la prima definisce i gruppi di utenti che potranno accedere al server, ogni gruppo deve essere separato da virgola (,). Mentre la seconda sezione è relativa al warning presentato all’utente in occasione dell’avvicinarsi del momento della scadenza della Password, deve essere dichiarato il numero di giorni per cui deve essere notificato l’utente.

Figura 9 Impostazione utenti di accesso

Concessione dei diritti di Sudoer

È anche possibile specificare quali utenti possono essere “Sudoer” ossia in grado di operare come “amministratori” sul server.

Questa configurazione è gestibile tramite il comando “visudo“, che consente di editare in modo corretto il file di impostazione, è necessario dichiarare uno per riga i gruppi di dominio a cui si vuole concedere questo permesso.

Il formato deve essere %DOMINIO\\gruppo ALL=(ALL) ALL

Il carattere (%) ad inizio riga specifica che il permesso non è concesso ad un singolo utente ma ad un gruppo, nel caso si debba concedere il diritto Sudoer ad un singolo utente è sufficiente dichiararlo allo stesso modo ma senza il carattere iniziale %.

N.B. è necessario separare in nome dominio dall’utente con un doppio \ (\\)

Figura 10 impostazione Sudoers in Visudo

Gestione delle Home Directory degli utenti

Con le impostazioni fin qui viste per ogni utente di dominio che esegue il logon al server non verrà creata la home directory.

In alcuni casi può essere una scelta voluta, ad esempio se l’utente non deve utilizzare il sistema in console ma soltanto alcuni servizi, tuttavia nella maggior parte delle situazioni questo comportamento può essere un problema, ad esempio dove è necessario che ogni utente che accede al server abbia il proprio ambiente configurato tramite il bash_profile,, al termine della configurazione eseguire il comando:

• authconfig –enablemkhomedir  -update
  

in questo modo per ogni utente che esegue il logon al server viene creata la Home directory in /home/DOMINIO/nome-utente dove DOMINIO è il nome Netbios dell’Active Directory

Configurazione mediante interfaccia grafica

La procedura vista qui è utilizzata in ambienti che dispongono di interfaccia grafico, esiste un’alternativa a questa modalità che è utilizzabile con Gnome , il comando da eseguire all’interno di X è authconfig-gtk la cui configurazione è riportata nelle immagini seguenti

Figura 11 Authconfig-gtk

Per analogia con la figura 2 è stata riportata la stessa numerazione dei vari campi da impostare

Figura 12 Authconfig-gtk ( gestione delle Home Dir)

In questo caso per abilitare la creazione delle home directory degli utenti il comando visto in precedenza è sostituito con il flag riportato nella figura qui sopra.

Riferimenti:

https://access.redhat.com/sites/default/files/attachments/rhel-ad-integration-deployment-guidelines-v1.5.pdf