Come configurare una linux box per i domini win2k - ActiveDirectory (v. 1.1)

Come configurare una linux box per i domini win2k - ActiveDirectory

Introduzione

Questa guida è stata scritta allo scopo di facilitare il compito di inserire una macchina Linux in un dominio ADS con PDC win2k o win2k3.
La documentazione allegata al pacchetto Samba su questo argomento non è molto comprensibile ad un non-tecnico e non copre tutti gli aspetti coinvolti.
Anche altri documenti reperibili in rete presentano gli stessi difetti.

Indice

1) Generalità su Active Directory
2) Kerberos
3) Configurare il DNS
4) Installare i pacchetti necessari
5) Configurazione
6) Unire la macchina al dominio
7) Installazioni dual-boot

Il poter integrare una macchina linux nelle reti microsoft con Active directory dovrebbe incentivare le aziende che usano tale tecnologia a portare almeno alcuni servizi di rete sui sistemi Linux. Compiti come server di stampa, firewall, server di posta ecc. possono tranquillamente essere svolti da macchine su cui gira il pinguino, con migliore efficienza e sicurezza rispetto ai sistemi proprietari. Per non parlare dei benefici economici, pur potendo disporre di un sistema costantemente aggiornato.

Ringraziamenti

Si ringrazia il LUG di Grosseto (GROLUG) per la collaborazione e i preziosi consigli.

1) Generalità su Active Directory

Dall' introduzione di windows 2000 microsoft ha cambiato il sistema di gestione dei domini, passando dal sistema basato su smb ( usato da NT) a quello che impiega alcuni protocolli aperti, in particolare DNS, LDAP, NTP e KERBEROS, l' implementazione dei quali tuttavia è stata “personalizzata” ed estesa da microsoft. La gestione dei domini tramite questi protocolli è stata denominata Active Directory. In altre parole l' active directory è un database centralizzato sul PDC che contiene informazioni su utenti, computer, stampanti ecc. L' ADS è suddiviso, ai fini amministrativi, in domini gestiti da un Primary Domain Controller e da altre macchine che duplicano le funzioni del PDC. Ovviamente non è tutto così semplice e ci sono anche altri protocolli: per esempio c' è un insieme di API definite GSS-API che fungono da mezzo intermedio tra gli applicativi e kerberos in modo da svincolarli da chiamate dirette a kerberos. Con tutti i vantaggi conseguenti ad avere un insieme comune di API che “nascondono” i dettagli di implementazione del sistema di autenticazione.
Microsoft non supporta più il vecchio sistema di gestione dei domini, rimane solo la funzione client, cioè i sistemi win2000 e successivi sono ancora in grado di unirsi a domini in stile NT.
Una volta inserita la linuxbox nel dominio ADS sarà possibile accedere alla stessa dagli altri client senza la necessità di immettere nessun dato di autenticazione, essendo sufficiente essersi autenticati all' atto del login.
Inoltre l' account utilizzato per il login alla macchina potrà essere uno di quelli nativi presenti nel sistema ADS. Poiché tale account non esiste nella macchina linux, samba creerà gli uid e gid associati a tali utenti e ne manterrà il collegameto con l' account ADS, cioè con il SID di windows.
Un altro aspetto dell' integrazione nel dominio ADS risiede nel fatto che i programmi richiedenti informazioni di autenticazione presso il PDC eseguiranno l' operazione in modo automatico e trasparente all' utente, a patto che siano stati concepiti e sviluppati per sfruttare Kerberos.
In altre parole si raggiunge quello che viene chiamato Single Sign On.
Naturalmente da Linux sarà possibile accedere alle macchine win o linux e alle stampanti condivise. Il tutto in condizioni di ragionevole sicurezza. Al momento Samba può solo funzionare da client, cioè non è possibile avere un PDC Active Directory con l' accoppiata Linux/Samba. Il problema è sempre lo stesso, comune ad altri progetti: gli standard utilizzati da microsoft non sono aperti, devono essere interpretati analizzandoli e studiandoli mentre funzionano.
Il sistema di controllo dominio presente in samba è quello in stile NT.

