Samba-3.0.7-1.3E Active Directory Issues

Eric Horst erich at cac.washington.edu
Thu Oct 21 23:19:53 GMT 2004


On Thu, 14 Oct 2004, 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.
>
> [...]
>
> Anyhow, I put together a patch [1] 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.)

First, the best part of your patch [1] is the description which includes 
the first ever mention of this gem:

"The enctype which AD uses when issuing tickets for a service depends on 
the userAccountControl attribute of the computer account entry in the 
directory, so the RC4-or-DES behavior can be controlled by modifying this 
value.  Samba sets this value when the computer account is created, but it 
does not currently modify the value if you rejoin to an existing account, 
even if your Kerberos implementation gains or loses the ability to use RC4 
ciphers.  This may cause some confusion if systems are upgraded."

I was stumped for a long while wondering why changing to Kerberos 1.3.5 
made no improvement to my situation. Deleting the computer account and 
rejoining did the trick.  Simply redoing the "net ads join" without 
deleting wasn't sufficient.

Beyond this helpful tip I like the idea of your patch. My 3.0.4 to 3.0.7 
upgrade is still stumped and seems that it might be this issue. Your patch 
is not quite working for me though. Problem starts in the net join:

# net ads join
Using short domain name -- DOMAIN
[2004/10/21 16:07:48, 0, pid=6404] libads/kerberos.c:verify_service_password(369)
   kerberos_kinit_password HOSTNAME$@DOMAIN.WASHINGTON.EDU at DOMAIN.WASHINGTON.EDU
   failed: Preauthentication failed
Segmentation fault

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

I love your fqdn patch [2]! Seems to do the right thing. It addresses my 
long standing bug (705) that you reference in your description. Until now 
I'd been using setspn.exe to manually add service principals.

Although, as hinted above, with Samba 3.0.7 even adding the additional 
service principals doesn't result in working Kerberos and it looks like 
your salt patch might be the solution. At least it looks that way right 
now.

> I'd love to get some feedback on these.
>
> [1] http://people.redhat.com/nalin/test/samba-3.0.8pre1-salt.patch
> [2] http://people.redhat.com/nalin/test/samba-3.0.8pre1-fqdn.patch

I'd love to see more. I'm currently confused by the apparent mess around 
Red Hat Enterprise, Kerberos 1.2.7 vs 1.3.5, and Samba. It shouldn't be 
this hard. I'm still just trying to get updated from 3.0.4 to 3.0.7 but 
finding it annoying to figure out where the landmines are. It isn't going 
smoothly.

--Eric


More information about the samba-technical mailing list