Da Faber Libertatis.

In determinate configurazioni di rete, quali internet point, scuole oppure aziende, può essere necessario centralizzare le informazioni di login degli utenti, in genere nome utente, password e i permessi dell'utente.

Nel caso dei server LTSP, in genere è sufficiente usare la modalità standard di gestione delle utente dei sistemi Unix/Linux, cioè dei file di testo nella directory /etc, ma il numero degli utenti può crescere velocemente e in questi caso il vecchio sistema potrebbe rivelarsi inefficiente. Oppure, per gestire un proxy di rete con autenticazione che sia usato sia dalla rete LTSP che dagli eventuali altri PC stand-alone della rete, potremmo necessitare di esportare le funzionalità di autenticazione e proxy dal server LTSP e concentrarle in un server dedicato in rete. Potremmo avere cioè una configurazione di questo tipo:

 ________       __________
| CLIENT |     | PC       |   
| LTSP 1 +--+  | STANDARD +--
|________|  |  |__________|  |
 ________   |   ________     |   ________
| CLIENT |  |  | SERVER |    |  | LDAP + |
| LTSP 2 +--+--+  LTSP  +----+--+ PROXY  +----> INTERNET
|________|  |  |________|       |________|
...         |       
 ________   |
| CLIENT |  |
| LTSP n +--+
|________|  |

LDAP

Per i sistemi Unix e Linux è conveniente utilizzare per centralizzare le informazioni sugli utenti, un server LDAP (Lightweight Directory Access Protocol), in particolare la sua incarnazione libera più diffusa, cioè OpenLDAP.

In pratica LDAP è un protocollo di rete, derivato da X.500, per cui necessita di una componente server ed una client. In genere la componente server è ricoperta, come detto, da OpenLDAP, mentre quella client da programmi specifici oppure da moduli di PAM, il principale sistema di autenticazione e gestione degli accessi usato sotto Linux.

Le informazioni gestite dal server LDAP sono contenute in una sorta di database che si differenzia in alcune caratteristiche salienti:

E' progettato per essere molto più veloce in lettura che in modifica dei dati (in fondo, i dati degli utenti cambiano con una frequenza molto limitata rispetto ad un database standard);
la struttura dei dati si affida ad un albero gerarchico che ricorda la struttura del file system, e non ad un insieme dii tabelle.

Di seguito uno schema esemplificativo di una struttura gerarchica in LDAP:

          ()
    dc=example,dc=net
          /\
         /  \
        /    \
       /      \
      ()      () 
 ou=People ou=Group
      /|       |\
     / |       | \
    /  |       |  \
   /   |       |   \
  ()   ()     ()    ()
uid=   uid=   cn=    cn=
user1  user2  group1 group2

Questa è probabilmente la più semplice struttura realizzazione con LDAP per rappresentare i dati degli utenti. Abbiamo infatti:

una radice che corrisponde alla rete, dove dc=example,dc=net rappresenta il dominio example.net, dc infatti significa "domain component";
una ramificazione dell'albero ou=People raggruppa tutti gli utenti, ou significa "organizational unit";
un'altra ramificazione dell'albero ou=Groups raggruppa tutti i gruppi a cui attribuire gli utenti;
le estremità dell'abero al di sotto del nodo ou=People rappresentano gli utenti, ad esempio uid=user1;
le estremità dell'abero al di sotto del nodo ou=Group rappresentano i gruppi, ad esempio cn=group1.

La struttura è comunque flessibile, è infatti possibile gestire più sotto-alberi per reti diverse, oppure introdurre dei sotto-alberi per gestire informazioni come gli host della rete oppure una rubrica comune...

Un altro concetto indispensabile è quello di dn o "distinguished name", cioè una stringa che rappresenta in modo univoco un nodo dell'albero fornendo tutti i nodi che si attraversano per raggiungere la radice. Nel nostro caso ad esempio user1 e group1 sono identificati dai seguenti dn:

uid=user1,ou=People,dc=example,dc=net
cn=group1,ou=Group,dc=example,dc=net

Nel fare ricerca in un albero è spesso utile utilizzare una base di ricerca (base search), ad esempio per trovare un utente si cerca il nodo con quel determinato uid al di sotto della base di ricerca ou=People,dc=example,dc=net.

Ma cosa sono uid, cn, ou, dc? Sono attributi associati agli oggetti contenuti nell'albero. Ad un oggetto o nodo dell'albero vengono assegnate delle classi e quindi eredita degli attributi associati a queste classi, alcuni attributi sono obbligatori, altri sono opzionali. In genere un oggetto utente in genere eredita gli attributi dalle classi account,posixAccount,shadowAccount,top, mentre un oggetto gruppo dalle classi posixGroup,top.

Naturalmente gli attributi sono molti, e ulteriormente estensibili, e li vedremo di volta in volta. Per il momento ecco la traduzione di quelli visti fin'ora:

uid, User IDentity;
cn, Common Name;
ou, Organizational Unit;
dc, Domain Component.

La gestione degli utenti in Unix/Linux

Ogni processo in Unix/Linux è identificato da un numero positivo, il PID (Process IDentifier). Il PID 0 è associato al Kernel il PID 1 è associato al primo processo avviato dal Kernel, in genere il programma /sbin/init. Init avvia in modo diverso, a seconda del tipo di init (un init BSD, un System V Init, l'Upstart di Ubuntu etc.), vari processi, ognuno con un suo specifico PID univoco. Ad un certo punto Init avvia vari processi getty associandoli ai terminali virtuali. Questi stessi processi getty avviano un processo login che verifica le credenziali dell'utente e avvia una shell (in genere /bin/bash). Similmente viene fatto anche per il terminale grafico, dove un desktop manager (gdm, kdm, xdm etc) richiede all'utente di autenticarsi e poi avvia l'ambiente grafico. Tutti i processi sono associati a loro volta ad un UID (User IDentifier). Fino al processo che effettua il login questi processi sono associati all'UID 0, cioè root, poi il processo di login lancia la shell (testuale o grafica) effettuando un cambio di UID, utilizzando l'UID dell'utente che si è autenticato.

Anche i file di un file system POSIX-compliant sono associati ad un UID, ma oltre a questo anche ad un GID, cioè un Group IDentifier. Tutte le informazioni relative ad un UID e a GID sono in genere contenute in alcuni file di testo sotto la directory /etc.

Struttura del file /etc/passwd

Gli utenti sono dichiarati all'interno del file /etc/passwd, un file di testo modificabile solo da root ma leggibile da tutti, in cui ogni riga rappresenta un utente, a sua volta divisa in campi dal carattere separatore ':'. Il significato del campo dipende dalla sua posizione nell'ordine. Di seguito il significato dei campi (per la man page eseguire 'man 5 passwd'):

nome di login (detto anche nome utente), deve essere univoco;
password cifrata;
UID, è un numero intero positivo, deve essere univoco;
GID del gruppo primario dell'utente, è un numero intero positivo e identifica un gruppo definito nel file /etc/group;
un campo descrittivo, definito 'gecos', a volte diviso in più campi con il carattere ',' che può contenere informazioni come nome e cognome dell'utente, il numero di telefono, il numero della stanza etc.;
il path dell'home directory dell'utente;
la shell predefinita, cioè il programma che viene automaticamente lanciato una volta autenticatisi correttamente al programma login.

Questo file si può leggere con un editor o un pager, oppure elaborato con i comandi di elaborazione testi (cat, cut, grep etc). Un buon strumento è però getent in quanto non solo permette di effettuare una ricerca in un file di sistema ma anche nella base dati LDAP che andremo a realizzare.

Eseguire dunque Il seguente comando:

getent passwd faber

Questo comando visualizza le informazioni sull'utente faber ordinandole come una riga del file /etc/passwd. Ecco la risposta sul mio sistema di test:

faber:x:1000:1000:Faber Libertatis,,,,:/home/faber:/bin/bash

Questo utente è stato il primo ad essere creato durante la fase di installazione, per cui ha il primo UID disponibile, che in genere è il 1000, in quanto quelli inferiori sono riservati per gli utenti di sistema.

Si noti che anche il GID è uguale a 1000 e che il campo password è sostituito con una x. Analizziamo ora dove sono memorizzate le informazioni sui gruppi e sulla password.

Struttura del file /etc/group

Il file di sistema dove sono conservate le informazioni sui gruppi è /etc/group ed ha una struttura simile a /etc/passwd ma un significati diverso nei campi e anche un numero di campi differente. Eccoli:

nome del gruppo, deve essere univoco;
la password del gruppo, praticamente mai usata;
GID, è un numero intero positivo, deve essere univoco;
lista degli utenti membri del gruppo (non sono elencati gli utenti che hanno il gruppo come gruppo primario ma solo come secondario).

Prendiamo ad esempio il gruppo primario dell'utente faber, e estraiamolo con il comando getent:

getent group faber

Ed ecco il risultato:

faber:x:1000:

Come si vede possono esistere un utente ed un gruppo con lo stesso nome e lo stesso identificativo. In oltre il quarto campo è vuoto perché faber è il gruppo primario dell'utente faber. Se eseguiamo il seguente comando avremo la lista dei gruppi di cui fa parte l'utente faber:

groups faber
faber adm dialout cdrom floppy audio dip video plugdev fuse lpadmin admin

Eseguendo ad esempio una ricerca sul gruppo admin troveremo elencato anche l'utente faber in quanto è un gruppo secondario:

getent group admin
admin:x:115:faber

Struttura del file /etc/shadow

Linux in genere usa le shadow password, ovvero conserva le password degli utenti in un file diverso da /etc/passwd (dove normalmente sarebbero). Questo file è leggibile e modificabile solo da root ed è /etc/shadow. In ogni caso le password non sono mai conservate in chiaro, ma cifrate, o meglio ancora, ne è conservato un hash code, cioè il risultato di un'operazione crittografica che utilizza la password in chiaro e una stringa detta 'salt' per ottenere una stringa detta appunto hash code che abbia le seguenti caratteristiche:

sia molto difficile se non impossibile ricavare dall'hash code e dal salt la password originale;
non devono esserci stessi risultati per dati in ingresso differenti.

L'algoritmo predefinito in Unix è una versione rivisitata del DES ma ha diversi difetti che lo rendono poco sicuro oggi da attacchi brute-force e dictionary, per cui su Linux si preferisce l'MD5.

L'hashing code è composto dalla concatenazione dell'hash code con il codice risultato dalla trasformazione, per cui per verificare che una password immessa sia corretta, viene rieseguita la stesso procedimento crittografico, se il risultato coincide con il valore memorizzato la password è corretta.

Oltre alla password nel file /etc/shadow sono contenute ulteriori informazioni sulla gestione della password stessa, soprattutto se è valida, quando scade o quando risulta disabilitata. Di seguito la spiegazione del significato dei campi usati in questo file:

nome di login, è lo stesso del primo campo del file /etc/passwd;
password cifrata, se inizia con $1$ è cifrata in MD5, a seguire si trova il salt e dopo un terzo $ comincia il risultato del procedimento di hashing. Se inizia per ! o * non è possibile autenticarsi come per tutte le stringhe che non siano degli hash code validi;
data dell'ultima modifica della password, è espressa in giorni dall'epoch day cioè il 01/01/1970;
numero di giorni prima dei quali la password non può essere nuovamente cambiata;
numero di giorni dopo i quali la password deve essere cambiata;
numero di giorni prima della scadenza della password in cui l'utente viene avvertito;
numero di giorni dopo la scadenza della password che, se passati senza cambiare la password, l'account viene disabilitato;
data in cui l'account viene disabilitato, sempre espressa come numero di giorni a partire dall'epoch day;
campo riservato.

Per ricavare da una data espressa come numero di giorni dall'epoch day, la data in formato italiano (cioè gg/mm/aaaa, tipo 31/12/2008) possiamo usare in Linux il seguente comando sostituendo il numero 14330:

date -d '1970-01-01 UTC 14330 days' '+%d/%m/%Y'

Per capire il procedimento del cambio password, prendiamo il seguente caso:

sudo getent shadow testuser
testuser:$1$kbLCDTPe$WGEfsoutWp2zrE3mtlRoF1:14332:7:30:7:7::

Con il comando di prima scopriamo che 13442 corrisponde al 29/03/2009. Per 7 giorni da questa data l'utente non può cambiare la propria password, se però non lo fa sarà costretto a farlo a partire dal trentesimo giorno e sarà avvisato ogni volta che effettua il login per 7 giorni prima di quella data. Al trentesimo sarà costretto a cambiare la password. Se però al trentesimo non effettua più il login, e pertanto non cambia la password, e passano altri 7 giorni, il suo account sarà disabilitato.

Creazione, modifica e cancellazione di utenti e gruppi

Per intervenire sui tre file fino ad adesso presentati si usano di solito dei comandi da shell, anche se nulla vieterebbe di editare i singoli file.

In genere è abitudine creare un gruppo specifico per un nuovo utente con lo stesso nome di gruppo del nome di login dell'utente. Per fare questo si usa il comando groupadd. Di seguito un esempio per il gruppo testuser:

sudo groupadd testuser

Il programma crea il record nel file /etc/group associandolo al primo GID disponibile tra quelli riferiti ai gruppi non di sistema, in genere dal 1000 in su.

Una volta creati tutti i gruppi a cui l'utente deve appartenere, è possibile inserire anche l'utente. Vediamo il comando per la creazione di un utente desktop in Ubuntu (quindi senza il gruppo admin) di nome testuser:

sudo useradd -g testuser -G adm,dialout,cdrom,floppy,audio,dip,video,plugdev,fuse,lpadmin -c 'Utente di test' -d /home/testuser -m -s /bin/bash testuser

In questo caso ci sono diversi parametri, uno è sottinteso ed è l'UID che viene assegnato automaticamente sulla base del primo libero tra quelli non riservati per gli utenti di sistema (in genere al di sotto di 1000). Vediamo gli altri parametri:

-g testuset, assegna all'utente il gruppo primario,
-G adm,..., assegna all'utente i gruppi secondari, si noti che è una lista i cui elementi sono separati da una virgola
-c 'Utente di test', assegna la descrizione dell'utente;
-d /home/testuset, assegna la home directory dell'utente;
-m crea la home directory se non esiste;
-s /bin/bash, assegna la shell predefinita;
testuser, cioè l'ultimo parametro è il nome di login dell'utente.

OpenLDAP, lato server

Installazione di OpenLDAP

Il software OpenLDAP in Ubuntu è suddiviso in vari pacchetti. La componente server che svolge la funzione di server LDAP è slapd. Procediamo quindi alla sua installazione assieme alle utility necessarie per le query di test ed il popolamento della base dati.

sudo apt-get install slapd ldap-utils

I pacchetti che saranno installati sono: ldap-utils, libdb4.2, slapd.

In fase di configurazione del package, è richiesto di inserire due volte la password dell'utente amministratore della base dati. Conclusa l'installazione la base il server slapd è già avviato ed si dispone di una base dati vuota da popolare.

Configurazione di OpenLDAP

In quanto il processo di auto-configurazione tenta di prevedere tutti i parametri di configurazione, è meglio rieseguire la configurazione costringendo in questo modo il processo di configurazione a chiedere ulteriori informazioni. Eseguiamo:

sudo dpkg-reconfigure slapd

Tra le domande, quelle da personalizzare, oltre alla password di admin, sono le domande sul nome di dominio e l'organizzazione. Non è strettamente necessario che il nome di dominio sia quello di un server DNS, ma deve struttura la forma di un nome di dominio, cioè stringhe di lettere e numeri divisi da punti, per esempio faberlibertatis.org.

Alle domande rispondere nel seguente modo:

Omit OpenLDAP server configuration? No
Nome di dominio DNS: <nome di dominio>
Organization name: <descrizione della propria organizzazione>
Administrator password: <password di admin>
Confirm password: <password di admin>
Database di backend da usare: HDB
Do you want the database to be removed when slapd is purged? No
Spostare il vecchio database? No
Allow LDAPv2 protocol? No

Test di installazione

A questo punto slapd è in esecuzione con una base dati popolata solo dall'organizzazione che rappresenta la radice del nostro albero e dall'utente amministratore. Per testare il buon funzionamento del sistema eseguire i seguenti comandi ldapsearch, che permettono di effettuare delle query della base dati:

ldapsearch -xLLL -b 'dc=faberlibertatis,dc=org' 
ldapsearch -xLLL -b 'dc=faberlibertatis,dc=org' -D 'cn=admin,dc=faberlibertatis,dc=org' -W

Sostituire 'dc=faberlibertatis,dc=org' con la propria radice o base di ricerca, corrisponde al nome di dominio con i singoli descrittori divisi da punti, stavolta divisi da virgole ',' e preceduti da 'dc='. Per esempio con il dominio dominio.net avremo una base di ricerca espressa come 'dc=dominio,dc=net'.

Il primo comando restituisce tutti gli attributi che un utente non autenticato può ricevere, quindi tutti tranne la password degli utenti. La seconda invece prevede l'autenticazione da parte dell'utente admin e restituisce anche questa informazione. Viene infatti richiesta la password dell'utente admin. Il significato dei parametri è il seguente:

-x, non usare l'autenticazione SASL (che in questo tutorial non usiamo);
-LLL, restituisce meno commenti oltre alle informazioni effettive;
-b, imposta la base di ricerca;
-D, indica il distinguished name dell'utente con cui fare login alla base dati;
-W, richiede la digitazione di una password.

Ora conviene configurare il file /etc/ldap/ldap.conf con i dati fondamentali per utilizzare i comandi del pacchetto ldap-utils. Modificare il file inserendo le seguenti righe, adattando come già fatto il parametro BASE alla propria base di ricerca:

BASE	dc=faberlibertatis,dc=org
URI	ldap://127.0.0.1:389/

Rieseguire ora gli stessi comandi di prima senza il parametro -b per verificare che tutto funzioni:

ldapsearch -xLLL 
ldapsearch -xLLL -D 'cn=admin,dc=faberlibertatis,dc=org' -W

Popolamento della base dati

Ora bisogna creare gli organizational unit per gli utenti (People) e i gruppi (Group). Eseguire quanto segue, sostituendo dc=faberlibertatis,dc=org con la propria base di ricerca:

cat << EOT > ~/people-group.ldif
dn: ou=People,dc=faberlibertatis,dc=org
objectClass: organizationalUnit
ou: People

dn: ou=Group,dc=faberlibertatis,dc=org
objectClass: organizationalUnit
ou: Group
EOT

ldapadd -x -D 'cn=admin,dc=faberlibertatis,dc=org' -W -f ~/people-group.ldif

Per verificare la creazione dei nuovi nodi eseguire uno dei comandi ldapsearch già visti.

Creare il primo utente per i test

La creazione di un utente può essere relizzatata con la scrittura di un file LDIF ed il suo caricamento con i tool già visti. Purtroppo è un'operazione complessa ed è meglio affidarsi a dei tool che semplifichino il processo. Vedremo ora lo strumento CPU

sudo apt-get install cpu

Saranno installati i pacchetti: cpu e cracklib2. Modifichiamo il file di configurazione /etc/cpu/cpu.conf introducendo i seguenti valori, gli altri vanno bene come sono, ricordarsi di sostituire il proprio dominio a dc=faberlibertatis,dc=org e la propria password di admin dove necessario:

BIND_DN = cn=admin,dc=faberlibertatis,dc=org
BIND_PASS = <password di admin>
USER_BASE = ou=People,dc=faberlibertatis,dc=org
GROUP_BASE = ou=Group,dc=faberlibertatis,dc=org
MIN_UIDNUMBER = 2000
MIN_GIDNUMBER = 2000
USERGROUPS = no
USERS_GID = 100

In quanto il file contiene una password di amministrazione ha i permessi di lettura solo da parte di root. Queste informazioni forniscono allo strumento cpu le informazioni per operare come amministratore dell'albero LDAP (dn dell'utente admin e password), le strutture assegnate a contenere gli utenti e i gruppi, il numero minimo da assegnare agli UID e ai GID (considerate che abbiamo già un utente con UID e un GID 1000, per cui quelli sono già stati occupati, ecco perché qui partiamo da 2000). Inoltre per semplicità non prevediamo di definire un gruppo personale per ogni utente ma di associarlo ad un gruppo predefinito che poi è il gruppo users (il cui GID è 100).

