On Пят, 15 сак 2024, Jonathan Calmels via FreeIPA-users wrote:
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?
No, 2FA SPAKE is not implemented. Even if it would be implemented, it
still needs FAST channel wrapping.
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
I think it is also helpful from auditing purposes, a poor man's
replacement of exposing auth indicators at an application level or in
KDC logs. Explicitly different user name helps to hilight the fact that
this user is 2FA-authenticated for login.
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.
Feel free to propose a specific algorithm to extend the plugin.
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 think it should work. Debug logs would help -- please open an issue,
may be upstream for SSSD, with debug logs to show what's wrong. That
said, I think main responders (nss, pam) should not use socket
activation. Debian packaging was wrong in defaulting to this.
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.
Glad that it worked overall. Please file bugs, we can look at what could
be improved. This is indeed a challenging area and a certain level of
hand-helding is still needed so that admins wouldn't go too wild. ;)
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland