UCS LDAP-Passwort

UCS - Univention Corporate Server
#1

Unsere Konstellation:

  • zentraler Master 4.0.3 für mehrere OU/Schulen mit UCS@School ohne Samba
  • in den Schulen jeweils einen DC-Slave EDU 4.0.3 und einen DC-Slave GOV 4.0.3, beide mit UCS@School/Samba4
  • als Clients benutzen wir hauptsächlich Kubuntu 14.04 in beiden Netzen, Passwortänderungen über KDM und Systemeinstellungen funktionieren.

Wir wollen/müssen für eine externe Anwendung das LDAP-Passwort auf dem Master auslesen. Dies funktioniert auch soweit super, aber:

  1. Ändern des Passworts mit der UMC auf dem Master als Administrator:
    -> Passwort wird geändert
    -> UCS-LDAP Passwort ausgelesen mit ‘univention-ldapsearch uid=xxxx’ -> userPassword:: ‘gecrypted lang’

  2. Ändern des Passworts über die UMC auf dem DC-Slave als User:
    -> Passwort wird geändert
    -> UCS-LDAP Passwort ausgelesen mit ‘univention-ldapsearch uid=xxxx’ -> userPassword:: e0s1S0VZfQ== (bedeutet (K5KEY))

  3. Ändern des Passworts über die UMC auf dem DC-Slave als OU-Admin
    -> Passwort wird geändert
    -> UCS-LDAP Passwort ausgelesen mit ‘univention-ldapsearch uid=xxxx’ -> userPassword:: ‘gecrypted lang’

  4. Ändern des Passworts am W7-Client oder Kubuntu-Client(über Systemeinstellungen oder über KDM nach Aufforderung zur Passwortänderung)
    -> Passwort wird geändert
    -> UCS-LDAP Passwort ausgelesen mit ‘univention-ldapsearch uid=xxxx’ -> userPassword:: e0s1S0VZfQ== (bedeutet (K5KEY))

Die Synchronisation kann man im Logfile des S4-Connector nachverfolgen - sync from ucs, sync to ucs. Bei Punkt 3 erfolgt eine weitere Synchronisation sync from ucs.

Die Authentifizierung der Clients am DC-Slave funtioniert in alle 4 Fällen.
Da unsere Lehrer und Mitarbeiter hauptsächlich über Punkt 2 oder Punkt 4 ihr Passwort ändern, wird ständig als userPassword nicht das aktuelle Passort eingetragen.

Wo liegt der Fehler?

Vielen Dank
Gruss
Detlef Stang

Password-Self-Service macht Murks :-)
#2

Hallo Herr Stang,

zum besseren Verständnis des eigentlichen Problems möchte ich gerne noch etwas genauer nachfragen.

Wenn ich Sie richtig verstehe, besteht aktuell ein Problem mit einem externen Dienst, der die Benutzerpasswörter aus dem LDAP ausliest. Als Grund dafür könnte die Tatsache in Betracht kommen, dass die Passwörter (je nach Methode 1-4) auf unterschiedliche Art und Weise im LDAP gespeichert. Ist das so korrekt?

Viele Grüße
Dr. Alexander Kläser

#3

Hallo Herr Kläser,

das Auslesen des Attributes ‘userPassword’ per univention-ldapsearch/ldapsearch auf dem Master/im UCS-LDAP funktioniert.

Bei Methode 1 und 3, bei denen das gehashte Passwort aus dem Attruibut ‘userPassword’ übernommen wird, funktioniert dann die Athentifizierung auf dem externen Dienst.

Bei Methode 2 und 4 wird das Passwort - in diesem Fall ‘e0s1S0VZfQ==’ - aus dem Attribut ‘userPassword’ auch übernommen. Die Authentifizierung auf dem externen Dienst schlägt dann fehl, weil ja hier nicht das gehashte Passwort des Users eingetragen/übernommen wurde, sondern ‘e0s1S0VZfQ==’.

