LDAP Identity does not convert ID to DN for lookup

[Adam Young]

there is a disconnect between how Identity gets users for Authentication and how it creates users.

When creating a user, deleting a user, etc, the identity code calls:

            conn.add_s(self._id_to_dn(values['id']), attrs)

Which attempts to convert an id to a dn two different ways. One is by composing the DN:

    def _id_to_dn_string(self, object_id):
        return u'%s=%s,%s' % (self.id_attr,
                              ldap.dn.escape_dn_chars(
                                  six.text_type(object_id)),
                              self.tree_dn)

The other is by searching for a record of that objectclass

The difference is whether subtree searches are enabled.

The authenticate code path is different:

    def authenticate(self, user_id, password):
        try:
            user_ref = self._get_user(user_id)
...
    def _get_user(self, user_id):
        return self.user.get(user_id)

    def get(self, object_id, ldap_filter=None):
        res = self._ldap_get(object_id, ldap_filter)

    def _ldap_get(self, object_id, ldap_filter=None):
        conn = self.get_connection()
        query = (u'(&(%(id_attr)s=%(id)s)' ....

Note that this second way of finding the object matches the subtree search method.

I think this has worked thus far mostly due to convention: If a DN is of the form:

uid=ayoung,cn....

and the object has the attribute

uid=ayoung

Both searches will match the object. However, if the DN is like this:

CN=ayoung,CN=...

but the user has
CN=Adam

The second will not match.

[Dolph Mathews (dolph)]

Can you explain the actual impact on end users? How do you reproduce a misbehavior?

[Launchpad Janitor (janitor)]

[Expired for Keystone because there has been no activity for 60 days.]