Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
This request looks related to Bug 1271397, where IdM was requested to function as a meta directory, proxying authentication to other LDAPs. It was closed as WONTFIX with following reasoning:
~~~
[...]
Identity Management in RHEL cannot provide this capability by itself. It can provide the functionality partially, when IdM is in a Trust relationship with AD, AD users can authenticate via the LDAP compat tree (aiming legacy clients primarily):
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/trust-legacy.html#legacy-trust-conf-server
The use case of interfacing also with other LDAP server is not on our roadmap or planned use cases. There are other products or approaches (including OpenLDAP as reported) that can be used as a Meta Directory.
~~~
It applies for this RFE as well. What I would like to highlight is that if the other LDAP server is Active Directory, IdM has native means of interoperating it with it, whether with IdM AD Trusts (recommended) or User Synchronization (Winsync, no longer developed).
We have discussed this request again within IdM Engineering group and thought that it might be actually solved with existing IdM user External Authentication via RADIUS protocol. IdM on RHEL-7.1 or later supports OTP via native OTP tokens, but also external OTP tokens where it connects via RADIUS. This channel could be used for forwarding the authentication if Kerberos is used.
This solution requires both IdM server and client (SSSD) to be RHEL-7.1 or later, but if customer adds RADIUS server with his existing LDAP instance as a backend, configures that server in IdM and configures users with external authentication, the authentication could work as requested.
This is related documentation for RADIUS proxy:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/otp.html#migrating-proprietary-otp
When IdM is configured that way, the user authentication credentials would be passed following way:
SSSD (RHEL-7.1+) ---> IdM Kerberos KDC (RHEL-7.1+) ---> RADIUS ---> Existing LDAP server
The limitation is that this solution does not work with bare `kinit <password>` as the Kerberos client libraries need to create armored FAST channel with existing credentials cache, to be able to send the clear-text password to the server. Some information on the topic are in:
https://fedorahosted.org/freeipa/ticket/4411http://www.freeipa.org/page/V4/OTP#Implementation
It should work with properly configured SSSD though as it does have a keytab and sufficient material to create FAST channel automatically.