Bug #17794

Users created via external delegation API don't get usergroups on first login

Added by Daniel Lobato Garcia 10 months ago. Updated about 1 month ago.

Status:Ready For Testing
Priority:Normal
Assigned To:Daniel Lobato Garcia
Category:Authentication
Target version:Foreman - Team Marek Iteration 21
Difficulty: Bugzilla link:1406295
Found in release: Pull request:https://github.com/theforeman/foreman/pull/4119
Story points-
Velocity based estimate-
Release1.16.0Release relationshipAuto

Description

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.

Expected results:
The user groups should be updated when the user logs in for all Authentication sources where "Usergroup sync" is checked.

History

#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".

#3 Updated by The Foreman Bot 10 months ago

  • Status changed from Assigned to Ready For Testing
  • Pull request https://github.com/theforeman/foreman/pull/4119 added

#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.

#5 Updated by Daniel Lobato Garcia 10 months ago

  • Target version set to Team Daniel - iteration 8

#6 Updated by Daniel Lobato Garcia 9 months ago

  • Target version changed from Team Daniel - iteration 8 to Team Brad - Iteration 11

#7 Updated by Brad Buckingham 8 months ago

  • Target version deleted (Team Brad - Iteration 11)

#8 Updated by Daniel Lobato Garcia 8 months ago

  • Target version set to Team Daniel - Iteration 9

#9 Updated by Marek Hulán 3 months ago

  • Target version changed from Team Daniel - Iteration 9 to Team Marek Iteration 18

#10 Updated by Marek Hulán 3 months ago

  • Target version changed from Team Marek Iteration 18 to Team Marek Iteration 19

#11 Updated by Marek Hulán 2 months ago

  • Release set to 1.16.0

#12 Updated by Marek Hulán about 1 month ago

  • Target version changed from Team Marek Iteration 19 to Team Marek Iteration 20

#13 Updated by Marek Hulán about 1 month ago

  • Target version changed from Team Marek Iteration 20 to Foreman - Team Marek Iteration 21

Also available in: Atom PDF