How should one go about setting up client-side keytab files for each client machine to access network services? My working example is NFSv4, which requires each client to have a Kerberos keytab locally on the client machines (as well as the NFS server hosts).
-
What badness, if any, could result from sharing the same key in a generic keytab file (for NFS purposes) between all client machines requiring access to the NFS host(s)?
-
If, from the result of #1, we really do need to use a separate key in a different keytab on every client, what is an effective — and, more importantly, secure — way to automate the creation of the keytab for each of several thousand machines? I don't want to have to generate and export a key on every box!
Best Answer
A generic keytab is no use at all - the Kerberos Service Principle is tied to hostname. So a generic keytab simply won't work. You don't necessarily need an NFS specific key - depending which OS version you're using. We can use
HOST/full.qualified.hostnameto authenticate NFS on RHEL 6+.So yes, you do need a keytab on each machine. I know that's horrible, but that's the way of things.
Bear in mind that in a Windows domain, you have to do effectively the same thing with your 'domain join' process - one of the major things that does is create a keytab on Windows clients.
We've started down the road of integrated domains - binding our Linux clients to a Windows AD. With that approach, you can use the
netcommand on Linux e.g.net ads joinwhich is I think part of SAMBA. You can embed into it a username and password, and run it via whatever existing automation mechanism you have already. (net ads keytab createalso does .... well exactly what it says on the tin. )If you're not using an AD, then I'm afraid I don't know. I would imagine that something similar exists for generating a keytab.