Per poter assegnare ad un utente definito nell'albero LDAP un gruppo è necessario che questo sia clonato con lo stesso GID e lo stesso nome di gruppo dal file /etc/group. Facciamolo per il gruppo primario predefinito degli utenti:

sudo cpu groupadd --gid=100 users

Ora creiamo l'utente ldaptestuser con la password omonima:

sudo cpu useradd --password=ldaptestuser ldaptestuser

Per verificare che l'utente ed il gruppo siano stati generati correttamente possiamo eseguire, oltre ai precedenti comandi, i seguenti:

sudo cpu cat
ldapsearch -xLLL -D 'uid=ldaptestuser,ou=People,dc=faberlibertatis,dc=org' -W '(uid=ldaptestuser)'

Il secondo comando richiede la password appena assegnata all'utente stesso ed esegue una ricerca solo per quel determinato utente.

Ora siamo pronti per tentare di autenticarci con il nuovo utente appena creato.

Autenticazione LDAP, lato client

Configurazione del client LDAP sulla macchina server LDAP

Iniziando configurando la stessa macchina con il server LDAP per autenticarsi sul server stesso. Installiamo le librerie client:

sudo apt-get install ldap-auth-client

Saranno installati i seguenti pacchetti: auth-client-config, ldap-auth-client, ldap-auth-config, libnss-ldap e libpam-ldap.

