On Аўт, 12 сак 2024, Jonathan Calmels via FreeIPA-users wrote:
> Having said that, I'm not even sure if one can request a
specific
> preauth method today in SSSD.
And by that I mean as a hint before the actual AS_REQ. IIUC this isn't
straightforward to do currently because:
- The PAM conversation happens after the AS_REP and depends on the
supported auth methods
- There is no password fallback with the idp auth
The other way would be to contact both KDC and somehow keep track of
both until you get the user input, but it gets tricky
There is no explicit way in MIT Kerberos client side to influence which
pre-auth mechanism is used other than forcing configuration externally
to avoid certain choices. There is no API to control what happens at
pre-authentication. All methods available to both KDC and the client
will be tried one by one by the client code until they produce an answer
that can be sent out to the KDC.
This gives us one option, though: an application may register prompt
handlers that a pre-auth method may use to query a user for a detail to
complete the pre-auth and this is something you can influence by
choosing to not respond to a prompt request. This is something that was
broken in SSSD until the past week.
If you have idp or passkey method enabled alongside with a password,
SSSD did not fall. This has been fixed just recently upstream:
https://github.com/SSSD/sssd/issues/7152
We also have a very crude way: don't provide FAST channel, this removes
KDC response for OTP, RADIUS, external IdP, and passkey methods. This
is, obviously, not what you'd want for this situation. Similarly, one
can redefine plugins_base_dir and then play with clpreauth in [plugins]
section to force not using or, instead, using a particular plugin.
All these aren't the things you are looking for. ;)
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland