openldap

Classe d'objet glue dans un annuaire LDAP

J'ai observé un comportement curieux sur un annuaire OpenLDAP, suite à la mise en place de nouveaux serveurs dans une topologie de réplication.

En parcourant l'annuaire avec un browser LDAP, le container / OU qui contient les comptes de services n'est plus visible... Alors qu'on peut toujours faire une requête LDAP pour trouver les comptes de services situés dans ce container.

Au départ, je pensais à une ACI, mais je n'arrivais pas à l'identifier. Et même en utilisant le compte administrateur (qui ne prend pas en compte les ACI), l'objet est toujours invisible.

OpenLDAP - LastBind Overlay

La question qui se pose est : pourquoi mémoriser la date de dernière authentification ?

Le principal intérêt est de mettre en place un premier niveau de gouvernance : cette date permet d'identifier les comptes qui sont obsolètes dans l'annuaire, par exemple qui n'ont pas été utilisés pour s'authentifier depuis plusieurs mois.

Par défaut, cette information n'est pas disponible sur OpenLDAP (comme cela peut l'être dans un AD).

On peut analyser les logs systèmes (avec un niveau de log OpenLDAP à 256), mais ce n'est pas optimal.

Tags

OpenLDAP : mise en place de la réplication

Mise en place de la réplication dans OpenLDAP

La plupart du temps, les annuaires LDAP sont paramétrés avec une réplication entre deux serveurs, afin d'apporter une meilleure disponibilité ou permettre une montée en charge horizontale, via la mise en place d'un répartiteur de charge en frontal.

Situation de base

Un serveur installé en tant que master : openldap1.arciam.fr. Il écoute sur le port 389. L'overlay syncprov a été chargé en tant que module , via la configuration :

Les ACL dans OpenLDAP

Principes généraux

Les ACL dans OpenLDAP peuvent se trouver à 2 niveaux, database ou backEnd, sachant qu'il est assez courant d'avoir un backend par database (ou vice-versa).

Les ACL sont donc généralement positionnées dans la configuration de la database.

Syntaxe

La syntaxe globale est :

olcAccess: to [ressource]
  by [à qui] [type d'accès autorisé]
  by [à qui] [type d'accès autorisé]
  by [à qui] [type d'accès autorisé]

Un exemple de base, qui limite l'accès à l'attribut userPassword :

Migration de schéma Sun DSEE vers OpenLDAP

Comme vu précédemment (https://www.vincentliefooghe.net/content/migration-sun-dsee-vers-openld…) la migration Sun DSEE vers OpenLDAP nécessite une phase d'adaptation des schémas spécifiques.

Si on utilise des attributs ou classes d'objets propres à la structure (ce qui est bien souvent le cas) il faudra adapter la définition pour OpenLDAP.

Exemple d'un fichier 99user.ldif :

Migration Sun DSEE vers OpenLDAP

Suite au rachat de Sun par Oracle, et à la fin de support de l'annuaire Sun DSEE (la version 7 étant la dernière, avec un support étendu jusque Décembre 2017), pas mal de clients regardent ailleurs pour migrer leur annuaire LDAP.

Nous voyons ainsi des migration vers OpenDJ, mais aussi vers OpenLDAP.

Si les deux annuaires respectent le protocole LDAP, l'implémentation réalisée par OpenLDAP est beaucoup plus stricte (ou moins permissive) que ne l'était celle de Sun. Il faut ainsi faire attention à plusieurs points :

OpenLDAP : setup multiple instances on a server

Abstract : in some cases, it is interesting to have multiples instances of OpenLDAP running on the same machine. This could be used to separate data, test replication on the same server, or whatever you want.

This note will explain how to do this.

Main principles

In a standard GNU/Linux OpenLDAP install (Red Hat or Debian based), there are several files or directories used to set up OpenLDAP instance and data :

Tuning OpenLDAP avec DB_CONFIG

Afin d'améliorer les performances de OpenLDAP, il est recommandé de pouvoir utiliser le plus de cache possible pour monter en mémoire les données OpenLDAP.

Ceci se fait via les réglagles du fichier DB_CONFIG, qui se trouve dans le répertoire contenant les données de l'annuaire, et qui permet de paramétrer la base de données Berkeley, utilisée comme back-end de stockage par OpenLDAP.
Par défaut, il n'y a pas de fichier DB_CONFIG créé. Par contre on peut trouver un exemple dans /usr/share/openldap-servers/DB_CONFIG.example :