slapd[15245]: warning: cannot open /etc/hosts.deny: Too many open files
~~~
Pour l'éviter ajouter dans /etc/default/slapd :
~~~
ulimit -n 8192
~~~
## Configuration
Depuis Debian Squeeze, OpenLDAP stocke directement sa configuration et de son schéma dans l'arborescence *cn=config*.
Notez que si vous êtes un vieux barbu fainéant, il est toujours possible d'utiliser un bon vieux _'slapd.conf_.
Le contenu de cette arborescence est aussi stocké sous forme de fichiers, dans le répertoire _/etc/ldap/slapd.d/_, et ceux-ci sont chargés au démarrage de OpenLDAP.
Selon vos goûts, différentes commandes pour visualiser la configuration:
Note : cette dernière commande fonctionne si l'ACL (_olcAccess_) suivante est positionnée sur l'entrée _olcDatabase={0}config,cn=config_ :
~~~
olcDatabase={0}config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by * break
olcRootDN: cn=admin,cn=config
~~~
### Modifier la configuration
On pourra donc modifier la configuration à chaud via _ldapvi_ ou tout simplement _ldapmodify_ et de superbes fichiers LDIF.
À savoir : lorsqu'on modifie à chaud la configuration, OpenLDAP met alors immédiatement à jour le contenu du fichier correpondant dans _/etc/ldap/slapd.d/_ !
Une autre possibilité est de stopper _slapd_, de modifier les fichiers LDIF dans _/etc/ldap/slapd.d/_ et de le redémarrer.
Attention, cela risque de générer des warnings à propos de checksums sur les fichiers. Pour contourner cela, il faut ré-éditer les entrées à chaud pour
que les dumps soient regénérés avec les bons checksums.
Autre détail important, avant la version 2.5 il n'est pas possible de faire un delete à chaud sur une entrée de _cn=config_ !
Il faut donc utiliser la méthode nécessitant l'arrêt de _slapd_, faire les modifications sur les fichiers LDIF et le relancer.
### Directives
Pour gérer les logs, on utilise la directive _olcLogLevel_ dans l'entrée _cn=config_.
Exemple pour désactiver les logs :
~~~
cn=config
olcLogLevel: 0
~~~
### Gestion des schémas
Autrefois, il suffisait d'un simple _include_ vers un fichier .schema pour ajouter un schéma.
Mais avec la configuration dans _cn=config_, il faut désormais convertir un schéma en LDIF puis l'injecter !
Voici les étapes pour convertir un .schema en .ldif (exemple avec _amavis.schema_) :
1. Créer un fichier _/tmp/convert-to-ldap.conf_ contenant une seule ligne :
adding new entry "cn={4}amavis,cn=schema,cn=config"
~~~
Note : Si besoin, on peut bien sûr convertir plusieurs schémas d'un coup via un fichier _/tmp/convert-to-ldap.conf_ du type :
~~~
include /etc/ldap/schema/core.schema
include /etc/ldap/schema/collective.schema
[...]
include /etc/ldap/schema/monschema2.schema
~~~
### Gestion des ACL
Les ACL s'ajoutent via des règles du type :
~~~
olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymous auth by dn="cn=admin,dc=example,dc=com" write by * none
olcAccess: {1}to dn.base="" by * read
olcAccess: {2}to * by self write by dn="cn=admin,dc=example,dc=com" write by peername.ip="127.0.0.1" read by * none
~~~
/!\ en cas de réplication, bien penser à inclure l'utilisateur de réplication pour les attrs=userPassword,shadowLastChange sous peine
de ne pas avoir de synchronisation des mots de passe !!!
Pour ne pas avoir un annuaire lisible publiquement mais accessible depuis l'extérieur, on peut forcer l'authentification en remplaçant "by peername.ip="127.0.0.1" read" par :
~~~
by users read by anonymous auth
~~~
### Réplication (master->slave)
*Sur le master :*
* Ajouter le module syncprov (dans l'objet cn=module{0},cn=config) :
Suite à cette mise en place, si en tentant de se connecter au serveur apparaît l'erreur `ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)`, il se peut que ça soit dû au certificat non reconnu. Pour désactiver la vérification du certificat, sur le client, ajouter cette ligne dans _/etc/ldap/ldap.conf_ :
~~~
TLS_REQCERT never
~~~
## Utilisation
### ldapvi
_ldapvi_ permet d'éditer un annuaire LDAP avec Vim.
Le fichier _~/.ldaprc_ est utilisé pour les outils inclus dans `ldap-utils` il permet de définir des paramètres particulier.
On peut notamment autoriser les certifications non reconnus :
~~~
tls_reqcert never
~~~
## Backup
Rien de plus simple :
~~~
slapcat -l ldap.bak
~~~
Cela dump l'arbre ldap dans un seul fichier LDIF. Cette sauvegarde n'inclut *pas* cn=config.
Pour sauvegarder la configuration (ACLs, Schema...etc) :
~~~
slapcat -b cn=config -l config.ldif
~~~
## Restauration
~~~
/etc/init.d/slapd stop
rm -rf /var/lib/ldap/*
sudo -u openldap slapadd -l ldap.bak
/etc/init.d/slapd start
~~~
## Infos sur les attributs LDAP
### Attributs pour authentification Windows
*sambaPwdMustChange*: Timestamp Unix, date d'expiration du mot de passe Windows.
*sambaKickoffTime*: Timestamp Unix, date d'expiration du compte Windows.
*sambaPwdLastSet*: Timestamp Unix, dernière fois que le mot de passe a été changé. (Bizarrerie à ce propos...)
### Attributs pour authentification UNIX
'''
shadowExpire''': Durée en nombre de jours depuis le 1° Janvier 1970. Date d'expiration du compte.
*shadowInactive*: Combien de jours il faut accepter un mot de passe qui a expiré.
*shadowWarning*: Nombre de jours avant que le mot de passe expire et où le système va avertir de la proche expiration.
*shadowFlag*: -1 ???
*shadowLastChange*: Durée en nombre de jours depuis le 1° Janvier 1970 de la dernière fois que le mot de passe a été modifié (Ex: 15579 = 27/08/2012).
*shadowMin*: Age minimum en jours avant que l'utilisateur puisse changer son mot de passe. (Défaut à 0 = quand il veut).
*shadowMax*: Durée en jours de la validité du mot de passe. (Ex 365 = 1 an). Pour désactiver l'expiration du mot de passe, affecter la valeur -1.
## FAQ
### could not parse entry
Lors d'ajout/modification d'un annuaire LDAP, si vous obtenez un message de ce type :
~~~
str2entry: invalid value for attributeType objectClass #0 (syntax 1.3.6.1.4.1.1466.115.121.1.38)
slapadd: could not parse entry (line=70)
structuralObjectClass: organizationalRole
~~~
C'est sûrement dû au fait que vos schémas spécifiques ne sont pas pris en compte car _slapd_
utilise la configuration présente dans _/etc/ldap/slapd.d_ si le dossier est présent.
### Insufficient access
~~~
Uncaught exception from user code:
Insufficient access at ./add.pl line 678, <STDIN> line 2.
~~~
Vérifier dans les acl que votre utilisateur a le droit de modifier l'attribut que vous modifier.
### ldif_read_file: checksum error
Si lors d'opérations slapd* (slapcat, etc), vous obtenez des messages du type :
~~~
53af54a7 ldif_read_file: checksum error on "/etc/ldap/slapd.d/cn=config/olcDatabase={-1}frontend.ldif"
53af54a8 ldif_read_file: checksum error on "/etc/ldap/slapd.d/cn=config/olcDatabase={0}config.ldif"
~~~
C'est dû au fait que vous avez modifié "à froid" la configuration dans /etc/ldap/slapd.d/ ; cela ne pose pas de problème si vous le faites bien lorsque _slapd_ est arrêté, mais cela génère ces warnings. En effet, lorsqu'une entrée est modifiée "à chaud" (via ldapvi par exemple), l'entrée est dumpée dans un fichier dans /etc/ldap/slapd.d/ et un checksum est généré. Pour contourner ce problème, il vous suffit de faire une modification à chaud de l'entrée (même inutile) afin qu'un dump soit regénéré avec son checksum correspondant.