|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?|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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 (https://linux.die.net/man/5/pam_ldap) 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
My weapon of choice for LDAP deployments on POSIX-based systems is
Arthur De Jong's nss-pam-ldapd (https://arthurdejong.org/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.
|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|