Found on the Postgres mailing list... seems like some folks like to do user provisioning with config management tools rather than LDAP.

I don't agree with the guy, but he does point out one issue that I find interesting, which is the absense of a "history" of sorts. Are you guys thinking of some sort of "snapshotting" / COW feature?

Would something like that even make sense?

-Stephan

---------- Forwarded message ---------- From: Stephen Frost Date: Fri, Sep 13, 2013 at 10:29 AM Subject: Re: [GENERAL] Using LDAP for PostgreSQL permissions/authentication Cc: pgsql-general@postgresql.org

* Bill Moran 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

----------------------------------------