Nel seguito si forniranno tutte le informazioni necessarie per unire una linux box ad un dominio ADS utilizzando le distribuzioni Mandriva LE2005 e Debian Sarge.
Per sarge il display manager può essere gdm o kdm associato a KDE o Gnome, in mandriva si è considerato solo kde con il diplay manager di default.
La ipotetica macchina a cui ci si riferisce è xgiuseppe.miodominio.it.
Tutti gli esempi forniti sono stati testati in pratica in una lan di circa 30 calcolatori con PDC win2k3 aggiornato con tutti i service-pack.

Documenti consultati:
samba-HowTo
Using samba
Samba3 by example
Documentazione di PAM
Documentazione per Dhcp e DNS (microsoft win 2000 DNS white paper)
microsoft windows 2000 kerberos white paper

2) Kerberos

Lo strumento fondamentale che assicura la sicurezza dei dati nei domini ADS è il Kerberos, un protocollo concepito a questo scopo presso il MIT. Di seguito sarà fornita una breve descrizione dei suoi principi basilari. Anche se la lettura di questo paragrafo non è indispensabile per ottere l' inserimento della linuxbox nel dominio, se ne trarrà comunque una migliore comprensione dell' argomento, utile anche in caso di problemi. Non si pretende di fornire un completo tutorial, pertanto si consiglia anche di leggere la documentazione fornita col pacchetto e quella microsoft. Questo paragrafo è una breve sintesi dei succitati documenti.
Come dice il nome, il protocollo si basa su tre entità distinte: due “princpal” e il KDC.
Il KDC (Key Distribution Center) è un servizio che esegue l' autenticazione centralizzata dei principal e fornisce le chiavi di criptazione. E' suddiviso in due parti principali: AS (Authentication Service) e TGS (Ticket Granting Service) / CS (Client Server Exchange). Questo servizio va in esecuzione su tutti i computer che svolgono il ruolo di PDC.
I principal in genere sono utenti o servizi ai quali vengono assegnati i ticket. Questi ultimi sono un insieme di informazioni in formato elettronico il cui scopo è permettere l' accesso ai servizi (ad es. accedere allo share di una macchina windows o ad una stampante condivisa ).
Il concetto alla base del funzionamento del protocollo è la condivisione di un secreto tra il KDC e i vari principal, conservato nei computer in cui è in esecuzione il KDC.
In una situazione tipica di un dominio ADS i due principal sono il client, che vuol accedere ad un servizio condiviso, ed il server che condivide una sua risorsa.

Alcune delle informazioni incluse nei ticket sono:
nome del realm
chiave di criptazione
nome del client
Orario dell' autenticazione iniziale da parte del client
Questo elenco è incompleto, ce ne sono diverse altre.

Il KDC inoltre crea e distribuisce le chiavi di criptazione usate dal protocollo per inviare informazioni tra i computer del dominio.
Queste chiavi sono di due tipi: il primo sono le long-term key, che rappresentano il segreto comune al KDC e ad ogni principal, vengono create basandosi sulle password dei principal; Il secondo tipo sono le session key, le quali vengono chiamate in causa quando un client vuol dialogare con un server.
Il primo ticket che viene assegnato dal computer che funge da KDC è il TGT (Ticket Granting Ticket ); la sua funzione è quella di ottenere ulteriori ticket necessari per accedere effettivamente ai servizi. Quindi i ticket sono lo strumento utilizzato dal KDC per verificare l' identità degli utenti.
Un altro concetto utile per l' uso di Kerberos è il realm, cioè l' entità amministrativa gestita dal KDC; in genere corrisponde al nome del dominio in MAIUSCOLO.
A questo punto possiamo dare uno sguardo più approfondito ai principal.
Secondo la documentazione un principal è una identità ben specifica a cui kerberos assegna i ticket.
Agli utenti sarà assegnato un principal del tipo:
nomeutente/instance@REALM.
Nella situazione che ci interessa nomeutente è semplicemente il nome di un account del dominio ADS, quello usato per autenticarsi anche all' avvio di windows.
Instance è un ulteriore componente del principal, che normalmente viene trascurata. Come esempio un utente potrebbe avere il principal giuseppe@MIODOMINIO.IT per l' uso normale e
giuseppe/admin@MIODOMINIO.IT per l' amministrazione del database Kerberos.
In linea di principio si potrebbero anche avere dei principal con più di due componenti.
Le informazioni inerenti tutti i principal presenti nel realm, comprese le password, sono archiviate in un database sul computer KDC, per cui l' autenticazione su ogni computer membro del dominio è centralizzata sul KDC. Una macchina linux che entri a far parte del dominio ADS pertanto deve interagire con tale database centralizzato; come conseguenza l' account da usare per ottenere l' accesso alla macchina è uno di quelli riconosciuti dal dominio, non uno dei locali presenti nei file /etc/passwd o /etc/shadow. Sarà il demone winbindd a creare degli uid gid ed a mapparli all' account ADS che ha richiesto il login.
Riassumento e semplificando molto, il ruolo di kerberos in un domnio ADS può essere suddiviso in due parti fondamentali:
1) autenticazione degli utenti (al login), svolto da AS
2) concedere l' accesso ai member server da parte dei client, funzione del TGS.

