Autenticazione di sistemi Linux verso un dominio Active Directory con Winbind

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 KerberosWinbind (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

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 nome_utente@test.local

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_vinbind.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

SID // Technical Cloud Day 2017

Come di consueto torna il Technical Cloud Day, ma quest’anno con alcune importanti novità: nuova location (Palazzo Lombardia – Piazza Città di Lombardia 1, la stessa dell’ultimo SID) e nuovo nome, ora inquadrato negli eventi della community SID. Il SID // Technical Cloud Day è un evento gratuito di un giorno dedicato alle soluzioni cloud Microsoft, rivolto a tutte le aziende, consulenti e partner che vogliono conoscere cos’è possibile fare con i vari prodotti, come ottimizzare i costi e che vogliono conoscere le best-practice di implementazione. Sarà un evento dedicato agli scenari di implementazione, per […]

The post SID // Technical Cloud Day 2017 appeared first on vInfrastructure Blog.

Veeam Backup & Replication 9.5 Update 1 con supporto per VMware vSphere 6.5

Dopo un periodo in preview, finalmente è disponibile Veeam Backup & Replication 9.5 Update 1 che aggiunge il pieno supporto a VMware vSphere 6.5 support (notare che la versione 9.5 già supportava pienamente Windows Server 2016 e l’ultima versione di Hyper-V). Prima di aggiornare accertarsi di avere la versione 9.5.0.580, 9.5.0.711 o 9.5.0.802. Alla fine dell’aggiornamento la nuova build sarà 9.5.0.823. Il supporto a VMware vSphere 6.5 non è limitato solo alla nuova versione dell’hypervisor, ma a tante delle nuove nuove funzionalità che sono state introdotte: Encrypted VMs support. vSphere 6.5 introduces VMs with encrypted […]

The post Veeam Backup & Replication 9.5 Update 1 con supporto per VMware vSphere 6.5 appeared first on vInfrastructure Blog.

VEEAM: Ottieni licenze Gratis per il mondo fisico e virtuale

Proteggi i carichi di lavoro fisici, AWS e Azure, più Microsoft Office 365, GRATUITAMENTE!

Con questa “Promo Limitata” si può ottenere una licenza gratuita (fino ad un anno) per questi nuovi prodotti:

NUOVO Veeam Agent for Microsoft Windows IN ARRIVO e NUOVO Veeam Agent for Linux per proteggere:

  • Server fisici (in esecuzione con Windows o Linux)
  • Endpoint (Notebook/desktop)
  • VM in esecuzione su Amazon Web Services (AWS) o Microsoft Azure

NUOVO Veeam Backup for Microsoft Office 365 per proteggere:

  • Caselle di posta di Microsoft Office 365

I NUOVI Veeam Agents for Microsoft Windows e Linux e Veeam Backup for Microsoft Office 365 sono facili da installare e funzionano con Veeam Backup & Replication™, Veeam Availability Suite™ e Veeam Backup Essentials™.

Questi nuovi prodotti fanno parte dell’Availability Platform per il cloud ibrido di Veeam, che offre l’Availability for the Always-On Enterprise™ consentendo ad aziende e imprese di tutte le dimensioni di garantire l’Availability dei carichi di lavoro virtuali, fisici e nel cloud.

Registrandosi i clienti avranno:
Veeam Agents for Microsoft Windows IN ARRIVO e NUOVO Veeam Agent for Linux Un abbonamento di sei mesi GRATUITO per workstation e server illimitati. Comprende il supporto di base.

Veeam Backup for Microsoft Office 365: 1 anno di sottoscrizione GRATUITA per utenti illimitati. Comprende il supporto di base.

Il tutto GRATUITAMENTE: non è richiesto alcun acquisto aggiuntivo, non ci sono condizioni

Per sfruttare questa promo basta registrarsi a questa pagina.

Termini e condizioni della promozione:

I clienti Veeam devono possedere o acquistare Veeam Availability Suite, Veeam Backup & Replication o Veeam Backup Essentials entro il 30 giugno 2017 e devono avere la manutenzione attiva. L’offerta comprende il supporto di base. Gli abbonamenti gratuiti si attivano al momento della registrazione. Sarà accettata solo una registrazione per dominio corporate Al termine del periodo della promozione, i clienti avranno la possibilità di acquistare le licenze con una nuova sottoscrizione per continuare a usare il prodotto senza alcun obbligo di acquisto.

I rivenditori Veeam o i Cloud & Service Provider di Veeam che utilizzano Veeam Availability Suite, Veeam Backup & Replication o Veeam Backup Essentials per le VM interne sono idonei per la promozione. La licenza di abbonamento gratuito per Veeam Backup for Microsoft Office 365, Veeam Agent for Microsoft Windows o Linux È solo per uso interno – e non include diritti di utilizzo di terza parte. Non può essere usata per fornire servizi ai clienti. Al termine del periodo della promozione, i service provider avranno la possibilità di acquistare nuove licenze di hosting per continuare a usare il prodotto.

Atlantis Community Experts (ACE)

Atlantis Community Experts (ACE) è il programma di Atlantis Computing con il quale riconosce gli esperti nella community della virtualizzazione, del software designed storage e del mondo iperconvergente. Di fatto è la versione di Atlantis dei programmi “vExpert” o “MVP”. Come avevo scritto in un post precedente, questo programma è relativamente nuovo (introdotto nel 2016) e non ha una form pubblica per la nomina, bensì bisogna seguire le istruzioni presenti in questo post. Nel secondo anno del programma sono state aggiunte 8 persone nuove, incluso me. E’ sicuramente un grande onore e sono molto curioso […]

The post Atlantis Community Experts (ACE) appeared first on vInfrastructure Blog.

Esame 300-180 DCIT Troubleshooting Cisco Data Center Infrastructure 6.0

L’esame 300-180 DCIT 6.0 è associato alla certificazione Cisco CCNP Data Center. Questo esame verifica la capacità di risoluzione problemi di un data center relativamente alla connettività di rete, le infrastrutture, la rete di storage, capacità di calcolo. Domande: 60-70 Durata: 90 + 30 minuti per i non madrelingua inglese Costo: 228 euro Data ritiro: Status: ATTIVO […]

L'articolo Esame 300-180 DCIT Troubleshooting Cisco Data Center Infrastructure 6.0 sembra essere il primo su KISS Keep IT Simple Stupid.

Esame 300-160 DCID Designing Cisco Data Center Unified Computing v6.0

L’esame 300-160 DCID 6.0 è associato alla certificazione Cisco CCNP Data Center. Questo esame testa le capacità di progettazione di infrastrutture dei data center relative ai requisiti di implementazione e le opzioni per la connettività di rete, le infrastrutture, la rete di storage, connettività della capacità di calcolo ed le relative risorse. Domande: 60-70 Durata: 90 + […]

L'articolo Esame 300-160 DCID Designing Cisco Data Center Unified Computing v6.0 sembra essere il primo su KISS Keep IT Simple Stupid.

Esame 300-170 DCVAI Implementing Cisco Data Center Virtualization and Automation 6.0

L’esame 300-170 DCVAI 6.0 è associato alla certificazione Cisco CCNP Data Center. Questo esame verifica la conoscenza di implementare l’infrastrutture di un data center tra cui la virtualizzazione, l’automazione, Cisco Cisco Application Centric Infrastructure (ACI), le risorse di rete ACI e la gestione e il monitoraggio di ACI. Domande: 60-70 Durata: 90 + 30 minuti per i non madrelingua […]

L'articolo Esame 300-170 DCVAI Implementing Cisco Data Center Virtualization and Automation 6.0 sembra essere il primo su KISS Keep IT Simple Stupid.

HPE acquisisce Simplivity

Alla fine, come si rumoreggiava da tempo, HPE acquista SimpliVity, una delle aziende leader nel software-defined e soprattutto nelle soluzioni iperconvergenti . Il tutto per la “modica” cifra di $650 milioni (in contanti)! Sicuramente è un segno di come il mercato iperconvergente sia diventato mainstream (secondo analisi di mercato, questo segmento è stato stimato di circa $2.4 billion nel 2016, e si stima una crescita annuale attorno al 25% fino arrivare a $6 billion nel 2020). Ma anche di come ad HPE servisse una soluzione in questo settore più matura e moderna rispetto alla semplice […]

The post HPE acquisisce Simplivity appeared first on vInfrastructure Blog.

Esame 300-165 DCII Implementing Cisco Data Center Unified Fabric 6.0

L’esame 300-175 DCUCI 6.0 è associato alla certificazione Cisco CCNP Data Center. Questo esame testa di conoscenza di implementare le infrastrutture di un data center compresi i protocolli chiave, protocolli di routing e switching, la manutenzione, la gestione, le operazioni, la sicurezza e lo storage. Domande: 60-70 Durata: 90 + 30 minuti per i non madrelingua inglese […]

L'articolo Esame 300-165 DCII Implementing Cisco Data Center Unified Fabric 6.0 sembra essere il primo su KISS Keep IT Simple Stupid.

Blog italiani (e in italiano) nel mondo IT/ICT