The user_additional_attribute_mapping (self.extra_attr_mapping) is ignored in the attribute mapping code after a LDAP get operation. Except for the 'special' case where 'description' is mapped to 'description' due to the attribute_mapping..get(k, k) (see https://github.com/openstack/keystone/blob/master/keystone/common/ldap/core.py#L1359).
Since the user_additional_attribute_mapping seems to be only evaluated during LDAP create (https://github.com/openstack/keystone/blob/master/keystone/common/ldap/core.py#L1433) which has been deprecated, I think it does make sense that either a user_description_attribute config is supported or the user_additional_attribute_mapping is evaluated after LDAP get operations.
For our use-cases a user.description is definitely a need to have, since user name & email aren't necessarily very expressive.
No. Unfortunatily that doesn't work.
The user_additional _attribute_ mapping (self.extra_ attr_mapping) is ignored in the attribute mapping code after a LDAP get operation. Except for the 'special' case where 'description' is mapped to 'description' due to the attribute_ mapping. .get(k, k) (see https:/ /github. com/openstack/ keystone/ blob/master/ keystone/ common/ ldap/core. py#L1359).
Since the user_additional _attribute_ mapping seems to be only evaluated during LDAP create (https:/ /github. com/openstack/ keystone/ blob/master/ keystone/ common/ ldap/core. py#L1433) which has been deprecated, I think it does make sense that either a user_descriptio n_attribute config is supported or the user_additional _attribute_ mapping is evaluated after LDAP get operations.
For our use-cases a user.description is definitely a need to have, since user name & email aren't necessarily very expressive.
see also: https:/ /bugs.launchpad .net/keystone/ +bug/1336769