For a list of Access Manager patches that are obsoleted by this patch, and any patches you must install prior to installing this patch, refer to the included patch README. This patch is not a standalone installation and does not include Access Manager 6.2. Access Manager 6.2 must be installed prior to patch installation. Please note that this document is applicable to all Access Manager 6.2 supported platforms with following patch IDs:

• Solaris™ Operating System (Solaris OS) on SPARC® based system - 115766
• Solaris OS on x86 platforms - 120091
• Linux systems - 119409

It is important that this patch, as with any other patch, be tested thoroughly on a staging or pre-deployment system prior to being put into production. Additionally, special care should be taken in regards to some customized JSP files. Due to the nature and complexity of some modifications, the patch installer might fail to update some of those files properly, so manual changes might be required in order for the product to continue functioning normally.

Back to top

1. amamAdminConsole.xml
2. amAuth.xml
3. amAuthSafeWord.xml
4. amProviderConfig.xml
5. amAdminCLI.properties
6. amAdminModuleMsgs.properties
7. amAuth.properties
8. amAuthSafeWord.properties
9. amAuthUI.properties
10. amProviderConfig.properties
11. AMConfig.properties
12. Login.jsp
13. membership.jsp
14. new_org.jsp

For the Solaris 8 and 9 releases, refer to the man pages for instructions on using the patchadd and patchrm commands provided with the Solaris OS. Any other special or non-generic installation instructions should be described below as special instructions. The following example installs a patch to a standalone machine:

# patchadd /var/spool/patch/120091-11

When the post patch script is executed, it will ask one to three questions about the server instance path. If Access Manager is running on Web Server, you will be asked this question:

What is the path of the WS 6.1 instance [/opt/SUNWwbsvr/https-hostname.domainname] ?

If Access Manager is running on Application Server, the following question will be asked:

What is the path of Application Server instance [/var/opt/SUNWappserver7/domains/domain1/server1] ?

When Access Manager is running on Application Server, if the Access Manager applications are redeployed multiple times, the application root path can vary. In this case, you will be asked to input the correct path to the deployment directory of application /amserver and /amconsole:

What is the path of the deployment directory of /amserver [/var/opt/SUNWappserver7/domains/domain1/server1/applications/j2ee-modules/amserver_1] ?

What is the path of the deployment directory of /amconsole [/var/opt/SUNWappserver7/domains/domain1/server1/applications/j2ee-modules/amconsole_1] ?

Besides the above, there are two more questions to be asked:

What is the dn of the Directory Manager [cn=Directory Manager]
What is the password for the Directory Manager []

Restart Access Manager after the patch is installed successfully.

The following example removes a patch from a standalone system:

# patchrm 120091-11

For additional examples please see the appropriate man pages.

Back to top

This section describes known problems while applying the patch and associated workarounds for Access Manager.

1. If any of the files are customized in the current installation, back up those customized files. Compare the contents of the backed up files with the contents of the new files installed by this patch to identify the customizations done. Merge the customizations with the new files and save them. Please carefully read the following step 2 and 3 for more info on how to deal with customized files.


