Password-Self-Service macht Murks :-)

openldap

#1

Hallo!

In Kürze: Neuerdings (?) scheint die App Self-Service beim Ändern eines Passwortes nicht mehr das Attribut userPassword zu befüllen, sondern nur noch sambaNTPassword und krb5Key. Von unseren 120 Nutzer*innen haben mittlerweile an die 10 von ihnen Passworteinträge, die nicht mehr ordentlich befüllt sind. Gab es da eine Änderung im Code? Gab es eine Änderung im Passwordreset-Konzept?

UCS LDAP-Passwort hat uns ein wenig auf die Spur gebracht, was da passiert; eigene Tests haben ergeben, dass Self-Service das Attribut userPassword nur noch mit e0s1S0VZfQ== (= {K5Key}) befüllt. Gibt es eine Möglichkeit, dass das Passwort via Self-Service erst im OpenLDAP gesetzt wird und darüber dann mit dem Samba-LDAP abgeglichen wird?

Besten Gruß
Masin Al-Dujaili


#2

Moin,

das ist schon immer so gewesen, wenn ich mich nicht irre. Das ist im Normalfall auch überhaupt kein Problem, denn Authentifizierung gegen’s LDAP läuft über einen Bind, und wenn der Bind im userPassword-Attribut den Wert {K5KEY} findet, so vergleicht er eben mit dem Kerberos-Attribut, und nicht mit dem userPassword-Attribut selber.

Das einzige Problem dabei besteht, wenn eine Anwendung userPasswort-Feld direkt auslesen möchte — wobei das im Normalfall keine Anwendung tun sollte, und das darf nach LDAP-ACLs eh nur der LDAP-Superuser.

Was ist denn Ihr eigentliches Problem?

m.


#3

Nachtrag: man kann sich so oder so nicht darauf verlassen, dass userPassword immer gefüllt ist, denn sämtliche Wege, die von ActiveDirectory-Seite aus das Passwort ändern (z.B. Strg+Alt+Entf unter Windows drücken, im Dialog dann »Passwort ändern« auswählen) setzen ebenfalls nur Samba-seitig die Kerberos- und NT-Passwort-Felder, die dann über den S4-Connector ins OpenLDAP synchronisiert werden. Das ist schlicht im AD so.


#4

Wir haben, wie in https://docs.software-univention.de/domain-4.0.html#ext-dom-syncrepl beschrieben, einen externen OpenLDAP-Server aufgesetzt. Damit sind wir wohl schon aus jedwedem Support raus, nehme ich an, auch wenn das in der offiziellen Doku beschrieben wird.

Bislang hatten wir unsere Webanwendung direkt gegen den UCS Primary authentifizieren lassen, der aber inhouse steht und nur per VPN erreichbar ist; seit ein paar Tagen testen wir das neue Setup, um eben auch im Falle eines Verlustes der Internetanbindung den externen Mitarbeitern Zugriff auf ebenjene Webanwendung zu ermöglichen. Bei dem OpenLDAP-Server scheint es aber keinen Automatismus zu geben, wonach der Bind im beschriebenen Falle gegen die Kerberos-Attribute authentifiziert.


#5

Huhu,

Es kann gut sein, dass das eine Univention-spezifische Erweiterung ist.

Warum setzen Sie dafür nicht einen UCS-basierten Server auf und joinen den in die Domäne (Rolle: DC Slave)? Dann hat der ebenfalls den LDAP-Inhalt dabei, und Sie haben das Problem nicht.

Gruß
mosu


#6

Hallo Herr Bunkus,

inwiefern ist es zur Lösung unseres Problems notwendig zu wissen, warum wir keinen UCS-basierten Server aufsetzten und als Slave-DC joinen?

Können Sie mit absoluter Sicherheit sagen, dass das Selfservice-Modul früher nicht vielleicht doch das userPassword-Attribut im LDAP gesetzt hat? Unsere User verwenden nämlich ausschließlich das Selfservice-Module, um ihre Passwörter zu setzen (Es sind keine Strg-Alt-Entf-Rechner im Spiel). Und fast alle unsere User haben einen Passworthash im LDAP-Attribut “userPassword”. Außer diejenigen, sich jetzt über das Selfservice-Modul ein neues Passwort vergeben, die bekommen {KRB5}.
Das legt aus unserer Sicht erst mal die Vermutung nahe, dass sich mit irgendeinem UCS-Update etwas geändert haben könnte.


#7

Huhu,

