Re: BUG #16079: Question Regarding the BUG #16064

Greetings,

* PG Bug reporting form (noreply(at)postgresql(dot)org) wrote:
> As your team mentioned that LDAP process is not secured compared to the
> GSSAPI authentication.

No, it isn't.

> Can you clarify me this question, whenever the client provide his
> credentials to connect to the PostgreSQL server it will authenticated
> against the LDAP Server and then LDAP will direct the client connecttion to
> the Postgrers server. But the user credentials will not be sent to
> Postgresql server to authenticate.

Uh, the user's credentials certainly are sent to the PG server.

Here's a nice short patch that just prints out the user's password after
the server gets it when using LDAP auth. You'll see the results like
this in the log:

users password is: hello

> Because your team mentioned this statement " it's much more secure than
> using LDAP-based auth and avoids the user's password being
> sent to the PostgreSQL server (where it could be compromised if the
> PGprocess is compromised)."

Yes, that's correct, if the PG server is compromised then the user's
credentials, when using LDAP auth, can be captured.

> I am having user defined in the LDAP server with all the credentails and
> also same user in the postgres server.

I'm not sure what you're suggesting here, but the way LDAP auth in PG
works is that the user's password is sent to the PG server and then the
PG server turns around and tries to use it to authenticate to the LDAP
server and, if successful, the authentication is allowed, and if
unsuccessful, the authentication is denied. When using LDAP auth, we
don't look at the rolpassword column in pg_authid at all.

I do think it'd be a useful improvement to add a way to control who is
allowed to access a PG server (aka- authorization), perhaps through an
LDAP query to check it, while using Kerberos/GSSAPI authentication to
actually do the authentication, but there isn't a way to do that with PG
today.

Thanks,

Stephen