Hide Forgot
Description of problem: After configure ldap auth and usergroup sync, I'm keeping the user sync feature *disabled* on ldap auth source conf, then it's expected to see, at the first login customer see *access denied* but after some time, the task *ldap:refresh_usergroups* via crontab should update this status but is not. Version-Release number of selected component (if applicable): 6.3.4 How reproducible: 100% Steps to Reproduce: 1. Configure ldap auth source 2. Configure user group 3. Login with the AD user 4. Execute the command *foreman-rake ldap:refresh_usergroups* Actual results: via webUI we are not seeing changes via user groups to that user Expected results: See the correct information related to User versus group Additional info:
Created attachment 1544591 [details] foreman-tail output foreman-tail logs during foreman-rake call. I see this when I run the command line `/usr/sbin/foreman-rake ldap:refresh_usergroups` or when I authenticate with an LDAP user.
We are hitting this bug as well with Satellite 6.4.2. I added our debug logs as attachments. Our LDAP auth works correctly, but the usergroup sync doesn't work when using the foreman-rake task or when logging into the web interface. The only way to refresh the usergroups is to use the web interface to manually refresh the usergroups one at a time. Below is the direct output when running the foreman-rake test: [root@satellite-test ~]# /usr/sbin/foreman-rake ldap:refresh_usergroups /usr/share/foreman/lib/foreman.rb:8: warning: already initialized constant Foreman::UUID_REGEXP /usr/share/foreman/lib/foreman.rb:8: warning: previous definition of UUID_REGEXP was here /usr/share/foreman/lib/core_extensions.rb:182: warning: already initialized constant ActiveSupport::MessageEncryptor::DEFAULT_CIPHER /opt/theforeman/tfm-ror51/root/usr/share/gems/gems/activesupport-5.1.6/lib/active_support/message_encryptor.rb:22: warning: previous definition of DEFAULT_CIPHER was here /opt/theforeman/tfm/root/usr/share/gems/gems/katello-3.7.0.46/app/models/katello/concerns/content_facet_host_extensions.rb:7: warning: already initialized constant Katello::Concerns::ContentFacetHostExtensions::ERRATA_STATUS_MAP /opt/theforeman/tfm/root/usr/share/gems/gems/katello-3.7.0.46/app/models/katello/concerns/content_facet_host_extensions.rb:7: warning: previous definition of ERRATA_STATUS_MAP was here /opt/theforeman/tfm/root/usr/share/gems/gems/katello-3.7.0.46/app/models/katello/concerns/content_facet_host_extensions.rb:14: warning: already initialized constant Katello::Concerns::ContentFacetHostExtensions::TRACE_STATUS_MAP /opt/theforeman/tfm/root/usr/share/gems/gems/katello-3.7.0.46/app/models/katello/concerns/content_facet_host_extensions.rb:14: warning: previous definition of TRACE_STATUS_MAP was here /opt/theforeman/tfm/root/usr/share/gems/gems/katello-3.7.0.46/app/models/katello/concerns/subscription_facet_host_extensions.rb:13: warning: already initialized constant Katello::Concerns::SubscriptionFacetHostExtensions::SUBSCRIPTION_STATUS_MAP /opt/theforeman/tfm/root/usr/share/gems/gems/katello-3.7.0.46/app/models/katello/concerns/subscription_facet_host_extensions.rb:13: warning: previous definition of SUBSCRIPTION_STATUS_MAP was here
Waldirio, would it be possible to get access to your reproducer? I have a feeling this may be actually https://projects.theforeman.org/issues/26831, the patch would be trivial to test https://patch-diff.githubusercontent.com/raw/theforeman/foreman/pull/6772.diff if you or your customer is interested. Mac, I looked at your logs which showed different error, looking more https://projects.theforeman.org/issues/24497, where it turned out user had netgroups enabled for non netgroups use. Can you double check that? But then most likely you will start hitting the same as above.
Mac, also this is related to your logs https://projects.theforeman.org/issues/25840 - fixed in 6.5
Hello all I'll test on 6.5 and will post the results here. Thank you! Best Regards -- Waldirio M Pinheiro | Senior Software Maintenance Engineer
I have tested and can confirm that it's working on Satellite 6.6.0 Beta.
We have recently updated our satellite and capsule servers to 6.5.2.1. Kindly confirm when will version 6.6.0 be out for public use? Regards, Ramesh Daryani
Ramesh, If you had seen the update from Marek Hulan, earlier i.e. ~~~~~~~~~~~~~~~~~~~~~~ I have a feeling this may be actually https://projects.theforeman.org/issues/26831, the patch would be trivial to test https://patch-diff.githubusercontent.com/raw/theforeman/foreman/pull/6772.diff if you or your customer is interested. ~~~~~~~~~~~~~~~~~~~~~~ This is already delivered on Satellite 6.6 Public beta and seems to be working as it was expected. We will test the patch "https://patch-diff.githubusercontent.com/raw/theforeman/foreman/pull/6772.diff" on Satellite 6.5 and update here if that gives me a positive result. Meanwhile, Your patience will be appreciated. Regards, Sayan
This landed upstream in 1.22 which is the basis for 6.6. Moving ON_QA for verification.
*** Satellite 6.4.4 Hotfix Available *** 1) Download http://people.redhat.com/~mmccune/hotfix/HOTFIXRHBZ1639907.tar to your Satellite 2) Unpack and Install: tar cvf HOTFIXRHBZ1639907.tar rpm -Uvh foreman*.rpm 3) restart: satellite-maintain service restart 4) resume operations and verify ldap refresh functions properly
Tested on Satelllite 6.6 Snap 22 using the reproducer from the initial report and comment #1. hammer> user-group info --id 8 Id: 8 Name: ADGroup2 Admin: yes Users: User groups: External user groups: foobargroup Roles: Created at: 2019/09/26 11:47:58 Updated at: 2019/09/26 11:47:58 ["foreman-rake ldap:refresh_usergroups" run in other terminal. No errors in the terminal or a log.> hammer> user-group info --id 8 Id: 8 Name: ADGroup2 Admin: yes Users: foobar User groups: External user groups: foobargroup Roles: Created at: 2019/09/26 11:47:58 Updated at: 2019/09/26 11:47:58 The user group mapped to an external group on a AD server gets updated successfully after running foreman-rake ldap:refresh_usergroups. VERIFIED
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-2019:3172