Comment configurer la maintenance inversée de l'appartenance à un groupe sur un serveur openldap? (membre de)

Je travaille actuellement sur l'intégration de l'authentification LDAP dans un système et je voudrais restreindre l'accès en fonction du groupe LDAP. La seule façon de le faire est via un filtre de recherche et donc je crois que ma seule option est l'utilisation de l'attribut "memberOf" dans mon filtre de recherche. Je crois comprendre que l'attribut "memberOf" est un attribut opérationnel qui peut être créé par le serveur pour moi chaque fois qu'un nouvel attribut "member" est créé pour toute entrée "groupOfNames" sur le serveur. Mon objectif principal est de pouvoir ajouter un attribut "membre" à une entrée "groupOfNames" existante et d'ajouter un attribut "memberOf" correspondant au nom distinctif que je fournis.

Ce que j'ai réussi à réaliser jusqu'à présent:

Je suis encore assez nouveau dans l'administration LDAP, mais d'après ce que j'ai trouvé dans le guide de l'administrateur openldap, il semble que le maintien de l'appartenance à un groupe inversé aka "memberof overlay" atteindrait exactement l'effet que je recherche.

Mon serveur exécute actuellement une installation de package (slapd sur ubuntu) d'Openldap 2.4.15 qui utilise une configuration d'exécution de style "cn = config". La plupart des exemples que j'ai trouvés font référence à l'ancienne méthode de configuration statique "slapd.conf" et j'ai fait de mon mieux pour adapter les configurations au nouveau modèle basé sur les répertoires.

J'ai ajouté les entrées suivantes pour activer le module de superposition memberof:

Activer le module avec olcModuleLoad

cn=config/cn\=module\{0\}.ldif

dn: cn=module{0}
objectClass: olcModuleList
cn: module{0}
olcModulePath: /usr/lib/ldap
olcModuleLoad: {0}back_hdb
olcModuleLoad: {1}memberof.la
structuralObjectClass: olcModuleList
entryUUID: a410ce98-3fdf-102e-82cf-59ccb6b4d60d
creatorsName: cn=config
createTimestamp: 20090927183056Z
entryCSN: 20091009174548.503911Z#000000#000#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20091009174548Z

Activé la superposition de la base de données et lui a permis d'utiliser ses paramètres par défaut (groupOfNames, membre, memberOf, etc.)

cn=config/olcDatabase={1}hdb/olcOverlay\=\{0\}memberof

dn: olcOverlay={0}memberof
objectClass: olcMemberOf
objectClass: olcOverlayConfig
objectClass: olcConfig
objectClass: top
olcOverlay: {0}memberof
structuralObjectClass: olcMemberOf
entryUUID: 6d599084-490c-102e-80f6-f1a5d50be388
creatorsName: cn=admin,cn=config
createTimestamp: 20091009104412Z
olcMemberOfRefInt: TRUE
entryCSN: 20091009173500.139380Z#000000#000#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20091009173500Z

Mon résultat actuel:

En utilisant la configuration ci-dessus, je peux ajouter un NOUVEAU "groupOfNames" avec n'importe quel nombre d'entrées "member" et avoir tous les DN impliqués mis à jour avec un attribut "memberOf". Cela fait partie du comportement auquel je m'attendrais. Bien que je pense que ce qui suit aurait dû être accompli avec le membre de la superposition, je ne sais toujours pas comment faire ce qui suit et je serais heureux de recevoir tout conseil:

1. Ajoutez un attribut "membre" à un "groupOfNames" EXISTANT et créez automatiquement un attribut "memberOf" correspondant.
2. Supprimez un attribut "member" et supprimez automatiquement l'attribut "memberOf" correspondant.

J'ai eu du mal avec la même chose, la documentation openldap est minimaliste et peu utile du tout. Quand ils sont passés à une base de données de configuration (ce n'est pas une mauvaise idée en principe), toutes les options ont changé, donc lorsque les gens donnent l'exemple de /etc/ldap/slapd.conf, cela est inutile avec une configuration slapd moderne (comme Ubuntu).

J'ai finalement réussi à le faire fonctionner. Voici le résumé ... premier fichier LDIF:

dn: cn=module,cn=config
objectClass: olcModuleList
cn: module
olcModulePath: /usr/lib/ldap
olcModuleLoad: memberof

Deuxième fichier LDIF:

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

Ajoutez-les dans la base de données de configuration à l'aide de ldapadd (identique à la configuration normale).

Il ne met pas automatiquement à jour les données existantes dans la base de données, j'ai donc dû utiliser slapcat pour tout copier dans un fichier temporaire et visiter chaque groupe, supprimer le groupe et ajouter à nouveau le même groupe (force les attributs memberOf à mettre à jour correctement). Si vous commencez avec une base de données vide, elle mettra correctement à jour les attributs à mesure que des objets sont ajoutés.

Notez également que "olcDatabase = {1} hdb" est très typique, mais n'est pas garanti pour correspondre à votre configuration. Assurez-vous de vérifier celui-là.

J'ai récemment écrit à ce sujet sur mon blog, www.jordaneunson.com. J'ai copié et collé les parties pertinentes dans.

Ce que je devais faire était d'arrêter le service "slapd" sur mon serveur LDAP et d'éditer mon fichier slapd.conf et d'ajouter les deux lignes suivantes.

moduleload memberof.la
overlay memberof

J'avais déjà un groupOfNames appelé vpn, j'ai donc dû créer un fichier LDIF avec le contenu suivant:

dn: cn=vpn,ou=Groups,dc=shop,dc=lan
objectclass: groupofnames
cn: vpn
description: Users allowed to connect on VPN
member: uid=jordan,ou=People,dc=shop,dc=lan

Et ajouté ceci à ma base de données LDAP

slapadd -f file.ldif

Après cela, j'ai lancé le serveur LDAP dans le débogage pour vérifier les erreurs

slapd -d 99 -f /etc/ldap/slapd.conf 

et vérifié pour m'assurer que mon appartenance à "vpn" était répertoriée dans mon entrée utilisateur.

ldapsearch -h ldap -x -b "dc=shop,dc=lan" '(uid=jordan)' memberOf 

et bam! Succès!

jordan, People, shop.lan
dn: uid=jordan,ou=People,dc=shop,dc=lan
memberOf: cn=vpn,ou=Groups,dc=shop,dc=lan

J'ai donc renvoyé le service slapd et j'ai eu beaucoup de succès depuis lors. Pour un nouvel outil de gestion de l'interface graphique, j'utilise phpLDAPAdmin et je n'ai aucun problème avec l'attribut memberOf attribué et non attribué à mes utilisateurs.

Une dernière chose à noter est que l'attribut "memberOf" ne fait pas partie du schéma LDAP v3 de base et donc effectuer une recherche ldapsearch ne révélera pas cet attribut à moins qu'il ne soit spécifiquement interrogé. C'est pourquoi dans mon exemple ci-dessus, il est déclaré à la fin des paramètres ldapsearch.

J'espère que cela t'aides.

Edit: je viens de tester votre problème avec Apache Directory Studio: tant que j'entre la valeur de membre d'attribut dans son ensemble comme mentionné ci-dessus, cela fonctionne A-OK. Cependant, l'attribut memberOf n'apparaît pas dans l'entrée utilisateur. Cela est dû au fait que l'attribut memberOf ne fait pas partie du schéma LDAPv3. Pour vérifier qu'il existe, utilisez l'outil de ligne de commande ldapsearch:

ldapsearch -h ldap -x -b "dc=shop,dc=lan" '(uid=jordan)' memberOf