Hi,
On Суб, 09 сак 2024, Jonathan Calmels via FreeIPA-users wrote:
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.
Correct. It is not possible and will not be possible, in IPA deployment,
without some external entity's help.
IPA only responsible for its own users. If authentication relies on an
external identity (e.g. AD user), then authority holding information
about that identity would need to be responsible for its authentication
Kerberos-wise.
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)
This is not supported. Technically, you can use trusted domains'
principals as aliases of IPA principals with
$ ipa user-add-principal ipa_user ad_user@AD.DOMAIN
If enterprise principal support is advertised by the client, a KDC would
return the primary principal name in the ticket, which has to be IPA
realm's principal. However, this would make impossible to login as AD
user through IPA KDC because we would find that principal alias and
instead of issuing a cross-realm referral handle it locally.
On top of that, IPA has no realm aliases, that's why one cannot set
AD_DOMAIN as a realm for IPA principals and expect it working.
The principal aliasing should work to allow AD users to have "shadow"
IPA users they'll map onto with the help of external IdP authentication,
kerberos-wise. It might need more support from SSSD side, though.
Obviously, these IPA users will be then the POSIX users on IPA systems
as they will technically be different from AD users. One might try to
map AD users to these IPA users via ID overrides but it would be a bit
muddy to maintain since there will definitely be a problem with ID
ranges or SSSD expectations.
A possible solution here would be to use IPA users as jump-host-style
entities:
- login as normal IPA users (without AD aliases), authenticated by an external
IdP
- do 'ksu' or 'ssh' onto AD users, with the help of .k5user mapping.
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.)
It will not work. IPA KDC does not look into ID Views at all -- those
aren't considered Kerberos principals at all. Either you have a Kerberos
in this realm (IPA's) or KDC will route to the known trusted realm
directly or via some known trusted realm and there KDC would handle this
principal.
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-/.
It would still not be possible to make what you want even if we'd treat
AD users somehow as Azure/Entra ID users. The identities coming from two
separate places would need to be separate. If one source already handles
Kebreros for those *same* identities, the other one cannot provide the
same Kerberos identity unless it is a part of the same realm.
Also, another way around this could be to support WHfB / Cloud Kerberos
trust on Linux, but this is somewhat orthogonal to the above.
The 'cloud Kerberos' thing is pretty much a setup where Entra ID would
become a yet another (read-only) KDC for the on-premise Active
Directory. So in this case two requirements would be put towards IPA
hosts:
- IPA host needs to be registered against Entra ID
- IPA host would need to handle PRT and other things to perform user
authentication.
While that would be eventually possible, I hope, it would mean use of a
completely different mechanism to obtain actual Kerberos ticket for the
user, one that avoids talking to IPA KDC for this purpose. E.g. we are
back to dealing with AD DCs issuing that user's ticket.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
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/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