Zu Ihrem Problem gibt es keine direkte Lösung, weil das aktuelle Verhalten “working as intended” ist. Wir haben in einem ganz anderen Zusammenhang mit genau diesem Problem zu kämpfen gehabt, in der Zeit viel mit Univention kommuniziert und haben schließlich eine eigene (eingeschränkte) Variante des Self-Services implementiert, der den udm-Befehl zur Passwortänderung nutzt (siehe unten, warum).

Meine Frage habe ich dann daher gestellt, weil die Nutzung von UCS als LDAP-Server das Problem komplett umgehen würde.

Es gibt momentan schlicht mehrere verschiedene Varianten, wie Passwörter geändert werden können. Zwei davon triggern die Passwortänderung am OpenLDAP, wodurch userPasswort gesetzt wird; von dort aus wird das Passwort zu Samba4 synchronisiert. Die anderen Mechanismen kommen von der anderen Seite: sie triggern die Passwortänderung via Kerberos, schreiben also initial ins Samba, und von dort werden die modifizierten Kerberos- und NT-Passwort-Felder ins OpenLDAP synchronisiert.

Das Problem am zweiten Weg ist schlicht, dass Samba keinerlei Zugriff aufs neue Klartextpasswort bekommt, wenn ich das richtig verstanden habe, und damit gar nicht das für userPassword nötige Hashing vornehmen könnte. Außerdem gibt es im AD-LDAP-Schema das Feld für das Unix-Passwort schlicht nicht.

Hier die zwei Methoden, wir das Passwort OpenLDAP-seitig geändert werden kann:

  1. Über den Kommandozeilenbefehl univention-directory-manager bzw. udm, z.B. udm users/user modify --dn uid=mbunkus,… --set password=SuperSecret
  2. Über die webbasierte Univention Management Console, wenn man als Administrator angemeldet ist und dort im User-Modul einen Benutzer ändert

Hier ein paar Methoden, die letztlich über Kerberos laufen und damit nur noch {K5KEY} im OpenLDAP-userPassword-Attribut hinterlassen:

  1. Das Self-Service-Modul
  2. Wenn man sich als normaler User in der Univention Management Console anmeldet und sein eigenes Passwort ändert
  3. Wenn man’s über PAM ändert (z.B. Anmeldung via ssh, dann mit dem Befehl passwd)
  4. Wenn man an einem Windows-PC angemeldet ist und die dort vorhandene Funktion zur Passwortänderung nutzt

Nein, das mag früher vielleicht wirklich so gewesen sein. Ich bin mir aber nahezu absolut sicher, dass wir aufgrund der oben aufgeführten Randbedingungen nicht mehr in die Situation kommen werden, in der wir uns auch nur ansatzweise auf den Inhalt von userPassword verlassen können.

Gruß
mosu


#8

Für ein Simple Bind auf dem Syncrepl-System muss moduleload smbk5pwd.so und overlay smbk5pwd in slapd.conf eingetragen sein, damit die {K5KEY}-Passwörter funktionieren. Selbstverständlich muss auch das entsprechende Slapdmodul installiert sein. Für debian-basierte Systeme: apt install slapd-smbk5pwd
Vielleicht könnte man hier noch einen Hinweis dazu anbringen: https://docs.software-univention.de/domain-4.0.html#ext-dom-syncrepl
Auf unserrem UCS wird ein Modul namens k5pwd.so verwendet, das sich anscheinend in keiner slapd-Distribution, außer der von UCS befindet. Was hat es damit auf sich? Ist das das selbe wie smbk5pwd.so oder etwas ähnliches oder was ganz anderes? Wo gibt es die Sourcen zu k5pwd.so?

Grüße
Tobias Herre


#9

Huhu,

Das ist gut zu wissen.

Sie können die Quellen ganz normal mit apt-get source herunterladen, sofern vorher die Quell-Repos aktiviert wurden:

ucr set repository/online/sources=yes
apt-get update
apt-get install dpkg-dev
apt-get source slapd

Beim Entpacken der Sourcen werden diverse Patches angewendet, darunter auch debian/patches/univention-k5pwd und debian/patches/univention-k5pwd-empty-password, welche das Modul beinhalten.

Gruß
mosu


#10

Hi Moritz,

vielen Dank, das war sehr hilfreich. Ich habe gestern verzweifelt die Quellen vom UCS gesucht und nix gefunden :smiley: – eigentlich hätte ich mir ja denken können, dass es dafür einen Konfigurationsschlüssel gibt. Und ja, README zu k5pwd.c schreibt “This module was copied from smbk5pwd.”

Besten Gruß aus Berlin-Kreuzberg
Masin