openldap

OpenLDAP : surveiller et contrôler la réplication

La mise en place d'une réplication de type miroir entre deux annuaires OpenLDAP est assez simple.

Une fois la mise en place effectuée, il s'agit de vérifier que la réplication se fait de manière satisfaisante. Car parfois, en cas de charge élevée sur l'un des annuaires, certaines transactions peuvent ne pas être propagées. Il est alors intéressant de savoir si les instances d'annuaires sont bien synchronisées, et comment les remettre d'aplomb si ce n'est pas le cas.

Problème sur OpenLDAP avec des overlays multiples

Version française

Récemment nous avons eu des soucis curieux sur un annuaire OpenLDAP.

Lors de la création d'une entrée, le message d'erreur était :

adding new entry "uid=GFR6285008,ou=users,dc=example,dc=com"
ldap_add: Constraint violation (19)
    additional info: attribute 'pwdChangedTime' cannot have multiple values

L'overlay ppolicy est en place, et une politique par défaut existe. Le message n'apparaît pas lorsque l'on modifie une entrée.

Mise en place OpenSSL sur OpenLDAP

La mise en place de SSL pour OpenLDAP permet de sécuriser les échanges, que ce soit en utilisant LDAPS ou START/TLS (dans ce dernier cas, la connexion démarre sur le port LDAP et passe ensuite en mode sécurisé).

En préalable, on aura généré une clé privée, récupéré un certificat, ainsi que celui de l'autorité de certification. (voir un article précédent sur le mémento OpenSSL ).

Les étapes pour la sécurisation sont :

Ajout d'index sur un annuaire OpenLDAP

Introduction & contexte

Par défaut, les attributs d'un annuaire OpenLDAP ne sont pas indexés. Comme dans une base de données, ceci peut impacter les performances de l'annuaire, en introduisant des full scan qui balaient toutes les entrées. Il est possible, comme sur une base de données, de créer des index sur certains attributs, pour améliorer la vitesse de recherche.
Toutefois, les index ont également un inconvénient : lors des mises à jour, l'index doit être recalculé, et ceci peut être pénalisant, notamment lors de modifications en masse.

OpenLDAP : Overlay AccessLog

Dans la série des overlays pour OpenLDAP, après le Password Policy, regardons l'accesslog.

Intérêt de l'overlay Accesslog

L'overlay Accesslog peut être utile pour récupérer dans une branche séparée de l'annuaire un ensemble d'opérations appliquée sur une database.

Le paramétrage distingue 4 sortes d'opérations :

OpenLDAP - Changer de moteur backend

Depuis la version 2.4, le moteur de stockage recommandé par défaut pour OpenLDAP est MDB ou LMDB (Lightning Memory-Mapped Database). Dans les distributions Red Hat par contre, c'est toujours le moteur BDB (Berkeley DataBase), ou son évolution HDB (Hierarchical Database) qui est recommandé et utilisable, vu la version ancienne utilisé : 2.4.23.

HDB est une variante du backend BDB. HDB utilise un modèle hiérarchique, qui supporte notamment le renommage d'un sous-arbre. Etant basé sur BDB, les mêmes options de configurations sont présentes.

Optimisation OpenLDAP pour la suppression d'un membre d'un groupe

La suppression d'un membre dans un groupe (uniqueMember) est très longue par défaut, sur un groupe qui contient plus de 66 000 entrées :

time ldapmodify -x D bindn -w password-f delMember.ldif 
delete uniqueMember:
	uid=USER1,ou=employees,ou=users,ou=example,o=com
modifying entry "cn=InternalUsers,ou=groups,ou=example,o=com"
modify complete


real	6m17.845s
user	0m0.088s
sys	0m0.112s

Le fichier LDIF utilisé étant le suivant :

Sauvegarde et Restauration OpenLDAP

Sur un serveur Linux, la configuration OpenLDAP se trouve dans /etc/openldap, et plus précisément dans /etc/openldap/slapd.d.
Les données, quant à elles, se trouvent... où on leur a dit de se mettre, puisque ceci est défini pour chaque rootSuffix.

Par exemple, si pour notre rootSuffix, nous définissons dans le fichier /etc/openldap/slapd.d/cn=config/olcDatabase={2}bdb.ldif les informations suivantes (extrait) :