@abbra may be able to help as someone who works on FreeIPA and knows the ins and outs of how all this works.

Alternatively, @rishi did the implementation for GNOME and may be able to help.

Thanks. This is, as you might suspect, is not enough.

FreeIPA, in general, and Fedora Accounts system, in particular, do support multiple authentication mechanisms through Kerberos. These mechanisms in MIT Kerberos are represented as pre-authentication plugins (internally) and some of them only available when both Kerberos KDC and Kerberos client advertise a special mechanism to protect those pre-authentication exchanges. This mechanism, FAST armor, relies on the use of a separate, early obtained Kerberos ticket. See https://datatracker.ietf.org/doc/html/rfc6113 for the framework description.

In case of Fedora Accounts System, which is also used by CentOS, Rocky Linux, AlmaLinux, GNOME, and few other organizations, users are allowed to utilise second factor authentication tokens (2FA) authentication, based on TOTP or HOTP methods. This authentication mechanism requires use of FAST armor. For such armor, one uses a ticket obtained with the help of anonymous PKINIT authentication. Fedora documentation explains how this works in Fedora: https://docs.fedoraproject.org/en-US/fedora-accounts/user/#_2_initialize_the_credentials_cache

Basically, it can be done with kinit tool by using a separate ccache to obtain anonymous PKINIT ticket first and then use it as a FAST armor:

$ kinit -n @FEDORAPROJECT.ORG -c /path/to/ccache.file
$ kinit -T /path/to/ccache.file some-username

This also assumes overall Kerberos setup is in order, as anonymous PKINIT mechanism utilizes configuration that Kerberos has for smartcard-based authentication using x.509 certificates (hence, Public Key Cryptography for Initial Authentication in Kerberos (PKINIT), https://www.rfc-editor.org/rfc/rfc4556).

In FreeIPA more pre-authentication mechanisms use FAST armor to protect their communication. The prompts/exchanges you get through kinit tool may vary depending on what user is allowed to use in FreeIPA. For example, in Fedora Accounts system you can either authenticate with password or password+second factor token. Both are pretty much "fire and forget" style communications: you get asked for a single question, enter your answer, wait for completion. The question differs: for password, you'd asked to enter a password. For 2FA case, you are asked 'Enter OTP token:' (really, password+token value). But there are more options: RADIUS integration is similar to 2FA OTP case, smartcard-based authentication require specifying PKI URI to kinit -X option (and use of a smartcard device or certificate files). Smartcard authentication may require entering a PIN to unlock the smartcard. In FreeIPA 4.10 we added authentication against external OAuth2 identity provider, like Github or Google, or Azure AD, which support OAuth2 device authorization flow. In that case you'd get asked to visit an URI in a browser and then press enter to kinit prompt to continue. Finally, in FreeIPA 4.11 we will add FIDO2 integration which implies you have the token locally accessible over libfido2 library (over USB in most cases). There one can be asked to enter a device PIN and confirm access to the token by pressing a button on it.

So all those methods require certain interaction between kinit output and input and the user. The unfortunate thing is that one cannot achieve that programmatically without re-implementing most of kinit code. GSSAPI interface, which was supposed to simplify how applications perform authentication with different protocols, including Kerberos, has no means to perform Kerberos authentication with non-password (and non-keytab) means, so GSSAPI cannot be used here, at least right now. Thus, most tools run kinit with various options and expect some response.

SSSD kerberos backend handles these all variations through raw krb5 API. Technically, if the machine is enrolled into a domain that supports Kerberos (like FreeIPA), one could simply use PAM API to load a PAM configuration which uses pam_sss module and navigate through PAM messages. But absolute majority of Fedora users don't enroll their systems in Fedora's FreeIPA domain, so this is not really usable.

I believe @rishi's code also doesn't handle these cases. It only handles a single password-based variant.

@abbra: So what should @nicolasfella do, then?

If you are using kinit executable as an interface, implement use of anonymous PKINIT as a FAST channel. May be allow users to switch it on/off -- usability-wise one can present this as 'My Kerberos account uses multi-factor authentication' checkbox. You can use raw krb5 API similar to how SSSD does at https://github.com/SSSD/sssd/tree/master/src/providers/krb5 but that is probably too much to require, using kinit executable is easier.

What you need to be prepared for is that in Debian world all this wouldn't be working because Debian by default builds and uses Heimdal kerberos which has no support for all these methods. In a sense, it is very much simpler there -- you can install MIT Kerberos too but defaults are using Heimdal. So there would be a bit of adaptation to the distribution.