Editions ENI Livres | Vidéos | e-Formations
Ajout de fonctionnalités appelées "overlay"
Introduction
OpenLDAP offre la possibilité d’ajouter des fonctionnalités nommées "overlay" afin de modifier et d’enrichir le comportement de l’annuaire. Par défaut, OpenLDAP implémente strictement les RFC du protocole LDAP, et ne dispose donc de ce fait que de peu de fonctionnalités. Ces fonctionnalités sont placées au-devant (frontend) de la base de données (backend) contenant les informations des utilisateurs de l’annuaire et agissent donc sur celle-ci en fonction de la nature et du contenu de l’opération LDAP.
Le terme "overlay" en anglais se traduit par "superposition" en français pour indiquer qu’il s’applique au-dessus de la base de données.
Tous les overlay disponibles dans OpenLDAP sont listés et décrits en détail dans ce chapitre. Mais avant cela, la section suivante va décrire la manière dont s’ajoute un overlay.
Ajouter un overlay
Les overlay peuvent être compilés de façon statique dans le code de l’annuaire OpenLDAP ou bien chargés par l’intermédiaire d’un module à activer. Bien que la plupart des overlay ne soient applicables qu’au niveau des bases de données locales de l’annuaire (DIT), certains sont également applicables au niveau de la configuration globale de l’annuaire dans l’entrée :
dn: olcDatabase={-1}frontend,cn=config
Cela signifie qu’ils peuvent être exécutés une fois qu’une demande a été analysée et validée et donc avant que cette requête ne soit traitée par la base de données appropriée.
1. Vérification de son existence dans l’annuaire
Avant de charger un overlay, il faut tout d’abord s’assurer qu’il existe dans la version qui a été installée sur votre serveur. Pour ce faire, il faut se rendre dans le répertoire /usr/lib64/openldap et regarder la liste des fichiers "*.la".
[root@ldap01 tmp]# cd /usr/lib64/openldap/
[root@ldap01 openldap]# ls -lrt
total 720
-rwxr-xr-x. 1 root root 1068 Jun 18 2014 auditlog.la
-rwxr-xr-x. 1 root root 1074 Jun 18 2014 accesslog.la
-rwxr-xr-x. 1 root root 1050 Jun 18 2014 deref.la
-rwxr-xr-x. 1 root root...AccessLog
1. Présentation
Cette fonctionnalité est appliquée au niveau d’une base de données de l’annuaire et permet de collecter les opérations (selon des critères ou pas) qui ont été effectuées sur celle-ci puis de les enregistrer dans une autre base de données. Les opérations peuvent être sélectionnées de manière très sélective, car elle s’appuie sur les filtres de recherche du protocole LDAP et permet donc de réaliser une supervision de l’activité désirée. Un exemple serait de tracer l’activité de certains utilisateurs ou bien de certaines entrées de l’annuaire. Cet overlay permet également de consulter et d’examiner l’activité LDAP d’une base de données dans un format LDAP au lieu de visionner des fichiers plats à l’aide du mode "debug" du processus "slapd".
Cette fonctionnalité est d’ailleurs requise pour l’utilisation de la réplication "Delta-syncrepl" (voir chapitre La réplication).
Pour obtenir plus d’informations, entrer la commande :
man slapo-accesslog
2. Exemple de configuration
|
1. |
Le module "accesslog.la" doit tout d’abord être chargé dans l’entrée : dn: cn=module{0},cn=config |
|
2. |
Il faut ensuite... |
Audit logging
1. Présentation
Cette fonctionnalité permet d’enregistrer dans un fichier plat toutes les modifications qui ont été effectuées dans un annuaire LDAP (ajout, suppression ou modification d’entrées). Cependant, il ne permet pas, comme pour la fonctionnalité "AccessLog", de choisir le type d’opération à inventorier.
Toutes les informations seront visibles en entrant la commande :
man slapo-auditlog
2. Exemple de configuration
|
1. |
Il faut tout d’abord charger le module "auditlog.la" dans l’entrée : dn: cn=module{0},cn=config |
|
2. |
Puis, il faudra appliquer cette fonctionnalité au niveau de l’entrée de l’annuaire à surveiller. |
dn: olcOverlay=auditlog,olcDatabase={1}bdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcAuditLogConfig
olcOverlay: auditlog
olcAuditlogFile: /tmp/auditlog.log
|
3. |
Par la suite, le fichier "/tmp/audit.log" précédemment désigné pourra contenir des entrées de ce type : |
# add 1196797576 dc=exemple,dc=com cn=root,dc=exemple,dc=com
dn: dc=exemple,dc=com
changetype: add
objectClass: dcObject
objectClass: organization
dc: exemple
o: Suretec Systems Ltd.
structuralObjectClass: organization
entryUUID: 1606f8f8-f06e-1029-8289-f0cc9d81e81a
creatorsName: cn=root,dc=exemple,dc=com ...Constraint
1. Présentation
La fonctionnalité "constraint" est utilisée afin de s’assurer que les valeurs d’un ou plusieurs attributs correspondent bien à la syntaxe attendue. En effet, ce contrôle peut s’avérer utile lorsque des attributs attendent des valeurs de type canoniques bien connues, comme des numéros de téléphone, des codes postaux, des FQDN, etc.
2. Exemple de configuration
|
1. |
Il faut tout d’abord charger le module "constraint.la" dans l’entrée : dn: cn=module{0},cn=config |
|
2. |
Puis, il faudra appliquer cette fonctionnalité au niveau de l’entrée de l’annuaire ciblé (ex. olcDatabase={1}hdb,cn=config) à l’aide d’une commande ldapadd. |
dn: olcOverlay=constraint,olcDatabase={1}hdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcConstraintConfig
olcOverlay: constraint
olcConstraintAttribute: jpegPhoto size 131072
olcConstraintAttribute: phoneNumber count 3
Dans cet exemple sont configurées deux contraintes pour les attributs jpegPhoto et phoneNumber : la taille maximale de l’image pour le premier et le nombre de numéros de téléphone maximum pour le second. Il est possible de définir des règles bien plus complexes. Pour plus d’informations, taper ’man...
Dynamic Lists
1. Présentation
Cette fonctionnalité permet de maintenir les valeurs d’un attribut de manière dynamique au travers d’une requête LDAP en s’affranchissant ainsi de la maintenance d’une liste de valeurs statiques. La liste obtenue peut avoir deux sortes de résultats : l’attribut accompagné de sa valeur ou bien seulement les DN en fonction de la syntaxe de la requête. On parle alors de liste dynamique pour le premier cas et de groupe dynamique pour le second cas.
Cet overlay peut ainsi se comporter à la fois comme une liste dynamique ou un groupe dynamique selon la manière dont il est configuré.
Sa syntaxe est la suivante :
dynlist-attrset <group-oc> <URL-ad> [member-ad]
Les paramètres de la directive dynlist-attrset ont la signification suivante :
-
<Group-oc> spécifie quelle classe d’objet déclenchera la recherche LDAP spécifiée. Chaque fois qu’une entrée avec cette classe d’objet sera récupérée, la recherche sera effectuée.
-
<URL-annonce> est le nom de l’attribut qui détient l’URI de recherche. Les attributs et les valeurs présents dans le résultat de la recherche sont ajoutés à l’entrée à moins que le paramètre member-ad ne soit utilisé.
-
[Member-ad] : si présent, modifie...
Password Policy
1. Présentation
Cette fonctionnalité permet d’appliquer une politique de mots de passe et de sécuriser l’utilisation des comptes liés aux entrées de l’annuaire contenant l’attribut userPassword.
L’ajout de cette fonctionnalité permettra de renforcer la sécurité en :
-
Appliquant une longueur minimale aux nouveaux mots de passe.
-
S’assurant que les mots de passe ne sont pas trop fréquemment changés.
-
S’assurant que les mots de passe expirent, fournissent des avertissements avant qu’ils ne soient modifiés et autorisent un nombre autorisé de connexions "gracetime" afin de permettre à leur utilisateur de le changer après leur expiration.
-
Maintenant un historique des mots de passe utilisés afin d’empêcher leur réutilisation.
-
Effectuant des contrôles sur la qualité des mots de passe.
-
Empêchant l’utilisation d’un compte par "verrouillage" de celui-ci, de manière définitive ou après une période de temps spécifiée, après constatation de tentatives d’authentification infructueuse.
-
Forçant un mot de passe à changer lors de la prochaine authentification.
-
Ayant la possibilité de définir un verrou administratif sur un compte.
Cet "overlay" permet d’appliquer plusieurs stratégies de compte en fonction des entrées. Ainsi, il est possible d’appliquer une stratégie de compte "spécifique" avec un renouvellement des mots de passe tous les 90 jours à un groupe d’utilisateurs et une autre stratégie de compte sans renouvellement du mot de passe à un groupe d’utilisateurs de type administrateur.
2. Exemple de configuration
|
1. |
Il faut tout d’abord charger le module "ppolicy.la" dans l’entrée :dn: cn=module{0},cn=config |
|
2. |
Par ailleurs, cet overlay utilise un schéma spécifique qu’il faudra charger dans l’annuaire. Cependant, il devrait y être par défaut lors de l’installation du serveur OpenLDAP. Une simple vérification dans ce cas suffit : |
[root@ldap01 schema]# ldapsearch -h localhost -D cn=config -W -b
"cn=schema,cn=config" -s one objectclass=olcSchemaConfig dn -LLL ...L’intégrité référentielle
1. Présentation
Cette fonctionnalité est appliquée au niveau d’une base de données de type "bdb" ou "hdb" et permet de garantir la cohérence des données de l’annuaire. Ainsi, chaque fois qu’une modification est effectuée au niveau du DN d’une entrée de l’annuaire (suppression ou renommage) cette fonctionnalité recherchera dans le DIT toutes les entrées ayant des attributs faisant référence à celui-ci et les mettra à jour en conséquence. S’il s’agissait d’une opération de suppression alors la référence serait supprimée. S’il s’agissait d’une opération de modification du DN alors la référence serait mise à jour avec le nouveau DN.
Par exemple, une tâche d’administration très courante consiste à maintenir des listes d’utilisateurs via leur DN au sein de différents groupes de l’annuaire. Ainsi, lorsqu’un compte utilisateur est supprimé ou renommé, tous les groupes d’appartenance de cet utilisateur doivent être mis à jour. Les administrateurs LDAP ont généralement des scripts pour cela, mais grâce à cette fonctionnalité, ils n’en auront plus l’usage....
Sync Provider
1. Présentation
Cette fonctionnalité est utilisée afin de configurer la réplication de type "fournisseur/consumer" entre un ou plusieurs annuaires OpenLDAP, mais elle ne doit être chargée que du côté du "fournisseur". Cet overlay est utilisé afin de maintenir une trace de la dernière opération de réplication qui a eu lieu grâce à l’attribut contextCSN qu’il crée et maintient à la racine de la base de données. Il est aussi chargé d’informer le "consumer" lorsqu’une mise à jour a été réalisée dans le mode de réplication "RefreshPersisting".
2. Exemple de configuration
|
1. |
Il faut tout d’abord charger le module "syncprov.la" dans l’entrée :dn: cn=module{0},cn=config |
|
2. |
Puis, il faudra appliquer cette fonctionnalité au niveau de l’entrée de l’annuaire ciblé (ex. olcDatabase={1}hdb,cn=config) à l’aide d’une commande ldapadd avec les paramètres par défaut suivants : |
dn: olcOverlay=syncprov,olcDatabase={1}hdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
olcSpCheckpoint: 100 10
Il existe très peu d’attributs de configuration pour cette fonctionnalité....
Attribute Uniqueness
1. Présentation
Cette fonctionnalité peut être utilisée avec une base de données de type "bdb" ou "hdb" et permet de faire respecter l’unicité de valeur de certains ou de tous les attributs d’un annuaire. En effet, dans le cas d’un attribut de type "numéro de téléphone", il paraît évident que la valeur de celui-ci ne peut être détenue que par une seule et même personne. L’inverse étant par ailleurs faux : une personne peut détenir plusieurs numéros de téléphone. Ainsi, lors de l’ajout d’une valeur de type "numéro de téléphone", cette fonctionnalité parcourra donc l’annuaire pour vérifier qu’elle n’est pas déjà utilisée dans une autre entrée.
Cette fonctionnalité n’est pas rétroactive et traite les opérations qu’elle reçoit seulement au moment de son activation sur l’annuaire. Ainsi, pour vérifier l’unicité des données existantes, il faudra utiliser des requêtes LDAP de type recherche et faire soi-même la comparaison de toutes les valeurs. Une autre méthode consisterait à exporter son annuaire puis à le réimporter à l’aide de commande de type...
Reverse Group Membership Maintenance
1. Présentation
Cette fonctionnalité peut être utilisée dans certains cas où il serait nécessaire de connaître les groupes dont une entrée est membre et sans émettre de nouvelles requêtes. À titre d’exemple, il est possible de trouver des applications utilisant l’annuaire afin d’effectuer des contrôles d’accès basés sur des groupes d’autorisation.
Ainsi, cette fonctionnalité va créer un nouvel attribut ’opérationnel’ nommé memberof qui sera automatiquement mis à jour lorsque la valeur de l’attribut member d’un groupe sera modifiée (ajout ou suppression).
Cette fonctionnalité n’est pas rétroactive et traite les opérations qu’elle reçoit seulement au moment de son activation sur l’annuaire. Ainsi, toutes les valeurs member existantes avant la mise en action de cette fonctionnalité ne seront pas prises en compte.
2. Exemple de configuration
|
1. |
Il faut tout d’abord charger le module memberof.la dans l’entrée : dn: cn=module{0},cn=config |
|
2. |
Puis, il faudra appliquer cette fonctionnalité au niveau de l’entrée de l’annuaire ciblé (ex. olcDatabase={1}bdb,cn=config) à l’aide d’une commande ldapadd avec les paramètres... |
