openldap

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) :

Ajouter un schéma spécifique

Il est très fréquent de vouloir ajouter ses propres attributs et classes d'objets à un annuaire LDAP, car les classes et attributs standards ne couvrent pas tous les cas fonctionnels. Cette opération peut maintenant être réalisée en "live" sur OpenLDAP, via l'objet cn=schema,cn=config. Il faut pour cela créer un fichier LDIF contenant la définition des attributs à ajouter et les classes d'objets, puis ajouter ce fichier LDIF dans l'annuaire.

Exemple de fichier LDIF :