Description of problem: When "Usergroup sync" is enabled when using LDAP authentication, Satellite searches the "Base DN" instead of the "Groups Base DN" indicated in the LDAP Authentication configuration. This causes a delay in LDAP authentication while Satellite is searching the whole subtree of the base DN instead of just the groups base DN. Version-Release number of selected component (if applicable): satellite-6.2.2.1-1.0.el7sat.noarch How reproducible: Every Time Steps to Reproduce: 1. Configure LDAP Authentication in "LDAP server" tab. 2. Configure "Base DN" and "Groups Base DN" in Accounts tab. (e.g. Base DN: dc=example,dc=com & Groups Base DN: ou=groups,dc=example,dc=com) 3. Check the box that says "Usergroup Sync". 4. Authenticate to Satellite with an LDAP id. Actual results: The login process takes approximately 20 seconds. A packet capture reveals that Satellite is doing a search in LDAP with a base object of "dc=example,dc=com", scope of wholeSubtree, filter of (memberUID=$username). Expected results: Login should take less time. The LDAP search should have a base object of ou=groups,dc=example,dc=com. Additional info:
"Satellite is doing a search in LDAP with a base object of "dc=example,dc=com", scope of wholeSubtree, filter of (memberUID=$username)." What implementation of LDAP are you using? From the looks of it it's OpenLDAP or something similar that implements POSIX LDAP. The library we use for LDAP seems to look in the group DN for all cases except that one. Given that the filter POSIX uses is quite similar to the one - I've assume it's that and submitted a patch upstream. https://github.com/theforeman/ldap_fluff/pull/55 Feel free to apply the patch locally (it's tiny) and let us know if it fixes your problem in the meantime. I think this is safe enough to backport to 6.2.z
Sorry for the late reply, just got back from vacation. We are using Sun One Directory Server, which does implement POSIX LDAP. I will apply the patch after I get caught up and let you know how it goes.
I installed the patch and verified that it is working as it should now. Thanks for your help!
Glad to hear that! I will merge by the end of the day and hopefully release ldap_fluff 0.4.5 so that we can serve it in 6.2.x
https://github.com/theforeman/foreman-packaging/pull/1486 is on the pipeline for packaging upstream. Once it gets built I'll make sure to propose it for 6.2.z
Adam, the bugfix is already released in ldap_fluff 0.4.5 upstream. It's making it's way through packaging, then QA will test it and it'll get to you in a zStream. Thanks for providing feedback about the patch before :)
Created attachment 1250272 [details] posix ldap Build: Satellite 6.2.8 snap 2 tfm-rubygem-ldap_fluff-0.4.5-1.el7sat.noarch Verification Steps: With Base DN :cn=Users,dc=xxx,dc=xxx,dc=xxx,dc=xxx,dc=xxx,dc=xxx Groups base DN : cn=foobargroup,dc=xxx,dc=xxx,dc=xxx,dc=xxx,dc=xxx,dc=xxx The LDAP search has a base object of cn=foobargroup,dc=xxx,dc=xxx,dc=xxx,dc=xxx,dc=xxx,dc=xxx. Tested this with AD and also Posix PFA
Created attachment 1250273 [details] Ad ldap
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/RHBA-2017:0447