Bug 3697 - Can't get new principal that is not in Windows' built-in list
Summary: Can't get new principal that is not in Windows' built-in list
Status: NEW
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: Client Tools (show other bugs)
Version: 3.0.14a
Hardware: Other Linux
: P3 normal
Target Milestone: none
Assignee: Samba Bugzilla Account
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-04-18 10:16 UTC by Rudi Chiarito
Modified: 2006-04-20 09:27 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Rudi Chiarito 2006-04-18 10:16:01 UTC
The page at

http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/tkerbdel.mspx

features a list of principals that are recognised by default by an AD controller. Other principals are still possible, they just require further permissions.

I am successfully adding hosts to a folder in the AD tree over which I have been given full control (I am not otherwise an AD administrator). I can get principals with "net ads keytab add" for CIFS, HOST, HTTP, DNS, etc., but I can't get one for NFS. I can actually create one using my credentials on an XP Professional system, so I know it's not a problem on the server side.

Can anyone reproduce this? It should be trivial given a Samba client and an AD server.
Comment 1 Gerald (Jerry) Carter (dead mail address) 2006-04-20 07:49:20 UTC
Please provide some more details and logs to illustrate the problem.
Thanks.
Comment 2 Rudi Chiarito 2006-04-20 09:27:08 UTC
(In reply to comment #1)
> Please provide some more details and logs to illustrate the problem.
> Thanks.

# kinit USER
Password for USER@DOMAIN:
# net ads keytab add nfs/HOST.FQDN@DOMAIN [domain part of FQDN and DOMAIN are different]
Processing principals to add...
# klist -k | grep nfs
   2 nfs/HOST@DOMAIN
   2 nfs/HOST@DOMAIN
   2 nfs/HOST.FQDN@DOMAIN
   2 nfs/HOST.FQDN@DOMAIN
# kvno nfs/HOST.FQDN
nfs/HOST.FQDN@DOMAIN: Server not found in Kerberos database while getting credentials

There is a first bug here: the net command adds a bogus principal to the keytab that doesn't exist on the KDC.

Let's try with -d3:

# net ads keytab add -d3 -S KDC test/HOST.FQDN@DOMAIN
[2006/04/20 09:13:21, 3] param/loadparm.c:lp_load(3916)
  lp_load: refreshing parameters
[2006/04/20 09:13:21, 3] param/loadparm.c:init_globals(1321)
  Initialising global parameters
[2006/04/20 09:13:21, 3] param/params.c:pm_process(573)
  params.c:pm_process() - Processing configuration file "/etc/samba/smb.conf"
[2006/04/20 09:13:21, 3] param/loadparm.c:do_section(3418)
  Processing section "[global]"
[[ adds a bunch of interfaces ]]
Processing principals to add...
[2006/04/20 09:13:21, 3] libads/ldap.c:ads_connect(285)
  Connected to LDAP server x.x.x.x
[2006/04/20 09:13:21, 3] libads/ldap.c:ads_server_info(2469)
  got ldap server name KDC@DOMAIN, using bind path: [snip]
[2006/04/20 09:13:21, 3] libads/sasl.c:ads_sasl_spnego_bind(204)
  ads_sasl_spnego_bind: got OID=1 2 840 48018 1 2 2
[2006/04/20 09:13:21, 3] libads/sasl.c:ads_sasl_spnego_bind(204)
  ads_sasl_spnego_bind: got OID=1 2 840 113554 1 2 2
[2006/04/20 09:13:21, 3] libads/sasl.c:ads_sasl_spnego_bind(204)
  ads_sasl_spnego_bind: got OID=1 2 840 113554 1 2 2 3
[2006/04/20 09:13:21, 3] libads/sasl.c:ads_sasl_spnego_bind(204)
  ads_sasl_spnego_bind: got OID=1 3 6 1 4 1 311 2 2 10
[2006/04/20 09:13:21, 3] libads/sasl.c:ads_sasl_spnego_bind(211)
  ads_sasl_spnego_bind: got server principal name =KDC$@DOMAIN
[2006/04/20 09:13:21, 3] libsmb/clikrb5.c:ads_cleanup_expired_creds(318)
  Ticket in ccache[FILE:/tmp/krb5cc_0] expiration Thu, 20 Apr 2006 18:37:11 GMT
[2006/04/20 09:13:21, 2] libads/kerberos_keytab.c:ads_keytab_add_entry(79)
  ads_keytab_add_entry: Using default system keytab: WRFILE:/etc/krb5.keytab
[2006/04/20 09:13:21, 3] libads/kerberos.c:kerberos_derive_salting_principal_for_enctype(552)
  verify_service_password: get_service_ticket failed: Server not found in Kerberos database
[2006/04/20 09:13:21, 3] libads/kerberos_keytab.c:ads_keytab_add_entry(149)
  ads_keytab_add_entry: Will try to delete old keytab entries
[2006/04/20 09:13:21, 3] libads/kerberos_keytab.c:ads_keytab_add_entry(268)
  ads_keytab_add_entry: adding keytab entry for (test/HOST.FQDN@DOMAIN) with encryption type (23) and version (2)
[2006/04/20 09:13:21, 3] libads/kerberos_keytab.c:ads_keytab_add_entry(268)
  ads_keytab_add_entry: adding keytab entry for (test/HOST.FQDN@DOMAIN) with encryption type (3) and version (2)
[2006/04/20 09:13:21, 2] utils/net.c:main(897)
  return code = 0

That seems to say to me that an error was ignored. Unless get_ticket_service failure does not necessarily preclude new principals from being created.

Attempts to create principals with names included in Windows' built-in list work  as expected.

On the XP system, I can use setspn to create a principal for the Linux system using 'nfs' or any other random principal name (again, that's because my user has been given complete control over the OU into which the machine account was created).

Is this enough? Anything else I can try to help pinpoint the problem?