Comment 5 for bug 997700

Quite right. I wasn't trying to suggest it was a problem per se, just
that it's flexibility often makes proper configuration more
complicated. In this case, just one more parameter.

On Thu, May 10, 2012 at 3:11 PM, Tim Spriggs <email address hidden> wrote:
> Doug: uid is mandatory for the posixAccount objectClass. It's not a
> problem with LDAP, it just makes it slightly more complex to support in
> software.
>
> If someone wants to use the same ldap auth source that their unix system
> uses then you will likely see posixAccount (or even subclasses of
> posixAccount) which guarantees everything that a unix account needs.
>
> Another potential glitch is groupOfUniqueNames vs posixGroup. While the
> former contains a list of verified DNs (uniqueMember), the latter is a
> list of usernames (memberUID). There is nothing stopping someone from
> having an object with both classes. Maintaing both sets of classes is
> another story...
>
> Many pieces of software will adopt their own schema when their settings
> don't map 1:1 and simply enforce usage of their own schema to make their
> own lives easier. The expense is that ldap administrators lives get
> slightly harder as they then need to support the different schema. In no
> way am I recommending this, just mentioning it.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/997700
>
> Title:
>  LDAP should not check username on "sn" field
>
> Status in OpenStack Identity (Keystone):
>  New
>
> Bug description:
>  The ldap backend is hardcoded to only check the entered username
>  against the "sn" attribute type. In general, this is a misuse of the
>  "sn" attribute, which refers to SurName, but the fact that this is
>  hardcoded is more troublesome, as the username field may take on
>  different attribute types in various LDAP implementations. Most widely
>  used would be "cn", or CommonName, which generally maps to a username.
>
>  Most LDAP implementations allow the name of the field on which the
>  query is done to be specified in a config file. Indeed, there are many
>  options in the keystone config relating to LDAP fields, but this is
>  not one of them.
>
>  See:
>  https://github.com/openstack/keystone/blob/master/keystone/identity/backends/ldap/core.py#L251
>
>  The quick fix is to make this "cn" instead of "sn", the better fix
>  would be to make this an option in the config.
>
>  I imaging this would make ldap auth fail for the majority of people -
>  everyone who doesn't have their username the same as their lastname.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/keystone/+bug/997700/+subscriptions