On 04/20/2016 09:10 PM, Dmitry Sutyagin wrote:
Another correction - the issue is observed in Kilo, not Liberty, sorry
for messing this up. (though this part of the code is identical in L)
On Wed, Apr 20, 2016 at 5:50 PM, Dmitry Sutyagin
<dsutya...@mirantis.com <mailto:dsutya...@mirantis.com>> wrote:
Correction:
group_dns = [u'CN=GroupX,OU=Groups,OU=SomeOU,DC=zzz']
ra.user_dn.upper() = 'CN=GROUPX,OU=GROUPS,OU=SOMEOU,DC=ZZZ'
So this could work if only:
- string in group_dns was str, not unicode
- text was uppercase
Now the question is - should it be so?
On Wed, Apr 20, 2016 at 5:41 PM, Dmitry Sutyagin
<dsutya...@mirantis.com <mailto:dsutya...@mirantis.com>> wrote:
Hi everybody,
I am observing the following issue:
LDAP backend is enabled for identity and assignment, domain
specific configs disabled.
LDAP section configured - users, groups, projects and roles
are mapped.
I am able to use identity v3 api to list users, groups, to
verify that a user is in a group, and also to view role
assignments - everythings looks correct so far.
I am able to create a role for user in LDAP and if I put a
user directly into a role, everything works.
But when I put a group (which contains that user) into a role
- the user get's 401.
I have found a spot in the code which causes the issue:
https://github.com/openstack/keystone/blob/stable/liberty/keystone/assignment/backends/ldap.py#L67
This check returns False, here is why:
===============================================
group_dns = ['cn=GroupX,ou=Groups,ou=YYY,dc=...']
role_assignment.user_dn = 'cn=UserX,ou=Users,ou=YYY,dc=...'
===============================================
Therefore the check:
====================================
if role_assignment.user_dn.upper() in group_dns
====================================
Will return false. I do not understand how this should work -
why should user_dn match group_dn?
I would not advise using the LDAP assignment backend, but rather use
LDAP for identity, and put assignments in SQL. LDAP assignments was
deprecated a few releases ago and has since been removed.
--
Yours sincerely,
Dmitry Sutyagin
OpenStack Escalations Engineer
Mirantis, Inc.
--
Yours sincerely,
Dmitry Sutyagin
OpenStack Escalations Engineer
Mirantis, Inc.
--
Yours sincerely,
Dmitry Sutyagin
OpenStack Escalations Engineer
Mirantis, Inc.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
