If Access Manager is installed in Realm mode, whenever a new group is created, Access Manager dynamically creates a new Group Admin with the ACIs necessary to manage the group. In Realm mode, these Group Admin ACIs are not used. Directory Server, however, still evaluates them while processing entries under the suffix, which can degrade Access Manager performance, particularly if a deployment creates a large number of groups.
Workaround: The workaround for this problem involves two parts:
Preventing Access Manager from creating a Group Admin and corresponding ACIs whenever a new group is created
Removing any existing Group Admin ACIs from Directory Server
Preventing Group Admin ACIs From Being Created
The following procedure prevents Access Manager from creating a Group Admin and corresponding ACIs whenever a new group is created.
This procedure permanently prevents the creation of Group Admins and corresponding ACIs whenever a new group is created. Use this procedure only if this behavior is appropriate for your specific deployment.
Backup the amAdminConsole.xml file. This file is located in the following directory, depending on your platform:
Solaris systems: /etc/opt/SUNWam/config/xml
Linux and HP-UX systems: /etc/opt/sun/identity/config/xml
Windows systems: javaes-install-dir\identity\config\xml
javaes-install-dir represents the Java ES 5 installation directory. The default value is C:\Program Files\Sun\JavaES5.
In the amAdminConsole.xml file, remove the following Group Admin entry, shown between the comment lines:
<AttributeSchema name="iplanet-am-admin-console-dynamic-aci-list" type="list" syntax="string" i18nKey="g111"> <DefaultValues> ... # Beginning of entry to delete <Value>Group Admin|Group Admin Description|ORGANIZATION:aci: (target="ldap:///GROUPNAME")(targetattr = "*") (version 3.0; acl "Group and people container admin role"; allow (all) roledn = "ldap:///ROLENAME";)##ORGANIZATION:aci: (target="ldap:///ORGANIZATION") (targetfilter=(&FILTER(!(|(nsroledn=cn=Top-level Admin Role,dc=iplanet,dc=com) (nsroledn=cn=Top-level Help Desk Admin Role,dc=iplanet,dc=com) (nsroledn=cn=Top-level Policy Admin Role,dc=iplanet,dc=com) (nsroledn=cn=Organization Admin Role,ORGANIZATION) (nsroledn=cn=Container Admin Role,ORGANIZATION) (nsroledn=cn=Organization Policy Admin Role,ORGANIZATION))))) (targetattr != "iplanet-am-web-agent-access-allow-list || iplanet-am-web-agent-access-not-enforced-list|| iplanet-am-domain-url-access-allow || iplanet-am-web-agent-access-deny-list ||nsroledn") (version 3.0; acl "Group admin's right to the members"; allow (read,write,search) roledn = "ldap:///ROLENAME";)</Value> # End of entry to delete ... </DefaultValues> </AttributeSchema>
Use amadmin to delete the Admin Console service from Access Manager. For example, on Solaris systems:
# cd /opt/SUNWam/bin # ./amadmin -u amadmin -w amadmin_password --deleteservice iPlanetAMAdminConsoleService
Use amadmin to reload the Admin Console service into Access Manager from the edited amAdminConsole.xml file from Step 2. For example:
# ./amadmin -u amadmin -w amadmin_password -s /etc/opt/SUNWam/config/xml/amAdminConsole.xml
Restart the Access Manager web container. (If you plan to remove ACIs from Directory Server, as described in the next procedure, wait and restart the web container after you finish that procedure.)
Removing Existing Group Admin ACIs
The following procedure uses the ldapsearch and ldapmodify utilities to find and remove the Group Admin ACIs. If your deployment is using Directory Server 6.0, you can also use the Directory Server Control Center (DSCC) or the dsconf command to perform these functions. For more information, see the Directory Server 6.0 documentation:
http://docs.sun.com/app/docs/coll/1224.1
The following procedure removes Group Admin ACIs that already exist in Directory Server.
Create an LDIF file to use with ldapmodify to remove the Group Admin ACIs. To find these ACIs, use ldapsearch (or another directory search tool, if you prefer).
For example, the following entries in the sample LDIF file named Remove_Group_ACIs.ldif will remove the ACIs for a group named New Group:
dn: ROOT_SUFFIX changetype: modify delete: aci aci: (target="ldap:///cn=New Group,ou=Groups,o=isp")(targetattr = "*") (version 3.0; acl "Group and people container admin role"; allow (all) roledn = "ldap:///cn=cn=New Group_ou=Groups_o=isp,o=isp";) dn: ROOT_SUFFIX changetype: modify delete: aci aci: (target="ldap:///ou=People,o=isp")(targetattr="nsroledn") (targattrfilters="add=nsroledn:(!(nsroledn=*)), del=nsroledn:(!(nsroledn=*))") (version 3.0; acl "Group admin's right to add user to people container"; allow (add) roledn = "ldap:///cn=cn=New Group_ou=Groups_o=isp,o=isp";) dn: ROOT_SUFFIX changetype: modify delete: aci aci: (target="ldap:///o=isp") (targetfilter=(&(|(memberof=*cn=New Group,ou=Groups,o=isp) (iplanet-am-static-group-dn=*cn=New Group,ou=Groups,o=isp)) (!(|(nsroledn=cn=Top-level Admin Role,o=isp) (nsroledn=cn=Top-level Help Desk Admin Role,o=isp) (nsroledn=cn=Top-level Policy Admin Role,o=isp) (nsroledn=cn=Organization Admin Role,o=isp)( nsroledn=cn=Container Admin Role,o=isp) (nsroledn=cn=Organization Policy Admin Role,o=isp))))) (targetattr != "iplanet-am-web-agent-access-allow-list || iplanet-am-web-agent-access-not-enforced-list || iplanet-am-domain-url-access-allow || iplanet-am-web-agent-access-deny-list ||nsroledn") (version 3.0; acl "Group admin's right to the members"; allow (read,write,search) roledn = "ldap:///cn=cn=New Group_ou=Groups_o=isp,o=isp";) aci: (target="ldap:///o=isp")(targetattr="*") (version 3.0; acl "S1IS special dsame user rights for all under the root suffix"; allow (all) userdn = "ldap: ///cn=dsameuser,ou=DSAME Users,o=isp"; )
Use ldapmodify with the LDIF file from the previous step to remove the Group ACIs from Directory Server. For example:
# ldapmodify -h ds-host -p 389 -D "cn=Directory Manager" -w ds-bind-password -f Remove_Group_ACIs.ldif
Restart the Access Manager web container.