Bug 1306436

Summary: OpenLDAP proxy to 3 different domains
Product: Red Hat CloudForms Management Engine Reporter: Jared Deubel <jdeubel>
Component: ApplianceAssignee: abellott
Status: CLOSED WORKSFORME QA Contact: Matt Pusateri <mpusater>
Severity: urgent Docs Contact:
Priority: high    
Version: 5.5.0CC: abellott, bascar, brjohnso, cpelland, gblomqui, jdeubel, jhardy, jvlcek, obarenbo
Target Milestone: GA   
Target Release: 5.7.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: ldap
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-03-17 14:22:38 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:
Attachments:
Description Flags
multi-ldap/active direcotry SSSD none

Description Jared Deubel 2016-02-10 21:04:18 UTC
Description of problem:
Trying to OpenLDAP Proxy to 3 different domains.  samaccountname and passwords are being cached and passing domain isn't going to work.  CFME is passing '\username' to LDAP and it isn't authenticating.  

We were able to reproduce this issue.  In the log User [ ... ]  we put   domainprefix\userid,  so when we log in to AD, We see  domain\userid,  if we clean the domain prefix, I see \userid and cannot login. The problem seems to be that you probably have the domain prefix empty. Can you check Configure->Authentication->Domain Prefix, that should have their domain prefix (no \'s).

Snippet from evm.log
================================================================================
[----] I, [2016-01-27T14:08:55.743488 #15418:1189998]  INFO -- : MIQ(MiqLdap#bind) Binding to LDAP: Host: [10.10.10.1], User: [\user]...
[----] W, [2016-01-27T14:08:55.753992 #15418:1189998]  WARN -- : MIQ(MiqLdap#bind) Binding to LDAP: Host: [10.10.10.1], User: [\user]... unsuccessful
[----] W, [2016-01-27T14:08:55.769144 #15418:1189998]  WARN -- : <AuditFailure> MIQ(Authenticator.authenticate) userid: [user] - Authentication failed for userid \user
[----] W, [2016-01-27T14:08:55.769288 #15418:1189998]  WARN -- : MIQ(Authenticator::Ldap#authenticate) Authentication failed
[----] E, [2016-01-27T14:08:55.769634 #15418:1189998] ERROR -- : MIQ(dashboard_controller-authenticate): Sorry, the username or password you entered is incorrect.
================================================================================

Version-Release number of selected component (if applicable):
5.5.0.13,

Comment 2 abellott 2016-02-12 18:16:10 UTC
Initially attempted to resolve with MiqLdap, but we could not even bind to
the OpenLdap proxy with just the samaccountname (no \).

This authentication scenario was resolved by leveraging the External Authentication (httpd/apache) mechanism supported by CloudForms.

In the environment, the OpenLdap proxy was removed from the CloudForms solution and the Linux/SSSD was configured to authenticate directly with the Active Directory domains. 

Since a service account with entitlements to join a domain was not an option, we could not base the configuration process based on https://github.com/ManageIQ/manageiq_docs/blob/master/auth/active_directory.adoc with realm discover/join. We needed to leverage the more involved https://github.com/ManageIQ/manageiq_docs/blob/master/auth/ldap.adoc but manually configuring the sssd domains against AD using the ldap directives.

With the approach taken, one could login to CloudForms with the fully qualified userid@domain reflecting the specific AD domain, we could also query the groups of users within CloudForms using the same userid@domain syntax for username.

So, no code change was needed to get this to work.

We need to add a configuration scenario in https://github.com/ManageIQ/manageiq_docs/blob/master/auth/ for LDAP external auth to one or more AD domains for documenting the above.

Comment 3 Brandon Johnson 2016-02-17 14:49:08 UTC
Created attachment 1127962 [details]
multi-ldap/active direcotry SSSD

Comment 8 Joe Vlcek 2017-03-17 14:22:38 UTC
Closing per Brandon Johnson's comment indicating this can be closed.

If it is felt this should not be closed please reopen and provide more details.

Thank you,

JoeV