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 beschrieben: 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

2FA und OpenLDAP mit Argon2 als Passwordhash

Im letzten Artikel ging es um die Einrichtung von TOTP für die Authentifizierung. In dem Artikel habe ich auf das OpenLDAP-Modul pw-totp gesetzt, da es auf den ersten Blick recht einfach einzurichten war. Ist es auch, nur habe ich dann erfahren, dass das Modul alt ist und nicht mehr genutzt werden soll, besser sei es das Modul otp zu nutzen, das neu ist und im OpenLDAP 2.5 bereitgestellt wird. Dann macht es Sinn auch gleich eine gute Verschlüsselung der Passwörter einzubringen. Der Tipp war, die Argon2-Verschlüsselung zu nutzen, das von OpenLDAP in der Version 2.5 voll unterstützt wird. Also, alles wieder auf Anfang und das ganze neu Eingerichtet. Als Grundlage für den OpenLDAP habe ich dieses mal Debian Experimental (Danke Roland für den Tipp) genutzt, denn da ist die Version 2.5.5 schon vorhanden. Also jeder der das hier nachbauen will, ist nicht mehr auf den Bau des OpenLDAP angewiesen. Leider ist das Module autoca hier nicht enthalten, sprich die Einrichtung der Client-Zertifikate aus dem letzten Artikel klappt hier noch nicht.

Als Pakete habe ich installiert:

  • slapd
  • ldap-utils
  • argon2

Debian generiert sofort eine dynamische Konfiguration für den OpenLDAP, auf die ich auch aufgesetzt habe. Mein erst Schritt war dann den Passwordhash {ARGON2} einzurichten. Dafür wird das entsprechende Modul im OpenLDAP benötigt. Mit der folgenden LDIF-Datei wird das Modul geladen:

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

Anschließend kann der Passwordhash mit der folgenden LDIF-Datei gesetzt werden:

dn: olcDatabase={-1}frontend,cn=config
changetype: modify
add: olcPasswordHash
olcPasswordHash: {ARGON2}

Wichtig ist hier, dass der Passwordhash in der Datenbank {-1}frontend,cn=config eingetragen wird und nicht direkt in cn=config.

Nach dem jetzt der OpenLDAP-Server den Passwordhash kennt, soll jetzt als erstes das Passwort des rootdn umgestellt werden. Durch die Umstellung des Passworts des rootdn können Sie auch gleich testen, ob die Authentifizierung mittels eines Argon2-Passworts funktioniert. Das folgende Listing zeigt die Änderung des Passworts:

dn: olcDatabase={1}mdb,cn=config
changetype: modify
replace: olcRootPW
olcRootPW: {ARGON2}$argon2i$v=19$m=4096,t=3,p=

1$MTIzNDU2Nzg5$t0cMsY/yM7a2wxx

btHWiTtEso2cW2iKrsOHvVCa0+A

Aber warum jetzt Argon2 und nicht mehr SSHA oder PBKDF2 als Passwordhash? Bei diesen Passwordhashes kann, mit relativ preiswerter Hardware ein Brute-Force Angriff auf die Passwörter durchgeführt werden. Oft werden hierfür Grafikprozessoren benutzt. Was dieser preiswerten und schnellen Hardware aber fehlt, ist Arbeitsspeicher. Da kommt dann Argon2 ins Spiel, denn Argon2 erzeugt große Vektoren im Arbeitsspeicher, wie viel Speicher dafür benötigt wird, kann beim erzeugen des Passworts festgelegt werden. Mehr zu Argon2 gibt es hier. Zu beschreiben, wie jetzt welche Parameter beim erzeugen eines Passworts gesetzt werden sollten, würde den Rahmen hier sprengen. Ein guter Einstig zu dem Thema finden Sie hier.

Das Passwort für den rootdn wurde von mir mit den Standardwerten von Argon2 erzeugt. Das Passwort habe ich mit dem folgenden Kommando erzeugt:

echo -n „geheim“ | argon2 „123455678“ -e

Das Passwort ist später „geheim“, „12345678“ ist der salt-Wert für den Passwordhash.

Jetzt können Sie, mittels „ldapsearch -x -D cn=admin,dc=example,dc=net -W -LLL“ den LDAP-Baum abfragen. Wenn das klappt, funktioniert auch der Passwordhash in Argon2.

Um die Passwörter in Argons2 und später auch TOTP testen zu können, habe ich eine OU „ou=users,dc=example,dc=net“ angelegt in der alle neuen Benutzer abgelegt werden. Den ersten Benutzer sehen Sie in der folgenden LDIF-Datei:

dn: cn=u1,ou=users,dc=example,dc=net
objectClass: posixAccount
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
loginShell: /bin/bash
homeDirectory: /home/u1
uid: u1
uidNumber: 10010
gidNumber: 10000
sn: u
givenName: 1
userPassword: {ARGON2}$argon2i$v=19$m=4096,t=3,p=

