Re: LDAP Authentication

On Thu, Aug 24, 2023 at 10:07 PM Stephen Frost <sfrost(at)snowman(dot)net> wrote:

> Greetings,
>
> * Emile Amewoto (emileam(at)yahoo(dot)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