<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 03/02/2015 01:19 AM, Michael
Lasevich wrote:<br>
</div>
<blockquote
cite="mid:CAAFs98W3ONi=AW9b_4WcexkT9jo81JnAge2WfQWkh5H_ODyM=w@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div>
<div>There is actually a way to achieve what you most likely
want to but not what you are asking for.<br>
<br>
</div>
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.<br>
<br>
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:<br>
<br>
</div>
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.<br>
<br>
</div>
<div>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.<br>
</div>
</div>
</blockquote>
<br>
This customization is very specific to the conventions that you
choose for yourself to follow.<br>
It is not a bad solution, just a bit too custom.<br>
<br>
<blockquote
cite="mid:CAAFs98W3ONi=AW9b_4WcexkT9jo81JnAge2WfQWkh5H_ODyM=w@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
</div>
<div>HTH,<br>
<br>
</div>
<div>-M <br>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Sun, Mar 1, 2015 at 6:40 PM, Dmitri
Pal <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:dpal@redhat.com" target="_blank">dpal@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"><span
class="">On 02/27/2015 11:37 AM, Matt Wells wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
I see how that would work but as you mentioned, I no
longer have SSO.<br>
<br>
My desktops are all 3. Linux, Mac and Windows however
the Windows<br>
systems talk with AD and a trust exists to facilitate
those<br>
communications and SSO between the systems.<br>
<br>
It doesn't sound like this is really possible without
the heavy loss<br>
of functionality. This would be an amazing option to
add though. The<br>
ability to define a service and prioritize an
authentication<br>
mechanism.<br>
</blockquote>
<br>
</span>
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.<br>
<br>
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.<br>
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.<br>
<br>
Bottom line it is a popular request but it is unclear how we
can satisfy it.
<div class="HOEnZb">
<div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
On Thu, Feb 26, 2015 at 2:09 PM, Dmitri Pal <<a
moz-do-not-send="true" href="mailto:dpal@redhat.com"
target="_blank">dpal@redhat.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
On 02/26/2015 12:40 PM, Matt Wells wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
Had an error on my options for the list and the
replies failed to get<br>
to me. We'll see if this reply works. :)<br>
<br>
@Dmitri - Anyone coming through this service/host
(OpenVPN with pam)<br>
will be required to use 2-Factor. Their normal
logins at their desk<br>
are not required for 2-factor, it's ok if they use
it but it's not<br>
required at all.<br>
This VPN service is as assumed, exposed to the
internet. We're<br>
wanting to protect ourselves as best we can with
AAA.<br>
</blockquote>
<br>
If we just talking about managing users in IdM and
having tokens for them<br>
managed in IdM too then the recommendation is:<br>
<br>
- Set users to use OTP or password (set both check
boxes)<br>
- Configure VPN to use Kerberos authentication
against IPA - that will force<br>
use of 2FA with the policy above<br>
- Configure computers at the desk to use LDAP (you
loose Kerberos SSO) -<br>
that would allow single factor with the policy above<br>
<br>
What are your desktops? Lunux? Mac?<br>
Is there any AD involved?<br>
<br>
<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
-------------------------------<br>
I've got many of users setup with 2-Factor and I'd
like to enforce it<br>
with some services.<br>
For example.<br>
Server <a moz-do-not-send="true"
href="http://vpn.example.com" target="_blank">vpn.example.com</a>
is an openvpn servers setup to use PAM.<br>
Since he's tied to my 4.X IDM servers I can use
2-Factor with him.<br>
However I want to enforce that users from this
system/service require<br>
2-Factor.<br>
Can anyone point me in the right direction? My
Google Foo is showing<br>
to be poor on this one and any guidance would be
appreciated.<br>
<br>
As always thanks for taking the time to read over
this.<br>
<br>
<br>
So do you want to use 2FA for some users and 1FA
for others or do you<br>
want to have flexibility to use 2FA for the same
user on one system<br>
and not another?<br>
Do you plan to use external tokens like RSA or you
plan to use native<br>
OTP support in IPA?<br>
<br>
<br>
<br>
<br>
--<br>
Thank you,<br>
Dmitri Pal<br>
<br>
Sr. Engineering Manager IdM portfolio<br>
Red Hat, Inc.<br>
<br>
<br>
</blockquote>
<br>
--<br>
Thank you,<br>
Dmitri Pal<br>
<br>
Sr. Engineering Manager IdM portfolio<br>
Red Hat, Inc.<br>
<br>
--<br>
Manage your subscription for the Freeipa-users
mailing list:<br>
<a moz-do-not-send="true"
href="https://www.redhat.com/mailman/listinfo/freeipa-users"
target="_blank">https://www.redhat.com/mailman/listinfo/freeipa-users</a><br>
Go To <a moz-do-not-send="true"
href="http://freeipa.org" target="_blank">http://freeipa.org</a>
for more info on the project<br>
</blockquote>
<br>
<br>
</blockquote>
<br>
<br>
-- <br>
Thank you,<br>
Dmitri Pal<br>
<br>
Sr. Engineering Manager IdM portfolio<br>
Red Hat, Inc.<br>
<br>
-- <br>
Manage your subscription for the Freeipa-users mailing
list:<br>
<a moz-do-not-send="true"
href="https://www.redhat.com/mailman/listinfo/freeipa-users"
target="_blank">https://www.redhat.com/mailman/listinfo/freeipa-users</a><br>
Go To <a moz-do-not-send="true"
href="http://freeipa.org" target="_blank">http://freeipa.org</a>
for more info on the project<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Thank you,
Dmitri Pal
Sr. Engineering Manager IdM portfolio
Red Hat, Inc.</pre>
</body>
</html>