Microsoft AD ldap e samba

In rete ci sono tantissime guide su come configurare un "client" linux affinchè effettui il join di un dominio active directory. In questo articolo cercherò quindi, al posto di copiare una guida, di soffermarmi su alcuni concetti che mi son sempre risultati ostici da comprendere.

 

Qualche concetto sparso

Microsoft AD usa ldap come suo compoente ma non è solamente una implementazione di LDAP di Microsoft.
Active Directory è un servizio che offre una Authentication basata su kerberos e Authorization basata su ldap (tramite una serie di policy memorizzate)

L'implementazione di ldap e kerberos di Microsoft ovviamente non è al 100% compatibile con tutte le altre implementazioni

In ogni caso, una volta installato e configurato un server AD, i client potranno connettersi ad esso per esplorare l'albero ldap.
Si può usare qualsiasi strumento (da ldapsearch a JXplorer) anche se ho trovato molto utile Active-Directory-Explorer di Sysinternals.

ADAM, Active Directory Application Mode, ora chiamato AD-LDS (Active Directroy Lightweight Directory Sercices) è Active Directory senza la gestione del dominio.
Lo si installa (in win8 è un componente di windows da attivare), si fa partire il wizard (Active Directory Lightweight Directory Services Setup Wizard) che crea l'istanza (lo vedrai poi nei servizi) e, tramite un client, puoi poi lavorare sull'albero.

Le porte, di default, sono le solite

LDAP port 389
LDAP+SSL port 636

Come username per effettuare il bind potresti dover usare la dicitura "domain\administrator"

 

LDAP SEARCH SUL DB AD

Nota: Il dominio su cui provo si chiama DOMAIN.LOCALE.IT e il server ad ha ip 192.168.100.253 (WINDOWS.DOMAIN.LOCALE.IT). A volte puoi abbreviare il nome dicendo solo DOMAIN. Nel db ldap i nomi sono memorizzati in minuscolo come dc=domain,dc=locale,dc=it. Il realm kerberos è identico al dominio, quindi DOMAIN.LOCALE.IT.
La macchina linux “domain member server” (centos.domain.locale.it) ha ip 192.168.100.254.

Avendo a disposizione un dominio AD si può interrogare coi classici strumenti di ldap da una macchina linx.

Oppure, andando su altri campi tipici dello schema che utilizza windows per un dominio

 

SQUID AUTH SULLO STESSO DB

Allo stesso modo posso utilizzare il db ldap creato da un server ad per effettuare l'autenticazione ldap (bind) di prodotti di terze parti (squid in questo caso)

 

MODIFICA DI UN UTENTE TRAMITE ADMIN

 

EXPORT del DB

Da window server, il comando per effettuare export dell'albero ldap (non esporta proprio tutto,il campo della password per esempio non si può leggere)

 

MODIFICA DEL DB TRAMITE MODIFICA DEL FILE LDIF

Modifichi poi un campo del file ldif e dopo aver fatto la modifica

Il campo changetype governa il comportamento di questo comando
se c'è scritto add aggiunge il campo, modify lo modifica, delete lo cancella (che genialata)

 

CAMPO PASSWORD

Lo schema di ldap di un ad non memorizza la password nel campo userPassword e la stessa non viene esportata col comando precedente

 

QUALCHE ESPERIMENTO, DIDATTICO
Creo sul server ad un utente chiamato testo, con password testo
Aggiungo le estensioni UNIX (uid,gid shell etc) e cambio la password ridigitando ancora testo (così mi riempie il campo  msSFU30Password).

Vado a cercare questo utente

La password memorizzata nel campo msSFU30Password è un hash salted con l'algoritmo crypt.
Questo il comando per crearla a mano

msSFU30Password: 4Z5bqxVFM5cAk
la password io so che è "testo"
quindi

4Z5bqxVFM5cAk

 

KERBEROS
Serve farsi un'idea di come funzioni il protocollo
http://maimon-it.blogspot.it/2007/08/kerberos-authentication-with-ldap.html

E' utile inoltre ricordarsi che kerberos viene utilizzato solo per l'autenticazione nelle architetture ad Active Directory. Se joini un Workgroup o un dominio NT4, oppure se banalmente effettui un login locale utilizzi NTLM (NTLMv2).

 

Linux autentication (gdm-login etc) vs ad

Abbiamo 3 strategie possibili quando vogliamo che gdm/login effettuino il login contro un dominio ad.

1)
Uso il dominio ad come un db ldap e faccio l'autenticazione tramite bind ldap e identificazione come search nel db.
(sssd,nss,pam) Auth e identity via ldap -> AD

2)
Uso il dominio ad come db ldap, utilizzo ldap per fare il search dell'utente e poi utilizzo il server kerberos dell'ad (configurando opportunamente il client su linux??)per richiedere il ticket corrispondente all'utente (principal) sul dominio ad.
(sssd,nss,pam) -> Auth kr5b, id ldap -> AD

3)
Faccio in modo che venga creata una corrispondenza fra i sid memorizzati nel dominio ad (ldap) e uid/gid locali tramite winbind e poi utilizzzo kerberos per effettuare l'autenticazione
(nss,pam) -> (winbind e kr5b) -> AD

 

JOIN DI UN DOMINIO AD
Volendo joinare un dominio ad con una linux-box (che diventerà domain member server) bisognerà configurare samba al minimo con queste direttive.

