SPNEGO in Samba - Longhorn Server interop issues...

[Todd Stecher-4]

When Windows shipped, there were no other SPNEGO implementations to  
test against, and so Windows really didn't match SPNEGO RFC 2478  
100%.  Eventually, Larry, Paul "Mr. CIFS" Leach, & company at  
Microsoft made an effort to clean this mess up, and revisit the  
standard so that everyone could play well together.  The end result  
is RFC 4178, which supersedes 2478.

As such, in early versions of Windows SPNEGO, there were some "extra"  
fields added to the negTokenInit message which are being deprecated  
in Vista, Longhorn Server, and eventually service packs for older  
platforms.  The most significant of these fields is the principal  
name - there is really no place in either standard which allows the  
return of a principal in negTokenInit messages.  This is being  
corrected for in Vista and Longhorn server by continuing to add the  
field, but instead of a "real" principal, it now contains  
"not_defined_in_RFC4178 at please_ignore".

 From a security standpoint, allowing the server to specify its  
service principal is a "bad idea" - I'm OK with this change, but it  
means we'll need to fix up some Samba code, and we'll need to start  
using / generating real service principal names in order to get  
Kerberos authentication.  Currently, we try to get a service ticket  
to the @please_ignore realm!!!

Volker made a fix in cliconnect.c (http://lists.samba.org/archive/ 
samba-cvs/2006-October/071344.html) to partially address this.  
However, this does not address issues when operating against Longhorn  
Server (Windows 2008 server?).  I'm sorting through the issues, but  
the first error occurs when trying to join a Samba server to the  
domain - the code in ads_sasl_spnego_bind() uses this principal to  
attempt to get a Kerberos ticket to the ldap head.

I'm sure this is the first layer of the onion (there are encoding  
issues in the old Microsoft implementation as well), but there'll be  
more - before I get too deep, is this work already being done  
elsewhere???  If not, I should be able to get fairly solid Longhorn  
Server interop moving forward in the next week, and will submit a patch.


Thanks,
Todd




Todd Stecher | Windows Interop Dev
Isilon Systems    P [phone]     F  [phone]
www.isilon.com    D [phone]    M [phone]

[Jeremy Allison]

On Tue, Jul 03, 2007 at 04:10:30PM -0700, Todd Stecher wrote:
>
> I'm sure this is the first layer of the onion (there are encoding  
> issues in the old Microsoft implementation as well), but there'll be  
> more - before I get too deep, is this work already being done  
> elsewhere???  If not, I should be able to get fairly solid Longhorn  
> Server interop moving forward in the next week, and will submit a patch.

Not to my knowledge ("work already being done elsewhere"). I'd
appreciate a patch and I'll definately review it asap.

Thanks !

Jeremy.

[Love Hörnquist Åstrand]

4 jul 2007 kl. 01.10 skrev Todd Stecher:

> When Windows shipped, there were no other SPNEGO implementations to  
> test against, and so Windows really didn't match SPNEGO RFC 2478  
> 100%.  Eventually, Larry, Paul "Mr. CIFS" Leach, & company at  
> Microsoft made an effort to clean this mess up, and revisit the  
> standard so that everyone could play well together.  The end result  
> is RFC 4178, which supersedes 2478.
>
> As such, in early versions of Windows SPNEGO, there were some  
> "extra" fields added to the negTokenInit message which are being  
> deprecated in Vista, Longhorn Server, and eventually service packs  
> for older platforms.  The most significant of these fields is the  
> principal name - there is really no place in either standard which  
> allows the return of a principal in negTokenInit messages.  This is  
> being corrected for in Vista and Longhorn server by continuing to  
> add the field, but instead of a "real" principal, it now contains  
> "not_defined_in_RFC4178 at please_ignore".
>
> From a security standpoint, allowing the server to specify its  
> service principal is a "bad idea" - I'm OK with this change, but it  
> means we'll need to fix up some Samba code, and we'll need to start  
> using / generating real service principal names in order to get  
> Kerberos authentication.  Currently, we try to get a service ticket  
> to the @please_ignore realm!!!
>
> Volker made a fix in cliconnect.c (http://lists.samba.org/archive/ 
> samba-cvs/2006-October/071344.html) to partially address this.  
> However, this does not address issues when operating against  
> Longhorn Server (Windows 2008 server?).  I'm sorting through the  
> issues, but the first error occurs when trying to join a Samba  
> server to the domain - the code in ads_sasl_spnego_bind() uses this  
> principal to attempt to get a Kerberos ticket to the ldap head.
>
> I'm sure this is the first layer of the onion (there are encoding  
> issues in the old Microsoft implementation as well), but there'll  
> be more - before I get too deep, is this work already being done  
> elsewhere???  If not, I should be able to get fairly solid Longhorn  
> Server interop moving forward in the next week, and will submit a  
> patch.

We have an implementation RFC4178 in Heimdal, its farly easy to test  
it with LH with gssmaggot/gssmaster (or using heimdal's gssmask/
gssmaestro).

Love

[Todd Stecher-4]

Sorry this is taking so long - I'm multitasking.

I have this all working (against NT4, W2000, 2003, 2008), but our  
implementation has taken a dependency to start adding the default  
realm to krb5.conf when making outbound CIFS request from a Samba  
server (e.g. RPC).

This is because before these changes we used to rely on the principal  
returned in the spnego negtokeninit message (which had the form host/
machinename.domain.com@...).  However, now the principals  
we're passing into the kerberos libraries are of the form host/
machinename.domain.com (no info after the @ sign).  This means it has  
to fall back on the default realm value provided in krb5.conf for  
realm location.

Is it fairly normal for people to add in the default realm into  
krb5.conf when running in ADS mode?  Any suggestions on a "better"  
way to divine the service's realm, if its not available in the SPNEGO  
message?

Thanks,
Todd





On Jul 10, 2007, at 3:48 PM, Todd Stecher wrote:

> Wanon & Andrew pointed me at a fix for this - join is now working,  
> as is basic functionality.  Patch forthcoming...
>
>
> On Jul 10, 2007, at 2:48 PM, Todd Stecher wrote:
>
>> I'm guessing this is a description of the policy - problem is, its  
>> "disabled" in the UI:
>>
>>
>>
>> Domain member: Require strong (Windows 2000 or later) session key
>>
>> This security setting determines whether 128-bit key strength is  
>> required for encrypted secure channel data.
>>
>> When a computer joins a domain, a computer account is created.  
>> After that, when the system starts, it uses the computer account  
>> password to create a secure channel with a domain controller  
>> within the domain. This secure channel is used to perform  
>> operations such as NTLM passthrough authentication, LSA SID/name  
>> Lookup, and so on.
>>
>> Depending on what version of Windows is running on the domain  
>> controller that the domain member is communicating with and the  
>> settings of the parameters:
>>
>> Domain member: Digitally encrypt or sign secure channel data (always)
>> Domain member: Digitally encrypt secure channel data (when possible)
>> Some or all of the information that is transmitted over the secure  
>> channel will be encrypted. This policy setting determines whether  
>> or not 128-bit key strength is required for the secure channel  
>> information that is encrypted.
>>
>> If this setting is enabled, then the secure channel will not be  
>> established unless 128-bit encryption can be performed. If this  
>> setting is disabled, then the key strength is negotiated with the  
>> domain controller.
>>
>> Default: Disabled.
>>
>> Important
>>
>> In order to take advantage of this policy on member workstations  
>> and servers, all domain controllers that constitute the member's  
>> domain must be running Windows 2000 or later.
>> In order to take advantage of this policy on domain controllers,  
>> all domain controllers in the same domain as well as all trusted  
>> domains must run Windows 2000 or later.
>>
>>
>> I seem to recall one patch where 128 bit secure channel was  
>> supported...
>>
>>
>>
>> On Jul 10, 2007, at 2:39 PM, Todd Stecher wrote:
>>
>>> OK - I have the SPNEGO problems worked out, and join mostly  
>>> works, but it appears as if the secure channel we emit is  
>>> unacceptable to Longhorn server in its default state:
>>>
>>> From netlogon.log on the Longhorn DC:
>>>
>>>
>>> 07/10 14:01:39 [MAILSLOT] Ping response 'Sam Logon Response  
>>> Ex' (null) to \\W2009-1 Site: Default-First-Site-Name on UDP LDAP
>>> 07/10 14:01:39 [SESSION] NetrServerAuthenticate entered: W2009-1  
>>> on account W2009-1$ (Negot: 400701ff)
>>> 07/10 14:01:39 [SESSION] NetrServerAuthenticate3: the client  
>>> W2009-1$ is asking for NT4 crypto and this server disallows it.
>>> 07/10 14:01:39 [MISC] Eventlog: 5722 (1) "W2009-1" "W2009-1$"  
>>> 0xc0000388 d0706242 73ca0006 205b4f26 3a297e85   Bbp....s&O[ .~):
>>> 07/10 14:01:39 [MISC] Didn't log event since it was already logged.
>>>
>>>
>>> Err - are the details of Windows 2000+ secure channel support  
>>> emerged from your collective investigations?  I'm certain there's  
>>> a policy to change this restriction, but changing security  
>>> policies is not usually something domain admins want to do.    
>>> Who's our resident secure channel expert?
>>>
>>> (I'll do some independent investigation over coffee and  
>>> basketball w/ my favorite netlogon developer - but he may not be  
>>> super helpful given the proprietary nature of the protocol, as  
>>> well as the fact that its damn hard to figure out).
>>>
>>> Todd
>>>
>>>
>>>
>>> On Jul 3, 2007, at 4:16 PM, Jeremy Allison wrote:
>>>
>>>> On Tue, Jul 03, 2007 at 04:10:30PM -0700, Todd Stecher wrote:
>>>>>
>>>>> I'm sure this is the first layer of the onion (there are encoding
>>>>> issues in the old Microsoft implementation as well), but  
>>>>> there'll be
>>>>> more - before I get too deep, is this work already being done
>>>>> elsewhere???  If not, I should be able to get fairly solid  
>>>>> Longhorn
>>>>> Server interop moving forward in the next week, and will submit  
>>>>> a patch.
>>>>
>>>> Not to my knowledge ("work already being done elsewhere"). I'd
>>>> appreciate a patch and I'll definately review it asap.
>>>>
>>>> Thanks !
>>>>
>>>> Jeremy.
>>>
>>> Todd Stecher | Windows Interop Dev
>>> Isilon Systems    P [phone]     F  [phone]
>>> www.isilon.com    D [phone]    M [phone]
>>>
>>>
>>>
>>
>> Todd Stecher | Windows Interop Dev
>> Isilon Systems    P [phone]     F  [phone]
>> www.isilon.com    D [phone]    M [phone]
>>
>>
>>
>
> Todd Stecher | Windows Interop Dev
> Isilon Systems    P [phone]     F  [phone]
> www.isilon.com    D [phone]    M [phone]
>
>
>

Todd Stecher | Windows Interop Dev
Isilon Systems    P [phone]     F  [phone]
www.isilon.com    D [phone]    M [phone]

[eddietse]

How about use the the servicePricipalName attribute from Active Directory for the target HOST.

Todd Stecher-4 wrote:

Sorry this is taking so long - I'm multitasking.

I have this all working (against NT4, W2000, 2003, 2008), but our  
implementation has taken a dependency to start adding the default  
realm to krb5.conf when making outbound CIFS request from a Samba  
server (e.g. RPC).

This is because before these changes we used to rely on the principal  
returned in the spnego negtokeninit message (which had the form host/
[e-mail]).  However, now the principals  
we're passing into the kerberos libraries are of the form host/
machinename.domain.com (no info after the @ sign).  This means it has  
to fall back on the default realm value provided in krb5.conf for  
realm location.

Is it fairly normal for people to add in the default realm into  
krb5.conf when running in ADS mode?  Any suggestions on a "better"  
way to divine the service's realm, if its not available in the SPNEGO  
message?

Thanks,
Todd





On Jul 10, 2007, at 3:48 PM, Todd Stecher wrote:

> Wanon & Andrew pointed me at a fix for this - join is now working,  
> as is basic functionality.  Patch forthcoming...
>
>
> On Jul 10, 2007, at 2:48 PM, Todd Stecher wrote:
>
>> I'm guessing this is a description of the policy - problem is, its  
>> "disabled" in the UI:
>>
>>
>>
>> Domain member: Require strong (Windows 2000 or later) session key
>>
>> This security setting determines whether 128-bit key strength is  
>> required for encrypted secure channel data.
>>
>> When a computer joins a domain, a computer account is created.  
>> After that, when the system starts, it uses the computer account  
>> password to create a secure channel with a domain controller  
>> within the domain. This secure channel is used to perform  
>> operations such as NTLM passthrough authentication, LSA SID/name  
>> Lookup, and so on.
>>
>> Depending on what version of Windows is running on the domain  
>> controller that the domain member is communicating with and the  
>> settings of the parameters:
>>
>> Domain member: Digitally encrypt or sign secure channel data (always)
>> Domain member: Digitally encrypt secure channel data (when possible)
>> Some or all of the information that is transmitted over the secure  
>> channel will be encrypted. This policy setting determines whether  
>> or not 128-bit key strength is required for the secure channel  
>> information that is encrypted.
>>
>> If this setting is enabled, then the secure channel will not be  
>> established unless 128-bit encryption can be performed. If this  
>> setting is disabled, then the key strength is negotiated with the  
>> domain controller.
>>
>> Default: Disabled.
>>
>> Important
>>
>> In order to take advantage of this policy on member workstations  
>> and servers, all domain controllers that constitute the member's  
>> domain must be running Windows 2000 or later.
>> In order to take advantage of this policy on domain controllers,  
>> all domain controllers in the same domain as well as all trusted  
>> domains must run Windows 2000 or later.
>>
>>
>> I seem to recall one patch where 128 bit secure channel was  
>> supported...
>>
>>
>>
>> On Jul 10, 2007, at 2:39 PM, Todd Stecher wrote:
>>
>>> OK - I have the SPNEGO problems worked out, and join mostly  
>>> works, but it appears as if the secure channel we emit is  
>>> unacceptable to Longhorn server in its default state:
>>>
>>> From netlogon.log on the Longhorn DC:
>>>
>>>
>>> 07/10 14:01:39 [MAILSLOT] Ping response 'Sam Logon Response  
>>> Ex' (null) to \\W2009-1 Site: Default-First-Site-Name on UDP LDAP
>>> 07/10 14:01:39 [SESSION] NetrServerAuthenticate entered: W2009-1  
>>> on account W2009-1$ (Negot: 400701ff)
>>> 07/10 14:01:39 [SESSION] NetrServerAuthenticate3: the client  
>>> W2009-1$ is asking for NT4 crypto and this server disallows it.
>>> 07/10 14:01:39 [MISC] Eventlog: 5722 (1) "W2009-1" "W2009-1$"  
>>> 0xc0000388 d0706242 73ca0006 205b4f26 3a297e85   Bbp....s&O[ .~):
>>> 07/10 14:01:39 [MISC] Didn't log event since it was already logged.
>>>
>>>
>>> Err - are the details of Windows 2000+ secure channel support  
>>> emerged from your collective investigations?  I'm certain there's  
>>> a policy to change this restriction, but changing security  
>>> policies is not usually something domain admins want to do.    
>>> Who's our resident secure channel expert?
>>>
>>> (I'll do some independent investigation over coffee and  
>>> basketball w/ my favorite netlogon developer - but he may not be  
>>> super helpful given the proprietary nature of the protocol, as  
>>> well as the fact that its damn hard to figure out).
>>>
>>> Todd
>>>
>>>
>>>
>>> On Jul 3, 2007, at 4:16 PM, Jeremy Allison wrote:
>>>
>>>> On Tue, Jul 03, 2007 at 04:10:30PM -0700, Todd Stecher wrote:
>>>>>
>>>>> I'm sure this is the first layer of the onion (there are encoding
>>>>> issues in the old Microsoft implementation as well), but  
>>>>> there'll be
>>>>> more - before I get too deep, is this work already being done
>>>>> elsewhere???  If not, I should be able to get fairly solid  
>>>>> Longhorn
>>>>> Server interop moving forward in the next week, and will submit  
>>>>> a patch.
>>>>
>>>> Not to my knowledge ("work already being done elsewhere"). I'd
>>>> appreciate a patch and I'll definately review it asap.
>>>>
>>>> Thanks !
>>>>
>>>> Jeremy.
>>>
>>> Todd Stecher | Windows Interop Dev
>>> Isilon Systems    P [phone]     F  [phone]
>>> www.isilon.com    D [phone]    M [phone]
>>>
>>>
>>>
>>
>> Todd Stecher | Windows Interop Dev
>> Isilon Systems    P [phone]     F  [phone]
>> www.isilon.com    D [phone]    M [phone]
>>
>>
>>
>
> Todd Stecher | Windows Interop Dev
> Isilon Systems    P [phone]     F  [phone]
> www.isilon.com    D [phone]    M [phone]
>
>
>

Todd Stecher | Windows Interop Dev
Isilon Systems    P [phone]     F  [phone]
www.isilon.com    D [phone]    M [phone]

[Gerald Carter-4]

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

eddietse wrote:
> How about use the the servicePricipalName attribute from
> Active Directory for the target HOST.

The SPN doesn't contain the realm.  You need to search for
(dNSHostName=$fqdn) in GC and then you could deduce the realm
from the DN by converting the RFC2247 DC syntax back to a dns
domain.  However, this wouldn't really work well for cross
realm trusts as you can't tell the difference between a host
in another forest and one that is just not in AD.

> Todd Stecher-4 wrote:
>>
>> I have this all working (against NT4, W2000, 2003, 2008), but our  
>> implementation has taken a dependency to start adding the default  
>> realm to krb5.conf when making outbound CIFS request from a Samba  
>> server (e.g. RPC).
>>
>> This is because before these changes we used to rely on the principal  
>> returned in the spnego negtokeninit message (which had the form host/
>> machinename.domain.com@...).  However, now the principals  
>> we're passing into the kerberos libraries are of the form host/
>> machinename.domain.com (no info after the @ sign).  This means it has  
>> to fall back on the default realm value provided in krb5.conf for  
>> realm location.
>>
>> Is it fairly normal for people to add in the default realm into  
>> krb5.conf when running in ADS mode?  Any suggestions on a "better"  
>> way to divine the service's realm, if its not available in the SPNEGO  
>> message?

Todd, If I understand you correctly, using the default realm
from krb5.conf means that we break when contacting a server
via a cross realm trust, no?





cheers, jerry



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGpLj7IR7qMdg1EfYRAt+tAJ48LmsLilg2nXhLLnRe4uM/6rBygQCdGm9L
pVnuyIeCQa/47CCpmr/IV7Y=
=j26Y
-----END PGP SIGNATURE-----