Bug #7355
open
External groups not updated when user created on the fly
Added by Leah Fisher over 10 years ago.
Updated almost 10 years ago.
Description
I had a new user log in with AD credentials and the user account was created with default permissions. I then had to log in and refresh the external group to give him proper permissions so he could have access to the system.
When new users are created, they should have groups refreshed because otherwise why bother with external groups or on the fly creation.
- Translation missing: en.field_release set to 10
- Translation missing: en.field_release deleted (
10)
- Category set to Authentication
I tried reproducing this and I couldn't, these are the scenarios:
- User group "a" with external user group "foremaners". User "lobato" (who is in "foremaners" in LDAP) tries to log in and autocreate the account. Account is autocreated and user "lobato" gets put in user group "a"
- User group "a" with external user group "foremaners". User "vito" (who is in "katellers" in LDAP, nested below "foremaners") tries to log in and autocreate the account. Account is autocreated and user doesn't get put in any user group because there is no external user group "katellers".
Is the second scenario what you're experiencing? I'm not entirely sure we should support that.
I seem to be getting a different response in scenarios 1. I have tested multiple times and see nothing in the logs suggesting it is trying to refresh the user groups. Is this possible that it works for the freeipa ldap servers, but not for AD ldap servers?
My logs look like the following:
Processing by UsersController#login as HTML
Parameters: {"utf8"=>"✓", "authenticity_token"=>"FLAD+WwH1UynfdA8zheoUqyc2I2Iru8vJP/ki6XalvQ=", "login"=>{"login"=>"lrf", "password"=>"[FILTERED]"}, "commit"=>"Login"}
Expire fragment views/tabs_and_title_records-9 (0.2ms)
Expire fragment views/tabs_and_title_records-9 (0.1ms)
User 'lrf' auto-created from LDAP-AD
Expire fragment views/tabs_and_title_records-9 (0.2ms)
Expire fragment views/tabs_and_title_records-9 (0.1ms)
Redirected to https://foreman/hosts
Completed 302 Found in 5751ms (ActiveRecord: 19.9ms)
Processing by HostsController#index as HTML
Rendered common/403.html.erb within layouts/application (1.5ms)
Rendered common/_searchbar.html.erb (30.4ms)
Rendered home/_user_dropdown.html.erb (2.3ms)
Read fragment views/tabs_and_title_records-9 (0.1ms)
Rendered home/_organization_dropdown.html.erb (4.2ms)
Rendered home/_location_dropdown.html.erb (3.1ms)
Rendered home/_org_switcher.html.erb (8.1ms)
Rendered home/_submenu.html.erb (0.9ms)
Rendered home/_submenu.html.erb (1.2ms)
Write fragment views/tabs_and_title_records-9 (3.7ms)
Rendered home/_topbar.html.erb (28.3ms)
Rendered layouts/base.html.erb (30.6ms)
Filter chain halted as :authorize rendered or redirected
Completed 403 Forbidden in 96ms (Views: 58.5ms | ActiveRecord: 16.2ms)
I am seeing the same behaviour as Leah on FreeIPA
Steps to reproduce:
Create group in FreeIPA
Add user to the new group in FreeIPA (and ensure they haven't logged in to Foreman before)
Ensure group is allowed in the HBAC rule for Foreman
Create a new user group in Foreman with the same name as the group you created in FreeIPA
Add External group and add the group you added to FreeIPA
Login as the user you added to the new group
Expected Behaviour:
The user should be logged in to Foreman and be a member of the Foreman user group you created above
Actual Behaviour:
The user is logged into Foreman but is not a member of any user group in Foreman. If you refresh the external groups for the Foreman user group you created above then the user is added into the user group.
The
Sorry, should have added the versions being used:
Foreman: 1.7.3
FreeIPA: 3.0.0 (Release: 42.el6.centos)
Both running on CentOS 6.5
- Related to Bug #11428: External user groups refresh is not case insensitive added
Also available in: Atom
PDF