Comment 19 for bug 1231488

I ran into this "issue" as well. However, I agree with Dolph in that it is behaving as intended (while not well documented :D ).

After looking through LDAP back-end for Keystone, I found that there is a close relationship between the 'user_id_attribute' and the distinguished name. The LDAP back-end assumes the 'user_id_attribute' is the leftmost RDN (relative distinguished name) of the entry's DN (https://github.com/openstack/keystone/blob/2ec9817b3a4d44829fa3a11640d3bd2afa5576b2/keystone/common/ldap/core.py#L780).

Also, whatever the left most RDN of the DN is, that ends up being the Keystone ID (https://github.com/openstack/keystone/blob/2ec9817b3a4d44829fa3a11640d3bd2afa5576b2/keystone/common/ldap/core.py#L806).

Therefore, it appears (at this time) that the 'user_id_attribute' must be the left-most RDN of the distinguished names for user entries. Unfortunately, AD has the convention of using an entries CN (common name) as part of an entries DN. This is also relevant that helped me to better understand what was going on(https://ask.openstack.org/en/question/3837/keystone-ldap-integration-with-active-directory/).

It is confusing to understand this 'user_id_attribute' and DN relationship unless you dive into the code. I can see two paths forward:
1) Better document how 'user_id_attribute' should be used when using LDAP with Keystone.
2) Make changes to the LDAP back-end to support using the 'user_id_attribute' independently of the DN (which will probably require an additional cross-reference query to find the desired DN to use).