I have kerberized NFSv3 working with a generic Linux NFS server and multiple Linux clients with a Windows AD 2012 domain for the Kerberos Realm.
Windows KDC requires that when you create a keytab for authentication to the NFS server you must map an AD user to a Service Principal (Linux client). When you create the keytab with ktpass you input the password of that user which is the password used to create the key.
So to create a new Service Principal and therefore specific keytab for each new Linux client I therefore have to map each Service Principal (Linux client) to a unique User Principal in AD.
If I map the Service Principal to the same User Principal, each time I run ktpass the previous keytabs created for other clients would stop working as the key for that user changes. Therefore you are obliged to create a new User Principal for each Service Principal for each new client, which seems an administrative nightmare.
My notes are here –
As a workaround for this if I use say the first keytab created for the first Linux client for all Linux clients this works just fine, and saves me having to create lots of new users and export new keytabs each time. A sort of generic approach.
So my question –
Is the workaround suggested in the spirit of Kerberos as despite working it does not correctly identify the Linux clients through specific Service Principals? (I am not sure if it is that important for the keytab to identify the actual client, as the user subsequently identifies themselves by authenticating with kinit to actually write stuff to the NFS export)
Any clarification would be great
You are meant to distribute the keytab for the service to everyone who needs it.
If you regenerate the keytab, the KVNO (version number) will be incremented, invalidating any other keytabs for that service with a lower KVNO.
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.