Access Manager 7.1 patch 3 fixes a number of problems, as listed in the README file included with the patch. Patch 3 also includes changes and known issues:
Check the Sun Java System LDAP JDK Patches section to determine if you need to apply these patches.
Beginning with patch 3 (and any subsequent patches unless specifically noted), you must run the updateschema.sh script on Solaris and Linux systems or the updateschema.pl script on Windows. The updateschema script updates the Sun Java System Directory Server schema with any new attributes required by the patch.
Requirements for the updateschema.sh or updateschema.pl script include:
The updateschema.sh or updateschema.pl script requires JDK 1.5 or later. Therefore, set your JAVA_HOME environment variable to a JDK installation of 1.5 or later.
On Windows systems, the updateschema.pl script requires AcivePerl 5.8 or later.
Access Manager 7.1 WAR File Deployment
To locate the updateschema script:
After you unzip the 140504-05.zip file, unzip the AccessManager7_1Patch4.zip file.
In the 140504-05/patch directory, unzip the AM7_1Patch4.zip file.
The updateschema.sh and updateschema.bat scripts are in the 140504-05/patch/bin directory.
For an Access Manager 7.1 WAR file deployment, run the updateschema script after you add the patch. The script prompts you for paths to the following items:
Access Manager 7.1 WAR file deployment directories (which must already exist):
Sun Java System Directory Server information:
Fully-qualified hostname. For example: ds.example.com
Port number, Default is 389.
Directory Manager DN and password. Default is cn=Directory Manager.
Top-level administrator and password. For example: uid=amadmin,ou=People,dc=example,dc=com
Access Manager 7.1 Installer (Package-Based) Deployment
After you unzip the patchID.zip file, the updateschema.sh or updateschema.bat script is in the patchID directory, where patchID is 126356-05, 126357-05, 126358-05, or 126359-05, depending on your platform.
For an Access Manager 7.1 installer (package-based) deployment, run the updateschema script after you add the patch. The script prompts you for the same Directory Server information as requested for a WAR file deployment.
Patch 3 removes the limitation for Creation of Data Store authentication module instance fails in Legacy mode (6764919).
In patch 2, the amadmin user was prevented from logging in to any authentication module other than the Data Store and Application authentication modules. CR 6811036 in patch 3 removes this restriction, but at the same time re-implements the original security fix to protect the authentication for the amadmin user, which is considered as a special or “internal” user.
An internal user such as amadmin must first authenticate internally to the OpenSSO configuration data store before it can authenticate to any authentication module. Hence you can login as amadmin to any authentication module only if you can first successfully authenticate to the configuration data store.
Note. Due to CR 6811036, if you log in as amadmin to the Access Manager Admin Console and provide an incorrect password, the “Your authentication module is denied' message will be displayed instead of “Authentication Failed” (which was displayed prior to patch 2).
Patch 3 fixes the Backward compatibility issue between Access Manager 7.1 and amclientsdk.jar File (6754863). If you apply patch 3, the workaround documented for patch 2 is not needed.
The fix for CR 6804294 requires that the following Java Web Console 3.1 patches be applied:
Solaris SPARC systems: 125950-18
Solaris x86 systems: 125951-18
Windows: 125955-18 and 127534-18
These patches are available on SunSolve (http://sunsolve.sun.com/).
For a Distributed Authentication UI server deployment, Access Manager 7.1 patch 3 (CR 6700722) includes the new com.sun.identity.authentication.destroySessionAfterUpgrade property to prevent old sessions from being destroyed after a session upgrade. Values for this property can be:
true (default): Old sessions are destroyed immediately after a session upgrade.
false: Old sessions are not destroyed after a session upgrade.
Note. This new property applies only to a Distributed Authentication UI server and not to Access Manager 7.1 server.
To prevent sessions from being destroyed after a session upgrade:
Add this new property with a value of false in the AMConfig.properties file. For example:
Restart the Distributed Authentication UI server.
Access Manager 7.1 patch 3 (CR 6496155) includes the new com.iplanet.dpro.session.dnRestrictionOnly property to enforce the DN as the SSO token restriction rather then the IP address in cross-domain single sign-on (CDSSO) deployments and cookie-hijacking prevention mode. Values for this property can be:
true: Access Manager 7.1 server enforces that an agent send the DN as the SSO token restriction.
false (default): Access Manager 7.1 server uses whatever SSO token restriction is sent by the agent. The token restriction can be the IP address (for older agents that have amclientsdk.jar from Access Manager 7 2005Q4 patch 5 and earlier) or the DN (for newer agents that have amclientsdk.jar from Access Manager 7 2005Q4 patch 6 and later).
Note: Older agents that use amclientsdk.jar from Access Manager 7 2005Q4 patch 5 and earlier should not set this property to true.
To require Access Manager 7.1 server to enforce that an agent send the DN as the SSO token restriction:
Add this new property with a value of true in the AMConfig.properties file. For example:
Restart Access Manager 7.1 server.
An Access Manager 7.1 patch 3 Distributed Authentication UI server now works with basic authentication (CR 6754852).
Access Manager 7.1 patch 3 includes support for the SecurID authentication module on Linux systems (CR 6767780).
SecurID authentication support is also available on Solaris SPARC systems and Solaris x86 systems (since patch 2). See SecurID authentication is supported on Solaris x86 systems (6621802).
If Access Manager 7.1 patch 3 is deployed from a single WAR file, the https protocol handler cannot be used.
If Access Manager 7.1 patch 3 is deployed from a single WAR file on Windows, running the updateschma.pl script fails if the path to the config directory contains a space.
For example: c:\Documents and Settings\Administrator\AMConfig
Workaround. In the updateschema.pl file, add a double quote (") around the filename path in the following lines and then rerun the script:
$XMLFILE="$AM_ETCDIR/add_cert_org_serverconfig.xml"; $XMLFILE="$AM_ETCDIR/add_cert_org.xml"; $XMLFILE="$AM_ETCDIR/add_choice_none_org.xml"; $XMLFILE="$AM_ETCDIR/add_choice_none_org_serverconfig.xml"; $XMLFILE="$AM_ETCDIR/add_delegation_default_SubjectIdType.xml"; $XMLFILE="$AM_ETCDIR/add_auth_attr.xml";
$XMLFILE="\"$AM_ETCDIR/add_cert_org_serverconfig.xml\""; $XMLFILE="\"$AM_ETCDIR/add_cert_org.xml\""; $XMLFILE="\"$AM_ETCDIR/add_choice_none_org.xml\""; $XMLFILE="\"$AM_ETCDIR/add_choice_none_org_serverconfig.xml\""; $XMLFILE="\"$AM_ETCDIR/add_delegation_default_SubjectIdType.xml\""; $XMLFILE="\"$AM_ETCDIR/add_auth_attr.xml\""; Entry 1
If Access Manager 7.1 patch 3 is deployed from a single WAR file on Windows, running the updateschma.pl script fails because the path to the tools directory is hard-coded.
Workaround. Remove /amAdminTools from the following line of the updateschema.pl file and then rerun the script: