[PATCH] spnego SPN fix when contacting trusted domains

[Steven Danneman-3]

Doing some testing with W2K8 I found there's still a few more bugs using
proper Kerberos credentials when we're joined to a W2K3 domain, but
attempting to connect to a W2K8 domain which has a forest transitive
trust with our domain.

 

There are two patches against v3-0-test attached.  The first one is a
quick and dirty hack to get 3.0 head behaving like our in-house modified
3.0.24 which I originally wrote the second patch again.

 

0001:

 

Changes were made in winbindd_cm.c:cm_prepare_connection() to use
get_trust_creds() to fill in machine_krb5_principal and
machine_password.  Unfortunately, they're filled in incorrectly in the
case where we're trying to connect to a trusted domain.

 

Say our machine is called MACHINE, we're joined to a domain
W2K3.DOMAIN.COM, which has a transitive trust to W2K8.DOMAIN.COM.  The
first time we try to connect to W2K8, get_trust_creds() incorrectly
tells us to use the machine_password from W2K8, and a
machine_krb5_principal of MACHINE$@....  These should be the
machine_password from W2K3 and MACHINE$@....

 

So the first patch is a quick hack to fill in those values like they
were in 3.0.24.   These changes probably need to be put somewhere else,
and I haven't audited any other callers of the functions in that patch
to make sure they still work.

 

0002:

 

This is what I was trying to submit initially, and the patch explains
the changes and why they're necessary.  There are many ways to implement
this fix, I chose to change the function signature, and pass in a real
REALM so we could eventually stop relying on the negHint in
NegTokenInit2 all together.

 

Steven Danneman | Software Development Engineer

Isilon Systems    P [phone]    F  [phone]

www.isilon.com    

[Jeremy Allison]

On Thu, May 08, 2008 at 02:12:49PM -0700, Steven Danneman wrote:

> Doing some testing with W2K8 I found there's still a few more bugs using
> proper Kerberos credentials when we're joined to a W2K3 domain, but
> attempting to connect to a W2K8 domain which has a forest transitive
> trust with our domain.
>
>  
>
> There are two patches against v3-0-test attached.  The first one is a
> quick and dirty hack to get 3.0 head behaving like our in-house modified
> 3.0.24 which I originally wrote the second patch again.

Just for clarification, 002 is the one you really want us to
review/integrate - yes ? 001 is a demonstration of a hack fix
for the problem ?

Jeremy.

[Jeremy Allison]

On Thu, May 08, 2008 at 06:20:47PM -0700, Steven Danneman wrote:

>
> Sorry, my message was a bit confusing.
>
> 0002 is the patch I want you to review/integrate.  In applying it from
> my 3.0.24 codebase to 3.0.28a, I found another blocking bug that exists
> in 3.0.28a.
>
> I didn't have time to also thoroughly fix it, so 0001 is a quick hack
> fix for this blocking bug, that should be applied before 0002 so you can
> see that 0002 works.  However, the bug fixed by 0001 needs to be
> addressed first.
>
> I can file a more specific bug report on the issue fixed by 0001.
>
> Bah, this is confusing.  I'm on IRC for the next 40 minutes if you want
> to hash it out.

Sorry, I'm at home and won't be back on IRC until tomorrow morning.

I'll review/add 0002, and discuss 0001 with Jerry tomorrow. Do
both these issues appear in 3.2 ? (I imagine so). Logging bugs
for both of them (as they appear to be 3.2 showstoppers) would
also help, as we'll need that to get them into 3.2-stable for
release.

Thanks,

        Jeremy.

[Steven Danneman-3]

> Just for clarification, 002 is the one you really want us to
> review/integrate - yes ? 001 is a demonstration of a hack fix
> for the problem ?
>

Sorry, my message was a bit confusing.

0002 is the patch I want you to review/integrate.  In applying it from
my 3.0.24 codebase to 3.0.28a, I found another blocking bug that exists
in 3.0.28a.

I didn't have time to also thoroughly fix it, so 0001 is a quick hack
fix for this blocking bug, that should be applied before 0002 so you can
see that 0002 works.  However, the bug fixed by 0001 needs to be
addressed first.

I can file a more specific bug report on the issue fixed by 0001.

Bah, this is confusing.  I'm on IRC for the next 40 minutes if you want
to hash it out.

-Steven

[Steven Danneman-3]

 
> I'll review/add 0002, and discuss 0001 with Jerry tomorrow. Do
> both these issues appear in 3.2 ? (I imagine so). Logging bugs
> for both of them (as they appear to be 3.2 showstoppers) would
> also help, as we'll need that to get them into 3.2-stable for
> release.
>

I've submitted two bugs matching the patches:

https://bugzilla.samba.org/show_bug.cgi?id=5451
https://bugzilla.samba.org/show_bug.cgi?id=5454

Both are against 3.0.28a, as that's the environment I've used to find
and test these.  Looking at the code, they probably both also exist in
3.2.

-Steven

[Gerald (Jerry) Carter]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Steven,


0001-Use-machine....
  I think the change to secrets.c may break winbindd running
  on a PDC.  The change to winbindd_cm.c is ok since we only
  do krb5 logins on a domain member server anyways.

0002-spnego-SPN-fix.....
  I'd agree with the logic here after a quick review.  No testing.
  If no one has a Windows 2008 forest (other than Steven), I'll
  add some trusts to mine and finish up testing on Monday.




cheers, jerry

Steven Danneman wrote:

> Doing some testing with W2K8 I found there's still a few more bugs using
> proper Kerberos credentials when we're joined to a W2K3 domain, but
> attempting to connect to a W2K8 domain which has a forest transitive
> trust with our domain.
>
>  
>
> There are two patches against v3-0-test attached.  The first one is a
> quick and dirty hack to get 3.0 head behaving like our in-house modified
> 3.0.24 which I originally wrote the second patch again.
>
>  
>
> 0001:
>
>  
>
> Changes were made in winbindd_cm.c:cm_prepare_connection() to use
> get_trust_creds() to fill in machine_krb5_principal and
> machine_password.  Unfortunately, they're filled in incorrectly in the
> case where we're trying to connect to a trusted domain.
>
>  
>
> Say our machine is called MACHINE, we're joined to a domain
> W2K3.DOMAIN.COM, which has a transitive trust to W2K8.DOMAIN.COM.  The
> first time we try to connect to W2K8, get_trust_creds() incorrectly
> tells us to use the machine_password from W2K8, and a
> machine_krb5_principal of MACHINE$@....  These should be the
> machine_password from W2K3 and MACHINE$@....
>
>  
>
> So the first patch is a quick hack to fill in those values like they
> were in 3.0.24.   These changes probably need to be put somewhere else,
> and I haven't audited any other callers of the functions in that patch
> to make sure they still work.
>
>  
>
> 0002:
>
>  
>
> This is what I was trying to submit initially, and the patch explains
> the changes and why they're necessary.  There are many ways to implement
> this fix, I chose to change the function signature, and pass in a real
> REALM so we could eventually stop relying on the negHint in
> NegTokenInit2 all together.
>
>  
>
> Steven Danneman | Software Development Engineer
>
> Isilon Systems    P [phone]    F  [phone]
>
> www.isilon.com    
>

- --
=====================================================================
Samba                                    ------- http://www.samba.org
Likewise Software          ---------  http://www.likewisesoftware.com
"What man is a man who does not make the world better?"      --Balian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIJLVQIR7qMdg1EfYRAlaDAKCjNwXDjmAiyfw0klywqc/2CAahnACfTNwz
SXqP09jc3EVKll8KiKHvyjA=
=nBVF
-----END PGP SIGNATURE-----

[Steven Danneman-3]

>
> 0001-Use-machine....
>   I think the change to secrets.c may break winbindd running
>   on a PDC.  The change to winbindd_cm.c is ok since we only
>   do krb5 logins on a domain member server anyways.

Jerry,

I've looked into this a little more today.  My initial impression is
that there are two situations where we need to acquire credentials to
access a trusted domain:

1) Samba is a PDC, and is using the trust account and password
established when the trust relationship was created.

2) Samba is a member server and is using its machine account and machine
password, first to kinit to its PDC, then to connect directly to the
trusted PDC.

I believe both of these cases are covered by patch 0001.  Is there
another scenario that I'm missing?

-Steven

[Gerald (Jerry) Carter]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Steven,

I've checked bother patches into the v3-0-test tree and will
forward port them to 3-2 and 3-3.  After reviewing the current
code more, my concerns about the first patch breaking a
Samba PDC with domain trusts was unfounded.





cheers, jerry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFINwrlIR7qMdg1EfYRAigZAJ4jZHekzqZ+ct7C5oGPkC7N+javHgCfd0WZ
YpyLVeaP4temGbLLDdyqTVo=
=u3FH
-----END PGP SIGNATURE-----