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.
La serie comprende questi articoli :
Realizzare un Primary Domain Controller con SAMBA, Openldap e smbldap-tools : (1 di 6)
Realizzare un Primary Domain Controller con SAMBA, Openldap e smbldap-tools : (2 di 6)
Realizzare un Primary Domain Controller con SAMBA, Openldap e smbldap-tools : (3 di 6)
Realizzare un Primary Domain Controller con SAMBA, Openldap e smbldap-tools : (4 di 6)
Realizzare un Primary Domain Controller con SAMBA, Openldap e smbldap-tools : (5 di 6)
Realizzare un Primary Domain Controller con SAMBA, Openldap e smbldap-tools : (6 di 6)
Nota :
Questo articolo è originariamente apparso su Tux Journal nel Gennaio 2008.
Da sempre appassionato del mondo open-source e di Linux nel 2009 ho fondato il portale Mia Mamma Usa Linux! per condividere articoli, notizie ed in generale tutto quello che riguarda il mondo del pinguino, con particolare attenzione alle tematiche di interoperabilità, HA e cloud.
E, sì, mia mamma usa Linux dal 2009.
Lascia un commento