User-ID and Windows clients running GPO's with another useraccount !

[sbjornstad]

Hi ppl !

We have a problem regarding User-Id and the security log from windows AD. Normally when the user logs in on a windows pc and connect to AD, the USer-Id and ip > username  maps correct.

The problem occurs when a "GPO" on the client starts up with system privilegies and another user account (administrator rights account). These gpo's runs with the same user privilegies on all clients on a schedule.

The user > ip mapping in windows security log will then contain the "adminstrator" user and the original user will no longer exists until the user himself connects to AD (open the fileshare/connect to exchange).

The result is that the user will loose connection until he reconnect to AD and the user > ip is correct again.

I have configured the firewall to ignore the user that runs the GPO and the result is that i have no "source user" in monitor and the session is dropped in FW.

If i dont ignore the user, a lot of computer will get internet connections with the same user-id. This will compromise our security policy.

Hope some of you have any ideas how to solve this problem.

Regards

[kfindlen]

If a system account performs an authentication to the AD server then the user mapping will change.  You can configure the Agent to ignore specific user accounts on the domain by configuring the ignore list.  If the ignore list was configured for the "administrator" account in this case, the Agent would not create a mapping for that account whenever it authenticates.

See document: https://live.paloaltonetworks.com/docs/DOC-2893

[mikand]

What about remote support such as RDP or such?

Where the support dude/dudette login to the /console on the client who wish assistence to help out through remote administration or for that matter bounce through a SCCM server (or whatever they are called).

[kfindlen]

I would think that a domain account being used for RDP would need to be excluded as well or the agent would think a new user logged in and would update the mappings as needed. 

The agent is simply looking for particular events hitting the security log on the domain controller.  If the client machine authenticates a remote support session (or any other non-interactive login) in the same way that a normal login would be processed then the Agent has no way to differentiate between the two.  The only capability the Agent has is to exclude specific usernames that are not being used for a normal user login so service accounts don't cause the active user's mapping to be overwritten.