RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1781799 - ipa-client-install towards RHEL7.6 IPA server is failing
Summary: ipa-client-install towards RHEL7.6 IPA server is failing
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: ipa
Version: 8.1
Hardware: Unspecified
OS: Unspecified
urgent
urgent
Target Milestone: rc
: 8.0
Assignee: Thomas Woerner
QA Contact: ipa-qe
URL:
Whiteboard:
Depends On: 1788572
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-12-10 15:41 UTC by mpanaous
Modified: 2023-09-07 21:13 UTC (History)
19 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-04-28 15:44:12 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
Untested patch for OpenLDAP (5.93 KB, patch)
2020-01-10 17:44 UTC, Christian Heimes 		no flags Details | Diff
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker FREEIPA-8195 0 None None None 2022-04-25 23:27:55 UTC
Red Hat Issue Tracker RHELPLAN-31822 0 None None None 2022-04-25 23:22:50 UTC
Red Hat Knowledge Base (Solution) 4783381 0 None None None 2020-02-20 13:08:20 UTC
Red Hat Product Errata RHEA-2020:1640 0 None None None 2020-04-28 15:44:32 UTC

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
Note You need to log in before you can comment on or make changes to this bug.