Terminata la descrizione del progetto, è venuto il momento di iniziare a configurare le componenti che impiegheremo nel PDC, partendo da Openldap.

Configurazione di SLAPD

Il primo passo da compiere nello sviluppo del progetto PDC riguarda l’installazione del Directory Server e delle utilities per accedervi :

# apt-get install slapd ldap-utils

durante l’installazione verrà richiesta la password relativa all’utente “admin”, amministratore del direttorio.

Al termine dell’installazione, il sistema avvierà il server LDAP:

# Starting OpenLDAP: slapd.

a questo punto, si procederà all’installazione dei pacchetti SAMBA e delle smbldap-tools:

# apt-get install samba samba-doc smbclient smbldap-tools

per la quale si potranno confermare le opzioni di default suggerite, in quanto la configurazione di SAMBA andrà sensibilmente modificata in fase di sviluppo del progetto.

In fase di installazione, il file di configurazione del demone slapd subisce già delle modifiche automatiche relative in particolare al suffisso del dominio LDAP che dovrà gestire. Tale suffisso è legato al nome della macchina. Nel caso illustrato, la macchina è stata nominata in fase di installazione “pdc” con dominio “testlan.local”, il programma di installazione ha quindi inserito il suffisso “dc=testlan,dc=local” nel file.

Chiaramente il file andrà compilato a seconda delle esigenze, modificando il suffisso con i dati del dominio che interessa servire.

Il tipo di oggetto registrato in un Directory Service deve essere conosciuto dallo stesso. E’ per questo che tra le righe di configurazione di slapd.conf sono presenti le dichiarazioni degli schemi supportati. Uno schema LDAP contiene le definizioni dei campi che lo compongono e dei tipi dei dati, in sostanza la struttura dell’oggetto che può essere registrato.

Lo schema con il quale gli account utente SAMBA verranno registrati nel direttorio andrà quindi specificato in aggiunta a quelli dichiarati nel file di configurazione di slapd.

All’interno del pacchetto “samba-doc” è contenuto il file che contiene lo schema relativo all’alberatura SAMBA. Sarà quindi sufficiente copiare tale file nella directory degli schema ldap :

# zcat /usr/share/doc/samba-doc/examples/LDAP/samba.schema.gz > /etc/ldap/schema/samba.schema

tale schema verrà quindi richiamato nel file /etc/ldap/slapd.conf:

include /etc/ldap/schema/samba.schema

Il modo in cui Slapd gestisce le informazioni dipende dal tipo di backend usato. Dalla scelta del backend dipenderà il modo in cui i dati verranno fisicamente registrati su disco. Il backend che useremo per realizzare il PDC è “bdb”, ossia l’interfaccia transazionale dello Sleepycat Berkley DB, che è anche il backend di default di Slapd.

Andranno poi aggiunti nel file degli indici per ottimizzare le ricerche, ricercando quindi “# Indexing options for database #1” all’interno del file, alla riga :

index objectClass eq

andranno aggiunte queste altre:

index uid,uidNumber,gidNumber,memberUid eq
index cn,mail,surname,givenname eq,subinitial
index sambaSID eq
index sambaPrimaryGroupSID eq
index sambaDomainName eq

infine, come ultimo passo per l’ottimizzazione di slapd per il pieno supporto ai domini windows andrà modificata la riga relativa alle modifiche password da:

access to attrs=userPassword,shadowLastChange

a

access to attrs=userPassword,shadowLastChange,sambaNTPassword,sambaLMPassword

Per rendere effettive le modifiche alla struttura del file di configurazione, andrà riavviato il servizio slapd:

# /etc/init.d/slapd restart
Stopping OpenLDAP: slapd.
Starting OpenLDAP: slapd.

A questo punto potrà essere verificata la funzionalità del server slapd attraverso il comando:

# slapcat

e la configurazione del componente client del pacchetto openldap, il file /etc/ldap/ldap.conf:

BASE dc=testlan, dc=local
URI ldap://127.0.0.1

che verrà utilizzata dal comando:

ldapsearch -x

che dovrebbe produrre un output simile al seguente:

# extended LDIF
#
# LDAPv3
# base <> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
# testlan.local
dn: dc=testlan,dc=local
objectClass: top
objectClass: dcObject
objectClass: organization
o: testlan.local
dc: testlan
# admin, testlan.local
dn: cn=admin,dc=testlan,dc=local
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: admin
description: LDAP administrator
# search result
search: 2
result: 0 Success
# numResponses: 3
# numEntries: 2

Che dimostra come il nostro direttorio, sebbene vuoto, esista e sia interrogabile.

Nel prossimo articolo verrà descritta nel dettaglio la configurazione delle smbldap-tools e la loro integrazione con Openldap.

LEZIONI PRECEDENTI:
11 Gennaio 2008: Realizzare un Primary Domain Controller con SAMBA, Openldap e smbldap-tools (1/6)

di Raoul Scarazzini - TuxJournal.net