We have several deployments of RHEL IdM consisting of a cross-forest trust with on-prem MS Active Directory. Users are able to login to the IdM resources with their Corporate AD credentials (i.e. password or existing AD ticket). Users identities (including Posix attributes) are fetched from AD along with all their group information.
Recently we've had the need to support Azure AD authentication motivated by several factors such as cloud-joined clients and FIDO2 requirements. In our case, Azure AD is partially synced with the on-prem AD through Azure AD connect. Given our current deployments how can we achieve this? Namely, how can we support AAD authentication on top of our current authentication with our user identities sourced from on-prem AD? The first thing that comes to mind is the external IdP integration in IPA, however given the nature of its implementation, this requires that IdP identities are managed through IdM. So what we need is effectively a way to link an IdM user (referenced by the IdP association) to an external trust user, which doesn't seem possible today. We've tried several things, and glancing at the various software pieces of the IdM stack, this doesn't look supported. We might have missed something obvious though. Nonetheless, the main ideas we had were: 1. Add a reference to the AD trust user in the IdM user through the use of Kerberos enterprise principals. Here the idea is to define the IdM user (for IdP) with a canonical principal name set to the fully qualified trust user (i.e. ipa user-add idm_user --principal ad_user\\@ad_domain --idp-user-id aad_user@aad_domain) This way SSSD could theoretically detect and use the trust user instead of the IdM one during authentication. We've personally tried this but hit a few roadblocks (and this list is probably non-exhaustive): - KDB returns KRB5KDC_ERR_WRONG_REALM on enterprise principals consisting of a trusted domain - krb5_child responder would need to return the new user translation (i.e. aname_to_lname of ad_user\@ad_domain@IDM_REALM -> ad_user@ad_domain) - To support the above, sssd_krb5_localauth_plugin would need to be aware of this specific case, or be disabled to simply strip IDM_REALM as opposed to returning the IdM user back (i.e. ad_user\@ad_domain@IDM_REALM -> idm_user) - pam_sss would need to set PAM_USER to the result of this translation and use the resulting name for subsequent queries (similar to user hints in certificates) - getAccountInfo would probably need tweaking too (not exactly sure) 2. Modify the trust IDView to include the IdP association and signal the fact that IdP authentication should be done through IdM and not the trusted KDC. From there, I'm not sure how this would work on the IdM KDC side since there wouldn't be any existing principal to authenticate against (maybe matching enterprise principals could be created dynamically similar to 1.) Hopefully there exists a simple solution for this use-case already, if not, I hope that the ask was clear enough. Finally, note that this is somewhat related to the recent talks at FOSDEM, specifically https://fosdem.org/2024/schedule/event/fosdem-2024-2587-posix-identities-out-of-oauth2-identity-providers-how-to-redesign-sssd-and-samba-/. Also, another way around this could be to support WHfB / Cloud Kerberos trust on Linux, but this is somewhat orthogonal to the above. -- _______________________________________________ FreeIPA-users mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
