Samba-3.0.7-1.3E Active Directory Issues

Doug VanLeuven roamdad at sonic.net
Wed Oct 27 21:55:58 GMT 2004


Nalin Dahyabhai wrote:

>On Wed, Oct 27, 2004 at 11:32:16AM -0700, Doug VanLeuven wrote:
>  
>
>>Good to have this patch for samba interop, but I doubt unix command line 
>>utilities using DES can be made to interoperate with a MS KDC 2000 or 
>>2003 server.
>>    
>>
>
>It may not be quite that bad.  The application server and the KDC do
>have to agree on the application server's key, but the client isn't
>expected to be able to decrypt things with that key.  It doesn't even
>have to know how to encrypt things with that key, which places the
>entire interoperability burden on the application server and the KDC.
>  
>
Well, I made that statement in the context of host/shortname.realm at REALM 
!= host/fqdn at REALM for older Kerberos libraries that do not have 
rc4-hmac available as an enctype.  For the instance of DNS name != REALM 
DNS using des-cbc-md5, the MS KDC will encrypt the password with a salt 
unacceptable to native Kerberos libraries where reverse IP has to 
resolve to the actual DNS name and a keytab entry of host/fqdn at REALM.

On the other hand, if the reverse IP resolves to shortname.realm, then 
DNS == REALM and samba works to authenticate using DES just fine without 
your patch AND run native applications dependent on Kerberos library 
authentication.

What I am saying is you'll run into the situation where someone asks 
"Hey, my machine DNS is out of REALM and samba works with DES 
encryption, how come klogin or ktelnet doesn't?"  for the specific 
instance of where samba corrects MS 2000 & 2003 incorrect salting on DNS 
domain out of realm installations that must use DES enctype because 
rc4-hmac is not available.

Again, this is all about samba managed keytabs.  It looked to me that 
creating a user account and mapping a Kerberos principal to it, then the 
MS KDC used the correct salt for out of domain principals.  This is just 
when the MS KDC is only using the computer account information to 
construct the salt and encrypt the key as when samba creates and manages 
the keytab.

As I understand the specs,
Frequently asked questions about Kerberos
Subject:1.23. What is a key salt? kvno?
To understand a key salt, it's important to remember that in Kerberos 
you prove your identity by being able to decrypt or encrypt data using 
an encryption key that you share with the KDC.

So yes, the client applications using native Kerberos libraries do have 
to be able to decrypt what is encrypted by the KDC.

Kinit, itself, outside of samba would have difficulties getting the 
initial tgt if it's not using the same salt as the MS KDC in the 
specific instance of DNSdomain != REALM and stuck with des-cbc-md5.

>But if the computer account is not flagged as requiring DES, then the
>KDC's preference for RC4 will ensure that the incorrect DES keys in the
>keytab are never used by the application server.
>  
>
This would only be true for more current Kerberos and if so, don't need 
to use DES encryption at all, and there's no need for a salt and what I 
wrote about MS not fixing in 2000 and 2003 isn't relevant.

Even in rc4-hmac, there is still a need for multiple SPN's host/fqdn and 
host/shortname.realm (same for cifs) in the computer account for samba 
to work as it sits.  For the specific instance of DNSdomain != REALM.

Nice job on the patch.  Too bad MS messed up it's design goal.  I don't 
believe they expected anyone to be using the computer account in the way 
samba does, although I believe they should have.  All their 
interoperability papers map Kerberos principals to user accounts.  
You're completely correct in saying the interoperability burden is 
normally on the Kerberos implementer, in this case MS.

I really was just informing the list that MS acknolwedges the issue of 
the salts and won't be fixing it in server 2000 or 2003.  There is an 
outside chance it will be fixed in the next release, but by then, DES 
only in a mixed mode windows/unix environment will be, for all practical 
purposes, obsolete.

So if you want to fix it now, your patch is the only way.  Kudos to 
Redhat and you personally.

Regards, Doug

Chief Engineer, USMM
Systems Engineer, LDX Microsystems
Systems Analyst, Sonoma County Water Agency



More information about the samba-technical mailing list