Bug 1238442 - AD Integration fails
Summary: AD Integration fails
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Users & Roles
Version: 6.1.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: Unspecified
Assignee: Daniel Lobato Garcia
QA Contact: Kedar Bidarkar
David O'Brien
URL: http://projects.theforeman.org/issues...
Whiteboard: relnote-prio
: Red Hat1249760 (view as bug list)
Depends On:
Blocks: sat61-release-notes
TreeView+ depends on / blocked
Reported: 2015-07-01 21:31 UTC by Andrew Schofield
Modified: 2020-01-17 15:31 UTC (History)
18 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2015-11-19 15:56:23 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Article) 1313323 0 None None None Never
Red Hat Product Errata RHBA-2015:2474 0 normal SHIPPED_LIVE Satellite 6.1.4 bug fix update 2015-11-19 20:45:48 UTC

Description Andrew Schofield 2015-07-01 21:31:01 UTC
Description of problem:

Using public beta the AD integration does not assign default priviliges.

Version-Release number of selected component (if applicable):
6.1 public beta

How reproducible:

Steps to Reproduce:
1. Create LDAP Authentication (we set: Name, Server, Port, Server Type, Account Name, Account Password, Base DN, 'Automatically create accounts in Foreman'. Attribute mappings are: sAMAccountName, givenName, sn, userPrincipleName (in order).
2.Create a user group. We name it 'Test' NO users are assigned. On the Roles tab we select 'Admin' external groups we give this an external name which matches one of our AD groups (Satellite seems happy with this name, fails with errors if we use a name NOT in AD).
3. Now logging into Satellite using a member of this group the account is created in Satellite BUT the user is assigned NO roles (according to the above, they should get the admin role).

Actual results:
As above.

Expected results:
When logging in as a user of an AD group the user should be assigned the priviliges in the 'Roles' tab. (In out example 'Admin').

Additional info:

Comment 1 RHEL Program Management 2015-07-01 21:43:39 UTC
Since this issue was entered in Red Hat Bugzilla, the release flag has been
set to ? to ensure that it is properly evaluated for this release.

Comment 3 Andrew Schofield 2015-08-13 22:57:57 UTC
This is still an issue in 6.1.1. The attached KB gives a 404 (but wasn't a solution anyway - it just said 'hey, do it manually'.

Comment 6 Daniel Lobato Garcia 2015-08-18 18:40:52 UTC
Andrew and I have been debugging this together and we've found this bug was the culprit, which we've fixed & he's got a working patch in his installation already:


https://github.com/theforeman/foreman/pull/2616/ is the fix

This allows refresh of usergroups to work properly through the UI clicking on refresh and the cronjob that runs foreman-rake ldap:refresh_usergroups. 

We found a bug, where Satellite is only looking for an attribute 'users' on LDAP users when they log in to update the usergroups. 


In Active Directory, this attribute is called 'memberof', so it will not put the user in the appropriate user groups on login, only when an admin clicks on refresh or the cronjob runs.

I'll open a new issue on Redmine for the latter issue, and mark this one as POST.

Thanks Andrew & Johnray for your cooperation on fixing this one, it's been a boon

Comment 7 Daniel Lobato Garcia 2015-08-18 18:54:47 UTC
Actually disregard that last comment about memberof, I'm investigating the issue and it might be just another instance of the same problem with uppercase/lowercase logins.

Comment 8 Daniel Lobato Garcia 2015-08-18 18:58:37 UTC
http://projects.theforeman.org/issues/7355 would be the relevant bug for the other part of this bug.

Comment 9 Andrew Schofield 2015-08-18 19:29:53 UTC
Daniel: Comment 7 is correct. If I specify the AD group ALL lowercase in Usergroups->Usergroup->External Groups. Then delete my user and login then the user is created AND I'm granted the access I should be (Admin in my case):

2015-08-18 15:11:19 [I] User 'n018147' auto-created from LDAP-GBL-AD
2015-08-18 15:11:19 [I] Expire fragment views/tabs_and_title_records-14 (0.1ms)
2015-08-18 15:11:19 [I] Expire fragment views/tabs_and_title_records-14 (0.1ms)
2015-08-18 15:11:19 [I] Redirected to https://usl10149335.am.hedani.net/hosts
2015-08-18 15:11:19 [I] Completed 302 Found in 15301ms (ActiveRecord: 40.7ms)

Comment 10 Andrew Schofield 2015-08-18 20:25:12 UTC
I think this may originate from the update_usergroups function in /usr/share/foreman/app/models/auth_sources/auth_source_ldap.rb:

def update_usergroups(login, password)
  ldap_con(login, password).group_list(login).each do |name|                 
      external_usergroup = external_usergroups.find_by_name(name)
      external_usergroup.refresh if external_usergroup.present?
    rescue => error
      logger.warn "Could not update user group #{name}: #{error}"

group_list(login).each iterates through a lowercase arrary of AD groups I'm a member of. However, external_usergroups.find_by_name(name) expects the same case as is in satellite hence lowercaseing the entry in satellite works,

Comment 12 Daniel Lobato Garcia 2015-08-19 11:25:29 UTC
Thanks Andrew, that was helpful. Patch on the making for that.

Comment 13 Daniel Lobato Garcia 2015-08-19 14:58:59 UTC
https://github.com/theforeman/foreman/pull/2621 submitted, should make it to the Z-stream release. This one fixes the issue where the external user groups would not be updated on login, as described by Andrew on comment 10.

Thanks again Andrew!

Comment 14 Andrew Schofield 2015-08-19 15:25:50 UTC
# diff auth_source_ldap.rb auth_source_ldap.rb.bak
<         #external_usergroup = external_usergroups.find_by_name(name)
<         external_usergroup = external_usergroups.where('lower(name) = ?', name.downcase).last
>         external_usergroup = external_usergroups.find_by_name(name)

Verified this and it works a charm. Many thanks for this Daniel.

Comment 15 Mike McCune 2015-08-26 16:58:42 UTC
This bug is not POST, the upstream is not merged, moving to assigned.

Comment 16 Bryan Kearney 2015-09-16 14:48:45 UTC
Connecting redmine issue http://projects.theforeman.org/issues/11428 from this bug

Comment 17 Bryan Kearney 2015-09-16 14:57:40 UTC
Moving to POST since upstream bug http://projects.theforeman.org/issues/11428 has been closed
Daniel Lobato Garcia
Applied in changeset commit:33d7500a8d3148b6877d630a72f598f4be06b423.

Comment 23 Kedar Bidarkar 2015-10-12 16:34:35 UTC
Looks like we have a regression related to this bug.

when trying to setup the AD authentication and trying to login to the sat6 with an AD user. I see the following message.

015-10-12 10:20:55 [I] Processing by UsersController#login as HTML
2015-10-12 10:20:55 [I]   Parameters: {"utf8"=>"✓", "authenticity_token"=>"f/kAq9I4eUpuHaeJ04KBEkbIO+5n/B1h+15AmyCwGTg=", "login"=>{"login"=>"foobar", "password"=>"[FILTERED]"}, "commit"=>"Login"}
2015-10-12 10:21:00 [I] Expire fragment views/tabs_and_title_records-4 (0.3ms)
2015-10-12 10:21:00 [I] Expire fragment views/tabs_and_title_records-4 (0.4ms)
2015-10-12 10:21:01 [W] Operation FAILED: wrong number of arguments (2 for 1)
2015-10-12 10:21:01 [I]   Rendered common/500.html.erb within layouts/application (12.6ms)
2015-10-12 10:21:01 [I]   Rendered layouts/base.html.erb (2.8ms)
2015-10-12 10:21:01 [I] Completed 500 Internal Server Error in 6205ms (Views: 375.8ms | ActiveRecord: 42.7ms)

Currently normal AD authentication too is broken.

a) Create LDAP auth source
b) Create Usergroups, assign role as "admin" and add the external usergroup, in this case here it was "foobargroup".
c) Trying to login via "foobar" user throws the below message on the UI.

"wrong number of arguments (2 for 1)" and also 500 ISE.

d) Trying to relogin with the user "foobar" does not provide the admin rights, but the login attempt is successful.

I tried with the same AD setup on an older sat6 setup build and it works fine.

Comment 29 Kedar Bidarkar 2015-10-13 11:11:27 UTC
Ignore point f) from comment 27. running "foreman-rake ldap:refresh_usergroups" via CLI works as expected.

Comment 37 Kedar Bidarkar 2015-11-05 17:52:19 UTC
VERIFIED With Satellite-6.1.0-RHEL-$-20151104.0 for both RHEL6 and RHEL7.

We can now login with the Admin privileges.

Comment 41 errata-xmlrpc 2015-11-19 15:56:23 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Comment 42 Daniel Lobato Garcia 2015-12-10 09:28:16 UTC
*** Red HatBug 1249760 has been marked as a duplicate of this bug. ***

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