Example Domain Topology: Computer named MACHINE joined to W2K3.DOMAIN.COM, which has a transitive forest trust with W2K8.DOMAIN.COM. Repro: 1) Start winbindd with debug level 10 2) Run a command that will connect to W2K8 # wbinfo -g --domain=w2k8 Expect: Kerberos authentication will occur with w2k8. Actual: Check the logs and you'll see: [2008/05/08 19:03:29, 5] nsswitch/winbindd_cm.c:cm_prepare_connection(733) connecting to w2k8-dc1.w2k8.domain.com from MACHINE with kerberos principal [MACHINE$@W2K8.DOMAIN.COM] [2008/05/08 19:03:29, 3] libsmb/cliconnect.c:cli_session_setup_spnego(801) Doing spnego session setup (blob length=124) [2008/05/08 19:03:29, 3] libsmb/cliconnect.c:cli_session_setup_spnego(826) got OID=1 2 840 48018 1 2 2 [2008/05/08 19:03:29, 3] libsmb/cliconnect.c:cli_session_setup_spnego(826) got OID=1 2 840 113554 1 2 2 [2008/05/08 19:03:29, 3] libsmb/cliconnect.c:cli_session_setup_spnego(826) got OID=1 2 840 113554 1 2 2 3 [2008/05/08 19:03:29, 3] libsmb/cliconnect.c:cli_session_setup_spnego(826) got OID=1 3 6 1 4 1 311 2 2 10 [2008/05/08 19:03:29, 3] libsmb/cliconnect.c:cli_session_setup_spnego(834) got principal=not_defined_in_RFC4178@please_ignore [2008/05/08 19:03:29, 10] libads/kerberos.c:kerberos_kinit_password_ext(91) kerberos_kinit_password: using [MEMORY:cliconnect] as ccache and config [(null)] [2008/05/08 19:03:29, 0] libsmb/cliconnect.c:cli_session_setup_spnego(865) Kinit failed: Client not found in Kerberos database [2008/05/08 19:03:29, 4] nsswitch/winbindd_cm.c:cm_prepare_connection(742) failed kerberos session setup with Client not found in Kerberos database Problem: In cm_prepare_connection() get_trust_creds() incorrectly tells us to use the machine_password from W2K8, and a machine_krb5_principal of MACHINE$@W2K8.DOMAIN.COM. These should be the machine_password from W2K3 and MACHINE$@W2K3.DOMAIN.COM
Created attachment 3281 [details] Temp patch This is a quick and dirty patch to cause get_trust_creds() to return the proper values in this situation. This test shouldn't be applied, because I haven't done any regression testing of the other callers.
Steven, thanks for reporting! This is almost the same as bug #5425. But the kreberos bit is extra. The kerberos part of the patch is ok in any case. It re-installs the original behaviour of before my modification. I think that the get_trust_pw_clear() part of the patch is not correct in all situations. But of course it will fix this one. I just noted that jerry has applied your patch to all branches. So it might need some other corrections, but this bug can be be closed, I guess?
(In reply to comment #2) > I think that the get_trust_pw_clear() part of the patch is not > correct in all situations. But of course it will fix this one. I reviewed the code and tested on a domain member and PDC. What do you think it will break ?
Hi Jerry, the problem I am seeing may be academic or theoretical. It lies in the fact that is_trusted_domain_situation() checks for lp_allow_trusted_domains(). Thus, in get_trust_pw_clear(), when the first check fails, we fall into the branch for fetching the machine account password for our own domain, which might not fail (on a self joined dc). So instead of returning false, we would return invalid credentials in that case. This is There are some other uses of is_trusted_domain_situation(), that should actually not check lp_allow_trusted_domains(): one in get_trust_pw_has() and one in cm_prepare_connection(). In these cases, using the check without lp_allow_trusted_domains() prevents calls that will fail anyways. Well, code speaks. I have prepared corresponding modifications of v3-3-test in a series of atomic commits that I just checked in: 0a24c038b7bc6edef0021eb121a072cc7e8f9165 a5a51ca8e5971992d9b060d66201b808bd2b7a53 aa1b8287f44f47f23bd4158112d0a132df04426c 5f197c659e9c8a573ba5032c7f90c816df45770c 0b26bcd3becb869319bca48bbf244c18b6e8e3dd a284c8843528972904d142b573f1170a08c97751 For your convenience, I'll attach a combined diff next. What do you think - does this make sense? Is it a reasonable extension of Steven's patch? Michael
Created attachment 3313 [details] combined diff This is a comined diff of the commits mentioned in comment #4.
Michael, is this resolved actually ?
(In reply to comment #6) > Michael, is this resolved actually ? Yes, I think this is in fact long solved. Should be ok at least in 3.3 and newer. Gonna close this bug. Please reopen if problems persist.