Bug 5451 - get_trust_creds() returns incorrect credentials when connecting to a trusted domain
Summary: get_trust_creds() returns incorrect credentials when connecting to a trusted ...
Status: RESOLVED FIXED
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: winbind (show other bugs)
Version: 3.0.28a
Hardware: All All
: P3 major
Target Milestone: none
Assignee: Michael Adam
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks: 5454
  Show dependency treegraph
 
Reported: 2008-05-08 21:11 UTC by Steven Danneman
Modified: 2009-11-19 16:11 UTC (History)
3 users (show)

See Also:


Attachments
Temp patch (1.66 KB, text/x-patch)
2008-05-08 21:13 UTC, Steven Danneman
no flags Details
combined diff (3.62 KB, patch)
2008-05-26 15:29 UTC, Michael Adam
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Steven Danneman 2008-05-08 21:11:20 UTC
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
Comment 1 Steven Danneman 2008-05-08 21:13:44 UTC
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.
Comment 2 Michael Adam 2008-05-24 18:24:47 UTC
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?
Comment 3 Gerald (Jerry) Carter (dead mail address) 2008-05-26 09:39:44 UTC
(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 ?
Comment 4 Michael Adam 2008-05-26 15:27:19 UTC
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
Comment 5 Michael Adam 2008-05-26 15:29:59 UTC
Created attachment 3313 [details]
combined diff 

This is a comined diff of the commits mentioned in comment #4.
Comment 6 Guenther Deschner 2009-10-14 09:25:22 UTC
Michael, is this resolved actually ?
Comment 7 Michael Adam 2009-11-19 16:11:27 UTC
(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.