SPNEGO in Samba - Longhorn Server interop issues... - KRB5.CONF

[Todd Stecher]

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 at 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 +1-206-315-7500     F  +1-206-315-7501
>>> www.isilon.com    D +1-206-315-7638    M +1-425-205-1180
>>>
>>>
>>>
>>
>> Todd Stecher | Windows Interop Dev
>> Isilon Systems    P +1-206-315-7500     F  +1-206-315-7501
>> www.isilon.com    D +1-206-315-7638    M +1-425-205-1180
>>
>>
>>
>
> Todd Stecher | Windows Interop Dev
> Isilon Systems    P +1-206-315-7500     F  +1-206-315-7501
> www.isilon.com    D +1-206-315-7638    M +1-425-205-1180
>
>
>

Todd Stecher | Windows Interop Dev
Isilon Systems    P +1-206-315-7500     F  +1-206-315-7501
www.isilon.com    D +1-206-315-7638    M +1-425-205-1180