Tuto Openldap, partie II : Les Overlays

Deuxième partie de la série de tuto sur OpenLDAP. Nous avons vu précédemment la configuration de base. Voyons maintenant les Overlays.

Article révisé en octobre 2022

 

I – Quid ?

Les overlays sont des fonctionnalités supplémentaires qui se rajoutent. Ils en existent un certain nombre. La liste est non exhaustive, je n’ai mis que les plus « importants ».

• accesslog : Enregistrement des accès. Attention, réduit drastiquement les performances
• auditlog : Enregistrement des modifications
• chain : Liaison de plusieurs serveurs LDAP au niveau des recherches
• collect : Implémentation de la RFC 3671. Les attributs collectifs partagent des valeurs communes entre l’ensemble des membres héritant d’une entrée commune
• constraint : Permet de forcer des contraintes sur des attributs
• memberof : Permet de connaître les groupes auxquels appartient un utilisateur
• ppolicy : Password Policy. Permet la mise en place de contrôles sur les mots de passe (longueur, durée de validité, etc…)
• refint :Referential Integrity. Permet de s’assurer de la cohérence de l’annuaire lors de suppression d’entrées
• syncprov :Syncrepl Provider. Permet la réplication syncrepl, incluant la fonctionnalité de recherche persistante. On l’installera plus tard
• translucent : Translucent Proxy. Cet overlay peut être utilisé avec un backend local pour créer un proxy transparent. Le contenu des entrées récupérées à partir d’un serveur LDAP distant peut être en partie réécrit/modifié/complété par la base locale
• unique : permet de s’assurer de l’unicité d’attributs
• valsort : Permet de forcer l’ordre pour les valeurs d’attributs lorsqu’ils sont retournées suite à une recherche

En gras, ceux dont nous nous servirons.

Plus d’informations sur ce site : https://www.openldap.org/doc/admin24/overlays.html.

