GlobalProtect authentication problem

[TheBest]

Hello,

The group I use to authenticate GP connections doesn't work properly.

I followed the advice on this thread:  https://live.paloaltonetworks.com/thread/8661

It was necessary to place the NETBIOS domain name in the LDAP server profile.  Output from the CLI now clearly displays the logon format with domain\user, unlike before, for GP clients.

The GP Portal specifically sites the group allowing VPN connections in the Agent COnfiguration section.  Yet, I can still logon with an account that is in the AD but not in that group.

Why is this happening?  What is the best practice to limit who can connect via GP?

Follow-up question:  Is it possible to deploy new GP clients to a group of test users?

Thanks for your help!

[kadak]

Hello TheBest,

I would remove the AD group from the agent configuration and would use it in a security rule. For example, if your tunnel belongs to a zone called 'GP-VPN', I would create a security rule from 'GP-VPN' to 'Trust' and leverage the user-group feature in the 'source user' column of that policy and then test.

Hope that helps!

Thanks and regards,

Kunal Adak

[TheBest]

Hi,

OK, so it appears that the AD group in the agent configuration would be mainly to target a group for a specific configuration of the agent.  Therefore, this parameter has nothing to do with security and access filtering.  Still, using this method, I don't think its possible to target a specific group for a newer version of GP client.  I think the only way may be to deploy the MSI via GPO.

Your idea is a good one but won't work currently with my configuration.  The security zone for the VPN tunnel is already "Trust".  This explains why we have no granularity and clearly reduces security.  However, the physical interface connection to the internet is in the zone "Untrust".  It looks like there is a 1:1 relationship between the physical interface and a zone.  So, it looks like I would have to change the VPN tunnel zone from "Trust" to "Untrust" and then add the policy as you suggested, right?  Otherwise, is it possible to have multiple zones linked to one physical interface?  In that case the interface to the outside would include "Untrust" and a new zone "GP-VPN"?

Thanks for your valuable help!

[kadak · Accepted solution]

Hello TheBest,

You can have multiple interfaces of same type (L2/ L3/ Vwire) in one zone, but cannot tie multiple zones to one interface. Having said that, it was always a best practice to associate the tunnel interface to its own zone - something like GP-VPN and then configure a security rule from GP-VPN to Trust and GP-VPN to Untrust. In that way, you not only have more control over the traffic but you can also turn on PAN's IDS/IPS feature by applying AV, anti-spyware, anti-vulnerability, URL-filtering and data filtering profiles.

Thanks and regards,

Kunal Adak

[TheBest]

Hello,

Yes, we needed to associate the tunnel interface with its own zone rather than the trusted zone.  As you stated, this modification now allows additional and needed granularity. 

There are still two comments/questions, though not critical:

1.  I was obliged to add a Client Configuration in the GlobalProtect portal, citing an AD group and external gateway IP.  Without this, I was getting this error after compiling: 

Config commit phase 1 aboreted (Module: device)

missing both client config and satellite config

(Module: sslvpn)

Commit failed

2. I can still connect to the portal FQDN and authenticate with ANY account in the AD to download the GlobalProtect client.  Thanks to the new rules, it is now not possible to authenticate with ANY account in the AD from GlobalProtect - it is necessary to have an account in the designated allowed group.  In any case, shouldn't the authentication be denied when connecting to the portal FQDN and before being able to download the globalprotect MSI?

Best regards