Re: More flexible LDAP auth search filters?

From: Mark Cave-Ayland <mark(dot)cave-ayland(at)ilande(dot)co(dot)uk>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: More flexible LDAP auth search filters?
Date: 2017-09-08 17:24:06
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 08/09/17 16:33, Peter Eisentraut wrote:

> A couple of comments on this patch. I have attached a "fixup" patch on
> top of your v4 that should address them.
> - I think the bracketing of the LDAP URL synopsis is wrong.
> - I have dropped the sentence that LDAP URL extensions are not
> supported. That sentence was written mainly to point out that filters
> are not supported, which they are now. There is nothing beyond filters
> and extensions left in LDAP URLs, AFAIK.
> - We have previously used the ldapsearchattribute a bit strangely. We
> use it as both the search filter and as the attribute to return from the
> search, but we don't actually care about the returned attribute (we only
> use the DN (which is not a real attribute)). That hasn't been a real
> problem, but now if you specify a filter, as the code stands it will
> always request the "uid" attribute, which won't work if there is no such
> attribute. I have found that there is an official way to request "no
> attribute", so I have fixed the code to do that.
> - I was wondering whether we need a way to escape the % (%%?) but it
> doesn't seem worth bothering.
> I have been looking around the Internet how this functionality compares
> to other LDAP authentication systems.
> I didn't see the origin of the %u idea in this thread, but perhaps it
> came from Dovecot. But there it's a general configuration file syntax,
> nothing specific to LDAP. In nginx you use %(username), which again is
> general configuration file syntax. I'm OK with using %u.
> The original LDAP URL design was adapted from Apache
> (
> They combine the attribute filter and the general filter if both are
> specified, but I think they got that a bit wrong. The attribute field
> in the URL is actually not supposed to be a filter but a return field,
> which is also the confusion mentioned above.
> The PAM module ( also has a way to
> specify a search attribute and a general filter and combines them.
> Neither of these allows substituting the user name into the search filter.

Great work! Having installed quite a few LDAP-based authentication
setups in the past, I can promise you that pam_ldap is the last tool I
would consider for the job so please don't hold to this as being the
gold standard(!).

My weapon of choice for LDAP deployments on POSIX-based systems is
Arthur De Jong's nss-pam-ldapd (
which is far more flexible than pam_ldap and fixes a large number of
bugs, including the tendency for pam_ldap to hang infinitely if it can't
contact its LDAP server.

Take a look at nss-pam-ldapd's man page for nslcd.conf and in particular
pam_authz_search - this is exactly the type of filters I would end up
deploying onto servers. This happens a lot in large organisations
whereby getting group memberships updated in the main directory can take
days/weeks whereas someone with root access to the server itself can
hard-code an authentication list of users and/or groups in an LDAP
filter in just a few minutes.



In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Catalin Iacob 2017-09-08 17:24:44 Re: [bug fix] Savepoint-related statements terminates connection
Previous Message Fabien COELHO 2017-09-08 17:17:56 Re: pgbench - allow to store select results into variables