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.

Who Me Too'd this topic

Global Protect Pre-Logon conflicting with User-ID agent

L1 Bithead

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?

 

Who Me Too'd this topic