Bug 1238442

Summary: AD Integration fails
Product: Red Hat Satellite Reporter: Andrew Schofield <andrew.schofield>
Component: Users & RolesAssignee: Daniel Lobato Garcia <dlobatog>
Status: CLOSED ERRATA QA Contact: Kedar Bidarkar <kbidarka>
Severity: urgent Docs Contact: David O'Brien <daobrien>
Priority: unspecified    
Version: 6.1.0CC: ahuchcha, ahumbe, bbuckingham, bkearney, chpeters, chrobert, cwelton, dlobatog, greartes, howey.vernon, johfulto, jpazdziora, kabbott, mmccune, nshaik, rmarti, sreber, xdmoon
Target Milestone: UnspecifiedKeywords: Regression, ReleaseNotes, Triaged
Target Release: Unused   
Hardware: Unspecified   
OS: Unspecified   
URL: http://projects.theforeman.org/issues/11428
Whiteboard: relnote-prio
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-11-19 15:56:23 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1190823    

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:
Always.

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:

http://projects.theforeman.org/issues/11407

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. 

https://github.com/theforeman/foreman/blob/develop/app/models/user.rb#L232

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|                 
    begin
      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}"
    end
  end
end

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
93,94c93
<         #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.

https://access.redhat.com/errata/RHBA-2015:2474

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