* Michael O'Donnell (odonnellm(at)usgs(dot)gov) wrote:
> I am trying to authenticate PostgreSQL 9.0 login roles against LDAP/Active
> directory (AD). PostgreSQL 9.0 is installed on a Windows 2008 R2 64bit. My
> pg_hba.conf setting looks like the following:
My first reaction to this, to be honest, is to ask why you're using
LDAP-based authentication instead of SSPI/Kerberos-based authentication?
Kerberos is supported and is a much better protocol that would, among
other things, prevent the server from ever seeing an individual user's
> When I use the following psql command I get an error:
> C:\Windows\System32>psql -d <db> -U <user> -W
> Password for user <user>:
> psql: FATAL: password authentication failed for user "<user>"
Since it works with a different user, I wonder if there's some issue
just passing the username on the command-line; are you sure that the
user shown in the error from psql matches what you're passing in? Have
you checked the PostgreSQL server logs? Do you have anything in
> I have added the <user> to the login role and the user exists in AD.
Not quite sure what you mean, exactly, by having the user added to the
'login' role, but you definitely want to make sure that the 'LOGIN'
attribute is set for the role; eg: ALTER ROLE user WITH LOGIN;
> If I use pyscopg2 (a python module that is commonly used for PostgreSQL
> interaction), I can actually connect to the database using the settings
> specified in the pg_hba.conf file shown above. If I use a false username,
> the script fails. Therefore the script is behaving as I would expect, but
> I am confussed why psql is behaving differently.
This definitely makes me wonder if there's something weird with the user
being passed on the command-line that's causing the issue.
> 3. Is the transfer of the password automatically encrypted? I read in a
> blog that using LDAP does not encrypt and I need to use SSL. I tried using
> ldaptls=1 but this was causing a failure in postgres reading the conf.
More specifics about this would help- the exact pg_hba.conf line, the
exact error from the server logs, etc. Of course, just moving to
Kerberos-based authentication would simplify this whole thing and remove
all the LDAP fun..
In response to
pgsql-admin by date
|Next:||From: Craig Ringer||Date: 2012-08-08 02:38:52|
|Subject: Re: Data corruption after SAN snapshot|
|Previous:||From: Michael O'Donnell||Date: 2012-08-08 02:07:25|
|Subject: PostgreSQL 9.0 authentication against LDAP/AD|