What is a "large" deployment for User-ID on the firewall?

[rgraves]

We have a pair of 5020s and about 4000 users on 4 AD controllers. Throughout the 4.0 and 4.1 series, we have seen the Windows-based UserID Agent drop groups and users, and are interested in seeing if native event log polling from 5.0 might help. Target date is mid-March, by which point we hope 5.0 to be somewhat stable.

The documentation says that the UserID Agent is still supported and recommended for "large" deployments. Can anyone quantify that? I consider us "small," but to the extent that PAN firewalls have displaced UTM and web filters, maybe we're "medium."

[mikand]

I got the impression that the built in PAN-agent (which lives in the mgmtplane of PANOS 5.0 and upwards) is mainly for small deployments.

Like max 100 users/clients or so...

But I could be wrong... it would however be really nice if the built in PAN-agent is all you need when running PANOS 5.0 even for larger deployments (thousands or ten of thousands of clients).

The problem is that the security log can be somewhat large when it comes to bandwidth. And in a large deployment there can be up to 100 DC-servers which, if you are unlucky, would mean up to 500Mbit/s just in security log being sent to the PA-device. The bandwidth between PAN-agent and each PA-device is much lower than the bandwidth between each PAN-agent and DC-servers.

[jochristian]

Hello,

I have previously asked support about this since we have considered using agentless user-id in a large deployment. Here are the numbers that I got:

It depends on a few things. It depends on the number of DCs that are involved and the type of device the customer is using.

If its a 500 series you should be fine monitoring up to 10 servers. Same is true for a 200 series. The 2000 series has only little memory in the management plane, which is why I would possibly only monitor 2-5 servers.
Other devices like the new 3000 series or the 5000 series have more memory in the management plane. Meaning monitoring up to 50 servers should work fine."

So the limitation is not the number of users but number of DCs that is monitored.

As for your installation you should be fine with using agentless installation, but remember if you got "slow" links between the PA and the DC's you should consider installing the user-id agent.

Jo Christian

[reaper · Accepted solution]

Hi

The limitation does lie in the amount of servers monitored and these are limited by the platform and the resources available to the mgmt plane as JoChristian mentions above.

The maximum amount of users is identical across all platforms which is currently 64k on the DP users and 640 groups, so a pair of 5020's with 4 AD's and 4k users should not be a problem at all

regards

Tom

[ericgearhart]

We have case number 00110330 open right now, describing symptoms that mirror this same issue. On our PA5020s we only have 835 out of 2,000 users sync'ing.

[mikand]

So even with 32.000 users and lets say 50 DC servers it should not be any problem of using the internal PAN-agent if you run 3000-series and upwards?

Any drawbacks by using this internal PAN-agent other than the bandwidth needed between the PA device and all DC's ?

Will for example commit times run away as with 2000-series?

[Ludwig]

To be a little bit more specific concerning the 640 groups "a firewall can hold": --> This is only the number of groups that can be used in the policies of the firewall (source or destination user section), but the firewall can store more than 640 groups in its database, which of course is a MUST because many customers might have more than 640 groups in their ADs.

To see the actual number of different groups, you can use the following command on the CLI:

show user group list | match Total

This shows the number of groups.