Global Protect and User-ID

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

Global Protect and User-ID

L2 Linker

I want to make my GP portal more secure by adding User-ID to my GP inbound rule so that only users in the AD group can authenticate.

 

At the moment source user is just set to 'any' and the VPN is working fine.

 

When I add the group as in the attached image it breaks. I'm guessing there are some extra configuration steps i'm missing here...

 

Note that the group mapping is working fine in other rules once users are authenticated. I'm just wondering if I can utilise user-id at the first step in the authentication process.

 

Screenshot 2021-05-11 at 14.30.05.png

1 accepted solution

Accepted Solutions

Cyber Elite
Cyber Elite

@GeorgePalo,

Ya by default this wouldn't work. The problem is that your firewall doesn't know who the user is when a user is attempting to connect from untrust to your GlobalProtect portal/gateway. So the SSL_VPN_IN is never going to be matched and you'll always hit the Block-In entry. For this to work, you would need to tie it with an authentication rulebase entry to feed unidentified users attempting to access GlobalProtect and have them login so that they actually have a user-id mapping on their public IP so they match your SSL_VPN_IN entry. 

 

I honestly don't recommend you try do anything like this. Let your GlobalProtect Portal do it's job of authenticating the users. If you want to secure it as much as possible, restrict access to regions that you expect/allow users to work from and setup an automatic block for the source address after X number of GlobalProtect authentication failures. 

View solution in original post

3 REPLIES 3

Cyber Elite
Cyber Elite

@GeorgePalo,

Ya by default this wouldn't work. The problem is that your firewall doesn't know who the user is when a user is attempting to connect from untrust to your GlobalProtect portal/gateway. So the SSL_VPN_IN is never going to be matched and you'll always hit the Block-In entry. For this to work, you would need to tie it with an authentication rulebase entry to feed unidentified users attempting to access GlobalProtect and have them login so that they actually have a user-id mapping on their public IP so they match your SSL_VPN_IN entry. 

 

I honestly don't recommend you try do anything like this. Let your GlobalProtect Portal do it's job of authenticating the users. If you want to secure it as much as possible, restrict access to regions that you expect/allow users to work from and setup an automatic block for the source address after X number of GlobalProtect authentication failures. 

Yeah that makes sense.

 

Do you have any more information about how to set the number of authentication failures before lockout on the portal?

 

Thanks,

As an alternative you can use the portal agent to only allow selected users to connect, 

MickBall_1-1620829061474.jpeg

 

 

if you are not in the AD group you will get this message,,

 

MickBall_0-1620828718798.png

 

  • 1 accepted solution
  • 3543 Views
  • 3 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

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!