LDAP group_members_are_ids = false fails in Rocky/Stein

[Drew Freiberger]

I'm running into an interesting issue with the group_members_are_ids: false
Per the documentation, this means that the group's group_member_attribute values (in my case "member") are understood to be full LDAP DNs to the user records.

  https://docs.openstack.org/keystone/queens/_modules/keystone/identity/backends/ldap/core.html#Identity.list_users_in_group

Unfortunately, the call to self._transform_group_member_ids(group_members) is calling to self.user._dn_to_id(user_key) where user_key would be a string like "uid=dfreiberger,ou=users,dc=mysite,dc=com".

This code is here:
  https://docs.openstack.org/keystone/queens/_modules/keystone/identity/backends/ldap/core.html#Identity.list_users_in_group
This calls out to:
    return ldap.dn.str2dn(dn)[0][0][1]

https://github.com/openstack/keystone/blob/stable/rocky/keystone/identity/backends/ldap/common.py#L1298

from: https://www.python-ldap.org/en/latest/reference/ldap-dn.html#ldap.dn.str2dn, this should spit out something like:

    >>> ldap.dn.str2dn('cn=Michael Str\xc3\xb6der,dc=example,dc=com',flags=ldap.DN_FORMAT_LDAPV3)
    [[('cn', 'Michael Str\xc3\xb6der', 4)], [('dc', 'example', 1)], [('dc', 'com', 1)]]

Which would then mean the return from _dn_to_id(user_key) would be "Michael Str\xc3\xb6der" or "dfreiberger" in my example user_key above.

Ultimately, this means that either group_members_are_ids = false will return a user_id of the first attribute value within the DN string, even if the first field of the DN is not the actual user_name_attribute or user_id_attribute. If group_members_are_ids = true, it will return uidNumbers, which works fine with the knock on calls in the identity backend.

  - The problem is that the _transform_group_member_ids has to be
    returning a user ID such as the typical hex ID of a user in the
    keystone database, not the username of the user.
  - With group_members_are_ids, uidNumber is returned by the function,
    but with group_members_are_ids false, usernames are returned by the
    function.
  - Also, the _dn_to_id(user_key) from the group only returns the first entry in the DN, not the actual user_id_attribute or user_name_attribute field of the object. This requires a broken assumption that the user_id_attribute field called out in the ldap client config is also the first field of the distinguished name.

    - This would bug out if, say, your group had a member attribute/value pair of:

member="cn=Drew Freiberger,dc=mysite,dc=com", _dn_to_id would return "Drew Freiberger" as my user_id, however, I may have told ldap that the user_name_attribute is uid, and inside my ldap record of "dn=cn=Drew Freiberger,dc=mysite,dc=com", there's a uid=dfreiberger field showing my login name is dfreiberger which is what _dn_to_id should return, or perhaps _dn_to_id should return my uidNumber=12345 attribute to actually function as expected.

[Pen Gale (pengale)]

Reading through the code, and testing a few hacks on _dn_to_id, I can confirm that the method naively finds the value of the first element of the user key, without trying to figure out whether it's a uid or not.

@afreiberger one thing I'm not clear on -- in your case, is there a "uid" field in the key that you're passing in. Is it just a matter of finding and returning that uid? Or do you want to actually do a lookup for "Name.domain.tld" in a database, and return the uid of that entry?

[Hua Zhang (zhhuabj)]

@Drew, have you tried user_id_attribute=uid as well in addition to user_name_attribute=uid ?

[Drew Freiberger (afreiberger)]

We do not believe it is a good idea in this production cloud to change the user_id_attribute to = uid, as the user mapping table has already stored the uidNumbers as the user_id_attribute, and this would lead to database inconsistency unless we wiped the user table from the database.

user_id_attribute is supposed to be like the passwd database UID field, and user_name_attribute is supposed to be your login like "dfreiberger".

Please see documentation regarding posixAccount affinity for these variables on this page for configuration guide:
https://docs.openstack.org/keystone/pike/admin/identity-integrate-with-ldap.html

The intention of the keystone ldap integration documentation clearly states that it expects a full DN in the group_member_attribute if group_members_are_ids = false. This means that the code must dereference the dn uid=drew,ou=users,dc=mysite,dc=com and return the user_id_attribute field if the function needs to reference the user_id field.

[Drew Freiberger (afreiberger)]

@petevg, as for the field being passed in, it does contain a UID, however, UID == user_name for keystone. $user_id_attribute (uidNumber) is the field keystone should be looking for within the DN's record to equate to user_id in the code context.

[Drew Freiberger (afreiberger)]

It seems that most of our clouds use LDAP backends, which also use group_member_are_ids = false, but we do not specify a user_id_attribute.. This then falls back to the default of using the "CN" attribute.

It just so happens that Active directory entities are labeled with cn=$sAMAccountName,$user_tree_dn, and so the default code to assume user_id_attribute is the first field of the DN works in most production cases.

Suggest renaming title to "Specifying user_id_attribute that is not the distinguished name's primary key field in LDAP database fails when referencing group members if group_members_are_ids = false"

[Hua Zhang (zhhuabj)]

@Drew, However, we had a same case as this one in the past, and it was fixed by using user_id_attribute=uid finally. It looks like your name is in this test data 'uid=dfreiberger,ou=users,dc=mysite,dc=com', does it mean that you already have a test env? If yes, is it conventient for you to do a quick test for it? Or share your ldif test data similiar to [1] and your test steps, thus I can set up a test env exactly like yours then do this test. thanks.

[1] https://api.jujucharms.com/charmstore/v5/~openstack-charmers/ldap-test-fixture-3/archive/files/backup.ldif

[James Page (james-page)]

Agree with zhhuabj - please can we get a sanitised LDAP dump from the deployment so we can see how things are wired in the LDAP dataset.

[Corey Bryant (corey.bryant)]

Related bug: https://bugs.launchpad.net/keystone/+bug/1782922

[Corey Bryant (corey.bryant)]

I think we can probably mark this as a duplicate of bug 1782922 since that appears to be describing the same issue and is triaged already for upstream keystone.