user crud in ldap backend breaks when changing user_name_attribute and user_id_attribute

Bug #1158077 reported by Allan Feid on 2013-03-21
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Identity (keystone)
Allan Feid

Bug Description

When changing both user_id_attribute and user_name_attribute, the ldap schema for a new user becomes incorrect, at least when using the inetOrgPerson objectClass. An example being, if you take the following existing user schema:

dn: uid=afeid,ou=People,dc=example,dc=net
objectClass: posixAccount
objectClass: inetOrgPerson
cn: Allan Feid
sn: Feid
uid: afeid
gecos: Allan Feid
gidNumber: 10000
uidNumber: 10031
homeDirectory: /home/afeid
loginShell: /bin/bash

The user_id_attribute makes sense to be mapped to uid and user_name_attribute to be mapped to cn. The problem here is that inetOrgPerson requires the sn attribute in addition to uid and cn. A simple proposal is to add a new configuration option such as:

user_additional_attribute_mappings = sn:name, description:email

Where the format is <ldap_attribute>:<attribute_mapping_key> (from BaseLdap.attribute_mapping). These additional attributes would then be passed along when performing the related crud operations.

Allan Feid (crayz) on 2013-03-21
description: updated
Dolph Mathews (dolph) on 2013-03-21
Changed in keystone:
importance: Undecided → Medium
status: New → Triaged

Fix proposed to branch: master

Changed in keystone:
assignee: nobody → Allan Feid (crayz)
status: Triaged → In Progress

Submitter: Jenkins
Branch: master

commit f452c3d6b15123ca1b383f1d200f4cb406c81852
Author: Allan Feid <email address hidden>
Date: Thu Mar 21 14:19:48 2013 -0400

    Allow additional attribute mappings in ldap

    This is needed as a work around for objectclasses that require additional
    attributes other than just what is supplied in user_id_attribute and

    Change-Id: Ie6cdd0534b8389f62f98fdca7d19bc0feb9c131f
    Fixes: bug #1158077

Changed in keystone:
status: In Progress → Fix Committed
Thierry Carrez (ttx) on 2013-05-29
Changed in keystone:
milestone: none → havana-1
status: Fix Committed → Fix Released
Thierry Carrez (ttx) on 2013-10-17
Changed in keystone:
milestone: havana-1 → 2013.2
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers