Samba-3.0.7-1.3E Active Directory Issues
roamdad at sonic.net
Fri Oct 15 23:21:50 GMT 2004
Will Tatam wrote:
>I'm running a REHL 3 server which had previously been running perfectly
>with security=ADS but after running redhat's up2date to install 3.0.7-1E
>i started getting "Failed to verify incoming ticket!"
>After speaking to Jeremy Allison at Linux Expo he suggested that I
>needed the MIT 1.3.x version of kerberos installed, however rpm -qa |
>grep krb5 reports
>For the moment I have got the system back up and running by reverting to
>security=domain however I would like to get the system up and running
>correctly using *official* redhat rpms so that my system is correctly
>covered by the support contract.
>RedHat have tried to fob me off my saying that this isn't really
>supported by their SLA and saying that it's a samba issue see
>The last message from them helpfully told me "Samba 3.0.7 is now
>officially released, you might want to try this version and see if that
>resolve your current problem." even though 3.0.7 was released by them on
>the 30th of september and that is was this new release that triggered my
This thread you started, and others I've seen, pushed me into removing
the rc4-hmac enctype from my list of permissible enctypes, wiping all
the tdb files on my production domain developement machine and starting
over trying to establish samba and local Kerberos utilities using
des-cbc-crc or des-cbc-md5 against my 2003 AD.
I originally had this going months ago on my AIX systems using the IBM
writeup and the MS hotfix 833708, before I decided to upgrade the
Kerberos to 1.3.4.
Imagine my surprise when not much worked.
I use the MS resource kit kerbtray.exe so I can see the DC's idea of
what ticket is in use. No matter that I had eliminated any usage of
rc4-hmac from the Kerberos files on the AIX system, the DC KDC was
listing RSADSI RC4-HMAC as the ticket encryption type and of course,
since that was no longer a usable enctype on the AIX box, samba and
local utilities couldn't authenticate.
There's a checkbox for "Use DES encryption for this account" listed for
users, but nothing for computers. That option is set in
userAccountControl as 0x200000 or 2097152 decimal.
If I use adsiedit.msc and add the value 2097152 dec to the existing
value of userAccountControl (69632 dec) what I end up with for the
computer account shows up in ldp.exe as
userAccountControl: 0x11000 = ( UF_WORKSTATION_TRUST_ACCOUNT |
userAccountControl: 0x211000 = ( UF_WORKSTATION_TRUST_ACCOUNT |
UF_DONT_EXPIRE_PASSWD | UF_USE_DES_KEY_ONLY );
Works like a champ. kerbtray.exe is showing "Kerberos DES-CBC-MD5" on
the 2003 DC as the enctype. Might do the trick for you. Of course the
machine has to be "net ads join" before you can edit it. But that was
always working for me, even when little else was. To kick start it, I
had to type the admin & password dialog box once after browsing over
because of the prior failures.
It's actually listed as a legal value in the NET_DISPLAY_MACHINE
structure at MS
Platform SDK: Network Management
To test against a RH box running MIT Kerberos 1.3.4 I switched to the
test 2003 domain and removed any references to rc4-hmac like above from
the RH9 samba server. Here the samba server was a member of a parent
DNS domain that had been working with the enctype of rc4-mdac and the
workarounds of adding the HOST/FQDN and CIFS/FQDN to
servicePrincilpalName . Even with the above I get the "Failed to
verify incoming ticket!".
Reconfiguring the server so DNS=REALM was necessary to fix this.
I then rolled back MS hotfix 833708 and samba key renewal didn't work.
What I get out of this
1. Samba server currently has to have DNS domain resolve to the REALM
for des-cbc-md5 to work reliably. Probably because (from
kerberos-faq/general) "In Kerberos 5 the complete principal name
(including the realm) is used as the salt. This means that the same
password will not result in the same encryption key in different realms
or with two different principals in the same realm.". So I have to
agree with Nalin Dahyabhai about the salts from a branch of this thread,
the MS KDC is using hostname.realm at REALM. It explains why a common
error reported is "Decrypt integrity check failed",
KRB5KRB_AP_ERR_BAD_INTEGRITY - the krb5 responce for bad password if the
Unix krb5.keytab is using the principal hostname.dnsdomain at REALM.
2. userAccountControl requires UF_USE_DES_KEY_ONLY or the MS KDC tries
to issue an rc4-hmac ticket.
3. The MS hotfix 833708 for 2003 servers to allow clients to pick the
etype is part of the cure
And maybe my MIT Kerberos 1.3.4 has a better implementation of the DES
enctypes than your 1.2.7. I can't revert that far back.
I let samba manage the keytab. If you manage your own keytab, the
results would vary.
I hope it helps. In the last 5 months I have gone round and round on
this issue. I personally feel much better now. I won't feel like I'm
betraying the trust of several hundred users by deploying this now.
It's like you did me a favor by enervating me :-)
I suppose if I was really enervated, I'd write & propose a patch for an
option to "net ads" that would flag --des-only and --any-enc for
backwards compatibility and have samba do it during the join or any time
later on. If I don't have to go to Spain, and can test more of the
permutations, I'll do that.
Kind of chatty for the technical list. Hope no one is offended.
More information about the samba-technical