1$MTIzNDU2Nzg5$t0cMJsY/yM7a2w

xxbtHWiTtEso2cW2iKrsOHvVCa0+A
cn: u1

Nach dem Anlegen des Benutzers können sie auch hier wieder mit ldapsearch testen, ob eine Authentifizierung mit dem Argon2-Passwort möglich ist. Damit ist der erste Schritt zur zwei-Faktoren-Authentifizierung mit sicherem Passwort schon abgeschlossen.

Jetzt kommt der zweite Teil, Einrichten von TOTP mit dem neuen OpenLDAP-Modul otp.la. Das Modul muss als erstes geladen werden, dafür sehen Sie hier die folgenden LDIF-Datei:

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

Jetzt tragen Sie noch mittels einer LDIF-Datei das Overlay in die Objektdatenbank ein:

dn: olcOverlay=otp,olcDatabase={1}mdb,cn=config
objectClass: olcOverlayConfig

Achten Sie bei der Nummerierung der Datenbank auf Ihre Konfiguration.

Die manpage zu slapo-otp beschreibt zwar alle Parameter die benötigt werden genau, aber wie jetzt welcher Parameter zu setzen ist, fehlt ganz. Was sagen Entwickler dazu? „Wieso Dokumentation, steht doch alles im Quellcode!“ Im folgenden Listing sehen Sie die Konfiguration für TOTP:

dn: ou=users,dc=example,dc=net
changetype: modify
add: objectClass
objectClass: oathTOTPParams

add: oathOTPLength
oathOTPLength: 6

add: oathHMACAlgorithm
# choose SHA1, algorithm OIDs are specified in RFC 8018
oathHMACAlgorithm: 1.2.840.113549.2.7

add: oathTOTPTimeStepPeriod
oathTOTPTimeStepPeriod: 30

add: oathTOTPTimeStepWindow
oathTOTPTimeStepWindow: 3

Hier werden für die OU ou=users,dc=example,dc=net drei Parameter gesetzt:
– oathOTPLength: 6 (Die Länge des OTP-Tokens für den zweiten Faktor)
– oathHMACAlgorithm: 1.2.840.113549.2.7 (Der ODI für den Verschlüsselungsalgorithmus)
– oathTOTPTimeStepPeriod: 30 (Die Dauer der Gültigkeit des Tokens)
– oathTOTPTimeStepWindow: 3 (maximales Gültigkeitsfenster hier 3*30 Sekunden)

Dieses sind die Standardwerte, die auch vom Googleauthenticator und freeOTP+ genutzt werden.

Die Parameter werden immer eine OU zugewiesen und könne anschließend an die Benutzer übergeben werden.

Jetzt wird ein sharedkey für die Errechnung des Tokens benötigt, die folgenden Kommandos erstellen eine Datei mit einem sharedkey im data-Format:

  • $ touch sharedkey
    $ chmod 600 sharedkey
    $ openssl rand 20 > sharedkey
    $ base32 sharedkey
    7XNAA3KOAFGUTBSPWUGTNC6OSKMRKANW

Das Ergebnis ist der Schlüssel der in die entsprechende App, z.B. Googleauthenticator, eingetragen werden muss, aus der dann der sechs-Stellige Token generiert wird.

Jetzt fehlt nur noch die Anpassung des Benutzers. Dazu erzeugen Sie eine LDIF-Datei mit dem folgenden Inhalt:

dn: cn=u1,ou=users,dc=example,dc=net
changetype: modify
add: objectClass
objectClass: oathTOTPToken

add: oathTOTPParams
oathTOTPParams: ou=users,dc=example,dc=net

add: oathSecret
oathSecret:< file:///root/sharedkey

add: objectClass
objectClass: oathTOTPUser

add: oathTOTPToken
oathTOTPToken: cn=u1,ou=users,dc=example,dc=net

Damit wird das Benutzerobjekt um die benötigten Parameter erweitert. Damit der Benutzer den Schlüssel nicht von Hand in die App eintragen muss, kann aus dem Schlüssel ein QR-Code erzeugt werden, der dann einfach mit der App gescanned werden kann.

Ist der Schlüssel eingetragen, kann der erste Test mit dem Benutzer durchgeführt werden. Einfach ein:

ldapsearch -x -D cn=u1,ou=users,dc=example,dc=net“ -W -LLL

Ausführen. Bei der Fragen nach dem Passwort geben Sie als erstes das Passwort ein, unmittelbar im Anschluss den sechs-Stelligen Token, z.B „geheim123456“ Ohne Leer- oder Trennzeichen.

Das war es dann schon, jetzt können Sie nach und nach alle Benutzer auf eine zwei-Faktoren-Authentifizierung umstellen.