il KDC crea ed invia il TGT al client in forma criptata usando una chiave derivata dalla password dell' utente.

Funzione di AS
Si riporta una breve descrizione del funzionamento di AS tratta dalla doc. ms,
Quando un utente da workstation del domino fa logon, le librerie kerberos su quella macchina convertono la password in chiave crittografica tramite una funzione hash. Questa è la long_term key. Il KDC ricava la long_term key dal database degli account. Se l' autenticazione ha successo, il client kerberos chiede un session ticket e una session key per le successive operazioni durante questa sessione di logon.
Il KDC risponde con session ticket particolare, denominato TGT. Quest' ultimo, come qualsiasi ticket, contiene una copia della session key che il KDC usa per comunicare con il client.
Il messagio che trasporta il TGT al client contiene anche una copia della session key che il client può usare per comunicare con il KDC. Il TGT è crittato con la long_term key del KDC. La copia per il client della session key è invece crittata usando come chiave la long_term key dell' utente.
Quando il client riceve la risposta dal KDC alla sua richiesta iniziale, decritta la session key per mezzo della sua long term key che in cache. Da ora in avanti il client non ha più necessità, per gli scambi con il KDC, della propria long_term key (derivata dalla password). Infatti dovrà usare a tale scopo la session_key appena ricevuta e aperta. Quest' ultima, nota anche come logon_session key, ha un carattere temporaneo e rimane valida finchè lo è il TGT o finchè l' untente non fa logoff.

Si può descrivere il processo precedente con più precisione evidenziando i messaggi scambiati.
Il client manda al servizio di autorizzazione (AS) un messaggio KRB_AS_REQ. La prima parte di questo identifica l' utente e contiene anche il nome del servizio per il quale si richiedono le credenziali, cioè in questo caso il TGS.
Nella seconda parte del messaggio ci sono i dati di preautenticazione che dimostrano la conoscenza della password utente da parte del client. Questo dato in genere è un timestamp crittato usando come chiave la long_term key dell' utente.
Il KDC, all' atto dell' arrivo del messaggio KRB_AS_REQ ricerca il nome utente nel suo database, trova la long_term key corrispondente, decritta i dati di preautenticazione ottenendo il timestamp inviato dal client. Se questo passa il test, il KDC può ritenere che il timestamp è stato crittato con la long_term key dell' utente la cui identità è perciò assicurata.
Successivamente il KDC crea le credenziali che il client kerberos dalla workstation potrà inviare al TGS. Per prima cosa crea una session key chiamata logon session key, ne cripta una copia usando come chiave la long_term session key dell' utente. Poi inserisce un' altra copia della logon session key nel TGT che sta per mandare al client (nel TGT ci sono anche altre informazioni).
Il KDC quindi critta il TGT usando la propria long_term key. Infine la logon session key e il TGT sono spediti al client in un Kerberos Authentication Service Reply (KRB_AS_REP).
Quando il client riceve il messaggio, può decrittare la logon session key e la pone nella cache delle credenziali. Quindi estrae il TGT (crittato con la chiave del KDC) e lo conserva nella stessa cache.

Funzione TGS
-----------------------------

Funzione CS
----------------------------

Esistono due implementazioni distinte del protocollo: quella mit e quella Heimdall. In questa guida si ricorrerà a quella mit fornita come pacchetto nelle distribuzioni utilizzate.
Nota finale.
I nomi del protocollo e delle implementazioni richiamano personaggi mitologici che avevano fama di guardiani inviolabili: kerberos (Cerberus secondo l' ortografia latina) è il cane a tre teste della mitologia greca. Heimdall probabilmente deriva dalla mitologia scandinava: era il guardiano degli dei che custodiva la preziosissima collana di Freya, divinità dell' amore e fertilità. La sua vista era acutissima e riusciva ad avvistare i nemici in lontananza .

3) Configurare il DNS

