Überprüfung der Replikation von OpenLDAP

Beim Einsatz von OpenLDAP, gerade ein einer multi Provider Umgebung, stellt sich immer wieder die Frage: Funktioniert meine Replikation? Wie ausgelastet sind meine Server? Die Nutzung des monitor-Backend beantwortet die Fragen schon sehr genau, gerade in eine multi Provider Umgebung, wenn dann auch noch die Konfiguration repliziert wird, sollten Sie auf gar keinen Fall auf den Einsatz von Monitoringsoftware verzichten. Alle aktuellen System zum Monitoring unterstützen das monitor-Backend vom OpenLDAP.

Mit der neuen Version (2.5.x und 2.6.x) des OpenLDAP ist aber auch ein kleines Kommandozeilenwerkzeug dazu gekommen, mit dem Sie, recht einfach, viele Informationen über den Zustand der OpenLDAP-Server und der Replikation erhalten können.  

Das Kommando heißt slapd-watcher und ist in allen aktuellen Versionen vorhanden. Als Parameter werden die zu überprüfenden Server angegeben und ein Benutzer mit Passwort der die Informationen auch auslesen kann: Das folgende Listing zeigt den Aufruf und die Informationen, die Sie erhalten:

slapd-watcher -b dc=example,dc=net ldaps://ldap-provider-01.example.net ldaps://ldap-provider-02.example.net ldaps://ldap-provider-03.example.net -x -D cn=admin,dc=example,dc=net -W

ldaps://ldap-provider-01.example.net
  Entries Bind Unbind  Search  Compare  Modify  ModDN   Add  Delete    Abandon   Extended  
Num  6     84      77        359          0          5            0             10          0          0         72  
Num/s 0.00 0.00  0.00   0.30       0.00       0.00       0.00       0.00       0.00       0.00    0.00  
contextCSN: 20221103122011.866810Z#000000#001#000000 idle
contextCSN: 20221103125320.893807Z#000000#002#000000 idle, sync’d 

ldaps://ldap-provider-02.example.net
  Entries  Bind  Unbind  Search  Compare  Modify  ModDN   Add     Delete    Abandon   Extended  
Num  6     19         11        288          0          5          0                7          0           0                  7  
Num/s 0.00  0.00 0.00      0.20       0.00       0.00     0.00       0.00       0.00       0.00             0.00  
contextCSN: 20221103122011.866810Z#000000#001#000000 idle, sync’d
contextCSN: 20221103125320.893807Z#000000#002#000000 idle

ldaps://ldap-provider-03.example.net
 Entries  Bind  Unbind  Search  Compare Modify  ModDN  Add     Delete    Abandon   Extended  
Num  6     17        9        288          0          5           0              5          0           0                7  
Num/s 0.00 0.00  0.00   0.20       0.00       0.00       0.00       0.00       0.00      0.00        0.00  
contextCSN: 20221103122011.866810Z#000000#001#000000 idle, sync’d
contextCSN: 20221103125320.893807Z#000000#002#000000 idle, sync’d

Über die verschieden Werte können Sie so sehr schnell sehen, ob die Replikation funktioniert (Die Anzahl der Entries sollte bei einer multi Provider Umgebung auf allen Servern identisch sein) und wie stark die Server ausgelastet sind. Sollte z.B bei einem der Server die Anzahl der „Search“ Einträge erheblich von den anderen abweichen, kann das daran liegen, dass bestimmte Clients immer nur einen der Server abfragen. 

Der Einsatz von slapd-watch, kann aber kein Monitoring ersetzten sonder dient dazu schnell Informationen des Zustands Ihrer Server zu bekommen. 

Posted in Allgemein | Leave a comment

Fehlender NS-Record in reverse-zone

Wenn Sie in Ihrem Samba-AD den Bind9 einsetzen und eine oder mehrere reverse-Zonen verwalten, kann es bei zwei Gelegenheiten dazu kommen, dass der NS-Record der reverse-Zonen nicht mehr vorhanden ist und dann der Bind9 nicht mehr startet. 

Der erste Fall ist der, dass Sie den DC auf dem Sie die reverse-Zone angelegt haben demoten dann werden auch alle DNS-Einträge des DCs gelöscht, also auch alle NS-Records. Bei den Forward-Zone gibt es dann keine Problem, da alle DCs diese Rolle übernehmen. Bei den reverse-Zonen fehlt dann aber der NS-Record. Umgehen können Sie das Problem in dem Sie immer mindestens zwei DCs als NS-Record in die Zone eintragen, entweder über den Windows DNS-Manager oder auf einem DC über das Kommando:

samba-tool dns add dc1 56.168.192.in-addr.arpa @ NS
recover-dc2.example.net -U administrator

Der zweite Fall in dem Ihnen der NS-Record fehlt, ist nach einem eventuellen Recovery der gesamten Domäne aus dem Backup, dann haben alle reverse-Zonen keine NS-Record mehr. Der dann erstellte neu DC wird zwar in die forward-Zonen eingetragen, nicht aber in die reverse-Zonen. Sie haben jetzt die Möglichkeit alle reverse-Zonen mit dem samba-tool zu löschen und neu anzulegen, oder Sie gehen wie folgt vor:

  • Stoppen Sie den Samba-Dienst
  • Stellen Sie mit samba_upgradedns auf den internen DNS-Server um
  • Erweitern die Zeile server services in der smb.conf um den Parameter dns
  • Starten den Samba-Dienst neu
  • Erzeugen den NS-Record wie oben beschrieben
  • Schalten dann wieder mit samba_upgradedns –dns-backend=BIND9_DLZ  auf den Bind um
  • Entfernen den Parameter dns aus der smb.conf
  • Starten den Samba-Dienst neu
  • Dann können Sie den Bind9 wieder starten und alle NS-Record sind wieder vorhanden.

So bekommen Sie auch nach einem Recover der Domäne alle Zonen wieder funktionsfähig.

Posted in Allgemein | Leave a comment

Overlay memberof hat den Status „deprecated“ in OpenLDAP 2.6

In der neuen Version 2.6 vom OpenLDAP hat das Overlay memberof den Status „deprecated“ bekommen und wird wohl, über kurz oder lang, ganz aus dem OpenLDAP entfernt werden. Dazu ein Auszug aus der manpage zum slapo-memberof:

Note that this overlay is deprecated and support will be 
dropped in future OpenLDAP releases. Installations should use the 
dynlist overlay instead. Using this overlay in a replicated 
environment is especially discouraged.

Wer zusätzlich die, nun funktionierende, Technik der Replikation des cn=config nutzen will, sollte schon jetzt auf den Einsatz des Overlays memberof verzichten. Hat eh nicht immer das gemacht was es sollte.

Die Einrichtung des Overlays dynlist ist auch kein Hexenwerk. Ich werde hier beschreiben wie eine einfach Einrichtung im cn=config durchgeführt werden kann.

Im ersten Schritt benötigen Sie das Schema dyngroup. Da es zur Zeit nur die Möglichkeit gibt den OpenLDAP 2.6 selber zu bauen oder die Symas-Pakete zu nutzen, gebe ich hier die Pfade für die Symas-Pakete an: 

ldapadd -Y EXTERNAL -H ldapi:/// -f \
/opt/symas/etc/openldap/schema/dyngroup.ldif

Wenn Sie schon die dynamische Konfiguration vom cn=config eingerichtet haben, werden gleich alle LDAP-Server mit dem neuen Schema ausgestattet.

Im nächsten Schritt laden Sie das Modul dynlist und fügen Sie das Overlay in Ihre Objekt-Datenbank ein. Dafür können Sie eine LDIF-Datei mit dem folgenden Inhalt erstellen:

dn: cn=module{0},cn=config 
changetype: modify
add: olcModuleLoad
olcModuleLoad: dynlist.la

dn: olcOverlay=dynlist,olcDatabase={2}mdb,cn=config
changetype: add
objectClass: olcDynamicList
objectClass: olcOverlayConfig
olcOverlay: dynlist
olcDlAttrSet: groupOfURLs memberURL member

Achten Sie darauf, dass Sie die für Ihren LDAP-Server passende Nummer der Datenbank angeben!

Die Attributliste hinter dem Attribut olcDlAttrSet haben dabei die folgende Bedeutung

  • groupOfURLs ist der Gruppentyp der hier verwendet wird
  • memberURL ist das Attribut das aus dem Objekt der dynamischen Gruppe ausgewertet wird
  • member sorgt dafür, dass der vollständige DN in die Gruppe eingetragen wird

Nach dem Sie Ihren LDAP-Server soweit vorbereitet haben, können Sie jetzt die erste dynamische Gruppe anlegen. Im folgenden Listing sehen Sie eine LDIF-Datei für das Anlegen einer dynamischen Gruppe