2. Bug# 6254355: 6.2 patches should redeploy AM applications in postpatch scripts
   Due to complexity of updating customized content of several WAR files deployed on a web container, the patch installer might fail to preserve some of customized files replacing them with non-customized versions.
   
   
   1. Please read this quick guide, which will help you identify and manually update customized content of a WAR file.
      
      There are multiple ways to modify WAR files:
         - Edit files under $BASEDIR/$PRODUCT_DIR/web-src/applications/.
         - Modify the JSPs associated with the Access Manager custom admin console,auth modules, services, etc.
         - Modify resource bundles/property files in the WAR file.
      Note: $BASEDIR generally applies to /opt and $PRODUCT_DIR applies to SUNWam on Solaris systems. On Linux systems, $BASEDIR applies to /opt and $PRODUCT_DIR applies to /sun/identity.
      
      The WAR files that get modified are:
         $BASEDIR/$PRODUCT_DIR/amconsole.war
         $BASEDIR/$PRODUCT_DIR/ampassword.war
         $BASEDIR/$PRODUCT_DIR/amservices.war
      
      Changeable content in a WAR file:
      1. Properties files ($BASEDIR/$PRODUCT_DIR/locale/*.properties)
      2. Tag library descriptors $BASEDIR/$PRODUCT_DIR/web-src/applications/WEB-INF/*.tld)
      3. The web.xml file and the files used to construct it (WEB-INF/web.xml and WEB-INF/*.xml)
      4. Application specific files :
         1. JSP files (*.jsp)
         2. images(*.gif)
         3. stylesheets - background colors,font size etc.,(*.css)
         from the following directories:
            $BASEDIR/$PRODUCT_DIR/web-src/applications/console/
            $BASEDIR/$PRODUCT_DIR/web-src/services/
            $BASEDIR/$PRODUCT_DIR/web-src/password/
      
      How to update the WAR files?
         #cd ${BASEDIR}/${PRODUCT_DIR}
         #jar -uvf amconsole.war <$path/$modified file>
         #jar -uvf amservices.war <$path/$modified file>
         #jar -uvf ampassword.war <$path/$modified file>
         Here is an example:
            #cd /opt/SUNWam
            #jar -uvf amconsole.war index.html
            #rm index.html
      
      
   2. The following workaround is for the issue described in 6254355. These are the steps to follow in order to make sure all custom changes are properly preserved.
      Note: The steps below should be able to preserve custom changes in most cases. In a case where the changes are not preserved, use the technique explained in step 1.
      
      1. Make sure all your customized JSP files reside in proper subdirectories under $BASEDIR/$PRODUCT_DIR/web-src/
      and you have made a backup of all your customized files.
      2. Install the patch.
      3. Check whether the patch installer made any changes to your customized JSP files in $BASEDIR/$PRODUCT_DIR/web-src/... directories and add your original custom changes manually to the ones that got changed.
      4. Create the amsilent file based on $BASEDIR/$PRODUCT_DIR/bin/amsamplesilent template file and also set the appropriate configuration variables, including:
         - DEPLOY_LEVEL=21
         - DIRECTORY_MODE=5
         - Passwords for DS_DIRMGRPASSWD, ADMINPASSWD, and AMLDAPUSERPASSWD
         - Access Manager Web container variables. For more details about the Web container variables, see the amsamplesilent file in the /opt/SUNWam/bin directory on Solaris systems or the /opt/sun/identity/bin directory on Linux systems.
      5. Run the amconfig script as shown below. Before you run amconfig, Directory Server and the Access Manager web container must be running. For example, to run amconfig on a Solaris system with Access Manager installed in the default base installation directory:
           #cd /opt/SUNWam/bin
           #./amconfig -s amsilent
      For more information about running the amconfig script, see the Access Manager Administration Guide: http://docs.sun.com/doc/817-7647
   
   
   
3. In a case where auth JSP files have been customized, special care should be taken. Starting with Access Manager 6.2 Patch4, the 'goto' functionality for suborganizations could be broken:
   Bugs# 6237056/6294941: Applying patch 04 breaks 'goto' functionality in Access Manager 6.2
   It is advisable to backup all customized JSP files in <install_dir>/SUNWam/web-src/services/config/auth/default/ directory before applying the patch. After patch installation complete, note the differences (diff utility can help you identify those) between backed up JSP files and the new ones installed/modified by the patch. When it comes to updating multiple JSP files in the above directory, the current patch installer might fail to properly identify and update several manually customized JSP files. In order to make sure the 'goto' functionality is not broken in those files, the hidden 'goto' parameter:
   <input type="hidden" name="goto" value="<%= request.getParameter("goto") %>">
   should be added to all JSP files that use <auth:form> tags. For example:
   
   <auth:form name="Login" method="post" defaultCommandChild="DefaultLoginURL" >
   <script language="javascript">
       if (elmCount != null) {
          for (var i = 0; i < elmCount; i++) {
              document.write("<input name=\"IDToken" + i + "\" type=\"hidden\">");
          }
       document.write("<input name=\"IDButton" + "\" type=\"hidden\">");
       }
   </script>
   <input type="hidden" name="goto" value="<%= request.getParameter("goto") %>">
   </auth:form>

4. Bug# 5013729: Policy state is made inconsistent after the Policy Service is deleted.
   

   A new option "--cleanpolicyrules" is supported while removing services using amadmin. Here is an example:

   # amadmin --runasdn "admindn" --password password -r ServiceName --cleanpolicyrules

   If the option "--cleanpolicyrules" is passed while removing the service, policy rules defined for the <ServiceName> are removed along with the service.
5. Bug# 5060050: Unable to upgrade Portal in Access Manager/Portal Server separated configuration.
   To set propertiesViewBeanURL in a service configuration, do the following:
   
   1. Create an XML file that contains:

            <!DOCTYPE Requests
               PUBLIC "-//iPlanet//Sun Java System Access Manager Admin CLI DTD//EN"
               "jar://com/iplanet/am/admin/cli/amAdmin.dtd"
            >
      
            <Requests>
               <SchemaRootNodeRequests serviceName="$SERVICE_NAME">
               <SetPropertiesViewBeanURL url="$NEW_URL" />
               </SchemaRootNodeRequests>
            </Requests>

      Please replace $SERVICE_NAME with the service name of the service configuration; and replace $NEW_URL with the URL for the propertiesViewBeanURL of this service.

   2. Execute the amadmin command line tool:

      #cd $BASEDIR/$PRODUCT_DIR/bin
      # ./amadmin -u amadmin -w password --data xml-file

      where $BASEDIR/$PRODUCT_DIR is the directory where Access Manager is installed, password is the password of the amadmin user, and xml-file is the XML file that you have created in step 1.
      
      

6. Bug# 6175850: 6.2 Patch: Server Error on federating again after terminate federation
   The workaround is that the user either logs out or restarts the browser.

7. Bug# 5107381: Cert auth no longer searches recursively to locate users
   Change the 'People Container for All Users:' attribute value in the 'Core' auth service configuration, under default org from "ou=People,ROOT_SUFFIX" to "ROOT_SUFFIX" For example: ROOT_SUFFIX=dc=red,dc=iplanet,dc=com

8. Bug# 6276972: Delay in Access Manager 6.3 failover to secondary LDAP directory
   Add the following VM option to the server.xml file for the specific web container and restart the web container:
   <JVMOPTIONS>-Dnetworkaddress.cache.ttl=0</JVMOPTIONS>
   <JVMOPTIONS>-Dsun.net.inetaddr.ttl=0</JVMOPTIONS>
   
   

9. Bug# 6320475: com.iplanet.am.session.client.polling.enable on server side must not be true
   The com.iplanet.am.session.client.polling.enable property in the AMConfig.properties file on the server side is set to false by default and should never be reset to true.

Back to top