[Bug 1782922] Re: LDAP: changing user_id_attribute bricks group mapping
corey.bryant at canonical.com
Mon Dec 9 15:28:01 UTC 2019
@Felipe, by any chance can you re-test with the fix for LP: #1850634
which is in bionic-proposed?
You received this bug notification because you are a member of Ubuntu
OpenStack, which is subscribed to keystone in Ubuntu.
LDAP: changing user_id_attribute bricks group mapping
Status in Ubuntu Cloud Archive:
Status in Ubuntu Cloud Archive queens series:
Status in Ubuntu Cloud Archive rocky series:
Status in Ubuntu Cloud Archive stein series:
Status in Ubuntu Cloud Archive train series:
Status in OpenStack Identity (keystone):
Status in keystone package in Ubuntu:
Status in keystone source package in Bionic:
Status in keystone source package in Cosmic:
Status in keystone source package in Disco:
Status in keystone source package in Eoan:
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.
See details in comment #25: https://bugs.launchpad.net/keystone/+bug/1782922/comments/25
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.
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`  -> 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 . 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
To manage notifications about this bug go to:
More information about the Ubuntu-openstack-bugs