Soweit ich das System verstanden habe, gibt es allgemein gesagt das UCS-LDAP, Samba-LDAP und die Kerberos-Datenbank für die Hinterlegung u.a. des Userpassworts.

Unser Problem ist, das das gehashte Passwort nicht bei allen 4 Methoden im LADP-Attribut ‘userPassword’ eingetragen wird und damit nicht konsistent ist.

Wir brauchen immer das aktuelle LDAP-Passwort des Users.

Gruesse
Detlef Stang

#4

Hallo Herr Stang,

Ihre Beobachtung ist korrekt, das gehashte userPassword kann lediglich dann bereitgestellt werden, wenn die Passwort-Änderung direkt über das UCS Managment-System auf OpenLDAP-Seite läuft. Sobald eine Passwortänderung gegen Kerberos oder auf Samba-Seite durchgeführt wird, funktioniert das so nicht mehr. Grund dafür ist die Synchronisierung der Verzeichnis-Daten zwischen OpenLDAP und Samba (mit seinem eigenen LDAP-Dienst). Wird auf Kerberos-/Samba-Seite eine Passwortänderung durchgeführt, dann sind lediglich die dazu angelegten Kerberos-Hashes sowie der sambaNTPassword-Hash vorhanden. Bei der Synchronisierung von Samba zu OpenLDAP hin kann also nicht mehr der userPassword-Hash erzeugt werden, da das Klartextpasswort auf OpenLDAP-Seite nicht vorliegt. Somit wird ein LDAP-Eintrag wie dieser erzeugt:

root@ucs-dc-9713:~# univention-ldapsearch -LLL uid=test dn userPassword krb5Key sambaNTPassword | ldapsearch-wrapper 
dn: uid=test,cn=users,dc=mydomain,dc=intranet
sambaNTPassword: A4B25D5F2B51E082A312394CA2E6E993
krb5Key:: MB2hGzAZoAMCARehEgQQpLJdXytR4IKjEjlMoubpkw==
krb5Key:: ME+hKzApoAMCARKhIgQg9ColR2aojQ1qS2BHkdC+tRBYodv/5uzg/dB4QD8fiEWiIDAeoAMCAQOhFwQVTVlET01BSU4uSU5UUkFORVR0ZXN0
krb5Key:: MD+hGzAZoAMCARGhEgQQYajfvCNuCFYbiJQnhbLJIKIgMB6gAwIBA6EXBBVNWURPTUFJTi5JTlRSQU5FVHRlc3Q=
krb5Key:: MDehEzARoAMCAQOhCgQIGkO/zgf4Gv6iIDAeoAMCAQOhFwQVTVlET01BSU4uSU5UUkFORVR0ZXN0
krb5Key:: MDehEzARoAMCAQGhCgQIGkO/zgf4Gv6iIDAeoAMCAQOhFwQVTVlET01BSU4uSU5UUkFORVR0ZXN0
userPassword:: e0s1S0VZfQ==

Als Alternative scheint es mir die Möglichkeit zu geben, sambaNTPassword (=das gehashte NT-Passwort) statt userPassword zu nutzen. Vielleicht wäre es für den externen Dienst ja auch möglich, zur Überprüfung von Credentials bspw. einen LDAP-Bind durchzuführen. Dann bräuchten die Passwort-Hashes nicht ausgelesen zu werden.

Ich hoffe dies hilft Ihnen weiter.

Viele Grüße
Dr. Alexander Kläser

#5

Hallo Herr Kläser,

vielen Dank erstmal.
Das ist nicht gut für uns.

Ich habe doch noch ein paar Verständnisfragen.

Wenn ich mich am EDU-Slave als normaler Lehrer an der UMC unter Web-Services -> UCS@school oder Administration -> Systemeinstellungen anmelde und unter Benutzer mein eigenes Passwort ändere, wird es geändert, aber das Attribut userPasswort hat den falschen Eintrag. Wirkt die Arbeit mit der UMC hier nur gegen Kerberos bzw. Samba?

