Fare riferimento a http://wiki.infn.it/cn/ccr/aai/howto/389ds-1.x-install

NOTA BENE Gli esempi citati in questa guida si intendono per 389 Directory Server 1.x su Scientific Linux 5.x.

In caso di installazione con diverse versioni alcuni path o nomi dei pacchetti potrebbero differire.

E’ inoltre vivamente consigliato che IP address, IP Name e Hostname della macchina siano coerenti.

Modificare i parametri kernel in /etc/sysctl.conf:

echo "fs.file-max = 128000" >> /etc/sysctl.conf
echo "net.ipv4.ip_local_port_range = 1024 65000" >> /etc/sysctl.conf
echo "net.ipv4.tcp_keepalive_time = 300" >> /etc/sysctl.conf

Ricaricare sysctl:

sysctl -p

Modificare i limits in /etc/security/limits.conf inserendo la linea:

echo "* soft nofile 8192" >> /etc/security/limits.conf      
echo "* hard nofile 8192" >> /etc/security/limits.conf
echo "ulimit -n 8192" >> /etc/profile

Effettuare log-out e log-in in modo da ricaricare i limits.

Solo per macchine 64bit, eliminare le librerie SASL a 32bit. In questa fase potrebbe essere richiesto di eliminare come dipendenza molti pacchetti, si consiglia di accettare ed eliminarli. Sono solo delle copie con librerie a 32bit di software che rimarrà comunque nella versione a 64bit.

yum remove cyrus-sasl.i386 cyrus-sasl-devel.i386 cyrus-sasl-gssapi.i386 cyrus-sasl-plain.i386 cyrus-sasl-lib.i386

Installazione del client LDAP standard di Linux:

yum install openldap-clients

