Bug 963936

Summary:	PRD35 - [RFE][AAA] Support for "hardened" AD environments with RHEV
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	Allie DeVolder <adevolder>
Component:	ovirt-engine-extension-aaa-ldap	Assignee:	Alon Bar-Lev <alonbl>
Status:	CLOSED ERRATA	QA Contact:	Ondra Machacek <omachace>
Severity:	high	Docs Contact:
Priority:	high
Version:	3.1.0	CC:	aberezin, adevolder, alonbl, bazulay, iheim, jraju, juan.hernandez, juwu, lpeer, oourfali, pstehlik, rbalakri, Rhev-m-bugs, sherold, talayan, yzaslavs
Target Milestone:	---	Keywords:	FutureFeature, Improvement
Target Release:	3.5.0	Flags:	aberezin: Triaged+
Hardware:	All
OS:	Linux
Whiteboard:	infra
Fixed In Version:	ovirt-engine-3.5.0_rc1	Doc Type:	Enhancement
Doc Text:	The new LDAP provider ovirt-engine-extension-aaa-ldap fully supports SSL/TLS and startTLS protocols.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-02-11 18:12:25 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Infra	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1090515
Bug Blocks:	1063095, 1142923, 1156165

Description Allie DeVolder 2013-05-16 19:40:38 UTC

Customer needs the ability to connect RHEV to AD servers that have been "hardened" as per DoD specifications. This means that communication must occur over SSL or TLS.

Comment 2 Allie DeVolder 2013-05-16 19:46:08 UTC

Here's an example of what is returned when attempting to connect to a hardened AD:

# rhevm-manage-domains -action=add -domain=some.domain.everywhere.net -provider=ActiveDirectory -user=adminguy -interactive

General error has occured[LDAP: error code 8 - 00002028: LdapErr: DSID-0C09018A, comment: The server requires binds to turn on integrity checking if SSL\TLS are not already active on the connection, data 0, vece]
javax.naming.AuthenticationNotSupportedException: [LDAP: error code 8 - 00002028: LdapErr: DSID-0C09018A, comment: The server requires binds to turn on integrity checking if SSL\TLS are not already active on the connection, data 0, vece]
        at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3078)
        at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:3033)
        at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2835)
        at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2749)
        at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:316)
        at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:193)
        at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:211)
        at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:154)
        at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:84)
        at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
        at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:307)
        at javax.naming.InitialContext.init(InitialContext.java:242)
        at javax.naming.InitialContext.<init>(InitialContext.java:216)
        at javax.naming.directory.InitialDirContext.<init>(InitialDirContext.java:101)
        at org.ovirt.engine.core.utils.kerberos.JndiAction.run(JndiAction.java:83)
        at java.security.AccessController.doPrivileged(Native Method)
        at javax.security.auth.Subject.doAs(Subject.java:356)
        at org.ovirt.engine.core.utils.kerberos.KerberosConfigCheck.promptSuccessfulAuthentication(KerberosConfigCheck.java:193)
        at org.ovirt.engine.core.utils.kerberos.KerberosConfigCheck.validateKerberosInstallation(KerberosConfigCheck.java:169)
        at org.ovirt.engine.core.utils.kerberos.KerberosConfigCheck.checkInstallation(KerberosConfigCheck.java:154)
        at org.ovirt.engine.core.utils.kerberos.ManageDomains.checkKerberosConfiguration(ManageDomains.java:663)
        at org.ovirt.engine.core.utils.kerberos.ManageDomains.testConfiguration(ManageDomains.java:814)
        at org.ovirt.engine.core.utils.kerberos.ManageDomains.addDomain(ManageDomains.java:483)
        at org.ovirt.engine.core.utils.kerberos.ManageDomains.runCommand(ManageDomains.java:290)
        at org.ovirt.engine.core.utils.kerberos.ManageDomains.main(ManageDomains.java:171)
Failure while testing domain iwslin.nswc.navy.mil. Details: No user information was found for user

Comment 3 Itamar Heim 2013-05-17 07:15:03 UTC

yair - anything preventing doing this today?

Comment 4 Yair Zaslavsky 2013-05-19 06:15:35 UTC

From what Alon has stated, looks like we will have to add transport type support (i.e - still work with Kerberos but have SSL/TLS transport type).
Need to check if at the code this is only about changing the PROVIDER_URL property

Comment 5 Alon Bar-Lev 2013-05-19 10:08:35 UTC

(In reply to comment #4)
> From what Alon has stated, looks like we will have to add transport type
> support (i.e - still work with Kerberos but have SSL/TLS transport type).
> Need to check if at the code this is only about changing the PROVIDER_URL
> property

Well, for active directory this may be sufficient, but it would really great if we can support startTLS at the same effort.

Comment 11 Barak 2014-04-29 14:33:23 UTC

This will be solved only for generic LDAP provider (Bug 1083736)

Comment 12 Alon Bar-Lev 2014-06-11 14:00:40 UTC

new ldap implementation supports ldap with startTLS and ldap over SSL. we need environment to test the exact configuration.

Comment 17 errata-xmlrpc 2015-02-11 18:12:25 UTC

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/RHEA-2015-0174.html