Description Stefan Gohmann 2012-09-07 18:05:12 CEST

Wir sollten in der Doku darauf hinweisen, dass für diese Art der Vertraunesstellung ein Memberserver nicht reicht, sondern ein DC Slave verwendet werden soll.

+++ This bug was initially created as a clone of Bug #25244 +++

Auf UCS 3.0 Memberservern können Benutzer einer Windows-Domäne, mit der eine
Vertrauensstellung eingerichtet ist, nicht korrekt authentisert werden. Auf
Master, Backup und Slave geht das hingegen. Das Fehlerbild:


root@member123:~# wbinfo -a ARDOM2+winuser1%Univention123
plaintext password authentication failed
Could not authenticate user ARDOM2+winuser1%Univention123 with plaintext
password
challenge/response password authentication failed
error code was NT_STATUS_NO_SUCH_USER (0xc0000064)
error messsage was: No such user
Could not authenticate user ARDOM2+winuser1 with challenge/response


Jetzt wird's bizarr: Wenn man unter UCS einen gleichnamigen Benutzer (mit
anderem Passwort) anlegt, dann geht es:

root@member123:~# wbinfo -a ARDOM2+user5%Univention123
plaintext password authentication succeeded
challenge/response password authentication succeeded
## Der UCS-Benutzer hatte wirklich ein anderes Passwort:
root@member123:~# wbinfo -a user5%univention
plaintext password authentication failed
Could not authenticate user user5%univention with plaintext password
challenge/response password authentication succeeded

Wenn man das Konto des gleichnamigen UCS-Benutzers per UDM deaktivert, schlägt
das auf den ARDOM2+user5 aus der Vertrauten Windows-Domäne durch:

root@member123:~# wbinfo -a ARDOM2+user5%Univention123
plaintext password authentication failed
Could not authenticate user ARDOM2+user5%Univention123 with plaintext password
challenge/response password authentication failed
error code was NT_STATUS_ACCOUNT_EXPIRED (0xc0000193)
error messsage was: Account expired
Could not authenticate user ARDOM2+user5 with challenge/response