Per il corretto funzionamento del sistema ADS è indispensabile inserire nel database DNS del dominio un record relativo a tutti i calcolatori, quindi anche per la linuxbox. Nei casi in cui è attivo un servizio DHCP (la maggior parte delle volte) l' aggiornamento del database non pùò essere fatto manualmente ma deve essere il client DHCP a informare il server della necessità di aggiornare il DNS.
Nelle macchine Linux questo obiettivo si raggiunge modificando il file di configurazione del client dhcp. In Mandriva si può sfruttare allo scopo uno degli automatismi offerti dalla distribuzione; in Debian non sono sicuro che esista un aiuto di questo tipo. Sempre in Debian si deve anche installare un client dhcp come dhcpcd al posto di quello installato di default.
Se si intende approfondire l' argomento si può scaricare uno script creato da Andrew Tridgell che esegue l' aggiornamento del DNS dalle macchine Linux. Dato che le distribuzioni dovrebbero avere strumenti come quelli appena descritti, secondo me la sua utilità è limitata a scopi didattici oppure nei casi in cui la distro non offre soluzioni.
Lo script è scaricabile da:
http://us5.samba.org/samba/ftp/tsig-gss/

Ecco in dettaglio le operazioni da compiere per ciascuna distribuzione.

MANDRIVA:
a) metodo automatico
Andare in Centro di controllo Mandrake linux (“Configura il tuo computer” dal bottone start), scegliere “Rete e Internet”, quindi “configura una nuova interfaccia di rete”, LAN e immettere i dati richiesti dal sistema, optando ovviamente per una connessione DHCP. Si può tranquillamente trascurare lo zeroconf.
Completata la fase di setup, si può riavviare la rete e negli administrative tools della macchina PDC dovrebbe comparire il record relativo a linux. Oppure si può verificare con dig la riuscita dell' operazione.
b) modifica manuale del file di configurazione
Occorre aggiungere alcune righe al file /etc/sysconfig/network-scripts/ifcfg-eth0 :

DEVICE=eth0
BOOTPROTO=dhcp
NETMASK=255.255.255.0 #verificare se corrisponde ai settaggi della lan
ONBOOT=yes
METRIC=10
MII_NOT_SUPPORTED=no
USERCTL=no
DHCP_CLIENT=dhclient
DHCP_HOSTNAME=xgiuseppe.miodominio.it
NEEDHOSTNAME=yes
PEERDNS=yes
PEERYP=no
PEERNTPD=no

DEBIAN:
Come accennato in precedenza non sono sicuro della presenza di un sistema automatico per aggiornare il DNS. Comunque la modifica manuale del file di configurazione del client dhcp è molto semplice e non pone particolari problemi.
Per prima cosa conviene fermare i servizi di rete:
ifdown eth0.
Successivamente si deve disinstallare il client dhcp di default e al suo posto installare, p. es, dhcpcd.
Conviene verificare prima quale client è installato:
dpkg -l | grep dhc

Se il file sources.lists è già configurato sarànno sufficienti seguenti comandi:
apt-get remove dhclient
apt-get install dhcpcd

A questo punto si può modificare il file /etc/network/network/interfaces
aggiungendo i dati inerenti l' host name nella sezione relativa all' interfaccia eth0

auto eth0
iface eth0 inet dhcp
hostname xgiuseppe.miodominio.it

Riavviando l' interfaccia di rete tutto dovrebbe funzionare a dovere.
Anche in questo caso si possono fare i controlli citati per Mandriva.

4) Installare i pacchetti necessari

E' consigliabile installare i precompilati offerti dalle distribuzioni.

4.1) Pacchetti binari
MANDRIVA
I pacchetti necessari per samba sono:
samba-common-3.0.13-2mdk (i numeri di versione possono essere diversi)
samba-server-3-0.13-2mdk
samba-client-3.0.13-2mdk
samba-winbind-3.0.13-2mdk

per MIT kerberos:
krb5-workstation-1.3.6-6mdk ( è importante che siano > 1.3.x)
libkrb53-1.3.6-6mdk

DEBIAN

Pacchetti samba:
samba-common
samba-client

