Uno degli usi più interessanti di LDAP è quello che permette di sostituire l'elenco degli utenti e gruppi di un computer, al posto dei classici file /etc/passwd e /etc/groups; essendo il protocollo trasparente alla rete questo può essere immediatamente esteso ad un gruppo di macchine diverse, diventando una alternativa praticabile al posto di NIS, quando si debba gestire un sistema di autenticazione centralizzata di uno stesso gruppo di utenti su macchine diverse.
Rispetto a NIS infatti LDAP presenta numerosi vantaggi: anzitutto l'informazione mantenuta nel database può essere utilizzata anche per altri scopi (come per la gestione degli account di posta o di altre informazioni generali), inoltre LDAP permette un controllo di accesso alle varie informazioni memorizzate nell'elenco molto più dettagliato attraverso l'uso di access list, ed infine supporta la replicazione e la ridondanza, ed è pertanto in grado di rispondere ad esigenze di resistenza agli incidenti.
Il vantaggio più importante rispetto a NIS però è quello della sicurezza: LDAP può essere utilizzato attraverso TSL/SSL, consentendo la trasmissione crittata dei dati, la autenticazione di client e server, e la verifica dell'integrità dei dati.
Per gestire i dati di autenticazione convenieno creare un utente dedicato sull'elenco, da tenere separato dall'utente usato come amministratore per tutto l'elenco. Questo permette di avere un maggiore controllo su quanto i vari client potranno fare, limitando l'accesso alle sole informazioni che riguardano l'autenticazione.
Per questo definiremo un apposito utente authuser che avrà il permesso di accedere ai dati che ci interessano. Il primo passo è di inserire i suoi dati nell'elenco, per farlo usiamo il solito comando ldapadd, con il file user.ldif, al cui interno inseriremo i dati, del tipo:
dn: cn=authuser,dc=gnulinux,dc=it
cn: authuser
sn: authuser
objectClass: top
objectClass: person
userPassword: {SSHA}l/J+F07gZ/bgPAuHan2YjyBf35F6F+1S
che creerà il nuovo utente direttamente sotto la radice del nostro elenco;
l'ultimo dato è la password criptata, che può essere generata con il comando
slappasswd, di default, come nel caso, il comando chiede due volte la
password dal terminale e poi stampa il relativo hash, pronto all'uso per
essere inserito nel file con un taglia e incolla, usando l'algorimo SHA. Si
possono richiedere algoritmi alternativi con l'opzione -h, ad esempio
il comando:
[root@havnor migrationtools]# slappasswd -h {md5}
New password:
Re-enter new password:
{MD5}DIgCi/OqamoUPthG8r4epA==
genera la password con l'algoritmo MD5.
A questo punto su può aggiungere il nuovo utente con:
[root@havnor migrationtools]# ldapadd -x -D'cn=admin,dc=gnulinux,dc=it' -W -f user.ldif Enter LDAP Password: adding new entry "cn=authuser,dc=gnulinux,dc=it"ma restano da assegnarli i privilegi. Questo si fa andando ad aggiungere le access list che servono in slapd.conf; in particolare occorerà dare accesso alle password; questo si fa con le righe:
access to attribute=userPassword
by dn="cn=admin,dc=chl,dc=it" write
by dn="cn=authuser,dc=chl,dc=it" read
by anonymous auth
by self write
by * none
Il tipo di privilegio da assegnare al nuovo utente riguardo al campo userPassword dipende da come si vuole utilizzare il modulo pam-ldap. Al solo scopo di autenticazione basta il privilegio di lettura, come nell'esempio,12 in questo caso però gli utenti non saranno in grado di cambiare la loro password con passwd e dovranno ricorrere esplicitamente a ldapmodify.
Il problema è che la password che permette di collegarsi al server LDAP dai client è mantenuta in chiaro nel file ldap.secret; questo è un problema in quanto chiunque abbia accesso fisico alle macchine ha la possibilità di leggere questo file. Fintanto che si utilizza l'utente authuser in sola lettura questo non è particolarmente grave, in quanto è sostanzialmente equivalente a consentire la lettura delle password criptate per tutti gli utenti, cosa comunque inevitabile se si vuole poterli autenticare in maniera centralizzata su una macchina. Il problema nasce per l'accesso in scrittura; in questo modo chiunque abbia l'accesso come root ad una qualunque delle macchine client diventa in grado di cambiare le password per tutti gli utenti sul server e quindi avere un incidenza anche su tutte le altre.
Per questo motivo si è mantenuto il permesso in sola lettura, se però si vuole che gli utenti possano utilizzare i normali tool di gestione, come passwd, occorrerà assegnare anche il privilegio di scrittura.