Thread: LDAP Authentication

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.

Thanks,

Stephen

Greetings,

* Dominique Devienne (ddevienne@gmail.com) wrote:
> On Thu, Aug 24, 2023 at 10:07 PM Stephen Frost <sfrost@snowman.net> wrote:
> > * 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.

> 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?

https://www.crunchydata.com/blog/windows-active-directory-postgresql-gssapi-kerberos-authentication

> 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?

(just fyi- while they're not exactly the same, where I say 'Kerberos'
below, you can think of it as GSSAPI, Kerberos, or Kerberos/GSSAPI)

More-or-less.  Windows AD uses Kerberos/GSSAPI already for tons of
authentication- when you log into a AD connected system, that's
Kerberos, when you connect to an IIS site in an AD environment and
automatically get authenticated, that's Kerberos (and Negotiate to wrap
it, but still), when you connect to SQL Server, again, Kerberos.

The "pass-the-password" LDAP-based auth method is just about exclusively
used for 3rd-party non-Kerberos-speaking services.  When you have the
option to use Kerberos, you absolutely should.

> 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?

Kerberos *is* the true SSO that you're looking for- when you sign into
any AD connected system (eg: your laptop), you get Kerberos credentials
(run 'klist' at a cmd prompt sometime..) and you don't have to provide
your password again for any Kerberos authentication until/unless your
Kerberos tickets (acquired when you logged into the laptop) expire.

With the LDAP auth method, the user has to provide their AD password on
every connection to authenticate, or worse, save their AD password for
connection in some local file so they don't have to type it in every
time.  That password is then also sent to the PG server on every
connection, meaning that if the PG server is compromised, the account of
every user who logs into that PG server is then also compromised- their
full AD account.

> 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?

Kerberos tickets are acquired from the AD when you log into your laptop.
Those tickets will have some lifetime (which you can configure, but
tends to be 8-10 hours or so).  When you connect to a Kerberos service,
the system will automatically reach out to the AD to obtain a ticket for
that service (eg, a PostgreSQL ticket, for your account) which will also
have a specific lifetime.  When you connect to PostgreSQL, the PG server
is able to verify your identity based on the ticket you present- the PG
server never has to reach out to the AD system for user authentication.
For as long as the PostgreSQL ticket that you acquired when you first
connected to the PG server is valid (again, typically 8-10 hours, but
you can configure it), the AD server is no longer involved and doesn't
need to be contacted, no matter how many subsequent connections you make
to the PG server.

Note that Kerberos is all about authentication- not about authorization.
There's a few different tools out there for sync'ing users from AD into
PostgreSQL and those can be used to manage who is authorized for a given
PG server, including removing their authorization in a relatively short
period of time if needed (more-or-less how often you feel like running
the sync'ing cronjob or such).  I do think it'd be pretty cool to
improve on that with a way for PG to reach out to an AD system and run a
query and then track the changes to that query (LDAP has support for
this kind of thing) which would make changes to, eg, group membership in
AD propagate to the PG server in pretty close to real-time.  Sadly, I'm
not aware of anyone actively working on that though.

> Given that caching is often more trouble than it's worth, how is that
> better? Naïve question, really. --DD

This one I find pretty curious given that cacheing is a very large part
of what PostgreSQL does and is certainly quite worth it. ;)

Thanks,

Stephen