La fase di configurazione del pacchetto richiede le seguenti informazioni:

LDAP server Uniform Resource Identifier: ldap://127.0.0.1:389/
Distinguished name of the search base: dc=faberlibertatis,dc=org
LDAP version to use: 3
Make local root Database admin: Sì
Does the LDAP database require login? No
LDAP account for root: cn=admin,dc=faberlibertatis,dc=org
LDAP root account password: <password di admin>

Il processo di configurazione crea il file /etc/ldap.conf con i parametri usati da libnss-ldap che da libpam-ldap, mentre in /etc/ldap.secret si trova la password di admin, il file è comunque leggibile solo da root.

Per abilitare l'autenticazione su LDAP è necessario attivare la configurazione opportuna con il comando auth-client-config, ma prima è meglio modificare opportunamente il file di configurazione /etc/auth-client-config/profile.d/ldap-auth-config per contenere le configurazioni complete da applicare. In particolare si consiglia di cambiare il valore di umask con cui è generalmente creata la home directory, che di default in Ubuntu è 0022 (la home directory assume i permessi 755 o rwxr-xr-x quindi è leggibile ed attraversabile da tutti), in un valore più restrittivo come 0077 (la home directory assume i permessi 700 o rwx------). Inoltre è consigliabile eliminare le limitazioni nella password che non erano precedentemente definite (cioè min=4 e max=8) e se si vuole mantenere la riga con pam_foreground installare il package libpam-foreground. L'aspetto del file modificato dovrebbe essere dunque il seguente:

