Bug 1302345 - LDAP authentication has no base DN without groups from LDAP
LDAP authentication has no base DN without groups from LDAP
Status: CLOSED ERRATA
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Appliance (Show other bugs)
5.5.0
Unspecified Unspecified
unspecified Severity unspecified
: GA
: 5.7.0
Assigned To: Joe Vlcek
amogh
ldap
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-01-27 09:36 EST by Martin Welk
Modified: 2017-01-04 07:54 EST (History)
7 users (show)

See Also:
Fixed In Version: 5.7.0.0
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-01-04 07:54:21 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Martin Welk 2016-01-27 09:36:53 EST
Description of problem:
If you configure CFME to authenticate against an LDAP server, it won't work unless you also enable  "Get User Groups from LDAP". When you just need authentication, and leave "Get User Groups..." unchecked, even authentication doesn't work.

Version-Release number of selected component (if applicable):
5.5.0.13.20151201120956_653c0d4 

How reproducible:
100%

Steps to Reproduce:
1. Go to Configure -> Configuration - Authentication
2. Set some LDAP host name, LDAP port, User Type etc.
3. Make sure "Get User Groups from LDAP" is unchecked
4. Set log level to info
5. Try to logon with an LDAP user. In the evm.log you see, the bind request to the LDAP fails.
6. Check "Get User Groups from LDAP"
7. Enter a base DN
8. Try to logon with an LDAP user. In the evm.log you see the bind request is successful.

Actual results:
Base DN is only visible and can only be set if "Get User Groups from LDAP" is checked

Expected results:
Base DN should always be visible and should be part of the LDAP Settings, when it is always needed.

Additional info:

I am adding two log snippets, one for a failed request, one for the successful. It appears to me that CFME is trying to fetch groups even when it shouldn't, and if that happens, user authentication doesn't work either.

evm.log example without base DN set
[----] I, [2016-01-27T11:43:30.255088 #24266:e95994]  INFO -- : MIQ(MiqLdap#initialize) Server Settings: {:basedn=>nil, :bind_dn=>nil, :bind_pwd=>"********", :get_direct_groups=>true, :group_memberships_max_depth=>2, :ldaphost=>["edir.ed
vz.sbg.ac.at"], :ldapport=>"636", :mode=>"ldaps", :user_suffix=>"ou=staff,ou=employee,ou=users,o=data", :user_type=>"dn-uid", :amazon_key=>nil, :amazon_secret=>"********", :ldap_role=>false, :amazon_role=>false, :httpd_role=>false, :user
_proxies=>[{}], :follow_referrals=>false, :sso_enabled=>false}
[----] I, [2016-01-27T11:43:30.264336 #24266:e95994]  INFO -- : MiqLdap.connection: Resolved host [edir.edvz.sbg.ac.at] has these IP Address: ["141.201.90.29"]
[----] I, [2016-01-27T11:43:30.264401 #24266:e95994]  INFO -- : MiqLdap.connection: Connecting to IP Address [141.201.90.29]
[----] I, [2016-01-27T11:43:30.265544 #24266:e95994]  INFO -- : options: {:host=>"141.201.90.29", :port=>"636", :auth=>{:basedn=>nil, :bind_dn=>nil, :bind_pwd=>nil, :get_direct_groups=>true, :group_memberships_max_depth=>2, :ldaphost=>["edir.edvz.sbg.ac.at"], :ldapport=>"636", :mode=>"ldaps", :user_suffix=>"ou=staff,ou=employee,ou=users,o=data", :user_type=>"dn-uid", :amazon_key=>nil, :amazon_secret=>nil, :ldap_role=>false, :amazon_role=>false, :httpd_role=>false, :user_proxies=>[{}], :follow_referrals=>false, :sso_enabled=>false}, :encryption=>{:method=>:simple_tls}}
[----] I, [2016-01-27T11:43:30.265629 #24266:e95994]  INFO -- : MIQ(MiqLdap#bind) Binding to LDAP: Host: [141.201.90.29], User: []...
[----] E, [2016-01-27T11:43:30.272652 #24266:e95994] ERROR -- : MIQ(MiqLdap#bind) Binding to LDAP: Host: [141.201.90.29], User: [], 'Invalid binding information'

evm.log example with base DN set

----] I, [2016-01-27T11:57:48.242350 #24266:e95994]  INFO -- : MIQ(MiqLdap#initialize) Server Settings: {:basedn=>"o=data", :bind_dn=>"cn=svc_cloudforms,ou=sa,o=data", :bind_pwd=>"********", :get_direct_groups=>false, :group_memberships
_max_depth=>2, :ldaphost=>["edir.edvz.sbg.ac.at"], :ldapport=>"636", :mode=>"ldaps", :user_suffix=>"ou=staff,ou=employee,ou=users,o=data", :user_type=>"dn-cn", :amazon_key=>nil, :amazon_secret=>"********", :ldap_role=>true, :amazon_role=
>false, :httpd_role=>false, :user_proxies=>[{}], :follow_referrals=>true, :sso_enabled=>false}
[----] I, [2016-01-27T11:57:48.250800 #24266:e95994]  INFO -- : MiqLdap.connection: Resolved host [edir.edvz.sbg.ac.at] has these IP Address: ["141.201.90.29"]
[----] I, [2016-01-27T11:57:48.250860 #24266:e95994]  INFO -- : MiqLdap.connection: Connecting to IP Address [141.201.90.29]
[----] I, [2016-01-27T11:57:48.251921 #24266:e95994]  INFO -- : options: {:host=>"141.201.90.29", :port=>"636", :auth=>{:basedn=>"o=data", :bind_dn=>"cn=svc_cloudforms,ou=sa,o=data", :bind_pwd=>"BEEEEEEEEEP", :get_direct_groups=>false
, :group_memberships_max_depth=>2, :ldaphost=>["edir.edvz.sbg.ac.at"], :ldapport=>"636", :mode=>"ldaps", :user_suffix=>"ou=staff,ou=employee,ou=users,o=data", :user_type=>"dn-cn", :amazon_key=>nil, :amazon_secret=>nil, :ldap_role=>true, 
:amazon_role=>false, :httpd_role=>false, :user_proxies=>[{}], :follow_referrals=>true, :sso_enabled=>false}, :encryption=>{:method=>:simple_tls}}
[----] I, [2016-01-27T11:57:48.252011 #24266:e95994]  INFO -- : MIQ(MiqLdap#bind) Binding to LDAP: Host: [141.201.90.29], User: [cn=b1001787,ou=staff,ou=employee,ou=users,o=data]...
[----] I, [2016-01-27T11:57:48.266694 #24266:e95994]  INFO -- : MIQ(MiqLdap#bind) Binding to LDAP: Host: [141.201.90.29], User: [cn=b1001787,ou=staff,ou=employee,ou=users,o=data]... successful
[----] I, [2016-01-27T11:57:48.273117 #24266:e95994]  INFO -- : <AuditSuccess> MIQ(Authenticator.authenticate) userid: [b1001787] - User cn=b1001787,ou=staff,ou=employee,ou=users,o=data successfully validated by LDAP
Comment 2 Shveta 2016-02-01 16:31:51 EST
Assigning to add test case
Comment 4 CFME Bot 2016-05-02 17:45:44 EDT
New commit detected on ManageIQ/manageiq/master:
https://github.com/ManageIQ/manageiq/commit/83755dfff1136f6dcb38fe076ae0a0835c0aec81

commit 83755dfff1136f6dcb38fe076ae0a0835c0aec81
Author:     Joe VLcek <jvlcek@redhat.com>
AuthorDate: Wed Apr 27 15:04:42 2016 -0400
Commit:     Joe VLcek <jvlcek@redhat.com>
CommitDate: Thu Apr 28 16:18:23 2016 -0400

    Find LDAP user in DB using userprincipalname
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1302345

 app/models/authenticator.rb                |  2 +-
 app/models/authenticator/ldap.rb           |  7 ++++++-
 spec/models/authenticator/ldap_spec.rb     | 11 +++++++++++
 spec/models/user/user_ldap_methods_spec.rb |  3 +++
 4 files changed, 21 insertions(+), 2 deletions(-)
Comment 5 Oleg Barenboim 2016-05-02 20:27:01 EDT
This is in upstream master, but NOT backported to Darga (per Gregg Tanzillo).
Comment 10 Joe Vlcek 2016-10-10 14:00:24 EDT
Amogh,

As you and I discussed in our meeting this bug is fixed as best as
can be. If the administrator decides to leave  "Get User Groups from LDAP"
uncheck then it is up to the administrator to manually create the
"username" that will be reported from LDAP,

e.g.:

Username uid=test,ou=people,ou=prod,dc=psavrocks,dc=com

To simplify the system administrators job and help them to avoid having
to manually create user with complex "Username"s they can use the
"Get User Groups from LDAP" option.

So I "think" this bug is verified. If you feel differently let me know.

It's a pleasure working with you through this and thank you!

JoeV
Comment 11 amogh 2016-10-12 10:39:28 EDT
JoeV, 
As per our discussion, this looks ok to me. marking this ticket as verified in "5.7.0.4-alpha1.20161005153002_cfc8a23".
Comment 13 errata-xmlrpc 2017-01-04 07:54:21 EST
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://rhn.redhat.com/errata/RHBA-2017-0012.html

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