* Bill Moran (wmoran@potentialtech.com) wrote:
> As documented, LDAP solves a few of the problems we have -- since everyone
> will be in LDAP, we can use LDAP's password complexity rules and password
> expiration to handle those security requirements, and (of course) when
> someone changes their password, they don't have to remember to change it
> on every server ... these are big wins.
Better is to use Kerberos, imv. It's what AD does.
> But it doesn't help with the headache of creating the accounts on all the
> servers, or dropping them as part of employee termination procedures, or
> doing security audits, or changing permissions on multiple servers when
> an employee gets a promotion, etc.
Nope; I'd use puppet or chef or something along those lines to deal with
this aspect, much as I'd do with Unix accounts. Using nsswitch and
tying every user name look up to LDAP has certain.. drawbacks.
> Thus, when I go to log in as wmoran, LDAP checks my password, then informs
> PostgreSQL to allow me in with specified roles, and I can do operations
> granted to those roles.
That's a little over-simplistic, isn't it? What about objects which are
created by the 'wmoran' account?
> Obviously, that's not how it works now ... my question is why not? Is it just
> a matter of nobody's gotten to it yet, or are there issues that make such
> an implementation difficult/troublesome/impossible? If it's possible, does
> anyone have any concept of how hard it would be to implement?
My gut feeling on this is 'pretty darn hard' and 'not sure there are
many who really want it'. That last particularly because tools like
puppet and chef exist and solve this problem in a better way, imv
anyway, than LDAP. Back in the day, I was a big proponent of LDAPv3 and
all of the nice things it did, but the complexities involved in "what
happens when the network goes away" grew tiring and managing accounts
through a config management system which also tracks history of changes,
both to the master repo and to the individual systems, wins hands down.
Thanks,
Stephen
