User delete operations take an excessive period of time to perform on excessively large static groups in RSA Access Manager 6.0.4
2 years ago
Originally Published: 2010-04-12
Article Number
000054174
Applies To
RSA Product Set: Access Manager 6.0.4
RSA Product/Service Type: All LDAP datastores, All OS
RSA Version/Condition: 6.0.4



 
Issue
AxM 6.04 - User delete operations take an excessive period of time to perform on excessively large static groups
In timing this search that the adminAPI uses to delete a user which belongs to an excessively large static group:

ldapsearch -h 192.168.131.196 -D "cn=admin" -w thePassword -b "ou=Groups,dc=mydomain,dc=com" -s sub "(&(objectclass=groupOfUniqueNames)(uniquemember=uid=test_user4,ou=people,dc=mycompany,dc=com))"

...the search is extremely slow, causing the delete operation to take upwards of 12 seconds.  Please note, the static group in this instance is over 60,000 users (see notes section.  60k users in a static group far exceed any published maximum static group size as published by the vendor.  The datastore in place in this instance is Oracle OID, who publishes their maximum static user group at 10k).

When the search is changed to include the dn in the search criteria:

 ldapsearch -h 192.168.131.,196 -D "cn=admin" -w thePassword -b "ou=Groups, mydomain,dc=com" -s sub "(&(objectclass=groupOfUniqueNames)(uniquemember=uid=test_user4,ou=people,dc=mydomain,dc=com))" dn

...the search returns in milliseconds.  While the second search is a far more efficient search (even when the static group size is excessively large), an issue such as this should never be encountered when the vendors recommended static group limits are adhered to.
 
Cause
Excessively large static groups are historically known to cause performance problems in LDAP.  Major LDAP vendors have long since recognized the limitations of excessively large static groups, and publish thresholds on when to expect substantial performance impact based on membership size.  The answer to how deal with a performance problem imposed by a large static group is simply don't use them.  Static groups in LDAP as a technology feature is an antiquated notion.  Dynamic groups have long since been introduced by all major LDAP vendors as the solution to the limitations large static groups impose. When anticipating an excessive number of group members, always choose the newer dynamic group model in designing your LDAP deployment.  In AxM, exploit that by using the smart rule model, which will key off of group membership for entitlements via the dynamic group membership attribute as designed by vendor (isMemberOf, memberOf etc).

Some examples of static group membership limitations as published by vendor:

Sun publishes the maximum threshold at 20k members before performance is impacted:

http://docs.sun.com/source/816-2672/dit.htm#1005297

Microsoft Active Directory publishes the maximum threshold at 5k before performance is impacted:

http://technet.microsoft.com/en-us/library/cc756101%28WS.10%29.aspx

Oracle publishes the max threshold at 10k before performance is impacted:

http://download.oracle.com/docs/cd/E10761_01/doc/oam.1014/e10353/perform.htm#CFHGBGEA

 
Resolution
When static group membership is expected to approach or exceed the published limitation, DO NOT USE static group entitlements.  Use the far more efficient and modern dynamic group membership model with  AxM smart rules for entitlements

Because there is a more efficient way for the adminAPI to perform the group search during the delete operation, the AxM 6.04 server has been modified to use the faster method.   Please contact customer support and request cleartrust.jar hotfix 6.0.4.46 or higher.
 
Notes
Also insure the ldap.conf setting below is set as demonstrated here to maximize performance:add_to_default_admin_group  :false

 

Related Articles

Trending Articles

Don't see what you're looking for?