User-ID agent and 300,000 LDAP UID's

[KatanaNZ]

I need to run user Identification of a Sun-One LDAP server, that has two main classes for users, totalling 300,000 users, in one geographic location.

What is the maximum number of entries a user-id agent can handle/cache etc?

Would the best configuration here, be to use multple agents, and hae each agent pull UID's using the object class filter?

So a-k initial letters by one, l-s on another etc?

[ukhapre]

There is no limit for user agent entries. Its saved in a txt file.

It would be good to setup agent for each geographical location.

[KatanaNZ]

So the previous limitation of 65k odd entries has been removed?

Are the entries cached in memory for fast access, instead of reading through this txt file, as this is one geographical location,

and I'd like to limit the number of agents deployed.

Ideally it will be just the one, but then how do I calculate the amount of memory needed to hold 300,000 UIDs?

[skrall]

We do have a cache and it has a limit. All excess entries are stored in the text file.  If you are a large company with sites in different geographic locations, there is no need to download all groups and all users. For best performance you should identify the groups or IP subnets that need to get identified per site. Will users on the east coast be passing traffic throogh firewalls on the west coast? If not this allows you to reduce the number of users and IPs that an agent needs to track.  One requirement is that you will need one agent per domain. This is a requirement. But you can also do an agent per site if this makes sense. If you create firewalls that are heavily dependent on user-id, you may want to consider running a second agent for redundancy. If the agent were to fail for some reason, the firewall caches user-id information for one hour. If the agent has not reconnected in that time, all users become "unknown" and will drop through the rule base to something that has no user-id requirement.

SKrall

[KatanaNZ]

So this is where the location is a little different. All 300,000 UID's are on one site, which is one geographic location.

They need to by law keep all accounts active for 5-7 years after last use.

Instead of caching all users, can we only cache and hold users that we lookup, thereby only pulling in active users?

Being on one site, would it make sense to not cache any users, and how does this affect performance?

[pflanagan]

Any ideas on this? We have a single domain with 600,000 users in one location and we experience tons of problems whenever we connect this agent to the firewall (it even screws up other agents that were previously working fine).

Of the 600,000, only approximately 10,000 are active at any given time but it's impossible to narrow them down by IP address, location, etc.

It seems like the User ID Agent is sending the firewall all 600,000 users rather than active users only?

[KatanaNZ]

Nothing definative as yet, but have some ideas around object classes to determine UID classification, including active/inactive users etc.