[Bug 1832766] Re: LDAP group_members_are_ids = false fails in Rocky/Stein
Pete Vander Giessen
1832766 at bugs.launchpad.net
Fri Jun 14 22:15:47 UTC 2019
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?
** Changed in: keystone (Ubuntu)
Assignee: James Page (james-page) => Pete Vander Giessen (petevg)
--
You received this bug notification because you are a member of Ubuntu
OpenStack, which is subscribed to keystone in Ubuntu.
https://bugs.launchpad.net/bugs/1832766
Title:
LDAP group_members_are_ids = false fails in Rocky/Stein
Status in OpenStack Identity (keystone):
New
Status in keystone package in Ubuntu:
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
More information about the Ubuntu-openstack-bugs
mailing list