Capitolo 9.   Samba e OpenLDAP: gestione centralizzata degli utenti di rete

In questo capitolo viene esaminata la possibilità di utilizzare Samba come PDC con gli utenti della rete memorizzati in un archivio gestito da OpenLDAP (1) (<http://www.openldap.org>).

Uno dei principali vantaggi di una soluzione di questo genere è che anche eventuali macchine clienti GNU/Linux possono far accreditare gli utenti servendosi dello stesso archivio; è così possibile una gestione completamente centralizzata e uniforme degli utenti in una rete eterogenea.

Prima di entrare nei dettagli vengono presi in esame la natura del servizio LDAP e la sua installazione e configurazione indipendentemente da Samba.

9.1   Il servizio LDAP

LDAP (Lightweight Directory Access Protocol) è un protocollo di tipo cliente/servente proposto nel 1995 dall'università del Michigan allo scopo di accedere alle «directory» o «elenchi» in rete.

Da qui in poi si fa uso del termine «elenchi», anche se è sicuramente meno usato, soprattutto per evitare possibili confusioni con l'altro significato che il termine «directory» ha relativamente alla organizzazione logica dei dati sulle memorie di massa.

Nella descrizione dell'acronimo LDAP si nota che è presente il termine «lightweight» che fa pensare a qualcosa di poco pesante; il motivo è che questo protocollo si pone come un'alternativa semplificata al preesistente protocollo ISO/OSI (International Organization for Standardization/Open Systems Interconnection) X.500 definito per la gestione degli elenchi in rete e noto anche come protocollo DAP.

I vantaggi di LDAP rispetto a X.500 sono fondamentalmente i seguenti:

Esistono vari servizi di elenchi in rete proprietari, come ad esempio Oracle Internet Directory o Microsoft Active Directory; con OpenLDAP, del quale ci occupiamo in questa sede, è possibile realizzarli in modo completamente libero.

9.1.1   Natura degli elenchi in rete

Un elenco è un catalogo di informazioni anche eterogenee organizzate in una struttura gerarchica; secondo la terminologia ufficiale si parla di un DIT (Directory Information Tree) che contiene vari nodi (objectclass) ognuno dei quali ha una serie di attributi obbligatori o facoltativi che forniscono informazioni sul nodo.

La struttura gerarchica di un elenco può essere rappresentata come un albero capovolto, con la radice in alto; in un elenco possono comunque essere presenti più alberi (cataloghi diversi).

Ogni nodo di un albero può avere un solo genitore e un numero variabile di figli.

Per ogni elenco deve essere definito uno schema cioè l'insieme degli attributi possibili dei nodi, della loro sintassi e dei tipi di oggetti presenti.

In base a questa prima descrizione si può pensare di confrontare un elenco con una base di dati in quanto in entrambi i casi si tratta di insiemi strutturati di dati; esistono però delle differenze che sono di fondamentale importanza:

9.1.2   LDAP per gestire gli utenti di una rete

Uno degli utilizzi più interessanti di LDAP è la gestione centralizzata degli utenti di una rete in ambiente GNU/Linux, compito per il quale può validamente sostituire il vecchio servizio NIS (Network Information Service).

Rispetto al NIS infatti LDAP ha una importante serie di vantaggi:

Quanto appena affermato è realizzabile se Samba è configurato per utilizzare LDAP come sistema di memorizzazione delle parole d'ordine (cioè come password backend). Questo è proprio l'argomento per il quale è stato scritto il presente capitolo.

9.1.3   Definizione di un elenco

Prima di illustrare l'installazione e la configurazione di OpenLDAP è opportuno soffermarsi sulla progettazione dell'elenco delle informazioni da gestire.

Gli oggetti presenti in un elenco che sono «foglie» di un albero, cioè nodi terminali, senza figli, sono raggiungibili grazie ad un identificatore univoco chiamato DN (Distingueshed Name) che ha un aspetto simile al seguente:

uid=rossimario,ou=People,dc=max,dc=planck 

Leggendo il DN da sinistra a destra si ottiene il percorso per risalire dalla foglia alla radice dell'albero; in senso inverso si ottiene la scala gerarchica dei nodi presenti.

Nell'esempio abbiamo due dc (Domain Component) con valori rispettivamente max e planck che rappresentano il suffisso (o radice) dell'albero delle informazioni; seguono poi ou (Organizational Unit) con valore People e uid (User id) con valore rossimario.

In pratica vuol dire che nell'elenco esiste un nodo identificato dall'uid rossimario, appartenente al gruppo o settore delle persone, all'interno dell'organizzazione identificata dal suffisso max.planck.

Naturalmente non è detto che tutti i DN siano definiti con le stesse componenti in quanto dipendono dal tipo di nodo cui si riferiscono; sicuramente avranno questa struttura i DN relativi a oggetti di tipo People.

I valori degli attributi degli oggetti di un elenco non sono case sensitive.

Esiste anche un altro tipo di identificatore chiamato RDN (Relative Distingueshed Name) che può essere associato a qualsiasi nodo ma che non costituisce il percorso completo per reperirlo; esempi possono essere:

uid=rossimario
ou=People 

La decisione su quale sia la radice dell'albero delle informazioni è ovviamente molto importante e deve essere presa con attenzione; esistono due metodi che solitamente vengono usati nella definizione degli elenchi in rete:

  1. suffisso che identifica una organizzazione (azienda, scuola o altro) definito partendo da un nome di dominio; nell'esempio è stato scelto questo metodo usando un dominio privato, cioè non presente in Internet;

  2. suffisso definito con un criterio geografico come nell'esempio che segue.

ou=finance,o=Government,st=Minnesota,c=US 

In questo caso abbiamo un nodo che potrebbe essere relativo al settore finanze della organizzazione Govern dello stato Minnesota negli Stati Uniti.

Il primo metodo è comunque solitamente preferito e viene utilizzato anche nel proseguo di queste dispense mantenendo il nome max.planck.

Come detto in precedenza ogni oggetto dell'elenco ha una serie di attributi grazie ai quali si rendono disponibili le informazioni relative a quell'oggetto.

Facendo di nuovo riferimento all'esempio di un oggetto di tipo People potremmo avere degli attributi come:

cn=Rossi Mario
mail=rossimario@max.planck 

dove cn significa Common Name.

Per sapere quali sono i tipi di oggetti presenti in un elenco e quali sono i relativi attributi si deve conoscere quale è lo schema dell'elenco.

Per fortuna non è quasi mai necessario definire gli schemi degli elenchi da parte dell'amministratore degli stessi, in quanto nel pacchetto OpenLDAP sono già inseriti degli schemi precompilati che sono sufficienti per tutti i tipi più comuni di elenchi in rete.

9.2   Usare OpenLDAP

In questo paragrafo vediamo come installare, configurare e usare OpenLDAP versione 2.4 per la gestione degli utenti, facendo riferimento alla distribuzione Ubuntu.

Non vengono prese in considerazione alcune funzionalità come la replica dell'archivio su serventi diversi.

9.2.1   Installazione di OpenLDAP

Per l'installazione dei pacchetti si può utilizzare uno degli strumenti tipici dell'ambiente Debian come apt-get da linea di comando o synaptic dalla grafica; qui non vengono forniti dettagli sull'utilizzo di questi strumenti per i quali si rimanda alle numerose fonti disponibili in Internet.

I pacchetti da installare sono:

Il pacchetto slapd contiene il servente OpenLDAP e deve essere installato soltanto nella macchina servente.

Gli altri due pacchetti, che contengono rispettivamente le librerie per l'accesso agli elenchi e alcuni programmi di utilità per la gestione degli stessi, devono essere invece installati sia nel servente che nei clienti.

Nel pacchetto slapd è presente anche il demone slurpd che serve a gestire le repliche dell'archivio OpenLDAP tra serventi diversi e che qui, come detto, non usiamo.

Altri pacchetti da usare per sfruttare i servizi offerti da OpenLDAP; vengono qui solo elencati in attesa di esaminare i dettagli al momento opportuno:

Siccome alcuni dei pacchetti citati comprendono programmi scritti in Perl, è necessario che quest'ultimo sia installato nella macchina che stiamo utilizzando.

9.2.2   Configurazione di OpenLDAP

Nelle ultime versioni di OpenLDAP (precisamente a partire dalla 2.3) il sistema di configurazione è completamente variato.

In precedenza veniva usato il classico file di configurazione /etc/ldap/slapd.conf (che comunque può ancora essere utilizzato, come descritto nel paragrafo 9.2.3), mentre ora si è passati ad un metodo basato su una voce DIT speciale che contiene i vari parametri e che viene denominato in varie maniere:

Il nuovo sistema è stato adottato proprio per avere maggiore flessibilità e per poter variare dinamicamente la configurazione con il servizio attivo.

Con alcune distribuzioni di GNU/Linux c'è la possibilità di inserire i parametri fondamentali per l'uso di OpenLDAP semplicemente riconfigurando il pacchetto con il comando:

dpkg-reconfigure slapd

In questo modo si ricevono varie schermate con le richieste relative (tra le altre) alla radice dell'elenco e ai dati di accreditamento dell'utente amministratore.

Nelle versioni più recenti di Ubuntu questo non avviene in quanto il servente viene installato con una configurazione minima e deve essere manipolato con i comandi messi a disposizione dal pacchetto ldap-utils.

Gli unici aspetti su cui si può intervenire con la riconfigurazione sono:

Di seguito vediamo come inserire le informazioni di base nell'archivo di OpenLDAP, in una versione recente di Ubuntu.

Allo scopo vengono usati il comando ldapadd e i file con formato LDIF, che vengono dettagliati maggiormente nel paragrafo 9.2.5:

  1. rendere disponibili gli schemi fondamentali (presenti, dopo l'installazione, nella posizione /etc/ldap/schema/), con il comando:

    ls /etc/ldap/schema/*.ldif | xargs -I {} ldapadd -Y EXTERNAL\
      \-H ldapi:/// -f {}

  2. definire il suffisso dell'elenco (che si suppone corrisponda al dominio max.planck), il tipo di archivio (BDB Berkeley Data Base) e i dati dell'amministratore, con il comando:

    ldapadd -Y EXTERNAL -H ldapi:/// -f slapd_db.ldif

    dopo avere creato il file slapd_db.ldif con il seguente contenuto:

    # Carica i moduli per il tipo di db
    dn: cn=module,cn=config
    objectclass: olcModuleList
    cn: module
    olcModuleLoad: back_bdb.la
    # Crea l'archivio directory
    dn: olcDatabase=bdb,cn=config
    objectClass: olcDatabaseConfig
    objectClass: olcBdbConfig
    olcDatabase: bdb
    # Nome di dominio (esempio max.planck)
    olcSuffix: dc=max,dc=planck
    # Percorso che ospita il db
    olcDbDirectory: /var/lib/ldap
    # Dati dell'amministratore
    olcRootDN: cn=admin,dc=max,dc=planck
    # Ottenere la parola d'ordine con il comando: "slappasswd -h {crypt}" che
    # chiede due volte la password in chiaro (supponiamo sia admin) 
    # e poi incollarla nella riga seguente
    olcRootPW: {CRYPT}g4GGeu14vX3xA
    # Indici per velocizzare le ricerche
    olcDbIndex: uid pres,eq
    olcDbIndex: cn,sn,mail pres,eq,approx,sub
    olcDbIndex: objectClass eq
    # Permette all'utente di modificare la propria psw
    # Permette all'utente anonimo di autenticarsi
    # Permette ad admin di cambiare la psw di chiunque
    olcAccess: to attrs=userPassword
      by self write
      by anonymous auth
      by dn.base="cn=admin,dc=max,dc=planck" write
      by * none
    # Permette agli utenti di cambiare i propri dati
    # Permette a tutti di leggere la directory
    olcAccess: to *
      by self write
      by dn.base="cn=admin,dc=max,dc=planck" write
      by * read
    
  3. inserire la radice dell'elenco qualche unità organizzativa di base, con il comando:

    ldapadd -x -D cn=admin,dc=max,dc=planck -w admin\
      \-f slapd_people.ldif

    dove si suppone che la password dell'amministratore sia admin.

    Il file slapd_people.ldif deve essere creato con il seguente contenuto:

    # Create top-level object in domain
    dn: dc=max,dc=planck
    objectClass: top
    objectClass: dcObject
    objectclass: organization
    o: max.planck
    dc: max
    description: Home network 
    dn: ou=people,dc=max,dc=planck
    objectClass: organizationalUnit
    ou: people
    dn: ou=groups,dc=max,dc=planck
    objectClass: organizationalUnit
    ou: groups
    

Per verificare l'esito positivo delle operazioni appena descritte si può eseguire il comando:

slapcat

che serve ad estrarre le informazioni dall'elenco e dovrebbe fornire questo risultato:

dn: dc=max,dc=planck
objectClass: top
objectClass: dcObject
objectClass: organization
o: max.planck
dc: max
description:: SG9tZSBuZXR3b3JrIA==
structuralObjectClass: organization
entryUUID: b59b4738-f605-102e-9bfe-8f074a5e4515
creatorsName: cn=admin,dc=max,dc=planck
createTimestamp: 20100517134158Z
entryCSN: 20100517134158.581185Z#000000#000#000000
modifiersName: cn=admin,dc=max,dc=planck
modifyTimestamp: 20100517134158Z

dn: ou=people,dc=max,dc=planck
objectClass: organizationalUnit
ou: people
structuralObjectClass: organizationalUnit
entryUUID: b59be2f6-f605-102e-9bff-8f074a5e4515
creatorsName: cn=admin,dc=max,dc=planck
createTimestamp: 20100517134158Z
entryCSN: 20100517134158.585171Z#000000#000#000000
modifiersName: cn=admin,dc=max,dc=planck
modifyTimestamp: 20100517134158Z

dn: ou=groups,dc=max,dc=planck
objectClass: organizationalUnit
ou: groups
structuralObjectClass: organizationalUnit
entryUUID: b59c1a82-f605-102e-9c00-8f074a5e4515
creatorsName: cn=admin,dc=max,dc=planck
createTimestamp: 20100517134158Z
entryCSN: 20100517134158.586593Z#000000#000#000000
modifiersName: cn=admin,dc=max,dc=planck
modifyTimestamp: 20100517134158Z

Concludiamo questo paragrafo sulla configurazione mostrando il contenuto di un altro file, molto importante, presente in Ubuntu e altre distribuzioni derivate da Debian; si tratta del file /etc/default/slapd che contiene alcune impostazioni fondamentali come il nome dell'utente e del gruppo con i privilegi dei quali è in esecuzione il servente OpenLDAP e soprattutto l'indicazione di quale è la modalità di configurazione adottata.

Quest'ultima impostazione è visibile proprio all'inizio del file; non aggiungiamo ulteriori considerazioni sul suo contenuto in quanto i commenti già presenti sono sufficientemente chiari.

      1 # Location of the slapd configuration to use.  If using the cn=config          
      2 # backend to store configuration in LDIF, set this variable to the             
      3 # directory containing the cn=config data; otherwise set it to the location    
      4 # of your slapd.conf file.  If empty, use the compiled-in default              
      5 # (/etc/ldap/slapd.d). 
      6 SLAPD_CONF=
      7 
      8 # System account to run the slapd server under. If empty the server
      9 # will run as root.
     10 SLAPD_USER="openldap"
     11 
     12 # System group to run the slapd server under. If empty the server will
     13 # run in the primary group of its user.
     14 SLAPD_GROUP="openldap"
     15 
     16 # Path to the pid file of the slapd server. If not set the init.d script
     17 # will try to figure it out from $SLAPD_CONF (/etc/ldap/slapd.d by
     18 # default)
     19 SLAPD_PIDFILE=
     20 
     21 # slapd normally serves ldap only on all TCP-ports 389. slapd can also
     22 # service requests on TCP-port 636 (ldaps) and requests via unix
     23 # sockets.
     24 # Example usage:
     25 # SLAPD_SERVICES="ldap://127.0.0.1:389/ ldaps:/// ldapi:///"
     26 SLAPD_SERVICES="ldap:/// ldapi:///"
     27 
     28 # If SLAPD_NO_START is set, the init script will not start or restart
     29 # slapd (but stop will still work).  Uncomment this if you are
     30 # starting slapd via some other means or if you don't want slapd normally
     31 # started at boot.
     32 #SLAPD_NO_START=1
     33 
     34 # If SLAPD_SENTINEL_FILE is set to path to a file and that file exists,
     35 # the init script will not start or restart slapd (but stop will still
     36 # work).  Use this for temporarily disabling startup of slapd (when doing
     37 # maintenance, for example, or through a configuration management system)
     38 # when you don't want to edit a configuration file.
     39 SLAPD_SENTINEL_FILE=/etc/ldap/noslapd
     40 
     41 # For Kerberos authentication (via SASL), slapd by default uses the system
     42 # keytab file (/etc/krb5.keytab).  To use a different keytab file,
     43 # uncomment this line and change the path.
     44 #export KRB5_KTNAME=/etc/krb5.keytab
     45 
     46 # Additional options to pass to slapd
     47 SLAPD_OPTIONS=""

9.2.3   Vecchio sistema di configurazione di OpenLDAP

Come accennato in precedenza, il vecchio metodo di configurazione del servizio OpenLDAP è ancora utilizzabile; prima di vedere come, esaminiamo il contenutodi un file di configurazione slapd.conf relativo ad una versione di OpenLDAP precedente alla 2.3:

      1 # This is the main slapd configuration file. See slapd.conf(5) for more
      2 # info on the configuration options.
      3 
      4 #######################################################################
      5 # Global Directives:
      6 
      7 # Features to permit
      8 #allow bind_v2
      9 
     10 # Schema and objectClass definitions
     11 include         /etc/ldap/schema/core.schema
     12 include         /etc/ldap/schema/cosine.schema
     13 include         /etc/ldap/schema/nis.schema
     14 include         /etc/ldap/schema/inetorgperson.schema
     15 
     16 # Schema check allows for forcing entries to
     17 # match schemas for their objectClasses's
     18 # schemacheck     on
     19 
     20 # Where the pid file is put. The init.d script
     21 # will not stop the server if you change this.
     22 pidfile         /var/run/slapd/slapd.pid
     23 
     24 # List of arguments that were passed to the server
     25 argsfile        /var/run/slapd/slapd.args
     26 
     27 # Read slapd.conf(5) for possible values
     28 loglevel        256
     29 
     30 # Where the dynamically loaded modules are stored
     31 modulepath   /usr/lib/ldap
     32 moduleload   back_bdb
     33 
     34 # The maximum number of entries that is returned for a search operation
     35 sizelimit 500
     36 
     37 # The tool-threads parameter sets the actual amount of cpu's that is used
     38 # for indexing.
     39 tool-threads 1
     40 
     41 #######################################################################
     42 # Specific Backend Directives for bdb:
     43 # Backend specific directives apply to this backend until another
     44 # 'backend' directive occurs
     45 backend          bdb
     46 # checkpoint 512 30
     47 
     48 #######################################################################
     49 # Specific Backend Directives for 'other':
     50 # Backend specific directives apply to this backend until another
     51 # 'backend' directive occurs
     52 #backend         <other>
     53 
     54 #######################################################################
     55 # Specific Directives for database #1, of type bdb:
     56 # Database specific directives apply to this databasse until another
     57 # 'database' directive occurs
     58 database        bdb
     59 
     60 # The base of your directory in database #1
     61 suffix          "dc=max,dc=planck"
     62 
     63 # Where the database file are physically stored for database #1
     64 directory       "/var/lib/ldap"
     65 
     66 # For the Debian package we use 2MB as default but be sure to update this
     67 # value if you have plenty of RAM
     68 dbconfig set_cachesize 0 2097152 0
     69 
     70 # Sven Hartge reported that he had to set this value incredibly high
     71 # to get slapd running at all. See http://bugs.debian.org/303057
     72 # for more information.
     73 
     74 # Number of objects that can be locked at the same time.
     75 dbconfig set_lk_max_objects 1500
     76 # Number of locks (both requested and granted)
     77 dbconfig set_lk_max_locks 1500
     78 # Number of lockers
     79 dbconfig set_lk_max_lockers 1500
     80 
     81 # Indexing options for database #1
     82 index           objectClass eq
     83 
     84 # Save the time that the entry gets modified, for database #1
     85 lastmod         on
     86 
     87 # Where to store the replica logs for database #1
     88 # replogfile   /var/lib/ldap/replog
     89 
     90 # The userPassword by default can be changed
     91 # by the entry owning it if they are authenticated.
     92 # Others should not be able to see it, except the
     93 # admin entry below
     94 # These access lines apply to database #1 only
     95 access to attrs=userPassword,shadowLastChange
     96         by dn="cn=admin,dc=max,dc=planck" write
     97         by anonymous auth
     98         by self write
     99         by * none
    100 
    101 # Ensure read access to the base for things like
    102 # supportedSASLMechanisms.  Without this you may
    103 # have problems with SASL not knowing what
    104 # mechanisms are available and the like.
    105 # Note that this is covered by the 'access to *'
    106 # ACL below too but if you change that as people
    107 # are wont to do you'll still need this if you
    108 # want SASL (and possible other things) to work 
    109 # happily.
    110 access to dn.base="" by * read
    111 
    112 # The admin dn has full write access, everyone else
    113 # can read everything.
    114 access to *
    115         by dn="cn=admin,dc=max,dc=planck" write
    116         by * read
    117 
    118 # For Netscape Roaming support, each user gets a roaming
    119 # profile for which they have write access to
    120 #access to dn=".*,ou=Roaming,o=morsnet"
    121 #        by dn="cn=admin,dc=max,dc=planck" write
    122 #        by dnattr=owner write
    123 
    124 #######################################################################
    125 # Specific Directives for database #2, of type 'other' (can be bdb too):
    126 # Database specific directives apply to this databasse until another
    127 # 'database' directive occurs
    128 #database        <other>
    129 
    130 # The base of your directory for database #2
    131 #suffix   "dc=debian,dc=org"

La numerazione delle righe ovviamente non è presente nel file, è stata aggiunta per poter fare riferimento, in modo più preciso, alle righe di maggiore interesse.

Il file contiene righe di commento che, come al solito, iniziano con «#» ed è suddiviso in tre sezioni:

Le opzioni presenti in una sezione possono sovrascrivere quelle presenti in una sezione precedente.

Nella sezione delle direttive globali vediamo la riga 8 che, se non commentata, permette di avere il supporto per il vecchio protocollo LDAPv2; a seguire una serie di righe (dalla 11 alla 14) che permettono di includere nella definizione del nostro elenco alcuni schemi già pronti.

Questi schemi sono di solito sufficienti per un uso «normale» di OpenLDAP (eventualmente sarebbe da aggiungere lo schema per Samba in caso si vogliano avere gli utenti di quest'ultimo gestiti in un elenco).

Nel caso fosse necessario utilizzare ulteriori schemi, anche di nostra produzione, basta aggiungere la relativa riga include nel file di configurazione e il file contenente le specifiche dello schema nella directory /etc/apt/schema.

A titolo di esempio viene mostrata una porzione del file /etc/ldap/schema/core.schema riguardante gli attributi uid e mail:

attributetype ( 0.9.2342.19200300.100.1.1
        NAME ( 'uid' 'userid' )
        DESC 'RFC1274: user identifier'
        EQUALITY caseIgnoreMatch
        SUBSTR caseIgnoreSubstringsMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )

attributetype ( 0.9.2342.19200300.100.1.3
        NAME ( 'mail' 'rfc822Mailbox' )
        DESC 'RFC1274: RFC822 Mailbox'
        EQUALITY caseIgnoreIA5Match
        SUBSTR caseIgnoreIA5SubstringsMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} )

Riguardo le altre direttive globali ci soffermiamo solo sul livello di log a riga 29 (le altre dovrebbero essere abbastanza chiare ed in ogni caso si può fare riferimento ai commenti nel file e al manuale in linea di slapd.conf).

I valori possibili del livello di log sono -1, 0 o potenze del due; di seguito viene riportata la tabella dei valori che si trova nel manuale in linea di slapd.conf:

Livello di log Descrizione
-1 enable all debugging
0 no debugging
1 trace function calls
2 debug packet handling
4 heavy trace debugging
8 connection management
16 print out packets sent and received
32 search filter processing
64 configuration file processing
128 access control list processing
256 stats log connections/operations/results
512 stats log entries sent
1024 print communication with shell backends
2048 print entry parsing debugging

Il valore inserito può essere tale da attivare più opzioni di log; ad esempio se si sceglie 255 si attivano le opzioni corrispondenti ai livelli 1, 2, 4, 8, 16, 32, 64, 128.

Nella sezione delle specifiche del backend notiamo che, alla riga 45, è indicata BDB come base di dati; notiamo inoltre che sarebbe possibile avere più di un backend (righe commentate da 49 a 52).

Molto più corposa è la sezione delle specifiche della base di dati, all'interno della quale notiamo subito come sia possibile gestire più basi di dati o alberi con un solo servente OpenLDAP (righe commentate da 125 a 131).

Nel nostro esempio è sufficiente gestire un solo albero e le relative direttive sono comprese tra riga 55 e riga 123.

Una delle più importanti è naturalmente l'indicazione della radice (o suffisso) a riga 61; anche in questo caso il valore corrisponde a quanto indicato al momento della configurazione del pacchetto slapd.

Alla riga 64 viene indicato dove risiede fisicamente l'archivio; seguono direttive sulla memoria cache il bloccaggio degli oggetti, l'indicizzazione dell'archivio, che qui non vengono approfondite.

Nell'ultima parte della sezione ci sono le direttive per le access list che servono a indicare chi può accedere all'elenco e quali operazioni può fare.

Nello specifico: con le righe da 95 a 99 si indica che l'utente amministratore può cambiare le parole d'ordine di tutti, che ognuno può cambiare la propria, che gli altri non possono né leggere né scrivere la parola d'ordine di qualcuno.

La seconda direttiva access di riga 110, è presente per evitare malfunzionamenti se si utilizza il meccanismo di autenticazione SASL (Simple Authentication and Security Layer); nel nostro caso non servirebbe.

Con la terza (righe da 114 a 116) si stabilisce che l'amministratore può accedere in lettura e scrittura a qualsiasi oggetto, tutti gli altri utenti invece solo in lettura.

Prima di concludere la configurazione del servente, può essere opportuno definire i diritti di accesso di un altro utente, diverso dall'amministratore, da usare per la consultazione dell'elenco in sede di accreditamento.

A questo utente viene concesso solo il diritto di leggere le informazioni relative alle parole d'ordine (cosa sufficiente per le operazioni di accreditamento).

Un'altra possibilità sarebbe quella di accedere all'elenco come amministratore ma qui non viene presa in considerazione.

Entrambe le scelte hano infatti un «difetto»:

Per motivi di sicurezza è da ritenere preferibile la prima alternativa.

La riga da aggiungere in /etc/ldap/slapd.conf (fra le righe 96 e 97 già presenti) è la seguente:

      by dn="cn=auth,dc=max,dc=planck" read

avendo evidentemente scelto auth come nome dell'utente da usare per la consultazione dell'elenco.

Per usare il vecchio file di configurazione /etc/ldap/slapd.conf occorre convertirne il contenuto nel nuovo formato tramite il seguente procedimento:

9.2.4   Avvio e chiusura di OpenLDAP

Per avviare o riavviare il demone di OpenLDAP, nella Debian o simili, si esegue:

/etc/init.d/slapd start

oppure:

/etc/init.d/slapd restart

Per fermarlo si esegue:

/etc/init.d/slapd stop

Il servizio risponde sulla porta 389 (valore che può essere cambiato intervenendo nel file di configurazione).

Naturalmente è consigliabile fare in modo che il demone slapd sia inserito fra quelli che vengono avviati automaticamente all'accensione del sistema.

Di solito a questo provvedono gli script di installazione del pacchetto; se ciò non avviene si può ovviare creando un collegamento simbolico nella directory /etc/rc2.d allo script di attivazione del demone con il comando:

ln -s /etc/init.d/slapd /etc/rc2.d/S19slapd

Si presti attenzione al fatto che questo procedimento è valido solo per Debian e distribuzioni derivate, in altri casi varia leggermente.

9.2.5   Popolare l'elenco

Per inserire i dati all'interno dell'elenco e per poi poterli gestire si utilizzano una serie di programmi presenti nei pacchetti slapd e ldap-utils.

I primi sono eseguibili solo dall'utente root e il loro nome inizia con «slap»; gli altri sono eseguibili da tutti gli utenti e il loro nome inizia con «ldap».

Quello che segue è un elenco dei più importanti tra questi programmi.

Di quelli che utilizziamo per caricare e gestire il nostro elenco viene dato tra breve qualche dettaglio di utilizzo; per una panoramica più completa si rimanda, come sempre, ai relativi manuali in linea:

Per inserire i dati nell'elenco si utilizzano file scritti in uno speciale formato chiamato LDIF (Lightweight Directory Interchange Format).

Questo formato permette di descrivere gli oggetti dell'elenco e rende possibile il caricamento e lo scaricamento degli stessi in OpenLDAP.

Il formato LDIF è semplicemente un testo con una serie di coppie attributo/valore come nell'esempio che segue relativo ad un ipotetico oggetto «utente GNU/Linux»:

dn: uid=fulvio,ou=People,dc=max,dc=planck
uid: fulvio
cn:: ZnVsdmlv
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
userPassword: {crypt}$1$HvG0n.P3$/0rbqUdi40yALQEXWunv50
shadowLastChange: 13220
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
uidNumber: 1000
gidNumber: 1000
homeDirectory: /home/fulvio
gecos: fulvio,,,

Prima di tutto dobbiamo inserire nell'elenco l'utente auth da utilizzare per la consultazione dei dati in sede di accreditamento degli utenti della rete, come spiegato alla fine del paragrafo 9.2.2.

Per questo prepariamo un file auth.ldif come il seguente:

dn: cn=auth,dc=max,dc=planck
cn: auth
sn: auth
objectClass: top
objectClass: person
userPassword: {CRYPT}Eqz.Ufi0SLb3k

La parola d'ordine può essere ottenuta con il comando:

slappasswd -h {crypt}

e poi incollata nel file.

Quindi fermiamo il servizio OpenLDAP:

/etc/init.d/slapd stop

e inseriamo l'utente eseguendo:

slapadd -l auth.ldif

In teoria per inserire tutti i dati nell'elenco si dovrebbe operare in modo simile:

Anche se tecnicamente fattibile, questo procedimento sarebbe senza dubbio lungo e noioso; ecco quindi che sono stati creati degli strumenti automatici di migrazione scritti in Perl che permettono di ottenere automaticamente i file LDIF relativi a molti degli archivi gestiti in un sistema GNU/Linux come ad esempio gli utenti e i gruppi (attingendo i dati dai file /etc/passwd, /etc/shadow, /etc/group).

Questi strumenti si trovano nel pacchetto migrationtools che è stato già citato come molto utile e quindi senz'altro da installare.

In particolare usiamo (nell'ordine in cui sono elencati):

Tutti presenti nella directory /usr/share/migrationtools/.

Prima di usare questi strumenti occorre modificare il file /usr/share/perl5/migrate_common.ph, contenente le impostazioni di base per la migrazione, in modo che le righe riguardanti il nome del dominio e il suffisso assumano il seguente aspetto:

# Default DNS domain
$DEFAULT_MAIL_DOMAIN = "max.planck";

# Default base 
$DEFAULT_BASE = "dc=max,dc=planck";

Procediamo poi alla creazione dei file LDIF posizionandoci in /usr/share/migrationtools/ ed eseguendo:

./migrate_base.pl >base.ldif

./migrate_passwd.pl /etc/passwd >utenti.ldif

./migrate_group.pl /etc/group >gruppi.ldif

A questo punto può essere necessario intervenire sui file ottenuti per qualche modifica: ad esempio possiamo togliere dai file utenti.ldif e gruppi.ldif gli utenti e i gruppi «di sistema» (come bin, mail, news ecc.) che non sono utenti e gruppi effettivi.

Sicuramente dobbiamo eliminare dal file base.ldif le righe seguenti:

dn: dc=max,dc=planck
dc: max
objectClass: top
objectClass: domain

perché sono relative ad un oggetto già presente nell'elenco (è stato inserito quando si è configurato il pacchetto slapd).

Iniziamo quindi a popolare il nostro elenco con:

slapadd -l base.ldif

In questo modo vengono inseriti molti oggetti utili all'inserimento successivo di utenti e gruppi.

Se adesso eseguiamo il comando:

slapcat

otteniamo una risposta molto più corposa rispetto a quando l'elenco era quasi vuoto; ci sono infatti, oltre alla radice e all'utente amministratore, anche tutti gli oggetti seguenti:

dn: ou=Hosts,dc=max,dc=planck
ou: Hosts
objectClass: top
objectClass: organizationalUnit
structuralObjectClass: organizationalUnit
entryUUID: 1cade61c-c183-102a-94fb-6f2027449ad2
creatorsName:
modifiersName:
createTimestamp: 20060816145616Z
modifyTimestamp: 20060816145616Z
entryCSN: 20060816145616Z#000000#00#000000

dn: ou=Rpc,dc=max,dc=planck
ou: Rpc
objectClass: top
objectClass: organizationalUnit
structuralObjectClass: organizationalUnit
entryUUID: 1cae1e20-c183-102a-94fc-6f2027449ad2
creatorsName:
modifiersName:
createTimestamp: 20060816145616Z
modifyTimestamp: 20060816145616Z
entryCSN: 20060816145616Z#000001#00#000000

dn: ou=Services,dc=max,dc=planck
ou: Services
objectClass: top
objectClass: organizationalUnit
structuralObjectClass: organizationalUnit
entryUUID: 1cb07e90-c183-102a-94fd-6f2027449ad2
creatorsName:
modifiersName:
createTimestamp: 20060816145616Z
modifyTimestamp: 20060816145616Z
entryCSN: 20060816145616Z#000002#00#000000

dn: nisMapName=netgroup.byuser,dc=max,dc=planck
nisMapName: netgroup.byuser
objectClass: top
objectClass: nisMap
structuralObjectClass: nisMap
entryUUID: 1cb08fa2-c183-102a-94fe-6f2027449ad2
creatorsName:
modifiersName:
createTimestamp: 20060816145616Z
modifyTimestamp: 20060816145616Z
entryCSN: 20060816145616Z#000003#00#000000

dn: ou=Mounts,dc=max,dc=planck
ou: Mounts
objectClass: top
objectClass: organizationalUnit
structuralObjectClass: organizationalUnit
entryUUID: 1cb0acc6-c183-102a-94ff-6f2027449ad2
creatorsName:
modifiersName:
createTimestamp: 20060816145616Z
modifyTimestamp: 20060816145616Z
entryCSN: 20060816145616Z#000004#00#000000

dn: ou=Networks,dc=max,dc=planck
ou: Networks
objectClass: top
objectClass: organizationalUnit
structuralObjectClass: organizationalUnit
entryUUID: 1cb0ba9a-c183-102a-9500-6f2027449ad2
creatorsName:
modifiersName:
createTimestamp: 20060816145616Z
modifyTimestamp: 20060816145616Z
entryCSN: 20060816145616Z#000005#00#000000

dn: ou=People,dc=max,dc=planck
ou: People
objectClass: top
objectClass: organizationalUnit
structuralObjectClass: organizationalUnit
entryUUID: 1cb0c832-c183-102a-9501-6f2027449ad2
creatorsName:
modifiersName:
createTimestamp: 20060816145616Z
modifyTimestamp: 20060816145616Z
entryCSN: 20060816145616Z#000006#00#000000

dn: ou=Group,dc=max,dc=planck
ou: Group
objectClass: top
objectClass: organizationalUnit
structuralObjectClass: organizationalUnit
entryUUID: 1cb0d5a2-c183-102a-9502-6f2027449ad2
creatorsName:
modifiersName:
createTimestamp: 20060816145616Z
modifyTimestamp: 20060816145616Z
entryCSN: 20060816145616Z#000007#00#000000

dn: ou=Netgroup,dc=max,dc=planck
ou: Netgroup
objectClass: top
objectClass: organizationalUnit
structuralObjectClass: organizationalUnit
entryUUID: 1cb1cb4c-c183-102a-9503-6f2027449ad2
creatorsName:
modifiersName:
createTimestamp: 20060816145616Z
modifyTimestamp: 20060816145616Z
entryCSN: 20060816145616Z#000008#00#000000

dn: ou=Protocols,dc=max,dc=planck
ou: Protocols
objectClass: top
objectClass: organizationalUnit
structuralObjectClass: organizationalUnit
entryUUID: 1cb1dc90-c183-102a-9504-6f2027449ad2
creatorsName:
modifiersName:
createTimestamp: 20060816145616Z
modifyTimestamp: 20060816145616Z
entryCSN: 20060816145616Z#000009#00#000000

dn: ou=Aliases,dc=max,dc=planck
ou: Aliases
objectClass: top
objectClass: organizationalUnit
structuralObjectClass: organizationalUnit
entryUUID: 1cb1ea82-c183-102a-9505-6f2027449ad2
creatorsName:
modifiersName:
createTimestamp: 20060816145616Z
modifyTimestamp: 20060816145616Z
entryCSN: 20060816145616Z#00000a#00#000000

dn: nisMapName=netgroup.byhost,dc=max,dc=planck
nisMapName: netgroup.byhost
objectClass: top
objectClass: nisMap
structuralObjectClass: nisMap
entryUUID: 1cb201d4-c183-102a-9506-6f2027449ad2
creatorsName:
modifiersName:
createTimestamp: 20060816145616Z
modifyTimestamp: 20060816145616Z
entryCSN: 20060816145616Z#00000b#00#000000

Ora non rimane che inserire utenti e gruppi con i comandi:

slapadd -l utenti.ldif

slapadd -l gruppi.ldif

Si può verificare con slapcat che tutti i dati siano stati inseriti.

Ecco una parte della risposta, riguardante gli oggetti nell'elenco corrispondenti all'utente e al gruppo rossimario:

dn: uid=rossimario,ou=People,dc=max,dc=planck
uid: rossimario
cn: Rossi Mario
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
userPassword:: e2NyeXB0fSQxJEZjRlJNWnRrJG9YZWZmTldMd1RYSnNmV281amVtNTE=
shadowLastChange: 13376
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
uidNumber: 1001
gidNumber: 1001
homeDirectory: /home/rossimario
gecos: Rossi Mario,,0422-1234567,
structuralObjectClass: account
entryUUID: 2355333c-c19a-102a-836a-21b74a8ee554
creatorsName:
modifiersName:
createTimestamp: 20060816174105Z
modifyTimestamp: 20060816174105Z
entryCSN: 20060816174105Z#000000#00#000000

dn: cn=rossimario,ou=Group,dc=max,dc=planck
objectClass: posixGroup
objectClass: top
cn: rossimario
userPassword:: e2NyeXB0fXg=
gidNumber: 1001
structuralObjectClass: posixGroup
entryUUID: 25f2f44e-c19a-102a-8997-638e7699ad6b
creatorsName:
modifiersName:
createTimestamp: 20060816174110Z
modifyTimestamp: 20060816174110Z
entryCSN: 20060816174110Z#000000#00#000000

Per continuare a utilizzare il servente OpenLDAP, ricordiamo poi di riattivarlo:

/etc/init.d/slapd start

9.2.6   Gestire i dati dell'elenco

Vediamo brevemente come è possibile cancellare e modificare i dati dell'elenco e come si possono fare le ricerche; le prime due operazioni possono essere svolte solo da utenti autorizzati (per come abbiamo configurato il servente, solo dall'utente amministratore).

Vediamo poi anche un modo alternativo a slapadd per inserire i dati.

Dei comandi illustrati in questo paragrafo vengono fornite solo le linee essenziali di utilizzo; per i dettagli sulle numerose opzioni previste si rimanda come al solito ai manuali in linea.

Prima di utilizzare i programmi di gestione dell'elenco occorre modificare il file di configurazione /etc/ldap/ldap.conf (o /etc/ldap.conf) in modo che contenga le informazioni mostrate di seguito (il contenuto preciso del file varia secondo la versione dei pacchetti che si usano):

# LDAP Defaults
#

# See ldap.conf(5) for details
# This file should be world readable but not world writable.

BASE    dc=max, dc=planck
URI     ldap://127.0.0.1:389

Questo è necessario anche nelle macchine clienti nelle quali, evidentemente, l'indirizzo indicato nella riga URI deve essere quello del servente e non quello del localhost; in caso ci fossero problemi di collegamento al servente si può provare ad inserire la riga host numero_ip al posto di URI.

La presenza di queste impostazioni permette di usare i comandi di manipolazione dell'elenco senza indicare ogni volta informazioni come la radice dell'albero, l'indirizzo e la porta su cui è in ascolto il servente.

Per ulteriori dettagli sul contenuto di questo file si veda il manuale in linea di ldap.conf.

9.2.6.1   Cancellazione dei dati

Il comando per cancellare un oggetto è ldapdelete; vediamo subito un esempio supponendo di voler cancellare l'utente rossimario:

ldapdelete -x -D "cn=admin,dc=max,dc=planck" \
  \ "uid=rossimario,ou=People,dc=max,dc=planck" -W

Il significato delle opzioni e degli argomenti è questo:

Alcune altre opzioni importanti:

9.2.6.2   Modifica dei dati

Per la modifica si usa il comando ldapmodify; anche in questo caso esaminiamo un esempio:

ldapmodify -x -D "cn=admin,dc=max,dc=planck" -f file_modifiche.txt -W

Alcune opzioni (compresa -H) hanno esattamente lo stesso significato visto nel comando precedente; in questo caso si passa in input un file_modifiche che contiene le istruzioni sulle modifiche da apportare.

Il contenuto del file potrebbe essere simile al seguente:

dn: uid=rossimario,ou=People,dc=max,dc=planck
changetype: modify
replace: homeDirectory
homeDirectory:/home/rossi
-
replace: loginShell
loginShell: /bin/zsh
-

Il file contiene uno o più DN da modificare e per ognuno il tipo di modifica da fare (nell'esempio è modify ma potrebbe anche essere add o delete in modo da rimpiazzare rispettivamente i comandi ldapadd o ldapdelete). Qui si chiede di modificare gli attributi homedirectory e loginShell con i nuovi valori indicati; è anche possibile eliminare o aggiungere attributi (se consentito dallo schema) rispettivamente scrivendo delete o add al posto di replace.

Una volta eseguito il comando, ecco il nuovo aspetto dell'oggetto mariorossi ottenuto con slapcat:

dn: uid=rossimario,ou=People,dc=max,dc=planck
uid: rossimario
cn: Rossi Mario
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
userPassword:: e2NyeXB0fSQxJEZjRlJNWnRrJG9YZWZmTldMd1RYSnNmV281amVtNTE=
shadowLastChange: 13376
shadowMax: 99999
shadowWarning: 7
uidNumber: 1001
gidNumber: 1001
gecos: Rossi Mario,,0422-1234567,
structuralObjectClass: account
entryUUID: 02a4028a-c1b8-102a-8b59-6d8a33f08c2a
creatorsName:
createTimestamp: 20060816211455Z
homeDirectory: /home/rossi
loginShell: /bin/zsh
entryCSN: 20060816212358Z#000000#00#000000
modifiersName: cn=admin,dc=max,dc=planck
modifyTimestamp: 20060816212358Z

Esiste anche la possibilità di utilizzare ldapmodify senza passare il file di comandi; in questo caso si inseriscono le istruzioni di modifica da tastiera, con la stessa sintassi usata nel file, concludendo l'input con [Ctrl d].

9.2.6.3   Aggiunta di dati

In precedenza abbiamo utilizzato il comando slapadd per inserire oggetti nell'elenco. La stessa operazione si può fare anche con il comando ldapadd con la differenza che non occorre essere l'utente root e che il servente OpenLDAP deve essere attivo.

Il modo migliore per inserire oggetti nell'elenco è quello di preparare dei file LDIF contenenti i dati e passarli in input a ldapadd.

Nel caso si debbano aggiungere utenti o gruppi si può ricorrere come «modelli» ai file LDIF creati automaticamente dalle procedure di migrazione.

Ecco un esempio di uso di ldapadd:

ldapadd -x -D "cn=admin,dc=max,dc=planck" -f file_dati.ldif -W

Non occorre avere i privilegi di root per eseguire il comando ma occorre comunque accreditarsi (come per la cancellazione e la modifica) presso il servente OpenLDAP come utente abilitato alla scrittura dei dati (in questo caso l'utente admin).

Le opzioni sono le stesse viste per i comandi precedenti e anche qui è prevista l'opzione -H.

Di seguito vediamo il contenuto di un possibile file di input per l'inserimento di un utente e di uno per il corrispondente gruppo; si tenga presente che si possono comunque inserire più elementi contemporaneamente semplicemente predisponendo i corrispondenti gruppi di righe nel file di input:

dn: uid=bianchipaolo,ou=People,dc=max,dc=planck
uid: bianchipaolo
cn: Bianchi Paolo
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
userPassword: XXXXXXXXXXXXXXXXXXXXX
shadowLastChange: 13376
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
uidNumber: 1002
gidNumber: 1002
homeDirectory: /home/bianchipaolo
gecos: Bianchi Paolo,,0422-1234567,
dn: cn=bianchipaolo,ou=Group,dc=max,dc=planck
objectClass: posixGroup
objectClass: top
cn: bianchipaolo
userPassword: {crypt}x
gidNumber: 1002

Riguardo alla parola d'ordine si può agire in due modi diversi:

Usando il secondo metodo si riceve richiesta della nuova parola d'ordine dell'utente e della sua conferma (è l'effetto dell'opzione -S) e poi della parola d'ordine dell'utente (amministratore) che si collega per svolgere l'operazione (vedere figura 9.24).

Figura 9.24.

figure/samba-figura-9.1

Anche il comando ldappasswd prevede la possibilità di interagire con un servente diverso dal localhost grazie all'opzione -H.

Una volta che è stata assegnata la prima parola d'ordine ad un utente, questi può cambiarsela in ogni momento con un comando del tipo:

ldappasswd -x -D "uid=bianchipaolo,ou=People,dc=max,dc=planck" -W -S

In questo caso non è necessario specificare il DN dell'utente di cui variare la parola d'ordine perché, in mancanza di questa informazione, il sistema agisce sull'utente che si collega al servente (in questo caso bianchipaolo).

Per essere certi che le parole d'ordine vengano gestite correttamente con i comandi di OpenLDAP si deve fare in modo che vengano create con lo stesso metodo di cifratura utilizzato dal sistema GNU/Linux per le parole d'ordine degli utenti migrati in precedenza.

Sulla macchina usata per i nostri esempi tale metodo è crypt e quindi occorre aggiungere nel file di configurazione /etc/ldap/slapd.conf, fra le direttive globali, questa riga:

password-hash {CRYPT}

in mancanza di indicazioni viene invece applicato SSHA.

9.2.6.4   Ricerca di informazioni

Il comando per effettuare ricerche nell'elenco è ldapsearch.

Le opzioni e le possibilità di utilizzo sono numerose e quindi anche in questo caso si evita l'esame di tutti i dettagli, che sono comunque a disposizione nel manuale in linea, e si commentano alcuni esempi, ricordando che molte opzioni (-H, -x, -D, -W) hanno esattamente lo stesso significato visto nel paragrafo precedente.

ldapsearch -x -LLL -b "dc=max,dc=planck"

Si chiede il contenuto di tutto l'elenco che ha come radice dc=max,dc=planck (opzione -b); l'opzione -L serve ad avere il risultato in formato LDIF, se sono due si disabilitano i commenti e se sono tre si disabilita anche la visualizzazione della versione di LDIF.

L'indicazione della base della ricerca può essere evitata se si inserisce nel file di configurazione /etc/ldap/slapd.conf tra le direttive globali, la riga seguente:

defaultsearchbase dc=max,dc=planck

Come si vede non è necessario (anche se non è proibito) collegarsi al servente con credenziali valide perché la lettura delle informazioni è libera; per questo motivo nella risposta non appaiono gli attributi sensibili come la userPassword.

ldapsearch -x -LLL -b "dc=max,dc=planck" "(cn=*)"

Si chiedono tutti gli oggetti che hanno un attributo cn presente, qualsiasi sia il valore di quest'ultimo.

ldapsearch -x -LLL -b "dc=max,dc=planck" "(uid=*)"\
  \loginShell homeDirectory

Si chiedono tutti gli utenti e si vogliono visualizzare solo gli attributi loginShell e homeDirectory; in figura 9.27 si vede l'effetto del comando.

Figura 9.27.

figure/samba-figura-9.2

ldapsearch -x -LLL -b "dc=max,dc=planck" "(ou=p*)"

Si chiedono tutte le organizational unit il cui nome inizia con «p» o «P» (si ricorda che i valori degli attributi non sono case sensitive).

ldapsearch -x -LLL -b "dc=max,dc=planck"\
  \ "(&(uid=*)(loginshell=/bin/bash))" loginShell homeDirectory

In questo ultimo esempio si vede l'uso di un filtro di ricerca multiplo: si vogliono gli oggetti con attributo uid presente e loginShell uguale a /bin/bash; si noti la sintassi che prevede l'indicazione dell'operatore booleano in testa alla stringa di ricerca.

Gli operatori booleani sono:

9.2.7   Clienti grafici per OpenLDAP

Esistono vari strumenti grafici che facilitano la gestione di un elenco OpenLDAP.

Per i motivi già illustrati nella premessa, è consigliabile utilizzare questo tipo di programmi solo quando si è acquisita sufficiente conoscenza sulla struttura, la configurazione, la gestione di un elenco OpenLDAP, in modo da sfruttarne la comodità e velocità di utilizzo sapendo però quello che si sta facendo.

A titolo di esempio citiamo gq (2) (<http://gq-project.org/>) del quale vediamo un immagine in figura 9.28.

Figura 9.28.

figure/samba-figura-9.3

e l'ottimo programma webmin (3) (<http://www.webmin.com>) che permette la gestione completa di un sistema GNU/Linux con una comoda interfaccia Web (alla porta 10000) e che possiede anche moduli per gli utenti OpenLDAP (ldap users and groups e ldap client utilizzabili in caso si siano installati anche i pacchetti di OpenLDAP per l'autenticazione degli utenti di cui parliamo nel paragrafo 9.3).

Nella figura 9.29 vediamo la schermata di configurazione del modulo ldap client:

Figura 9.29.

figure/samba-figura-9.4

In figura 9.30 vediamo invece una delle schermate, dello stesso modulo, per l'interrogazione dei dati dell'elenco OpenLDAP.

Figura 9.30.

figure/samba-figura-9.5

9.3   Autenticazione degli utenti di rete OpenLDAP

Una volta installato e configurato il servente OpenLDAP si può passare a configurare i clienti affinché lo utilizzino per l'accreditamento degli utenti; a questo proposito possiamo senz'altro considerare tra i clienti anche la macchina dove è installato OpenLDAP.

9.3.1   Configurazione dei pacchetti necessari

Devono essere installati i pacchetti nscd (che non richiede configurazioni particolari), ldap-auth-client, ldap-auth-config, auth-client-config, libnss-ldap e libpam-ldap per i quali invece la procedura di installazione richiede alcune informazioni.

Si ricevono varie richieste riguardanti la configurazione di ldap-auth-config a partire dall'URI (Uniform Resource Identifier) del servente.

Nella figura 9.31 è visibile la relativa schermata in cui si suppone che il servente sia la macchina su cui si stanno configurando anche gli strumenti «lato cliente»; nella realtà questo è ovviamente il caso meno frequente, quindi consideriamo di dover indicare, al posto di localhost, l'indirizzo di una macchina remota.

Figura 9.31.

figure/samba-figura-9.6

Successivamente viene richiesto il suffisso dell'elenco da utilizzare (figura 9.32).

Figura 9.32.

figure/samba-figura-9.7

Quindi è la volta della versione di LDAP (scegliere la 3).

A seguire (figura 9.33) viene chiesto se si vuole che le password utility che utilizzano pam si comportino come se si stessero usando le parole d'ordine locali (ripondere affermativamente).

Figura 9.33.

figure/samba-figura-9.8

La schermata successiva permette di specificare se l'accesso all'archivio di OpenLDAP richiede accreditamento (rispondere affermativamente).

Infine si devono immettere i dati dell'utente abilitato a cambiare le parole d'ordine (deve essere un utente privilegiato, vedi figura 9.34) e dell'utente usato per collegarsi all'elenco (meglio che non sia un utente privilegiato vedi figura 9.35).

Quest'ultimo utente ovviamente deve essere presente nell'elenco; per il suo inserimento si faccia riferimento a quanto descritto nel paragrafo 9.2.5.

Figura 9.34.

figure/samba-figura-9.9

Figura 9.35.

figure/samba-figura-9.a

Entrambe le schermate sono seguite dalla richiesta di immissione delle parole d'ordine degli utenti prescelti.

Una volta ultimata questa configurazione occorre riavviare il demone nscd:

/etc/init.d/nscd restart

9.3.1.1   Modifiche alla configurazione di NSS

Nel file /etc/nsswitch.conf, contenente la configurazione del servizio NSS, è necessario aggiungere l'archivio gestito con OpenLDAP tra le fonti dei dati relativi a utenti e gruppi come mostrato di seguito:

passwd:     compat ldap
shadow:     compat ldap 
group:      compat ldap

L'ordine con cui vengono elencate le fonti è significativo e quindi è opportuno lasciare la priorità a compat in modo che per primi siano interrogati i file di sistema.

A questo punto si è già in grado di verificare con il comando:

getent passwd

che gli utenti dell'elenco appaiano fra quelli riconosciuti dal sistema.

Prima di fare questa prova è consigliabile togliere gli utenti e i gruppi dai file di configurazione del sistema /etc/passwd, /etc/shadow, /etc/group, cancellando le righe relative o usando i comandi userdel o deluser e groudel o delgroup; in questo modo siamo sicuri che gli utenti e i gruppi elencati sono davvero quelli di OpenLDAP.

Si può inoltre verificare il buon esito dell'accreditamento degli utenti sia sul sistema che ospita il cliente che su macchine clienti in cui si siano effettuate le configurazioni appena esaminate.

Prima di fare questa prova occorre però configurare un altro servizio che è molto utile nel contesto che stiamo esaminando: NFS (Network File System), con il quale possiamo centralizzare anche le directory personali degli utenti della rete GNU/Linux.

La macchina sulla quale far risiedere le directory può essere una qualsiasi nella rete, ma ha sicuramente senso che sia la stessa che accredita gli utenti, cioè quella dove è installato OpenLDAP.

Un esame approfondito del servizio NFS esula dagli scopi di queste dispense; ci limitiamo alle nozioni indispensabili il compito che ci proponiamo.

Nella macchina servente si devono installare i pacchetti nfs-kernel-server, nfs-common e portmap e si deve configurare il file /etc/exports come mostrato di seguito:

# /etc/exports: the access control list for filesystems which may be exported
#               to NFS clients.  See exports(5).
#
/home           10.0.0.0/255.0.0.0(rw)

Il significato della configurazione è abbastanza evidente: si vuole condividere la directory /home per tutte le macchine della rete con indirizzo 10.0.0.0 e maschera di rete 255.0.0.0 dando la possibilità di leggere e scrivere tale directory (fatti salvi i permessi sui singoli elementi in essa contenuti).

Si deve poi riavviare il servente NFS:

/etc/init.d/nfs-kernel-server restart

Sulle macchine clienti bisogna invece installare i pacchetti nfs-common e portmap e intervenire nel file /etc/fstab aggiungendo una riga come questa:

10.0.0.3:/home    /home    nfs

Significa che la directory /home del servente (che si suppone abbia indirizzo 10.0.0.3) viene montata sulla /home di quella macchina, che deve esistere ed essere possibilmente vuota (il montaggio non cancella il contenuto preesistente ma lo rende irraggiungibile).

Affinché il montaggio avvenga bisogna però anche eseguire:

mount -a

ma solo la prima volta perché i montaggi indicati nel file /etc/fstab vengono fatti automaticamente ad ogni riavvio del sistema.

Una volta fatte queste operazioni si può provare a collegarsi su una macchina cliente come utente presente nell'elenco OpenLDAP.

Nella figura 9.39 viene mostrata tale operazione con la successiva esecuzione di vari comandi che permettono di constatare come effettivamente l'utente si sia accreditato da remoto.

Figura 9.39.

figure/samba-figura-9.d

9.3.1.2   Modifiche ai file di configurazione dei moduli PAM

Durante la configurazione del pacchetto ldap-auth-config dovrebbe avvenire anche la configurazione del servizio PAM.

In caso contrario si può procedere manualmente ricordando le precauzioni da prendere prima di modificare i moduli PAM che sono state elencate nel paragrafo 7.1.3.

Lo scopo delle modifiche è fare in modo che le applicazioni presenti su una macchina GNU/Linux (login, gdm, ssh ecc.) effettuino l'autenticazione degli utenti attraverso OpenLDAP:

Nei file di configurazione PAM dei servizi che si vogliono autenticare con OpenLDAP si devono aggiungere righe simili a quelle sotto elencate prima delle analoghe righe che fanno riferimento a pam_unix.so con opzione required.

auth     sufficient   pam_ldap.so
account  sufficient   pam_ldap.so
session  sufficient   pam_ldap.so
password sufficient   pam_ldap.so

In Debian e distribuzioni derivate si può intervenire nei seguenti file (usati da tutte le applicazioni):

Anche in questo caso è possibile creare automaticamente la directory personale di un utente al suo primo accreditamento (come visto nel paragrafo 7.1.3) aggiungendo in testa al file /etc/pam.d/common-session la seguente riga:

session  required   /lib/security/pam_mkhomedir.so  skel=/etc/skel/  umask=0022

9.4   Usare Samba con OpenLDAP

Vediamo adesso come utilizzare Samba come PDC con archivio utenti gestito da OpenLDAP.

Questa possibilità è presente stabilmente dalla versione 3 di Samba; con le versioni precedenti era necessario configurare e compilare manualmente il software.

Si noti inoltre che, dovendo aggiornare un servente Samba dalla versione 2.2 alla 3 si deve prevedere una conversione degli oggetti dell'elenco in quanto non è stata mantenuta la compatibilità tra gli schemi di elenco utilizzati e si è passati dal tipo di oggetto sambaAccount a sambaSamAccount.

Per la conversione è possibile utilizzare lo script convertSambaAccount disponibile (in Debian) in /usr/share/doc/samba-doc/examples/LDAP/.

9.4.1   Creazione dell'elenco per Samba

Supponiamo di avere già un archivio di utenti GNU/Linux e che l'elenco OpenLDAP sia inizialmente vuoto; quindi ripartiamo da zero eliminando gli eventuali oggetti inseriti con le prove precedenti.

Il modo più rapido per ottenere questo è fermare il servente slapd, cancellare il contenuto della directory /var/lib/ldap/, e ricreare l'elenco nuovo eseguendo il comando:

dpkg-reconfigure slapd

Si devono poi reinserire schemi e informazioni di base e configurare ldap-auth-config come descritto nei paragrafi 9.2.2 e 9.3.1.

Dobbiamo poi installare il pacchetto smbldap-tools che contiene tutto quello che serve per i nostri scopi; i programmi presenti sono scritti in Perl e sono i seguenti (per i dettagli di funzionamento si rimanda alla consultazione dei rispettivi manuali in linea):

Prima di iniziare a definire l'elenco occorre modificare la configurazione di questo pacchetto e di OpenLDAP compiendo le seguenti operazioni:

  1. copiare i file smbldap.conf e smbldap_bind.conf da /usr/share/doc/smbldap-tools/examples/ a /etc/smbldap-tools/ con i comandi:

    zcat /usr/share/doc/smbldap-tools/examples/smbldap.conf.gz >\
      \/etc/smbldap-tools/smbldap.conf

    cp /usr/share/doc/smbldap-tools/examples/smbldap_bind.conf\
      \/etc/smbldap-tools/

  2. modificare il file smbldap.conf come mostrato di seguito:

          1 # $Source: /opt/cvs/samba/smbldap-tools/smbldap.conf,v $
          2 # $Id: smbldap.conf,v 1.18 2005/05/27 14:28:47 jtournier Exp $
          3 #
          4 # smbldap-tools.conf : Q & D configuration file for smbldap-tools
          5 
          6 #  This code was developped by IDEALX (http://IDEALX.org/) and
          7 #  contributors (their names can be found in the CONTRIBUTORS file).
          8 #
          9 #                 Copyright (C) 2001-2002 IDEALX
         10 #
         11 #  This program is free software; you can redistribute it and/or
         12 #  modify it under the terms of the GNU General Public License
         13 #  as published by the Free Software Foundation; either version 2
         14 #  of the License, or (at your option) any later version.
         15 #
         16 #  This program is distributed in the hope that it will be useful,
         17 #  but WITHOUT ANY WARRANTY; without even the implied warranty of
         18 #  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
         19 #  GNU General Public License for more details.
         20 #
         21 #  You should have received a copy of the GNU General Public License
         22 #  along with this program; if not, write to the Free Software
         23 #  Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307,
         24 #  USA.
         25 
         26 #  Purpose :
         27 #       . be the configuration file for all smbldap-tools scripts
         28 
         29 #############################################################################
         30 #
         31 # General Configuration
         32 #
         33 #############################################################################
         34 
         35 # Put your own SID. To obtain this number do: "net getlocalsid".
         36 # If not defined, parameter is taking from "net getlocalsid" return
         37 SID="S-1-5-21-4251291460-501516116-4086100184"
         38 
         39 # Domain name the Samba server is in charged.
         40 # If not defined, parameter is taking from smb.conf configuration file
         41 # Ex: sambaDomain="IDEALX-NT"
         42 sambaDomain="PLANCK"
         43 
         44 #############################################################################
         45 #
         46 # LDAP Configuration
         47 #
         48 #############################################################################
         49 
         50 # Notes: to use to dual ldap servers backend for Samba, you must patch
         51 # Samba with the dual-head patch from IDEALX. If not using this patch
         52 # just use the same server for slaveLDAP and masterLDAP.
         53 # Those two servers declarations can also be used when you have 
         54 # . one master LDAP server where all writing operations must be done
         55 # . one slave LDAP server where all reading operations must be done
         56 #   (typically a replication directory)
         57 
         58 # Slave LDAP server
         59 # Ex: slaveLDAP=127.0.0.1
         60 # If not defined, parameter is set to "127.0.0.1"
         61 slaveLDAP="127.0.0.1"
         62 
         63 # Slave LDAP port
         64 # If not defined, parameter is set to "389"
         65 slavePort="389"
         66 
         67 # Master LDAP server: needed for write operations
         68 # Ex: masterLDAP=127.0.0.1
         69 # If not defined, parameter is set to "127.0.0.1"
         70 masterLDAP="127.0.0.1"
         71 
         72 # Master LDAP port
         73 # If not defined, parameter is set to "389"
         74 masterPort="389"
         75 
         76 # Use TLS for LDAP
         77 # If set to 1, this option will use start_tls for connection
         78 # (you should also used the port 389)
         79 # If not defined, parameter is set to "1"
         80 ldapTLS="0"
         81 
         82 # How to verify the server's certificate (none, optional or require)
         83 # see "man Net::LDAP" in start_tls section for more details
         84 verify="require"
         85 
         86 # CA certificate
         87 # see "man Net::LDAP" in start_tls section for more details
         88 cafile="/etc/opt/IDEALX/smbldap-tools/ca.pem"
         89 
         90 # certificate to use to connect to the ldap server
         91 # see "man Net::LDAP" in start_tls section for more details
         92 clientcert="/etc/opt/IDEALX/smbldap-tools/smbldap-tools.pem"
         93 
         94 # key certificate to use to connect to the ldap server
         95 # see "man Net::LDAP" in start_tls section for more details
         96 clientkey="/etc/opt/IDEALX/smbldap-tools/smbldap-tools.key"
         97 
         98 # LDAP Suffix
         99 # Ex: suffix=dc=IDEALX,dc=ORG
        100 suffix="dc=max,dc=planck"
        101 
        102 # Where are stored Users
        103 # Ex: usersdn="ou=Users,dc=IDEALX,dc=ORG"
        104 # Warning: if 'suffix' is not set here, you must set the full dn for usersdn
        105 usersdn="ou=Users,${suffix}"
        106 
        107 # Where are stored Computers
        108 # Ex: computersdn="ou=Computers,dc=IDEALX,dc=ORG"
        109 # Warning: if suffix not set here, you must set the full dn for computersdn
        110 computersdn="ou=Computers,${suffix}"
        111 
        112 # Where are stored Groups
        113 # Ex: groupsdn="ou=Groups,dc=IDEALX,dc=ORG"
        114 # Warning: if 'suffix' is not set here, you must set the full dn for groupsdn
        115 groupsdn="ou=Groups,${suffix}"
        116 
        117 # Where are stored Idmap entries (used if samba is a domain member server)
        118 # Ex: groupsdn="ou=Idmap,dc=IDEALX,dc=ORG"
        119 # Warning: if 'suffix' is not set here, you must set the full dn for idmapdn
        120 idmapdn="ou=Idmap,${suffix}"
        121 
        122 # Where to store next uidNumber and gidNumber available for new users groups
        123 # If not defined, entries are stored in sambaDomainName object.
        124 # Ex: sambaUnixIdPooldn="sambaDomainName=${sambaDomain},${suffix}"
        125 # Ex: sambaUnixIdPooldn="cn=NextFreeUnixId,${suffix}"
        126 sambaUnixIdPooldn="sambaDomainName=${sambaDomain},${suffix}"
        127 
        128 # Default scope Used
        129 scope="sub"
        130 
        131 # Unix password encryption (CRYPT, MD5, SMD5, SSHA, SHA, CLEARTEXT)
        132 hash_encrypt="CRYPT"
        133 
        134 # if hash_encrypt is set to CRYPT, you may set a salt format.
        135 # default is "%s", but many systems will generate MD5 hashed
        136 # passwords if you use "$1$%.8s". This parameter is optional!
        137 crypt_salt_format="%s"
        138 
        139 #############################################################################
        140 # 
        141 # Unix Accounts Configuration
        142 # 
        143 #############################################################################
        144 
        145 # Login defs
        146 # Default Login Shell
        147 # Ex: userLoginShell="/bin/bash"
        148 userLoginShell="/bin/bash"
        149 
        150 # Home directory
        151 # Ex: userHome="/home/%U"
        152 userHome="/home/%U"
        153 
        154 # Default mode used for user homeDirectory
        155 userHomeDirectoryMode="700"
        156 
        157 # Gecos
        158 userGecos="System User"
        159 
        160 # Default User (POSIX and Samba) GID
        161 defaultUserGid="513"
        162 
        163 # Default Computer (Samba) GID
        164 defaultComputerGid="515"
        165 
        166 # Skel dir
        167 skeletonDir="/etc/skel"
        168 
        169 # Default password validation time (time in days) Comment the next line if
        170 # you don't want password to be enable for defaultMaxPasswordAge days (be
        171 # careful to the sambaPwdMustChange attribute's value)
        172 #defaultMaxPasswordAge="45"
        173 
        174 #############################################################################
        175 #
        176 # SAMBA Configuration
        177 #
        178 #############################################################################
        179 
        180 # The UNC path to home drives location (%U username substitution)
        181 # Just set it to a null string if you want to use the smb.conf 'logon home'
        182 # directive and/or disable roaming profiles
        183 # Ex: userSmbHome="\\PDC-SMB3\%U"
        184 userSmbHome="\\PDC-SRV\%U"
        185 
        186 # The UNC path to profiles locations (%U username substitution)
        187 # Just set it to a null string if you want to use the smb.conf 'logon path'
        188 # directive and/or disable roaming profiles
        189 # Ex: userProfile="\\PDC-SMB3\profiles\%U"
        190 userProfile="\\PDC-SRV\profiles\%U"
        191 
        192 # The default Home Drive Letter mapping
        193 # (will be automatically mapped at logon time if home directory exist)
        194 # Ex: userHomeDrive="H:"
        195 userHomeDrive="H:"
        196 
        197 # The default user netlogon script name (%U username substitution)
        198 # if not used, will be automatically username.cmd
        199 # make sure script file is edited under dos
        200 # Ex: userScript="startup.cmd" # make sure script file is edited under dos
        201 userScript="logon.bat"
        202 
        203 # Domain appended to the users "mail"-attribute
        204 # when smbldap-useradd -M is used
        205 # Ex: mailDomain="idealx.com"
        206 mailDomain="max.planck"
        207 
        208 #############################################################################
        209 #
        210 # SMBLDAP-TOOLS Configuration (default are ok for a RedHat)
        211 #
        212 #############################################################################
        213 
        214 # Allows not to use smbpasswd (if with_smbpasswd == 0 in smbldap_conf.pm) but
        215 # prefer Crypt::SmbHash library
        216 with_smbpasswd="0"
        217 smbpasswd="/usr/bin/smbpasswd"
        218 
        219 # Allows not to use slappasswd (if with_slappasswd == 0 in smbldap_conf.pm)
        220 # but prefer Crypt:: libraries
        221 with_slappasswd="0"
        222 slappasswd="/usr/sbin/slappasswd"
        223 
        224 # comment out the following line to get rid of the default banner
        225 # no_banner="1"
    

    i parametro più importanti sono il SID (Security IDentifier), l'indirizzo del servente OpenLDAP, la radice dell'albero, l'uso di TLS, il metodo di cifratura delle parole d'ordine.

    Per ottenere il SID bisogna eseguire il seguente comando sulla macchina in cui è attivo il servente Samba:

    net getlocalsid

    si noti che l'uso di TLS è disattivato (riga 80), che il metodo di cifratura è crypt (riga 132), che l'unità organizzativa cui appartengono gli utenti è Users (riga 105) e non People come negli esempi precedenti; importante è anche la riga 126 in cui si stabilisce in quale DN memorizzare i contatori uid e gid da usare quando si creano nuovi utenti;

  3. modificare il file smbldap_bind.conf inserendo il DN dell'amministratore e la relativa parola d'ordine;

  4. sistemare i permessi dei file di configurazione:

    chmod 0644 /etc/smbldap-tools/smbldap.conf

    chmod 0600 /etc/smbldap-tools/smbldap_bind.conf

A questo punto occorre differenziare le operazioni da svolgere in base al fatto che sia utilizzato il vecchio metodo di configurazione basato sul file /etc/ldap/slapd.conf oppure la cn=config configuration.

9.4.1.1   Configurazione dell'elenco per Samba con il vecchio metodo

Nel primo caso si procede nel modo seguente:

  1. copiare lo schema di elenco per Samba con il comando:

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

  2. aggiungere nel file /etc/ldap/slapd.conf, tra le direttive globali, la riga:

    include     /etc/ldap/schema/samba.schema
    
  3. per ottimizzare gli accessi ai dati in elenco da parte di Samba si possono inserire le righe seguenti fra le direttive della base di dati in /etc/ldap/slapd.conf:

    index    uid,uidNumber,gidNumber,memberUid eq
    index    cn,mail,surname,givenname         eq,subinitial
    index    sambaSID                          eq
    index    sambaPrimaryGroupSID              eq
    index    sambaDomainName                   eq
    
  4. per permettere agli utenti di cambiare la loro parola d'ordine NT e LM (Lan Manager) si può cambiare, sempre nello stesso file, la riga:

    access to attrs=userPassword,shadowLastChange
    

    in:

    access to attrs=userPassword,shadowLastChange,sambaNTPassword,sambaLMPassword
    
  5. eseguire solo la prima delle tre operazioni elencate nel paragrafo 9.2.2 (quella che riguarda l'inserimento della radice dell'elenco, del tipo di archivio ecc.);

  6. posizionarsi nella directory /etc/ldap e convertire il file di configurazione con il comando seguente:

    slaptest -f slapd.conf -F slapd.d

9.4.1.2   Configurazione dell'elenco per Samba con il nuovo metodo

Per definire e usare lo schema per Samba con il nuovo metodo di configurazione occorre prima trasformare la sua definizione nel formato LDIF e poi inserirlo nell'elenco.

I passi da compiere sono:

  1. copiare lo schema di elenco per Samba con il comando:

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

  2. creare il file schema_convert.conf (il nome può essere anche diverso) contenente:

    include /etc/ldap/schema/core.schema
    include /etc/ldap/schema/collective.schema
    include /etc/ldap/schema/corba.schema
    include /etc/ldap/schema/cosine.schema
    include /etc/ldap/schema/duaconf.schema
    include /etc/ldap/schema/dyngroup.schema
    include /etc/ldap/schema/inetorgperson.schema
    include /etc/ldap/schema/java.schema
    include /etc/ldap/schema/misc.schema
    include /etc/ldap/schema/nis.schema
    include /etc/ldap/schema/openldap.schema
    include /etc/ldap/schema/ppolicy.schema
    include /etc/ldap/schema/samba.schema
    
  3. creare una directory temporanea di lavoro:

    mkdir /tmp/ldif_output

  4. convertire i dati dello schema con il comando:

    slapcat -f schema_convert.conf -F /tmp/ldif_output -n0\
      \-s "cn={12}samba,cn=schema,cn=config" > /tmp/cn=samba.ldif

  5. nel file generato /tmp/cn\=samba.ldif togliere dalle prime righe «{12}» in modo da ottenere:

    dn: cn=samba,cn=schema,cn=config
    ...
    cn: samba
    
  6. e togliere le righe seguenti dal fondo del file:

    structuralObjectClass: olcSchemaConfig
    entryUUID: b53b75ca-083f-102d-9fff-2f64fd123c95
    creatorsName: cn=config
    createTimestamp: 20080827045234Z
    entryCSN: 20080827045234.341425Z#000000#000#000000
    modifiersName: cn=config
    modifyTimestamp: 20080827045234Z
    
  7. infine aggiungere lo schema all'elenco con il comando:

    ldapadd -Y EXTERNAL -H ldapi:/// -f /tmp/cn\=samba.ldif

  8. creare un nuovo file samba_indexes.ldif con:

    dn: olcDatabase={1}hdb,cn=config
    changetype: modify
    add: olcDbIndex
    olcDbIndex: uidNumber eq
    olcDbIndex: gidNumber eq
    olcDbIndex: loginShell eq
    olcDbIndex: memberUid eq,pres,sub
    olcDbIndex: uniqueMember eq,pres
    olcDbIndex: sambaSID eq
    olcDbIndex: sambaPrimaryGroupSID eq
    olcDbIndex: sambaGroupType eq
    olcDbIndex: sambaSIDList eq
    olcDbIndex: sambaDomainName eq
    olcDbIndex: default sub
    
  9. caricare gli indici definiti in questo file con il comando:

    ldapmodify -Y EXTERNAL -H ldapi:/// -f samba_indexes.ldif

9.4.2   Popolare l'elenco per Samba

A questo punto si fa ripartire il servente OpenLDAP e si può popolare l'elenco eseguendo il comando:

smbldap-populate -a admin

Vengono inseriti tutti gli oggetti di base per il funzionamento di Samba con backend OpenLDAP e al termine viene richiesto di inserire la password per l'amministratore dell'elenco.

9.4.3   Configurazione di Samba

Vediamo ora le modifiche da apportare al file /etc/samba/smb.conf affinché il servente Samba funzioni in associazione a OpenLDAP.

Ovviamente si danno per acquisite tutte le configurazioni utili al funzionamento di Samba comprese quelle per la funzionalità di PDC illustrate nel capitolo 6.

Tutte le righe prese in esame fanno parte della sezione global del file di configurazione.

Prima di tutto si configura l'archivio degli utenti intervenendo sulla direttiva passdb backend:

   passdb backend = ldapsam:ldap://127.0.0.1/

Quindi si impostano le opzioni relative all'elenco:

   ldap admin dn = cn=admin,dc=max,dc=planck
   ldap suffix = dc=max, dc=planck
   ldap group suffix = ou=Groups
   ldap user suffix = ou=Users
   ldap machine suffix = ou=Computers
   ldap idmap suffix = ou=Users
   ldap ssl = no

Altre impostazioni riguardano la possibilità di cambiare la parola d'ordine e di amministrare utenti e gruppi da MS-Windows e fanno uso di alcuni dei programmi del pacchetto smbldap-tools:

   ldap passwd sync = Yes
   passwd program = /usr/sbin/smbldap-passwd %u
   passwd chat = *New*password* %n\n *Retype*new*password*\
  \%n\n *all*authentication*tokens*updated* add user script = /usr/sbin/smbldap-useradd -m "%u" ldap delete dn = Yes delete user script = /usr/sbin/smbldap-userdel "%u" add machine script = /usr/sbin/smbldap-useradd -w "%u" add group script = /usr/sbin/smbldap-groupadd -p "%g" delete group script = /usr/sbin/smbldap-groupdel "%g" add user to group script = /usr/sbin/smbldap-groupmod -m "%u" "%g" delete user from group script = /usr/sbin/smbldap-groupmod -x "%u" "%g" set primary group script = /usr/sbin/smbldap-usermod -g "%g" "%u"

Dopo avere controllato con testparm che non ci siano errori si aggiunge la parola d'ordine dell'amministratore di Samba con il comando:

smbpasswd -w psw_di_admin

e si fa ripartire il servente.

9.4.4   Inserimento degli utenti nell'elenco

Rimangono da inserire gli utenti (compresi gli utenti speciali corrispondenti alla macchine) per i quali si possono creare dei file LDIF in modo analogo a quanto mostrato in precedenza.

Se però, vogliamo partire da un archivio utenti GNU/Linux già esistente, possiamo migrarlo usando dei programmi Perl forniti con il pacchetto smbldap-tools.

Rendiamo tali programmi disponibili per l'esecuzione con i comandi:

zcat /usr/share/doc/smbldap-tools/examples/migration_scripts/\
  \smbldap-migrate-unix-accounts.gz > /usr/bin/smbldap-migrate-unix-accounts

zcat /usr/share/doc/smbldap-tools/examples/migration_scripts/\
  \smbldap-migrate-unix-groups.gz > /usr/bin/smbldap-migrate-unix-groups

chmod 755 /usr/bin/smbldap-migrate-unix-*

Copiamo poi i file /etc/passwd, /etc/shadow e /etc/group in /tmp/ e togliamo dai file copiati le righe relative a utenti e gruppi di sistema; saranno questi file, così «depurati» a costituire l'input per la migrazione.

Per inserire utenti e gruppi nell'elenco eseguiamo (con il servente OpenLDAP attivo):

smbldap-migrate-unix-groups -a -G /tmp/group

smbldap-migrate-unix-accounts -a -P /tmp/passwd\
  \-S /tmp/shadow

dopodiché si possono eliminare utenti e gruppi migrati dai file /etc/passwd, /etc/shadow e /etc/group.

A questo punto non rimane che definire la parola d'ordine degli utenti con il comando:

smbldap-passwd nome_utente

In verità la parola d'ordine per GNU/Linux sarebbe già definita (migrata da /etc/shadow) ma manca quella per MS-Windows; il comando le ridefinisce entrambe (si può anche definire solo la parola d'ordine per GNU/Linux o solo quella per MS-Windows usando l'opzione -s o l'opzione-u ).

Ecco una parte della risposta al comando slapcat riguardante l'utente e il gruppo verdimarco dopo la migrazione e la definizione della parola d'ordine:

dn: uid=verdimarco,ou=Users,dc=max,dc=planck
objectClass: posixAccount
objectClass: inetOrgPerson
objectClass: shadowAccount
objectClass: sambaSamAccount
uid: verdimarco
cn: Verdi Marco
sn: Marco
uidNumber: 1002
gidNumber: 1002
gecos: Verdi Marco,,,
homeDirectory: /home/verdimarco
loginShell: /bin/bash
shadowLastChange: 13390
shadowMax: 99999
shadowWarning: 7
sambaSID: S-1-5-21-4251291460-501516116-4086100184-3004
structuralObjectClass: inetOrgPerson
entryUUID: aa0935aa-cc48-102a-880c-4b28893bdc7f
creatorsName: cn=admin,dc=max,dc=planck
createTimestamp: 20060830075535Z
sambaLMPassword: F1CDD48D94CE974325AD3B83FA6627C7
sambaNTPassword: 4B56A9FE1BF0C1D8F3BE14D8E86022E3
sambaPwdLastSet: 1156925821
userPassword:: e0NSWVBUfXJJOHY5R3FrOHdRN3c=
sambaAcctFlags: [UX         ]
entryCSN: 20060830083209Z#000000#00#000000
modifiersName: cn=admin,dc=max,dc=planck
modifyTimestamp: 20060830083209Z

dn: cn=verdimarco,ou=Groups,dc=max,dc=planck
objectClass: posixGroup
objectClass: sambaGroupMapping
cn: verdimarco
userPassword:: e2NyeXB0fXg=
gidNumber: 1002
sambaSID: S-1-5-21-4251291460-501516116-4086100184-3005
sambaGroupType: 2
structuralObjectClass: posixGroup
entryUUID: 4a780ca4-cc4f-102a-880f-4b28893bdc7f
creatorsName: cn=admin,dc=max,dc=planck
createTimestamp: 20060830084302Z
entryCSN: 20060830084302Z#000002#00#000000
modifiersName: cn=admin,dc=max,dc=planck
modifyTimestamp: 20060830084302Z

Per gestire gli utenti dell'elenco OpenLDAP per Samba si possono usare i comandi del pacchetto smbldap-tools come smbldap-groupadd, smbldap-useradd, smbldap-userdel, il cui ruolo dovrebbe essere chiaro già dal nome.

Ad esempio per inserire in elenco il nuovo utente rossimario, appartenente al gruppo omonimo, e definirne la parola d'ordine si eseguono i comandi:

smbldap-groupadd -a rossimario

smbldap-useradd -a -g rossimario -m rossimario

smbldap-passwd rossimario

L'opzione -a nel primo comando provoca la creazione di un SID per quel gruppo; nel secondo comando invece fa si che quell'utente abbia anche un account Samba oltre che GNU/Linux.

L'opzione -g serve ad assegnare l'utente al gruppo indicato, mentre -m permette la creazione automatica della sua directory personale.

Se invece si devono inserire in elenco delle utenze per macchina (cosa essenziale se abbiamo come clienti delle workstation MS-Windows NT o XP) dobbiamo eseguire:

smbldap-useradd -w nome_utenza

dove -w significa appunto che si tratta di una utenza di tipo macchina.

9.4.5   Uso del servente

Arrivati a questo punto si può provare a utilizzare il nostro servente Samba con backend OpenLDAP sia da clienti GNU/Linux configurati come illustrato nel paragrafo 9.3.1, sia da clienti MS-Windows configurati come spiegato nel capitolo 6.

A tale proposito si noti che, per unire le workstation MS-Windows al dominio gestito da Samba, viene richiesto di accreditarsi (durante il processo di unione effettuato sulla workstation) con un utente Samba con sufficienti privilegi: si può utilizzare a tale scopo l'utente admin.

Nella figura 9.55 si vede il risultato di un tentativo di accreditamento su un cliente GNU/Linux da parte dell'utente verdimarco:

Figura 9.55.

figure/samba-figura-9.e

In figura 9.56 invece c'è una prova di collegamento alla risorsa condivisa tmp del servente Samba (il cui nome è plancknew) effettuata con lo strumento smbclient e atta a verificare la validità dello stesso utente anche come account Samba.

Figura 9.56.

figure/samba-figura-9.f

9.4.6   Interfacce grafiche per Samba-OpenLDAP

Un cliente grafico per gestire gli utenti di Samba con backend OpenLDAP è ldap account manager (4) (<http://lam.sourceforge.net/>).

Si tratta di uno strumento, scritto in PHP, che fornisce un'interfaccia Web per la gestione dei dati dell'elenco.

Una volta installato e configurato (per i dettagli si rimanda alla documentazione del pacchetto) si accede all'interfaccia collegandosi all'indirizzo https://localhost/lam e si ottiene la schermata di accreditamento (vedi figura 9.57).

Figura 9.57.

figure/samba-figura-9.g

Nella figura 9.58 è invece mostrato il modulo di gestione dei dati di un utente dell'elenco.

Figura 9.58.

figure/samba-figura-9.h

9.5   Usare OpenLDAP con SSL

Fino a questo momento è stato illustrato l'uso di un servente OpenLDAP con comunicazione in chiaro tra quest'ultimo e i clienti.

Questa soluzione comporta ovviamente il rischio che le parole d'ordine degli utenti cadano in mano a persone non autorizzate e tale rischio è presente anche se il servizio è utilizzato solo in un contesto di rete locale.

Per ridurre ai minimi termini tale rischio di può cifrare la comunicazione con il servente OpenLDAP usando OpenSSL.

9.5.1   Natura del pacchetto OpenSSL

OpenSSL (5) (<http://www.openssl.org>) permette l'utilizzo dei protocolli SSL (Secure Socket Layer) e TLS (Transport Layer Security).

SSL è stato sviluppato dalla Netscape ed è divenuto lo strumento universalmente accettato per l'autenticazione e la cifratura della comunicazione tra clienti e serventi in rete.

TLS è l'evoluzione di SSL ma la natura del protocollo non è cambiata di molto; in questo paragrafo si fa riferimento unicamente a SSL considerando il fatto che il livello di sicurezza ottenibile è del tutto analogo e che nell'uso assieme a OpenLDAP l'unica differenza visibile è nel fatto che se si usa TSL il servizio continua a rispondere sulla porta 389 mentre con SSL risponde sulla porta 636.

SSL si colloca nella pila dei protocolli TCP/IP tra il livello di trasporto e il livello applicazione e viene usato per rendere sicuri i servizi che utilizzano TCP; l'utilizzo più comune e noto anche al «grande pubblico» è quello che permette di rendere sicuro il protocollo HTTP e quindi le connessioni con i serventi Web (protocollo HTTPS).

SSL utilizza un algoritmo a chiave privata per cifrare la comunicazione tra due nodi di rete; la chiave privata viene invece trasmessa in modo sicuro grazie a un algoritmo a chiave pubblica.

9.5.2   Creazione della CA e del certificato con OpenSSL

In questo paragrafo non vengono forniti tutti i dettagli riguardanti la configurazione di OpenSSL tramite il file /etc/ssl/openssl.cnf, l'uso del comando openssl e l'uso degli strumenti per la creazione e firma dei certificati disponibili in /usr/lib/ssl/misc/; viene solo mostrato quanto indispensabile per la creazione di certificati e chiavi per rendere sicura la comunicazione con il servente OpenLDAP.

Una volta installato il pacchetto OpenSSL con il comando:

apt-get install openssl

occorre definire un certificato valido per il servente e quindi creare una CA (Certification Authority) che possa firmare tale certificato.

Questa CA non è evidentemente una di quelle globalmente riconosciute in rete e autorizzate alla diffusione dei certificati, ma solo una CA «personale».

Prima di definire il certificato possiamo impostare la durata dello stesso ad un periodo più lungo di quello impostato per difetto (1 anno); questo si fa modificando nello script /usr/lib/ssl/misc/CA.sh la seguente riga:

$DAYS="-days 365";

sostituendo il valore 365 ad esempio con 1825 (5 anni).

Creiamo poi una directory utile ad accogliere tutti i file contenenti certificati e chiavi che ci accingiamo a definire e posizioniamoci in essa (tale posizionamento rimane in essere per tutti i comandi di questo paragrafo):

mkdir /etc/ssl/ca

cd /etc/ssl/ca

Quindi generiamo la nostra CA con il comando:

/usr/lib/ssl/misc/CA.sh -newca

Vengono richiesti il nome di un certificato (invio per definirne uno nuovo); e i dati relativi alla propria organizzazione che verranno inseriti nel certificato stesso.

Nella figura 9.60 viene mostrata questa fase di lavoro con delle risposte relative ad una organizzazione di tipo scolastico (l'ITIS «Max Planck» di Treviso dove insegno).

Figura 9.60.

figure/samba-figura-9.i

Importantissima è la risposta alla domanda riguardante il common name: occorre indicare il FQDN Fully Qualified Domain Name della macchina che ospita il servente (nell'esempio serlinux3.max.planck).

Sono invece opzionali e possono essere omesse le informazioni challenge password e company name.

Prestare anche particolare attenzione, all'inizio, alla definizione della pass phrase da associare al certificato della CA e che viene poi chiesta ogni volta che si fanno operazioni con il certificato o che se ne richiede l'uso (ad esempio al termine di questa procedura come si vede nella figura).

Nella figura 9.61 viene mostrato come si conclude il procedimento con la stampa a video dei dati del certificato; quest'ultimo con la relativa chiave pubblica viene memorizzato nel file /etc/ssl/ca/demoCA/cacert.pem mentre la chiave privata della CA nel file /etc/ssl/ca/demoCA/private/cakey.pem.

Figura 9.61.

figure/samba-figura-9.j

Il passo successivo consiste nella generazione del certificato di richiesta e della chiave privata per il servente, da compiere con il comando:

openssl req -new -nodes -keyout newreq.pem -out newreq.pem

Si ricevono le richieste di inserimento informazioni analoghe alle precedenti (figura 9.60 ma solo fino alla richiesta relativa al optional company name).

Attenzione al fatto che il common name deve essere lo stesso FQDN inserito in sede di creazione del certificato della CA personale.

Il certificato di richiesta e la chiave privata vengono memorizzate nel file /etc/ssl/ca/newreq.pem.

Si può controllare la richiesta con il comando:

openssl req -text -noout < newreq.pem

A questo punto serve la firma della CA sul certificato di richiesta in modo da avere un certificato valido; la si ottiene con il comando:

/usr/lib/ssl/misc/CA.sh -sign

Nella figura 9.62 vediamo l'effetto di tale comando con la richiesta della pass phrase relativa alla CA definita in precedenza e le richieste di conferma della firma e di memorizzazione del certificato.

Figura 9.62.

figure/samba-figura-9.k

Il procedimento si conclude con l'emissione a video dei dati del certificato e della chiave pubblica che vengono memorizzati nel file /etc/ssl/ca/newcert.pem.

9.5.3   Configurazione del servente OpenLDAP per l'uso con OpenSSL

Conclusa la creazione del certificato e della chiave del servente spostiamo i relativi file nella directory di configurazione di OpenLDAP cambiando loro anche il nome:

cp /etc/ssl/ca/demoCA/cacert.pem /etc/ldap/cacert.pem

cp /etc/ssl/ca/newcert.pem /etc/ldap/servercrt.pem

cp /etc/ssl/ca/newreq.pem /etc/ldap/serverkey.pem

Proteggiamo poi da accessi indesiderati il file contenente la chiave privata rendendolo contemporaneamente leggibile al gruppo openldap (si tenga presente infatti che il demone slapd viene eseguito con i diritti di utente e gruppo openldap):

chown root:openldap /etc/ldap/serverkey.pem

chmod 640 /etc/ldap/serverkey.pem

Per configurare OpenLDAP per l'uso di SSL bisogna fare in modo che il servente sia in ascolto sia sulla porta 389 che sulla porta 636 che è quella dedicata al traffico cifrato; a tale scopo interveniamo nel file /etc/default/slapd e attiviamo la riga:

SLAPD_SERVICES="ldap://127.0.0.1:389/ ldaps://serlinux3.max.planck/"

Occorre poi intervenire sulla configurazione del servente, distinguendo, come al solito tra le vecchie versioni di OpenLDAP e quelle nuove (a partire dalla 2.3).

Nel primo caso si devono aggiungere le seguenti righe nel file /etc/ldap/slapd.conf tra le direttive globali:

TLSCACertificateFile /etc/ldap/cacert.pem
TLSCertificateFile /etc/ldap/servercrt.pem
TLSCertificateKeyFile /etc/ldap/serverkey.pem

Nel secondo caso si deve eseguire il comando:

ldapmodify -Y EXTERNAL -H ldapi:///

con il quale si entra nella console del comando ldapmodify e si digita quanto segue:

dn: cn=config
add: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/ldap/cacert.pem
-
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ldap/servercrt.pem
-
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ldap/serverkey.pem

Al termine, dopo un ulteriore pressione del tasto [Invio], si ottiene il messaggio «modifying entry cn=config» e si può uscire premendo [Ctrl c].

Infine, in entrambi i casi presi in esame, facciamo ripartire il servizio.

9.5.4   Configurazione dei clienti GNU/Linux

Il primo file che prendiamo in considerazione sulle macchine clienti (fra le quali, come al solito, possiamo considerare anche lo stesso servente) è /etc/ldap/ldap.conf (o /etc/ldap.conf) per fare in modo che i programmi lato cliente LDAP come ad esempio quelli del pacchetto ldap-utils dialoghino con il servizio sul canale cifrato:

BASE    dc=max,dc=planck
URI     ldaps://serlinux3.max.planck
TLS_REQCERT allow

Si noti l'attivazione delle interrogazioni usando il protocollo sicuro LDAPS con indicazione del FQDN della macchina servente, che deve essere lo stesso usato nella definizione dei certificati.

Inoltre è importante la direttiva TLS_REQCERT allow che fa in modo che il cliente possa richiedere il certificato della CA al servente evitando di doverne possedere una copia in locale.

Ricordarsi infine di far ripartire il demone nscd.

Per testare il buon esito delle modifiche eseguire qualche ricerca con ldapsearch sia usando il canale in chiaro:

ldapsearch -x -b dc=max,dc=planck -H 'ldap://serlinux3.max.planck'

che quello cifrato:

ldapsearch -x -b dc=max,dc=planck -H 'ldaps://serlinux3.max.planck'

Inoltre verificare che gli utenti gestiti dal servente siano ancora raggiungibili dal servizio NSS con il comando:

getent passwd

9.5.5   Uso di Samba e OpenLDAP su canale cifrato

Se si vuole che anche il traffico tra i serventi Samba e OpenLDAP avvenga con l'uso di SSL occorre apportare delle modifiche ai file di configurazione di Samba e del pacchetto smbldap-tools.

Notiamo che questo è necessario solo se i due serventi sono in esecuzione su due macchine diverse altrimenti si tratta di una precauzione esagerata.

In tal caso infatti si può considerare una protezione ragionevole quella ottenibile configurando il servizio in modo che sia in ascolto sulla porta 389 (canale in chiaro, da usare per Samba) e sulla porta 636 (canale cifrato, da usare per i clienti GNU/Linux), come visto nel paragrafo 9.5.3.

Si deve infatti tenere presente che la comunicazione tra i clienti MS-Windows e il servente Samba non avviene in chiaro a meno che non si usino macchine equipaggiate con MS-Windows 95.

In /etc/samba/smb.conf bisogna aggiungere la riga:

ldap-ssl = on

e cambiare quella relativa al backend degli utenti in:

passdb backend = ldapsam:ldaps://serlinux3.max.planck/

In /etc/smbldap-tools/smbldap.conf bisogna attivare l'uso dei certificati variando o attivando le righe seguenti:

slaveLDAP="ldaps://serlinux3.max.planck"
slavePort="636"
masterLDAP="ldaps://serlinux3.max.planck"
masterPort="636"
ldapTLS="1"
verify="require"
# CA certificate
cafile="/etc/ldap/cacert.pem"
# certificate to use to connect to the ldap server
clientcert="/etc/ldap/servercrt.pem"
# key certificate to use to connect to the ldap server
clientkey="/etc/ldap/serverkey.pem"

Inoltre è bene fare in modo che il servente OpenLDAP sia in ascolto solo sulla porta 636 (nel contesto «ipersicuro» che stiamo definendo la 389 non serve più) e quindi variamo la riga SLAPD_SERVICES di /etc/default/slapd in modo che diventi:

SLAPD_SERVICES="ldaps://serlinux3.max.planck/"

Infine riavviamo i servizi Samba e OpenLDAP.


1) OpenLDAP   OpenLDAP License, 2.3

2) gq   GNU GPL

3) webmin   3-clause BSD-style license

4) ldap account manager   GNU GPL

5) OpenSSL   OpenSSL license