Today there are various options to achieve UserID using PaloAlto Networks devices:
- Install agent on AD-servers to tail the local security log to pick up which userid uses which ip.
- Install agent on remote servers that will tail the security log of one (or more) AD-servers (variant of the above - will bring you more network traffic but at the same time you will avoid installing 3rd party software on your AD-servers).
- Let the PA device do the above.
- Variant of all 3 above is to tail other logtypes to pick up a relation between userid and sourceip (MS Exchange logs, various other textbased logs etc).
- Using WMI (either from agent or from PA device) to verify directly towards the computer who is logged in.
- Install TS-agent which will define which userid uses which portrange when using a terminal server.
Any other method that I might have missed?
What I wonder is if the following two use cases have been fixed and in which version (like any differences regarding UserID between PANOS 6.x and 7.x?):
Use case 1:
More than one user is logged in to the same client computer (example one user in front of the computer and one user (lets say supportpersonel) thats logged in remotely, or for that matter one user is logged in (and locked screen) but now a second user arrived and used "switch user" - that is second user login (and get his/her own screen) while the first user is still logged in) - how does PA UserID handle this today?
If I recall it correctly previously a single sourceip (except for when TS-agent is used on terminal servers) can only have a single userid connected to it.
This gives that the latest userid will always overwrite the previous userid (like if someone RDP into the client workstation that RDP user will be identified in UserID and the original user is now no longer identified by UserID).
Use case 2:
A single user is logged in to 2 or more computers at once. Lets say the client workstation and then login to some VDI on a terminal server. Will both ip-addresses be valid for the current userid or wil it be similar to as above that latest login is the valid one and previous ip-address associated with this userid is now overwritten?
Are there any up2date whitepaper regarding UserId when it comes to best practices but also what it can (and cannot) do?
For example how do UserID today identify that a user now logged out of his/her computer(s)?
If use case 1 and 2 are still issues, are there any work in progress to fix this or recommended workarounds?
1. Any new record from any data source will update the firewall's records for the associated IP. With the respective counter resetting
2. Multiple IPs don't matter to the FW (See my screen capture)
I've always been told that if 100% user attribution was necessary that GP is the only way to go.
Thanks for a quick reply! :-)
I guess a workaround to apply would be to simply disable "switch user" through GPO because I can imagine a potential break in UserID after user2 logged in on the same box and then user1 returns (because that wont really login but rather just unlock currently logged in session - in this case there might be a risk that user1 is logged as user2 by the firewall).
What about that RDP case - will a support person who login through RDP (to assist currently logged in desktop user) produce a different eventid compared to if the login is on the physical console? I mean it this perhaps something that PA is already addressing (local vs remote users) or is it even possible to address?
2) Sounds great!
This mean that being logged in to the desktop and at the same time login to a VDI/Citrix/RDP session elsewhere as long as its a terminal server running TS-agent would make both ip's to be identified as the particular user (in the terminal server case along with which srcip is being used).
This is why I said 'eventually' for Exchange logs , same for 'file server' logs : it happens very often that people access a shared directory with a secondary login. Secretaries also often open their boss mailbox with their boss login ... etc etc, many many grey cases that may make these methods greyish.
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!