Heute möchte ich mal ein Thema zum OpenLDAP ansprechen, dass nicht so bekannt ist, aber doch nützlich sein kann. Das Thema ACLs wird in vielen Büchern und auf vielen Webseiten ausführlich beschrieben, so auch in meinem Buch und allen meinen Unterlagen, aber einen Teil finden Sie recht selten und zwar die Nutzung von „sets“. Beim Einsatz von „sets“ geht es um die Vergabe von Berechtigungen in Relation zu anderen Objekten. Worum geht es dort:
1. Vergabe von Berechtigungen über ACLs an verschachtelte Gruppen.
Wenn Sie die Gruppe (A) in der Gruppe (B) als Mitglied eintragen und anschließend der Gruppe (A) Rechte im LDAP-Baum geben, heißt das nicht, dass auch die Mitglieder der Gruppe (B) die Rechte erhalten, denn normaler Weise verfolgt der OpenLDAP verschachtelte Gruppen nicht. Mit den „sets“ ist das aber möglich.
2. Verfolgung von Referenzen
Stellen Sie sich vor, Sie haben bei allen Benutzern einer Abteilung im Attribut „manager“ den Abteilungsleiter eingetragen und der soll über eine ACL Rechte an bestimmten Attributen seiner Mitarbeiter erhalten. Dann können Sie diese Aufgabe sehr einfach über „sets“ realisieren. Hier soll als Beispiel, bei allen Benutzerobjekten der „ou=Verwaltung“, der Abteilungsleiter „cn=Verw al,ou=users,ou=Verwaltung,dc=example,dc=net“ im Attribute „manager“ eingetragen werden.
3. Stellvertreter Regeln
Nehmen wir den Fall aus Punkt 2. und gehen mal davon aus, dass der Abteilungsleiter einen Stellvertreter hat der ebenfalls diese Rechte erhalten soll. Der Stellvertreter ist über das Attribut „secretary“ beim Abteilungsleiter eingetragen und erhält die benötigten Rechte über eine entsprechend angepasste ACL. Gehen wir auch hier noch mal einen Schritt weiter. Der Abteilungsleiter hat mehrere Stellvertreter von denn aber nur eine bestimmte Gruppe die Rechte erhalten soll, dann können Sie hier auch noch über eine Gruppenmitgliedschaften die Rechte nur diesen Stellvertretern geben.

Wenn Sie sich die Technik einmal genauer angeschaut haben, werden Sie bestimmt schnell auf eigene Ideen kommen.

Da bekanntlich alle Theorien grau sind, folgen jetzt zu den einzelnen Punkten Beispiele:

Beginnen möchte ich mit den verschachtelten Gruppen.
Für die Vergabe von Passwörtern soll eine neue Gruppe des Typs groupOfNames erstellt werden, in der ein Benutzer, in diesem Fall „uid=skania,ou=users,dc=example,dc=net“, eingetragen ist. Dieser Benutzer soll für alle Benutzer der Abteilung „ou=verwaltung,dc=example,dc=net“ die Passwörter ändern können.
Hier eine Auszug der beiden Gruppen:

dn: cn=pw-set,ou=groups,dc=example,dc=net
objectClass: groupOfNames
cn: pw-set
member: cn=all-sec,ou=groups,ou=verwaltung,dc=example,dc=net
member: uid=skania,ou=users,dc=example,dc=net

dn: cn=all-sec,ou=groups,ou=Verwaltung,dc=example,dc=net
objectClass: groupOfNames
cn: all-sec
member: cn=sec1,ou=users,ou=verwaltung,dc=example,dc=net
member: cn=sec2,ou=users,ou=verwaltung,dc=example,dc=net
member: cn=sec3,ou=users,ou=verwaltung,dc=example,dc=net

