This section describes the following known issues and workarounds, if available, at the time of the Access Manager 7.1 release.
Information about Java System Enterprise installation issues is contained in the Java Enterprise System 5 Release Notes. See the section Access Manager Installation Issues in Sun Java Enterprise System 5 Release Notes for UNIX.
This section contains the following Known Issues:
There is a known issue with the single WAR deployed on Weblogic 8.1, with JAX-RPC initialization. In order for Access Manager to communicate with the client SDK, you need to replace the JAX-RCP 1.1 jar files with JAX-RPC 1.0 jar files.
Workaround:
There are two ways to obtain the WAR file. One is through the Java Enterprise System 5 installer with Access Manager set to the Configure Later option, the other is from Sun's download site.
If you have generated the WAR file through the Java Enterprise System 5 installer with the Configure Later option:
Remove the following JAXRPC 1.1 .jar files from AccessManager-base/SUNWam/web-src/WEB-INF/lib:
jaxrpc-api.jar
jaxrpc-spi.jar
jaxrpc-impl.jar
Copy the following .jar files from their respective locations to AccessManager-base/SUNWam/web-src/WEB-INF/lib:
jaxrpc-api.jar from /opt/SUNWam/lib/jaxrpc 1.0
jaxrpc_ri.jar from /opt/SUNWam/lib/jaxrpc 1.0
commons-logging.jar from /opt/SUNWmfwk/lib
Goto AccessManager-base/SUNWam/bin/ and run the following command:
amconfig —s samplesilent
For more information on configuring Access Manager using the amconfig script, see Running the Access Manager amconfig Script in the Access Manager Post Installation Guide.
If you have obtained the WAR file through the Oracle download site (http://www.oracle.com/technetwork/indexes/downloads/index.html):
Acquire the ZIP_ROOT/applications/jdk14/amserver.war file and explode it into a staging area, such as /tmp/am-staging.
Remove the following JAXRPC 1.1 .jar files from /tmp/am-staging/WEB-INF/lib:
jaxrpc-api.jar
jaxrpc-spi.jar
jaxrpc-impl.jar
Copy the following JAXRPC 1.0 .jar files and the commons logging .jar file, located in the ZIP_ROOT/applications/jdk14/jarFix directory to /tmp/am-staging/WEB-INF/lib:
jaxrpc-api.jar
jaxrpc-ri.jar
commons-logging.jar
Recreate and deploy the Access Manager WAR. For more information, see Deploying Access Manager as a Single WAR File in the Access Manager Post Installation Guide.
If the Access Manager single WAR is generated using the Java Enterprise System 5 installer with the Configure Later option, additional .jar files are required before you deploy Websphere 5.1.
Workaround:
Copy jsr173_api.jar from /usr/share/lib to the AcessManager-base/opt/SUNWam/web-src/WEB-INF/lib directory.
Goto AccessManager-base/SUNWam/bin/ and run the following command:
amconfig —s samplesilent
For more information on configuring Access Manager using the amconfig script, see Running the Access Manager amconfig Script in the Access Manager Post Installation Guide.
In order for the Access Manager single WAR deployment with Websphere 5.1 to successfully communicate with the client SDK, you must make changes to the server.xml file.
Workaround:
To correctly change the server.xml file, see the following steps:
Acquire the amserver.war file. There are two ways to get the single WAR file; through the Java Enterprise System 5 installer with the Configure Later option, or through the sun download site.
If you have generated the WAR file through the Java Enterprise System 5 installer, make sure that you complete the steps outlined in Known Issue #6550261.
Explode the Access Manager WAR into a staging area, for instance /tmp/am-staging.
Copy the following shared .jar files from /tmp/am-staging/WEB-INF/lib to a shared location, such as/export/jars:
jaxrpc-api.jar jaxrpc-spi.jar jaxrpc-impl.jar saaj-api.jar saaj-impl.jar xercesImpl.jar namespace.jar xalan.jar dom.jar jax-qname.jar jaxb-api.jar jaxb-impl.jar jaxb-libs.jar jaxb-xjc.jar jaxr-api.jar jaxr-impl.jar xmlsec.jar swec.jar acmecrypt.jar iaik_ssl.jar iaik_jce_full.jar mail.jar activation.jar relaxngDatatype.jar xsdlib.jar mfwk_instrum_tk.jar FastInfoset.jar jsr173_api.jar
Remove the same .jar files from the /tmp/am-staging/WEB-INF/lib in the staging area.
Update the Webshpere instance's server.xml. Make the changes to jvmEntries in server.xml if your default instance location is/opt/WebSphere/AppServer/config/cells/node-name/nodes/node-name/servers/server1, as shown below:
<classpath>/export/jars/jaxrpc-api.jar:/export/jars/jaxrpc-spi.jar: /export/jars/jaxrpc-impl.jar:/export/jars/saaj-api.jar: /export/jars/saaj-impl.jar:/export/jars/xercesImpl.jar: /export/jars/namespace.jar:/export/jars/xalan.jar:/export/jars/dom.jar: /export/jars/jax-qname.jar:/export/jars/jaxb-api.jar:/export/jars/jaxb-impl.jar: /export/jars/jaxb-libs.jar:/export/jars/jaxb-xjc.jar:/export/jars/jaxr-api.jar: /export/jars/jaxr-impl.jar:/export/jars/xmlsec.jar:/export/jars/swec.jar: /export/jars/acmecrypt.jar:/export/jars/iaik_ssl.jar: /export/jars/iaik_jce_full.jar:/export/jars/mail.jar: /export/jars/activation.jar::/export/jars/relaxngDatatype.jar: /export/jars/xsdlib.jar:/export/jars/mfwk_instrum_tk.jar: /export/jars/FastInfoset.jar:/export/jars/jsr173_api.jar</classpath>
Restart the container.
Recreate and deploy the Access Manager WAR from /tmp/am-staging. For more information, see Deploying Access Manager as a Single WAR File in the Access Manager Deployment Planning Guide.
The Distributed Authentication WAR requires additional jar files for parsing for both Weblogic 8.1 and Websphere 5.1 because the container is version JDK14. The JDK14 .jar files are located in the following directory of the .zip file:
ZIP-ROOT/applications/jdk14/jarFix
Workaround:
For Weblogic 8.1:
Configure Distributed Authentication using the setup scripts. See Deploying a Distributed Authentication UI Server in the Access Manager Post Installation Guide.
Explode the updated Distributed Authentication WAR into a temporary location, such as /tmp/dist-auth.
Copy xercesImpl.jar, dom.jar and xalan.jar to the /tmp/dist_auth/WEB-INF/lib directory from ZIP-ROOT/applications/jdk14/jarFix.
Regenerate the Distributed Authentication WAR from the temporary location and deploy it. For more information, see Deploying a Distributed Authentication UI Server WAR File in the Access Manager Post Installation Guide.
For Websphere 5.1:
Configure Distributed Authentication using the setup scripts. See Deploying a Distributed Authentication UI Server in the Access Manager Post Installation Guide.
Explode the updated Distributed Authentication WAR into a temporary location, such as /tmp/dist_auth/.
Copy xercesImpl.jar, dom.jar and xalan.jar to the /tmp/dist_auth/WEB-INF/lib directory from ZIP-ROOT/applications/jdk14/jarFix.
Edit theWEB-INF/web.xml file and replace jar://web-app_2_3.dtd with http://java.sun.com/dtd/web-app_2_3.dtd.
Regenerate the Distributed Authentication WAR from the temporary location and deploy it. For more information, see Deploying a Distributed Authentication UI Server WAR File in the Access Manager Post Installation Guide.
Access Manager deployed as a single WAR fails to configure on Directory Server 6 with a single component root suffix, for example. dc=example. However, it works with multi component root suffix, for example dc=example,dc=com. After running the configurator with configuration datastore as Sun Java System Directory server, it is always advised to go and edit the serverconfig.xml to replace the cn=directory manager with less privileged user, such as cn=dsameuser. This user should be available in the directory server with proper access permissions to the Access Manager service tree.
Workaround: Use the multi component root suffix, for example dc=example,dc=com.
When configuring the second instance of Access Manager single WAR on the same host against Directory Server, it throws an exception while updating the Organization Alias. This issue does not occur if the second instance configured is on a different host.
For additional information, see Upgrade Issues in Sun Java Enterprise System 5 Release Notes for UNIX.
The Required Services functionality is not supported in Realm Mode. Required Services are services that are dynamically added to user entries when the entries are created. Required Services are not supported for users created under the Access Control tab (that is, using the realm feature) because these users will be under the services node. This scenario applies to an Access Manager 7.1 installation in Legacy Mode or the coexistence of Access Manager 7.1 in Legacy Mode with Sun OpenSSO Enterprise 8.0.
However, the Required Services functionality is supported as follows:
Access Manager 7.1 Legacy Mode with the old Console.
Access Manager 7.1 Legacy Mode with the new Console for users created under the Directory Manager tab (that is, using the legacy feature) and for users dynamically created using the amadmin CLI under the User Management DIT and not the realm DIT.
Access Manager Single Sign-On fails on Universal Web Client (6367058, 6429573)
StackOverflowError occurs on Web Server 7.0 running in 64–bit mode (6449977)
Incompatibilities exist in core authentication module for legacy mode (6305840)
Delegated Administrator commadmin utility does not create a user (6294603)
Delegated Administrator commadmin utility does not create an organization (6292104)
The problem occurs after you install Access Manager, Messaging Server, and Calendar Server and configure them to work together, and then install the Java Enterprise System 5 120955-01 patch. The user encounters a login error. The error is due to an incompatibility between Policy Agent 2.1 properties and AMSDK. There is no workaround at this time.
If Access Manager is configured on a Web Server 7.0 instance using a 64–bit JVM, the user encounters a Server Error message when accessing the console login page. The Web Server error log contains a StackOverflowError exception.
Workaround: Modify the Web Server configuration by following these steps:
Log in to the Web Server administration console as the Web Server administrator.
Click Edit Configuration.
In the Platform field, select 64, then click Save.
Click the Java tab, and then click the JVM Settings tab.
Under Options, look for the minimum heap size entry (for example : -Xms). The minimum heap size value should be at least 512m. For example, if the heap size value is not -Xms512m or greater, then change the value to at least -Xms512m.
The maximum heap size value should be at least 768m. If the maximum heap size is not -Xmx768m or greater, then change the value to at least -Xmx768m.
Set the Java stack size to 512k or 768k by using -Xss512k or -Xss768k. You can leave it at the default size for 64-bit JVM on Solaris Sparc (1024k) by leaving it blank.
Click the Performance tab, then click the link "Thread Pool Settings.”
Change the stack size value to at least 261144, and then click Save.
Click the "Deployment Pending" link in the upper right corner of the screen.
In the Configuration Deployment page, click the Deploy button.
In the Results window, click OK to restart the Web Server instance.
Click the Close in the Results window after the Web Server has been restarted.
Access Manager 7.1 legacy mode has the following incompatibilities in the core authentication module from Access Manager 6 2005Q1:
Organization Authentication Modules are removed in legacy mode.
The presentation of the “Administrator Authentication Configuration” and “Organization Authentication Configuration” has changed. In the Access Manager 7.1 Console, the drop-down list has ldapService selected by default. In the Access Manager 6 2005Q1 Console, the Edit button was provided, and the LDAP module was not selected by default.
Workaround: None.
The Delegated Administrator commadmin utility with the -S mail,cal option does not create a user in the default domain.
Workaround: This problem occurs if you upgrade Access Manager to version 7.1 but you do not upgrade Delegated Administrator.
If you do not plan to upgrade Delegated Administrator, follow these steps:
In the UserCalendarService.xml file, mark the mail, icssubcribed, and icsfirstday attributes as optional instead of required. This file is located by default in the /opt/SUNWcomm/lib/services/ directory on Solaris systems.
In Access Manager, remove the existing XML file by running the amadmin command, as follows:
# ./amadmin -u amadmin -w password -r UserCalendarService
In Access Manager, add the updated XML file, as follows:
# ./amadmin -u amadmin -w password -s /opt/SUNWcomm/lib/services/UserCalendarService.xml
Restart the Access Manager web container.
The Delegated Administrator commadmin utility with the -S mail,cal option does not create an organization.
Workaround: See the workaround for the previous problem.
Incorrect console redirection behind a load balancer (6480354)
Password Reset service reports notification errors when a password is changed (6455079)
Account Locking feature fails to send email notification when the user's account is locked (6760137)
Platform server list and FQDN alias attribute are not updated (6309259, 6308649)
Data validation for required attributes in the services (6308653)
Document workaround for deployment on a secure WebLogic 8.1 instance (6295863)
The amconfig script does not update the realm/DNS aliases and platform server list entries (6284161)
Default Access Manager mode is realm in the configuration state file template (6280844)
If you have Access Manager instances deployed behind a load balancer, login to the Access Manager Console may be redirected to one of the Access Manager instances rather than to the load balancer. The URL in the browser also changes to the Access Manager instance. For example, this problem can occur if you login into the Console using this URL:
http://loadbalancer.example.com/amserver/realm
This redirection can occur in both Realm mode and Legacy mode deployments.
There are two workarounds for this issue. You can use either one:
Login with either of the following URLs:
http://loadbalancer/amserver/UI/Login
http://loadbalancer/amserver
In AMConfig.properties, set the com.sun.identity.loginurl property to the name of the loadbalancer. This needs to be done on each Access Manager Instance behind the load balancer.
If you install the Access Manager SDK without a web container by running the Java ES 5 installer with the Configure Now option, the com.iplanet.am.notification.url property in the AMConfig.properties file is set to NOTIFICATION_URL. If you don't perform any additional web container configuration, users will not receive notifications from the remote Access Manager server.
Workaround: Reset this property as follows: com.iplanet.am.notification.url=""
When a password is changed, Access Manager submits the email notification using an unqualified sender name Identity-Server, which results in errors entries in the amPasswordReset logs. For example:
07/19/2006 10:26:04:010 AM PDT: Thread[service-j2ee,5,main] ERROR: Could not send email to user [Ljava.lang.String;@999262 com.sun.mail.smtp.SMTPSendFailedException: 553 5.5.4 <Identity-Server>... Domain name required for sender address Identity-Server |
Workaround: The following workaround is for Solaris systems. For other platforms such as Linux, Windows, or HP-UX, adjust the base installation directory for the specific platform.
In /opt/SUNWam/locale/amPasswordResetModuleMsgs.properties, change fromAddress.label=<Identity-Server> to fromAddress.label=<IdentityServer@myhost.company.com>.
In /opt/SUNWam/locale/amAuth.properties, change the lockOutEmailFrom property from Password-Administrator to Password-Administrator@myhost.company.com.
Restart Access Manager server.
If the Account Locking feature is enabled and a user is locked out after a defined number of failures, an email notification is not sent.
Workaround. Change the lockOutEmailFrom property as described in Step 2 of the workaround for Password Reset service reports notification errors when a password is changed (6455079) and then restart Access Manager server.
In a multiple server deployment, the platform server list and FQDN alias attribute are not updated if you install Access Manager on the second (and subsequent) servers.
Workaround: Add the Realm/DNS aliases and platform server list entries manually. For the steps, see the section Adding Additional Instances to the Platform Server List and Realm/DNS Aliases in Sun Java System Access Manager 7.1 Postinstallation Guide.
Access Manager 7.1 enforces required attributes in service XML files to have default values.
Workaround: If you have services with required attributes that do not have values, add values for the attributes and then reload the service.
If you deploy Access Manager 7.1 into a secure (SSL enabled) BEA WebLogic 8.1 SP4 instance, an exception occurs during the deployment of each Access Manager web application.
Workaround: Follow these steps:
Apply the WebLogic 8.1 SP4 patch JAR CR210310_81sp4.jar, which is available from BEA.
In the /opt/SUNWam/bin/amwl81config script, (Solaris systems) or /opt/sun/identity/bin/amwl81config script (Linux systems), update the doDeploy function and the undeploy_it function to prepend the path of the patch JAR to the wl8_classpath, which is the variable that contains the classpath used to deploy and un-deploy the Access Manager web applications.
Find the following line containing the wl8_classpath:
wl8_classpath= ...
Immediately after the line you found in Step 2, add the following line:
wl8_classpath=path-to-CR210310_81sp4.jar:$wl8_classpath
In a multiple server deployment, the amconfig script does not update the realm/DNS aliases and platform server list entries for additional Access Manager instances.
Workaround: Add the Realm/DNS aliases and platform server list entries manually. For the steps, see the section Adding Additional Instances to the Platform Server List and Realm/DNS Aliases in Sun Java System Access Manager 7.1 Postinstallation Guide.
By default, the Access Manager mode (AM_REALM variable) is enabled in the configuration state file template.
Workaround: To install or configure Access Manager in Legacy mode, reset the variable in the state file:
AM_REALM = disabled
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.
New Access Manager Console cannot set the CoS template priorities (6309262)
Old console appears when adding Portal Server related services (6293299)
Add ContainerDefaultTemplateRole attribute after data migration (4677779)
The new Access Manager 7.1 Console cannot set or modify a Class of Service (CoS) template priority.
Workaround: Login to the Access Manager 6 2005Q1 Console to set or modify a CoS template priority.
Portal Server and Access Manager are installed on the same server. With Access Manager installed in Legacy mode, login to the new Access Manager Console using /amserver. If you choose an existing user and try to add services (such as NetFile or Netlet), the old Access Manager Console (/amconsle) suddenly appears.
Workaround: None. The current version of Portal Server requires the Access Manager 6 2005Q1 Console.
Install Directory Server and then Access Manager with the existing DIT option. Login to the Access Manager Console and create a group. Edit the users in the group. For example, add users with the filter uid=*999*. The resulting list box is empty, and the console does not display any error, information, or warning messages.
Workaround: The group membership must not be greater than the Directory Server search size limit. If the group membership is greater, change the search size limit accordingly.
In Legacy mode, he user's role does not display under an organization that was not created in Access Manager. In debug mode, the following message is displayed:
ERROR: DesktopServlet.handleException() com.iplanet.portalserver.desktop.DesktopException: DesktopServlet.doGetPost(): no privilige to execute desktop
This error becomes evident after the Java ES installer migration scripts are run. The ContainerDefaultTemplateRole attribute is not automatically added to the organization when the organization is migrated from an existing directory information tree (DIT) or from another source.
Workaround: Use the Directory Server console to copy the ContainerDefaultTemplateRole attribute from another Access Manager organization and then add it to the affected organization.
An administrator assigned the Organization Admin role is not able to create a new user with the amadmin command line utility due to incorrect logging privileges.
Workaround: Both the Organization Admin and the Top-level admin may set the permissions. To do so through the Administration Console:
Go to the organization to which the Organization Admin belongs.
Click on the Privileges tab.
Click on the Organization Admin Role link.
Select Read and write access to all log files or Write access to all log files.
Click Save.
Clients do not get notifications after the server restarts (6309161)
SDK clients need to restart after service schema change (6292616)
Applications written using the client SDK (amclientsdk.jar) do not get notifications if the server restarts.
Workaround: None.
If you modify any service schema, ServiceSchema.getGlobalSchema returns the old schema and not the new schema.
Workaround: Restart the client after a service schema change.
This problem is fixed in patch 1.
When you deploy the Distributed Authentication UI server using the default application user, performance drops significantly due to the default application user's restricted privileges.
Workaround: Create a new user with appropriate privileges.
To create a new user with the proper ACIs:
In the Access Manager console, create a new user. For example, create a user named AuthUIuser.
In Directory Server console , add the following ACI.
dn:ou=1.0,ou=SunAMClientData,ou=ClientData,<ROOT_SUFFIX> changetype:modifyadd:aci aci: (target="ldap:///ou=1.0,ou=SunAMClientData,ou=ClientData,<ROOT_SUFFIX>") (targetattr = "*"(version 3.0; acl "SunAM client data anonymous access"; allow (read, search, compare) userdn = "ldap:///<AuthUIuser's DN>";) |
Notice that the userdn is set to "ldap:///<AuthUIuser's DN>".
See the instructions in the To Install and Configure a Distributed Authentication UI Server in Sun Java System Access Manager 7.1 Postinstallation Guide for editing the amsilent file, and for running the amadmin command.
In the amsilentfile, set the following properties:
Enter AuthUIuser.
Enter a password for AuthUIuser.
Save the file.
Run the amconfig script using the new configuration file. For example, on a Solaris system with Access Manager installed in the default directory:
# cd /opt/SUNWam/bin
# ./amconfig -s ./DistAuth_config
Restart the web container on the Distributed Authentication UI server.
After installation with Access Manager in legacy mode, the default configuration for the Statistics Service has changed:
The service is turned on by default (com.iplanet.services.stats.state=file). Previously, it was off.
The default interval (com.iplanet.am.stats.interval) has changed from 3600 to 60.
The default stats directory (com.iplanet.services.stats.directory) has changed from /var/opt/SUNWam/debug to /var/opt/SUNWam/stats.
Workaround: None.
After you install Access Manager, login as amadmin and add the o, sunPreferredDomain, associatedDomain, sunOrganizationAlias, uid, and mail attributes to the Unique Attribute List. If you create two new organizations with the same name, the operation fails, but Access Manager displays the “organization already exists” message rather than the expected “attribute uniqueness violated” message.
Workaround: None. Ignore the incorrect message. Access Manager is functioning correctly.
If Access Manager is deployed with Web Server as the web container using a load balancer with SSL termination, clients are not directed to the correct Web Server page. Clicking the Sessions tab in the Access Manager Console returns an error because the host is invalid.
Workaround: In the following examples, Web Server listens on port 3030. The load balancer listens on port 80 and redirects requests to Web Server.
In the web-server-instance-name/config/server.xml file, edit the servername attribute to point to the load balancer, depending on the release of Web Server you are using.
For Web Server 6.1 Service Pack (SP) releases, edit the servername attribute as follows:
<LS id="ls1" port="3030" servername="loadbalancer.example.com:80" defaultvs="https-sample" security="false" ip="any" blocking="false" acceptorthreads="1"/>
Web Server 6.1 SP2 (or later) can switch the protocol from http to https or https to http. Therefore, edit servername as follows:
<LS id="ls1" port="3030" servername="https://loadbalancer.example.com:443" defaultvs="https-sample" security="false" ip="any" blocking="false" acceptorthreads="1"/>
The default method of maintaining sessions for authentications is “internal session” instead of HttpSession. The default invalid session maximum time value of three minutes is sufficient. The amtune script sets the value to one minute for Web Server or Application Server. However, if you are using a third-party web container (IBM WebSphere or BEA WebLogic Server) and the optional HttpSession, you might need to limit the web container's maximum HttpSession time limit to avoid performance problems.
The deletion of dynamic attributes in Policy Configuration Service causes issues in editing of policies for this scenario:
Create two dynamic attributes in the Policy Configuration Service.
Create a policy and select the dynamic attributes (from Step 1) in the response provider.
Remove the dynamic attributes in the Policy Configuration Service and create two more attributes.
Try to edit the policy created in Step 2.
Results are: “Error Invalid Dynamic property being set.” No policies were displayed in the list by default. After a search is done, the policies are displayed, but you cannot edit or delete the existing policies or create a new policy.
Workaround: Before removing the dynamic attributes from the Policy Configuration Service, remove the references to those attributes from the policies.
Access Manager 7.1 startup returns the debug errors in amDelegation and amProfile debug files:
amDelegation: Unable to get an instance of plug-in for delegation
amProfile: Got Delegation Exception
Workaround: None. You can ignore these messages.
Error displayed when performing AMIdentity.modifyService (6506448)
Access Manager Login URL Returns Message "No such Organization found" (6430874)
Sub-org creation not possible from Access Manager when using amadmin (5001850)
When using AMIdentity.modifyService to set desktop service dynamic attribute on a realm, Access Manager returns a null pointer exception.
Workaround:Add the following property to AMConfig.properties and then restart the server.:
com.sun.am.ldap.connnection.idle.seconds=7200
The problem occurs under the following conditions:
Define a realm with the following realm configuration:
Top-level realm is amroot. A subrealm is example.com.
The subrealm example.com has two data stores: exampleDB and exampledminDB.
The data store exampleDB contains all the users starting at dc=example,dc=com. Supported LDAPv3 operations is set to user=read,write,create,delete,service.
The data store exampleadminDB contains an admin group for the realm. The admin group is DN: cn=example.com Realm Administrators,ou=Groups,dc=example,dc=com. This group has a single member, scarter. Supported LDAPv3 operations is set to group=read,write,create,delete.
Click the Subjects tab, then Groups, then the entry for example.com Realm Administrators.
Click the User tab.
All the users in the exampleDB data store show up as available, but scarter does not show up in the Selected field.
Workaround: Add the operation user=read to the supported LDAPv3 operations in the exampleadminDB data store.
The problem may be due to the use of mixed-case (both uppercase and lowercase) characters in the fully qualified domain name (FQDN).
Example: HostName.PRC.Example.COM
Workaround : After installation, do not use the default Access Manager login URL. Instead, in the login URL, include the LDAP location of the default organization. For example:
http://HostName.PRC.Example.COM/amserver/UI/Login?org=dc=PRC,dc=Example,dc=COM
Once you've successfully logged in to Access Manager, you can eliminate the need to enter the full path to the user's organization each time you log in to Access Manager. Follow these steps:
Go to the Realm tab in Realm mode, or go to the Organization tab in Legacy mode.
Click the default realm or organization name.
In this example, click prc.
Change all uppercase characters in the Realm/DNS Alias value to lowercase characters.
In this example, add the all-lowercase value hostname.prc.example.com to the list, and then remove the mixed-case HostName.PRC.Example.COM value from the list.
Click Save, and log out of Access Manager Console.
You can now log in using any one of the following URLs:
http://hostname.PRC.Example.COM/amserver/UI/Login
http://hostname.PRC.Example.COM/amserver
http://hostname.PRC.Example.COM/amserver/console
This problem occurs when multi-master replication is enabled between two Directory Servers and you attempt to create a sub-organization using the amadmin utility.
Workaround: In both Directory Servers, set the nsslapd-lookthroughlimit property to -1.
If the Access Manager container is running in SSL mode, and the container SSL certificate is expired, amconfig fails and may cause classpath corruption.
Workaround: If you have already run amconfig with an expired certificate, and the classpath is corrupted, first obtain a valid SSL certificate. Revert to the original domain.xml file, or a copy of the domain.xml file, in which the classpath is not corrupted. Then rerun the amconfig command:
/opt/SUNWam/bin/amconfig -s $PWD/amsamplesilent
Sample files are included in the Client SDK. These demonstrate how to write stand-alone programs and how to write web applications. The samples are located under the directory where you generated the Makefile.clientsdk, and in the following subdirectories:
.../clientsdk-samples/
.../clientsdk-webapps/
Clientsdk-samples includes samples for authentication, logging, policy and SAML stand-alone programs. Clientsdk-webapps includes samples for user management, service management, and policy programs. Each sample has a Readme.html file with instructions on compiling and running the sample program.
In order to compile the samples, the makefile should be run in the corresponding sub-directory. The Top-level makefile does not compile the samples in the sub-directories.
If you are running Application Server 8.1 on Red Hat Linux, the stack size of the threads created by the Red Hat OS for Application Server is 10 Mbytes, which can cause JVM resource problems when the number of Access Manager user sessions reaches 200.
Workaround: Set the Red Hat OS operating stack size to a lesser value such as 2048 or even 256 Kbytes, by executing the ulimit command before you start Application Server. Execute the ulimit command on the same console that you will use to start Application Server. For example:
# ulimit -s 256;
Access Manager auto configuration failed when installing on zh_TW and es locales (6515043)
HP-UX needs gettext binary with AM while installing Java Enterprise System full stack (6497926)
Workaround: In zh_TW and es locales on HP-UX platform, Access Manager has to be configured in "Config Later" mode only. Start the JavaES installer, install the Access Manager product and exit the JavaES installer. Then invoke the Access Manager configurator as shown below:
LANG=C
export LANG
Edit accessmanager-base/bin/amsamplesilent file
Run accessmanager-base/bin/amconfig -s amsamplesilent
There is no current workaround for this problem.
In realm mode, if you federate user accounts on an identity provider (IDP) and service provider (SP), terminate Federation, and then logout, an error occurs: Error: No sub organization found.
Workaround: None.
Administration console components displayed in English in the zh locale (6470543)
Current Value and New value are incorrectly displayed in the console (6476672)
Policy condition date must be specified according to English custom (6390856)
Multi-byte characters are displayed as question marks in log files (5014120)
When setting the browser locale to zh, the Administration console components are displayed in English, for example the Version, Help and Logout buttons.
Workaround: Set browser locale setting to zh-cn instead of zh.
In the localized version of the Administration console, the labels for the Current Value and New Value attributes are incorrectly displayed as label.current.value and label.new.value, respectively.
Policy condition date format labels under the Chinese locale are not displayed according to Chinese customs. Labels are proposing a date format like English date format. Related fields also accept English date format values.
Workaround: For each field, follow the date format example given in the field label.
The Client Detection function is not working properly. Changes made in the Access Manager 7.1 Console are not automatically propagated to the browser.
Workaround: There are two workarounds:
Restart the Access Manager web container after you make a change in the Client Detection section.
or
Follow these steps in the Access Manager Console:
Click Client Detection under the Configuration tab.
Click the Edit link for genericHTML.
Under the HTML tab, click the genericHTML link.
Enter the following entry in the character set list: UTF-8;q=0.5 (Make sure that the UTF-8 q factor is lower than the other character sets of your locale.)
Save, logout, and login again.
Multi-byte messages in log files in the /var/opt/SUNWam/logs directory are displayed as question marks (?). Log files are in native encoding and not always UTF-8. When a web container instance starts in a certain locale, log files will be in native encoding for that locale. If you switch to another locale and restart the web container instance, the ongoing messages will be in the native encoding for the current locale, but messages from previous encoding will be displayed as question marks.
Workaround: Make sure to start any web container instances always using the same native encoding.
Missing information when configuring Access Manager in SSL mode (6660610)
Document the roles and filtered roles support for LDAPv3 plug-in (6365196)
Document unused properties in the AMConfig.properties file (6344530)
In Chapter 8, Configuring Access Manager in SSL Mode, in Sun Java System Access Manager 7.1 Postinstallation Guide, the documentation fails to mention that the port number is changed from 80 to 443 if configure SSL for Access Manager with a secure WebServer and did not select the "Enable SSL" checkbox during installation.
Access Manager supports non-ascii characters in password fields only if the Directory Server is configured to support them. The Sun Java System Directory Server 7-Bit check plug-in should be disabled to let non-ascii characters to be stored. This flag, by default, is enabled in Directory Server 5.2 and should be disabled if non-ascii characters are needed to be entered in the userPassword entery. The 7-Bit Check Plug-in is disabled by default in Directory Server versions 6.0 and above.
After applying the respective patch, you can configure roles and filtered roles for the LDAPv3 plug-in, if the data is stored in Sun Java System Directory Server (fixes problem ID 6349959). In the Access Manager 7.1 Administration console, in LDAPv3 configuration for the “LDAPv3 Plug-in Supported Types and Operations” field, enter the values as:
role: read,edit,create,delete filteredrole: read,edit,create,delete
You can enter one or both of the above entries, depending on the roles and filtered roles you plan to use in your LDAPv3 configuration.
The following properties in the AMConfig.properties file are not used:
com.iplanet.am.directory.host com.iplanet.am.directory.port
To enable XML encryption for either Access Manager or Federation Manager using the Bouncy Castle JAR file to generate a transport key, follow these steps:
If you are using a JDK version earlier than JDK 1.5, download the Bouncy Castle JCE provider from the Bouncy Castle site (http://www.bouncycastle.org/). For example, for JDK 1.4, download the bcprov-jdk14-131.jar file.
If you downloaded a JAR file in the previous step, copy the file to the jdk_root/jre/lib/ext directory.
For the domestic version of the JDK, download the JCE Unlimited Strength Jurisdiction Policy Files from the Sun site (http://www.oracle.com/technetwork/java/index.html) for your version of the JDK. For IBM WebSphere, go to the corresponding IBM site to download the required files.
Copy the downloaded US_export_policy.jar and local_policy.jar files to the jdk_root/jre/lib/security directory.
If you are using a JDK version earlier than JDK 1.5, edit the jdk_root/jre/lib/security/java.security file and add Bouncy Castle as one of the providers. For example:
security.provider.6=org.bouncycastle.jce.provider.BouncyCastleProvider
Set the following property in the AMConfig.properties file to true:
com.sun.identity.jss.donotInstallAtHighestPriority=true
Restart the Access Manager web container.
For more information, refer to problem ID 5110285 (XML encryption requires Bouncy Castle JAR file).