| 2013-03-21 02:15:54 |
Allan Feid |
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=shuttercorp,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. 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. |
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. |
|
