The regular method of using dedicated userid/pan-agent servers will most likely not scale that well for enterprise use. You might consider install the userid/pan-agent service on each DC and lock it to only follow the security log from localhost. That is because the userid/ip mapping is done by tailing/following the security log (events 672, 673 and 674 for Win2003 DCs and events 4768, 4769 and 4770 for Win2008 DCs) and when a user logins to the domain only the DC who authed the user will log its presence (the security log is not replicated within the domain for some odd reason). With a network of just 2 DCs this is not a problem (even if you have 10.000 concurrent users). But if you have lets say have 50 DCs (with 10.000 concurrent users) the math will be something like (with 2 PA devices): - Dedicated userid/pan-agent servers (tailing security log of each DC over the network): 50 * 5Mbit/s * 2 + 2 * 0-100kbit/s ~= 500Mbit/s network load (5Mbit/s is estimated network load to follow a single DC in an environment with approx 10.000 concurrent users). vs. - Userid/pan-agent installed on each DC (and configured to only read the local security log): 50 * 0-100kbit/s * 2 ~= 0-10Mbit/s network load (that is each PA device (2 of them in this example) will connect directly to each DC (who runs the userid/pan-agent service)). Having that said there are a number of quirks that one must be able to handle. One is how large TTL/cache timeout would you use? Too small will raise the bandwidth needed for the userid stuff (along with cpu usage of mgmtplane) while too large will end up with wrong user might be logged. For example if user1 logins, then unplugs their laptop and then user2 (who already is logged in) plugs their laptop into the network and get the same ip as user1 (just an example). If you have a TTL of 1 hour then the log in PA might display the incorrect user for up to 1 hour. So the fix here is obviously to choose as small TTL/cache timeout as possible. Another fix to better track users is to enable WMI lookups along with server logs inspection (for example inspect logs of ms exchange server) - this way you will have more sources to have your user-ip mapping better updated. Another quirk which comes from how AD works is that there doesnt seem to be any logout event, basically because users can hibernate and all sort of things (or just unplug their box). A workaround for this is to use the XML api of PA and perhaps write your own syslog tail script that could inspect arp logs from switches and other stuff in order to invalidate specific ip addresses. The above is to track users who are logged in to a AD. Another tracking method is the ts-agent. However ts-agent is meant to be used on citrix servers and works by informing the PA box which user is currently logged in and which srcport range is associated with this client. When doing stuff from a citrix server each client gets a dedicated srcport range which gives that the ts-agent have a better "hitrate" than the AD-tracking pan-agent but at the same time they are meant for different purposes. I think globalprotect (without the VPN stuff) can also be used to also inform your PA devices who is logged in at a specific srcip.
... View more