Kerberos
krb5-user.deb
libkrb53.deb
e relative dipendenze.

4.2) Installazione da sorgente
Questa procedura è più complessa della precedente, richiede più tempo e non offre vantaggi particolari, tranne in quelle sistuazione in cui vi è l' esigenza di compilare samba con opzioni particolari, oppure se si vuole disporre dell' ultima release del programma. Inoltre facendo l' installazione da sorgenti potrebbe essere meno semplice aggiornare samba ad una nuova versione, o ancora nel caso di debian stable se si vuole installare il pacchetto della testing senza provocare gli aggiornamenti a catena che si verificherebbero con i precompilati.
Inoltre facendo l' installazione da sorgenti potrebbe essere meno semplice aggiornare samba ad una nuova versione.
Le procedure di compilazione sono ben descritte nel libro “Using Samba” di .......... edito da O' Reilly e liberamente scaricabile dal sito di samba e su quello dell' editore.
Alcuni parametri da assegnare allo script configure di samba sono:
--with-ads
--with-winbind
--enable-cups (non relativo ad ADS)
--with-krb5= directory per trovare i file kerberos in una dir non-standard

Inoltre sarà necessario installare i pacchetti devel di kerberos.
Oltre a queste operazioni si dovranno creare anche alcuni link simbolici e modificare gli script per avviare automaticamente i servizi all' accensione della machina.

5) Configurazione

5.1) Samba
Quando Samba funziona da server sono disponibili diversi metodi di autenticazione dei client, sfruttando inforamzioni locali o centralizzate.
Il parametro all' interno di smb.conf che determina il comportamento di samba è
security = tipo dove tipo può essere:
a) user
b) share
c) domain
d) ads

Con il metodo a) si associa ad ogni utente che intenda accedere agli share linux una coppia nome_utente / password, cioè gli utenti devono fornire un nome utente e password. Per svolgere l' autenticazione non si può ricorrere direttamente alle informazioni presenti nei file /etc/passwd: infatti nelle reti microsoft le password viaggiano criptate e il loro formato non può essere convertito in quello di linux. Inoltre anche la quantità di informazioni è diversa tra i due sistemi. Quindi si deve introdurre un database aggiuntivo che sarà usato per provare l' identità dei client prima che questi passino alla verifica locale di linux, permessi sui file compresi. Ad ogni account del database samba deve corrispondere un' entità nell' archivio locale (/etc/passwd o altro). Sono disponibili diversi database: smbpasswd, tdbsam , openldapsam.., tutti contenenti almeno nomi utenti e password.
Il sistema basato su smbpasswd viene ormai sconsigliato con le nuove versioni di samba, quindi è preferibile utilizzare gli archivi più moderni.
Il metodo b) associa ad ogni share una password, la stessa per tutti i client
Il metodo c) è un sistema centralizzato, compatibile con il formato dei domini NT, quindi si può utilizzare nelle situazioni dove il PDC è winnt o Samba.
Il metodo d) è quello che ci interessa: permette di attivare il funzionamento come membro del dominio ADS, member server.
Un file smb.conf minimale che permette il funzionamento nel dominio Active Directory deve contenere almeno le seguenti righe:

workgroup = miodominio
netbios name = xgiuseppe # facoltativo, altrimenti viene estratto dal record DNS
server string = samba server %v
encrypt passwords = yes
security = ADS
realm = MIODOMINIO.IT
client use spnego = yes # serve per win2k3
wins support = no
wins server = 192.168.2.1
name resolve order = wins bcast
; guest ok= yes
password server = *
;client schannel =yes
winbind separator = +
idmap uid = 10000-20000
idmap gid = 10000-20000
winbind enum users = yes
winbind enum groups = yes
template shell = /bin/bash
template homedir = /home/%u
winbind use default domain = yes
#winbind use default domain = no , va bene anche = no,vedi più avanti
ldap ssl =no
; guest account = nobody
printing = cups
print cap = cups
message command = /usr/bin/linpopup "%f" "%m" %s; rm %s # per inviare messaggi
# a winpopup
# Livello di log a piacimento
# log level=3

[share]
path = /home/giuseppe/share
comment = shareLinux
browseable = yes
read only =no
hide dot files = yes

