Samba-3.0.7-1.3E Active Directory Issues

Nalin Dahyabhai nalin at redhat.com
Tue Oct 26 20:25:56 GMT 2004


On Thu, Oct 21, 2004 at 04:19:53PM -0700, Eric Horst wrote:
> 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

Have you enabled the "use kerberos keytab" option?

Kerberos 5 1.2 didn't allow applications to use "WRFILE:" keytabs by
default.  Samba's configure script checks for this at compile-time,
determines that "WRFILE:" isn't available, and assumes that "FILE:" is
the method which should be used for writing to keytabs.  The problem
here is that the pointers to the writing functions for "FILE:" keytabs
are set to NULL.  There's not much Samba can do to work around this,
except maybe check for the error case.

It also looks like you hit upon a bug somewhere, probably in the patch,
because HOSTNAME$@DOMAIN.WASHINGTON.EDU at DOMAIN.WASHINGTON.EDU just looks
wrong (the realm name is being tacked onto the machine account twice).
I'm pretty sure that it's been corrected, but would appreciate it if you
could double-check it with the revised salt patch (below).

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

Thanks!

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

That patch has gone through a few revisions [1] since I originally
posted about it -- in particular, more of the guesswork is done using
loops and iteration, based on some feedback received off-list, and
libsmbclient.so needs to link with $(SECRETS_OBJ) to avoid having
undefined symbols.

I was hoping that there would be One Correct Salt, and the patch could
be pared down to something substantially smaller, but unfortunately I
think it still needs to actually check the validity of a key at "net
join" time.  At least on my test boxes, a Win2k server and a Win2k3
server will use different salts, and I can't tell the difference any
other way.

BTW, I'm using a test program I've placed on people.redhat.com [2] to
obtain credentials for services and verify them with the machine
password -- most of the additional guesses which the patch now makes are
things that I stumbled onto while continuing to test things.  It's been
very helpful in determining what's happening on the KDC.

One more, unrelated, issue that I've run into is that SMB signing
doesn't seem to work quite right if the session key which the client and
server negotiate is a DES key.  After some guessing, it looks as though
the key either needs to be at least 128 bits long, or it needs to be
padded with zeros to make it seem so [3].

Further feedback is still appreciated.

Thanks,

Nalin

[1] http://people.redhat.com/nalin/test/samba-3.0.8pre1-salt-5.patch
[2] http://people.redhat.com/nalin/test/ktverify-0.0.tar.gz
[3] http://people.redhat.com/nalin/test/samba-3.0.8pre1-signing-shortkey.patch


More information about the samba-technical mailing list