Univention Bugzilla – Bug 49394
UCS as Member in AD does not Authenticate on Proper Server with UCS 4.4 in Trust
Last modified: 2019-04-30 19:42:58 CEST
An AD domain exists (Level 2008R2). A UCS Master 4.4 (freshly installed) is added there as "Trust" to this AD Domain. In the AD domain there is a UCS member server joined which hosts fileshares. Expected behaviour: Trying to access the fileshare from a Windows client in the UCS domain should offer the share without the need of further authentication. Seen behaviour: An authentication window pops up and requests credentials when trying to access the share. Currently unsure if the request is successful when entering credentials. Additional information: On the member sever getent passwd and getent groups works fine and shows the UCS users when requested. kinit works fine, too and klist shows the granted ticket afterwards. We see in Samba log on the member server: authenticated session setup to master_ucsmaster.domain.de using REALM\filesrv$ status: NT_LOGON FAILURE
Thinking loud: In this case the Samba member/fileserver will try to authenticate the "UCSDOM\ucsuser" against some DC. I assume it will ask windbind to make the LSA RPC connection and that may "somehow" try to connect to the UCSDOM\ucsmaster (netbios? DNS?). Some network trace could be interesting, and for that we may need a test setup to extract kerberos keys. OTOH Stefan also suggested that it could basically be a similar thing as Bug 47314, where the Samba member server receives a logon request from "OTHERDOM\user" and winbind directs that logon request to the UCS master, which doesn't recognize the user. Brilliant idea, but that should work in this case, where AD trusts UCS and the AD DC should be able to redirect the authentication to the UCS DC. Also it doesn't explain why the Samba member/fileserver directly tries to contact the UCS DC (instead of the AD DC).