[lac_ldap]
nss_passwd=passwd: files ldap
nss_group=group: files ldap
nss_shadow=shadow: files ldap
pam_auth=auth       sufficient   pam_ldap.so
        auth       required     pam_unix.so nullok_secure use_first_pass
pam_account=account    sufficient   pam_ldap.so
        account    required     pam_unix.so
pam_password=password   sufficient   pam_ldap.so
        password   required     pam_unix.so nullok obscure md5
pam_session=session    required     pam_unix.so
        session    required     pam_mkhomedir.so skel=/etc/skel/ umask=0077
        session    optional     pam_ldap.so
        session    optional     pam_foreground.so

In alternativa, si può seguire la configurazione suggerita da Utente:Stefano che ha il seguente vantaggio "nel caso il servente LDAP sia down (non raggiungibile) le varie procedure che usano pam dovranno attendere il timeout prima di passare allo step successivo (pam_unix in questo caso)." La configurazione suggerita è la seguente::

[lac_ldap]
nss_passwd=passwd: files ldap
nss_group=group: files ldap
nss_shadow=shadow: files ldap
pam_auth=auth [success=1 default=ignore] pam_unix.so nullok_secure
        auth required pam_ldap.so use_first_pass
        auth required pam_permit.so
pam_account=account sufficient pam_unix.so
        account required   pam_ldap.so