Die Gruppe „cn=all-sec“ hat drei Mitglieder und ist wiederum selbst Mitglied der Gruppe „cn=pw-set“. Jetzt fehlt noch die ACL die der Gruppe cn=pw-set das Recht zur Änderung der Passwörter gibt und dadurch auch indirekt den Mitglieder der Gruppe cn=all-sec. Starten wir mir der ACL für die Gruppe cn=pw-set, die dann um das „set“ erweitert wird.

Da es hier darum geht die Passwörter zu ändern, wird die ACL für die Passwörter erweitert:

access to attrs=userPassword,shadowLastChange
by anonymous auth
by self write
by group/groupOfNames/member=“cn=pw-set,ou=groups,dc=example,dc=net“ write
by * none

So erhalten erst mal nur die Mitglieder der Gruppe „cn=pw-set“ das Recht die Passwörter zu ändern. Jetzt geht es dann darum, die ACL für die Verschachtelte Gruppe zu erweitern. Dazu passen Sie die ACL wie folgt an:

access to attrs=userPassword,shadowLastChange
by anonymous auth
by self write
by set=“[cn=pw-set,ou=groups,dc=example,dc=net]/member* & user“ write
by * none

Beide Regeln können natürlich auch in die dynamische Konfiguration eingetragen werden, dazu sehen Sie hier erst die LDIF-Datei für die einfache Gruppen ACL:

ACHTUNG! Übernehmen Sie die LDIF-Dateien nicht einfach in Ihr System, sondern passen Sie die Dateien an Ihre Konfiguration an.

dn: olcDatabase={2}mdb,cn=config
changetype: modify
delete: olcAccess
olcAccess: {1}
–
add: olcAccess
olcAccess: {1}to attrs=userPassword
by self write
by group/groupOfNames/member=“cn=pw-set,ou=groups,dc=example,dc=net“ write
by anonymous auth
by * none
–
delete: olcAccess
olcAccess: {2}
–
add: olcAccess
olcAccess: {2}to attrs=shadowLastChange
by self write
by group/groupOfNames/member=“cn=pw-set,ou=groups,dc=example,dc=net“ write
by anonymous auth
by * none

Jetzt folgt die ACL mit der Anpassung für die Verschachtelten Gruppen:

dn: olcDatabase={2}mdb,cn=config
changetype: modify
delete: olcAccess
olcAccess: {1}
–
add: olcAccess
olcAccess: {1}to attrs=userPassword
by self write
by set=“[cn=pw-set,ou=groups,dc=example,dc=net]/member* & user“ write
by anonymous auth
by * none
–
delete: olcAccess
olcAccess: {2}
–
add: olcAccess
olcAccess: {2}to attrs=shadowLastChange
by self write
by set=“[cn=pw-set,ou=groups,dc=example,dc=net]/member* & user“ write
by anonymous auth
by * none

Jetzt können Sie Gruppen vom Typ groupOfNames oder groupOfUniqeNames verschachteln und Rechte im LDAP-Baum vergeben. Soll eine weitere Gruppe die Möglichkeit erhalten, wie hier im Beispiel, die Passwörter zu ändern, brauchen Sie lediglich die Gruppe in die Gruppe cn=pw-set eintragen, die ACL brauchen Sie jetzt nicht mehr anzupassen.

Aber was ist, wenn in der Gruppe auf die Sie verweisen wollen nicht der vollständige DN als Mitglied enthalten ist? Also zum Beispiel bei einer Posix-Gruppe. Auch das ist kein Problem, auch die Verschachtelung dieser Gruppen ist möglich, dann ist die Syntax für die ACL aber etwas anders. Hier sehen Sie ein Beispiel für die statischen Konfiguration:

access to attrs=userPassword,shadowLastChange
by anonymous auth
by self write
by set=“[cn=posix,ou=groups,dc=example,dc=net]/memberUID & user/uid“ write
by * none

Auch hierzu folgt noch ein Beispiel für die dynamische Konfiguration:

dn: olcDatabase={2}mdb,cn=config
changetype: modify
delete: olcAccess
olcAccess: {1}
–
add: olcAccess
olcAccess: {1}to attrs=userPassword
by self write
by set=“[cn=posix,ou=groups,dc=example,dc=net]/memberUID & user/uid“ write
by anonymous auth
by * none

Kommen wir jetzt zum nächsten Punkt: Verfolgung von Referenzen.
Ähnlich wie Sie es vielleicht von dynamischen Gruppen her kennen, wird bei der Verfolgung von Referenzen der Inhalt eines Attributs ausgewertet. Bei dem entsprechenden Attribut handelt es sich um eine Attribut in dem der vollständige DN eines Benutzers eingetragen ist. Im Beispiel habe ich geschrieben, dass die Benutzerobjekte in der „ou=verwaltung“ alle den DN „cn=Verw al,ou=users,ou=verwaltung,dc=example,dc=net“ als „manager“ eingetragen haben. Jetzt soll der Abteilungsleiter an allen Benutzern seiner Abteilung das Schreibrecht erhalten.

Nachdem Sie das Attribut bei den gewünschten Benutzer gesetzt haben, benötigen Sie nur noch die ACL um die Rechte zu vergeben. Auch hier zeige ich Ihnen als erstes wieder ein Beispiel für eine statische ACL:

access to dn.sub=“ou=users,ou=verwaltung,dc=example,dc=net“
by set=“this/manager & user“ write
by * break

Für die dynamische Konfiguration schauen Sie sich das folgende Listing an. Achten Sie auch hier darauf, dass Sie die Nummerierung der ACL nicht einfach übernehmen, sonder an Ihre Umgebung anpassen.

dn: olcDatabase={2}mdb,cn=config
changetype: modify
add: olcAccess
olcAccess: {3}to dn.sub=ou=users,ou=verwaltung,dc=example,dc=net
by set=“this/manager & user“ write
by * break

Nach dem Sie die ACL eingespielt haben, kann jetzt, der als „manager“ eingetragenen Benutzer, die von Ihnen freigegeben Attribute ändern.

Last but not least geht es im folgenden Beispiel um die Stellvertreter des Abteilungsleiters. Hier gibt es wieder zwei Möglichkeiten. Fangen wir mit der einfacheren an:

Beim Abteilungsleiter wurden bestimmte Benutzerobjekte als „secretary“ eingetragen, siehe das folgende Listing:

dn: cn=Verw al,ou=users,ou=verwaltung,dc=example,dc=net
objectClass: posixAccount
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
loginShell: /bin/bash
homeDirectory: /home/verw-al
uid: verw-al
cn: Verw al
userPassword:: e1NTSEF9OURIWjB4ZVVmekl5WHVhcC9lOHo5OWZvQkRrMFdqaFo=
uidNumber: 10006
gidNumber: 10000
sn: al
givenName: Verw
employeeType: Abteilungsleiter
secretary: cn=sec1,ou=users,ou=verwaltung,dc=example,dc=net
secretary: cn=sec2,ou=users,ou=verwaltung,dc=example,dc=net
secretary: cn=sec3,ou=users,ou=verwaltung,dc=example,dc=net

Diese Hier eingetragen Benutzerobjekte sollen jetzt in der Lage sein, die Eigenschaften der Benutzer in der „ou=verwaltung“ zu ändern. Sie sollen aber nicht alle in der Lage sein die Passwörter der Benutzer anzupassen. Deshalb wird nur die ACL für den Zugriff auf die „ou=verwaltung“ geändert. Da die ACL für die Passwörter vor der entsprechenden ACL steht, betrifft die Änderung nicht die Passwörter. Achten Sie daher stehts auf die richtige Reihenfolge der ACLs. Hier die geänderte statische ACL für den Zugriff auf die Objekte:

access to dn.sub=“ou=users,ou=verwaltung,dc=example,dc=net“
by set=“this/manager & user“ write
by set=“this/manager/secretary & user“ write
by * break

