Bug 963936 - PRD35 - [RFE][AAA] Support for "hardened" AD environments with RHEV
Summary: PRD35 - [RFE][AAA] Support for "hardened" AD environments with RHEV
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-extension-aaa-ldap
Version: 3.1.0
Hardware: All
OS: Linux
high
high
Target Milestone: ---
: 3.5.0
Assignee: Alon Bar-Lev
QA Contact: Ondra Machacek
URL:
Whiteboard: infra
Depends On: 1090515
Blocks: oVirt-AAA-LDAP rhev3.5beta 1156165
TreeView+ depends on / blocked
 
Reported: 2013-05-16 19:40 UTC by Allie DeVolder
Modified: 2019-04-28 09:47 UTC (History)
16 users (show)

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.
Clone Of:
Environment:
Last Closed: 2015-02-11 18:12:25 UTC
oVirt Team: Infra
Target Upstream Version:
Embargoed:
aberezin: Triaged+


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2015:0174 0 normal SHIPPED_LIVE new package: ovirt-engine-extension-aaa-ldap 2015-02-11 22:40:02 UTC

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


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