Users created via external delegation API don't get usergroups on first login
|Status:||Ready For Testing|
|Assigned To:||Daniel Lobato Garcia|
|Target version:||Foreman - Team Marek Iteration 21|
|Found in release:||Pull request:||https://github.com/theforeman/foreman/pull/4119|
|Velocity based estimate||-|
Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1406295
Description of problem:
Customer has an user who logs in via external delegation (REMOTE_USER). This user is created automatically upon login. The user is not authenticated using regular Satellite LDAP authentication sources, but through the 'authorized login delegation' setting.
When the user is created in this manner, it will not get its usergroups until the next time the cron job runs, or unless the admin clicks on refresh external user groups.
Version-Release number of selected component (if applicable): 6.2.4, but it shows up in nightly and upstream even.
How reproducible: Always
Steps to Reproduce:
1. Setup some external user groups linked to Satellite user groups
2. Login via external delegation (krb5 ticket, for example)
3. Notice how the users, even if they are in the external user groups, do not get updated.
The user groups should be updated when the user logs in for all Authentication sources where "Usergroup sync" is checked.
#1 Updated by Dominic Cleal 10 months ago
- Category set to Authentication
- Status changed from New to Assigned
Are the REMOTE_USER_GROUP_* variables set correctly? The description doesn't mention them - if only REMOTE_USER is set then this would be normal. It shouldn't rely on LDAP connectivity or refreshing.
#3892 implements this.
#2 Updated by Daniel Lobato Garcia 10 months ago
They are not set, the issue here is that they were expecting REMOTE_USER logins to check in all LDAP auth sources as they don't want to add more configuration for REMOTE_USER_GROUP. They worked around it by running the cron very often - it will find a login shared by the REMOTE_USER and the ActiveDirectory auth source and put users from auth source "EXTERNAL" into external usergroups linked to LDAP.
In the end, our code already checks in LDAP auth sources during cron or manual refresh, so it's just a matter of checking on login for external users too.
Foreman doesn't deal well with 'logins' that happen to be in multiple authentication sources. E.g: I create an 'admin' user on FreeIPA and AD. Then on Foreman I'll get added to all external user groups (linked to both FreeIPA and AD) even if my user.authentication_source is just FreeIPA. It's not great but this scenario happens rarely (or ever?) I believe.
Things like this (AD provides krb5 tokens that I use for REMOTE_USER, but the REMOTE_USER isn't linked to AD in Foreman) are more or less common.
Aside from patching the code to deal with that scenario, I think we should be providing this info to the Foreman admin users. "Hey you seem to have a user with the same login in 2 auth sources (external and AD). Be warned about this and that".
#4 Updated by Dominic Cleal 10 months ago
Then on Foreman I'll get added to all external user groups (linked to both FreeIPA and AD) even if my user.authentication_source is just FreeIPA. It's not great but this scenario happens rarely (or ever?) I believe.
Users with a different authentication source to the external user group shouldn't be linked - the list of users from the auth source when refreshing the external user group should be filtered to only those with the same auth source.
This is likely buggy behaviour and shouldn't be relied upon like this, not built upon to force-refresh LDAP external user groups when using external auth sources.