Project

General

Profile

Bug #14407

foreman-rake ldap:refresh_usergroups ends in endless loop with external user group in Active Directory

Added by Daniel Lobato Garcia over 6 years ago. Updated about 5 years ago.

Status:
Duplicate
Priority:
High
Category:
Authentication
Target version:
-
Difficulty:
Triaged:
No
Bugzilla link:
Pull request:
Fixed in Releases:
Found in Releases:

Description

Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1261997
Description of problem:
While attaching Satellite 6.1.1 to Active Directory using the built in LDAP provider, I found that when adding "external user group" to automatically assign a role to an Active Directory account, `foreman-rake ldap:refresh_usergroups` is ending up in a end-less loop

Version-Release number of selected component (if applicable):
foreman-1.7.2.34-1.el7sat.noarch

How reproducible:
Always

Steps to Reproduce:

hammer> auth-source ldap info --id=4
Id:                             4
Name:                           system-rhev.gsslab.rdu.redhat.com
LDAPS?:                         false
Port:                           389
Server Type:                    AuthSourceLdap
Account Username:               RHEV\sre_system
Base DN:                        cn=users,dc=rhev,dc=gsslab,dc=rdu,dc=redhat,dc=com
LDAP filter:                    
Automatically Create Accounts?: true
Login Name Attribute:           sAMAccountName
First Name Attribute:           givenName
Last Name Attribute:            sn
Email Address Attribute:        mail
Photo Attribute:
hammer> user-group info --id=2
Id:                   2
Name:                 Admin
Users:                
    sre_test2
User groups:          

External user groups: 
    sre_sat6
Roles:                
    Viewer
    View hosts
    Tasks Reader
    Tasks Manager
    Site manager
    Red Hat Access Logs
    Manager
    Edit partition tables
    Edit hosts
    Discovery Reader
    Discovery Manager
    Boot disk access
    Access Insights Viewer
    Access Insights Admin
Created at:           2015/09/10 09:36:27
Updated at:           2015/09/10 09:36:27

hammer> user-group external info --user-group Admin --id=2
Id:          2
Name:        sre_sat6
Auth source: system-rhev.gsslab.rdu.redhat.com

ldapsearch -LLL -x -h rhev-ad.gsslab.rdu2.redhat.com -D "RHEV\sre_system" -W -b "cn=users,dc=rhev,dc=gsslab,dc=rdu,dc=redhat,dc=com" '(sAMAccountName=sre_test1)'
Enter LDAP Password: 
dn: CN=Test 1. Reber,CN=Users,DC=rhev,DC=gsslab,DC=rdu,DC=redhat,DC=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: Test 1. Reber
sn: Reber
givenName: Test
initials: 1
distinguishedName: CN=Test 1. Reber,CN=Users,DC=rhev,DC=gsslab,DC=rdu,DC=redha
 t,DC=com
instanceType: 4
whenCreated: 20150910080741.0Z
whenChanged: 20150910081516.0Z
displayName: Test 1. Reber
uSNCreated: 676204
memberOf: CN=sre_sat6,CN=Users,DC=rhev,DC=gsslab,DC=rdu,DC=redhat,DC=com
uSNChanged: 676228
name: Test 1. Reber
objectGUID:: ocosGfW7ekKk7EfhTZFH6g==
userAccountControl: 66048
badPwdCount: 0
codePage: 0
countryCode: 0
badPasswordTime: 130863534640478484
lastLogoff: 0
lastLogon: 130863534735478484
pwdLastSet: 130863460614552568
primaryGroupID: 513
objectSid:: AQUAAAAAAAUVAAAA1xQhMV2+kD5S4cm/ngQAAA==
accountExpires: 9223372036854775807
logonCount: 0
sAMAccountName: sre_test1
sAMAccountType: 805306368
userPrincipalName: sre_test1@rhev.gsslab.rdu.redhat.com
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=rhev,DC=gsslab,DC=rdu,
 DC=redhat,DC=com
dSCorePropagationData: 16010101000000.0Z
lastLogonTimestamp: 130863465167973044

ldapsearch -LLL -x -h rhev-ad.gsslab.rdu2.redhat.com -D "RHEV\sre_system" -W -b "cn=users,dc=rhev,dc=gsslab,dc=rdu,dc=redhat,dc=com" '(sAMAccountName=sre_test2)'
Enter LDAP Password: 
dn: CN=Test2 Reber,CN=Users,DC=rhev,DC=gsslab,DC=rdu,DC=redhat,DC=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
objectClass: inetOrgPerson
cn: Test2 Reber
sn: Reber
givenName: Test2
distinguishedName: CN=Test2 Reber,CN=Users,DC=rhev,DC=gsslab,DC=rdu,DC=redhat,
 DC=com
instanceType: 4
whenCreated: 20150910123829.0Z
whenChanged: 20150910135100.0Z
displayName: Test2 Reber
uSNCreated: 676274
memberOf: CN=sre_sat6,CN=Users,DC=rhev,DC=gsslab,DC=rdu,DC=redhat,DC=com
uSNChanged: 676299
name: Test2 Reber
objectGUID:: Syvv33EYOUajgPatGfUtew==
userAccountControl: 66048
badPwdCount: 0
codePage: 0
countryCode: 0
badPasswordTime: 0
lastLogoff: 0
lastLogon: 0
pwdLastSet: 130863666600942818
primaryGroupID: 513
objectSid:: AQUAAAAAAAUVAAAA1xQhMV2+kD5S4cm/ogQAAA==
accountExpires: 9223372036854775807
logonCount: 0
sAMAccountName: sre_test2
sAMAccountType: 805306368
userPrincipalName: sre_test2@rhev.gsslab.rdu.redhat.com
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=rhev,DC=gsslab,DC=rdu,
 DC=redhat,DC=com
dSCorePropagationData: 16010101000000.0Z
lastLogonTimestamp: 130863623932659008

Login with an Active Directory Account, which is member of sre_sat6 and check on whether permissions are being assigned

Actual results:
User does not have any role assigned and when running `foreman-rake ldap:refresh_usergroups`, the command does not finish

Expected results:
Role automatically assigned to user or at least when `foreman-rake ldap:refresh_usergroups` is run

Additional info:
I checked the `foreman-rake ldap:refresh_usergroups` command and found that it does a end-less loop in /opt/rh/ruby193/root/usr/share/gems/gems/ldap_fluff-0.3.2/lib/ldap_fluff/active_directory.rb

When I comment the below section and manually defining `users` the command is successful and the user defined has the correct role assigned

... active_directory.rb
[...]
  def users_from_search_results(search, method)
    users = ["sre_test2"]

    search.send(method).each do |member|
      entry = @member_service.find_by_dn(member).first
      objectclasses = entry.objectclass.map(&:downcase)
#
#      if (%w(organizationalperson person) & objectclasses).present?
#        users << @member_service.get_login_from_entry(entry)
#      elsif (%w(organizationalunit group) & objectclasses).present?
#        users << users_for_gid(entry.cn.first)
#      end

    end

    users.flatten.uniq
  end

[...]

Uncommenting "users << users_for_gid(entry.cn.first)" will cause the loop to occur again


Related issues

Is duplicate of Foreman - Bug #13608: LDAP Authentication failure: stack level too deepClosed2016-02-08

History

#1 Updated by Dominic Cleal over 6 years ago

  • Description updated (diff)
  • Category set to Authentication
  • Status changed from New to Need more information

Could you please try with a current version? ldap_fluff 0.3.2 is old and a few group lookup bugs have been fixed since.

#2 Updated by Anonymous about 5 years ago

  • Status changed from Need more information to Resolved

no reaction, closing. I can't access that BZ.

#3 Updated by Marek Hulán about 5 years ago

  • Status changed from Resolved to Duplicate

Sorry for that, it was closed as dup of #13608

#4 Updated by Marek Hulán about 5 years ago

  • Is duplicate of Bug #13608: LDAP Authentication failure: stack level too deep added

Also available in: Atom PDF