Re: [openstack-dev] [keystone] Liberty - problem with assignment LDAP backend - Groups

2016-04-20 Thread Adam Young 

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 
> 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
> 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

Re: [openstack-dev] [keystone] Liberty - problem with assignment LDAP backend - Groups

2016-04-20 Thread Dmitry Sutyagin 
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 
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 
> 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?
>>
>> --
>> 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

Re: [openstack-dev] [keystone] Liberty - problem with assignment LDAP backend - Groups

2016-04-20 Thread Dmitry Sutyagin 
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 
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?
>
> --
> 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-dev] [keystone] Liberty - problem with assignment LDAP backend - Groups

2016-04-20 Thread Dmitry Sutyagin 
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?

-- 
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