** Changed in: cloud-archive
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:
Fix Released
Status in Ubuntu Cloud Archive queens series:
Fix Committed
Status in Ubuntu Cloud Archive rocky series:
Fix Released
Status in Ubuntu Cloud Archive stein series:
Fix Released
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:
Fix Committed
Status in keystone source package in Cosmic:
Won't Fix
Status in keystone source package in Disco:
Fix Released
Status in keystone source package in Eoan:
Fix Released
Bug description:
[Impact]
When using the keystone LDAP backend, changing user_id_attribute breaks group
mapping. This is because the _dn_to_id() method only calculated the uid to be
the first RDN of the DN. _dn_to_id() is updated in the fix to also deal with
the case where the uid is set to a different attribute.
[Test Case]
See details in comment #25:
https://bugs.launchpad.net/keystone/+bug/1782922/comments/25
[Regression Potential]
The patch takes a minimal approach to the fix and includes unit tests to help
ensure the patched code doesn't regress. The patches have landed in all
upstream releases back to stable/queens which helps get even more exposure with
upstream reviews, gate testing and real deployments.
[Original 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
--
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
