LDAP (LightWeight Directory Access Protocol) è un protocollo standard per l’interrogazione e la modifica dei servizi di directory, come ad esempio un elenco aziendale di email o una rubrica telefonica, o più in generale qualsiasi raggruppamento di informazioni che può essere espresso come record di dati ed organizzato in modo gerarchico (fonte Wikipedia). Esso permette in parole povere di memorizzare e gestire dati, relativi esempio ad utenti di un sistema, su un server, per poi gestirli a livello client. Può essere molto utile per gestire ad esempio un archivio centralizzato di utenti di una rete locale; vedremo come installarlo su Debian e come configurarlo affinchè l’accesso al sistema sui client (ovvero l’autenticazione) possa avvenire usando (anche) utenti remoti memorizzati sul server.

LDAPworm
Si tratta di un protocollo complesso, utilizzabile in svariate situazioni, altamente configurabile (anche se a mio modesto parere, la configurazione alle volte risulta piuttosto macchinosa): quello che sarà mostrato è solo un esempio di utilizzo, in quanto una trattazione davvero esaustiva pretenderebbe praticamente un intero corso dedicato a LDAP. Questa è una configurazione che ho realizzato nella pratica io stesso per un progettino di qualche tempo fa. Non pretendo che sia la migliore possibile, né che sia l’unica possibile, però funziona.

Prima di proseguire, fissiamo una configurazione di esempio per il nostro server:

  • IP: 192.168.10.100
  • Hostname: server.red-blue.local

Il primo passo consiste nell’installazione di OpenLDAP, l’implementazione open source del protocollo LDAP, sulla macchina server, per farlo su Debian diamo come root:

apt-get install slapd ldap-utils

Durante l’installazione ci verrà richiesta una password di amministrazione per LDAP, basterà fornirla e confermarla; inoltre, dovremo rispondere anche ad una serie di domande, diciamo che si può rispondere nel seguente modo:

  • Omettere la configurazione del server di OpenLDAP? No
  • Nome di dominio: red-blue.local
  • Nome dell’organizzazione: red-blue.local
  • Password di amministrazione: fornire password
  • Conferma password: ripetere la password
  • Database di backend: HDB
  • Rimuovere il database se slapd viene disinstallato: No
  • Muovere il vecchio database: Si
  • Abilitare LDAPv2: No

A questo punto la configurazione è completa, e possiamo testare in maniera molto semplice:

ldapsearch -x

Da dare sempre come root. Il risultato dovrebbe essere qualcosa del genere:

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

In pratica, ci viene detto che il server presenta solo l’utente admin, relativo al dominio che abbiamo specificato. Ora, il database è vuoto, occorre popolarlo con gli utenti che poi potranno autenticarsi su un qualsiasi sistema. Prima di procedere però, come ulteriore conferma, apriamo il file /etc/ldap/ldap.conf, dovremmo vedere qualcosa di simile:

#
 # LDAP Defaults
 #
 # See ldap.conf(5) for details
 # This file should be world readable but not world writable.
 BASE dc=red-blue,dc=local
 URI ldap://192.168.10.100 ldap://server.red-blue.local
 #SIZELIMIT 12
 #TIMELIMIT 15
 #DEREF never
 # TLS certificates (needed for GnuTLS)
 TLS_CACERT /etc/ssl/certs/ca-certificates.crt

Da notare le righe BASE e URI, che contengono le informazioni principali, soprattutto per quanto riguarda l’URI. Se le due righe dovessero essere commentate, decommentatele e modificatele aggiungendo i dati necessari.

Se dovesse essere necessario, riavviate LDAP con il comando (sempre come root mi raccomando!):

service slapd restart

Dicevamo, occorre popolare il database: quello di LDAP è un database con un’organizzazione gerarchica, per cui di fatto avremo una specie di albero, a partire dalla radice fino ad arrivare alle foglie (gli utenti). Proviamo ad aggiungere un paio di organizationalUnit (gruppi all’interno dei quali poi potremo inserire gli utenti), creiamo un file orgunits.ldif con all’interno:

dn: ou=Groups,dc=red-blue,dc=local
ou: Groups
objectClass: top
objectClass: organizationalUnit
 
dn: ou=People,dc=red-blue,dc=local
ou: People
objectClass: top
objectClass: organizationalUnit

Dopo aver salvato il file, diamo il comando:

ldapadd -x -D cn=admin,dc=red-blue,dc=local -w 123456 -f orgunits.ldif

In pratica, ci stiamo autenticando come admin, fornendo la password (supponiamo che sia banalmente 123456) e indichiamo come fonte di informazioni il file appena creato.

A questo punto, non ci resta che provare ad inserire un utente, facciamolo creando il file user.ldif:

dn: uid=user1,ou=People,dc=red-blue,dc=local
uid: user1
cn: Utente di Test
givenName: user1
sn: user1
objectClass: inetOrgPerson
objectClass: posixAccount
loginShell: /bin/bash
uidNumber: 1000
gidNumber: 1000
homeDirectory: /home/user
 
dn: cn=user1,ou=Groups,dc=red-blue,dc=local
objectClass: posixGroup
cn: user1
gidNumber:1000

E come prima, dopo aver salvato, diamo il comando:

ldapadd -x -D cn=admin,dc=red-blue,dc=local -w 123456 -f user.ldif

Se tutto è andato bene, il comando:

 ldapsearch -x

Adesso restituirà qualcosa del genere:

# extended LDIF
 #
 # LDAPv3
 # base <dc=unixmen,dc=local> (default) with scope subtree
 # filter: (objectclass=*)
 # requesting: ALL
 #
 # red-blue.local
 dn: dc=red-blue,dc=local
 objectClass: top
 objectClass: dcObject
 objectClass: organization
 o: red-blue
 dc: red-blue
 # admin, red-blue.local
 dn: cn=admin,dc=red-blue,dc=local
 objectClass: simpleSecurityObject
 objectClass: organizationalRole
 cn: admin
 description: LDAP administrator
 # Groups, red-blue.local
 dn: ou=Groups,dc=red-blue,dc=local
 objectClass: organizationalUnit
 objectClass: top
 ou: Groups
 # People, red-blue.local
 dn: ou=People,dc=red-blue,dc=local
 objectClass: organizationalUnit
 objectClass: top
 # user1, People, red-blue.local
 dn: uid=user1,ou=People,dc=red-blue,dc=local
 gidNumber: 1000
 homeDirectory: /home/user
 sn: user
 givenName: Utente di Test
 loginShell: /bin/bash
 objectClass: inetOrgPerson
 objectClass: posixAccount
 objectClass: top
 uidNumber: 1000
 uid: user1
 # search result
 search: 2
 result: 0 Success
 # numResponses: 6
 # numEntries: 5

Per ora direi che basta così, il server LDAP è configurato e funzionante. Il mio consiglio è quello di cercare di fare un pochino di pratica con questi elementi prima di proseguire. Vedremo in seguito come configurare anche un client e, infine, uno strumento che potrebbe facilitarci la vita nella gestione del server LDAP.

Alla prossima..

FacebookTwitterGoogle+LinkedInRedditTumblrDiggOknotizie
Molto scarsoScarsoSufficienteBuonoOttimo (Nessun voto)
Loading...

Licenza

Creative Commons License
RedBlue's Blog di RedBlue è rilasciato sotto licenza Creative Commons 2.5 Italia.

Badges

Wikio - Top dei blog - Linux Cionfs'Forum CMS Check PageRank

Other

Se hai trovato utile questo blog, supportalo con una piccola donazione per l'hosting..


Locations of visitors to this page