'openstack user list' is not listing userid correctly in case of LDAP

[Deepak Ghuge]

The command 'openstack user list' is not listing proper user details when keystone is configured with LDAP.

The user_id_attribute is set to uid but user listing show hash like ids during user listing.

This behavior is seen in Pike release.

keystone.conf
[ldap]
user_id_attribute = uid
user_mail_attribute = mail
user_name_attribute = cn

The First column is ID, it should show the correct ID of user from LDAP based on 'user_id_attribute'
but here is showing hash like id.

[root@a2n1 ~]# openstack user list --domain EXT_USER_DOMAIN
+------------------------------------------------------------------+------------------------+
| ID | Name |
+------------------------------------------------------------------+------------------------+
| dfda96a70eec870fe0cc154778e4c527001984589d69a4d602666a756b5dd35f | userr |
| 98d8c9a1f148c15f42c954b3f54a2117dfe5a1db90b977af395dce3731ec6271 | userrw |
| ee70d65cd729d20655c4aa966490e9210dc99879e4e22205442957a4805558a2 | userr_1 |

In Mitaka or earlier release, value of ID was coming from LDAP and was correctly shown in ID column of 'openstack user list' output.

[Deepak Ghuge (deeghuge)]

The Functionality also seems to broken.
For example, if user has following configuration

[ldap]
user_id_attribute = uid
user_name_attribute = cn

and on LDAP if user has following details
uid=userrw
cn=rwuser

In Mitaka or previous release, all functionality used to work for both ID and Name. Like user was able to user userrw and rwuser for openstack command.

But in pike, openstack commands work only with name attribute. ie rwuser.
Operstack command fails if user try to use userrw in openstack commands. The logs shows user not found errors.

[Deepak Ghuge (deeghuge)]

Output from Mitaka release with same ldap server and same configuration
keystone.conf
[ldap]
user_id_attribute = uid
user_mail_attribute = mail
user_name_attribute = cn

[root@a1n2 ~]# openstack user list
+------------------------+------------------------+
| ID | Name |
+------------------------+------------------------+
| userr | userr |
| rwuser | userrw |
| userr_1 | userr_1 |

[Lance Bragstad (lbragstad)]

There was a major effort to rework how identities behave in keystone during the Mitaka and Newton development cycles. Part of that work was to "shadow" LDAP users [0], which kept references to those users in sql and allowed operators to assign roles and create group memberships using "shadow IDs". The advantage was that it allowed the operator of the OpenStack deployment to manage authorization for LDAP users without having access to LDAP (e.g. if they are managed by two separate teams or organizations).

That work might be what you're seeing here. I'd like to get a couple other developers to double check this though.

[0] http://specs.openstack.org/openstack/keystone-specs/specs/keystone/newton/shadow-users-newton.html

[Colleen Murphy (krinkle)]

Using the hash of the ID is intentional when keystone has a domain configured to use the LDAP backend. Otherwise there would be no way to guarantee uniqueness, since the ID comes from an external provider and since there could be multiple domains configured to use LDAP.