Sie können hier die Abhängigkeit der Attribute von einander sehen. Ein Benutzer der bei Objekten als „manager“ eingetragen wurde und selbst über „secretary“-Einträge verfügt gewährt diesen den Zugriff.

Hier folgt jetzt noch die geänderte ACL für die dynamische Konfiguration:

dn: olcDatabase={2}mdb,cn=config
changetype: modify
delete: olcAccess
olcAccess: {3}
–
add: olcAccess
olcAccess: {3}to dn.sub=ou=users,ou=verwaltung,dc=example,dc=net
by set=“this/manager & user“ write
by set=“this/manager/secretary & user“ write
by * break

Jetzt hat unser Abteilungsleiter aber drei Stellvertreter, aber nur zwei von denen sollen in der Lage sein die Passwörter der Benutzer zu ändern. Diese beiden Stellvertreter wurden in der Gruppe „cn=secretary,ou=groups,ou=verwaltung,dc=example,dc=net“ zusammengefasst:

dn: cn=secretary,ou=groups,ou=verwaltung,dc=example,dc=net
objectClass: groupOfNames
cn: secretary
member: cn=sec1,ou=users,ou=verwaltung,dc=example,dc=net
member: cn=sec2,ou=users,ou=verwaltung,dc=example,dc=net

Als erstes entfernen Sie jetzt die Gruppe „cn=all-sec“ aus der Gruppe „cn=pw-set“, denn in der Gruppe sind alle Stellvertreter Mitglied und hätten durch die Verschachtelung der Gruppe immer das Recht die Passwörter zu verändern.

Damit nur noch der als „manager“ eingetragene Benutzer und die Stellvertreter aus der Gruppe „cn=secretary“ das Recht habe Passwörter zu ändern, wird jetzt die ACL wie folgt angepasst:

access to attrs=userPassword,shadowLastChange
by anonymous auth
by self write
by set=“this/manager & user“ write
by set=“this/manager/secretary & [cn=secretary,ou=groups,ou=verwaltung,dc=example,dc=net]/member* & user“ write
by * none

Auch diese Regel können Sie einfach von links nach rechts lesen: Der als „manager“ eingetragene Benutzer und die beim „manager“ eingetragen „secretary“ (wenn sie dann Mitglied der Gruppe cn=secretary sind) erhalten das Recht die Passwörter zu ändern.

Da Benutzer der Verwaltung über andere ACLs (die hier nicht erklärt werden) nur Zugriff auf die Objekte der „ou=verwaltung“ erhalten, können sie auch nur die Passwörter der Benutzer anpassen, denn auf die anderen Benutzerobjekte anderer Abteilungen haben Sie keinen Zugriff.

Fehlt nur noch die Anpassung der dynamischen Konfiguration. Dafür folgt jetzt der Inhalt der LDIF-Datei für die Anpassungen:

dn: olcDatabase={2}mdb,cn=config
changetype: modify
delete: olcAccess
olcAccess: {1}
–
add: olcAccess
olcAccess: {1}to attrs=userPassword
by self write
by set=“this/manager & user“ write
by set=“this/manager/secretary & [cn=secretary,ou=groups,ou=verwaltung,dc=example,dc=net]/member* & user“ write
by anonymous auth
by * none
–
delete: olcAccess
olcAccess: {2}
–
add: olcAccess
olcAccess: {2}to attrs=shadowLastChange
by self write
by set=“this/manager & user“ write
by set=“this/manager/secretary & [cn=secretary,ou=groups,ou=verwaltung,dc=example,dc=net]/member* & user“ write
by anonymous auth
by * none

Ich hoffe, dass ich Ihnen mit dieser kleinen Anleitung ein paar Anregungen für die vereinfachte Umsetzung von ACLs gegeben habe. Vielleicht kann der Eine oder Andere damit auch Aufgaben im eigen LDAP lösen, die vorher nur schwer lösbar waren.