Bug 1651 - servicePrincipalName and local Kerberos interoperability with keytab
Summary: servicePrincipalName and local Kerberos interoperability with keytab
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: net utility (show other bugs)
Version: 3.0.6
Hardware: All All
: P3 normal
Target Milestone: none
Assignee: Jeremy Allison
QA Contact: Samba QA Contact
: 705 (view as bug list)
Depends on:
Blocks: 1717
  Show dependency treegraph
Reported: 2004-08-23 14:14 UTC by Doug VanLeuven
Modified: 2005-08-24 10:26 UTC (History)
2 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Doug VanLeuven 2004-08-23 14:14:40 UTC
This gets to be more than one screen, so first the issue.

servicePrincipalName in AD needs to have the actual DNS name of the host
for local Kerberos utilities to work where samba creates and maintains
the keyfile.  Either in addition to, or instead of, using the DNS equivalent
of the Realm.  I have workarounds (see below)
There are some solid reasons I don't want to move all the unix servers into
a delegated DNS zone for AD.  Can't, in some instances.

In other words, samba is sometimes forcing the domain name to be equal to the
Realm name and sometimes it isn't.

In libads/ldap.c
      psp = talloc_asprintf(ctx, "HOST/%s.%s",

It seems this might be a much larger issue than changing the initial setup.
As proof of concept, I have added a windows 2000 client LAB-WKSTN1.ldxnet.com to
a 2003 AD NT.LDXNET.COM and windows is OK with this.  Kerberos works.

>> Dn: CN=LAB-WKSTN1,CN=Computers,DC=nt,DC=ldxnet,DC=com
2> servicePrincipalName: HOST/LAB-WKSTN1; HOST/lab-wkstn1.ldxnet.com;

Notice the workstation does not belong to the nt.ldxnet.com domain.

If I just submitted a patch to add an additional principal name using the real
fqdn when it wasn't the same as the host+realm, it would seem like a kludge
that's missing some fundamental point.
And changing the realm to the DNS domain in the servicePrincipalName
could break fundamental assumptions in the rest of samba.

Thanks everyone for everything.  I just love that I can add unix Kerberos
authentication and utilities in the same moment as upgrading samba from 2.2.x.
And it looks like a masterpiece even if everyone is hot to do it right in the
next release.
Do you still take pizza?  Once upon a time in a land far, far away ...

The gory details:

Linux gate.ldxnet.com 2.4.20-28.9smp #1 SMP Thu Dec 18 13:37:36 EST 2003 i686
i686 i386 GNU/Linux
krb5-1.3.4-i686-pc-linux pre-compiled binary from MIT
samba-3_0 svn revision 1824
Windows 2000 standard server native mode domain (since upgraded to enterprise 2003)
 All current security fixes & updates.

       workgroup = FOREST
       realm = NT.LDXNET.COM
       security = ADS
       use kerberos keytab = yes
       winbind trusted domains only = yes
       idmap backend = ad:ldap://ranger1.nt.ldxnet.com
         (small change to make it work, added for completeness)

 kdc = ranger1.nt.ldxnet.com:88
 admin_server = ranger1.nt.ldxnet.com:749
 default_domain = nt.ldxnet.com

 .nt.ldxnet.com = NT.LDXNET.COM
 nt.ldxnet.com = NT.LDXNET.COM
 gate.ldxnet.com = NT.LDXNET.COM
 ldxnet.com = NT.LDXNET.COM
 .ldxnet.com = NT.LDXNET.COM

Legacy unix domain
ldxnet.com IN SOA  gate.ldxnet.com (the samba 3.0 machine)
   NS      gate.ldxnet.com

Microsoft AD domain, delegated & glued
nt.ldxnet.com IN SOA  ranger1.nt.ldxnet.com
   NS      ranger1.nt.ldxnet.com

Partial list from /etc/krb5.keytab generated by samba
  0 host/gate.ldxnet.com@NT.LDXNET.COM
  0 cifs/gate.ldxnet.com@NT.LDXNET.COM

The host and service principal names get added to servicePrincipalName as
    dNSHostName: gate.ldxnet.com;

This prevents the local Kerberos from finding the host gate.ldxnet.com in the
KDC database.

I have two (2) workarounds.  Each worked alone on seperate linux machines.

1. Use ktpass on the DC to generate the host/gate.ldxnet.com mapping to the
gate$ machine account
 This adds to altSecurityIdentities:
 I'm still waiting to see if this expires.  Not added to /etc/krb5.keytab.

2. Manually edit servicePrincipalName and add
 This worked instantaneously.

In either case, it also seemed advantageous to add the linux names to the
nt.ldxnet.com zone.
Comment 1 Gerald (Jerry) Carter (dead mail address) 2004-08-24 08:12:18 UTC
addiong this to my long list of bugs....
Comment 2 Doug VanLeuven 2004-09-02 13:45:00 UTC
(In reply to comment #1)
> addiong this to my long list of bugs....

Would it make sense not to spend the time in 3.x to fix this, but instead just
request this be part of the consideration for 4.x ?
Then just a short howto paragraph for the few legacy unix admins for whom this
might be applicable?  I could do that.
Comment 3 Gerald (Jerry) Carter (dead mail address) 2004-10-28 07:02:31 UTC
I think this patch from nalin fixes the problem.
Jeremy, handing this one off to you since you're
working on it.  If you need me to look at it, then 
let me know.

Comment 4 Doug VanLeuven 2004-10-29 04:36:44 UTC
(In reply to comment #3)
> I think this patch from nalin fixes the problem.
> http://people.redhat.com/nalin/test/samba-3.0.8pre1-fqdn.patch

Deleted /etc/krb5.keytab, private/secrets.tdb, locks/*.tdb
Delete computer account on 2003 server DC
Delete host A record from AD sub-domain.
Did I forget anything for a completely clean start?

installed fresh svn co 3326 w/patch, including libnns_winbind.so and libnss_wins.so
rebooted machine

net ads join (yes)
start samba
smbclient -k to DC in different combinations
browse from DC to samba, open, delete
winbind functions OK
net ads functions OK

keytab looks good
2 host/linx.ldxnet.com@NT.LDXNET.COM (ArcFour with HMAC/md5) 
2 cifs/linx.ldxnet.com@NT.LDXNET.COM (ArcFour with HMAC/md5)

Virtually no errors in log files
This has fixed it for me

Any other tests anyone want me to do?
Comment 5 Gerald (Jerry) Carter (dead mail address) 2004-10-29 06:32:20 UTC
*** Bug 705 has been marked as a duplicate of this bug. ***
Comment 6 Jeremy Allison 2004-11-05 16:48:35 UTC
Applied - thanks.
Comment 7 Gerald (Jerry) Carter (dead mail address) 2005-08-24 10:26:22 UTC
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.