Project

General

Profile

Bug #17794

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

Added by Daniel Lobato Garcia almost 2 years ago. Updated 3 months ago.

Status:
New
Priority:
Normal
Category:
Authentication
Target version:
-
Difficulty:
Triaged:
Bugzilla link:
Team Backlog:
Fixed in Releases:
Found in Releases:

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 almost 2 years 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 almost 2 years 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 almost 2 years ago

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

#4 Updated by Dominic Cleal almost 2 years 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 almost 2 years ago

  • Target version set to 1.15.5

#6 Updated by Daniel Lobato Garcia over 1 year ago

  • Target version changed from 1.15.5 to 169

#7 Updated by Brad Buckingham over 1 year ago

  • Target version deleted (169)

#8 Updated by Daniel Lobato Garcia over 1 year ago

  • Target version set to 1.11.0

#9 Updated by Marek Hulán about 1 year ago

  • Target version changed from 1.11.0 to 1.17.0-RC2

#10 Updated by Marek Hulán about 1 year ago

  • Target version changed from 1.17.0-RC2 to 1.18.0-RC2

#11 Updated by Marek Hulán about 1 year ago

  • Legacy Backlogs Release (now unused) set to 240

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

  • Target version changed from 1.18.0-RC2 to 214

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

  • Target version changed from 214 to 1.16.0-RC2

#14 Updated by Marek Hulán 12 months ago

  • Target version changed from 1.16.0-RC2 to 1.16.0-RC1

#15 Updated by Marek Hulán 12 months ago

  • Target version changed from 1.16.0-RC1 to 1.16.2

#16 Updated by Daniel Lobato Garcia 11 months ago

  • Legacy Backlogs Release (now unused) deleted (240)
  • Status changed from Ready For Testing to New

Resetting status as this isn't really a bug but a hack to fix communication if your LDAP management IT & Foreman admins cannot agree to provide REMOTE_USER_GROUP variables.

#17 Updated by Marek Hulán 11 months ago

  • Target version changed from 1.16.2 to 1.16.1

#18 Updated by Marek Hulán 10 months ago

  • Target version changed from 1.16.1 to 238

Also available in: Atom PDF