Inoltre alla directory condivisa dovranno essere assegnati i necessari permessi Linux.
Questo è un file abbastanza semplice, si possono aggiungere sezioni per le stampanti, per la sezione [HOME] oppure per mappare i gruppi linux a quelli del dominio ed altre ancora.

Le righe che iniziano con idmap servono a stabilire l' intervallo dei gid / uid assegnati da samba agli account del dominio. E' importante che non interferiscano con quelli associati agli account linux locali.
Il collegamento tra uid / gid e sid di windows viene mantenuto nel file winbind_idmap.tdb; risulta quindi superfluo avvertire di non rovinare questo file E' bene quindi averne la massima cura.
Se si esegue un' installazione di samba sopra una precedente è consiglaibile cancellare i files di cache mantenuti dal programma.
La linea winbind separator assegna il simbolo che separa il nome utente dalla parte dominio del nome account completo, come in MIODOMINIO+giuseppe; questo vale se si è posto winbind use default domain = no

La documentazione di samba raccomanda di inserire nel file /etc/hosts un campo con i dati del controllore di dominio:
pdc.miodominio.it 192.168.xxx.xxx #( inserire l' indirizzo giusto)
La sua funzione è permettere la risoluzione inversa dei nomi per il pdc. Non dovrebbe essere indispensabile, si può applicare in caso di problemi.

5.2) Kerberos
Un file /etc/krb5.conf minimale è il seguente:

[logging]
default = FILE:/var/log/kerberos/krb5libs.log
kdc = FILE:/var/log/kerberos/krb5kdc.log
admin_server = FILE:/var/log/kerberos/kadmind.log

[libdefaults]
ticket_lifetime = 24000
default_realm = MIODOMINIO.IT
default_tgs_enctypes = des3-hmac-sha1 des-cbc-crc
default_tkt_enctypes = des3-hmac-sha1 des-cbc-crc
# dns_lookup_realm = true
#dns_lookup_kdc = true
kdc_req_checksum_type = 2
checksum_type = 2
ccache_type = 1
forwardable = true
proxiable = true

[realms]
MIODOMINIO.IT = {
kdc = kdc.miodominio.it:88 #sostituire kdc.miodominio.it con il vero nome del kdc
#admin_server = kerberos.mandrakesoft.com:749
default_domain = miodominio.it
}

[domain_realm]
.miodominio.it = MIODOMINIO.IT

#[kdc]
#profile = /etc/kerberos/krb5kdc/kdc.conf

[pam]
debug = false
ticket_lifetime = 36000
renew_lifetime = 36000
forwardable = true
krb4_convert = false

[login]
krb4_convert = false
krb4_get_tickets = false

5.3) Il name service switch
Devono essere modificate le linee del file /etc/nsswitch.conf inerenti password e group aggiungendo il riferimento a winbind

passwd: files winbind
shadow: files
group: files winbind

5.4) Orologio
La massima differenza ammessa tra gli orari segnati dal PDC e da ciacun menbro del dominio vale 300 sec. Questo punto è indispensabile per il buon esito dell' autenticazione, per convincersene basta ricordare il meccanismo di kerberos descritto nel paragrafo 4.
La sincronizzazione degli orologi può essere ottenuta agendo manualmente su ciacun calcolatore oppure si può installare ntp per sincronizzarsi automaticamente sull' orologio del PDC.
Una volta unita la macchina al dominio la sincronizzazione si può ottenere semplicemente digitando da console: net time set.

5.5) PAM
Modificare in modo errato i file di configurazione di PAM può provocare gravi disservizi, come non riuscire più a loggarsi sulla linux box.
Prima di procedere è pertanto opportuno accertarsi di essere in grado di riavviare il calcolatore con floppy o CD di emergenza, oppure con CD live.
Naturalmente è anche buona norma fare il backup dei files contenuti in /etc/pam.d.
In questa directory sono presenti diversi files, ciascuno associato ad uno specifico servizio di autenticazione. In qualche caso potrebbe esserci un unico file suddiviso in sezioni, ciascuna associata ai vari servizi.
Se lo scopo di inserire la macchina linux nel domnio è quello di permettere login locale o remoto, da console o da X, sarà necessario modicare i seguenti files:

