Questo documento descrive, in salsa cookbook, come realizzare il join di una macchina Red Hat Linux Server versione 6 ad un dominio Active Directory realizzato con Windows server 2003 o 2008.

Segue una seconda parte che descrive come poter montare i dischi esposti da Windows ed usarli in scrittura e lettura.

A seconda dei requisiti una volta fatto il join sarà anche possibile usare le utenze del dominio Windows per fare le autenticazioni sulla macchina Linux.

Al termine del documento è presente una piccola sezione di troubleshooting, sempre in forma cookbook.

Premessa

Prima di passare alla parte operativa è bene raccogliere i dati del dominio dal sistemista che lo gestisce. In questa guida si ipotizza la seguente configurazione:

• Hostname del server Windows: win1.dom.it
• IP del server Windows: 10.0.0.1
• DNS 1: 10.0.0.3
• DNS 2: 10.0.0.4
• Server NTP: 10.0.0.5
• Nome Dominio: dom.it
• Nome Gruppo Windows: domit
• Hostname del server Linux: redhat100.dom.it
• IP del server Linux: 10.0.0.100
• Disco condiviso da Windows: testsharing

Tre note importanti da tenere presente:

1. Il server NTP deve essere quello usato dal server Windows.
2. Le indicazioni qui riportate potrebbero non dare successo. Esistono alcune varianti in Linux e in Windows server, ma, sopratutto, dipende dalle configurazioni del dominio Windows. Windows facilita molto l’amministratore nel configurare il server, ma non rende subito visibili alcuni parametri di configurazione. Potrebbe essere necessaria una analisi più dettagliata della configurazione del server da parte dall’amministratore.
3. Il nome del server Linux deve essere già registrato nel DNS del dominio Windows.

Join di una macchia RHEL a Dominio Windows 2K3/2K8

Per poter fare il join a un dominio Windows dobbiamo intervenire sul nostro server Linux prima configurando adeguatamente il DNS, poi la sincronizzazione dell’orario in sintonia con la configurazione del PDC del dominio Windows, configureremo poi Kerberos ed in fine faremo il join.

Verifica firewall

Prima di procedere oltre è bene controllare che non sia attivo un firewall in Linux. Infatti potrebbe verificarsi che le corrette configurazioni diano risultati fallimentari perché le comunicazioni sono interrotte dal firewall. Finita tutta la configurazione e certi del buon funzionamento di tutto si può ripristinare il firewall facendo attenzione a lasciare aperte le varie porte necessarie al funzionamento di tutto.

Per disattivare il firewall:

# service iptables stop
# chkconfig iptables off

Configurazione del DNS

1. Collegarsi al server Red Hat come root ed editare il file /etc/resolv.conf
2. inserire le seguenti righe:

   search dom.it
   nameserver 10.0.0.3
   nameserver 10.0.0.4

Configurazione client NTP

1. Verificare l’installazione del demone NTP ed installarlo se non presente:

   yum install ntp ntpdate

2. Editare /etc/ntp.conf e aggiungere il server NTP del dominio (nota: se ci sono altri server inseriti, quello usato dal dominio deve essere il primo):

   server 10.0.0.5

3. Riavviamo il demone:

   # service ntpd restart

4. impostiamo il demone come servizio di defualt all’avvio della macchina:

   # chkconfig ntpd on

NOTA: se la differenza di orario e data del server Linux rispetto a quella fornita dal server NTP impostata dovesse essere molto grande (ore o giorni) l’orario e la data corretta del server Linux devono essere impostati manualmente.

Configurazione di Kerberos

1. Verificare l’installazione dei pacchetti kerberos client ed installarli se non presenti:

   # yum install krb5-workstation

2. editare il file /etc/krb5.conf

   [logging]
   default = FILE:/var/log/krb5libs.log
   kdc = FILE:/var/log/krb5kdc.log
   admin_server = FILE:/var/log/kadmind.log[libdefaults]
   default_realm = DOM.IT
   dns_lookup_realm = false
   dns_lookup_kdc = false
   ticket_lifetime = 24h
   renew_lifetime = 7d
   forwardable = true
   
   [realms]
   
   DOM.IT = {
   kdc = win1.dom.it
   admin_server = 10.0.0.1
   }
   
   [domain_realm]
   .dom.it = DOM.IT
   dom.it = DOM.IT

3. testiamo la configurazione chiedendo la creazione di un ticket e successivamente chiediamo di vedere l’elenco dei ticket ricevuti. Per far questo dobbiamo usare un utente qualsiasi presente e attivo nel dominio:

   # kinit stefano.bortolato@DOM.IT
   # klist
   