Workgroup = DOMAIN
realm = your.kerberos.REALM (DOMAIN.LOCALE.IT)
security = ADS
password server = WINDOWS.DOMAIN.LOCALE.IT (l'host del server ad)

e poi joini il dominio

Fatto questo si potranno vedere gli utenti e i gruppi sul server col con i comandi

Appartenere a un dominio, quindi essere domain member server o client, quindi mettere security = ads (o il vetusto domain) significa proprio centralizzare sul dominio active directory la gestione delle utenze (e  di molte altre cose). Per cui il server samba joina il dominio con net ads join, l'ad memorizza un machine trust account e poi samba non avrà bisogno di un suo db di utenti per autenticare (passdb backend) in quanto usa quello remoto, anche se avrà sempre bisogno del corrispettivo utente locale linux per risolvere l'identità del traffico di rete che gli arriva. Questo può essere fatto appoggiandosi ai canonici mezzi linux (/etc/passwd, /etc/group). Per esempio se l'utente DOMINIO\gabriele  prova ad aprire una connessione al server samba verrà effettuata una richiesta che farà si che il sistema cerchi l'utente “gabriele” nel db /etc/passwd

Per fare questo (il riconoscimento dell'identità) puoi anche usare winbind che mappa il SID degli utenti sul dominio con un UID/GID locali.
Questa mappa che viene creata da winbind puoi anche memorizzarla su un db ldap in modo che ciascun “domain member server” che joina il dominio non si inventi una nuova mappa ogni volta.

Nota che qui stiamo parlando di traffico di rete non di login locale, quindi pensa a un utente windows loggato sul dominio che accede via smb al domain member server linux con samba e richiede accesso a uno share.Oppure a un utente windows che cerca di accedere direttamente allo share fornendo come credenziali DOMINIO/UTENTE – password.
In tutti questi casi l'autenticazione è fatta dall'ads (tramite kerberos) e il mapping degli utenti dell'ad con quelli locali linux serve per sapere i privilegi sulle directory associate agli share richiesti.

Su un pc linux configurato come domain member server, avendo creato sull'ad l'utente testo provo a simulare un accesso di rete tramite cifs/smb

Non va perchè manca l'utente locale corrispondente, lo addo senza creare la password in quanto per questa prova non mi serve.

Discorso diverso invece se si vuole utilizzare winbind e gli utenti di un dominio rimappati in locale anche per fare l'autenticazione tramite gdm/login. In questo caso bisognerà riconfigurare pam con pam_winbind e qualcosa del genere

+++ auth      required        pam_winbind.so  use_first_pass
+++ account   required        pam_winbind.so  use_first_pass
+++ password  sufficient      pam_winbind.so
+++ session   required        pam_winbind.so

e nsswitch.conf con qualcosa del genere

passwd: files winbind
shadow: files
group: files winbind

e poi potrò guardare l'elenco degli utenti rimappati con

Secondo me kerberos client (kr5b.conf) in questo caso si può anche non configurare (è da provare perchè tutte le guide dicono di farlo).

Un' altra opportunità (come visto in un altro recente articolo) per far si che gdm/login si autentichino su un ad ldap è quello di configurare sssd usando come id server il db ldap fornito dall' ad e come auth server kerberos dell'ad. Fatto questo si configura nsswitch.conf mettendo al posto di winbind ssss e pam utilizzando al posto di pam_winbind pam_sss.

 

COMANDO PDBEDIT E SMBCLIENT

PDBEDIT guarda nel passdb backend che, in caso di “domain member server” NON c'è (o non meglio, non contiene gli utenti del dominio ad)
Pdbedit va sul backend che gli specifichi dopo la -i per cui
pdbedit -i smbpasswd:/etc/smbpasswd.old  -L utente -v
altrimenti se non specifichi -i usa quello che trova in smb.conf che nel caso di ads non contiene gli utenti che cerchi.
smbclient invece simula una richiesta di rete e quindi risolve i nomi  degli utenti sul ad.

-------------------------------------------------------------------
Questo dice la documentazione ufficiale
Samba, when running on a domain member server, can resolve user identities from a number of sources:

By executing a system getpwnam() or getgrnam() call. On systems that support it, this utilizes the name service switch (NSS) facility to resolve names according to the configuration of the /etc/nsswitch.conf file. NSS can be configured to use LDAP, winbind, NIS, or local files.

Performing, via NSS, a direct LDAP search (where an LDAP passdb backend has been configured). This requires the use of the PADL nss_ldap tool (or equivalent).

Directly by querying winbindd. The winbindd contacts a domain controller to attempt to resolve the identity of the user or group. It receives the Windows networking security identifier (SID) for that appropriate account and then allocates a local UID or GID from the range of available IDs and creates an entry in its winbindd_idmap.tdb and winbindd_cache.tdb files.

If the parameter idmap backend = ldap:ldap://myserver.domain was specified and the LDAP server has been configured with a container in which it may store the IDMAP entries, all domain members may share a common mapping.
-------------------------------------------------------------------

Diverso è il caso in cui samba sia configurato con security=user facendo da pdc o da “server spaiato”: In questo caso samba deve autenticare gli utenti e quindi deve avere un SUO db di password/utenti nelle varie forme di tdbsam/ldapsam, e anche, come sempre, il corrispettivo utente locale linux

Comando per la richiesta di ticket kerberos al server ad

klist invece elenca i ticket richiesti

Print Friendly, PDF & Email