So, I got to play around with this and implemented the "workaround" we
discussed.
I ended up using ksu with sshd ForceCommand to make it more seamless for users.
Here are some of the issues I faced though:
1. IdP requires FAST and I'm not sure how I'm supposed to configure that correctly
in SSSD since I need it for both AD and IPA and can't set two different
krb5_fast_principal. With one, it could work with cross-realm requests I suppose but
it's not ideal. SPAKE 2FA would also be nice here but doesn't seem supported yet?
2. I need two distinct usernames per user, e.g. myuser and myuser_idp. I tried using the
same usernames for both AD and IPA users but SSSD gets really confused depending on
what's cached. We use shortnames with a domain resolution order, so I thought having
both usernames alias could work and SSSD would just prefer the IPA one if it exists. On
the bright side, this allows users to pick the authentication method depending on which
username they choose, so there is that
3. SSSD localauth plugin gets in the way when it comes to remapping both principals to the
AD user (e.g. for ksu authorization). The IPA principal gets mapped to myuser_idp and one
cannot write custom aname2lname rules because SSSD is always called first in the krb5
module order. Only way I found is to disable all the SSSD snippet generation and write my
own rules but I would rather avoid that.
4. IdP auth doesn't work when the SSSD PAM responder is socket activated. I
haven't really looked into why it fails, but this caught me off guard at first.
I'm not sure if I should file separate bugs for those, but after all of that it
works.
Overall, I would still prefer if there was a way to do this natively in SSSD somehow (i.e.
external users shadowed by IPA auth). Having said that, I understand that this is quite
challenging.