pam_password=password   sufficient   pam_ldap.so
        password   required     pam_unix.so nullok obscure md5
pam_session=session    required     pam_unix.so
        session    required     pam_mkhomedir.so skel=/etc/skel/ umask=0077
        session    optional     pam_ldap.so
        session    optional     pam_foreground.so

Applicare dunque le modifiche con il seguente comando:

sudo auth-client-config -a -p lac_ldap

Le modifiche saranno apportate ai file /etc/nsswitch.conf, a /etc/pam.d/common-auth, /etc/pam.d/common-account, /etc/pam.d/common-session e /etc/pam.d/common-password.

Verificare che tutto funzioni correttamente con i seguenti comandi (al secondo fornire la password data per l'utente ldaptestuser):

getent passwd ldaptestuser
su - ldaptestuser

PhpLdapAdmin, Ldap Account Manager, Ldap Web Administration Tool

Al fine di facilitare la gestione di un gran numero di utenti, può essere utile ricorrere ad uno di questi tool Web nati per l'amministrazione di base dati LDAP.

PhpLdapAdmin

Installare il gestore di basi dati LDAP PhpLdapAdmin:

sudo apt-get install phpldapadmin

Saranno installati i seguenti pacchetti: apache2, apache2-mpm-prefork, apache2-utils, apache2.2-common, libapache2-mod-php5, libapr1, libaprutil1, libpq5, php5-common, php5-ldap e phpldapadmin.

Se in fase di avvio del server apache dovesse comparire il seguente errore: "apache2: Could not reliably determine the server's fully qualified domain name, using <indirizzo IP> for ServerName", modificare il file /etc/apache2/apache2.conf andando ad inserire la seguente riga dopo ServerRoot, sostituendo <Indirizzo IP> con l'indirizzo IP statico del server da usare per accedervi:

ServerName <indirizzo IP>

Collegandosi con il browser a http://<indirizzo IP>/phpldapadmin/ è probabile che appaia la scritta: "Memory Limit low. Your php memory limit is low - currently 16M". In tal caso cambiare la riga "memory_limit = 16M" in "memory_limit = 32M" nel file /etc/php5/apache2/php.ini e riavvia Apache con il seguente comando: