In article alpine.LRH.2.02.1110062229170.24568@pfyva-tcf.pfhavk.pbzc.yrrqf.np.hx, John Hodrien centos@centos.org wrote:
On Thu, 6 Oct 2011, Steve Rikli wrote:
So, back to my original example of automount maps (which I've long thought about implementing in LDAP but never pursued), how do you deal with the situation of needing map(s) loaded, without an active user on the system to authenticate the LDAP query with their username/password?
That is, NIS clients bind to the NIS server, and thereby have access to auto.home map or what have you, whether a user ever logs into the client system or not. Automounter is functional and has the map data.
You need an account that can do lookups. Either you have one 'lookup' account that you share between multiple machines,
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?
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?
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?
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?
What's the functional equivalent for LDAP automount maps?
Automount maps work just nicely in LDAP, there's a standard schema and you just populate the records and it works.
I grok'd that part; it was the "NIS binding" sort of equivalent behavior that I was specifically interested in for LDAP.
Cheers, sr.