yahoo-eng-team team mailing list archive

[Thierry Carrez <thierry.carrez+lp@xxxxxxxxx>]

** Changed in: keystone
       Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1340041

Title:
  OpenLDAP 2.3: naming attribute [...] is not present in entry; Naming
  violation

Status in OpenStack Identity (Keystone):
  Fix Released

Bug description:
  My keystone server is hosted on RHEL 6.4

  The keystone version from rpm -qa is openstack-
  keystone-2014.1-0.3.b2.el6.noarch

  I am working with LDAP backend and have defined following:
  - a user: authadmin (objectclass: Inetorgperson)
  - a tenant: authentication (objectclass: groupOfNames)
  - a role: admin (objectclass: organizationalRole)

  My keystone.conf snippet is:
  user_tree_dn = ou=Users,ou=OpenStack,dc=ldap,dc=com
  user_objectclass = inetOrgPerson
  user_id_attribute = uid
  user_name_attribute = uid

  tenant_tree_dn = ou=Customers,ou=OpenStack,dc=ldap,dc=com
  tenant_objectclass = groupOfNames
  tenant_id_attribute = cn
  tenant_name_attribute = cn

  role_tree_dn = ou=Roles,ou=OpenStack,dc=ldap,dc=com
  role_objectclass = organizationalRole
  role_id_attribute = cn
  role_name_attribute = cn

  While assigning 'admin' role to 'authadmin' user under tenant
  'authentication' I get the following error

  keystone user-role-add --user authadmin --role admin --tenant authentication
  An unexpected error prevented the server from fulfilling your request. {'info': "naming attribute 'cn' is not present in entry", 'desc': 'Naming violation'} (HTTP 500)

  Looking at the network traffic I could see that ldapadd request is for
  the dn: cn=admin,ou=authentication,ou=openstack,dc=ldap,dc=com

  with 2 attributes:
  objectclass: organizationalRole
  roleOccupant: uid=authadmin,ou=users,ou=openstack,dc=ldap,dc=com

  And since the 'cn' is missing which is the mandatory attribute for
  organizationalRole objectclass, I am observing this failure.

  If I use a new OpenLDAP server, say slapd 2.4.23, this works fine. The
  LDAP server automatically adds the 'cn' attribute which is mentioned
  in the 'dn'. Active Directory is also behaving in the similar way

  Now I am unable to conclude if this is an OpenLDAP bug or a keystone
  bug. Why is keystone not adding the 'cn' attribute in the ldapadd
  request ?

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1340041/+subscriptions