user crud in ldap backend breaks when changing user_name_attribute and user_id_attribute

[Allan Feid]

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.

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/25038
Committed: http://github.com/openstack/keystone/commit/f452c3d6b15123ca1b383f1d200f4cb406c81852
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
    user_name_attribute.

    Change-Id: Ie6cdd0534b8389f62f98fdca7d19bc0feb9c131f
    Fixes: bug #1158077