Bug 1880149

Summary: Fails to connect to LDAP server after upgrade to 1.4.1
Product: [oVirt] ovirt-engine-extension-aaa-ldap Reporter: Rik Theys <rik.theys>
Component: CoreAssignee: Martin Perina <mperina>
Status: CLOSED CURRENTRELEASE QA Contact: Petr Matyáš <pmatyas>
Severity: high Docs Contact:
Priority: high    
Version: 1.4.1CC: 47b13, aoconnor, bugs, mmartinv, redhat.bugzilla
Target Milestone: ovirt-4.4.3Flags: pm-rhel: ovirt-4.4+
aoconnor: blocker-
Target Release: 1.4.2   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: ovirt-engine-extension-aaa-ldap-1.4.2 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-11-13 14:48:05 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:

Description Rik Theys 2020-09-17 19:23:23 UTC
Description of problem:
After upgrading to ovirt-engine 4.4.2, I can no longer login on the admin portal. This upgrade pulled in ovirt-engine-extension-aaa-ldap.noarch 1.4.1-1.el8.

The log shows:

2020-09-17 20:39:57,638+02 ERROR [org.ovirt.engine.core.sso.servlets.InteractiveAuthServlet] (default task-1) [] Internal Server Error: An error occurred while attempting to connect to server ldap.esat.kuleuven.be:389:  IOException(LDAPException(resultCode=91 (connect error), errorMessage='An error occurred while attempting to establish a connection to server ldap.esat.kuleuven.be/10.86.18.10:389:  SocketException(Network is unreachable (connect failed)), ldapSDKVersion=4.0.14, revision=c0fb784eebf9d36a67c736d0428fb3577f2e25bb'))                                                      
2020-09-17 20:39:57,638+02 ERROR [org.ovirt.engine.core.sso.utils.SsoUtils] (default task-1) [] An error occurred while attempting to connect to server ldap.esat.kuleuven.be:389:  IOException(LDAPException(resultCode=91 (connect error), errorMessage='An error occurred while attempting to establish a connection to server ldap.esat.kuleuven.be/10.86.18.10:389:  SocketException(Network is unreachable (connect failed)), ldapSDKVersion=4.0.14, revision=c0fb784eebf9d36a67c736d0428fb3577f2e25bb'))                                                                                              
2020-09-17 20:39:57,648+02 ERROR [org.ovirt.engine.core.aaa.servlet.SsoPostLoginServlet] (default task-1) [] server_error: An error occurred while attempting to connect to server ldap.esat.kuleuven.be:389:  IOException(LDAPException(resultCode=91 (connect error), errorMessage='An error occurred while attempting to establish a connection to server ldap.esat.kuleuven.be/10.86.18.10:389:  SocketException(Network is unreachable (connect failed)), ldapSDKVersion=4.0.14, revision=c0fb784eebf9d36a67c736d0428fb3577f2e25bb'))                                                                   

But the server is reachable and the log on the LDAP server shows a connection:

Sep 17 20:39:57 ldap1 slapd[1099]: conn=1506817 fd=118 ACCEPT from IP=10.86.19.2:47502 (IP=0.0.0.0:389)
Sep 17 20:39:57 ldap1 slapd[1099]: conn=1506817 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Sep 17 20:39:57 ldap1 slapd[1099]: conn=1506817 op=0 STARTTLS
Sep 17 20:39:57 ldap1 slapd[1099]: conn=1506817 op=0 RESULT oid= err=0 text=
Sep 17 20:39:57 ldap1 slapd[1099]: conn=1506817 fd=118 TLS established tls_ssf=256 ssf=256
Sep 17 20:39:57 ldap1 slapd[1099]: conn=1506817 op=1 BIND dn="" method=128
Sep 17 20:39:57 ldap1 slapd[1099]: conn=1506817 op=1 RESULT tag=97 err=0 text=
Sep 17 20:39:57 ldap1 slapd[1099]: conn=1506817 fd=118 closed (connection lost)

This setup has worked for a long time, and downgrading back to 1.4.0 allows me to login again.

My AAA properties file has:

include = <rfc2307-openldap.properties>

vars.server = ldap.esat.kuleuven.be

pool.authz.auth.type = none
pool.default.serverset.type = single
pool.default.serverset.single.server = ${global:vars.server}
pool.default.ssl.startTLS = true
pool.default.ssl.truststore.file = ${local:_basedir}/esat.kuleuven.be.jks
pool.default.ssl.truststore.password = changeit

From the changelog I see that 1.4.1 brings in IPv6 support? Our ldap server has an IPv6 address, but my engine does not have an IPv6 address, so it should use IPv4 instead. Maybe that's the reason for the unreachable message?

Version-Release number of selected component (if applicable):
ovirt-engine-extension-aaa-ldap.noarch 1.4.1-1.el8

How reproducible:
Always for me

Steps to Reproduce:
1. Have an aaa ldap setup with an engine that only has IPv4 connectivity to an ldap server that has both an ipv6 and ipv4 address
2. Upgrade to 1.4.1
3.

Actual results:
Fails to connect and can not login

Expected results:
Can login as expected

Additional info:

Comment 1 Rik Theys 2020-09-17 19:37:37 UTC
Hi,

When I add the following line to my /etc/ovirt-engine/aaa/esat.kuleuven.be.properties file, I can login again:

pool.default.socketfactory.resolver.supportIPv6 = false

This basically reverts the IPv6 change I assume.

So the IPv6 support seems to be broken when the ldap server resolves to (both) an IPv6 address (and IPv4 address), but the ovirt-engine host only has IPv4 connectivity.

Regards,
Rik

Comment 2 Nathaniel Roach 2020-10-17 14:09:17 UTC
I can confirm it's done the same thing to me, although confusingly only after upgrading both IPA hosts and then doing a complete restart of the oVirt cluster. The last time I updated oVirt was a few weeks back and I restarted the engine afterwards.

Both IPA servers have both IPv4 and v6 records published.

The same fix has resolved it for me.

Comment 3 Martin Perina 2020-10-25 20:06:54 UTC
*** Bug 1887458 has been marked as a duplicate of this bug. ***

Comment 5 Petr Matyáš 2020-11-11 12:17:40 UTC
Verified on ovirt-engine-extension-aaa-ldap-1.4.2-1.el8ev.noarch (4.4.3) upgraded from ovirt-engine-extension-aaa-ldap-1.4.0-1.el8ev.noarch (4.4.1)

Comment 6 Sandro Bonazzola 2020-11-13 14:48:05 UTC
This bugzilla is included in oVirt 4.4.3 release, published on November 10th 2020.

Since the problem described in this bug report should be resolved in oVirt 4.4.3 release, it has been closed with a resolution of CURRENT RELEASE.

If the solution does not work for you, please open a new bug report.