Greetings,
* Emile Amewoto (emileam@yahoo.com) wrote:
> Here is the high level process:
> 1- Create the user x without password in Postgres.
> 2- Assign role or roles to the user x
> 3- Update pg_hba.conf with the ldap connection link.
>
> You might need cert for the ldap to connect to AD, assuming you are using AD.
If you're using AD, you should *really* be using Kerberos/gssapi for
your authentication and *not* LDAP. LDAP is insecure as it involves
passing around the user's credentials which is extremely bad practice
and is strongly discouraged. LDAP auth also involves in-line round
trips to the LDAP server which can delay or even fail database
connections in the event that the LDAP server is even temporarily
unavailable.
Hi. Sorry, will probably be a stupid question, since these Auth issues are way outside my expertise...
But as part of a team that wants to hook PostgreSQL to the company's Windows AD, could you please
provide more info on how to configure the alternative you suggest should be used instead?
Are you saying AD already "speaks" Kerberos/GSSAPI, and instead of configuring LDAP in hba.conf,
one should configure GSSAPI instead? As "simple" as that?
What about SSO? Can the local creds / token from the already-AD-connected local OS user be extracted,
so the user doesn't need to supply any password, not even the AD-one?
We've successfully tested LDAP with PostgreSQL in the past (on a test AD, not the "real" one though).
Regarding your second point about availability of the LDAP server, isn't that normal to fail connecting
when Auth cannot be ascertained / verified? Kerberos/GSSAPI somehow main some cache to avoid that?
Given that caching is often more trouble than it's worth, how is that better? Naïve question, really. --DD