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: [email protected] On IPA my user principal is: ad_user\@[email protected] (the canonical one, it can still have the standard [email protected] 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\@[email protected]" aname_to_localname(ad_user\@[email protected]) // this gives us "[email protected]" pam_set_item(PAM_USER, "[email protected]") // 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) -- _______________________________________________ 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
