User-ID on incoming connections

[BrutalDismount]

So, we are currently using the user-id agent to monitor our CAS exchange servers. This is working great for identifiying our internal users hitting exchange from the inside. However I would like to begin identifying users that are accessing the CAS servers from the outside. I have tested this with a single IP address range added to the user-ID agent on our DC's to verify that it is indeed possible. This was also successfull.

The question I have is - Can one (or should one) include all IP addresses into the User-ID agent? Will this be too much overhead for the User-ID agent and or PA to handle? Is the IP include/exclude match occur before or after an appropriate event is found within the event stream? What will happen to the WMI probing process?

[mikand]

Hopefully you have your clients segmented away from the servers which gives that adding only the clientip ranges should be enough (and most optimized).

For clients from for example Internet I assume you use some kind of VPN and this will have internal ip's that your internal firewall will see.

I imagine that if you add 0.0.0.0/0 as ip range the user-id agent will try to resolve connections it doesnt have to, like connection from another server.

But sure - if the process running on the source server is using a specific account you could use userid to limit not only on zone, ip, service (port) and appid but also userid. But I dont know how user-id agent is compatible with such approach (since on the server there is normally noone logged in on the console and each process runs with their own user).

[Jeff_K]

I think the User-ID Agent must process every relevant event in the security log regardless of your include/exclude list.  The include/exclude list is simply a control mechanism for what addressing the agent ultimately provides user mapping for. I think including all addressing will have negligible effect on performance. 

I wouldn't want the agent to do a WMI probe of an external client.  For external users it might be better to run a separate agent with all the probing options turned off... exclude all private addressing and include 0.0.0.0/0. 

Jeff

[BrutalDismount]

What we are trying to accomplish is to correlate a user with a file block/data filter rules that we have on connections coming from the internet into our DMZ OWA server. Right now it is a manual process; We see a data filter get triggered, then we have to get the source public IP and dig into the OWA IIS logs to see what AD user logged in from that IP.

I will probaly increase the included IP ranges slowly to see how the user-agent reacts. It already takes up a healthy amount of memory.