Samba-3.0.7-1.3E Active Directory Issues

[Doug VanLeuven]

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
>
>pam_krb5-1.73-1
>krb5-libs-1.2.7-28
>krb5-devel-1.2.7-28
>krb5-workstation-1.2.7-28
>
>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 
>http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=132378
>
>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
>problems
>  
>
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
before:
userAccountControl: 0x11000 = ( UF_WORKSTATION_TRUST_ACCOUNT | 
UF_DONT_EXPIRE_PASSWD );
after:
 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 
<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/netmgmt/netmgmt/net_display_machine_str.asp>

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.

Regards, Doug