If Samba joins a native-mode DC, all transitive trusts work correctly. If Samba joins a mixed-mode DC, wbinfo --sequence and wbinfo -m work correctly, but authentication (wbinfo -a) fails for all domains that are not directly connected to the DC, i.e., transitive trusts don't work for authentication.
Interesting to note that if you join an NT4 box to a mixed mode AD domain, you don't get all of the domains that could be reached by transitive trusts listed in the CTRL+ALT+DEL logon window. Only those of immediate trusts. If you join a 2k box to the same domain, you get all of the trusted domains listed in the logon window. The failure that is causing users from a transitive trusted domain not to be able to logon is that the net_sam_logon is failing which appears consistent with the NT4 behavior. Will have to work on it some more but I'm guessing this is coming down to a kerberos issue. So 'wbinfo -a' will fail be definition in this case but win2k clients accessing the Samba box as a user from a transitive trust domain should work. Since they don't, this is a confirmed legitimate bug.
I did look at a trace and the win2k is only send the NTLMSSP OID in the SMBsesssetup request.
Andrew B. has a fix for the problem where we were getting downgraded to NT4 in AD (operatingSystem and operatingSystemVersion attributes). That should fix this as well since the 2k clients will now use krb5 logons. I'll wait to test his patch (in the next day or so) but I'm pretty sure it will solve this bug as well.
I still plan to do more testing, but looks very good so far. Brilliant work, guys!
This is fixed with Andrew B's latest checkin. See the comments about the extra bits needed in the sec_channel negotiate flags. Please run as many tests as possible to make sure we have broken winbindd in some other way.
Something still ain't right. With this configuration: SUPTRA (mixed-mode) +-- CAMPBELLS (mixed-mode) +-- KAMA (mixed-mode) +-- TANTRA (native-mode) If I join SUPTRA, "wbinfo -a" works for TANTRA, but it cannot authenticate user connections to TANTRA (DC name is "JAYA"). Level 10 logs: [2003/08/20 22:52:01, 10] nsswitch/winbindd_util.c:add_trusted_domains(187) Found domain TANTRA [2003/08/20 22:52:01, 3] nsswitch/winbindd_cm.c:cm_get_ipc_userpass(106) IPC$ connections done anonymously [2003/08/20 22:52:01, 5] nsswitch/winbindd_cm.c:cm_open_connection(177) connecting to JAYA from SA1501 with kerberos principal [SA1501 $@SUPTRA.NSSOLUTIONS.COM] [2003/08/20 22:52:01, 2] libsmb/cliconnect.c:cli_session_setup_spnego(646) Doing spnego session setup (blob length=128) [2003/08/20 22:52:01, 2] libsmb/cliconnect.c:cli_session_setup_kerberos(496) Doing kerberos session setup [2003/08/20 22:52:01, 3] nsswitch/winbindd_util.c:add_trusted_domain(135) add_trusted_domain: tantra.kama.suptra.nssolutions.com is a native mode domain [2003/08/20 22:52:01, 1] nsswitch/winbindd_util.c:add_trusted_domain(142) Added domain TANTRA tantra.kama.suptra.nssolutions.com S-0-0 [2003/08/20 22:52:01, 10] nsswitch/winbindd_cache.c:domain_sid(1293) domain_sid: [Cached] - doing backend query for info for domain TANTRA [2003/08/20 22:52:01, 3] nsswitch/winbindd_ads.c:domain_sid(953) ads: domain_sid [2003/08/20 22:52:01, 1] libsmb/clikrb5.c:ads_krb5_mk_req(269) krb5_cc_get_principal failed (No credentials cache found) [2003/08/20 22:52:01, 0] libads/kerberos.c:ads_kinit_password(133) kerberos_kinit_password HOST/sa1501@TANTRA.KAMA.SUPTRA.NSSOLUTIONS.COM failed: Client not found in Kerberos database [2003/08/20 22:52:01, 1] nsswitch/winbindd_ads.c:ads_cached_connection(70) ads_connect for domain TANTRA failed: Operations error wbinfo --sequence shows TANTRA DISCONNECTED, but wbinfo -a to TANTRA works OK. Sorry...
This line in the log file bothers me. I'm pretty sure this is due to Andrew's changes, so i think he'll have to respond kerberos_kinit_password HOST/sa1501@TANTRA.KAMA.SUPTRA.NSSOLUTIONS.COM failed: Client not found in Kerberos database I see the servicePrincopalName attribute for a Samba 3.0 box joined to an AD domain is in the form HOST/SHAGGY HOST/shaggy.ad.plainjoe.org CIFS/SHAGGY CIFS/shaggy.ad.plainjoe.org Since these are just DirectoryStrings, i can't imagine that they would be case sensitive. Could you check the attribute value on your DC using ADSIedit?
RC2 will ship with this issue unresolved. We'll put it on the plate for RC3 and hope to resolve it by then.
The bug here is that we have code making assumptions about the remote server's realm. We should (as per the agreement after CIFS2003) always honer lp_realm(), not the remote server's realm for the kerberos ticket. I was writing up code to make this always consistant - brining that back to life should solve this bug. Andrew Bartlett
Created attachment 114 [details] Always use lp_realm() for our realm. In the meantime, this compleatly untested patch should solve it.
Andrew's patch does indeed seem to fix the problem. Well done! Here's a level 10 log comparable to my earlier one: [2003/08/30 09:03:35, 10] nsswitch/winbindd_util.c:add_trusted_domains(220) Found domain TANTRA [2003/08/30 09:03:35, 3] nsswitch/winbindd_cm.c:cm_get_ipc_userpass(106) IPC$ connections done anonymously [2003/08/30 09:03:35, 5] nsswitch/winbindd_cm.c:cm_open_connection(177) connecting to JAYA from SA1501 with kerberos principal [SA1501 $@SUPTRA.NSSOLUTIONS.COM] [2003/08/30 09:03:35, 2] libsmb/cliconnect.c:cli_session_setup_spnego(646) Doing spnego session setup (blob length=128) [2003/08/30 09:03:35, 2] libsmb/cliconnect.c:cli_session_setup_kerberos(496) Doing kerberos session setup [2003/08/30 09:03:35, 3] nsswitch/winbindd_util.c:add_trusted_domain(135) add_trusted_domain: tantra.kama.suptra.nssolutions.com is a native mode domain [2003/08/30 09:03:35, 1] nsswitch/winbindd_util.c:add_trusted_domain(142) Added domain TANTRA tantra.kama.suptra.nssolutions.com S-0-0 [2003/08/30 09:03:35, 10] nsswitch/winbindd_cache.c:domain_sid(1293) domain_sid: [Cached] - doing backend query for info for domain TANTRA [2003/08/30 09:03:35, 3] nsswitch/winbindd_ads.c:domain_sid(971) ads: domain_sid [2003/08/30 09:03:35, 1] nsswitch/winbindd_util.c:add_trusted_domains(201) scanning trusted domain list
I'm checking this fix in. Will need lots of testing in all cases for trust relationships. Thanks andrew.
originally reported against one of the 3.0.0rc[1-4] releases. Cleaning up non-production versions.
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.
database cleanup