Red Hat Bugzilla – Bug 1301425
OpenShift v3's LDAP authentication doesn't handle inheritance group (groups-in-groups)
Last modified: 2016-10-30 18:55:04 EDT
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
Can you provide the LDAP sync config they are using (with any private information redacted)
Extensible match support is fixed in 3.1.1.
That user story is for group sync, not authentication.
(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?
> 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=...)"
(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.
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