On Thu, 6 Oct 2011, Steve Rikli wrote:
That's what I thought. But doesn't that "lookup" account need to have a published password (and likewise, hardcoded in scripts and config files and whatnot) in order to do the LDAP querying without end-user interactivity?
Yes. Either you're talking about a samba tdb file, a password in plain text, or a kerberos keytab file. GSSAPI means you don't need to hardcode anything, as it just fishes around in your keytab.
Granted, we're talking about "public data" in this example (i.e. automount map data) so security isn't a concern for that part; but the "lookup" account could potentially be used for other means, yes?
It can be used to do what you grant it access to do (but it can be constrained). That's not worse than NIS.
or you do it AD style and have an account per machine.
OK for user workstations, impractical when you're talking about servers, no? Or do I misunderstand your example?
Account per machine is fine. As part of your install do a 'net ads join' (in AD speak), and you're done. You'll want kerberos credentials per machine anyway, so it's nothing new. Servers more than clients want kerberos credentials, as lots of services can benefit from kerberos authentication (httpd, cups, nfs, ssh, smtp, imap...).
As I do it, this auth is done with a kerberos keytab credential with GSSAPI.
Sounds like I would need to research that, then. This replaces the need for the "lookup" account, or augments it, or something else entirely?
If you're generating a keytab per machine (which you want for kerberised services), then having a credential within that that's able to do lookups isn't a big extra. Look at FreeIPA as suggested, as this wraps all this up and makes it quite straightforward (in much of the same way as MS AD does).
jh