Damit die Anwender nicht den Schlüssel in die App eintragen müssen, ist es sinnvoll einen QR-Code aus dem Schlüssel zu erstellen, der dann eingescanned werden kann. Dazu wird das Programm qrencode benötigt. Erst wird der Text für den QR-Code erstellt und anschließend der QR-Code.

QR=“otpauth://totp/ldap:u1@example.net?secret=7XNAA3KOAFGUTBSPWUGTNC6OSKMRKANW&issuer=stka&30&digits=6&algorithm=SHA1″
echo $QR | qrencode -s9 -o u1@example.net.png

Selbstverständlich können Sie den Text für den QR-Code auch direkt an das Programm übergeben.

Das war der zweite Teil zur zwei-Faktoren-Authentifizierung. Ich denke, ein Teil wird noch kommen. Darin wird es dann wieder darum gehen, dass ganze über Ansible einzurichten.

Posted in LDAP | Tagged , , , | Leave a comment

Der Fehlerteufel hat beim letzten Artikel zugeschlagen

Leider ist mir beim erstellen des tar-Files für die Rollen ein Fehler unterlaufen, der LDAP-Server wird leider nach der Installation mit der Rolle nicht starten. Problem ist, das Attribut „olcPasswordHash“ habe ich dort (wie bei anderen Konfigurationen auch) direkt nach cn=config geschrieben, die neuen Passwordhashes wie {TOTP} müssen aber unter {-1}frontend eingetragen werden. Ich habe das entsprechende Skript geändert neu Verlinkt. Wenn Sie die Dateien schon runtergeladen haben, dann einfach erneut runterladen. Oder einfach diesem Link hier folgen, da sind auch die richtigen Dateien hinterlegt. 

Posted in Allgemein | Leave a comment

OpenLDAP 2.5 mit TOPT und autoca

Seit einiger Zeit gibt es nun endlich den OpenLDAP 2.5. Lange wurde er angekündigt. Ich habe hier die Version 2.5.4 genutzt um die beiden neuen Overlays autoca und totp einzurichten und zu testen. Da es noch keine Pakete für Debian 10 gibt, habe ich OpenLDAP aus den Quellen gebaut. Um bei späteren Versionen möglichst schnell einen Server einrichten zu können, habe ich hier wieder voll auf Ansible gesetzt. Ich habe eine neue Rolle definiert, die folgende Tasks durchführt:

  • Installation der Build-Umgebung mit allen Abhängigkeiten
  • Download der Quellen vom OpenLDAP
  • Bauen des OpenLDAP und allen benötigten Modulen
  •  Einrichten der Systemd-Skripte zum Start des OpenLDAP
  • Konfigurieren des OpenLDAP über ein Template
  • Einspielen der ersten Objekte
  • Anlegen eines simpleSecurityObjecs ldap-admin. Dieses Objekt hat alle Rechte an allen Objekten 
  • Anlegen eines simpleSecurityObjects repl-user später für die Replikation genutzt werden soll
  • Einrichten der Overlays autoca und totp

Um totp anschließend testen zu können, habe ich in der rolle openldap25 im Verzeichnis files ein Skript (create-qr.bash) abgelegt, dass den shared-key und den QR-Code für einen Benutzer erstellt.
Das Overlay autoca erzeugt für jeden Benutzer, ein Client-Zertifikat. Das Zertifikat wird bei einer Suche nach dem entsprechenden Attribut im Objekt des Benutzer abgelegt. Auch dieser Schritt wird mit dem Script durchgeführt.
In der aktuellen Konfiguration wird lediglich die Anmeldung mit einem TOTP eingerichtet. Durch Anpassung des Passwort-Hashes ist es auch möglich, auf eine zwei Faktoren Authentifizierung umzustellen. Die Umstellung werde ich hier zu einem späteren Zeitpunkt ergänzen. 

Die benötigten Rollen um den Server einzurichten finden Sie HIER.

Posted in Allgemein | Leave a comment

Benutzer gelöscht

Ich bin heute mal durch die List der hier angemeldeten Benutzer gegangen und habe aufgeräumt. Dabei habe ich alle Konten gelöscht, deren Emaildomäne nicht auflösbar war. Auch habe ich einige Benutzer gelöscht mit kryptischen Namen und die dazu auch keinen echten Namen angegeben haben. Sollte ich jemande gelöscht haben der hier noch aktiv ließt und unter einen der Kategorien gefallen sein, dann tut es mir Leid. Bitte dann einfach neu Anmelden und eine Emailadresse verwenden die  nachvollziehbar ist, In Zukunft werde ich alle Benutzer, die sich mit einer Wegwerfadresse registrieren sofort löschen. Sonst wird das für mich zu unübersichtlich.

Posted in Allgemein | Leave a comment