Impostare i repository YUM EPEL (https://fedoraproject.org/wiki/EPEL).

rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-3.noarch.rpm

Installare 389-ds:

yum install 389-ds

Creare l’utente ds:

useradd -r -s /bin/false ds

Lanciare il setup di 389-ds

/usr/sbin/setup-ds-admin.pl

Scegliere l’opzione 3 in modo da personalizzare l’installazione:

• Configurare come utente/gruppo "ds";
• Controllare il root suffix;
• Scegliere la porta 1500 per l’Administration Server;
• Tutto il resto può essere lasciato al default.

Attenzione : In questa fase verra' chiesto il nome dell'istanza del DS, di default corrisponde all'hostname senza dominio. Si consiglia di lasciare il default e impostare la variabile DSUID in ~/.bash_profile. Di seguito si farà infatti riferimento a tale valore con $DSUID.

echo 'export DSUID=nome.istanza.ds' >> ~/.bash_profile
source ~/.bash_profile

Impostare la partenza dei servizi di 389-ds al boot

chkconfig dirsrv on
chkconfig dirsrv-admin on

Per migliorare le performance di 389ds incrementare il massimo numero di file descriptor a disposizione del server modificando il file /etc/dirsrv/slapd-$DSUID/dse.ldif e /etc/sysconfig/dirsrv

/etc/init.d/dirsrv stop
sed -i 's/^nsslapd-maxdescriptors: .*$/nsslapd-maxdescriptors: 8192/' /etc/dirsrv/slapd-$DSUID/dse.ldif
sed -i 's/^# *ulimit/ulimit/' /etc/sysconfig/dirsrv
/etc/init.d/dirsrv start

Controllare che il limite "Max open files" sia effettivo:

cat /proc/`pidof ns-slapd`/limits

Da questo momento e' possibile lanciare la console di gestione del Directory Server, attraverso la quale e' possibile fare ogni tipo di configurazione e gestire i dati della Directory.

Per eseguire la console:

389-console -x nologo -a http://localhost:1500/ -u "cn=Directory Manager"

E possibile connettersi all'administration server da remoto installando sul proprio client la Management Console.

L'unico requisito e' la presenza di una JRE. Puo' essere installata tramite yum su linux. Dal sito http://directory.fedoraproject.org/ e' disponibile anche un msi per Windows.

Impostare il Directory Information Tree come segue:

• Nella console nel primo tab "Servers and Applications" espandere l’albero di sinistra, cliccare con il tasto destro su "Directory Server" e scegliere "Open"
• Scegliere il tab "Configuration"

• Sotto "Data" cliccare con il tasto sinistro e poi con il destro sul suffix esistente "dc=dN,dc=example,dc=com" ed eliminarlo

• Cliccare sinistro e poi destro su "Data" e scegliere "New Root Suffix"
• Inserire come new suffix dc=example,dc=com e come database name example-com-root-db

• Cliccare sinistro e poi destro sul suffix dc=example,dc=com (non sul db) e scegliere "New Sub Suffix"
• Inserire come new suffix dc=dN (dove N e' il numero della vostra postazione) e come database name dN-db

• Cliccare sul tab "Directory"
• Cliccare sinistro e poi destro sulla radice dell'albero (fqdn del server)
• Selezionare "New Root Object" → "dc=example,dc=com"
• Scegliere "dcobject" e cliccare OK
• Lasciare i default e cliccare OK

• Cliccare sinistro e poi destro sul nodo "example"
• Selezionare "New" → "Other"
• Scegliere "dcobject" e cliccare OK
• Inserire come "dc", al posto di New: DN (dove N e' il numero della vostra postazione)

Inserire le entry di base nel vostro suffix:

• Cliccare sinistro e poi destro sulla entry appena creata dN e selezionare "New" → "Organizational Unit"
• Inserire come "Name": People

Ripetere gli ultimi due punti inserendo anche Groups

Fermare 389-ds:

/etc/init.d/dirsrv stop

Scaricare gli schema personalizzati INFN-AAI:

cd /etc/dirsrv/slapd-$DSUID/schema
wget -O 97schac.ldif http://wiki.infn.it/_media/cn/ccr/aai/doc/97schac.ldif
wget -O 98infn.ldif http://wiki.infn.it/_media/cn/ccr/aai/doc/98infn.ldif
chown ds:ds 98infn.ldif 97schac.ldif
chmod 440 98infn.ldif 97schac.ldif

Far ripartire 389-ds:

/etc/init.d/dirsrv restart

Per l’esercitazione del tutorial AAI trovate i certificati dei server e della CA in http://www.lnf.infn.it/~dmaselli/share/INFN/AAI/Tutorial/Cert/

Configurare il client ldap di default di linux (openldap) inserendo la chiave pubblica della CA nella directory /etc/openldap/cacerts/ e creare gli hash link eseguendo:

cacertdir_rehash /etc/openldap/cacerts/

Convertire il certificato con chiave privata del server in formato pkcs12 in un file temporaneo. Non è necessario impostare un password.

openssl pkcs12 -export -inkey ds_server_key.pem -in ds_server_crt.pem -out /tmp/crt.p12 -nodes -name 'Server-Cert'

Importare il certificato con chiave privata del server nel DB di 389-ds. E’ necessario impostare una password per il DB e ricordarla. La prima password (più conferma) che viene chiesta è quella del DB di 389-ds, la seconda è invece quella eventualmente impostata nell’export.

cd /etc/dirsrv/slapd-$DSUID
pk12util -i /tmp/crt.p12 -d .
rm /tmp/crt.p12

Creare un il file con la password del DB dei certificati:

cd /etc/dirsrv/slapd-$DSUID
vi pin.txt

Inserire:

Internal (Software) Token:PASSWORD

Impostare i permessi:

chown ds:ds pin.txt
chmod 600 pin.txt

Far partire la console

389-console -x nologo -a http://localhost:1500/ -u "cn=Directory Manager"

Nel primo tab "Servers and Applications" espandere l’albero di sinistra, cliccare con il tasto destro su "Directory Server" e scegliere "Open"

Andare in Console → tab Tasks → Manager Certificates → tab CA Certs Tramite il tasto "Install" installare il certificato della CA.

Andare in Console → tab Configuration → Encryption Abilitare le opzioni "Enable SSL for this server" e "Use this Cipher Family: RSA" Assicurarsi che in Certificate ci sia "Server-Cert", altrimenti uscire e rientrare nella console. Cliccare su "Save" e confermare i messaggi.

Far ripartire 389-ds:

/etc/init.d/dirsrv restart

NOTA: Se si vuole impostare o cambiare la password del DB dei certificati di 389-ds:

cd /etc/dirsrv/slapd-$DSUID
modutil -dbdir . -changepw "NSS Certificate DB"

Per consentire l’autenticazione con certificati x509 è necessario configurare un mapping tra i subject dei certificati e le entry del DS.

Nel file /etc/dirsrv/slapd-$DSUID/certmap.conf troviamo la possibilità di impostare l’attributo del DS in cui 389-ds troverà il subject x509. Le sole righe non commentate dovranno essere:

certmap default         default
default:CmapLdapAttr    infnCertSubjectDN

Far ripartire 389-ds:

/etc/init.d/dirsrv restart

Per configurare l’autenticazione GSSAPI su 389-ds è necessario creare un K5 keytab per il ticket di servizio "ldap":

kadmin: addprinc -randkey ldap/fqdn.ds.server
kadmin: ktadd -k /etc/dirsrv/slapd-$DSUID/keytab ldap/fqdn.ds.server

Posizionato il keytab in /etc/dirsrv/slapd-$DSUID/keytab assicurarsi che solo l’utente ds possa accedervi:

chown ds /etc/dirsrv/slapd-$DSUID/keytab
chmod 400 /etc/dirsrv/slapd-$DSUID/keytab

Aggiungere al file /etc/sysconfig/dirsrv il path al keytab:

echo "KRB5_KTNAME=/etc/dirsrv/slapd-$DSUID/keytab ; export KRB5_KTNAME" >> /etc/sysconfig/dirsrv

Nella Management Console definire i SASL Mapping:

• Nel primo tab "Servers and Applications" espandere l’albero di sinistra e cliccare con il tasto destro su "Directory Server"
• Si aprirà la Management Console
• Cliccare sul tab "Configuration"
• Cliccare sul nome del server a sinistra e a destra scegliere il tab "SASL Mapping"
• Selezionare e cancellare (tasto Delete) le regole esistenti.
• Cliccare Add.

Per configurare in modo che gli utenti con ticket valido vengano mappati nelle entry del DS, creare le seguenti regole:

              Name:  krb5_default_realm
Regular Expression:  ^[^@]+$
    Search Base DN:  dc=example, dc=com
     Search Filter:  (infnKerberosPrincipal=&@DEFAULT.REALM)

Dove DEFAULT.REALM e' il realm di default nel file /etc/krb5.conf (grep default_realm /etc/krb5.conf).

              Name:  krb5_other_realm
Regular Expression:  ^.+@.+$
    Search Base DN:  dc=example, dc=com
     Search Filter:  (infnKerberosPrincipal=&)

Far ripartire 389-ds.

/etc/init.d/dirsrv restart

Per compilare e configurare il plugin Kerberos5 per 389-ds eseguire le seguenti operazioni:

Installare il compilatore, i sorgenti di Kerberos e di openldap:

yum install gcc krb5-devel openldap-devel

• ottenere il codice sorgente krb5-plugin-20100518.tgz
• decomprimere ed estrarre i file
• nella directory krb5-plugin eseguire il comando make
• copiare la shared library libkrb5-plugin.so nella directory /usr/lib64/dirsrv/plugins/
• dopo essersi assicurati che il Directory Service non sia attivo editare il file /etc/dirsrv/slapd-$DSUID/dse.ldif aggiungendo:

  dn: cn=KRB5 Bind,cn=plugins,cn=config
  objectClass: top
  objectClass: nsSlapdPlugin
  objectClass: extensibleObject
  cn: KRB5 Bind
  nsslapd-pluginPath: /usr/lib64/dirsrv/plugins/libkrb5-plugin.so
  nsslapd-pluginInitfunc: krb5plugin_init
  nsslapd-pluginType: preoperation
  nsslapd-pluginEnabled: on
  nsslapd-plugin-depends-on-type: database
  nsslapd-pluginId: krb5-bind
  nsslapd-pluginVersion: 1.0.4
  nsslapd-pluginVendor: Fedora Project
  nsslapd-pluginDescription: Kerberos 5 bind pre-operation plugin (INFN)

Ricordarsi che l'ultima linea del file dse.ldif deve essere vuota.

• far ripartire il Directory Service

Affinche' il plugin crei il principal specificato in infnKerberosPrincipal in fase di bind e aggiorni la chiave Kerberos qualora venga cambiato l'attributo LDAP userPassword e' necessario per ogni REALM creare la keytable

/etc/dirsrv/kadmin.keys/kadmin-REALM.keytab

contenente il principal di servizio 389/admin@REALM. Tale file deve essere leggibile dall'utente ds.

I messaggi di debug vengono loggati in /var/log/dirsrv/slapd-$DSUID/errors.

Si configurera' una replica Master-Slave, con slave Read-Only con autenticazione tramite certificato x509.

Per prima cosa e' necessario creare una entry che rappresenti il supplier che si autentichera' verso il consumer.

E' necessario che la entry venga creata sutto un suffix il cui DB non sia oggetto della replica in questione, e' consigliato utilizzare il suffix cn=config.

1. Aprire la console, nella configurazione del Directory Server
2. Posizionarsi nel tab "Directory"
3. Click destro su "cn=config" e scegliere New → Other
4. Selezionare l'ObjectClass "infnHost"
5. Impostare come come "Full Name" (attributo "cn") il FQDN del supplier
6. Cliccare "Add Atribute"
7. Scegliere l'attributo infnCertSubjectDN
8. Nel un nuovo attributo inserire il subject del certificato del supplier. Utilizzare la forma "Distinguished Name", inversa rispetto alla notazione x509-Subject, ad esempio "CN=kdc.example.com, OU=Host, O=INFN, C=IT" e NON "/C=IT/O=INFN/OU=Host/CN=kdc.example.com"

Per configurare la Replica:

1. Posizionarsi sul tab "Configuration"
2. Espandere la cartella "Replication"
3. Cliccare sul DB che conterra' le informazioni provenienti dal supplier
4. Sulla destra abilitare "Enable Replica"
5. Selezionare "Dedicated Consumer"
6. Inserire il "Supplier DN" del tipo "cn=ds-1.example.com, cn=config" e premere "Add"
7. Salvare la configurazione (tasto "Save")

A questo punto il server e' pronto per ricevere gli aggiornamenti dal supplier specificato.

Configurare la Replica:

1. Posizionarsi sul tab "Configuration"
2. Cliccare su "Replication"
3. Abilitare "Enable Changelog" e impostare il path con "Use default"
4. Salvare la configurazione (tasto "Save")
5. Espandere la cartella "Replication"
6. Cliccare sul DB che conterra' le informazioni che dovranno essere replicate sul consumer
7. Sulla destra abilitare "Enable Replica"
8. Selezionare "Single Master"
9. Impostare un "Replica ID", tale id dovra' essere univoco tra tutte le master replication
10. Salvare la configurazione (tasto "Save")

Configurare il Replication Agreement:

1. Tasto destro sul nome del DB da relicare verso il consumer
2. Selezionare "New Replication Agreement…"
3. Scegliere un nome univoco per la replica → Next
4. Impostare il consumer cliccando su "Other"
5. Inserire il FQDN del consumer e scegliere la porta 636 (LDAPs)
6. Selezionare "Using encrypted SSL connection" e "SSL client authentication" → Next
7. Lasciare tutto invariato → Next
8. Lasciare tutto invariato → Next
9. Selezionare "Do not initialize consumer" → Next
10. Done

A questo punto sotto il DB apparira' il Replication agreement, ora si dovra' inizializzare il consumer, ovvero lanciare un primo trasferimento per assicurarsi che i dati del consumer siano identici a quelli nel supplier.

1. Tasto destro sul nome del Replication Agreement → Initialize Consumer
2. Controllare sotto "Status" in "Last update message" lo stato dell'inizializzazione.

Da questo momento ogni modifica effettuata sul supplier verra' replicata sul consumer in tempo reale.

La replica Multi-Master e' molto simile alla Master-Slave, ma entrambi i nodi si comporteranno sia da supplier che da consumer.

Su entrambi i nodi si dovra':

1. Creare le entry per l'autenticazione
2. Abilitare il Changelog
3. Configurare il ruolo nella replica nel DB come "Multiple Master"
4. Inserire ID di replica differenti
5. Inserire il Supplier DN corrispondente all'altro server
6. Creare il Replication Agreemente verso l'altro server