For a list of Sun Java System 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 Sun Java System Access Manager 6.2. Sun Java System Access Manager 6.2 must be installed prior to patch installation. Please note that this document is applicable to all AM 6.2 supported platforms with following PatchIDs: Solaris Sparc - 115766, Solaris x86 - 120091, Linux - 119409.

It is important that this patch, as with any other, be tested thoroughly on a staging or pre-deployment system prior to being put in to 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 Solaris 8 and 9 releases, refer to the man pages for instructions on using 'patchadd' and 'patchrm' scripts provided with Solaris. 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-08

When postpatch script is executed, it will ask one to three questions about the server instance path. In case Identity Server is running on web server, you will be asked with this question:

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

For Identity Server 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 Identity Server is running on application server, if the Identity Server 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 Sun ONE Identity Server once the patch is installed successful.

The following example removes a patch from a standalone system:

# patchrm 120091-08

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 the Sun Java System Access Manager.

1. If any of the files are customized in the current installation, please take a back up of those customized files. Compare the contents of the backedup 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 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, patch installer might fail to preserve some of customized files replacing them with non-customized versions.
   
   
   1. Please read this quick guide that should help 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 JSPs associated with the IS 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.
      
      The WAR files that get modified are:
         $BASEDIR/$PRODUCT_DIR/console.war
         $BASEDIR/$PRODUCT_DIR/password.war
         $BASEDIR/$PRODUCT_DIR/services.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. JSPs (*.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 console.war <$path/$modified file>
         jar -uvf services.war <$path/$modified file>
         jar -uvf password.war <$path/$modified file>
         Here is an example:
            cd /opt/SUNWam
            jar -uvf console.war index.html
            rm index.html
      
      
   2. Please carefully read the instructions below to workaround an issue described in 6254355. These are the steps to follow in order to make sure all custom changes are properly preserved.
      Note: Steps below should be able to preserve custom changes in most cases. In a case where the changes are not preserved, please use technique explained in 1.
      
      1. Make sure all your customized jsps 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 jsps in $BASEDIR/$PRODUCT_DIR/web-src/... directories and add your original custom changes manually to the ones that got changed.
      4. Create 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 /SUNWam/bin directory on Solaris systems.
      5. Run the amconfig command 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 AM 6.2 Patch4, the 'goto' functionality for suborganizations could be broken:
   Bugs# 6237056/6294941: Applying patch 115766-04 breaks 'goto' functionality in AM 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 'goto' functionality would not be broken in those files, hidden 'goto' parameter:
   <input type="hidden" name="goto" value="<%= request.getParameter("goto") %>">
   should be added to all jsp files that use <auth:form> tags, here is an 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 of useing it:

   # 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 IS/PS separated configuration.
   To set propertiesViewBeanURL in a service configuration. You can 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 amadmin command line tool:

      # $IS_INSTALL_DIR/SUNWam/bin/amadmin -u amadmin -w $PASSWORD --data $XML_FILE

      where $IS_INSTALL_DIR is the directory where Identity Service is installed. $PASSWORD is the password of amadmin user $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 restart 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" eg., ROOT_SUFFIX=dc=red,dc=iplanet,dc=com

Back to top