Pour chaque overlay, la configuration se fait en plusieurs fichiers. Généralement, un pour l’activation (qui ne sera utilisé qu’une fois). L’autre pour la configuration (nous pourrons alors le modifier plus tard). Ce fichier de configuration porte sur la base par défaut {1}mdb (qui contient notre arbre dc=debugo,dc=fr. Par la suite, avec d’autres arbres, nous pourrons alors configurer ces overlays sur ceux ci.

 

II – MemberOf

L’overlay memberof permet de savoir dans quels groupes se trouve un utilisateur en une seule requête au lieu de deux.
Exemple :

# ldapsearch -xLLL  "(uid=toto)" memberof

retournera la liste des groupes auquel l’utilisateur toto appartient.

Créez un fichier memberof_act.ldif et insérez le contenu suivant :

dn: cn=module,cn=config
cn:module
objectclass: olcModuleList
objectclass: top
olcmoduleload: memberof.la
olcmodulepath: /usr/lib/ldap

Créez un fichier memberof_conf.ldif et insérez le contenu suivant :

dn: olcOverlay=memberof,olcDatabase={1}mdb,cn=config
changetype: add
objectClass: olcMemberOf
objectClass: olcOverlayConfig
objectClass: olcConfig
objectClass: top
olcOverlay: memberof
olcMemberOfDangling: ignore
olcMemberOfRefInt: TRUE
olcMemberOfGroupOC: groupOfNames
olcMemberOfMemberAD: member
olcMemberOfMemberOfAD: memberOf

On injecte :

# ldapadd -Y EXTERNAL -H ldapi:/// -f memberof_act.ldif
# ldapadd -Y EXTERNAL -H ldapi:/// -f memberof_conf.ldif

Pour vérifier :

# ldapsearch -QLLLY EXTERNAL -H ldapi:/// -b "cn=config" "Objectclass=olcModuleList"

Ou bien encore :

# tree /etc/ldap/slapd.d/

On doit trouver trace dans la liste des modules.

On peut vérifier la configuration avec :

# ldapsearch -QLLLY EXTERNAL -H ldapi:/// -b "cn=config" "Objectclass=olcmemberOf"

 

III – Intégrité Référentielle

Cet overlay permet de supprimer un utilisateur d’un groupe quand on supprime l’utilisateur. Au passage, si un groupe se retrouve vide, l’admin sera automatiquement ajouté (un groupe vide créé une erreur dans OpenLdap)

Créez un fichier refint_act.ldif  et insérez le contenu suivant :

dn: cn=module,cn=config
cn: module
objectclass: olcModuleList
objectclass: top
olcmoduleload: refint.la
olcmodulepath: /usr/lib/ldap

Créez un fichier refint_conf.ldif  et insérez le contenu suivant :

dn: olcOverlay=refint,olcDatabase={1}mdb,cn=config
objectClass: olcConfig
objectClass: olcOverlayConfig
objectClass: olcRefintConfig
objectClass: top
olcOverlay: refint
olcRefintAttribute: memberof member manager owner
olcRefintNothing: cn=admin,dc=debugo,dc=fr

On injecte :

# ldapadd -Q -Y EXTERNAL -H ldapi:/// -f refint_act.ldif
# ldapadd -Q -Y EXTERNAL -H ldapi:/// -f refint_conf.ldif

On vérifie :

# ldapsearch -QLLLY EXTERNAL -H ldapi:/// -b "cn=config" "Objectclass=olcModuleList"

On peut vérifier la configuration avec :

# ldapsearch -QLLLY EXTERNAL -H ldapi:/// -b "cn=config" "Objectclass=olcRefintConfig"

 

IV – Overlay Audit Log

Cet overlay sert à auditer chaque modification au sein de l’annuaire. Dans notre cas, cela sera inscrit dans le fichier : /var/log/openldap/audit.ldif

Créez le fichier auditlog_act.ldif  pour y insérer :

dn: cn=module,cn=config
cn: module
objectclass: olcModuleList
objectclass: top
olcModuleLoad: auditlog.la
olcmodulepath: /usr/lib/ldap

Créez le fichier auditlog_conf.ldif  pour y insérer :

dn: olcOverlay=auditlog,olcDatabase={1}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcAuditLogConfig
olcOverlay: auditlog
olcAuditlogFile: /var/log/openldap/auditlog.log

Injectez :

# ldapadd -Q -Y EXTERNAL -H ldapi:/// -f auditlog_act.ldif
# ldapadd -Q -Y EXTERNAL -H ldapi:/// -f auditlog_conf.ldif

On vérifie :

# ldapsearch -QLLLY EXTERNAL -H ldapi:/// -b "cn=config" "Objectclass=olcModuleList"

On peut vérifier la configuration avec :

# ldapsearch -QLLLY EXTERNAL -H ldapi:/// -b "cn=config" "Objectclass=olcAuditLogConfig"

Ensuite, nous allons créer le fichier :

# mkdir /var/log/openldap
# chmod 755 /var/log/openldap
# chown openldap:openldap /var/log/openldap
# touch /var/log/openldap/auditlog.log
# chmod 755 /var/log/openldap/auditlog.log
# chown openldap:openldap /var/log/openldap/auditlog.log

 

V – Overlay Unique

Cet overlay permet de nous assurer l’unicité des attributs que l’on spécifie.

Créez un fichier unique_act.ldif pour y insérer :

dn: cn=module,cn=config
cn: module
objectclass: olcModuleList
objectclass: top
olcModuleLoad: unique.la
olcmodulepath: /usr/lib/ldap

Créez un fichier unique_conf.ldif pour y insérer :

dn: olcOverlay=unique,olcDatabase={1}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcUniqueConfig
olcOverlay: unique
olcUniqueUri: ldap:///ou=people,dc=debugo,dc=fr?uid?sub
olcUniqueUri: ldap:///ou=people,dc=debugo,dc=fr?mail?sub
olcUniqueUri: ldap:///ou=people,dc=debugo,dc=fr?uidNumber?sub
olcUniqueUri: ldap:///ou=groups,dc=debugo,dc=fr?cn?sub

Nous demandons ici à ce que les attributs ui, mail et uidNumber dans l’OU people soient uniques. Et que l’attribut cn dans l’OU groups soit lui aussi unique.

Injectez :

# ldapadd -Q -Y EXTERNAL -H ldapi:/// -f unique_act.ldif
# ldapadd -Q -Y EXTERNAL -H ldapi:/// -f unique_conf.ldif

On vérifie :

# ldapsearch -QLLLY EXTERNAL -H ldapi:/// -b "cn=config" "Objectclass=olcModuleList"

On peut vérifier la configuration avec :

# ldapsearch -QLLLY EXTERNAL -H ldapi:/// -b "cn=config" "Objectclass=olcUniqueConfig"

 

VI – Overlay Ppolicy

Cet overlay va nous permettre de spécifier une politique de mot de passe.

Un peu particulier, il faut ajouter son schéma dans l’annuaire :

# ldapadd -Q -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/ppolicy.ldif

On peut voir que c’est bon avec :

# ldapsearch -QLLLY EXTERNAL -H ldapi:/// -b "cn=schema,cn=config" cn

Ou bien encore :

# tree /etc/ldap/slapd.d/

Dans la branche cn=schema, on doit voir le schéma ppolicy qui s’est ajouté à ceux présent par défaut (core, cosine, nis et inetorgperson).

Créez un fichier ppolicy_act.ldif pour y insérer :

dn: cn=module,cn=config
cn: module
objectclass: olcModuleList
objectclass: top
olcModuleLoad: ppolicy.la
olcmodulepath: /usr/lib/ldap

Créez un fichier ppolicy_conf.ldif pour y insérer :

dn: olcOverlay=ppolicy,olcDatabase={1}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcPpolicyConfig
olcOverlay: ppolicy
olcPPolicyDefault: cn=ppolicy,dc=debugo,dc=fr
olcPPolicyHashCleartext: TRUE
olcPPolicyUseLockout: FALSE

olcPPolicyDefault : Indique le DN de configuration utilisé par défaut (nous le définirons apres).

olcPPolicyHashCleartext : Indique si les mots de passe doivent être cryptés.

olcPPolicyUseLockout : Si TRUE, le message d’erreur retourné en cas de connexion à un compte verrouillé indiquera qu’il s’agit d’un compte verrouillé. Si FALSE, ce sera un message d’échec stantard.

On injecte

# ldapadd -Q -Y EXTERNAL -H ldapi:/// -f ppolicy_act.ldif
# ldapadd -Q -Y EXTERNAL -H ldapi:/// -f ppolicy_conf.ldif

On vérifie :

# ldapsearch -QLLLY EXTERNAL -H ldapi:/// -b "cn=config" "Objectclass=olcPpolicyConfig" -LLL

On va maintenant créer la politique par défaut.

Créez un fichier ppolicy-def.ldif pour y insérer :

dn: cn=ppolicy,dc=debugo,dc=fr
objectClass: top
objectClass: device
objectClass: pwdPolicy
cn: ppolicy
pwdAllowUserChange: TRUE
pwdAttribute: userPassword
pwdCheckQuality: 1
pwdExpireWarning: 0
pwdFailureCountInterval: 30
pwdGraceAuthNLimit: 5
pwdInHistory: 5
pwdLockout: TRUE
pwdLockoutDuration: 60
pwdMaxAge: 0
pwdMaxFailure: 5
pwdMinAge: 0
pwdMinLength: 5
pwdMustChange: FALSE
pwdSafeModify: FALSE

La signification des attributs est :

• pwdAllowUserChange : indique si l’utilisateur peut changer son mot de passe
• pwdCheckQuality : indique si OpenLDAP renvoie une erreur si le mot de passe n’est pas conforme
• pwdExpireWarning : avertissement d’expiration
• pwdFailureCountInterval : Intervalle de temps entre deux tentatives infructueuses pour qu’elles soient considérées comme « à la suite »
• pwdGraceAuthNLimit : période de grâce suite à l’expiration du mot de passe
• pwdInHistory : nombre de mots de passe dans l’historique
• pwdLockout : indique si on bloque le compte au bout de X échecs
• pwdLockoutDuration : durée du blocage du compte (en secondes)
• pwdMaxAge : age maximal du mot de passe (en secondes)
• pwdMaxFailure : nombre d’échecs de saisie du mot de passe maximal (avant blocage)
• pwdMinAge : age minimal du mot de passe (en secondes)
• pwdMinLength : longueur minimale du mot de passe
• pwdMustChange : indique si l’utilisateur doit changer son mot de passe
• pwdSafeModify : indique si il faut envoyer l’ancien mot de passe avec le nouveau pour modification

On injecte :

# ldapadd -H ldap://localhost -D cn=admin,dc=debugo,dc=fr -y /root/pwdldap -f ppolicy-def.ldif

On vérifie :

# ldapsearch -QLLLY EXTERNAL -H ldapi:/// -b "dc=debugo,dc=fr" "Objectclass=pwdPolicy"

On peut avoir plusieurs politique (une adapté pour des comptes clients, par exemple).

Par ex, fichier ppolicy-client.ldif :

dn: cn=ppolicy-client,dc=debugo,dc=fr
objectClass: top
objectClass: device
objectClass: pwdPolicy
cn: ppolicy-client
pwdAllowUserChange: TRUE
pwdAttribute: userPassword
pwdCheckQuality: 1
pwdExpireWarning: 0
pwdFailureCountInterval: 30
pwdGraceAuthNLimit: 5
pwdInHistory: 10
pwdLockout: TRUE
pwdLockoutDuration: 60
pwdMaxAge: 0
pwdMaxFailure: 3
pwdMinAge: 0
pwdMinLength: 8
pwdMustChange: FALSE
pwdSafeModify: TRUE

Qu’on injecte :

# ldapadd -H ldap://localhost -D cn=admin,dc=debugo,dc=fr -y /root/pwdldap -f ppolicy-client.ldif

Et qu’on affectera avec un fichier changeppolicy.ldif :

dn: uid=toto,ou=client,ou=people,dc=debugo,dc=fr
changetype: modify
replace: pwdPolicySubEntry
pwdPolicySubEntry: cn=ppolicy-client,dc=debugo,dc=fr

Qu’on injectera avec :

# ldapadd -H ldap://localhost -D cn=admin,dc=debugo,dc=fr -y /root/pwdldap -f changeppolicy.ldif

On pourra aussi spécifier cet attribut à la création de l’utilisateur.

 

Voila qui termine cette deuxième partie.

Dans la suite, nous peuplerons notre annuaire.