dn: cn=adminuser,ou=groups,dc=example,dc=net 
objectClass: groupOfURLs
cn: adminuser
memberURL: ldap:///dc=example,dc=net??sub?(employeeType=IT)

Hier wird eine Gruppe cn=adminuser angelegt und jeder Benutzer der jetzt bei dem Attribut employeeType den Eintrag IT besitzt, wird automatisch Mitglied der Gruppe. Wird der Benutzer gelöscht oder sein Attribut employeeType wird verändert, wird er automatisch aus der Gruppe entfernt. Das funktioniert auch bei der Replikation von cn=config

Natürlich können Sie hier beliebig viele Gruppen anlegen und der Filter für die Mitgliedschaft kann auch komplex aufgebaut werden, denn Sie können hier alle möglichen logischen Verknüpfungen der OpenLDAP-Filter nutzen.

Posted in Allgemein | Leave a comment

Ubuntu pam-mount Active Directory

Wenn Sie versuchen auf einem Ubuntu 20.04 System pam-mount zusammen mit einem Share und  Active Directory  zu nutzen, und sich nach der Konfiguration das Mounten fehlschlägt, dann liegt es daran, dass es bei Ubuntu Abhängigkeitsprobleme gibt. Wenn Sie auf dem Client das Paket  libpam-mount installieren und anschließen auf ein Share im Aktive Directory via Kerberos-Authentifizierung zugreifen, wird das nicht funktionieren. Erst wenn Sie das Paket ktutils installieren wird das Mounten funktionieren. 

Hier auch noch einmal der Hinweis: Pam-mount verwendet immer noch SMBv1 als Standardprotokoll. Sowohl aktuelle Windows-Server als auch Samba verlangen aber mindestens SMBv2 besser wäre 3.1.1. Vergessen Sie daher nicht in den Optionen des zu moutenende Shares den Parameter ver=3.1.1 zu setzen.

Posted in Allgemein | Leave a comment

Fehlermeldung NT_STATUS_INVALID_TOKEN nach Update

Am 09.11.2021 wurde für alle aktuellen Samba-Versionen (4.13, 4.14, 4.15) ein Sicherheitsupdate bereitgestellt. Bei dem Update geht es, unter anderem, um die Sicherheit der Kerberos-Tickets. Wenn ein Domänenbenutzer auf einen lokalen Benutzer gemapped wird, kann das dazu führen, dass ein Angreifer zusätzliche Rechte bekommt. Mehr zu der Sicherheitslücke finden sie HIER. Einem gemapptem Domänenbenutzer wird durch das Update diese Möglichkeit genommen sich auf einen lokalen Benutzer zu mappen.

Jetzt ist es aber so, dass der Administrator der Domäne immer auf den root (also UID=0 und GID=0) gemapped wird. Durch das Update verliert der Administrator dadurch sein Rechte. Wenn Sie jetzt z.B. einen Windows-Client in die Domäne aufnehmen, mit dem Administrator, dann wird der join funktionieren, aber der DNS-Eintrag für den Client wird nicht erstellt und mit einer entsprechenden Fehlermeldung quittiert.

Der beste Weg diese Problem zu umgehen ist es, eine AD-Benutzer in die Gruppe „domain admins“ aufzunehmen und das Join nur noch mit diesem Benutzer durchzuführen. 

Sollte das aus irgend einem Grund nicht möglich sein, haben Sie immer noch die Möglichkeit den neuen smb.conf Parameter „min domain uid = 0“ zu setzen. Der Standardwert ist hier „1000“. Dann klappt es auch wieder mit dem Administrator. Besser ist aber auf jeden Fall der Weg über den Benutzer in der Gruppe „domain admins“ zu gehen.

Posted in Allgemein | Leave a comment

TOTP für die Benutzer einrichten

In diesem Teil zum Thema TOTP mit OpenLDAP soll es darum gehen, die Benutzerobjekte im LDAP um die TOTP-Attribute zu erweitern. Zwei Lösungsansätze werde ich hier beschreiben: Einmal die Zuweisung über ein Skript, das Sie als root ausführen und dann den Benutzern den QR-Code zukommen lassen. Die zweite Möglichkeit nutzt den LAM-Pro um den Benutzern über das SelfService-Module die Möglichkeit zu geben, sich den QR-Code selber zu generieren. Als root geben Sie den Benutzer lediglich das Initialpasswort für die Authentifizierung am SelfService-Modul.

Da ich für den Teil mit dem LAM einige Screenshots verwende, stelle ich den eigentlichen Artikel als PDF zum Download bereit.

