Bug 1301425

Summary:	OpenShift v3's LDAP authentication doesn't handle inheritance group (groups-in-groups)
Product:	OpenShift Container Platform	Reporter:	Kenjiro Nakayama <knakayam>
Component:	apiserver-auth	Assignee:	Jordan Liggitt <jliggitt>
Status:	CLOSED ERRATA	QA Contact:	weiwei jiang <wjiang>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	3.1.0	CC:	aos-bugs, erich, jliggitt, knakayam, pep, skuznets, tdawson, wsun
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-05-12 16:27:17 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1267746

Description Kenjiro Nakayama 2016-01-25 01:40:52 UTC

Description of problem:

- OpenShift's LDAP authentication doesn't handle inheritance group (groups-in-groups) on AD.
- Even if we added "1.2.840.113556.1.4.1941"[1] to the OID, the query doesn't find any user under the inheritance group.

(Although The user tested and provided useful output, I will file them as *private comment* since the results contain a lot of private information.

Version-Release number of selected component (if applicable):

- OpenShift Enterprise v3.1

How reproducible:

(In private - The user provided the steps. And I will commented it on private.)

Actual results:

- atomic-openshift-master log (loglevel=4)

  Jan 22 17:51:11 foo.com atomic-openshift-master[119664]: I0122 17:51:11.918597  119664 ldap.go:122] searching for (&(memberOf:1.2.840.113556.1.4.1941:=CN=openshift,OU=FooGroups,DC=xx,DC=groupA,DC=com)(sAMAccountName=userA))
  Jan 22 17:51:11 foo.com atomic-openshift-master[119664]: I0122 17:51:11.919606  119664 ldap.go:130] no entries matching (&(memberOf:1.2.840.113556.1.4.1941:=CN=openshift,OU=FooGroups,DC=xx,DC=groupA,DC=com)(sAMAccountName=userA))

Expected results:

- Find userA with the filter (&(memberOf:1.2.840.113556.1.4.1941:=CN=openshift,OU=FooGroups,DC=xx,DC=groupA,DC=com)(sAMAccountName=userA))

Additional info:

- Workaround is to add all users to the DN, instead of just being able to use their groups. However it is too much work.

[1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa746475%28v=vs.85%29.aspx

Comment 2 Jordan Liggitt 2016-01-26 16:32:42 UTC

Can you provide the LDAP sync config they are using (with any private information redacted)

Comment 5 Jordan Liggitt 2016-01-28 02:34:53 UTC

Extensible match support is fixed in 3.1.1.

Comment 9 Jordan Liggitt 2016-02-25 15:49:38 UTC

That user story is for group sync, not authentication.

Comment 10 weiwei jiang 2016-02-29 10:50:54 UTC

(In reply to Jordan Liggitt from comment #9)
> That user story is for group sync, not authentication.

Checked with:
# openshift version 
openshift v3.1.1.907-1-g0755947
kubernetes v1.2.0-alpha.7-703-gbc4550d
etcd 2.2.5
and work well.

And the fake data is
user1 is a member of group2
group2 is a member of group1(nested group)

Am I right?

Comment 11 Jordan Liggitt 2016-02-29 15:35:10 UTC

> And the fake data is: 
>   user1 is a member of group2
>   group2 is a member of group1 (nested group)

That is the correct structure. The test is to ensure a user lookup filter like this would find that user:

url: "ldap://ldap.example.com/o=Acme?sAMAccountName?sub?(memberOf:1.2.840.113556.1.4.1941:=CN=group1,OU=...,DC=...)"

Comment 12 weiwei jiang 2016-03-01 01:57:49 UTC

(In reply to Jordan Liggitt from comment #11)
> > And the fake data is: 
> >   user1 is a member of group2
> >   group2 is a member of group1 (nested group)
> 
> That is the correct structure. The test is to ensure a user lookup filter
> like this would find that user:
> 
> url:
> "ldap://ldap.example.com/o=Acme?sAMAccountName?sub?(memberOf:1.2.840.113556.
> 1.4.1941:=CN=group1,OU=...,DC=...)"

Thanks.

Comment 16 errata-xmlrpc 2016-05-12 16:27:17 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2016:1064