What VPN server are you using & how do you currently integrate it with FreeIPA? If you integrate via PAM, I think the following is possible, but it is untested--it's just what I've pulled together in my notes, I haven't got around to actually trying it yet. You can allow a user to use _either_ normal password authentication, or OTP: ipa user-mod myuser --user-auth-type=password,otp Now, pam_sss will prompt for 'first factor' and 'second factor (optional)' - if the user just hits enter then they can still log in with password alone. If they do provide a second factor, there will be an 'authentication indicator' included in their TGT which can be checked later on by the pam_sss_gss_module. On your VPN server, add the pam_sss_gss module to the vpn service's PAM module stack. It has to go after pam_sss has prompted the user & obtained a TGT; I guess the 'required' control flag is the right thing to use here. But the exact position will depend on what else you have in your module stack. Tell sssd to allow the use of pam_sss_gss by setting pam_gssapi_services = myvpn, and configure it to require the 'otp' indicator on the user's TGT by setting pam_gssapi_indicators_map = myvpn:otp. Both those settings are in the [pam] section of sssd.conf. (As an aside, I wonder why the former setting is needed--only root should be able to modify pam stacks; and why the latter setting couldn't have been implemented by a module argument... it would have been nicer to keep all the PAM config in once place...) The remaining bit of work is to get the VPN server to understand the prompts from pam_sss & provide the password to the 'first factor' prompt and the OTP to the 'second factor' prompt. -- Sam Morris <https://robots.org.uk/> PGP: rsa4096/CAAA AA1A CA69 A83A 892B 1855 D20B 4202 5CDA 27B9

Fair. Looks like there is an XAuth PAM plugin but I don't see how to configure the PAM conversation. -- Sam Morris <https://robots.org.uk/> PGP: rsa4096/CAAA AA1A CA69 A83A 892B 1855 D20B 4202 5CDA 27B9

On pe, 18 helmi 2022, Michael Schwartzkopff via FreeIPA-users wrote: Setting authentication type on IPA users or in the global configuration forces use of that authentication type by Kerberos KDC for all attempts to obtain a ticket granting ticket (TGT), initial ticket that user is granted before they would request a service ticket. This initial authentication process has no limit from where it could happen or which application could trigger it. Assigning specific authentication type also means that only the assgined types are possible to use and nothing else. If you add both OTP and password, for example, a user will be able to authenticate with OTP or with password but there is nothing at this stage that would worse it to use only OTP or only a password. Once TGT is obtained, it will contain a tag, called 'authentication indicator', that records how this TGT was obtained. A target application may look into a service ticket obtained with the help of TGT and decide whether this pre-authentication method was good enough. So a target application can deny tickets obtained with the help of a password and only accept tickets authenticated with OTP or a smart-card (PKINIT authentication indicator). As a result, in order to apply a policy 'OTP should only be asked in special cases like VPN access', you need two things: - allow use of OTP among allowed authentication types for a user on KDC side - force check for 'otp' authentication indicator in the Kerberos service ticket received by your application Up until recently there were not many applications that were able to analyze authentication indicators in Kerberos tickets even though there is a GSSAPI function that allows to do so. Since Autumn 2020, SSSD adds a new PAM module, pam_sss_gss, to enforce such check with applications using PAM and negotiating Kerberos. But if your application is not aware of this method, the only enforcement we have is on the KDC side, e.g. when TGT is obtained. And if you'd force use of a single authentication type there, it will apply everywhere. See more at https://freeipa.readthedocs.io/en/latest/workshop/11-kerberos-ticket-poli... -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland