Windows and User-Mappings

[david.alicea]

I have a user group in Active Directory where we place users who should not reach the internet. This user group is then tied to a Palo Alto rule to Deny access.

I've noticed (Windows PC) this week, that if a user who is in the Deny group logs in to a PC, they will be denied (works fine), however, lets say they log out and a person who should have access logs in to the same PC....packets are still hitting the firewall with the previous username, thus they get denied.

I dont believe this might be entirely tied to Palo Alto, I have a feeling it is something in Windows-land, but I just wanted to see if anyone else has ran into this.

One way to get it to work again is to change the VLAN on the user, forcing them to grab a different IP.

[Mick_Ball]

does the user ip mapping ever update to the correct user or have you never left it for that long to test.

[Remo]

@david.alicea do you may be also block access to the domain controller for this deny group?

[Brandon_Wertz]

Yes, and you'd be correct.  Indirectly it has nothing to do with the firewall, but rather or firewall being updated with the user ID change.

Whichever method you're using for user attribution I would ensure the update and general user-id collection intervals are appropriate.

More than likely what's occurring is the user that is logging into the PC that shouldn't be denied is logging into the PC via credentials which already exist on the PC.  Since you're collecting logs from a domain controller you aren't seeing updates to the firewall because there was in-fact no domain controller authentication.  The user authenticated to the local PC.  (That's just my guess)

[david.alicea]

On our end right now we are only using AD Authentication and not the actual User Agent-ID (yet). So the firewall is set to poll a few DCs on an interval. What settings would need to be updated to force more communication from the DC to the firewall. Or is it really trying to force more communication from the PC to the DC? That is what is sounds like based on your observation. The PC is the one not communicating to the DC to let the DC know there was a login change.

[david.alicea]

Its pretty wide open between DCs and users. This firewall is only traversed on the way to the internet.

[BPry]

@david.alicea,

Do you have an on-site Exchange enviroment that you could use to pull the security events from that? That in my case has been one of the more reliable ways to get user-id information in an office enviroment, simply because most users will always have Outlook open. Find more info on the Exchange setup HERE

That or you could setup GlobalProtect as an always-on format to ensure that the User-Id mapping is always up-to-date regardless of whether the user is internal or external. 

[david.alicea]

Yep, we do have an on-prem Exchange...for now. My plan was to eventually go through with the actual User Agent-ID setup.

However...is that really going to solve the scenario of a shared PC?

One user who is denied logs in to the shared PC and gets denied to the internet by the FW...but the second user who logs in (and should have access to the internet) will not be denied? As one of the above posts stated, the Windows username who should be allowed to the internet is logging into the same PC it already had a profile in. So that will not send domain info over to the Domain Controller.

[BPry]

@david.alicea,

This depends on whether or not the user is going to open Outlook on that machine. If they open their email after they login that will trigger the update for the user-id table if you are monitoring the Exchange enviroment. This would fix it from being denied. 

If the user isn't going to be logging into Outlook then this really isn't going to help you at all and you would have to explore the GlobalProtect options. 

[Harshit · Accepted solution]

using a UserID agent based set up would be better for your issues, 

when multiple people are logging in the same computer, the agent would pick up the latest login event of that pc and update it in firewall,

For no check with AD, i believe its partialy true, yes it will allow to log in but in background the pc would try to authenticate the pc with the credentials entered, and if they have any application logged in with there id, it may take a few minutes and they should be mapped correctly.

Captive portal can alo solve this probelm, by authenticating an unknown user to ip by prompting to the user.

your other question should be how would you block a  "restricted" user that just logged in and since previous id is  "allowed"  obtains the access to internet, In that case, set the id timeout on user id agent (assuming you set it up) to a mere few minutes.

~HTH

[david.alicea]

It seems everything is leading over to the Agent-ID. I'll begin the setup next week. Thanks everyone.