Global Protect Pre-Logon conflicting with User-ID agent

[buck1]

We are trying to deploy pre-logon, we have security policies around pre-logon users, and then security policies for actual users once they authenticate.  Basically, an initial pre-logon rule that allows access to domain controllers, etc., followed by a pre-logon deny all rule, followed by rules for users that have fully authenticated to GP.  All of this works great, except for one problem.  We run user-ID agents on our network to map IP to username, and we have found that once the user-ID agent maps an IP to a username, the firewall seems to no longer treat that connection as pre-logon from a security rules perspective.

So here is the specific example (by the way, we are testing with user initiated pre-logon):

User clicks connect button on logon screen, which initiates pre-logon connection to gateway.

User then enters domain credentials and successfully authenticates (pre-logon rules are being used for this).

User is now logged into computer, but not fully authenticated to GP yet as a user (MFA required to fully authenticate).

But because User-ID agent maps the IP of the user to the username, we see that the firewall jumps past our pre-logon deny rule and starts allowing the user to access internal resources we do not want them to access yet.

So.. status is still pre-logon, but they are jumping past our pre-logon rules.  Not ideal.  I opened a ticket with Palo and after explaining everything to them, they said that is just the way it is, and we would have to make a feature request to our SE to change this.  I just can't believe we are the only company that users user-ID agent mapping, and also uses Global Protect with pre-logon.  Seems like anyone using these two things together would have the same issue with their security policies.

On the occasion that user-ID IP/username mapping does not work, then the pre-logon deny rule does not get jumped, and everything works as expected (traffic gets denied to internal sensitive resources).  But any traffic that does capture the username will jump the pre-logon deny rule.

Anybody have any thoughts on a way to get around this issue?

[buck1 · Accepted solution]

I came up with a work-around solution that I am currently testing.  I decided to move the pre-logon off to a separate gateway.  This allows me to give it its own tunnel, with its own zone, and therefore I can disable the user-ID on just that zone.  Initial testing so far has been positive.

[MP18]

@buck1 

We have Pre Log on Always on with SAML Azure authentication.

We have same security rules allow username Prelogon to access DC and then deny all rule right after that.

For this we have Agent config in Portal to only allow usegroup prelogon.

Under App this Agent has connection method pre logon always on

Then  we have second agent config under same portal to allow  any user group.

Under App this Agent has connection method user initiated.

This way when user PC reboots GP is already connected using username prelogon.

Once use puts username and password GP is still connected with username pre logon.

Now he needs to connect manually on GP then he gets push notification on phone and then user name changes from pre log pn

to actual username.

Regards

[rajjair]

On the User ID agent you can create an exclusion for the IPs that you are using global protect agent for as that can be used as user id at the authentication time and no rely on the DC to get user id vpn users also. That is what we do we exclude the IP subnet on the user id