Public bug reported: 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. ** Affects: keystone Importance: Undecided Status: New ** Tags: canonical-bootstack -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1832766 Title: LDAP group_members_are_ids = false fails in Rocky/Stein Status in OpenStack Identity (keystone): New Bug description: 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. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1832766/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
