Bug 1781799

Summary: ipa-client-install towards RHEL7.6 IPA server is failing
Product: Red Hat Enterprise Linux 8 Reporter: mpanaous
Component: ipaAssignee: Thomas Woerner <twoerner>
Status: CLOSED ERRATA QA Contact: ipa-qe <ipa-qe>
Severity: urgent Docs Contact:
Priority: urgent    
Version: 8.1CC: abokovoy, afarley, alsharma, cheimes, dpal, fcami, frenaud, gael.queri, ipa-maint, kludhwan, ksiddiqu, msauton, pasik, rcritten, rmarigny, tmihinto, tscherf, twoerner, vmishra
Target Milestone: rc   
Target Release: 8.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-04-28 15:44:12 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1788572    
Bug Blocks:    
Attachments:
Description Flags
Untested patch for OpenLDAP none

Comment 4 Florence Blanc-Renaud 2019-12-17 10:49:34 UTC 
The error 9 in ipa-join is linked to an error during keytab retrieval.
1. From the options provided, I can see that the enrollment is performed with a non-admin user (idm_enrollement.PHM.EDUCATION.GOUV.FR). Can you provide the Roles associated to this user?
$ ipa user-show idm_enrollement --all --raw

2. The server-side logs would also help (/var/log/httpd/error_log and /var/log/dirsrv/slapd-DOMAIN/access generated when ipa-client-install is run).
In order to properly diagnose, please note the date/time ipa-client-install is run and provide corresponding server logs.


The client install log also shows
LDAP Error: Anonymous access not allowed
Did the customer add custom ACIs or configure the master to prevent anonymous LDAP access?
Comment 11 Florence Blanc-Renaud 2020-01-10 13:52:31 UTC 
Hi,

there was a change in openldap that may explain the issue. Can you check the content of the LDAP server certificate?
On the master, run:
$ certutil -L -d /etc/dirsrv/slap-<domain> -n Server-Cert
and check if there are "Certificate Subject Alt Name" extensions.

The SAN extension must contain the hostname.

And on the client, check the version of openldap:
$ rpm -qa openldap

Before openldap-2.4.46-10.el8, the validation was falling back to the content of the CN field if there was no SAN extension matching the host name.
Since openldap-2.4.46-10.el8, the validation fails if there is no SAN extension matching the host name.
(see BZ https://bugzilla.redhat.com/show_bug.cgi?id=1740070 and https://bugzilla.redhat.com/show_bug.cgi?id=1788572).
Comment 12 Christian Heimes 2020-01-10 17:44:32 UTC 
Created attachment 1651344 [details]
Untested patch for OpenLDAP

This untested patch for OpenLDAP replaces the custom hostname verification code with OpenSSL 1.0.2 API calls to X509_check_host() and X509_check_ip().
Comment 13 Christian Heimes 2020-01-10 17:52:01 UTC 
We have further analyzed the issue and now feel confident that the issue is caused by a regression in openldap-2.4.46-10.el8. OpenDALP client libraries no longer fall back to Subject CN for hostname verification in case the server certificate contains only non-hostname subject alt name (SAN) entries. The hostname check should only skip the fallback in case one or more SAN entries are of type DNSName general name. In some cases IPA and AD include other SAN entries like Kerberos principal.
Comment 37 errata-xmlrpc 2020-04-28 15:44:12 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://access.redhat.com/errata/RHEA-2020:1640