Red Hat Satellite engineering is moving the tracking of its product development work on Satellite to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "Satellite project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs will be migrated starting at the end of May. If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "Satellite project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/SAT-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1404906 - Users authenticated via external sources (except LDAP) contain no default context/location
Summary: Users authenticated via external sources (except LDAP) contain no default con...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Users & Roles
Version: 6.2.5
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: Unspecified
Assignee: satellite6-bugs
QA Contact: Katello QA List
URL:
Whiteboard:
: 1358544 1422306 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-12-15 03:47 UTC by Alexey Masolov
Modified: 2022-03-13 14:09 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-09-04 18:04:14 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Foreman Issue Tracker 21292 0 Normal New Users authenticated via external sources (Kerberos) contain no default context/location 2020-02-18 20:51:35 UTC

Description Alexey Masolov 2016-12-15 03:47:26 UTC
Description of problem:
A similar problem as in https://bugzilla.redhat.com/show_bug.cgi?id=1104822 but for IdM/AD if they're configured directly (https://access.redhat.com/documentation/en/red-hat-satellite/6.2/paged/server-administration-guide/92-using-identity-management).

Original description is still relevant:
Upon login using an 'external' user. The user cannot do anything. I've even attempted to specify an external group, but there is no context/location settings in the external group settings.

I was expecting it to be fixed but it wasn't. My current workaround is to use a foreman hook on user/after_create to modify taxable_taxonomies table.

foreman=# select id,login,auth_source_id from users where id = 38;
 id |       login        | auth_source_id 
----+--------------------+----------------
 38 | satellite-new-user |              3
(1 row)
foreman=# select id,type,name from auth_sources where id =3;
 id |        type        |   name   
----+--------------------+----------
  3 | AuthSourceExternal | External
(1 row)

foreman=# select * from taxable_taxonomies where taxable_id = 38 and taxable_type = 'User';
 id | taxonomy_id | taxable_id | taxable_type | created_at | updated_at 
----+-------------+------------+--------------+------------+------------
(0 rows)

Version-Release number of selected component (if applicable):
6.2.4
6.2.5

How reproducible:
100%

Steps to Reproduce:
1. Configure Idm as external auth source in accordance to https://access.redhat.com/documentation/en/red-hat-satellite/6.2/paged/server-administration-guide/92-using-identity-managemen
2. Create new user in IDM and login to Satellite

Actual results:
As described above

Expected results:
Organzation/location are assigned on creation. 

foreman=# select id,taxonomy_id,taxable_id,taxable_type from taxable_taxonomies where taxable_id = 38 and taxable_type = 'User';
 id  | taxonomy_id | taxable_id | taxable_type 
-----+-------------+------------+--------------
 894 |           1 |         38 | User
 895 |           2 |         38 | User
(2 rows)


Additional info:

Comment 1 Marek Hulan 2016-12-15 07:33:01 UTC
Hello Alexey. How would you recommend this to be handled? When user setup external authentication like this we have no notion of where the user is stored at. We only get information that the user was authenticated externally and what are his/her user groups. We could potentially enable admin to configure orgs and locs on external auth source which is currently only available for LDAP auth sources, but that means only single set of orgs and locs would be assigned to user. This is because all users are assigned to single external auth source which represents any external service.

Would that address your use case?

Comment 2 Daniel Lobato Garcia 2016-12-15 10:07:52 UTC
I think that in the next Z-stream this feature will be available by having taxonomies on LDAP, several LDAP auth sources can be created and linked to different taxonomies (depending on the base DN for example) to address this issue. I'll look for the original issue and mark this as a duplicate.

Comment 3 Marek Hulan 2016-12-15 11:59:51 UTC
Daniel, I don't think you're right. In this case they use external auth source, not LDAP auth source. This is why I asked support for external auth source in the original PR https://github.com/theforeman/foreman/pull/3864#discussion_r79814713 but since there is no way to update external auth source by user, we didn't include it. So this is not a duplicate I think.

Comment 4 Alexey Masolov 2016-12-16 01:07:05 UTC
Hi Marek,

I believe that any external auth sources (including LDAP) should be visible in WebUI and be in one place. So, I would say the best solution is to configure taxonomies for external IdM/AD in the same way as it is implemented for LDAP. I totally understand that there are some limitations like all users are assigned to single external source. 

Would it be appropriate to rename "LDAP Authentication" to "External Authentication" in WebUI and manage all sources from there?

Comment 6 Daniel Lobato Garcia 2016-12-20 14:43:13 UTC
Yeah - sounds like 6.3.0 work based on Alexey's comment and because this is a feature. I think that's a decent enough way to do it, having just one 'external authentication' source which allows users that log in through 'external' to be mapped to at least some org/loc. 

I would suggest setting a REMOTE_USER_ORG / REMOTE_USER_LOC variable too that we could take into account upon login.

Comment 9 Kim Borup 2017-03-29 09:37:41 UTC
*** Bug 1358544 has been marked as a duplicate of this bug. ***

Comment 13 Marek Hulan 2017-08-14 19:42:24 UTC
*** Bug 1422306 has been marked as a duplicate of this bug. ***

Comment 14 Daniel Lobato Garcia 2017-10-11 08:29:21 UTC
Created redmine issue http://projects.theforeman.org/issues/21292 from this bug

Comment 18 Bryan Kearney 2018-09-04 18:04:14 UTC
Thank you for your interest in Satellite 6. We have evaluated this request, and we do not expect this to be implemented in the product in the foreseeable future. We are therefore closing this out as WONTFIX. If you have any concerns about this, please feel free to contact Rich Jerrido or Bryan Kearney. Thank you.


Note You need to log in before you can comment on or make changes to this bug.