Thanks for the detailed answer, glad we didn't miss anything obvious. I just want to add a bit more clarification on what we were proposing
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.
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(a)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.
I understand that, in the case I described, technically IPA doesn't rely on an external identity. The principal alias is still part of the IPA realm, it's just that we "encode" the trusted domain in it, it doesn't use the AD realm at all. All the magic happens in SSSD.
On AD my user principal is: ad_user@AD.DOMAIN On IPA my user principal is: ad_user@ad.domain@IPA.DOMAIN (the canonical one, it can still have the standard ipa_user@IPA.DOMAIN as an alias)
Nothing changes here, the AD user authenticates through the referral, the IPA user authenticates normally in the IPA realm either with "kinit -C ipa_user" or "kinit -E ad_user@ad_domain" and gets a TGT from IPA.
Where it changes is on the SSSD side. What we want is effectively something akin to: auth_provider = ipa (for IdP) id_provider = ad (but really we want ipa here to do the idview)
There would be an option so that SSSD could handle this enterprise principal encoding and thus switch to the shadow user. In pseudo code, it would go something like this when the IPA user authenticates:
pam_authenticate(ipa_user) kinit(ipa_user@IPA_REALM) // this gets canonicalized to "ad_user@ad.domain@IPA.DOMAIN" aname_to_localname(ad_user@ad.domain@IPA.DOMAIN) // this gives us "ad_user@ad.domain" pam_set_item(PAM_USER, "ad_user@ad.domain") // this effectively switches the identity from the IPA user to the AD one going forward ...
So the user is authenticated against IPA with a TGT, but its username, UID, GIDs, etc are fetched from AD. The Posix information in IPA are never used (i guess they would if you wanted to by turning off canonicalization)
I realize this is pretty hacky, but in theory this could work right?
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.
Um yeah this could work but this not ideal for users. They would have to be aware of those two different accounts and how to manage them (shell, home dir, etc)