Sun Java™ System Access Manager 7 2005Q4 Patch 03 Release Notes

Last updated: Aug. 15, 2006


Contents


Access Manager 7 2005Q4 Patches

The latest revisions of the Access Manager 7 2005Q4 patches are available for download from SunSolve Online: http://sunsolve.sun.com. The most recent patch IDs are:

Important Access Manager 7 patches are cumulative. You can install patch 3 without first installing patch 1 or patch 2. However, if you did not install patch 1 or patch 2, review the new features and issues in the Access Manager 7 2005Q4 Patch 1 and Access Manager 7 2005Q4 Patch 2 sections to determine if any of the features and issues apply to your deployment. For example, if you didn't install patch 2, you might need to run the amadmin command to load specific XML files.


What's New in Access Manager 7 2005Q4 Patch 3

Access Manager 7 patch 3 (revision 03) fixes a number of problems, as listed in the README file included with the patch. Patch 3 also includes the following new features and known issues:

New Features

Known Issues

New Configuration Properties for Site Monitoring

The Access Manager site monitoring feature includes these new properties:

Property Description
com.sun.identity.sitemonitor.interval Interval time in microseconds for site monitoring. The site monitoring feature checks each siteÆs availability within the specified time interval. Default: 60000 microseconds (1 minute).
com.sun.identity.sitemonitor.timeout timeout in microseconds for site availability checking. The site monitoring feature waits for the specified timeout value for a response from the site. Default: 5000 microseconds (5 seconds).

The patch does not add these properties to the AMConfig.properties file. To use these new properties with values other than the default values:

1. With a text editor, add the properties and their values to the AMConfig.properties file in the following directory, depending on your platform:

2. Restart the Access Manager Web container for the values to take effect.

For Policy Agents, add these properties to the AMAgents.properties file.

Custom implementation. In addition, the com.sun.identity.sitemonitor.SiteStatusCheck class allows you to customize your own implementation for checking site availability using the following interface:

package com.iplanet.services.naming.WebtopNaming$SiteStatusCheck

Each implementation class must use the doCheckSiteStatus method.

