Comment configurer la maintenance des membres du groupe inversé sur un serveur OpenLDAP? (membre de)
Je travaille actuellement sur l'intégration de l'authentification LDAP dans un système et je voudrais limiter l'accès en fonction du groupe LDAP. La seule façon de le faire est par un filtre de recherche et donc je crois que ma seule option pour être 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 " membre " est créé pour une entrée " groupOfNames " sur le serveur. Mon principal objectif est d'être en mesure d'ajouter un " membre " attribut à un existant " groupOfNames " entrée et ont une correspondance " memberOf " attribut ajouté à la DN je fournis.
Ce que je suis parvenu à réaliser jusqu'à présent:
Je suis encore assez nouveau pour l'administration LDAP, mais en fonction de ce que j'ai trouvé dans le guide de l'administrateur OpenLDAP, il ressemble à appartenance à un groupe inverse Maintence alias " memberOf superposition " permettrait d'atteindre exactement l'effet que je cherche.
Mon serveur est en cours d'exécution d'une installation de package (slapd sur ubuntu) de OpenLDAP 2.4.15 qui utilise la configuration d'exécution de type "cn = config". La plupart des exemples que j'ai trouvé encore référence la méthode " slapd.conf " ancienne de configuration statique et j'ai essayé de mon mieux pour adapter les configurations du nouveau modèle à base de répertoire.
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 courant:
En utilisant la configuration ci-dessus, je suis en mesure d'ajouter un nouveau " groupOfNames " avec un certain nombre de " membre " entrées et ont toutes les mises à jour avec DNs impliqué un " memberOf " attribut. Cela fait partie du comportement que je me attends. Même si je crois que ce qui suit aurait dû être accompli avec la superposition de memberOf, je ne sais toujours pas comment faire ce qui suit et je serais heureux de recevoir des conseils:
- Ajouter un attribut " membre " à un EXISTANTS " groupOfNames " et ont un attribut " memberOf " correspondant est automatiquement créé.
- Supprimer un attribut " membre " attribut et ont le " memberOf " correspondant " est automatiquement supprimé.
Je me débats avec la même chose, la documentation OpenLDAP est minimaliste et à peine utile du tout. Quand ils sont passés à une base de données de configuration (pas une mauvaise idée en principe), toutes les options changèrent ainsi lorsque des personnes donnent l'exemple de /etc/ldap/slapd.conf, il est inutile avec une configuration SLAPD moderne (telle que Ubuntu).
J'ai finalement obtenu ce travail. 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 à celle de la configuration normale).
Cela fait ne met pas automatiquement à jour les données existantes Dans la base de données, j'ai donc besoin d'utiliser SLAPCAT pour tout copier dans un fichier temporaire et de visiter chaque groupe, de supprimer le groupe et d'ajouter le même groupe de nouveau. (force le membre attribu des attributs à la mise à jour correctement). Si vous commencez par une base de données vide, il mettra à jour correctement les attributs tels que des objets sont ajoutés.
Notez également que "OLCDATABASE = {1} HDB" est très typique, mais pas garantie de correspondre à votre configuration. Assurez-vous de vérifier celui-là.
J'ai écrit à ce sujet récemment sur mon blog, www.jordaneunson.com J'ai copié et collé les parties pertinentes.
Ce que je devais faire était d'arrêter le service "Slapd" sur mon serveur LDAP et de modifier mon fichier slapd.conf et ajoutez les deux lignes suivantes.
moduleload memberof.la
overlay memberof
J'ai déjà eu des noms de groupe appelés VPN, donc j'ai 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 tiré le serveur LDAP à DEBUG pour vérifier les erreurs
slapd -d 99 -f /etc/ldap/slapd.conf
et vérifié pour vous assurer que mon adhésion à mon groupe de "VPN" a été répertorié dans ma participation 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 tiré le service Slapd Sauvegarde et a eu beaucoup de succès depuis. Pour un nouvel outil de gestion de l'interface graphique, j'utilise Phpldapadmin et n'avez aucun problème avec le membre de l'attribut membre et non assigné à mes utilisateurs.
Une dernière chose à noter est que l'attribut "Membre de" ne fait pas partie du schéma de base LDAP V3 et faisons ainsi qu'un LDAPSearch ne révélera pas cet attribut sauf si 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 je saisis la valeur d'élément d'attribut dans son ensemble, comme mentionné ci-dessus, cela fonctionne A-OK. Cependant, l'attribut membre ne s'affiche pas dans l'entrée de l'utilisateur. En effet, l'attribut membre ne fait pas partie du schéma LDAPV3. Pour vérifier qu'il s'agit d'utiliser l'outil de ligne de commande LDAPSearch:
ldapsearch -h ldap -x -b "dc=shop,dc=lan" '(uid=jordan)' memberOf