Configurazione di samba

1. Editare il file /etc/samba/smb.conf. Le righe riportate sono quelle fondamentali per il join:

   workgroup = DOMIT
   password server = 10.0.0.1
   realm = DOM.IT
   security = ads
   idmap uid = 16777216-33554431
   idmap gid = 16777216-33554431
   template shell = /sbin/nologin
   winbind use default domain = true
   winbind offline logon = false
   winbind enum users = Yes
   winbind enum groups = Yes
   client use spnego = Yes
   encrypt passwords = yes
   restrict anonymous = 2
   winbind refresh tickets = yes
   preferred master = no
   server string = Server RedHat
   passdb backend = tdbsam

2. Avviare il demone winbind:

   # service winbind start

3. Rendere il demone un servizio di default all’avvio:

   # chkconfig winbind on

NOTA: ai fini del join e dell’SSO (descritta qui di seguito) è necessario il solo demone winbind. Winbind è una parte di SAMBA e si occupa esclusivamente del dialogo con i server Windows. Per far erogare servizi Windows anche alla nostra macchina Linux dobbiamo lanciare i demoni smbd e nmbd e completare adeguatamente la configurazione di SAMBA.

Join del server Linux

1. Prima di dare l’istruzione accertarsi di avere username e password di un amministratore del server Windows abilitato ad accettare i join. Inoltre assicurasi di essere root sul server Linux. Per evidenziare eventuali errori si può aggiungere al comando qui di seguito l’opzione “–verbose”:

   # net ads join -S win1.dom.it -U Administrator

2. verifichiamo il buon risultato del join tramite il test base e la richiesta della lista degli utenti e dei gruppi del dominio:

   # net ads testjoin
   # wbinfo -u
   # wbinfo -g

Arrivati a questo punto la nostra macchina è a tutti gli effetti un membro del dominio Windows. A seconda di quello che desideriamo possiamo sfruttare il server Windows per diversi vantaggi. I capitoli 3 e 4 illustrano due possibilità:

• SSO, ovvero l’autenticazione usando la lista utenti presente sul server Windows
• usare gli sharing esposti dal server Windows.

Troubleshooting

1. Per verificare se il firewall è attivo, per spegnerlo e impostarlo come servizio standard o meno collegarsi come utente root. Per vedere se il firewall è attivo e vedere le regole attive:

   # service iptables status

   Per disattivare al volo il firewall

   # service iptables stop

   Per attivare al volo il firewall

   # service iptables start

   Per rendere permanente la disattivazione del firewall

   # chkconfig iptables off
   # service iptables stop

   Per rendere permanente l’attivazione del firewall

   # chkconfig iptables on
   # service iptables start

2. Per verificare se il DNS funziona regolarmente si può usare dig. Questo programma stampa sul monitor la risposta del DNS permettendo di capire la correttezza della configurazione e l’eventuale errore. Ad esempio:

   # dig www.libero.it

3. L’ora della macchina Linux è sbagliata e ntp non la riallinea. Il demone ntp riallinea l’ora della macchina solo se la differenza è contenuta. Qualora ci siano ore di differenza, o giorni, o mesi o anni bisogna reimpostare manualmente data e ora. Successivamente ntp manterrà sincronizzata l’ora. Ipotizzando che vogliamo impostare data e ora al 1 agosto 2012, ore 9:00 procedere, come root, con il seguente comando. Il primo imposta date e ora del sistema, il comando seguente imposta data e ora del BIOS:

   # service ntpd stop
   # date -u -s "20120801 09:00:00"
   # hwclock -u --set --date="1/8/12 9:00:00"
   # service ntpd start

