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

[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/ 
> 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
> 
> 
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/SPNEGO-in-Samba---Longhorn-Server-interop-issues...-tf4021562.html#a11742731
Sent from the Samba - samba-technical mailing list archive at Nabble.com.