Wie konfiguriere ich die Reverse Group Membership Maintenance auf einem openldap-Server? (Mitglied von)

Ich arbeite derzeit an der Integration der LDAP-Authentifizierung in ein System und möchte den Zugriff basierend auf der LDAP-Gruppe einschränken. Der einzige Weg, dies zu tun, ist über einen Suchfilter und daher glaube ich, dass meine einzige Option die Verwendung des Attributs "memberOf" in meinem Suchfilter ist. Ich verstehe, dass das Attribut "memberOf" ein Betriebsattribut ist, das vom Server für mich erstellt werden kann, wenn für einen beliebigen Eintrag "groupOfNames" auf dem Server ein neues Attribut "member" erstellt wird. Mein Hauptziel ist es, einem vorhandenen "groupOfNames" -Eintrag ein "member" -Attribut hinzuzufügen und dem von mir angegebenen DN ein passendes "memberOf" -Attribut hinzuzufügen.

Was ich bisher geschafft habe:

Ich bin noch ziemlich neu in der LDAP-Administration, aber basierend auf dem, was ich im openldap-Administratorhandbuch gefunden habe, scheint Reverse Group Membership Maintence, auch bekannt als "memberof overlay", genau den gewünschten Effekt zu erzielen.

Auf meinem Server wird derzeit eine Paketinstallation (slapd unter Ubuntu) von openldap 2.4.15 ausgeführt, die die Laufzeitkonfiguration "cn = config" verwendet. Die meisten Beispiele, die ich gefunden habe, verweisen immer noch auf die ältere "slapd.conf" -Methode der statischen Konfiguration, und ich habe mein Bestes versucht, die Konfigurationen an das neue verzeichnisbasierte Modell anzupassen.

Ich habe die folgenden Einträge hinzugefügt, um das Overlay-Modul memberof zu aktivieren:

Aktivieren Sie das Modul mit 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

Das Overlay für die Datenbank wurde aktiviert und die Standardeinstellungen (groupOfNames, member, memberOf usw.) dürfen verwendet werden.

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

Mein aktuelles Ergebnis:

Mit der obigen Konfiguration kann ich eine NEUE "groupOfNames" mit einer beliebigen Anzahl von "member" -Einträgen hinzufügen und alle beteiligten DNs mit einem "memberOf" -Attribut aktualisieren. Dies ist Teil des Verhaltens, das ich erwarten würde. Obwohl ich der Meinung bin, dass das Folgende mit dem Overlay-Mitglied hätte erreicht werden sollen, weiß ich immer noch nicht, wie ich das Folgende tun soll, und würde mich über jeden Rat freuen:

1. Fügen Sie einem EXISTING "groupOfNames" ein "member" -Attribut hinzu und lassen Sie ein entsprechendes "memberOf" -Attribut automatisch erstellen.
2. Entfernen Sie ein "member" -Attribut und lassen Sie das entsprechende "memberOf" -Attribut automatisch entfernen.

Ich habe mit der gleichen Sache zu kämpfen, die Openldap-Dokumentation ist minimalistisch und kaum hilfreich. Als sie zu einer Konfigurationsdatenbank übergingen (im Prinzip keine schlechte Idee), änderten sich alle Optionen. Wenn die Leute also ein Beispiel aus /etc/ldap/slapd.conf angeben, ist dies mit einer modernen slapd-Konfiguration (wie Ubuntu) nutzlos.

Ich habe es endlich geschafft. Hier ist die Zusammenfassung ... erste LDIF-Datei:

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

Zweite LDIF-Datei:

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

Fügen Sie sie mit ldapadd (wie gewohnt) in die Konfigurationsdatenbank ein.

Es ist nicht automatisch die vorhandenen Daten aktualisieren in der Datenbank, so dass ich slapcat zu verwenden brauchte alles heraus in eine temporäre Datei zu kopieren, und jede Gruppe besuchen, die Gruppe löschen und die gleiche Gruppe wieder ein hinzufügen (Kräfte die memberOf Attribute Update korrekt). Wenn Sie mit einer leeren Datenbank beginnen, werden die Attribute beim Hinzufügen von Objekten korrekt aktualisiert.

Beachten Sie auch, dass "olcDatabase = {1} hdb" sehr typisch ist, aber nicht garantiert mit Ihrem Setup übereinstimmt. Stellen Sie sicher, dass Sie dies überprüfen.

Ich habe kürzlich in meinem Blog www.jordaneunson.com darüber geschrieben. Ich habe die relevanten Teile in kopiert und eingefügt.

Ich musste lediglich den Dienst "slapd" auf meinem LDAP-Server anhalten, meine Datei "slapd.conf" bearbeiten und die folgenden zwei Zeilen hinzufügen.

moduleload memberof.la
overlay memberof

Ich hatte bereits eine groupOfNames namens vpn, also musste ich eine LDIF-Datei mit folgendem Inhalt erstellen:

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

Und dies zu meiner LDAP-Datenbank hinzugefügt

slapadd -f file.ldif

Danach habe ich den ldap Server im Debug hochgefahren, um nach Fehlern zu suchen

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

und überprüft, um sicherzustellen, dass meine Gruppenmitgliedschaft von "vpn" in meinem Benutzereintrag aufgeführt war.

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

und bam! Erfolg!

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

Also habe ich den Slapd-Service wieder hochgefahren und hatte seitdem viel Erfolg. Für ein neues GUI-Management-Tool verwende ich phpLDAPAdmin und habe keine Probleme damit, dass das memberOf-Attribut meinen Benutzern zugewiesen und nicht zugewiesen wird.

Als letztes ist zu beachten, dass das Attribut "memberOf" nicht Teil des grundlegenden LDAP v3-Schemas ist und daher bei einer LDAP-Suche dieses Attribut nur dann angezeigt wird, wenn es speziell abgefragt wird. Aus diesem Grund wird es in meinem obigen Beispiel am Ende der ldapsearch-Parameter deklariert.

Hoffe das hilft.

Bearbeiten: Ich habe gerade Ihr Problem mit Apache Directory Studio getestet: Solange ich den Attribut-Member-Wert als Ganzes wie oben erwähnt eingebe, funktioniert es mit A-OK. Das Attribut memberOf wird jedoch nicht im Benutzereintrag angezeigt. Dies liegt daran, dass das Attribut memberOf nicht Teil des LDAPv3-Schemas ist. Um zu überprüfen, ob es vorhanden ist, verwenden Sie das Befehlszeilentool ldapsearch:

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