yahoo-eng-team team mailing list archive

[Corey Bryant <corey.bryant@xxxxxxxxxxxxx>]

For Ubuntu, a new package version including this fix has been uploaded to the following:
* eoan (and train cloud archive) - https://launchpad.net/ubuntu/+source/keystone
* disco unapproved queue - https://launchpad.net/ubuntu/disco/+queue?queue_state=1&queue_text=keystone
* rocky-staging (cosmic is EOL) - https://launchpad.net/~ubuntu-cloud-archive/+archive/ubuntu/rocky-staging/+packages?field.name_filter=keystone&field.status_filter=published&field.series_filter=
* bionic unapproved queue - https://launchpad.net/ubuntu/bionic/+queue?queue_state=1&queue_text=keystone

** Changed in: keystone (Ubuntu Eoan)
       Status: Triaged => Fix Released

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

Title:
  LDAP: changing user_id_attribute bricks group mapping

Status in Ubuntu Cloud Archive:
  Triaged
Status in Ubuntu Cloud Archive queens series:
  Triaged
Status in Ubuntu Cloud Archive rocky series:
  Triaged
Status in Ubuntu Cloud Archive stein series:
  Triaged
Status in Ubuntu Cloud Archive train series:
  Fix Released
Status in OpenStack Identity (keystone):
  Fix Released
Status in keystone package in Ubuntu:
  Fix Released
Status in keystone source package in Bionic:
  Triaged
Status in keystone source package in Cosmic:
  Won't Fix
Status in keystone source package in Disco:
  Triaged
Status in keystone source package in Eoan:
  Fix Released

Bug description:
  Env Details:
  Openstack version: Queens (17.0.5)
  OS: CentOS 7.5
  LDAP: Active Directory, Windows Server 2012R2

  We changed the user_id_attribute to sAMAccountName when configuring
  keystone. [ user_id_attribute = "sAMAccountName" ;
  group_members_are_ids = False ]. Unfortunately this bricks the group
  mapping logic in keystone.

  The relevant code in keystone:
  `list_users_in_group` [1] -> gets all groups from the LDAP server, and then calls `_transform_group_member_ids`. `_transform_group_member_ids` tries to match the user ids (for posixGroups e.g.) or the DN. However DN matching does not match the full DN. It rather takes the first RDN of the DN and computes the keystone user id [2]. The first RDN in Active Directory is the "CN". While the user-create part honors the user_id_attribute and takes "sAMAccountName" in our configuration. The generated user-ids in keystone now do not match anymore and hence group mapping is broken.

  A fix could be looking up the user by the DN received from the
  'member' attribute of a given group and compare the configured
  'user_id_attribute' of the received ldap user id and the in keystone
  stored user id. A quick fix could also be to mention that behavior in
  the documentation.

  /e: related
  https://bugs.launchpad.net/keystone/+bug/1231488/comments/19

  [1]
  https://github.com/openstack/keystone/blob/master/keystone/identity/backends/ldap/common.py#L1285

  [2]
  https://github.com/openstack/keystone/blob/master/keystone/identity/backends/ldap/core.py#L126

  [3]
  https://github.com/openstack/keystone/blob/master/keystone/identity/backends/ldap/common.py#L1296

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1782922/+subscriptions