4. La configurazione di SAMBA ed il suo corretto funzionamento può risultare complicato per l’estrema flessibilità che ha. Per avere documentazione ed eventuale supporto rimando ai siti di samba (http://www.samba.org) e di RedHat (http://www.redhat.com). Con RedHat è opportuno avere una sottoscrizione attiva per poter accedere anche alla parte FAQ, knoledgebase e supporto diretto. Un programma estremamente utile per verificare subito la correttezza formale della configurazione, ad avere riscontro dello stato di configurazione, ed, eventualmente, il dump della configurazione senza tutte le righe di commento è “testparm”. Come utente root dare il comando:

   # testparm

Autenticazione centralizzata SSO

In questo capitolo vediamo come configurare il Server Red Hat per usare i nomi utente e le password presenti nel server Windows per autenticarsi anche sul Server Linux. A seconda di quello che si vuole ottenere si dovranno inserire specifiche righe di configurazione in SAMBA, Apache, ecc…

L’utente root è sempre locale. Inoltre dobbiamo creare anche un secondo utente locale per i login remoti e/o assumere l’identità di root se non lo configuriamo come nologin.

Personalizzazioni dei file di configurazione

1. Editare /etc/samba/smb.conf e modificare la riga “template shell = /sbin/nologin” in “template shell = /bin/bash”
2. editare il file /etc/nsswitch.conf

   passwd: files winbind
   shadow: files winbind
   group: files winbind
   ...
   ...

3. editare il file /etc/pam.d/system-auth-ac:

   auth required pam_env.so
   auth sufficient pam_unix.so nullok try_first_pass
   auth requisite pam_succeed_if.so uid <= 500 quiet
   auth sufficient pam_winbind.so use_first_pass
   auth required pam_deny.so
   account required pam_unix.so broken_shadow
   account sufficient pam_localuser.so
   account sufficient pam_succeed_if.so uid > 500 quiet
   account [default=bad success=ok user_unknown=ignore] pam_winbind.so
   account required pam_permit.so
   password requisite pam_cracklib.so try_first_pass retry=3 type=
   password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok
   password sufficient pam_winbind.so use_authtok
   password required pam_deny.so
   session optional pam_keyinit.so revoke
   session required pam_limits.so
   session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
   session required pam_unix.so

4. editare il file/etc/pam.d/passwd:

   auth include system-auth
   account include system-auth
   password substack system-auth
   -password optional pam_gnome_keyring.so

5. editare il file /etc/pam.d/password-auth-ac:

   auth required pam_env.so
   auth sufficient pam_unix.so nullok try_first_pass
   auth requisite pam_succeed_if.so uid >= 500 quiet
   auth sufficient pam_winbind.so use_first_pass
   auth required pam_deny.so
   account required pam_unix.so broken_shadow
   account sufficient pam_localuser.so
   account sufficient pam_succeed_if.so uid < 500 quiet
   account [default=bad success=ok user_unknown=ignore] pam_winbind.so
   account required pam_permit.so
   password requisite pam_cracklib.so try_first_pass retry=3 type=
   password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok
   password sufficient pam_winbind.so use_authtok
   password required pam_deny.so
   session optional pam_keyinit.so revoke
   session required pam_limits.so
   session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
   session required pam_unix.so

A questo punto è possibile loggarsi sulla nostra macchina Linux con un utente presente sul dominio, ma non presente sul nostro server.

NOTA: tutte le configurazioni sopra riportate possono essere fatte automaticamente tramite l’utility testuale:

# authconfig-tui

o tramite l’utility grafica:

# system-config-authentication

Personalmente sconsiglio l’uso di questi tool per l’operazione di configurazione dell'SSO ed il join se non si è sicuri dei parametri del dominio o se, dopo il tentativo di join, i test danno risultato negativo. Questi due programmi mascherano i messaggi di output dell’operazione di join. Se c’è qualcosa di sbagliato ed il join non può essere completato con successo i messaggi di output notificano subito questa situazione e danno precise indicazione su dove si trovano gli errori.

Troubleshooting

Ci sono molti potenziali problemi in cui si potrebbe incappare. La questione è molto variegata soprattutto in riferimento alla nostra specifica configurazione. Qui di seguito do qualche dritta semplic per verificare il join (requisito NECESSARIO per far funzionare l’autenticazione SSO), gli utenti e gruppi del dominio Windows e sull’errore della home al login con un utente del dominio.

1. Abbiamo fatto il join, ma non siamo sicuri che sia riuscito. Per testare la validità del join da utente root dare l’istruzione:
   # net ads jointest
   Se otteniamo una risposta d’errore e ripetiamo il join potrebbe essere necessario che l’amministratore del dominio Windows rimuova la nostra macchina Linux dal dominio.
2. Per verificare l’appartenenza al dominio e per usare gli utenti ed i gruppi del dominio Windows possiamo usare getent. Se non specifichiamo un nome utente o un nome gruppo ci restituisce la lista completa degli utenti e dei gruppi disponibili. Rimando alla documentazione di SAMBA, per l’istruzione “net”, per manipolazioni avanzate come il caching degli utenti/gruppi in locale.

   # getent passwd
   # getent group
   # getent passwd utente.dominio
   # getent group gruppo.dominio

3. Completato con successo il join e la configurazione dell’SSO potremmo trovarci con un errore come il seguente dopo aver fatto il login con un utente del dominio Windows:
   Could not chdir to home directory /home/DOMIT/stefano.bortolato: No such file or directory
   Questo significa che non esiste la directory dell’utente. Bisogna procedere per configurare SAMBA e Linux che crei automaticamente la home degli utenti e, manualmente, creare la directory del gruppo Windows. Nel caso di questa guida si tratta di creare /home/DOMIT. Per il come fare rimando alla documentazione di SAMBA (www.samba.org) e di RedHat (www.redhat.com).

Usare condivisioni esposte da Windows server 2K3/2K8

Una volta completato il join al dominio è possibile usare i dischi condivisi dal server Windows.

Montaggio manuale temporaneo

Per montare manualmente un disco condiviso dal server è sufficiente:

1. loggarsi al server Linux come utente root o diventare l’utente root tramite il comando "su -"
2. dare il comando:

   mount -t cifs //win1.dom.it/testsharing /mnt -o rw,nosuid,nodev,user=nome.utente,domain=DOM.IT

Con questa istruzione verrà chiesta la password dell’utente.

Montaggio permanente

Per rendere persistenti le impostazioni del mount e rendere automatico l’operazione dobbiamo:

1. loggarsi a linux come utente root o diventare root tramite il comando "su -"
2. creare il file /etc/samba/credentials (nota: sostituire "nome.utente" e "password" con nomi e password reali!):

   user=nome.utente
   pass=password
   domain=DOM.IT

3. cambiare i permessi al file:

   chmod 600 /etc/samba/credentials

4. editare il file /etc/fstab e aggiungere la seguente riga:

   //win1.dom.it/testsharing /mnt cifs rw,nosuid,nodev,credentials=/etc/samba/credentials 0 0

A questo punto per montare subito il disco dare l’istruzione:

mount /mnt

Successivamente ad ogni reboot ci ritroveremo il disco automaticamente montato.

Troubleshooting

1. È possibile che a un tentativo di montaggio di un disco ci venga restituito il seguente errore:

   mount error(13): Permission denied

   Il significato è chiaro, ma le cause possono essere molteplici. Per individuare l’errore è utile adottare le seguenti pratiche:

   1. Verificare, lato server Windows, i log. Potrebbe essere scritta la causa, ma in alcune situazioni non viene tracciato nulla;
   2. Se abbiamo dato il comando manualmente verificare la correttezza sintattica di mount, in particolare: aver messo una corretta username, password e dominio, aver usato le virgole (,) come separatori dopo il "- o" e non gli spazi ( )
   3. Aver scritto correttamente il nome della condivisione Windows
   4. Che la condivisione Windows sia effettivamente accessibile per l’utente ed il computer da cui facciamo la richiesta
   5. Che il join precedentemente fatto del computer da cui facciamo la richiesta di montaggio sia effettivamente valido (usare, come root, il comando "net ads jointest").

Conclusioni

Questa guida in miniatura spiega cosa fare riportando i comandi da dare al computer senza alcuna spiegazione tecnica.

L'argomento affrontato è una configurazione avanzata, articolata e complessa. Offre delle grandi opportunità ed è estremamente flessibile.

Tutto ciò significa:

• è consigliabile avere esperienza
• è opportuno studiare le varie tecnologie coinvolte
• è possibile che l'applicazione fedele di queste indicazioni diano risultati fallimentari.

La complessità e varietà delle situazioni reali non permette una esposizione esaustiva in poche pagine e, soprattutto, realizzate con questo stile cookbook.

Avventurarsi seguendo questa guida, comunque, non è da sconsiderati, basta agire con prudenza. In caso di successo è buono, a fine lavoro, approfondire la conoscenza su questa tecnologia. In caso di fallimento si sa che serve un supplemento di indagine sul server/rete Windows e/o un approfondimento tecnico sulle tecnologie coinvolte.

Risorse utili

Segnalo dei link che possono essere utili per trovare risposte immediate a problemi topici e una guida che offre un’ottima descrizione a 360° sulla questione di integrazione di sistemi basati su SAMBA con il mondo Windows Active Directory:

• www.samba.org, Samba - opening windows to a wider world
• www.redhat.com, Red Hat | The World's Open Source Leader
• docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/ch-Configuring_Authentication.html, Chapter 10. Configuring Authentication
• www.linuxtopia.org/online_books/rhel6/rhel_6_deployment/rhel_6_deployment_ch-Authentication_Configuration.html, Chapter 8. Authentication Configuration
• www.gpaterno.com/pubblicazioni/single-sign-on-con-kerberos-e-ldap, Single Sign-On con Kerberos e LDAP