yahoo-eng-team team mailing list archive

[James Page <james.page@xxxxxxxxxx>]

** Also affects: keystone (Ubuntu)
   Importance: Undecided
       Status: New

** Changed in: keystone (Ubuntu)
     Assignee: (unassigned) => James Page (james-page)

-- 
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
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