ldap config "user_id_attribute" is ignored

[Beraldo]

I can sucessfully configure keystone LDAP settings and keystone user-list works fine. Shows to me id, name, enabled and email correctly. But when I do a "keystone user-get foo" the message shows:

No user with a name or ID of 'foo' exists.

The configuration file for user and ldap options are:

----
[ldap]
url = ldap://ldap.my.company.com
suffix = dc=my,dc=company,dc=com
objectClass = posixAccount
user_tree_dn = ou=people,dc=my,dc=company,dc=com
user_objectclass = posixAccount
user_unit = "People"
user_id_attribute = uid
user_name_attribute = cn
user_mail_attribute = mail
user_pass_attribute = userPassword
user_enabled_attribute = uidNumber
user_enabled_mask = 255
user_enabled_default = True
user_attribute_ignore = tenantId,tenants
user_allow_create = False
user_allow_update = False
user_allow_delete = False
----

I dont use Active Directory, so cn (the default user_id_attribute) is the full user name and not a login. In my base login is uid.

If I do a keystone user-get "Full Name of Foo" works fine. But sorry if is a mistake of me, but IMHO, should works with user_id_attribute configured in config file.

[Dolph Mathews (dolph)]

I suspect this is an issue with keystoneclient attempting to incorrectly "guess" whether you're providing ID or name.

[Dolph Mathews (dolph)]

(if so, this issue has been discussed before but I'm not sure if there's an open bug against this explicitly)

[Endre Karlson (endre-karlson)]

Basically the issue is that the user_id_attribute setting / option is not getting honored for anything.

After talking to Adam this piece https://github.com/openstack/keystone/blob/master/keystone/common/ldap/core.py#L261-L263 needs some change in order for this to work correctly. Currently this being broken breaks all standard AD use-cases where 'sAMAccountName' is the attribute for the login name instead of 'cn' as in a unux / linux ldap.

[Dolph Mathews (dolph)]

Is this issue present in grizzly?

[Endre Karlson (endre-karlson)]

I checked Grizzly stable from github, below is my config:
137 [ldap]
138 url = ldap://10.0.0.6
139 user = CN=s_keystone,CN=Users,DC=lab,DC=local
140 password = Superrand0m
141 suffix = DC=lab,DC=local
142 use_dumb_member = True
143 allow_subtree_delete = False
144 dumb_member = CN=s_keystone,CN=Users,DC=lab,DC=local
145
146 query_scope = sub
147
148 user_tree_dn = CN=Users,dc=lab,dc=local
149 #user_name_attribute = cn
150 user_mail_attribute = mail
151 user_enabled_attribute = userAccountControl
152 ##user_domain_id_attribute = businessCategory
153 user_enabled_mask = 2
154 user_enabled_default = 512
155 user_attribute_ignore = password
156 user_allow_create = False
157 user_allow_update = False
158 user_allow_delete = False
159 ## user_filter =
160 user_objectclass = organizationalPerson
161 ## user_domain_id_attribute = businessCategory
162 user_id_attribute = sAMAccountName
163 user_name_attribute = cn

I still get the same output when doing user-list and alike as I do with Havana.

The _dn_to_id is still the culprit I guess that ayoung mentioned:
https://github.com/openstack/keystone/blob/stable/grizzly/keystone/common/ldap/core.py#L196-L198

[Beraldo (beraldo-7)]

Yes, the bug was perceived in Grizzly (1:2013.1.3-0ubuntu1).

[Dolph Mathews (dolph)]

Adam, was there ever any progress on this? This looks like it was a client side issue to me (in the id vs name guesswork).

[Adam Young (ayoung)]

It wasn't a client issue; I marked it confrimed in server. It has to do with how IDs are done in LDAP, as a segment of a DistinguishedName (DN) . I wanted to complete "remember the DN" before addressing any other DN to ID issues, as I think they are related.

[Xiang Hui (xianghui)]

Hi，

  Would someone provide the result of above scerio with this command (ldapsearch -x -b "dc=openstack,dc=org" '(objectclass=*)'), changing the dc with your appropriate domain value.

  I doubt it is related with the data stored in ldap.

Thanks.

[Beraldo (beraldo-7)]

This is a partial output:

# extended LDIF
#
# LDAPv3
# base <dc=ncc,dc=unesp,dc=br> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# ncc.unesp.br
dn: dc=ncc,dc=unesp,dc=br
objectClass: top
objectClass: dcObject
objectClass: organization
o: ncc.unesp.br
dc: ncc

