Bug 1408135
| Summary: | Customer facing issues when adding Roles in UserGroup + LDAP Filter (LDAP Auth) | ||
|---|---|---|---|
| Product: | Red Hat Satellite | Reporter: | Waldirio M Pinheiro <wpinheir> |
| Component: | Users & Roles | Assignee: | Daniel Lobato Garcia <dlobatog> |
| Status: | CLOSED ERRATA | QA Contact: | Peter Ondrejka <pondrejk> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 6.2.2 | CC: | bbuckingham, dhlavacd, dlobatog, ehelms, jcallaha, mhulan, wpinheir, zhunting |
| Target Milestone: | Unspecified | Keywords: | Triaged |
| Target Release: | Unused | ||
| Hardware: | All | ||
| OS: | All | ||
| URL: | http://projects.theforeman.org/issues/17992 | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2018-02-21 17:05:36 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: | |||
|
Description
Waldirio M Pinheiro
2016-12-22 09:17:00 UTC
We did some debugging and here's what happened. The filter set in the auth source checks that ANY object Satellite contacts, must be in this inheritance tree:
- OU = groups
- CN = Red Hat Satellite Users
However, it was trying to add a group 'Nimbus Satellite Admins' which is NOT under that inheritance tree (Red Hat Satellite Users). Satellite is able to find the group, but the moment it checks for users, it notices they don't comply with the filter and ldap_fluff fails with an exception.
- OU = groups
- CN = Red Hat Satellite Users
- CN = Nimbus Satellite Admins
This will not work because the filter checks for the user belonging to "Red Hat Satellite Users", and here Nimbus Satellite Admins does NOT belong to it. (memberOf).
We changed "Nimbus Satellite Admin" to this:
- OU = groups
- CN = Red Hat Satellite Users
- CN = Nimbus Satellite Admin
- CN = whatever other group in satellite
And now it works.
So we're changing the bugzilla to just handle this nicely, and don't merely throw a 500, but explain what happened, by showing an error like:
You tried to add a user group that has users that do not belong to the filter in your LDAP auth source.
Connecting redmine issue http://projects.theforeman.org/issues/17992 from this bug Upstream bug assigned to dlobatog Upstream bug assigned to dlobatog The issue ended up having not much to do with the original thing described here. The filter was fine. Waldirio and I had a call with the customer to figure out the issue: 1. The Nimbus group could not refresh. 2. The issue was that the group contained 2 DNs on its list of members: - 1 of them as an user - the 2nd one was a group 3. When ldap_fluff AD tried to fetch the users, it called find_by_dn on all users of the group: - https://github.com/theforeman/ldap_fluff/blob/6d23888fb5ba6175a91da68ce51f6a7fde39f273/lib/ldap_fluff/generic.rb#L49 - https://github.com/theforeman/ldap_fluff/blob/master/lib/ldap_fluff/active_directory.rb#L33 - https://github.com/theforeman/ldap_fluff/blob/master/lib/ldap_fluff/generic_member_service.rb#L28 4. The method raised an UIDNotFoundException, because clearly the DN for the group could not be found as an user. We provided a hotfix to the customer in which in this situation groups are skipped. I would recommend this to be the behavior on the next implementation as the users can be fetched just fine and the groups can be ignored safely. I will submit a PR to ignore groups in this situation and release a patch version of ldap_fluff ASAP. I've also disconnected the upstream issue from this ticket as the fix provided to the customer is not related. This is now released upstream and pending merge downstream. Verified in Sat6.3 snap 26, using an LDAP auth source with custom filter does not prevent user groups from being edited. 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-2018:0336 The needinfo request[s] on this closed bug have been removed as they have been unresolved for 500 days |