LDAP Bind failing because of SSLHandshakeException after Virtualization Manager was rebooted
After moving and rebooting our Red Hat Virtualization Manager box to another node in our cluster, we are unable to make LDAP login work using StartTLS. No networking or configuration changes were made, but the logs indicate that the TLS negotiation is failing with our Active Directory domain controllers now. Specifically: "2018-11-13 10:33:12,500-05 WARN [org.ovirt.engineextensions.aaa.ldap.Framework] (ServerService Thread Pool -- 49) [] Exception: The connection reader was unable to successfully complete TLS negotiation: SSLHandshakeException(sun.security.validator.ValidatorException: No trusted certificate found), ldapSDKVersion=4.0.5, revision=b28fb50058dfe2864171df2448ad2ad2b4c2ad58" I have tried everything I can think of. I removed and reimported the certificate for the domain controller in the Java Keystore. I deleted the profile entirely and recreated it. I tried using the full certificate chain and I tried using single certificates from the chain, and all combinations together. For now, we have it working by specifying "pool.default.ssl.insecure = true" in the .properties file, but I'd prefer to have this working again using StartTLS. Is there something I am missing? I want to make sure that I'm not overlooking something before submitting any sort of bug report. Any help is appreciated. Thanks! PS - this is what the properties file looks like: [root@rhvm ~]# cat /etc/ovirt-engine/aaa/liberty.edu.properties include = <ad.properties> vars.domain = liberty.edu vars.user = cn=PREADER,ou=Service Accounts,ou=IS,OU=FSA,dc=University,dc=liberty,dc=edu vars.password = <redacted> pool.default.auth.simple.bindDN = ${global:vars.user} pool.default.auth.simple.password = ${global:vars.password} pool.default.serverset.type = srvrecord pool.default.serverset.srvrecord.domain = ${global:vars.domain} pool.default.ssl.startTLS = true pool.default.ssl.truststore.file = ${local:_basedir}/liberty.edu.jks
So, it turns out that one of the domain controllers had a different certificate chain (outside of my team's control) which was inexplicably causing the whole thing to fail. I would run "ovirt-engine-extensions-tool --log-level=FINEST --log-file=/tmp/aaa.log aaa login-user --user-name=preader@liberty.edu --profile=liberty.edu" and everything would look fine up until the point that it needed to "doFetchPrincipalRecord", at which point it would fail to get the principal record for the account. The bind would succeed, but because "Creating LDAPConnectionPool" would fail on *just one* of the domain controllers, it for some reason seemed to invalidate all of the entries in that pool, thereby causing the fetching of principal records to fail even though the bind succeeded on one of the OK domain controllers. Is this behavior intended? I really think this should be classified as a bug. For what it's worth, this was resolved by getting the certificate chain from the problem DC and then adding it to the Java Keystore with the other certificate chain that all the other domain controllers use.
On 11/13/18 10:09 PM, Will Hegedus wrote:
So, it turns out that one of the domain controllers had a different certificate chain (outside of my team's control) which was inexplicably causing the whole thing to fail.
I would run "ovirt-engine-extensions-tool --log-level=FINEST --log-file=/tmp/aaa.log aaa login-user --user-name=preader@liberty.edu --profile=liberty.edu" and everything would look fine up until the point that it needed to "doFetchPrincipalRecord", at which point it would fail to get the principal record for the account. The bind would succeed, but because "Creating LDAPConnectionPool" would fail on *just one* of the domain controllers, it for some reason seemed to invalidate all of the entries in that pool, thereby causing the fetching of principal records to fail even though the bind succeeded on one of the OK domain controllers.
Is this behavior intended? I really think this should be classified as a bug.
For what it's worth, this was resolved by getting the certificate chain from the problem DC and then adding it to the Java Keystore with the other certificate chain that all the other domain controllers use.
Please open a bug will detail information of the AD infrastructure, like what's the forest what's the domains, and which DC are in domain, and I will try to take a look. Thanks a lot!
_______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/ZCQPBSP4HW35JN...
participants (3)
-
Ondra Machacek -
wbhegedus＠gmail.com -
Will Hegedus