Bumping priority, this is something being actively asked.

Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1195696

Quote from Bug https://bugzilla.redhat.com/show_bug.cgi?id=1847205, comment #4,

Alexander explained that:

A generic answer is that with Kerberos, the source of truth is the KDC that stores information about the user. In case of Active Directory, those are Active Directory domain controllers, not IdM servers. As far as I know, Active Directory has no support for multifactor authentication on Kerberos level. Instead, they have it all integrated on the Windows operating system level and use a different protocol to authenticate the user on Windows desktop and then obtain a Kerberos ticket based on that. This method is not supported and will unlikely be supported as it is all proprietary.

In other words, the authentication need to be done with AD. IdM can trust the Kerberos ticket from AD, but not doing the authentication for AD.
So the AD must support multi-factor auth.

See microsoft document regarding this issue:

https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/manage-risk-with-additional-multi-factor-authentication-for-sensitive-applications

I am closing this ticket because we cannot implement anything on Microsoft's Active Directory side.
From FreeIPA point of view, we already support a method to authenticate users against an external identity provider supporting OAuth2 device authorization flow. Such support exists in Entra ID, Google, Github, and Red Hat build of Keycloak (former Red Hat SSO), for example. Active Directory users can be made authenticating through Entra ID. This would mean use of IPA users to define this authentication path and no need for trust to Active Directory would be required.