Using Microsoft AD's objectGUID attribute as user_id_attribute breaks
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Identity (keystone) |
Fix Released
|
Low
|
Lance Bragstad |
Bug Description
Microsoft AD has a default attribute in its schema for users and groups called objectGUID [0]. The attribute is assigned when new users and groups are created.
If we attempt to use this attribute as a user's ID by setting user_id_
I was able to recreate this with using a 2016 AD server with the following keystone LDAP configuration file:
[root@overcloud
[ldap]
url=ldap:
user=CN=
password=p@ssw0rd1
suffix=
user_tree_
user_objectclas
user_id_
query_scope=sub
user_name_
[identity]
driver=ldap
[stack@undercloud ~]$ openstack --os-cloud overcloud user list --domain windows
ID attribute objectGUID not found in LDAP object CN=Administrato
The root of the issue is that keystone isn't properly decoding the value, which you can see from the logs as the ldap backend processes results from AD.
/var/log/
Relevant code:
https:/
https:/
https:/
https:/
https:/
https:/
We might need to consider handling this value similar what the python-ldap community suggests:
https:/
[0] https:/
description: | updated |
Changed in keystone: | |
importance: | Undecided → Low |
The workaround for this issue is to not use objectGUID as the user or group ID. However, that workaround might not be applicable in all situations. For example, the default value for user_id_attribute is 'cn', but if that value spans more than 64 characters, keystone can't work with it.
(overcloud) [heat-admin@ overcloud- controller- 0 ~]$ openstack user list --domain tripleo 22ac75a440800d1 d179d0f3d153b3d 466b96c7ac50301 512539a4367314f 0d49c3ad33e85c6 e1cafe1 5e2bd347ac6e4e2 2ac75a440800d1d ' exceeds the limit of column local_id(CHAR(64)). (HTTP 400) (Request-ID: req-6e5082d5- b768-4376- 8990-f3004eae46 17)
String length exceeded. The length of string '5e2bd347ac6e4e