Samba-3.0.7-1.3E Active Directory Issues
nalin at redhat.com
Thu Oct 14 19:45:50 GMT 2004
On Thu, Oct 14, 2004 at 10:50:27PM +1000, Andrew Bartlett wrote:
> On Thu, 2004-10-14 at 22:18, 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!"
> I tried to debug this with another site, and came up with this patch.
> Somebody needs to look over the changes back in 3.0.4 with the 'use
> kerberos keytab' stuff.
> My guess was:
> But this apparently didn't work.
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.
Using krb5 1.3 masks the problem because the userAccountControl
attribute of the computer account which "net join" creates indicates
that the Samba server supports RC4, and the RC4 string-to-key function
ignores the salt. So the KDC goes to derive the computer's key from its
password with the non-obvious salt and gets the right key anyway.
Anyhow, I put together a patch  which attempts to guess the right
salt value at "net join" time, and if it hits on one, stores the
principal used for generating that salt in the secrets tdb. I figured
it needed to be done at this point to avoid storing incorrect keys in
the keytab, but it could also have been done on an as-needed basis in
ads_secrets_verify_ticket(), as you're doing. (The patch turned out to
be larger than I originally planned, sorry about that.)
Sort of related to this, if your DNS domain name doesn't match your
realm's name, the servicePrincipalName values which are added for the
computer account would have "sparky.ad.example.com" as the instance, and
Unix clients which request tickets for "host/sparky.example.com" keep
getting "server not found in kerberos database" type errors. I can't
figure out why "net join" sets that value, or what client software
expects it, but I needed to adjust that behavior as well .
I'd love to get some feedback on these.
More information about the samba-technical