i am configuring two factor authentication,
1) portal with certificate
2) gateway with OTP
i have noticed that i can authenticate to the portal with user "A" and than on the gateay i succesfully authenticated with the OTP of user B (username & password)
the question is if we can enforce the authentication to teh gateway will be with the same username as we have authenticated to the portal ?
if user A the laptop got stolen and for user B the phone with the OTP got stolen an attacker can gain access to the VPN
This enforcement is not possible. But if you "skip" the gateway authentication, it will do the same as you want. What I mean with that is: configure portal and gateway with the same authentication settings (both with cert and OTP) and configure also authentication override with a cookie. The cookie should obly be created on the portal and then be accepted for authentication on the gateway (do not configure the portal to accept cookies). This way you have the same level of security, the user also has to login only once and you have the same user on portal and gateway.
what you suggested is just bringing the two authentication mechanisms to the GP Portal.
Yes, thats exactly what I meant. This eliminates rhe possibility for a user-A/user-B login. I mean it depends on if this is even possible in your situation and the reasons why you have different authentications on portal and gateway.
ok , i shuld test it in my lab.
questions raised from the new topology
now we have the cookie for authenticating with the GP GW, lets say the cooki valid for 2 hours, this means that withing those 2 hours the user can connect freely to all of the GP GWs in my infrustructure withouth re-authenticating ?
does within those 2 hours the user is beeing locked out in the AD, does the GP GW checks this when a user connect to it with a cookie ?
do you think i can configure the infrastructure this way:
1) use GP Portal to authenticate with certificate
2) user GP GW to authenticate with Certificate and OTP
will this bring the same functionality ?
for the portal the user will just need to authenticate in some way but not in interactive way.
for the gateway we will bring the two factor authentication as you suggested.
In case of the authentication override I would configure the cookie to be only valid for one minute (less than one minute isn't possible). So that it is only valid during login.
Your way will also work, where there is at least the cert required to get the configuration and when the tunnel should be setup the full authentication is required.
But in either way, what I just realize is the point in your second post. It does not solve your problem at all. When someone steals the computer of user-a and the mobile phone of user-b the login is still possible... Exactly this fact that this possible we use ontentionally. In our situation the cert is "only" something that is required to authenticate the device and after that the MFA login does aithenticate the user where username, password and OTP is required. And I wrote intentionally because there are team/group computers out there where we need exactly that.
Because of this I also read again a little and checked the possible options. So I have another question, do you use personal or machine certificates?
I struggle with the stolen laptop and phone scenario...
so i steal a laptop from someones car and i steel a phone from a table in a pub.
when i get home i will need the users pin if the hard drive is encrypted and i will need to know the users laptop/domain password to get into the laptop.
so having guessed the laptop password i am then prompted for the phone users credentials, do i know his username...
perhaps i have missed something here... anyhows...
for us.... (for one of our many portals)
we use personal cert for portal auth along with RSA 2 factor. (The subject field is set to none in cert profile).
this generates a cookie with timeout 1 min as per @vsys_remo.
Cookie cannot be used for portal auth.
We still have 2 factor auth on the gateway, this is ignored with the cookie overide option but is there just in case our portal goes down. The client will then used cached gateways and chosen gateway will prompt for username, pin and passcode just as the portal would.
multi factor has been discussed in other topics and some are more strict on the gateway auth as this gives you the actual connection but some useful info can be obtained from client logs in portal auth so i try to nail it down from the start...
If you configure the Username Field in your certificate profile, the extracted username from the configured certificate attribute will be locked in the client and the user will be unable to change it.
For example if I set the Username Field to subject, and my certificate is cn=user1,ou=users,dc=customer,dc=com the username that will be submitted by the GP client to the RADIUS/LDAP server will be user1. If the authenticaiton fails, the user will be unable to change the username to user2.
i have tried to configure the portal to have both the Certificate profle and the OTP authentication profile, but the client is not able to authetnciate with the portal.
i have tried also to access the portal using my browser, i get the certificate pop-up but than i was expected to get the login page for the GP Portal but i get nothing.. it just keeps loading and loading.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!