Samba-3.0.7-1.3E Active Directory Issues
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
>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
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
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
So if you want to fix it now, your patch is the only way. Kudos to
Redhat and you personally.
Chief Engineer, USMM
Systems Engineer, LDX Microsystems
Systems Analyst, Sonoma County Water Agency
More information about the samba-technical