Re: User Authentication: LDAP and "local" accounts concurrently ?

Greetings,

* Lentes, Bernd (bernd(dot)lentes(at)helmholtz-muenchen(dot)de) wrote:
> > Am 23.11.2018 um 20:14 schrieb Stephen Frost <sfrost(at)snowman(dot)net>:
> > With LDAP, the user's password will be seen by the PostgreSQL server,
> > and sent over the wire in cleartext unless you're making sure to use TLS
> > on the connection to PG (and if you're doing that you really want to
> > make sure you have verify-full enabled on your clients....).
> >
> > With Kerberos/GSSAPI, the authentication tokens are encrypted by the KDC
> > (in your case, the AD domain controllers) and the user's password is
> > never exposed.
>
> I‘m Not sure wether my Clients speak TLS. I‘m afraid they don‘t.

That's certainly another reason to avoid using LDAP or any of the
password-based authentication methods except maybe SCRAM.

> But isn‘t then also the password transmitted in cleartext ? It must be transmitted from the client to the Pg Server, independent of using LDAP or Kerberos/GSSAPU.

No, Kerberos/GSSAPI *never* transmits the user's password to the server.
The user's password is actually used as an encryption key and is known
only to the KDC (your domain controllers) and the user. The KDC and the
PG server then share a different encryption key (the service principal).
When the user wants to connect to PG they ask the KDC for a ticket which
the KDC returns to the user as a blob which contains some information
for the PG server encrypted with the PG server's key and then encrypts
that and sends it to the user, who then decrypts it and uses it to
connect to the PG server.

How all of that works is a bit complicated but thankfully you don't
really need to worry about that- Windows and Active Directory handle
almost all of it. All you need to do is create a service principal in
active directory for the PG server and then export it and copy it over
to the PG server and then enable gssapi in PG.

Thanks!

Stephen