Samba-3.0.7-1.3E Active Directory Issues

[Nalin Dahyabhai]

On Sat, Oct 16, 2004 at 04:18:26AM -0700, Doug VanLeuven wrote:
> 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?

My experiments suggest that the servicePrincipalName is only used for
retrieving the computer account's password.  Once the computer's
password is determined, the servicePrincipalName and dnsHostName values
in the computer account entry seem to have no impact on the derivation
of the key.  The machine name and realm name appear to be the only
values which influence things.

> 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.

You've lost me here.  Are you saying that a Windows host attempts to set
(or reset) its servicePrincipalName values every time it's booted, and
that there's a configuration flag somewhere on the server which needs to
be toggled for this to be allowed?

> 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.

I don't think it would.  Samba sets the servicePrincipalName attributes
for an account when you join (or rejoin) the system to the domain.  You
can modify the value manually using "kinit" and "ldapmodify", or using
the adsiedit MMC plugin.

At that point, your clients would stop getting "Server not found in
Kerberos database" errors, and you'd start seeing "Decrypt integrity
check failed" errors on your Samba server, because the key which Samba
attempts to use to authenticate clients is different from the one the
KDC uses.

> 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.
[snip]
> 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

You should be able to add 0x2000000 to the userAccountControl value, per
the MSDN notes on userAccountControl [1], again, using ldapmodify or the
adsiedit MMC plugin.

I wouldn't expect this to trigger any problems on a Kerberos client
running Win2k, because my guess is that a Win2k client probably derives
keys in the same way that a Win2k KDC does.  As long as they use the
same key (no matter how it's derived), they can authenticate.

HTH,

Nalin

[1] http://msdn.microsoft.com/library/default.asp?url=/library/en-us/adschema/adschema/a_useraccountcontrol.asp