yahoo-eng-team team mailing list archive

[eraser <1340041@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

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 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=sonasldap,dc=com
user_objectclass = inetOrgPerson
user_id_attribute = uid
user_name_attribute = uid

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

role_tree_dn = ou=Roles,ou=OpenStack,dc=sonasldap,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 ?

** Affects: keystone
     Importance: Undecided
         Status: New

-- 
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:
  user-role-add not working with OpenLDAP - slapd 2.3.43

Status in OpenStack Identity (Keystone):
  New

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 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=sonasldap,dc=com
  user_objectclass = inetOrgPerson
  user_id_attribute = uid
  user_name_attribute = uid

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

  role_tree_dn = ou=Roles,ou=OpenStack,dc=sonasldap,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