There is actually a way to achieve what you most likely want to but not
what you are asking for.

I do not think there is currently a way to force 2fa based on service or
host being authenticated - it is all or nothing. However, if all you want
is ability to use 2fa against FreeIPA for OpenVPN authentication and use
just password everywhere else - that is actually possible.

This is how I achieved this - may not be an ideal setup but it works. As
suggested, set up users to support both 2fa and password authentication.
Forget about using PAM for OpenVPN authentication - instead use a plug-in
script with credentials passed using via-env. You can write the plugin in
any language you want (I used Python) and your logic should be something
along the lines of:

Parse password to separate OTP token from password. Use LDAP to
authenticate with just password and then again with password AND OTP token.
LDAP authentication happens on the IPA server and will support both
methods.  Authenticating twice is important to guarantee you do not have a
smart-alec user who sets their password to end in 6 digits instead of
actually enabling 2fa. Once you have successful authentication, you can use
it to perform additional verifications - like checking membership(or lack
thereof) in specific group, etc., etc.

So, here is something else to think about. You may not want to allow the
same accounts access to VPN and to the internal network. There is a reason
why this is generally considered a bad practice. If someone, by some means
(say another heartbleed-like exploit or some MITM attack or by gaining root
access to the VPN serve) gains access to your user's VPN login credentials
- the last thing you want is them having a full run of the network using
those exact same credentials. Ideally it would be nice if 2fa "pin" (the
non OTP portion of the 2fa) would be DIFFERENT from the password on the
same account, but FreeIPA does not support that - at least not at this
time. So what I would recommend is using a completely separate account in
FreeIPA for VPN access.  You can standardize this by using a standard
prefix (so that for example user "username" would have an "ext-username"
account for 2fa use with external authentication) - "ext" account would
have no permissions to any data or internal login, just to access the
network  from outside and the main account would have no external access.
To hack you, someone would then need to hack your OpenVPN box and then
would still need to hack your internal authentication - which should be
encrypted by TLS/SSH even over the VPN. You can also add the prefix
automatically behind the scenes with the OpenVPN authentication script, as
well as have the script only allow access for accounts that have no other
privileges besides external access. Something to think about.



On Sun, Mar 1, 2015 at 6:40 PM, Dmitri Pal <> wrote:

> On 02/27/2015 11:37 AM, Matt Wells wrote:
>> I see how that would work but as you mentioned, I no longer have SSO.
>> My desktops are all 3.  Linux, Mac and Windows however the Windows
>> systems talk with AD and a trust exists to facilitate those
>> communications and SSO between the systems.
>> It doesn't sound like this is really possible without the heavy loss
>> of functionality.  This would be an amazing option to add though.  The
>> ability to define a service and prioritize an authentication
>> mechanism.
> On Mac and Windows you would not get SSO anyways because Kerberos on thos
> platforms does not support latest RFCs related to 2FA at least yet and
> since they are proprietary it is unclear what their plans are.
> The problem we also have is that there is no way to be selective on the
> KDC/DS side - there is no way to determine what the client is and associate
> some policies to it.
> It would have to be the client that would have to have capability to
> enforce or not enforce 2FA if the server supports both. But again that
> means that Mac and Windows would have to keep up with this capability.
> Bottom line it is a popular request but it is unclear how we can satisfy
> it.
>> On Thu, Feb 26, 2015 at 2:09 PM, Dmitri Pal <> wrote:
>>> On 02/26/2015 12:40 PM, Matt Wells wrote:
>>>> Had an error on my options for the list and the replies failed to get
>>>> to me. We'll see if this reply works.  :)
>>>> @Dmitri - Anyone coming through this service/host (OpenVPN with pam)
>>>> will be required to use 2-Factor.  Their normal logins at their desk
>>>> are not required for 2-factor, it's ok if they use it but it's not
>>>> required at all.
>>>> This VPN service is as assumed, exposed to the internet.  We're
>>>> wanting to protect ourselves as best we can with AAA.
>>> If we just talking about managing users in IdM and having tokens for them
>>> managed in IdM too then the recommendation is:
>>> - Set users to use OTP or password (set both check boxes)
>>> - Configure VPN to use Kerberos authentication against IPA - that will
>>> force
>>> use of 2FA with the policy above
>>> - Configure computers at the desk to use LDAP (you loose Kerberos SSO) -
>>> that would allow single factor with the policy above
>>> What are your desktops? Lunux? Mac?
>>> Is there any AD involved?
>>>> -------------------------------
>>>> I've got many of users setup with 2-Factor and I'd like to enforce it
>>>> with some services.
>>>> For example.
>>>> Server is an openvpn servers setup to use PAM.
>>>> Since he's tied to my 4.X IDM servers I can use 2-Factor with him.
>>>> However I want to enforce that users from this system/service require
>>>> 2-Factor.
>>>> Can anyone point me in the right direction?  My Google Foo is showing
>>>> to be poor on this one and any guidance would be appreciated.
>>>> As always thanks for taking the time to read over this.
>>>> So do you want to use 2FA for some users and 1FA for others or do you
>>>> want to have flexibility to use 2FA for the same user on one system
>>>> and not another?
>>>> Do you plan to use external tokens like RSA or you plan to use native
>>>> OTP support in IPA?
>>>> --
>>>> Thank you,
>>>> Dmitri Pal
>>>> Sr. Engineering Manager IdM portfolio
>>>> Red Hat, Inc.
>>> --
>>> Thank you,
>>> Dmitri Pal
>>> Sr. Engineering Manager IdM portfolio
>>> Red Hat, Inc.
>>> --
>>> Manage your subscription for the Freeipa-users mailing list:
>>> Go To for more info on the project
> --
> Thank you,
> Dmitri Pal
> Sr. Engineering Manager IdM portfolio
> Red Hat, Inc.
> --
> Manage your subscription for the Freeipa-users mailing list:
> Go To for more info on the project
Manage your subscription for the Freeipa-users mailing list:
Go To for more info on the project

Reply via email to