LDAP should not check username on "sn" field
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Identity (keystone) |
Fix Released
|
Medium
|
Unassigned | ||
Essex |
Fix Released
|
Medium
|
Unassigned | ||
keystone (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Precise |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
The ldap backend is hardcoded to only check the entered username against the "sn" attribute type. In general, this is a misuse of the "sn" attribute, which refers to SurName, but the fact that this is hardcoded is more troublesome, as the username field may take on different attribute types in various LDAP implementations. Most widely used would be "cn", or CommonName, which generally maps to a username.
Most LDAP implementations allow the name of the field on which the query is done to be specified in a config file. Indeed, there are many options in the keystone config relating to LDAP fields, but this is not one of them.
See: https:/
The quick fix is to make this "cn" instead of "sn", the better fix would be to make this an option in the config.
I imaging this would make ldap auth fail for the majority of people - everyone who doesn't have their username the same as their lastname.
Related branches
- Ubuntu Server Developers: Pending requested
-
Diff: 13 lines (+6/-0)1 file modifieddebian/changelog (+6/-0)
Changed in keystone: | |
assignee: | nobody → Adam Young (ayoung) |
Changed in keystone: | |
status: | New → Triaged |
importance: | Undecided → Medium |
Changed in keystone: | |
assignee: | Adam Young (ayoung) → Anne Gentle (annegentle) |
Changed in keystone: | |
assignee: | Anne Gentle (annegentle) → nobody |
Changed in keystone: | |
milestone: | none → folsom-3 |
status: | Fix Committed → Fix Released |
Changed in keystone (Ubuntu): | |
status: | New → Fix Released |
Changed in keystone (Ubuntu Precise): | |
status: | New → Confirmed |
Changed in keystone: | |
milestone: | folsom-3 → 2012.2 |
So the trivial first fix is to change sn to cn for the name field in the identity LDAP backend.
The problem is that the cn is used as the user ID field already, and this cannot be the Name. I suspect that the right field to use would be the uid. But for inetOrgPerson, that is listed as MAY not MUST. That goes all the way up the hierarchy to 'Person' where the only two MUST fields are cn and sn.