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.
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
yair - anything preventing doing this today?
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
(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.
This will be solved only for generic LDAP provider (Bug 1083736)
new ldap implementation supports ldap with startTLS and ldap over SSL. we need environment to test the exact configuration.
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