public interface SiteStatusCheck {
public boolean doCheckSiteStatus(URL siteurl);

Liberty Identity Web Services Framework (ID-WSF) 1.1 Support

The default version of ID-WSF in Access Manager 7 patch 3 is WSF1.1. There is no separate configuration needed to trigger the ID-WSF, except that the samples need to use the new security mechanisms. The new security mechanisms for the ID-WSF1.1 are:

urn:liberty:security:2005-02:null:X509
urn:liberty:security:2005-02:TLS:X509
urn:liberty:security:2005-02:ClientTLS:X509
urn:liberty:security:2005-02:null:SAML
urn:liberty:security:2005-02:TLS:SAML
urn:liberty:security:2005-02:ClientTLS:SAML
urn:liberty:security:2005-02:null:Bearer
urn:liberty:security:2005-02:TLS:Bearer
urn:liberty:security:2005-02:ClientTLS:Bearer

New Property for Liberty ID-WSF Support

The com.sun.identity.liberty.wsf.version property determines the Liberty ID-WSF framework when the framework cannot determine from the in-bound message or from the resource offering when Access Manager is acting as the WSC. Values can be 1.0 or 1.1. The default is 1.1.

Note The patch installation does not add the com.sun.identity.liberty.wsf.version property to the AMConfig.properties file (CR# 6458184). To use this new property, add it to the AMConfig.properties file with the appropriate value after you install the patch and then restart the Access Manager Web container.

After Access Manager 7 patch 3 is installed, run the following command to load the schema changes:

# AccessManager-base/bin/amadmin -u amadmin -w amadmin_password -t /etc/opt/SUNWam/wsf1.1_upgrade.xml

The default value of AccessManager-base is /opt/SUNWam on Solaris systems and /opt/sun/identity on Linux systems.

The ID-WSF discovery registration can use these new security mechanisms when registering. Also, WSCs will automatically detect which version to use while communicating to WSPs. To configure for ID-WSF1.1, follow the Readme files for the Liberty ID-FF sample1 and the ID-WSF samples that are included with the product.

CR# 6455757: sunISManagerOrganization marker class must be added to an organization before an upgrade

An organization in an Access Manager DIT that was created before the Access Manager 7 release might not have the sunISManagedOrganization object class. Also, an organization created by a product other than Access Manager will not have the sunISManagedOrganization object class in its definition.

Workaround. Before you upgrade to Access Manager 7 2005Q4, make sure that all organizations in the DIT have the sunISManagedOrganization object class in their definition. If necessary, manually add this object class before you upgrade.

CR# 6454489: Access Manager 7 2005Q4 Patch 2 upgrade causes an error in the amconsole Current Sessions tab

An upgrade caused the following error on the Current Sessions tab in the Access Manager Console:

Failed to get valid Sessions from the Specified server

This problem applies to deployments that are upgrading from Access Manager 6.x versions that have a root suffix of the form o=orgname.

Workaround. After installing Manager 7 2005Q4, apply Manager 7 Patch 3 and then run the amupgrade script to migrate the data, as follows:

  1. Backup your Access Manager 6.x DIT.
  2. Run the ampre70upgrade script.
  3. Install Access Manager 7 2005Q4 with the Configure Later option.
  4. Undeploy the Access Manager Web applications.
  5. Deploy the Access Manager Web applications.
  6. Apply Access Manager 7 patch 3, but don't apply the XML/LDIF changes. The XML/LDIF changes must be applied after running the amupgrade script in the next step.
  7. Run the amupgrade script.
  8. Redeploy the Access Manager Web applications, because of the Access Manager 7 patch 3 changes.
  9. Access the Access Manager Console.

CR# 6452320: Exceptions are thrown when using polling with client SDK

When you deploy the Access Manager client SDK (amclientsdk.jar) and enable polling, errors such as the following can occur:

ERROR: Send Polling Error:
com.iplanet.am.util.ThreadPoolException: amSessionPoller thread pool's task queue is full.

Such errors can occur after you deploy the Distributed Authentication UI, J2EE agents, or in any situation where you deploy the Access Manager client SDK on a client machine.

Workaround: If you have only a few hundred concurrent sessions, add following properties and values in either the AMConfig.properties file or the AMAgents.properties file:

com.sun.identity.session.polling.threadpool.size=10
com.sun.identity.session.polling.threadpool.threshold=10000

For thousands or tens of thousands of sessions, the values should be set the same as those for notification in the Access Manager AMConfig.properties file after running the amtune-identity script. For example, for a machine with 4GB of RAM, the Access Manager amtune-identity script sets the following values:

com.sun.identity.session.notification.threadpool.size=28
com.sun.identity.session.notification.threadpool.threshold=76288

Set similar values on the client side in the AMAgent.properties or AMConfig.properties file when the Distributed Authentication UI server or the Access Manager client SDK is deployed on a client machine with 4GB of RAM.

CR# 6441918: Site monitor interval and timeout properties

Access Manager site failover includes the following new properties:

com.sun.identity.sitemonitor.interval
com.sun.identity.sitemonitor.timeout

For more information, see New Configuration Properties for Site Monitoring.

CR# 6440697: Distributed Authentication should run as non-amadmin user

If you do not want to use the default administrative user (amadmin) for Distributed Authentication application authentication, follow this procedure to create a Distributed Authentication administrator:

  1. Create an LDAP user for the Distributed Authentication administrator. For example:
    uid=distauthadmin,ou=people,o=am
  2. Add the Distributed Authentication admin user to the list of special users. For example:

com.sun.identity.authentication.special.users=cn=dsameuser,ou=DSAME Users,o=am|cn=amService-UrlAccessAgent,ou=DSAME Users,o=am|uid=distauthadmin,ou=People,o=am

Add this property to the AMConfig.properties file of all Access Manager servers, so that the Distributed Authentication admin user is not subject to session limits and session quotas.

CR# 6440695: Distributed Authentication UI servers with a load balancer

If your deployment includes a load balancer in front of multiple Distributed Authentication UI servers, set the following properties in the AMConfig.properties file after you deploy the WAR file.

com.iplanet.am.lbcookie.name=DistAuthLBCookieName
com.iplanet.am.lbcookie.value=DistAuthLBCookieValue

CR# 6440651: Cookie reply requires com.sun.identity.session.resetLBCookie property

For cookie replaying to work properly for Access Manager session failover, add the following property to the AMAgent.properties file for the Policy Agent and set it to true. For example:

com.sun.identity.session.resetLBCookie='true'

CR# 6440648: com.iplanet.am.lbcookie.name property assumes default value of amlbcookie

By default, a Policy Agent and Access Manager servers assume a load balancer cookie name of "amlbcookie". If you change the name of the cookie on the back-end server, you must use the same name in the the AMAgent.properties file for the Policy Agent. Also, if you are using the Access Manager client SDK, you must also use the same cookie name used by the back-end server.

CR# 6440641: com.iplanet.am.lbcookie.value property is deprecated

Access Manager no longer supports the the com.iplanet.am.lbcookie.value property on servers to customize the load balancer cookie. Instead, Access Manager now uses the server ID, which is configured as part of session configuration, for the cookie value and for the name to be replayed by the agent.

CR# 6429610: Unable to create SSO token in ID-FF SSO use case

After setting up the Liberty Identity Federation Framework (ID-FF) sample 1, Federation succeeded, but SSO failed.

Workaround. Add the uuid of dsameuser to the com.sun.identity.authentication.special.users property in the AMConfig.properties file. For application authentication, dsameuser needs a non-expiring SSO token for the Access Manager server.

CR# 6389564: Repetitious successive queries on role memberships of user in an LDAP v3 data store during Access Manager login

When a user logs into Access Manager, repetitive LDAP searches on the user's nsRoleDN attribute occur.

Workaround: After the Access Manager 7 patch 3 is installed, run the following command (shown for Solaris systems):

# /etc/SUNWam/bin/amadmin -u amadmin -w amadmin_password -t /etc/opt/SUNWam/idRepoServiceAddAttrSchemaRequest_Cache.xml

CR# 6385185: Authentication module must be able to override the "goto" URL and specify a different URL

An authentication module can override the "goto" URL and request re-direction to a different URL of an external Web site to get the user status validated.

See also the following CR 6385184 for additional information.

CR# 6385184: Re-direct from within a custom authentication module when SSOToken is still in invalid state

In this scenario, the deployment is using a custom authentication module to access a provisioning/credit card site:

  1. A user invokes the authentication process/login page for the custom authentication module.
  2. The user enters the credentials (user name and password) and submits a request to the custom authentication module.
  3. The custom authentication module redirects the user to a provisioning/credit card site with the required user information along with the request.
  4. The provisioning/credit card site checks the userÆs status and returns the request with either success or failure, which is set as part of the returned request.
  5. The custom authentication module validates the user based on the status returned in Step 4 and returns the corresponding status to the authentication service.
  6. The user authentication completes with either success or failure.

CR# 6324056: Federation fails when using artifact profile

Workaround: To fix this problem, apply latest version of the "Core Mobile Access" patch, depending on your platform:

After applying the patch, restart the Web container.


Access Manager 7 2005Q4 Patch 2

Access Manager 7 patch 2 (revision 02) fixed a number of problems, as listed in the README file included with the patch. Patch 2 also includes the following new features and known issues:

New Features

Known Issues

New Properties for the User Management, Identity Repository, and Service Management Caches

Patch 2 includes the following new properties for the User Management (Access Manager SDK), Identity Repository (IdRepo), and Service Management caches. These properties allow you to enable and disable the different caches independently, based on your deployment requirements, and to set the time to live (TTL) for the cache entries.

Property Description
New Properties to Enable and Disable Caches
com.iplanet.am.sdk.caching.enabled

Global property that enables (true) or disables (false) the Identity Repository (IdRepo), User Management, and Service Management caches. If true, or if the property is not present in the AMConfig.properties file, all three caches are enabled.

Note The following three properties to enable or disable the specific caches apply only if the previous property is set to false.
com.sun.identity.amsdk.cache.enabled

Enables (true) or disables (false) only the User Management (Access Manager SDK) cache.

com.sun.identity.idm.cache.enabled

Enables (true) or disables (false) only the Identity Repository (IdRepo) cache.

com.sun.identity.sm.cache.enabled

Enables (true) or disables (false) only the Service Management cache.

New User Management Cache Properties for TTL
com.iplanet.am.sdk.cache.entry.expire.enabled

Enables (true) or disables (false) the expiration time (as defined by the following two properties) for the User Management cache.

com.iplanet.am.sdk.cache.entry.user.expire.time

Specifies the time in minutes that user entries for the User Management cache remain valid after their last modification.

That is, after this specified time elapses (after the last modification or read from the directory), the data for the entry that is cached will expire. Then, new requests for data for these entries must be read from the directory.

com.iplanet.am.sdk.cache.entry.default.expire.time

Specifies the time in minutes that non-user entries for the User Management cache remain valid after their last modification.

That is, after this specified time elapses (after the last modification or read from the directory), the data for the entry that is cached will expire. Then, new requests for data for these entries must be read from the directory.

New Identity Repository Cache Properties for TTL
com.sun.identity.idm.cache.entry.expire.enabled

Enables (true) or disables (false) the expiration time (as defined by the following property) for the IdRepo cache.

com.sun.identity.idm.cache.entry.default.expire.time

Specifies the time in minutes that non-user entries for the IdRepo cache remain valid after their last modification.

That is, after this specified time elapses (after the last modification or read from the repository), the data for the entry that is cached will expire. Then, new requests for data for these entries must be read from the repository.

Using the New Caching Properties

The Access Manager 7 2005Q4 patches do not automatically add the caching properties to the AMConfig.properties file.

To use these new properties:

1. With a text editor, add the properties and their values to the AMConfig.properties file in the following directory, depending on your platform:

2. Restart the Access Manager web container for the values to take effect.

New Property for Federation Service Provider

The new com.sun.identity.federation.spadapter property defines the implementation class for com.sun.identity.federation.plugins.FederationSPAdapter, which is used to add application specific processing during Federation processing on the Service Provider side.

See also CR# 6385696: Existing and new IDPs and SPs are not visible.

LDAPFilterCondition Support

LDAPFilterCondition support is added in patch 2. Policy administrator can now specify an LDAP filter in the Condition while defining a policy. Policy would be applied to the user only if the LDAP entry of the user satisfies the LDAP filter specified in the Condition. The LDAP entry of the user is looked up from the directory specified in the Policy Config service.

To register and use the LDAPFilterCondition, run following commands after the Access Manager 7 patch 2 is installed.

# AccessManager-base/bin/amadmin -u amadmin -w amadmin_password -s /etc/opt/SUNWam/AddLDAPFilterCondition.xml
# AccessManager-base/bin/amadmin -u amadmin -w amadmin_password -t /etc/opt/SUNWam/amPolicyConfig_mod_ldfc.xml

The default value of AccessManager-base is /opt/SUNWam on Solaris systems and /opt/sun/identity on Linux systems.

Patch 3 Note If you have not installed Access Manager patch 2 (or did not run these commands after installing patch 2), run the above commands after installing patch 3 to import the XML files released with patch 2.

CR# 6283582: Num of login failures are not shared across Access Manager instances

After Access Manager 7 patch 2 is installed, run following commands:

# cd DirectoryServer-Base/shared/bin
# ./ldapmodify -h DirectoryServerHost -p DirectoryServerPort -D "cn=Directory Manager" -w DirectoryMangerPassword -a -f /etc/opt/SUNWam/accountLockout.ldif
# AccessManager-base/bin/amadmin -u amadmin -w amadmin_password -t /etc/opt/SUNWam/accountLockoutData.xml

The default value of AccessManager-base is /opt/SUNWam on Solaris systems and /opt/sun/identity on Linux systems.

The default value of DirectoryServer-base is /var/opt/mps/serverroot on Solaris systems and /var/opt/sun/directory-server on Linux systems.

Patch 3 Note If you have not installed Access Manager patch 2 (or did not run these commands after installing patch 2), run the above commands after installing patch 3 to import the XML files released with patch 2.

CR# 6293673: Need to retain the original session information when sending out session timeout notification

A new property com.sun.identity.session.property.doNotTrimList is added to AMConfig.properties, which can contain list of comma separated session property names. Once a session is timed out, those properties defined in this list will not be trimmed off, so that can be accessed before the session is purged. For example,

com.sun.identity.session.property.doNotTrimList=UserId, HostName

CR# 6244578: Access Manager should warn user that the browser cookie support is disabled/not available

A new property com.sun.identity.am.cookie.check is added to AMConfig.properties, which indicates whether server should check for the cookie support / cookie enabled in the browser. Value true will result in server checking for the cookie support / cookie enabled in the browser and throwing an error page if the browser does not support or has not enabled cookie. This value should be set to false (which is default) if the server is expected to support cookieless mode for authentication functionality. For example:

com.sun.identity.am.cookie.check=true

CR# 6236892: Image/Text place holder while CDCServlet is processing the AuthNResponse after login

A few new properties are added to AMConfig.properties. The property com.iplanet.services.cdc.WaitImage.display needs to be set to true to have an image displayed in the browser while waiting for the protected page in a CDSSO scenario (default is false). The other three following properties allow to choose the name, the width and and the height of the image. The default name for the image is waitImage.gif. This image be copied in the login_images directory. The default size is 420 x 120. These properties will be read by CDCServlet. For example,

com.iplanet.services.cdc.WaitImage.display=false
com.iplanet.services.cdc.WaitImage.name=waitImage.gif
com.iplanet.services.cdc.WaitImage.width=420
com.iplanet.services.cdc.WaitImage.height=120

CR# 6363157: Need to disable unnecessary persistent searches which affect performance

A new property com.sun.am.event.connection.disable.list is added to AMConfig.properties, which specifies which event connection can be disabled. There are three valid values - aci, sm and um (case insensitive). Multiple values should be separated with comma. For example,

com.sun.am.event.connection.disable.list=aci, um

CR# 6385696: Existing and new IDPs and SPs are not visible

A new property com.sun.identity.federation.spadapter is added to AMConfig.properties, which specifies the default implementation of federation service provider adapter where the application can get hold of assertion, response information. For example,

com.sun.identity.federation.spadapter=com.sun.identity.federation.plugins.FSDefaultSPAdapter

Top of Page


Access Manager 7 2005Q4 Patch 1

Access Manager 7 patch 1 (revision 01) fixed a number of problems, as listed in the README file included with the patch. Patch 2 also includes the following new features and known issues:

Creation of Debug Files

Access Manager debug files are created by default in the debug directory, even when com.iplanet.services.debug.level property in the AMConfig.properties file is set to error. Before Access Manager 7 patch 1 was released, a debug file was created only when the first debug message was logged to the file.

CR# 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.

CR# 6358751: Access Manager 7 patch 1 apply fails if the there are embedded spaces in the encryption key

If the password encryption key contains spaces, applying the patch fails.

Workaround Use a new encryption key that includes no spaces. For detailed steps of changing the encryption key, see Appendix B, "Changing the Password Encryption Key" in the Access Manager 7 2005Q4 Deployment Planning Guide: http://docs.sun.com/doc/819-2136.


Pre-Installation Considerations

Important If any of the files in your current installation are customized, back up those files before you install the patch. After you install the patch, compare the backed up files with the new files installed by this patch to identify the customizations. Merge the customizations with the new files and save them. For more information about how to handle customized files, read the following information.

Before you install a patch, back up the following files:

The default value of AccessManager-base is /opt/SUNWam on Solaris systems and /opt/sun/identity on Linux systems.

The Access Manager patches described in this document do not install Access Manager. Before you install the patch, Access Manager 7 2005Q4 must be installed on the server. For information about installation, see the Sun Java Enterprise System 2005Q4 Installation Guide for UNIX: http://docs.sun.com/doc/819-2328.

You should also be familiar with running the amconfig script to deploy, re-deploy, and configure Access Manager, as described in the the Access Manager 7 2005Q4 Administration Guide: http://docs.sun.com/doc/819-2137.

For a list of the Access Manager patches that are made obsolete by this patch and any patches that you must install before you install this patch, refer to the README file included with this patch.

Caution Access Manager patches (as with any other patches) should be tested on a staging or pre-deployment system before you put them into a production environment. Also, the patch installer might not update your customized JSP files properly, so you might need to make manual changes in these files in order for Access Manager to function properly.

Top of Page


Patch Installation Instructions

Solaris Systems

To add or remove a patch on Solaris systems, use the patchadd and patchrm commands, which are provided with the OS.

Solaris 10 Zones

The Solaris 10 operating system introduced the new concept of "zones." Consequently, the patchadd command includes the new -G option, which adds a patch only to the global zone. By default, the patchadd command looks for the SUNW_PKG_ALLZONES variable in the pkginfo of packages to be patched. However, for all Access Manager packages, the SUNW_PKG_ALLZONES variable is not set, and the -G option is required if Access Manager 7 2005Q4 is installed in the global zone. If Access Manager is installed in a local zone, the patchadd -G option has no effect.

If you are installing Access Manager 7 2005Q4 patches on a Solaris machine, it is recommended that you use the -G option. For example:

# patchadd -G AM7.0_patch_dir

Similarly, if Access Manager is installed in the global zone, the -G option is required to run the patchrm command. For example:

# patchrm -G 120954-03

patchadd Command

The following example installs a patch on a standalone machine:

# patchadd /var/spool/patch/120954-03

When the postpatch script is executed, the following message will be printed, except on a system that has only the Access Manager SDK component installed:

After the patch installation, redeploy the Access Manager applications by following the steps in the Patch Installation Instructions section. A draft amsilent file is created in $BASEDIR/SUNWam directory.

This amsilent is based on $INSTALL_DIR/bin/amsamplesilent, but with some required parameters set according to the Access Manager config files on this system.

The password parameter checks the accuracy of the other parameters values in $BASEDIR/SUNWam/amsilent contain default values. Uncomment and modify the value of each password parameter. Then, run the following command:

# cd $INSTALL_DIR/bin
# ./amconfig -s AccessManager-base/amsilent

The default value of AccessManager-base is /opt/SUNWam on Solaris systems and /opt/sun/identity on Linux systems.

Caution The amsilent file contains plain text passwords. After you have run the amconfig script to deploy Access Manager, delete (or move and secure) the amsilent file to prevent any potential security problems.

After you run the amconfig script, restart the Access Manager processes. For example, on a Solaris system:

# cd /opt/SUNWam/bin
# ./amserver stop
# ./amserver start

Then restart the Access Manager web container.

patchrm Command

The following example removes a patch from a standalone system:

# patchrm 120954-03

When the backout script is executed, a similar message will be printed, except on a system that has only the Access Manager SDK component installed.

After the patch is removed, redeploy the Access Manager applications by following the Patch Installation Instructions. A draft amsilent file is created in the AccessManager-base directory.

This amsilent file is based on $INSTALL_DIR/bin/amsamplesilent, but with some required parameters set according to the Access Manager config files on this system.

The password parameter values in AccessManager-base/amsilent contain default values. Uncomment and modify the value of each password parameter and carefully check and make sure the accuracy of other parameters in this file. Then run the command as follows:

# cd AccessManager-base/bin
# ./amconfig -s AccessManager-base/amsilent

The default value of AccessManager-base is /opt/SUNWam on Solaris systems and /opt/sun/identity on Linux systems.

For additional information and examples about the patchadd and patchrm commands, see the appropriate man pages.

Linux Systems

The following example installs a patch on a standalone Linux machine:

# ./installpatch

When the postpatch script is executed, messages that will be printed are similar to the messages on a Solaris system.

However, the procedure to back out a patch on a Linux system is different than on a Solaris system. There is no generic script to back out a Linux patch. If a lower version of the patch was previously installed, you can re-install that version and then follow the postpatch instructions to redeploy the Access Manager applications by running the amconfig script.

If the patch is installed on the Access Manager 7 2005Q4 RTM release and you want to remove the patch and restore the system to the RTM state, you must reinstall the Access Manager RTM bits using the reinstallRTM script. The reinstallRTM script takes the path where the Access Manager RTM RPMs are stored and installs the RTM RPMs over the patched RPMs. For example:

# ./scripts/reinstallRTM path_of_AM7.0_RTM_RPM_directory

After you run the reinstallRTM script, redeploy the Access Manager applications by running the amconfig script.

See the next section for more information.


Post-Installation Considerations

Considerations after you install the patch include:

CR# 6254355: Access Manager patches do not deploy Access Manager applications in postpatch scripts

The patch installer might not preserve some of the customized WAR files, replacing them with non-customized versions. To help you identify and then manually update the customized contents of a WAR file, consider the following procedure.

In the following examples, AccessManager-base is /opt/SUNWam on Solaris systems and /opt/sun/identity on Linux systems.

The WAR files that get patched are:

The changeable content in a WAR file includes:

To make sure that all custom changes are preserved, follow these steps. Before you make changes to a file, always backup the file first.

  1. Install the patch.
  2. Expand the WAR files into a temporary directory:
    # cd temporary-directory
    # jar -xvf AccessManager-base/console.war
    # jar -xvf AccessManager-base/services.war
    # jar -xvf AccessManager-base/password.war
  3. Check the expanded files to see whether the patch installer made any changes to your customized files and manually add your original custom changes to the ones that got changed in the temporary directory. For your changes to the files under the AccessManager-base/web-src/ directory but not included in the patched WAR files, you do not need to redo your changes.
  4. Update the WAR files with the modified files:
    # cd temporary-directory
    # jar -uvf AccessManager-base/console.war $path/$modified file
    # jar -uvf AccessManager-base/services.war $path/$modified file
    # jar -uvf AccessManager-base/password.war $path/$modified file
    For example, for Steps 2-4:
    # mkdir /tmp/war.tmp
    # cd /tmp/war.tmp
    # jar -xvf /opt/SUNWam/services.war
    # vi index.html
    # jar -uvf /opt/SUNWam/services.war index.html
  5. Reuse the silent configuration file (AccessManager-base/amsilent) generated by the patch or create a new one based on the AccessManager-base/bin/amsamplesilent template file and then set the appropriate configuration variables in the file, including:
    • DEPLOY_LEVEL=21
    • DIRECTORY_MODE=5
    • Passwords for DS_DIRMGRPASSWD, ADMINPASSWD, and AMLDAPUSERPASSWD
    • Access Manager Web container variables

    For more information 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.
  6. 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 /opt/SUNWam/amsilent

  7. After you run the amconfig script, restart the Access Manager processes. For example:

    # cd /opt/SUNWam/bin
    # ./amserver stop
    # ./amserver start

  8. Make sure all your customized JSP files reside in the proper subdirectories under the AccessManager-base/web-src/ directory and that you have backed up all of your customized files.
  9. Restart the Access Manager Web container.

For more information about running the amconfig script, see the Access Manager 7 2005Q4 Administration Guide:
http://docs.sun.com/doc/819-2137.

CR# 6436409: Redeploying the Distributed Authentication and Client SDK WAR Files

If you are using Distributed Authentication or the Client SDK, recreate and redeploy the Distributed Authentication WAR file and/or the Client SDK WAR file after you install the patch. For information, see:

Top of Page