Posted in Allgemein | Leave a comment

Neu Vagrant-Box für CTDB

Endlich habe ich es geschafft, ich habe eine neue Vagrant-Box mit Debian 11 erstellt. Diese neue Box enthält ein Grundsystem und eine zusätzliche Partition. Die zusätzliche Partition (2GB) ist mittels LVM2 und thin-provisioned eingerichtet, so dass auch GlusterFS-Snapshots ausprobiert werden können.

Die Box ist extra so gebaut, dass damit eine Samba-Umgebung mit Doamincontroller und beliebig vielen Gluster/CTDB -Knoten aufgebaut werden kann. Bei der Box handelt es sich um eine Box für VirtualBox als Virtualisierer. Daher sind die Voraussetzungen lediglich eine installierte VirtualBox in der aktuellen Version und eine aktuellen Version von Vagrant. 

Damit Sie die Umgebung einfach und schnell installieren können, lege ich hier noch einen Vagrantfile ab, in dem ein Domaincontroller mit Samba 4.14 (aus den Paketen von Louis van Belle) eingerichtet wird. Der DC nutzt dabei den Samba-internen DNS-Server. (entfernen Sie bei der Datei die Endung .txt)

Am 22.04.2022 habe ich eine neu Version des Vagrantfiles hinterlegt. Die virtuelle Platte ist etwas größer, da sich keine updates mehr eingespielt werden konnten. Die Versionsnummer ist angepasst und ein paar klein Änderungen am Skript selber habe ich vorgenommen. Unter anderem wird jetzt Samba 4.15 verwendet.

Durch eine Variabel können Sie festlegen, wie viele Gluster/CTDB-Knoten Sie auf einmal einrichten wollen. Bei der Einrichtung der Knoten werden die Samba 4.14 Pakte und GlusterFS 9 Pakte installiert. 

Auf allen Knoten werden zwei Netzwerkkarten in zwei verschiedenen Host-only-Netzwerken eingerichtet und konfiguriert. Als Resolver wird automatisch der DC auf allen Knoten eingetragen. Auch die Datei /etc/hosts wird durch das Skript angepasst. 

Durch die Vorkonfiguration können Sie sich ganz auf die Einrichtung von GlusterFS und CTDB konzentrieren. Alle benötigten Pakete sind installiert und es besteht sofort ein Produktivnetz in dem auch der DC eingerichtet ist und ein Heartbeat-Netz für die Kommunikation der Knoten untereinander. 

Ob Sie jetzt ein Gluster-Cluster mit zwei replicated-nodes oder mit 10 replicated-distributed-nodes einrichten wollen, passen Sie einfach die entsprechenden Variable an und das Skript erstellt die benötigten Hosts automatisch.

Viel Spaß bei Testen.

Posted in Allgemein | Leave a comment

Wie geht es eigentlich mit OpenLDAP weiter?

Heute mal was zum OpenLDAP. Ja, der Eine oder Andere wird jetzt sagen: „Der ist doch eh tot“. Nur stimmt das nicht. Die Entwicklung geht auch hier weiter. Zur Zeit hat die aktuelle Version die Versionsnummer 2.5.6, die auch schon sehr stabil läuft und auch schon genutzt werden kann. Leider gibt es noch für keine Distribution die entsprechenden Pakte. Selber bauen ist angesagt. Nur im Debian Experimental gibt es die Pakte schon, aber wer möchte Experimental schon produktiv einsetzen? Genau, niemand.

Aber wie geht es weiter mit OpenLDAP?

Für 2.4 gibt es nur noch kritische Updates, Neuerungen wird es hier nicht mehr geben. 2.4 hat den Status „end of live“ erreicht. Im September dieses Jahres wird es dann die Version 2.6 geben, die dann über längere Zeit mit Updates versorgt wird. Mit dem Erscheinen der Version 2.6 wird es keine Updates mehr für 2.4 geben. Ob das wieder 14 Jahre sind wie bei 2.4 wage ich zu bezweifeln. Im nächsten Jahr wird dann eine Version 2.7 erscheinen. Mit dem Erscheinen der 2.7 wird es keine Updates für 2.5 mehr geben.

Lohnt der Umstieg auf OpenLDAP 2.6? Ja, auf jeden Fall, denn einen performanteren Verzeichnisdienst wird man so schnell nicht finden.