# people, ncc.unesp.br
dn: ou=people,dc=ncc,dc=unesp,dc=br
objectClass: organizationalUnit
ou: people

# groups, ncc.unesp.br
dn: ou=groups,dc=ncc,dc=unesp,dc=br
objectClass: organizationalUnit
ou: groups

# guest, groups, ncc.unesp.br
dn: cn=guest,ou=groups,dc=ncc,dc=unesp,dc=br
cn: guest
objectClass: posixGroup
objectClass: top
description: Guest group account
gidNumber: 10033
memberUid: jonh

# jonh, people, ncc.unesp.br
dn: uid=jonh,ou=people,dc=ncc,dc=unesp,dc=br
givenName: Jonh
sn: Doe
uid: jonh
homeDirectory: /home/jonh
uidNumber: 10004
loginShell: /bin/bash
cn: Jonh Doe
mail: <email address hidden>
gidNumber: 10005
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: top

[nethawk (13951798214-f)]

I tried this command,but there is no problem about it and I could get correct result.
The objectclass I used for users in ldap is inetOrgPerson.

[Beraldo (beraldo-7)]

So, if you change the user_id_attribute attribute to anything else can you see the difference in keystone user-list output ? For me nothing is changed.

[Beraldo (beraldo-7)]

Ok, now I can get the user detail with user-get command, but the id attribute is not changed even in user-list and user-get command. Just for tests purposes i changed the id_attribute to email but in user-list and user-get the id column is showing the uid.

[Beraldo (beraldo-7)]

I'm trying to understand some points here....

With this config:

user_tree_dn=ou=people,dc=ncc,dc=unesp,dc=br
user_filter="(!(gidNumber=9999))"
user_objectclass=inetOrgPerson
user_id_attribute=uidNumber
user_name_attribute=uid
user_mail_attribute=mail

And theses variables:

export OS_USERNAME=foo
export OS_PASSWORD="mypass"
export OS_TENANT_NAME=admin_group
export OS_AUTH_URL=http://controller:35357/v2.0

And after foo user use the command keystone user-list, an error on authentication happens and the logs shows two queries:

2014-03-21 10:25:57.838 16623 DEBUG keystone.common.ldap.core [-] LDAP search: dn=ou=people,dc=ncc,dc=unesp,dc=br, scope=2, query=(&(uid=foo)(objectClass=inetOrgPerson)), attrs=['userPassword', 'enabled', 'uid', 'mail']

and after few logs:

2014-03-21 10:25:57.845 16623 DEBUG keystone.common.ldap.core [-] LDAP search: dn=ou=people,dc=ncc,dc=unesp,dc=br, scope=2, query=(&(uidNumber=foo)(!(gidNumber=9999))(objectClass=inetOrgPerson)), attrs=['mail', 'userPassword', 'enabled', 'uid'] search_s /usr/lib/python2.7/dist-packages/keystone/common/ldap/core.py:586

1. Why the first query has no filter ?
2. Why two queries ? (Note the first query returns correctly the user)

[Beraldo (beraldo-7)]

Reading more logs, more doubts and strange behavior:

To check if a user belongs to a tenant the code search for group (Using group_tree_dn and others group_ variables). In documentation there is no mention to groups when setting a ldap setup. What groups means ?

For tests I setup groups like tenants in keystone.conf.

This code is compatible with RFC2307 ? (Groups list only uids and not the full dn of members). I notice that when trying to query a user in groups, the code search for a full dn. The documentation tells that is RFC2307-compliant posixAccount, but on search is doing like this:

2014-03-21 10:56:35.069 20605 DEBUG keystone.common.ldap.core [-] LDAP search: dn=ou=groups,dc=ncc,dc=unesp,dc=br, scope=2, query=(&(&(objectClass=posixGroup)(memberUid=uid=foo,ou=people,dc=ncc,dc=unesp,dc=br))(objectClass=posixGroup)), attrs=['description', 'ou'] search_s /usr/lib/python2.7/dist-packages/keystone/common/ldap/core.py:586

Where we configure to search for uid instead of the dn ?

The variables group_member_attribute and tenant_member_attribute are already to "memberUid".

Thanks for your help, and sorry to bother your.

[Xiang Hui (xianghui)]

Hi beraido-7,

I can get the correct result with below configuration and commands:
/etc/keystone/keystone.conf
user_id_attribute = cn
user_name_attribute = sn
user_objectclass = inetOrgPerson
xianghui@xianghui:~/workplace/devstack$ keystone user-list
+----------------------------------+-------+---------+-------+
| id | name | enabled | email |
+----------------------------------+-------+---------+-------+
| e6e59b06feb74071b4a1aa51588d7949 | admin | | |
+----------------------------------+-------+---------+-------+
xianghui@xianghui:~/workplace/devstack$ keystone user-get admin
+----------+----------------------------------+
| Property | Value |
+----------+----------------------------------+
| id | e6e59b06feb74071b4a1aa51588d7949 |
| name | admin |
+----------+----------------------------------+

But if changed the configurations as yours, I can get the error:
user_id_attribute = uidNumber
user_name_attribute = uid
xianghui@xianghui:~/workplace/devstack$ keystone user-list
+----------------------------------+------+---------+-------+
| id | name | enabled | email |
+----------------------------------+------+---------+-------+
| e6e59b06feb74071b4a1aa51588d7949 | | | |
+----------------------------------+------+---------+-------+
xianghui@xianghui:~/workplace/devstack$ keystone user-get admin
No user with a name or ID of 'admin' exists.

It is not reasonable to set user_name_attribute = uid, since from the user-list, name is can't be retrieved from ldap.

My ldap data:
xianghui@xianghui:~/workplace/devstack$ ldapsearch -x -b "ou=Users,dc=openstack,dc=org" '(objectclass=*)'
# extended LDIF
#
# LDAPv3
# base <ou=Users,dc=openstack,dc=org> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# Users, openstack.org
dn: ou=Users,dc=openstack,dc=org
objectClass: organizationalUnit
ou: Users

# e6e59b06feb74071b4a1aa51588d7949, Users, openstack.org
dn: cn=e6e59b06feb74071b4a1aa51588d7949,ou=Users,dc=openstack,dc=org
objectClass: person
objectClass: inetOrgPerson
sn: admin
cn: e6e59b06feb74071b4a1aa51588d7949

...

The user admin is stored in the sn attribute.

[Matt Fischer (mfisch)]

Can someone explain why this is incomplete? When you auth against AD the results are pretty annoying. I can only make it work when user_id_attribute and user_name_attribute both are set to "cn", but what I'd really like is for people to login with their cn (which is like an employee number) and have displayName shown for the name attribute.

[Dolph Mathews (dolph)]

Matt: I'm wondering if everything here is (mostly?) behaving as intended, but those intentions don't quite match everyone's expectations. It's a lot to read through, but the only misbehavior I can see is that "user list" is not reporting the ID correctly, although it seems that auth is generally unaffected.

In your specific use case, we don't support a "display name" that's distinct from "name", although you could perhaps use the "description" attribute of users. It sounds like you want user_id_attribute = cn and user_name_attribute = displayName. Users can authenticate with either, depending on the interface to keystone (not sure if Horizon supports anything beyond user_name, but it could).

[Eric N. Vander Weele (ericvw)]

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).

[Dolph Mathews (dolph)]

Eric: Wow, fantastic analysis - thank you! I agree with your path forward, although I'd be happy with (1) as an easy first step until someone has time/interest to pursue (2), as the additional flexibility would provide a better long term solution.

[Eric N. Vander Weele (ericvw)]

I am more than happy to tackle (1) with some guidance and as I start becoming more comfortable with the code to attempt a solution for (2).

[Dolph Mathews (dolph)]

Eric: contact us in #openstack-keystone on IRC! In short, you'd probably be starting here:

  https://github.com/openstack/keystone/blob/master/keystone/common/config.py#L459-L460

[Dolph Mathews (dolph)]

(permalink of the above) https://github.com/openstack/keystone/blob/e954942d44265c8bf5caf16a83eb6a2328a7278b/keystone/common/config.py#L459-L460

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/93480

[OpenStack Infra (hudson-openstack)]

Change abandoned by Morgan Fainberg (<email address hidden>) on branch: master
Review: https://review.openstack.org/93480
Reason: This change is being abandoned because it has a negative score and has not seen an update in > 60 days. Feel free to re-instate this patch (as the author) by using the "restore" button or any member of the core team can re-instate the patch.

[Tom Fifield (fifieldt)]

This bug appears to be a duplicate of https://bugs.launchpad.net/keystone/+bug/1361306 which was fixed in Juno