Public bug reported: The bug seems similar in appearance to #1285065, but the cause seems different than the one described there. What I'm having configured:
group_objectclass=groupOfNames group_id_attribute=cn group_name_attribute=ou group_member_attribute=member group_desc_attribute=description What I'm expecting (after adding appropriate entries to the directory, of course): # keystone user-role-list --tenant-id testProject --user-id myuser WARNING: Bypassing authentication using a token & endpoint (authentication credentials are being ignored). +----------------------------------+-------+--------------+-------------+ | id | name | user_id | tenant_id | +----------------------------------+-------+--------------+-------------+ | 780bd000a6d84f329c3ba361f0dfa4a4 | admin | myuser | testProject | +----------------------------------+-------+--------------+-------------+ What I'm getting: # keystone user-role-list --tenant-id testProject --user-id myuser WARNING: Bypassing authentication using a token & endpoint (authentication credentials are being ignored). [nothing here] Adding LOG.debug() in various parts of the source code led me to the conclusion that someone had made some strange assumption about group object DN and while comparing it in assignment/backends/ldap.py thrown in some strange "case unification" in form of a upper() call without caring to think how the other side of the check looks. The function get_group_project_roles() makes role_list based on comparison between group_dns list and groups which are used in role assignment. I assume that someone made this comparison based on his LDAP directory structure in which some entries/attributes were named all- uppercase, but in real life DN's can be any case (cn=user,ou=users,dc=example and cn=UsEr,ou=Users,dc=example are the same object). So the right solution here, I believe will be to make sure that the list in which we will later be looking for upper-cased group DN is itself upper-cased. In other words in get_group_project_roles() method we should change group_dns = [self.group._id_to_dn(group_id) for group_id in groups] to group_dns = [self.group._id_to_dn(group_id).upper() for group_id in groups] ** 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/1417774 Title: LDAP groups role assignment not reported Status in OpenStack Identity (Keystone): New Bug description: The bug seems similar in appearance to #1285065, but the cause seems different than the one described there. What I'm having configured: group_objectclass=groupOfNames group_id_attribute=cn group_name_attribute=ou group_member_attribute=member group_desc_attribute=description What I'm expecting (after adding appropriate entries to the directory, of course): # keystone user-role-list --tenant-id testProject --user-id myuser WARNING: Bypassing authentication using a token & endpoint (authentication credentials are being ignored). +----------------------------------+-------+--------------+-------------+ | id | name | user_id | tenant_id | +----------------------------------+-------+--------------+-------------+ | 780bd000a6d84f329c3ba361f0dfa4a4 | admin | myuser | testProject | +----------------------------------+-------+--------------+-------------+ What I'm getting: # keystone user-role-list --tenant-id testProject --user-id myuser WARNING: Bypassing authentication using a token & endpoint (authentication credentials are being ignored). [nothing here] Adding LOG.debug() in various parts of the source code led me to the conclusion that someone had made some strange assumption about group object DN and while comparing it in assignment/backends/ldap.py thrown in some strange "case unification" in form of a upper() call without caring to think how the other side of the check looks. The function get_group_project_roles() makes role_list based on comparison between group_dns list and groups which are used in role assignment. I assume that someone made this comparison based on his LDAP directory structure in which some entries/attributes were named all-uppercase, but in real life DN's can be any case (cn=user,ou=users,dc=example and cn=UsEr,ou=Users,dc=example are the same object). So the right solution here, I believe will be to make sure that the list in which we will later be looking for upper-cased group DN is itself upper-cased. In other words in get_group_project_roles() method we should change group_dns = [self.group._id_to_dn(group_id) for group_id in groups] to group_dns = [self.group._id_to_dn(group_id).upper() for group_id in groups] To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1417774/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp