Bug 1302345
| Summary: | LDAP authentication has no base DN without groups from LDAP | ||
|---|---|---|---|
| Product: | Red Hat CloudForms Management Engine | Reporter: | Martin Welk <mwelk> |
| Component: | Appliance | Assignee: | Joe Vlcek <jvlcek> |
| Status: | CLOSED ERRATA | QA Contact: | amogh <amavinag> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 5.5.0 | CC: | abellott, cpelland, jhardy, jvlcek, obarenbo, simaishi, sshveta |
| Target Milestone: | GA | ||
| Target Release: | 5.7.0 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | ldap | ||
| Fixed In Version: | 5.7.0.0 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-01-04 12:54:21 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: | |||
Assigning to add test case New commit detected on ManageIQ/manageiq/master: https://github.com/ManageIQ/manageiq/commit/83755dfff1136f6dcb38fe076ae0a0835c0aec81 commit 83755dfff1136f6dcb38fe076ae0a0835c0aec81 Author: Joe VLcek <jvlcek> AuthorDate: Wed Apr 27 15:04:42 2016 -0400 Commit: Joe VLcek <jvlcek> 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(-) This is in upstream master, but NOT backported to Darga (per Gregg Tanzillo). 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 JoeV, As per our discussion, this looks ok to me. marking this ticket as verified in "5.7.0.4-alpha1.20161005153002_cfc8a23". 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 |
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