Univention Bugzilla – Bug 15062
{LANMAN} userPassword ablösen
Last modified: 2011-12-19 12:41:43 CET
Wie z.B. an Bug 14279 bearbeitet, unterstützt Samba Lanman Password Hashes nicht mehr in der Standardkonfiguration. Als Alternative wäre denkbar, den {SASL} Passwort Mechanismus für das userPassword zu verwenden, über den OpenLDAP angewiesen wird, intern SASL zu fragen, wenn vom Client ein Simple Bind versucht wird. SASL wiederum kann dann z.B. Kerberos (GSSAPI) zu Authentifikation verwenden. Diskutiert wurde das auf Samba Technical: http://lists.samba.org/archive/samba-technical/2003-June/030121.html http://lists.samba.org/archive/samba-technical/2004-February/034587.html Mögliche Nachteile sind die Stabilität der Speicherverwaltung von saslauthd und die Abhängigkeit von einer synchronen Systemzeit zwischen UCS DC Slave/Backup und UCS DC Master für ein simpleBind (für die Benutzer, bei denen {SASL} als userPassword Mechanismus verwendet wird).
Weitere Hinweise: http://www.openldap.org/doc/admin24/security.html 14.4. Password Storage Ich denke wir müssen für UCS 3.0 und Samba 4 eine Lösung finden, da dort keine LM-Hashes mehr gespeichert werden.
Um das {SASL} Schema für userPassword nutzen zu können, musste ich in etwa folgendes tun: cat << %EOF > /usr/lib/sasl2/slapd.conf log_level: 7 pwcheck_method: saslauthd saslauthd_path: /var/run/saslauthd/mux %EOF /etc/init.d/slapd restart Schöner wäre natürlich, wenn man ohne saslauthd auskäme.
Wenn man für das userPassword das "{SASL}user@REALM" Schema verwenden will, dann kommt man aktuell wohl nicht um die Verwendung von pam_krb5 herum, um die Authentifizierung per PLAIN Password gegen einen Kerberos-Server vornehmen zu lassen (quasi kinit). An saslauthd scheint dabei dann ebenfalls kein Weg vorbeizuführen. da "pwcheck_method: pam" nicht funktioniert. In der UCS-Sandardkonfiguration verwendet saslauthd schon den Mechanismus "pam" und man müsste daher zusätzlich zur /usr/lib/sasl2/slapd.conf (oder /etc/ldap/sasl2/slapd.conf, siehe Bug 20051) dann eine /etc/pam.d/ldap installieren. Minimal hat das mit folgenden zwei Zeilen funktioniert: auth [success=done new_authtok_reqd=ok user_unknown=ignore service_err=die authinfo_unavail=die default=ignore] pam_krb5.so account sufficient pam_krb5.so
Created attachment 3439 [details] Es gibt doch eine Alternative zu "{SASL}" und saslauthd: Das Overlay-Modul smbkrb5 führt unter anderem ein neues userPassword-Schema "{K5KEY}" ein. Ursprünglicher Zweck des Moduls ist es, die "PasswordModify Extended Operation" des LDAP-Servers so zu erweitern, dass bei Passwortänderungen per ldappasswd und pam_ldap nebenbei auch die krb5Key und Samba-Passworthashes per OpenLDAP direkt mit aktualisert werden. Das ist für unsere Zwecke vermutlich im Moment nicht besonders sinnvoll, da es potentiell die Komplexität in UCS erhöht und gegenüber der UCS-Variante von pam_krb5 keinen Vorteil bietet (u.a. wird krb5PasswordEnd nicht per default mit aktualisiert). Schön wäre es daher, wenn man die "{K5KEY}" Erweiterung ohne die Funktionalität der Passwortänderungen nutzen könnte. Das Overlay-Modul wird aus dem Quellpaket openldap mit gebaut und lässt sich einfach als Debianpaket slapd-smbk5pwd installieren. Doku dazu ist im openldap Quellpaket. Der angehängte Patch reduziert die Funktionalität des Overlay-Moduls auf die Auswertung des userPassword-Schemas "{K5KEY}". Wenn man diesen String als userPassword verwendet, dann wird bei einem simpleBind das Passwort direkt durch das Overlay-Modul gegen Kerberos geprüft. Ggf. kann man den Patch in etwas verbesserter Form upstream schicken, weil er den Einsatzbereich erweitert.
Es wurde jetzt OpenLDAP so erweitert, dass ein zusätzliches Overlay Modul k5pwd gebaut wird. In univention-ldap wird das Modul per Default geladen, s4-connector und ad-connector wurden entsprechend erweitert.
Das Overlay Modul wurde hinzugefügt und aktiviert: root@master51:~# samba-tool user add stefan1 univention User 'stefan1' created successfully root@master51:~# ldapsearch -x -D uid=stefan1,cn=users,$ldap_base -w univention uid=stefan -LLL dn dn: uid=stefan,cn=users,dc=deadlock5,dc=local root@master51:~# univention-ldapsearch uid=stefan1 -LLL userPassword dn: uid=stefan1,cn=users,dc=deadlock5,dc=local userPassword:: e0s1S0VZfQ== root@master51:~# python2.6 Python 2.6.6 (r266:84292, May 24 2011, 07:42:34) [GCC 4.4.5] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import base64 >>> base64.decodestring('e0s1S0VZfQ==') '{K5KEY}'
OK, funktioniert * ohne samba4/ad-connector, am Benutzerobjekt händisch das userPassword auf "{K5KEY}" geändert, simple ldap bind (ldapsearch -x -D ... -W ) funktioniert * mit samba4/s4-connector -> samba-tool user setpassword felix --newpassword='univention123!"§' -> univention-ldapsearch -LLLL uid=felix userpassword \ | ldapsearch-decode64 dn: uid=felix,cn=users2,dc=iii,dc=zzz userPassword: {K5KEY} -> ldapsearch -H ldap://10.200.7.144:7389 -b dc=iii,dc=zzz \ -x -D uid=felix,cn=users2,dc=iii,dc=zzz -W uid=felix dn: uid=felix,cn=users2,dc=iii,dc=zzz krb5PrincipalName: felix@III.ZZZ ... * AD Connector Nach der Passwort-Änderung eines Account steht im UCS LDAP "userPassword: {K5KEY}" am Objekt. LDAP Simple bind mit diesem Benutzer am UCS LDAP ok. Changelog Eintrag vorhanden
UCS 3.0-0 wurde veröffentlicht. Sollte der hier beschriebene Bug mit einer neueren Version von UCS erneut auftreten, so sollte dieser Bug dupliziert werden: "Clone This Bug"
*** Bug 21244 has been marked as a duplicate of this bug. ***