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.
Please provide some more details and logs to illustrate the problem. Thanks.
(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?