Bug 1404114

Created attachment 1231069 [details]
Success authentication

LDAPsearch on Failed Group
—————————————————————————-
$ /opt/quest/bin/ldapsearch -s sub '(&(objectclass=group)(samaccountname=Role-unix_admin))' '&((samaccountname)(uid))' '*'
# extended LDIF
#
# LDAPv3
# base <> with scope subtree
# filter: (&(objectclass=group)(samaccountname=Role-unix_admin))
# requesting: &((samaccountname)(uid)) * 
# with pagedResults control: size=500
#

dn: CN=Role-Unix_Admin,OU=Role Groups,OU=Delegation Groups,OU=Admin,DC=alinta,DC=net,DC=int
objectClass: top
objectClass: group
cn: Role-Unix_Admin
description: Provides login access to all Unix Servers in AD


Foreman Tail on failed group add
————————————————————————————————
==> /var/log/httpd/foreman-ssl_access_ssl.log <==
10.157.14.131 - - [13/Dec/2016:13:16:26 +1100] "POST /usergroups HTTP/1.1" 200 1846 "https://10.157.30.58/usergroups" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.98 Safari/537.36"

==> /var/log/httpd/foreman-ssl_error_ssl.log <==
[Tue Dec 13 13:16:26.722166 2016] [ssl:warn] [pid 4472] [client 10.157.14.131:32994] AH02227: Failed to set r->user to 'SSL_CLIENT_S_DN_CN', referer: https://10.157.30.58/usergroups

==> /var/log/foreman/production.log <==
2016-12-13 13:16:26 [app] [I] Started POST "/usergroups" for 10.157.14.131 at 2016-12-13 13:16:26 +1100
2016-12-13 13:16:26 [app] [I] Processing by UsergroupsController#create as */*
2016-12-13 13:16:26 [app] [I]   Parameters: {"utf8"=>"✓", "authenticity_token"=>"77Hj4JwHpewWu1Yvjzoww7aYn2qlDdbxoh5JK8EQEd8=", "usergroup"=>{"name"=>"Test", "user_ids"=>["", "", ""], "admin"=>"1", "role_ids"=>[""], "external_usergroups_attributes"=>{"new_1481595222832"=>{"_destroy"=>"1", "name"=>"", "auth_source_id"=>"3"}, "new_1481595229117"=>{"_destroy"=>"false", "name"=>"Role-Unix_Admin", "auth_source_id"=>"3"}}}}
2016-12-13 13:16:26 [app] [I] Failed to save: Name is not found in the authentication source              <<<<<<<<<<<--------ERROR MESSAGE
2016-12-13 13:16:26 [app] [I]   Rendered common/_edit_habtm.html.erb (0.3ms)
2016-12-13 13:16:26 [app] [I]   Rendered common/_edit_habtm.html.erb (3.4ms)
2016-12-13 13:16:26 [app] [I]   Rendered usergroups/_external.html.erb (2.5ms)
2016-12-13 13:16:26 [app] [I]   Rendered usergroups/_external.html.erb (2.2ms)
2016-12-13 13:16:26 [app] [I]   Rendered usergroups/_form.html.erb (28.9ms)
2016-12-13 13:16:26 [app] [I]   Rendered usergroups/new.html.erb (29.5ms)
2016-12-13 13:16:26 [app] [I] Completed 200 OK in 125ms (Views: 27.5ms | ActiveRecord: 7.2ms)


LDAPsearch on Successful Group
——————————————————————————————
$ /opt/quest/bin/ldapsearch -s sub '(&(objectclass=group)(samaccountname=ACL_Resource_Managers_WOL))' '&((samaccountname)(uid))' '*'
# extended LDIF
#
# LDAPv3
# base <> with scope subtree
# filter: (&(objectclass=group)(samaccountname=ACL_Resource_Managers_WOL))
# requesting: &((samaccountname)(uid)) * 
# with pagedResults control: size=500
#

