Hallo,
ich logge mich mit einem Domain User in das UDM ein, bei welchem die Option “pwdChangeNextLogin” aktiviert ist.
Es wird auch nach dem neuen Passwort gefragt, beim Speichern erscheint folgender Fehler:
Für den normalen User muß man über ucr eine LDAP-ACl aktivieren.
root@ucsmaster:~# ucr set ldap/acl/user/password/change=yes
Setting ldap/acl/user/password/change
Module: zarafa-cfg
Multifile: /etc/ldap/slapd.conf
root@ucsmaster:~# /etc/init.d/slapd restart
Immer noch gleicher Fehler…
Und heute folgendes Problem:
Login mit Benutzer “test” funktioniert, nur dann läd er ewig, und schreibt im Hintergrund “er muss das Passwort ändern”…
Browser: Firefox 21
Mit Internet Explorer funktioniert es bis zum Passwort ändern, aber da erhalte ich wieder Authenfication failed :(!!
Für mich ist das zunächst nicht reproduzierbar.
- Sind alle Benutzer betroffen oder nur bestimmte?
- Funktioniert die Passwortänderung im UDM wenn das Passwort nicht abgelaufen ist?
- Funktioniert die Passwortänderung über Windows und kinit?
- Funktioniert ein LDAP-Bind mit dem Benutzer (verschlüsselt) gegen den DC-Master?
- Welche Kontooptionen sind für den/die betroffenen Benutzer aktiv)?
Habe es mit Administrator & test probiert, bei beiden kommt beim Passwort ändern und nach der Eingabe “Authentifcation failed” (siehe oben).
Ja, dann funktioniert sie.
Auch über kinit erhalte ich den Fehler "Authentification failed.
samba4.log:
[2013/07/03 16:19:48, 3] ../lib/ldb-samba/ldb_wrap.c:318(ldb_wrap_connect)
ldb_wrap open of secrets.ldb
[2013/07/03 16:19:49, 3] ../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
Kerberos: AS-REQ Administrator@TOM.LOCAL from ipv4:192.168.0.3:41214 for krbtgt/TOM.LOCAL@TOM.LOCAL
[2013/07/03 16:19:49, 3] ../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
Kerberos: No preauth found, returning PREAUTH-REQUIRED -- Administrator@TOM.LOCAL
[2013/07/03 16:19:49, 3] ../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
Kerberos: AS-REQ Administrator@TOM.LOCAL from ipv4:192.168.0.3:43170 for krbtgt/TOM.LOCAL@TOM.LOCAL
[2013/07/03 16:19:49, 3] ../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
Kerberos: Client sent patypes: encrypted-timestamp
[2013/07/03 16:19:49, 3] ../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
Kerberos: Looking for PKINIT pa-data -- Administrator@TOM.LOCAL
[2013/07/03 16:19:49, 3] ../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
Kerberos: Looking for ENC-TS pa-data -- Administrator@TOM.LOCAL
[2013/07/03 16:19:49, 3] ../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
Kerberos: ENC-TS Pre-authentication succeeded -- Administrator@TOM.LOCAL using aes256-cts-hmac-sha1-96
[2013/07/03 16:19:49, 2] ../source4/auth/sam.c:207(authsam_account_ok)
sam_account_ok: Account for user 'Administrator@TOM.LOCAL' password must change!.
[2013/07/03 16:19:49, 3] ../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
Kerberos: AS-REQ Administrator@TOM.LOCAL from ipv4:192.168.0.3:60053 for kadmin/changepw@TOM.LOCAL
[2013/07/03 16:19:49, 3] ../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
Kerberos: No preauth found, returning PREAUTH-REQUIRED -- Administrator@TOM.LOCAL
[2013/07/03 16:19:49, 3] ../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
Kerberos: AS-REQ Administrator@TOM.LOCAL from ipv4:192.168.0.3:51646 for kadmin/changepw@TOM.LOCAL
[2013/07/03 16:19:49, 3] ../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
Kerberos: Client sent patypes: encrypted-timestamp
[2013/07/03 16:19:49, 3] ../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
Kerberos: Looking for PKINIT pa-data -- Administrator@TOM.LOCAL
[2013/07/03 16:19:49, 3] ../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
Kerberos: Looking for ENC-TS pa-data -- Administrator@TOM.LOCAL
[2013/07/03 16:19:49, 3] ../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
Kerberos: ENC-TS Pre-authentication succeeded -- Administrator@TOM.LOCAL using aes256-cts-hmac-sha1-96
[2013/07/03 16:19:49, 3] ../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
Kerberos: AS-REQ authtime: 2013-07-03T16:19:49 starttime: unset endtime: 2013-07-03T16:20:49 renew till: unset
[2013/07/03 16:19:49, 3] ../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
Kerberos: Client supported enctypes: aes256-cts-hmac-sha1-96, aes128-cts-hmac-sha1-96, des3-cbc-sha1, des3-cbc-md5, arcfour-hmac-md5, des-cbc-md5, des-cbc-md4, des-cbc-crc, using aes256-cts-hmac-sha1-96/arcfour-hmac-md5
[code]Administrator@TOM.LOCAL’s Password:
Your password will expire at Thu Jan 1 01:00:00 1970
Changing password
New password:
Repeat new password:
Error: Authentication failed[/code]
Auf einem Windows 8 Client funktioniert das ändern des Passwortes aber Problemlos!
Standard- Administratorkonto & Benutzer mit Standardeinstellungen
Was mir noch aufgefallen ist, wenn der Screen beim vor dem Passwort ändern ewig läd, meldet der Browser “Unsupported Media Type”:
Was ich getan habe:
Ich habe beim Admin & test Benutzer PW ändern gesetzt, dann einmal mit test eingeloggt, und dann mit Admin. Beim Admin hat er dann ewig geladen…
Ich habe das Browser-Verhalten unter 64Bit Windows 7 reproduzieren können. [bug]31898[/bug].
Das Verhalten bzgl. kinit wird bereits in einem anderen Thread diskutiert.
Wir haben das Problem ebenfalls beobachten können. Das Problem tritt wohl auf, wenn login.html (technisch ein IFrame) im Hintergrund geladen wird und “zur falschen Zeit” fertig ist. Das Problem tritt tatsächlich vermehrt im Internet Explorer auf, dürfte aber eigentlich nicht auf ihn beschränkt sein.
Im Prinzip sind es zwei unterschiedliche Fehler: Die Ladeanimation hört nicht auf und der Login schlägt fehl. Beide haben mit besagtem falschen Zeitpunkt zu tun, wobei der zweite Fehler gravierender ist.
Beim Setzen eines neuen Passworts wird der Benutzername und das (abgelaufene) Passwort noch einmal mitgesendet. Wir konnten beobachten, dass hin und wieder der falsche Benutzername gesendet wird. Das lag daran, dass noch ein alter Name gespeichert war und dieser in das Formular übertragen wird.
D.h.:
[ul]
[li]Anmelden z.B. als Administrator, arbeiten, abmelden[/li]
[li]Versuch der Anmeldung als Testnutzer mit abgelaufenem Passwort, Aufforderung zur Änderung geschickt bekommen[/li]
[li]Neues Passwort eingeben[/li][/ul]
Im dritten Schritt kann es passieren, dass das System nun versucht, den Administrator (und nicht den Testnutzer) mit dem Passwort des Testnutzers zu authentifizieren. Das scheitert und das neue Passwort wird nicht übernommen.
Noch ein Satz zum “Unsupported Media Type”. Ja, das wirkt merkwürdig und falsch. Wir brauchten einen speziellen HTTP-Status für den Fall, dass das Passwort abgelaufen ist. Es gibt aber keinen “eingebauten” Status für so etwas, also mussten wir einfach irgend einen nehmen. Das machen wir bei einigen Fällen so, und deshalb war der nächst freie eben die “415 Unsupported Media Type”. Es war in diesem Fall also alles richtig, das hat auch UMC erkannt (und schreibt deshalb “The password has expired and must be changed”). Eigentlich ist alles richtig, nur wurde die Ladeanimation nicht beendet, obwohl das hätte passieren sollen.
Ein Bugfix für beide Probleme liegt vor. Er wird demnächst veröffentlicht werden. Vielen Dank für das Auffinden!