Wenn ich mich am EDU-Slave als Lehrer, der auch in der Gruppe admin-ou ist, oder als Administrator anmelde und unter Schuladministration -> Passwörter(Lehrer) das Passwort setze, wird es geändert, ebenso das Attribut userPassword.
Ich arbeite an der selben/gleichen UMC des EDU-Slave, aber mit einem anderen Ergebnis -> Kerberos, Samba und OpenLDAP wird geändert.

Anmeldungen am GOV-Slave als normaler Lehrer/Mitarbeiter - Maske Passwort ändern, Passwort wird geändert, aber Attribut userPassword hat falschen Eintrag.

Melde ich mich als normaler Lehrer/Mitarbeiter am Master am, bekomme ich die Maske mein Passwort zu ändern. Die Änderung schlägt aber fehl - Fehler ‘Unable to reach any changepw server in realm xxxxx.xxxxx’.

Alle 4 Varianten arbeiten über ein UCS Managment-System, aber an verschiedenen Zielen.
Schade, das dies nicht vereinheitlicht ist oder ist dies ein Fehler in unserem System.

Viele Gruesse
Detlef Stang

#6

Hi,

I found this post looking for the e0s1S0VZfQ== string. I speak Spanish so I read it thanks to Google Translator.

I am facing the same issue with my deployment. Most users change theirs passwords using method 4 (SSSD AD on Ubuntu Gnome 16.04 clients).

I am trying to sync users passwords with G Suite using Google Cloud Directory Sync, so I don’t have to expose the UCS server to the web in order to allow users to authenticate through SAML / Google Apps for Work Connector.

There is no way to update the userPassword flied with the real hashed password when it is updated through Kerberos? G Suite is not compatible with NT hashes and I would like to avoid using plaintext passwords.

Thanks,

#7

The idea of using G Suite with UCS and SAML is to not expose the user passwords (or their hashes) to Google. Therefor the use of SAML.

The complete communication with SAML is done through the users browser. Google does never talk to UCS directly. There is no need to open the UCS server to the internet.
If you look at the Wikipedia page for SAML, you’ll find a picture there, where you see this:

  • “Service Provider” is Google
  • “User Agent” is your users browser
  • “Identity Provider” is your UCS server

UCS server and Google don’t talk directly, when authenticating a user or service.

Greetings
Daniel Tröder

#8

Hi Daniel,

Thanks for the response. I don’t fully explain the problem. We are implementing UCS on a small civil engineering firm, where most field engineers don’t hit the office in several days. We have a working VPN solution (pfSense + OpenVPN) setup both at the cellphones and company owned laptops, but sometimes they need to login to Google (mainly Gmail and Drive) using computers no managed by the company (mostly to upload / download construction drawings).

In order to allow this engineers to authenticate to Google using SAML from an external location, the UCS login page must be reachable from the internet, which is what we would like to avoid.

If I would have access to some form of the user’s hashed password (in Base64, unsalted MD5, or unsalted SHA-1 format), I could use GCDS to push passwords to G Suite.

The ideal solution would be to emulate the G Suite Password Sync approach, which is an AD listener who triggers a sync on a password change. I was looking at the Univention Directory Listener, however from your response on bug 44743 I infer it is not possible.

For now I am working on your suggestion to enable existing users on the G Suite Connector, and then look for a way to securely expose the UCS SAML service to the internet.

Thanks,

#9

I’m bringing this back up because I had a conversation with someone else who referred to this. I think vargax knows all of this by now, but for anyone coming back to this topic because of searching for plaintext passwords or password hashes:

  • UCS does not store user passwords in plaintext
  • Base64 is not a hashing algorithm, but an encoding (one can easily decode it. Hashes are only one-way)
  • Unsalted MD5 and SHA1 hashes are considered broken and should be treated as a security risk

Regarding the original problem:

I can understand those concerns, but I think it’s worth a second thought. I would rather expose the UCS SAML SSO Login page than syncing passwords that are either not encrypted (plaintext, base64) or use weak hashing algorithms (unsalted MD5/SHA1). To me, the latter sounds like a much more insecure choice.

Syncing UCS User Passwords with Google Workspace
Mastodon