dn: CN=ACL_Resource_Managers_WOL,OU=Permission,OU=Groups,OU=Client,DC=alinta,DC=net,DC=int
objectClass: top
objectClass: group
cn: ACL_Resource_Managers_WOL
description: Members can manage Wollongong resources

Foreman Tail on Successful Group Add
————————————————————————————————————
==> /var/log/httpd/foreman-ssl_error_ssl.log <==
[Tue Dec 13 13:25:49.232545 2016] [ssl:warn] [pid 4476] [client 10.157.14.131:33702] AH02227: Failed to set r->user to 'SSL_CLIENT_S_DN_CN', referer: https://10.157.30.58/usergroups

==> /var/log/foreman/production.log <==
2016-12-13 13:25:49 [app] [I] Started POST "/usergroups" for 10.157.14.131 at 2016-12-13 13:25:49 +1100
2016-12-13 13:25:49 [app] [I] Processing by UsergroupsController#create as */*
2016-12-13 13:25:49 [app] [I]   Parameters: {"utf8"=>"✓", "authenticity_token"=>"77Hj4JwHpewWu1Yvjzoww7aYn2qlDdbxoh5JK8EQEd8=", "usergroup"=>{"name"=>"Test", "user_ids"=>["", "", ""], "admin"=>"1", "role_ids"=>[""], "external_usergroups_attributes"=>{"new_1481595928216"=>{"_destroy"=>"false", "name"=>"ACL_Resource_Managers_WOL", "auth_source_id"=>"3"}}}}
2016-12-13 13:25:49 [app] [I] Redirected to https://10.157.30.58/usergroups

==> /var/log/httpd/foreman-ssl_access_ssl.log <==
10.157.14.131 - - [13/Dec/2016:13:25:49 +1100] "POST /usergroups HTTP/1.1" 302 97 "https://10.157.30.58/usergroups" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.98 Safari/537.36"
10.157.14.131 - - [13/Dec/2016:13:25:49 +1100] "GET /usergroups HTTP/1.1" 200 5196 "https://10.157.30.58/usergroups" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.98 Safari/537.36"

==> /var/log/httpd/foreman-ssl_error_ssl.log <==
[Tue Dec 13 13:25:49.818059 2016] [ssl:warn] [pid 4476] [client 10.157.14.131:33702] AH02227: Failed to set r->user to 'SSL_CLIENT_S_DN_CN', referer: https://10.157.30.58/usergroups

==> /var/log/foreman/production.log <==
2016-12-13 13:25:49 [app] [I] Completed 302 Found in 571ms (ActiveRecord: 6.7ms)
2016-12-13 13:25:49 [app] [I] Started GET "/usergroups" for 10.157.14.131 at 2016-12-13 13:25:49 +1100
2016-12-13 13:25:49 [app] [I] Processing by UsergroupsController#index as */*
2016-12-13 13:25:49 [app] [I]   Rendered usergroups/index.html.erb within layouts/application (9.5ms)
2016-12-13 13:25:49 [app] [I]   Rendered common/_searchbar.html.erb (2.8ms)
2016-12-13 13:25:49 [app] [I]   Rendered layouts/_application_content.html.erb (3.4ms)
2016-12-13 13:25:49 [app] [I]   Rendered home/_submenu.html.erb (1.4ms)
2016-12-13 13:25:49 [app] [I]   Rendered home/_user_dropdown.html.erb (1.4ms)
2016-12-13 13:25:49 [app] [I] Read fragment views/tabs_and_title_records-3 (0.2ms)
2016-12-13 13:25:49 [app] [I]   Rendered home/_topbar.html.erb (4.1ms)
2016-12-13 13:25:49 [app] [I]   Rendered layouts/base.html.erb (5.9ms)
2016-12-13 13:25:49 [app] [I] Completed 200 OK in 32ms (Views: 18.8ms | ActiveRecord: 3.3ms)

Hello,

I just reproduced this on my system. According to RFB 2254 (http://www.faqs.org/rfcs/rfc2254.html), you are supposed 
to escape the value part of a filter using few escape codes. In our use case it is space which is \0x32 or \20. But this will not work, we need to call Filter::from_rfc2254 in the ldap_fluff library in order to enable these escape sequences to be passed in LDAP correctly.

I will work on the patch on Monday.

http://osdir.com/ml/lang-ruby-ldap/2011-03/msg00016.html

Hi all,

Thanks for your attention and assistance with this.

I just wanted to mention that this appears to be similar to another bug, 1387093 which had similar issues with spaces (although that was in the login name as opposed to the DN path).

Once the patch is finalised I would be interested to see if it resolved that problem too.

Thanks

Shane

Can you enable the ldap logger and restart httpd to see what's happening exactly? 

To do so, add the following to /etc/foreman/settings.yaml : 

:loggers:
  :ldap:
    :enabled: true


Please try to reproduce the issue after that and paste the logs, so we can know what is going on. Are there any filters on the LDAP authentication source? I'm trying using a group base DN with spaces ("OU=Groups with spaces") and I get the users in the group successfully:


2016-12-20T13:36:45 [ldap] [D]   op search (2.1ms)  [ filter=(cn=dbz heroes), base=OU=Groups with spaces,DC=lobatolan,DC=home ]
2016-12-20T13:36:45 [ldap] [D]   op search (2.3ms)  [ filter=(cn=dbz heroes), base=OU=Groups with spaces,DC=lobatolan,DC=home ]
2016-12-20T13:36:45 [ldap] [D]   op search (2.6ms)  [ filter=(CN=goku), base=CN=Users,DC=lobatolan,DC=home ]
2016-12-20T13:36:45 [ldap] [D]   user_list (9.6ms)  [ group=dbz heroes ]

Also could you run 'rpm -qi tfm-rubygem-ldap_fluff' to check what version of ldap_fluff (the gem that does all the ldap queries) is the customer using? I'm trying to reproduce this with 0.4.3 as per https://access.redhat.com/downloads/content/250/ver=6.2/rhel---7/6.2.4/x86_64/packages

Also, both setups in my case Sat6.2.3 and sat6.2.4 use the "0.4.3" version of "tfm-rubygem-ldap_fluff" package.

We had a Bomgar session with the customer today (David Joo, Amit Kumar and myself). The customer is using ldap_fluff 0.4.3. At first we tried a few simple things via foreman-rake console:

calling `.test` on each of the AuthSourceLdap (one with spaces on base DN another without) - success
calling `.valid_group?` on each of the AuthSourceLdap for groups known to exist in each - success
calling `.group_list` on each of the AuthSourceLdap for groups known to exist in each source - success, it returned a list of users in the group.

These are essentially the checks Satellite 6 does when you refresh or add an external user group, so at that point we decided to go to the Satellite 6 UI and try it out.

The external user group was detected just fine (using the LDAP Auth Source with spaces in the Group DN). However, they didn't have any users to test it with. We created a user known to exist in that group through the console, and assigned it that auth source.

After that, we clicked on refresh and the user was added to the user group automatically. 

We checked twice, deleting and recreating the user group, it worked well. Customer is fine with us closing the bug, as it works now (expected, as 3 people in this BZ tried to reproduce it without success).

Maybe there were not using 0.4.3 originally, although this comment shows https://bugzilla.redhat.com/show_bug.cgi?id=1404114#c21 they have it, and the changes in 0.4.3 shouldn't affect this bug at all. I don't think we did anything new to fix it.

Why did it not work before? 2 guesses:

1. Problems on the AD side of things, misconfiguration, and whatnot
2. Human error in the configuration?

Anyhow, the bug can be closed (customer said OK to that) and the customer is able to use LDAP as they want now.

*** Bug 1268253 has been marked as a duplicate of this bug. ***