Re: [HACKERS] More flexible LDAP auth search filters?

On 17/07/17 13:09, Magnus Hagander wrote:

Hi Magnus,

Great to hear from you! It has definitely been a while...

>     Generally you find that you will be given the option to set the
>     attribute for the default search filter of the form
>     "(attribute=username)" which defaults to uid for UNIX-type systems and
>     sAMAccountName for AD. However there is always the ability to specify a
>     custom filter where the user is substituted via e.g. %u to cover all the
>     other use-cases.
>
> Right, but that's something we do already today. It just defaults to
> uid, but it's easy to change.

Yes, I think that bit is fine as long as the default can be overridden.
There's always a choice as to whether the defaults favour a POSIX-based
LDAP or AD environment but that happens with all installations so it's
not a big deal.

>     As an example, I don't know if anyone would actually do this with
>     PostgreSQL but I've been asked on multiple occasions to configure
>     software so that users should be allowed to log in with either their
>     email address or username which is easily done with a custom LDAP filter
>     like "(|(mail=%u)(uid=%u))".
>
>
> How would that actually work, though? Given the same user in ldap could
> now potentially match multiple different users in PostgreSQL. Would you
> then create two accounts for the user, one with the uid as name and one
> with email as name? Wouldn't that actually cause more issues than it solves?

Normally what happens for search+bind is that you execute the custom
filter with substitutions in order to find the entry for your bind DN,
but you also request the value of ldapsearchattribute (or equivalent) at
the same time. Say for example you had an entry like this:

dn: uid=mha,dc=users,dc=hagander,dc=net
uid: mha
mail: magnus@hagander.net

Using the filter "(|(mail=%u)(uid=%u))" would locate the same bind DN
"uid=mha,dc=users,dc=hagander,dc=net" with either one of your uid or
email address.

If the bind is successful then the current user identity should be set
to the value of the ldapsearchattribute retrieved from the bind DN
entry, which with the default of "uid" would be "mha". Hence you end up
with the same user role "mha" regardless of whether a uid or email
address was entered.

In terms of matching multiple users, all LDAP authentication routines
I've seen will fail if more than one DN matches the search filter, so
this nicely handles the cases where either the custom filter is
incorrect or more than one entry is accidentally matched in the directory.