Samba-3.0.7-1.3E Active Directory Issues

[Doug VanLeuven]

Nalin Dahyabhai wrote:

>On Thu, Oct 14, 2004 at 03:21:51PM -0700, Doug VanLeuven wrote:
>  
>
>> <>Nalin Dahyabhai wrote:
>> I recently spent a chunk of time looking at this, too. From what I can
>> tell, your patch is very much on the right track. My tests point to AD
>> salting passwords which are used for generating keys with salts which
>> differ from the ones Samba is using.
>>
>> Specifically, for a host "sparky.example.com" joined to a domain named
>> "AD.EXAMPLE.COM", the salt which AD uses is produced by giving the
>> principal-to-salt function "host/sparky.ad.example.com at AD.EXAMPLE.COM".
>> This salt is apparently used when generating keys for any service which
>> runs on sparky.
>>
>>If you want to join a computer whose DNS domain is different than the 
>>REALM, please see this bug report
>>https://bugzilla.samba.org/show_bug.cgi?id=1651
>>    
>>
>
>I agree: if your realm name doesn't match your DNS domain name, you're
>going to have some weirdness.  Bug #1651 looks very much like #705.
>
>I'm fairly certain that the difference in the selection of the salt is
>an unrelated problem.  Elaborating on my example, if the client makes a
>request to the KDC for credentials to authenticate to "sparky$",
>"SPARKY$", "cifs/sparky.example.com", or even "imap/sparky.example.com",
>the KDC will still derive keys for each of those services using the salt
>corresponding to "host/sparky.ad.example.com at AD.EXAMPLE.COM".
>  
>
Actually, I think it's 2 sides of the same problem.
I agree the issue is samba and the MS KDC using different salts.
It's the why of it.

Does the MS KDC construct a salt without actually using the 
servicePrincipalName, instead constructing it from machine name and realm?
Or does the MS KDC construct the salt from the servicePrincipalName it 
has on file that is unfortunately incorrect?

I still think if samba was consistent in it's usage of DNSdomain for the 
servicePrincipalName from net ads join and all subsequent calls that the 
issue of what salt to use would be moot.  The standard says use the 
complete principal name including realm.

It works to join a windows box to the REALM from outside the AD DNS 
domain and have Kerberos work, it's just that since the 
servicePrincipalName is only assigned on re-boot of the machine, a 
security setting has to be changed to allow the re-booting machine to 
pick it's own domain instead of being assigned one by the DC or 
administrator.  So it's rarely done.  And it's r4-hmac which doesn't use 
a salt, I know.

I followed the MS procedure to join a windows machine in a different 
domain than the REALM.  This is what I got.  Clearly MS set 
servicePrincipalName to HOST/lab-wkstn1.dnsdomain.  The assumption is 
the MS KDC would be using that for the salt.

 >> Dn: CN=LAB-WKSTN1,CN=Computers,DC=nt,DC=ldxnet,DC=com
    1> cn: LAB-WKSTN1;
    1> displayName: LAB-WKSTN1$;
    1> name: LAB-WKSTN1;
    1> userAccountControl: 0x1000 = ( UF_WORKSTATION_TRUST_ACCOUNT );
    1> sAMAccountName: LAB-WKSTN1$;
    1> operatingSystem: Windows 2000 Professional;
    1> operatingSystemVersion: 5.0 (2195);
    1> operatingSystemServicePack: Service Pack 4;
    1> dNSHostName: lab-wkstn1.ldxnet.com;
    2> servicePrincipalName: HOST/LAB-WKSTN1; HOST/lab-wkstn1.ldxnet.com;

A snapshot of a ticket list on the KDC follows.

gate is my samba server.  It's actually the ldxnet.com domain BIND9 
server and should live in that domain.  It's running des-cbc-md5, but 
only after I reconfigured it to be a member of it's child DNS domain - 
so the salt would be correct.  I believe that's true because of the 
incorrect initial servicePrincipalName entries added by samba.

Lab-wkstn1, a win2000 machine, has what I'd wish to see for samba.  
cifs/hostname.DNSdomain at REALM.
DES, with the normal salt rules, and nothing else, should work for that.

Tell me how to setup a win2000 to use des-cbc-md5 as the default and 
disable rc4-hmac and I'll run the test.

Regards, Doug

Cached Tickets: (6)
...
   Server: cifs/Lab-wkstn1.ldxnet.com at NT.LDXNET.COM
      KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)
      End Time: 10/16/2004 9:01:53
      Renew Time: 10/22/2004 23:01:53

   Server: cifs/gate.nt.ldxnet.com at NT.LDXNET.COM
      KerbTicket Encryption Type: Kerberos DES-CBC-MD5
      End Time: 10/16/2004 9:01:53
      Renew Time: 10/22/2004 23:01:53