per Mandriva: login, kde3 e system_auth
(Invece di modificare quest' ultimo, richiamato tramite pam_stack da molti servizi, è preferibile copiarlo con altro nome e fare riferimento in login e kde3 a tale file.)

per Debian: login, kdm e common-auth-winbind
(il file originale common-auth-winbind viene incluso in altri che sono associati a specifici servizi; anche in questo caso conviene copiare l' originale e fare riferimento a questo da login e kdm.

I file per Mandriva hanno il seguente contenuto

LOGIN:

#%PAM-1.
auth required /lib/security/pam_securetty.so
auth required /lib/security/pam_stack.so service=system-auth-winbind
auth required /lib/security/pam_nologin.so
account sufficient /lib/security/pam_winbind.so
account required /lib/security/pam_stack.so service=system-auth-winbind
password required /lib/security/pam_stack.so service=system-auth-winbind
session required /lib/security/pam_stack.so service=system-auth-winbind
session optional /lib/security/pam_console.so
session sufficient /lib/security/pam_mkhomedir.so skel=/etc/skel umask=0022

KDE3:

#%PAM-1.0
auth required pam_stack.so service=system-auth-winbind
auth required pam_nologin.so
account sufficient pam_winbind.so
account required pam_stack.so service=system-auth-winbind
password required pam_stack.so service=system-auth-winbind
session required pam_stack.so service=system-auth-winbind
session optional pam_console.so

SYSTEM-AUTH_WINBIND:

#%PAM-1.0
auth required pam_env.so
auth sufficient pam_winbind.so
auth sufficient pam_unix.so likeauth nullok use_first_pass
auth required pam_deny.so

account sufficient pam_winbind.so
account required pam_unix.so

password required pam_cracklib.so retry=3
password sufficient pam_unix.so nullok use_authtok md5 shadow
password required pam_deny.so

session required pam_mkhomedir.so skel=/etc/skel/ umask=0022
session required pam_limits.so
session required pam_unix.so

Invece per Debian i file sono:

LOGIN
auth requisite pam_securetty.so
auth requisite pam_nologin.so
auth required pam_env.so
auth sufficient pam_winbind.so
@include common-auth-winbind
# Standard Un*x account and session
account sufficient pam_winbind.so
@include common-account
@include common-session
session required pam_limits.so
session required pam_mkhomedir.so skel=/etc/skel umask=0022
#session optional pam_lastlog.so
#session optional pam_motd.so
#session optional pam_mail.so standard noenv
@include common-password

KDM
#
# /etc/pam.d/kdm - specify the PAM behaviour of kdm
#

# The standard Unix authentication modules, used with
# NIS (man nsswitch) as well as normal /etc/passwd and
# /etc/shadow entries.
auth sufficient pam_winbind.so
@include common-auth-winbind
account sufficient pam_winbind.so
@include common-account
@include common-password
@include common-session
auth required pam_nologin.so
auth required pam_env.so
session required pam_limits.so
session required pam_mkhomedir.so skel=/etc/skel umask=0022

Nel caso si sia installata Debian con un metodo standard (non expert) invece di kdm saranno presenti gdm con kde e gnome, pertanto il file da modificare è gdm
GDM (esclude KDM)
#%PAM-1.0
auth requisite pam_nologin.so
auth required pam_env.so
auth sufficient pam_winbind.so
@include common-auth-winbind
account sufficient pam_winbind.so
@include common-account
session required pam_limits.so
@include common-session
@include common-password
session required pam_mkhomedir.so skel=/etc/skel umask=0022

COMMON-AUTH-WINBIND
#
# /etc/pam.d/common-auth - authentication settings common to all services
#
# This file is included from other service-specific PAM config files,
# and should contain a list of the authentication modules that define
# the central authentication scheme for use on the system
# (e.g., /etc/shadow, LDAP, Kerberos, etc.). The default is to use the
# traditional Unix authentication mechanisms.
#
auth required pam_unix.so nullok_secure use_first_pass

Nella directory /etc/pam.d esiste anche un file denominato samba, probabilmente associato all' autenticazione dei servizi omonimi. Non ho provato ad adattarlo per il funzionamento in ADS.

Il concetto fondamentale da seguire per modificare i file pam è inserire prima delle righe che gestiscono l' autenticazione tradizionale Unix ( auth required pam_unix.so .....) una righa che esegue l' autenticazione centralizzata tramite winbindd, con parametro sufficient. In questa maniera si permette ad un utente locale che fallisce il test di winbindd di giungere alla riga successiva e proseguire con la normale autenticazione Unix. Nella stessa riga è stato aggiunto il parametro use_first_pass per evitare di dover digitare la password una seconda volta.
Le righe session che fanno riferimento a pam_mkhomedir.so svolgono la funzione di creare automaticamente la home dir degli utenti al primo login. In tale directory andranno poi copiati alcuni file di configurazione che normalmente utilizziamo in linux: quelli di bash e X tanto per richiamare i più importanti.

6) Unire la macchina al dominio

Per prima cosa si devono fermare i demoni samba:
killall smbd
killall nmbd
killall winbindd

Forse non è indispensasbile stoppare i primi due, ma in questo modo le cose funzionano a dovere.
Successivamente basta eseguire il comando
net ads join -U utenteadm
in cui utenteadm è un nome di account ads con privilegi di amministratore.
Dopo aver fornito la password richiesta, se tutto è andato liscio, la macchina è unita al dominio.
Quindi si può riavviare il sistema e provare ad autenticarsi con l' account di dominio; il nome utente da inserire è MIODOMINIO+nomeutente se in smb.conf risulta: winbind use default domain = no, in caso contrario è sufficiente digitare nomeutente.
Una volta avviato il sistema si possono dare i seguenti comandi per verificarne il corretto funzionamento:

net ads testjoin verifica l' unione al dominio
net ads status -U utenteads
net ads info
net ads user
net ads group
(alcuni di questi comandi richiedono la password dell' account di dominio. Se ci si autentica con kinit, vedi par. successivo, non sarà necessario digitare le password)
wbinfo -u restituisce l' elenco degli utenti del dominio
wbinfo -g restituisce l' elenco dei gruppi del dominio
getent passwd per ottenere l' elenco utenti con alcune informazioni aggiuntive ( uid,gid, shell..)
Un'ultima configurazione consiste nell' assegnare gli utenti di dominio ad alcuni gruppi predefiniti di sistema: audio (altrimenti il sistema sonoro non funziona), floppy (per formattare dischetti) e in debian plugdev (per ottenere il rilevamento e montaggio automatico dei dispositivi rimovibili )

Da root:
# adduser utenteADS audio

La macchina in rete

Per accedere alle macchine in rete dalla console testuale di linux conviene innanzitutto lanciare il comando kinit

[MIOMINIO+giuseppe]@xgiuseppe ~]$ kinit nomeutente

dove nomeutente è un account Active directory. Il comando esegue l' autenticazione presso il servizio AS di kerberos e fornisce il TGT all' utente.
Oppure semplicemente kinit se il login alla console è stato fatto da un utente di dominio.
Si può controllare l' elenco dei ticket attivi con klist. Il comando
[MIOMINIO+giuseppe]@xgiuseppe ~]$ smbclient -k //host/share
permette di accedere ai vari server del dominio senza la necessità di ulteriori autenticazioni. I ticket ottenuti dal KDC possono essere distrutti tramite kdestroy.
Notare quindi la differenza tra il login di Linux ad una console e kinit: quest' ultimo esegue la completa autenticazione presso AS e restituisce un TGT.

Il comando kpasswd permette di cambiare la password degli account ads, quindi la nuova password avrà efficacia anche per fare login da windows. Allo stesso scopo è disponibile net ads passwd.
Per navigare nel dominio con un browser grafico ( Konqueror ) è sufficiente scivere nella barra indirizzi smb:/. Apparirà un icona che rappresenta il dominio, clikkandoci sopra si otterrà la lista dei calcolatori e quindi degli share. Per evitare di doversi autenticare ogni volta conviene configurare KDE in moda che possa inviare la coppia nomeutente / password.
In genere bisogna andare nella configurazione di KDE, quindi rete / navigazione rete locale.
Esistono anche alcuni programmi sviluppati appositamente per navigare nelle reti samba, non tutti mi hanno funzionato bene con l' Active Directory. Forse è richiesta una configurazione più dettagliata di quella che ho fatto.

7) Installazioni dual-boot

Nei casi in cui linux è installato su una macchina dove era preesistente windows (XP o superiore) può presentarsi il problema di come configurare il sistema.
Probabilmente è consglaibile assegnare un nome host di Linux differente da quello windows. Altrimenti il computer risulterà già unito al dominio e con il DNS già configurato. Non ho avuto modo di verificare o approfondire questi aspetti del problema.