Warum denken viele OpenLDAP sei tot? Da gibt es eine Firma die unbedingt ihren 389DS durchsetzen will und OpenLDAP das Wasser abgraben möchte. Wer von OpenLDAP auf 389DS wechsel will, sollte sich das aber genau überlegen. Eine Übernahme der Daten ist nicht so einfach realisierbar. Das Sicherheitskonzept ist ein komplett anderes. Die ACLs sind komplett anders und müssen alle neu eingerichtet werden. Auch fehlen viele Funktionen, die der OpenLDAP bereitstellt, noch komplett. Im 389DS so ist es momentan (so mein Stand) noch nicht möglich einen LDAP-Proxy zu realisieren. Wer also seine LDAP-Server z.B. in einer DMZ eingerichtet hat und damit die Daten für die Authentifizierung externe Mitarbeiter aus dem Active Directory holen will, kann das nur mit OpenLDAP realisieren.

Alles vielleicht für den Einen oder Anderen kein Thema, aber zu bedenken ist auch, mit dem 389DS wir IMMER Java auf dem LDAP-Server benötigt, auch wenn keine grafische Oberfläche installiert werden soll. Dann kommt dazu, dass die Java-Version die mit dem 389DS installiert wird, eine Oracle-Lizenz unterliegt. Spätestens an dem Punkt sollte man sich Gedanken machen warum man eigentlich auf open source Software gesetzt hat.

Ich habe die Version 2.5 jetzt schon eine Zeit lang getestet und viele neue Möglichkeiten haben schon was, so gibt es jetzt die Möglichkeit automatisch Client-Zertifikate vom OpenLDAP erstellen zu lassen. Einfach die eigene CA hinterlegen und alles andere geht dann automatisch. Auch die Passwortverschlüsselung mit Argon2 funktioniert jetzt mit einem eigenen Overlay. Zusammen mit der Möglichkeit der Einrichtung einer zwei Faktoren Authentifizierung kann man den Sicherheitsstandard schon sehr hoch ansetzen.

Endlich wird auch in den dynamischen Gruppen das „member“-Attribut bei der Suche ausgewertet, so ist es jetzt möglich, dynamische Posix-Gruppen zu erzeugen, denn dann im Dateisystems eines Fileservers Rechte zugewiesen werden können. Was bringt das? Ich erzeuge für jede meiner Abteilung oder Projektgruppe eine eigene dynamische Posic-Gruppe. Der Gruppe gebe ich auf unterschiedlichen Fileservern verschieden Rechte. Dann suche ich mir ein Benutzerattribut, das beim Eintrag eins bestimmten Wertes, den Benutzer automatisch zum Mitglied der Gruppe macht. Entferne ich das Attribut, wir der Benutzer automatisch auch aus der Gruppe entfernt und verliert somit auch sofort die Rechte auf den den Fileservern.

Auch was die Performance angeht wurde viel gearbeitet. Die Replikation wurde komplett überarbeitet auch wird durch ein effektives Loadbalancing werden die anfragen beim Einsatz mehrerer LDAP-Server besser auf die alle LDAP-Server verteilt.

Wer mehr über die Neuerungen wissen möchte, hier ist ein interessanter Artikel der auf jeden Fall lesenswert ist.

Also, immer ein Auge auf die tot gesagten haben 😉

Posted in Allgemein | Leave a comment

Das neue Samba4 Buch ist da

Am 13.08 ist es endlich so weit, die neue Auflage meines Samba4 Buches erscheint. Dieses Mal konnte ich im Januar direkt mit der Version 4.14 beginnen. Der Dank dafür gilt auf jeden Fall Louis van Belle und Björn Baumbach. Beide haben mir, direkt beim erscheinen der rc1 Version, die Pakte für Debian gebaut, so dass ich sofort beginnen konnte. Auch der Lektor und der Verlag haben dafür gesorgt, dass das Buch schnell fertig geworden ist. So schnell habe ich eine neue Auflage noch nie geschrieben. Wegen Corona war ich viel zu Hause und konnte so erheblich mehr Zeit mit dem Schreiben des Buchs verbringen. Vieles habe ich aus der alten Auflage entfernt, da es entweder nicht mehr relevant oder veraltet war. Aber auch sehr viel Neues ist dazu gekommen. Endlich ist es möglich auch GPOs für Linux-Clients einzurichten. 

Wie immer freue ich mich auch hier wieder über Feedback zum Buch. 

Posted in Samba | Leave a comment

OpenLDAP ACLs mit Sets

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.

 

Posted in LDAP | Leave a comment