 PDF 文書ファイルをダウンロードする (1040 KB)
Sun Java System Access Manager 7 2005Q4 Release NotesAugust 7, 2009 Part Number 819-2134-25 The Sun JavaTM System Access Manager (Access Manager) 7 2005Q4 Release Notes contain important information available for the Sun Java Enterprise System (Java ES) release, including new Access Manager features and known issues with workarounds, if available. Read this document before you install and use this release. For information in this edition of the Release Notes, see the Revision History. To view the Java ES product documentation, including the Access Manager collection, see http://docs.sun.com/prod/entsys.05q4. Check this site prior to installing and setting up your software and then periodically thereafter to view the most up-to-date documentation. ContentsThe Access Manager 7 2005Q4 Release Notes contain the following sections: Revision HistoryThe following table shows the Access Manager 7 2005Q4 Release Notes revision history. Table 1 Revision History
About Sun Java System Access Manager 7 2005Q4Sun Java System Access Manager is part of the Sun Identity Management infrastructure that allows an organization to manage secure access to Web applications and other resources both within an enterprise and across business-to-business (B2B) value chains. Access Manager provides these main functions:
Access Manager 7 2005Q4 Patch ReleasesThe 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:
Note – Access Manager 7 2005Q4 patches are cumulative. You can install patch 10 without first installing an earlier patch. However, if you did not install an earlier patch, review the new features and issues in the earlier patch sections to determine if any of the features and issues apply to your deployment. Information about Access Manager 7 2005Q4 patches includes: Access Manager 7 2005Q4 Patch 10Access Manager 7 patch 10 (revision 10) fixes a number of problems, as listed in the README file included with the patch. Security Fixes. Patch 10 includes several important security fixes. Sun recommends that you install patch 10 to prevent from being exposed to these security risks. Refer to the patch README file for a list of these fixes. Patch 10 also includes these changes:
CR# 6813339: Access Manager reregisters Notification URL after a restartAccess Manager now reregisters the notification URL after a server restart if the following property is set in the server's AMConfig.properties file: com.sun.identity.agents.reregisterNotificationUrls=true The default value for this property is false. In a multi-server deployment, set this property for each Access Manager server. CR#6804391 and CR#6777889 Access Manager SecurID authentication process no longer crashesOn Solaris SPARC systems, the SecurID authentication process (amsecuridd) now avoids crashing because the process no longer writes to a closed connection. These CRs also fix a problem that caused users to be denied access even when authentication was successful. Also, more debug messages are added for better analysis in case other amsecuridd process problems occur. Pre-Installation ConsiderationsBacking Up FilesImportant 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, also back up the following files.
Installing and Configuring Access ManagerThe 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. If you are installing the patch on a Windows system, see the Sun Java Enterprise System 2005Q4 Installation Guide for Microsoft Windows. You should also be familiar with running the amconfig script to deploy, re-deploy, and configure Access Manager, as described in the Chapter 1, Access Manager 7 2005Q4 Configuration Scripts, in Sun Java System Access Manager 7 2005Q4 Administration Guide. 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. Patch Installation InstructionsPatch Installation Instructions For Solaris SystemsBefore you install the Solaris patch, make sure that you have backed up the files listed in Pre-Installation Considerations. To add and remove patches on Solaris systems, use the patchadd and patchrm commands, which are provided with the OS. patchadd Command Use the patchadd command to install a patch on a standalone system. For example: # patchadd /var/spool/patch/120954-10 Note – If you are installing the Solaris patch on a Solaris 10 global zone, invoke the patchadd command with the -G argument. For example: patchadd -G /var/spool/patch/120954-10 The postpatch script displays a message about redeploying the Access Manager applications, except on a system that has only the Access Manager SDK component installed. The postpatch script creates the amsilent file in the following directory:
AccessManager-base is the base installation directory. The default base installation directory is /opt on Solaris systems and /opt/sun on Linux systems. The amsilent is based on the amsamplesilent file, but with some required parameters set according to the Access Manager configuration files on the system. The password parameters, however, contain default values. Uncomment and modify the value of each password parameter and carefully check values of other parameters in this file, as needed for your deployment. The COMMON_DEPLOY_URI parameter, the URI prefix for the common domain web application, also contains a default value. If you have chosen a non-default value for this URI, make sure to update this value. Otherwise, the redeployment of the web applications with amconfig and the patch generated amsilent file will fail. Then, run the following command (shown with Access Manager installed in the default directory): # cd /opt/SUNWam/bin # ./amconfig -s /opt/SUNWam/amsilent Caution – The amsilent file contains sensitive data such as administrator passwords in plain text, so make sure you secure the file as appropriate for your deployment. After you run the amconfig script, execute the updateschema.sh script to load the XML and LDIF files. The updateschema.sh script is available after you install patch 10 in the following directory:
After you run the updateschema script, restart the Access Manager processes. For example: # cd /opt/SUNWam/bin # ./amserver stop # ./amserver start Then, restart the Access Manager web container. patchrm Command Use the patchrm command to remove a patch from a standalone system. For example: # patchrm 120954-03 The backout script displays a message similar to the patchadd command, except on a system that has only the Access Manager SDK component installed. After the patch is removed, redeploy the Access Manager applications using the amsilent file in the AccessManager-base/SUNWam directory, where AccessManager-base is the base installation directory. The default base installation directory is /opt on Solaris systems. Set the parameters in the amsilent file, as needed for your deployment. Then, run the following command, which is shown with Access Manager installed in the default directory on Solaris systems: # cd /opt/SUNWam/bin # ./amconfig -s /opt/SUNWam/amsilent For additional information and examples about the patchadd and patchrm commands, see the appropriate Solaris man pages. See also Post-Installation Considerations for more information. Solaris 10 ZonesThe 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 system, it is recommended that you use the -G option. For example: # patchadd -G AM7_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-09 Patch Installation Instructions For Linux SystemsBefore you install the Linux patch, make sure that you have backed up the files listed in Pre-Installation Considerations. The installpatch installs a patch on a standalone Linux system. For example: # ./installpatch The postpatch script prints messages 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. After you run the amconfig script, execute the updateschema.sh script (patch 5 and later patches) to load the XML and LDIF files. The updateschema.sh script is available after you install patch 10 in the patch-home-directory/120956-09/scripts directory. After you run the amconfig and updateschema.sh scripts, restart the Access Manager web container. 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. This 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_RTM_RPM_directory After you run the reinstallRTM script, redeploy the Access Manager applications by running the amconfig script and the restart the web container. See also Post-Installation Considerations for more information. Patch Installation Instructions For Windows SystemsThe requirements to install the Windows patch include:
Installing the Windows PatchBefore you install the Windows patch, make sure that you have backed up the files listed in Pre-Installation Considerations. In the base directory path for input to the patch scripts, use a forward slash (/). For example: c:/sun To install the Windows patch:
Backing Out the Windows PatchTo back out the Windows patch:
Note: If you back out the patch, the schema changes added by the AM7p8\scripts\updateschema.pl script are not removed from Directory Server. However, you do not need to remove these schema changes manually because they will not affect Access Manager functionality or usability after the patch is backed out. Patch Installation Instructions For HP-UX SystemsTo install or remove the HP-UX patch, use the swinstall and swremove commands. For example, to install the patch to a standalone system: # swinstall /var/spool/patch/126371-09 Or, to remove the patch from a standalone system: # swremove 126371-09 For information about the swinstall and swremove commands, refer to the swinstall and swremove man pages. After you install or remove the patch, you must re-deploy the Access Manager applications as described in the Post-Installation Considerations section. After you re-deploy the Access Manager applications, execute the updateschema.sh script (patch 5 and later patches) to load the XML and LDIF files. The updateschema.sh script is available after you install patch 10 in the patch-home-directory/120956-09/scripts directory. After you run the amconfig and updateschema.sh scripts, restart the Access Manager web container. Note: If you remove the patch, the schema changes added by the updateschema.sh script are not removed from Directory Server. However, you do not need to remove these schema changes manually because they will not affect Access Manager functionality or usability after the patch is removed. For more information about deploying Access Manager on HP-UX systems, see the Sun Java System Access Manager 7 2005Q4 Release Notes for HP-UX. Post-Installation ConsiderationsConsiderations after you install an Access Manager 7 2005Q4 patch include:
CR# 6254355: Access Manager patches do not deploy Access Manager applications in postpatch scriptsThe 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 the base installation directory. The default base installation directory is /opt on Solaris systems and /opt/sun on Linux systems. On Windows systems, AccessManager-base is javaes-install-directory\AccessManager. For example: C:\Program Files\Sun\AccessManager The WAR files that get patched are:
These files are located in AccessManager-base/SUNWam on Solaris systems and AccessManager-base/identity on Linux systems. On Windows systems: the WAR files that get patched are located in AccessManager-base\. 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.
For more information about running the amconfig script, see the: Chapter 1, Access Manager 7 2005Q4 Configuration Scripts, in Sun Java System Access Manager 7 2005Q4 Administration Guide. CR# 6436409: Redeploying the Distributed Authentication and Client SDK WAR FilesIf 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 the following documents:
Access Manager 7 2005Q4 Patch 9Access Manager 7 patch 9 (revision 09) fixes a number of problems, as listed in the README file included with the patch. Access Manager 7 2005Q4 Patch 8Access Manager 7 patch 8 (revision 08) fixes a number of problems, as listed in the README file included with the patch. Patch 8 also includes these changes:
CR# 6668882: Cannot access Console that was installed with upper and lower case characters in domain nameIf Access Manager is installed with a domain name that contains both upper and lowercase characters, you cannot log in to the Console. For example, if the domain name is amhost.realm-name.Example.COM, you cannot log in using amhost.realm-name.example.com. Workaround. There are two workarounds: First, try logging in using the following URL: http://amhost.realm-name.example.com:port/amserver/UI/Login?realm=realm-name Or, add the realm-name to the Realm/DNS aliases:
CR# 6691106: Multiple SiteMonitor threads could be running for checking the same siteThe amNaming log sometimes indicates multiple SiteMonitor threads running for checking the same site. To prevent this problem, patch 8 provides improved synchronization to prevent the creation of the multiple SiteMonitor threads for the same site. Patch 8 also includes these new configuration properties:
The fix for this problem also uses the following property, which was added for patch 5:
The patch does not add these new properties to the AMConfig.properties file. To use these properties with values other than the default values:
CR# 6697260: New property to set policy agent application session idle timeoutPatch 8 includes this new property:
By default, policy agent sessions never expire unless you set this property. To use this new property, add it with the maximum idle timeout value to the AMConfig.properties file and restart the Access Manager web container. CR# 2151598: Delegation privileges cannot be defined for a filtered roleIf you create a new filtered role, it does not appear under the Privileges tab in the Admin Console. Workaround. After you apply patch 8, follow these steps to update the Delegation Service (sunAMDelegationService) in the Directory Server schema:
Now, when you log in to the Admin Console, the filtered role will appear under the Privileges tab. Access Manager 7 2005Q4 Patch 7Access Manager 7 patch 7 (revision 07) fixes a number of problems, as listed in the README file included with the patch. Patch 7 includes these changes:
CR# 6637806: After restart, Access Manager sent an invalid application SSO token to an agentAfter an Access Manager server restart, the Access Manager client SDK now sends a meaningful exception to an agent, so the agent can re-authenticate itself to get a new application session. Previously, after applying Access Manager 7 2005Q4 patch 5, the Access Manager client SDK sent a invalid application SSO token to the agent after an Access Manager server restart. This problem has been fixed by duplicate CR 6496155. Patch 7 also provides an option (comp.iplanet.dpro.session.dnRestrictionOnly property) to send the application SSO token in a restrictive context. By default, agents send the IP address of the server where they are installed, but if strict DN checking is required, set this property in the AMConfig.properties file as follows: com.iplanet.dpro.session.dnRestrictionOnly=true CR# 6612609: Session failover works if network cable is disconnected from Message Queue serverIn a session failover deployment, if each Access Manager instance and Message Queue broker are installed on the same server, session failover now works if a network cable is disconnected from one of the servers. By default the Message Queue imqAddressListBehavior connection factory attribute is set to PRIORITY, which causes Message Queue to try addresses in the order in which they appear in the broker address list (for example: localhost:7777,server2:7777,server3:7777). If the attribute is set to RANDOM, the addresses are tried in random order. To set this attribute to RANDOM, set the following parameter in the amsessiondb script: -DimqAddressListBehavior=RANDOM For information about the Message Queue PRIORITY and RANDOM attributes, see Broker Address List in Sun Java System Message Queue 3.7 UR1 Administration Guide. CR# 6570409: Interaction service behind load balancer works correctly as Identity ProviderIn a deployment with two servers connected with a load balancer and functioning as a single Identity Provider, you must set the following properties in the AMConfig.properties file: com.sun.identity.liberty.interaction.lbWspRedirectHandler com.sun.identity.liberty.interaction.trustedWspRedirectHandlers The com.sun.identity.liberty.interaction.interactionConfigClass is the only class currently supported. Thus, by default, the interaction configuration class bundled with Federation Liberty is used to access the interaction configuration parameters. CR# 6545176: Redirect URLs can be dynamically set in post authentication processing SPI plug-inRedirect URLs can now be dynamically set in post authentication processing SPI plug-ins for login success, login failure, and logout. If a post processing plug-in is not executed, the redirect URL set in the post processing SPI is not used, and redirect URLs set by any other means will be executed as before. For information, see the com.iplanet.am.samples.authentication.spi.postprocess.ISAuthPostProcessSample.java sample. Access Manager 7 2005Q4 Patch 6Access Manager 7 patch 6 (revision 06) fixes a number of problems, as listed in the README file included with the patch. Patch 6 also includes the following new features, issues, and documentation updates. New Features in Patch 6
Known Issues and Limitations in Patch 6
Note – Before you install patch 6, it is recommended that you upgrade or patch the following components:
Access Manager supports the JDK 1.5 HttpURLConnection setReadTimeout methodTo support the setReadTimeout method, the AMConfig.properties file has the following new property for you to set the read time-out value: com.sun.identity.url.readTimeout If the web container is using JDK 1.5, set this property to an appropriate value to cause connections to time out, in order to avoid having too many open HttpURLConnections that might cause the server to hang. The default is 30000 milliseconds (30 seconds). The setReadTimeout method is ignored if com.sun.identity.url.readTimeout is not present in the AMConfig.properties file or is set to an empty string. Access Manager SDK falls back to primary Directory Server after primary comes back upIf Sun Java System Directory Server is configured for multi-master replication (MMR), the Access Manager SDK now falls back to the primary Directory Server after the primary server goes down and then comes back up. Previously, the Access Manager SDK continued to access the secondary Directory Server even after the primary server came back up. To support this new behavior, Access Manager has the following new property in the AMConfig.properties file: com.sun.am.ldap.fallback.sleep.minutes This property sets the time in minutes that a secondary Directory Server instance sleeps before it falls back to the primary server after the primary server comes back up. The default is 15 minutes. The com.sun.am.ldap.fallback.sleep.minutes property is hidden. To set this property to a value other than the default (15 minutes), explicitly add it to the AMConfig.properties file. For example, to set the value to 7 minutes: com.sun.am.ldap.fallback.sleep.minutes=7 For the new value to take effect, restart the Access Manager web container. Multiple Access Manager instances log to separate log filesMultiple Access Manager instances running on the same host server can now log to separate log files in different logging subdirectories by setting the following new property in the AMConfig.properties file: com.sun.identity.log.logSubdir Unless you change the default logging directory in the Admin Console, the default logging directories are:
The first Access Manager instance always logs to the default logging directory. To specify different logging subdirectories for additional Access Manager instances, set the com.sun.identity.log.logSubdir property in the AMConfig.properties file for each additional Access Manager instance. For example, if you have three instances, am-instance-1, am-instance-2, and am-instance-3, all running on the same Solaris host server, set the property as follows: com.sun.identity.log.logSubdir=am-instance-2 com.sun.identity.log.logSubdir=am-instance-3 The com.sun.identity.log.logSubdir property is hidden. You must explicitly add this property to the AMConfig.properties file as needed and restart the Access Manager web container for subdirectory values to take effect. The Access Manager instances then log to the following directories: /var/opt/SUNWam/logs/log-files-for-am-instance-1 /var/opt/SUNWam/logs/am-instance-2/log-files-for-am-instance-2 /var/opt/SUNWam/logs/am-instance-3/log-files-for-am-instance-3 Access Manager 7 allows multiple cookie domainsTo support multiple cookie domains, Access Manager has the following new property: com.sun.identity.authentication.setCookieToAllDomains The default is true. This new property is hidden. To set the value to false, explicitly add the property to the AMConfig.properties file, and restart the Access Manager web container. Microsoft IIS 6.0 post-authentication plug-in supports SharePoint ServerThe Microsoft Internet Information Services (IIS) 6.0 authentication plug-in now supports the Microsoft Office SharePoint Server. A user can login to Access Manager with either a user ID or login name. SharePoint Server, however, accepts a login name, which causes problems when the user specifies a user ID. To allow a login to SharePoint Server, the post-authentication plug-in (ReplayPasswd.java) now uses the following new property: com.sun.am.sharepoint_login_attr_name This new property indicates the user attribute that SharePoint Server uses for authentication. For example, the following property species the common name (cn) for authentication: com.sun.am.sharepoint_login_attr_name=cn The post-authentication plug-in reads the com.sun.am.sharepoint_login_attr_name property and gets the corresponding attribute value for the user from Directory Server. The plug-in then sets the authorization headers to allow the user to access SharePoint Server. This property is hidden. To set the property, explicitly add it to the AMConfig.properties file, and then restart the Access Manager web container for the value to take effect. Access Manager supports Internet Explorer 7Access Manager 7 2005Q4 patch 6 now supports Microsoft Windows Internet Explorer 7. CR# 6379325 Accessing Console during session failover throws null pointer exceptionIn this scenario, multiple Access Manager servers are deployed in session failover mode behind a load balancer configured for cookie-based sticky request routing. The Access Manager administrator accesses the Access Manager Console through the load balancer. When the administrator logs into the Console, the session is created on one of the Access Manager servers. If that server goes down, the Console session fails over to another Access Manager server, as expected. The administrator, however, sometimes experiences intermittent null pointer exceptions on the browser and in the web-container error log. The issue affects only the active Access Manager Console session at the time of the failover and not the functioning of the Access Manager servers. Workaround: To prevent these intermittent null pointer exceptions:
CR# 6508103: On Windows, clicking Help in the Admin Console returns an application errorOn Windows 2003 Enterprise Edition with Access Manager deployed on Sun Java System Application Server in locales other than English, clicking Help in the Admin Realm Mode Console returns an application error. Workaround:
CR# 6564877: Access Manager 7 patch installation overwrites SAML v2 filesIf the SAML v2 plug-in is installed, the patch installation overwrites the SAML v2 related files, and the postpatch script displays this message: The postpatch script detected that the SAML v2 plug-in is installed in your environment. When you run the amconfig script to redeploy the Access Manager applications, the script will recreate the amserver.war file and the SAML v2 related files will be lost. Therefore, after you run amconfig, recreate and redeploy the amserver.war file, as described in the Sun Java System SAML v2 Plug-in for Federation Services User's Guide. Workaround: After you install the patch and run the amconfig script, recreate and redeploy the amserver.war file for the Federation Manager or Access Manager deployments that use the SAML v2 plug-in. For the specific steps, see Chapter 2, Installing the SAML v2 Plug-in for Federation Services, in Sun Java System SAML v2 Plug-in for Federation Services User’s Guide. Access Manager 7 2005Q4 Patch 5Access Manager 7 patch 5 (revision 05) fixes a number of problems, as listed in the README file included with the patch. Patch 5 also includes the following new features, issues, and documentation updates. New Features in Patch 5
Known Issues and Limitations in Patch 5
Globalization (g11n) Issues Documentation Updates
Support for HP-UX SystemsPatch 126371 provides support for HP-UX systems. For more information see: For information about installation on HP-UX systems, see the Sun Java Enterprise System 2005Q4 Installation Guide for UNIX. Support for Microsoft Windows SystemsPatch 124296 provides support for Windows systems. For more information see: For information about installation on Windows systems, see the Sun Java Enterprise System 2005Q4 Installation Guide for Microsoft Windows. New updateschema.sh script to load LDIF and XML filesPatch 5 (and later) includes the updateschema.sh script to load the following files to update the Directory Server service schema:
In previous Access Manager patch releases, you were required to load these files manually. To run the updateschema.sh script:
Note If you back out patch 5, the schema changes added by the updateschema.sh script are not removed from Directory Server. However, you do not need to remove these schema changes manually because they will not affect Access Manager functionality or usability after the patch is backed out. Support for specific application idle session timeout valuesPatch 5 allows different applications to have different session idle timeout values. In an enterprise, some applications might require session idle timeout values that are less than the session idle time out specified in the session service. For example, you have specified session the idle timeout value in the session service as 30 minutes, but an HR application should timeout if a user has been idle for more than 10 minutes. Requirements to use this feature are:
To use this feature:
For example, consider a policy http://host.sample.com/hr/*, with this Authentication Scheme Condition:
If there are multiple policies defined to protect resources of the HR application, you must add the Condition to all of the policies. When a user in a distinct session attempts to access the HR application protected by the Access Manager agent, that user is prompted to authenticate for the LDAP scheme (if the user is not yet authenticated). If the user has already authenticated to the LDAP scheme, that user is allowed access only if the time is less than 10 minutes since the time the last authentication or if the time is less than 10 minutes since that user's last access time to the HR application. Otherwise, the user is prompted to authenticate to the LDAP scheme again to access the application. CDC Servlet can be deployed on a Distributed Authentication UI serverThe CDC Servlet can coexist with a Distributed Authentication UI server in the DMZ to enable Cross-Domain Single Sign-On (CDSSO). The Access Manager server can be deployed behind a firewall, and all access to Access Manager to achieve CDSSO is handled by the CDC Servlet in the Distributed Authentication UI server. To enable CDSSO, refer to the specific policy agent documentation and perform these additional steps:
Realm can be specified when CDC servlet redirects to the Access Manager login URLYou can now specify a realm name to the CDC servlet, so that when the redirect to the Access Manager login URL occurs, the realm name is included, and the user can logo into the specific realm. For example: com.sun.am.policy.agents.config.cdcservlet.url=
http://lb.example.com/amserver/cdcservlet?org=realm1
Certificate Authentication can use UPN value to map user profilePreviously, Certificate Authentication used only the dn component in the subjectDN to map a user profile. Access Manager now allows the user principal name (UPN) value in SubjectAltNameExt for profile mapping. Post authentication processing of logout occurs in a multiple-server environmentPost authentication processing now occurs when a user logs out of a different server from the one originally logged into in a multiple-server environment, either with or without session failover configured. SAML supports a new name identifier SPISAML now supports a new name identifier service provider interface (SPI), so that a site can customize the name identifier in the SAML assertion. A site can implement the new NameIdentifierMapper interface to map a user account to a name identifier in the subject of a SAML assertion. New Configuration Properties for Site MonitoringThe Access Manager site monitoring feature includes the following new properties to allow you to specify the behavior of the site status check.
The patch does not add these properties to the AMConfig.properties file. To use these new properties with values other than the default values:
User no longer must authenticate twice in authentication chainConsider the following scenario. A site configures an authentication chain with three LDAP modules. All modules are set to SUFFICIENT, and both the iplanet-am-auth-shared-state-enabled and iplanet-am-auth-store-shared-state-enabled options are set to true. For example: <AttributeValuePair> <Value>A-LDAP SUFFICIENT iplanet-am-auth-shared-state-enabled=true iplanet-am-auth-store-shared-state-enabled=true</Value> <Value>B-LDAP SUFFICIENT iplanet-am-auth-shared-state-enabled=true iplanet-am-auth-store-shared-state-enabled=true</Value> <Value>C-LDAP SUFFICIENT iplanet-am-auth-shared-state-enabled=true iplanet-am-auth-store-shared-state-enabled=true</Value> </AttributeValuePair> Patch 5 adds the new iplanet-am-auth-shared-state-behavior-pattern option to the module options with two possible values: tryFirstPass (default) and useFirstPass. To prevent a user from having to enter the user ID and password twice to get authenticated (as described in the previous scenario), set this new option to useFirstPass for all modules in the chain. Previously, a user who existed only in the third LDAP instance was required to enter a user ID and password twice to get authenticated. Changes to Performance Tuning ScriptsPatch 5 includes these changes to the performance tuning scripts:
Tuning scripts support a password filePatch 5 allows you to specify passwords for the tuning scripts in a text file. Previously, you could enter passwords only as a command-line argument, which could cause security issues. To use a password file, set the following variables, as needed, in the file: DS_ADMIN_PASSWORD=DirectoryServer-admin-password AS_ADMIN_PASSWORD=ApplicationServer8-admin-password For example, to tune Application Server 8: # ./amtune-as8 password-file where password-file contains AS_ADMIN_PASSWORD set to the Application Server 8 administrator password. The tuning scripts use the -j password-file option when they call the ldapmodify, ldapsearch, db2index, and dsconf Directory Server utilities. Tuning script removes unnecessary ACIs from Directory ServerIf Access Manager 7 2005Q4 is installed in Realm Mode, delegation privileges are used to determine access permissions, and therefore some Directory Server ACIs are not needed. Access Manager 7 2005Q4 patch 5 allows you to remove the unnecessary ACIs by running the amtune-prepareDSTuner script. This script reads a list of ACIs from the remacis.ldif file and then calls the ldapmodify utility to remove them. You can run the amtune-prepareDSTuner script to remove the unnecessary ACIs on Solaris, Linux, HP-UX, and Windows systems. For more information, including how to run the script, see Technical Note: Sun Java System Access Manager ACI Guide. Tuning scripts can tune the Distributed Authentication UI server web containerAfter you deploy the Distributed Authentication UI server on a web container, you can tune the web container by running the Access Manager tuning scripts. The following tuning scripts set the JVM and other tuning options for the respective web container: Table 2 Access Manager Web Container Tuning Scripts
To tune a web container for a Distributed Authentication UI server:
For more information about running the tuning script to tune an Access Manager web container, see Chapter 2, Access Manager Tuning Scripts, in Sun Java System Access Manager 7 2005Q4 Performance Tuning Guide. Single amtune-os script tunes both Solaris OS and Linux OSPatch 5 includes a single amtune-os script to tune both the Solaris OS and Linux OS. The script determines the OS type from the uname -s command. Previously, Access Manager provided separate amtune-os scripts to tune each OS. Tuning scripts run to completion in a Solaris 10 local zoneIf Access Manager is installed in a Solaris 10 local zone, all tuning scripts except amtune-os can run in the local zone. In a local zone, the amtune-os script displays a warning message but does not tune the OS. The script then continues running any other tuning scripts that you have requested. Previously, in a local zone, the amtune-os script would abort, and any subsequent tuning scripts that you requested would not run. In a Solaris 10 global zone, the amtune script invokes amtune-os to tune the OS as well as any other scripts that you have requested to run. Tuning scripts are available for Windows systemsPatch 5 includes tuning scripts for Windows systems. Running the tuning scripts on a Windows system is similar to running the scripts on a Solaris system or Linux system, with these differences:
Tuning Considerations for Sun Fire T1000 and T2000 ServersIf Access Manager is installed on a Sun Fire T1000 or T2000 server, the Patch 5 tuning scripts for Web Server 6.1 and Application Server 8 set the JVM GC ParallelGCThreads parameter to 8: -XX:ParallelGCThreads=8 This parameter reduces the number of garbage collection threads, which could be unnecessarily high on a 32–thread capable system. However, you can increase the value to 16 or even 20 for a 32 virtual CPU machine such as a Sun Fire T1000 or T2000 server, if it minimizes full garbage collection activities. Also, for Solaris SPARC systems with a CMT processor with CoolThreads technology, in the /etc/opt/SUNWam/config/AMConfig.properties file, it is recommended that you add the following property at the end of the file: com.sun.am.concurrencyRate=value The default value is 16, but you can set this property to a lower value, depending on the number of cores in the Sun Fire T1000 or T2000 server. Basic Authentication in the IIS 6.0 Policy AgentTo enable Basic Authentication in the Microsoft Internet Information Services (IIS) 6.0, the policy agent must obtain the user's name and password. Patch 5 includes the following new classes to enable this functionality using DES encryption of the user's password:
To use the Basic Authentication in IIS 6.0, you must perform steps on both the Access Manager server side and the IIS 6.0 policy agent side. On the Access Manager server side:
On the IIS 6.0 policy agent side:
The IIS 6.0 policy agent reads the encrypted password from the session response, decrypts the password from the com.sun.am.replaypasswd.key property, and sets the authentication headers, to allow the Basic Authentication to work. For information about the IIS 6.0 policy agent, see the Sun Java System Access Manager Policy Agent 2.2 Guide for Microsoft Internet Information Services 6.0. CR# 6567746: On HP-UX systems, Access Manager patch 5 reports incorrect errorCode value if password retry count is exceededWhen a user's account is locked, Access Manager 7 2005Q4 patch 5 on HP-UX systems reports errorCode = null instead of errorCode = 107 if the password retry count is exceeded. Workaround. None. CR# 6527663: Default value for com.sun.identity.log.resolveHostName property should be false instead of trueBefore you run the amtune-identity tuning script, it is recommended that you add the following property set to false to the AMConfig.properties file: com.sun.identity.log.resolveHostName=false A value of false minimizes the impact of resolving host names and thus can improve performance. However, if you want the client machine's hostname to be printed in the amAuthentication.access log, set the value to true. CR# 6527528: Patch removal leaves XML files with amldapuser password in clear textIf you remove patch 5 from an Access Manager full server installation, the amAuthLDAP.xml and amPolicyConfig.xml files contain the amldapuser password in clear text. These files are in the following directory, depending on your platform:
Workaround: Edit the amAuthLDAP.xml and amPolicyConfig.xml files and delete the clear text password. CR# 6527516: Full server on WebLogic requires JAX-RPC 1.0 JAR files to communicate with client SDKIn Access Manager 7 2005Q4 patches, the Access Manager configuration script for BEA WebLogic Server (amwl81config) adds the JAX-RPC 1.1 JAR files to the classpath for the WebLogic instance. While this modification is beneficial to products such as Sun Java System Portal Server, a full server installation (DEPLOY_LEVEL=1) deployed on WebLogic Server cannot communicate with a client SDK installation, and exceptions will subsequently occur. If Access Manager 7 2005Q4 server is installed on BEA WebLogic Server, the CLASSPATH in the startWebLogic.sh script must be set to the location of the JAX-RPC 1.0 JAR files to communicate with Access Manager client SDK. Workaround: Before applying the Access Manager patch, set the CLASSPATH in the startWebLogic.sh script for the WebLogic Server instance to use the JAX-RPC 1.0 JAR files instead of the JAX-RPC 1.1 JAR files:
Current value: CLASSPATH=/etc/opt/SUNWam/config: AccessManager-base/AccessManager-package-dir/lib/jax-qname.jar: AccessManager-base/AccessManager-package-dir/lib/namespace.jar: AccessManager-base/AccessManager-package-dir/lib/jaxrpc-api.jar: AccessManager-base/AccessManager-package-dir/lib/jaxrpc-spi.jar: AccessManager-base/AccessManager-package-dir/lib/jaxrpc-impl.jar: New value: CLASSPATH=/etc/opt/SUNWam/config: AccessManager-base/AccessManager-package-dir/lib/jax-qname.jar: AccessManager-base/AccessManager-package-dir/lib/namespace.jar: AccessManager-base/AccessManager-package-dir/lib/jaxrpc_1.0/jaxrpc-api.jar: AccessManager-base/AccessManager-package-dir/lib/jaxrpc-ri.jar: where AccessManager-base is the base installation directory. The default value is /opt on Solaris systems and /opt/sun on Linux and HP-UX systems. AccessManager-package-dir is the Access Manager package directory. 5. Restart the WebLogic Server instance. CR # 6523499: Patch 5 amsilent file is readable by all users on Linux systemsOn Linux systems. the postpatch script creates the /opt/sun/identity/amsilent file with permissions of 644, which allows read access by all users. Workaround: After executing the installpatch script, change the permissions on the amsilent file to allow read and write access only to the owner. For example: # chmod 600 /opt/sun/identity/amsilent CR# 6520326: Applying patch 5 to a second Access Manager instance on a server overwrites serverconfig.xml for first instanceIn this deployment scenario, two Access Manager instances are deployed on the same host server, with each instance on a different web container instance. You then follow these steps:
If NEW_INSTANCE=false in the amsilent file, the serverconfig.xml file for the first Access Manager instance is overwritten with information from the second Access Manager instance. A subsequent restart of the first Access Manager instance fails. The serverconfig.xml file is in the following directory depending on your platform:
Workaround: When you deploy the second Access Manager, set NEW_INSTANCE=true in the amsilent file. The serverconfig.xml file for the second Access Manager instance is then updated with the correct information, and the serverconfig.xml file for the first Access Manager instance is not overwritten. CR# 6520016: Patch 5 SDK-only install overwrites the samples makefilesApplying patch 5 to an SDK-only machine overwrites the samples makefiles. Workaround: Applying patch 5 to an SDK-only machine does not require a reconfiguration; however, if you want to use the samples makefiles, follow these steps to update the LDIF and properties files (that is, perform tag swapping) for the samples makefiles:
CR#6515502: LDAPv3 repository plug-in does not always handle Alias Search Attribute correctlyFor most searches, this problem has been fixed. However, be careful when setting the Alias Search Attribute. The value of the alias search attributes must be unique across an organization. If more than one alias search attribute is set, it is possible that one entry in the data store matches one attribute, and another entry matches with the other attribute. In this situation, Access Manager server throws the following error: An internal authentication error has occurred. Contact your system administrator. Workaround: None CR# 6515383: Distributed Authentication and J2EE agent do not work in same web containerA Distributed Authentication UI server and a J2EE policy agent do not work if they are installed in the same web container. Workaround: Create a second web container instance and deploy the Distributed Authentication UI server and J2EE policy agent on different instances of the container. CR# 6508103: Online help returns application error with Application Server on Windows systemsIf you deploy Access Manager on Sun Java System Application Server on a Windows system, clicking Help in the left panel of the help screen for the Realm Mode console returns an application error. Workaround: Copy the javaes-install-dir\share\lib\jhall.jar file to the JAVA_HOME\jre\lib\ext directory and then restart Application Server. CR# 6507383 and CR# 6507377: Distributed Authentication requires explicit goto URL parameterIf an explicit goto URL parameter is not specified, a Distributed Authentication UI server attempts to redirect to the goto on a success URL specified in Access Manager. This redirect can fail for these reasons:
Workaround: Always specify an explicit goto URL parameter for a Distributed Authentication UI server. CR# 6402167: LDAP JDK 4.18 causes LDAP client/Directory Server problemsAccess Manager 7 2005Q4 was released with LDAP JDK 4.18 as part of the Java ES 2005Q4 release, which resulted in a number of Access Manager and Directory Server connection problems. Workaround: Apply one of the following Sun Java System LDAP Java Development Kit patches:
The patches are available on SunSolve Online: http://sunsolve.sun.com. CR# 6352135: Distributed Authentication UI server files are installed in incorrect locationOn Solaris systems, the Java ES installer installs the Distributed Authentication UI server Makefile.distAuthUI, README.distAuthUI, and amauthdistui.war files in an incorrect location: /opt/SUNComm/SUNWam. Workaround: Copy these files to their correct location: /opt/SUNWam. Note: Any Distributed Authentication UI server problems fixed in a patch will go into the /opt/SUNComm/SUNWam/amauthdistui.war file, so whenever you apply a patch to the Access Manager server and then rebuild and deploy the WAR file, you must also copy these files to the /opt/SUNWam directory. CR# 6522720: Search in console online help does not work for multibyte characters on Windows and HP-UX systemsIf Access Manager is installed in a locale that uses multibyte characters (such as Japanese) on a Windows or HP-UX system, a search in the console online help with keywords entered using multibyte characters does not work. Workaround: None Patch 6 update: Access Manager 7 2005Q4 patch 6 fixes this problem on Windows systems. However, the problem still exists on HP-UX systems. CR# 6524251: Multibyte characters in output messages are garbled during Access Manager configuration on Windows systemsIf Access Manager is installed in a locale that uses multibyte characters (such as Japanese or Chinese) on a Windows system, during Access Manager configuration, words are garbled in output messages at the terminal window. Workaround: None, but this problem does not affect the configuration itself. CR# 6526940: Property keys appear instead of message text during patch 5 installation in non-English locales on Windows systemsIf you install patch 5 (124296-05) in a non-English locale on a Windows system, some strings in the install panels appear as property keys instead of the actual message text. Examples of property keys are PRODUCT_NAME, JES_Patch_FinishPanel_Text1, and JES_Patch_FinishPanel_Text2. Workaround: None CR# 6513653: Issue with com.iplanet.am.session.purgedelay property settingThe Access Manager amtune script sets the com.iplanet.am.session.purgedelay property to 1, in order to allow as many Access Manager sessions as possible. This property specifies the number of minutes to delay the purge session operation. For clients such as Sun Java System Portal Server, however, a value of 1 might not be sufficient. Workaround: Reset the com.iplanet.am.session.purgedelay property after you run the amtune script:
Access Manager 7 2005Q4 Patch 4Access Manager 7 2005Q4 patch 4 (revision 04) fixes the following problems:
Known Issues and Limitations in Patch 4
CR# 6470055: Distributed Authentication UI server performance improvementTo improve performance in reading, searching, and comparing user attributes for a Distributed Authentication UI server user, follow these steps:
CR# 6455079: Password reset service reports notification errors when a password is changedWhen a password is changed, Access Manager submits the email notification using the unqualified sender name Identity-Server, which results in error 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: Change the from address to include the fully qualified domain name of the host server in the amPasswordResetModuleMsgs.properties file:
Access Manager 7 2005Q4 Patch 3Access 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 in Patch 3 Known Issues and Limitations in Patch 3
New Configuration Properties for Site MonitoringThe Access Manager site monitoring feature includes these new properties:
The patch does not add these properties to the AMConfig.properties file. To use these new properties with values other than the default values:
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 SupportThe 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, shown with Access Manager installed in the default directory on Solaris systems: # /opt/SUNWam/bin/amadmin -u amadmin -w amadmin_password -t /etc/opt/SUNWam/wsf1.1_upgrade.xml 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# 6463779 Distributed Authentication amProfile_Client log and Access Manager server amProfile_Server log are filled with harmless exceptionsRequests to Access Manager server via a Distributed Authentication UI triggers exceptions in the distAuth/amProfile_Client log and the Access Manager server debug/amProfile_Server log. After numerous sessions, the amProfile_Client log can grow to several gigabytes, and the Access Manager server amProfile_Server log can grow to several megabytes. No loss of functionality is caused by these exceptions in the logs, but they can cause a false alarm for users, and potentially the logs can fill up the hard disk space. Workaround. Run cron jobs that will make the contents of the log files null. For example:
CR# 6460974 Default Distributed Authentication Application User should not be amadminIf you are deploying a Distributed Authentication UI server, the Distributed Authentication administrator should not be amadmin. The default Distributed Authentication Application User in the Makefile.distAuthUI file is amadmin and subsequently in the AMConfig.properties file after the distAuth.war file is deployed on the client side. The amadmin user has an AppSSOToken that expires after the amadmin session time runs out, which can cause a FATAL ERROR in the amSecurity log file (located by default in the /tmp/distAuth directory). Workaround. Specify UrlAccessAgent as the Distributed Authentication Application User. For example: Before deploying the distAuth.war file in the client Web container, change the following parameters in the Makefile.distAuthUI file: APPLICATION_USERNAME=UrlAccessAgent APPLICATION_PASSWORD=shared-secret-password or amldapuser-password or After deploying the distAuth.war file in the client Web container, change the following properties in the AMConfig.properties file for each Access Manager server: com.sun.identity.agents.app.username=UrlAccessAgent com.iplanet.am.service.password=shared-secret-password or amldapuser-password See also CR# 6440697: Distributed Authentication should run as non-amadmin user. CR# 6460576 No link for the User Service under Filtered Role in console online HelpThe Access Manager Console online Help does not have a link for the User Service under Filtered Role. In the online Help, go to Contents, Filtered Role, and “To Create a Filtered Role”. Page down and, depending on the identity type you selected, a list of services is displayed, but a User Service link is not available. Workaround. None CR# 6460085 Server on WebSphere is not accessible after running reinstallRTM and redeploying Web applicationsAfter applying Access Manager 7 patch 3 for a DEPLOY_LEVEL=1 deployment on IBM WebSphere Application Server 5.1.1.6 on Red Hat Linux AS 3.0 Update 4, the reinstallRTM script was run to restore the RTM RPMs. The Web applications were then redeployed after editing the amsilent file generated by the reinstallRTM script. WebSphere was restarted using the stopServer.sh and startServer.sh scripts. When accessing the login page, however, WebSphere displayed a 500 error, related to the amlcontroller filter. This problem occurred because the new server.xml file generated by the reinstallRTM script was corrupt. Workaround. The server.xml file backed up by the amconfig script is still valid. Use this previous copy, as follows:
CR# 6455757: sunISManagerOrganization marker class must be added to an organization before an upgradeAn organization in an Access Manager DIT that was created before the Access Manager 7 release might not have the sunISManagerOrganization object class. Also, an organization created by a product other than Access Manager will not have the sunISManagerOrganization object class in its definition. Workaround. Before you upgrade to Access Manager 7 2005Q4, make sure that all organizations in the DIT have the sunISManagerOrganization 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 Console Current Sessions tabAn 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 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:
CR# 6452320: Exceptions are thrown when using polling with client SDKWhen 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 a Distributed Authentication UI server, 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 4 GB 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 4 GB of RAM. CR# 6442905 SSOToken of authenticated user can be unintentionally revealed to rogue sitesAn authenticated Access Manager user can unintentionally reveal the SSOToken to a rogue site by clicking on a URL from the rogue site. Workaround. Always create a unique agent user profile in Access Manger for all participating Policy Agents to make sure that the site is not rogue. Also, make sure that none of these unique agent users use the same password as the shared secret password or amldapuser password. By default, Policy Agents are authenticated to the Access Manager Application authentication module as the UrlAccessAgent user. For more information about creating an agent using the Access Manager Admin Console, see Agents in Sun Java System Access Manager 7 2005Q4 Administration Guide. CR# 6441918: Site monitor interval and time-out propertiesAccess 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 userTo create a Distributed Authentication administrator other than the default administrative user (amadmin) for Distributed Authentication application authentication, follow this procedure:
CR# 6440695: Distributed Authentication UI servers with a load balancerIf 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 replay requires com.sun.identity.session.resetLBCookie propertyFor cookie replaying to work properly for Access Manager session failover, add the com.sun.identity.session.resetLBCookie property with a value of true for both the Policy Agent and the Access Manager server. For example: com.sun.identity.session.resetLBCookie='true'
Note: This property is required only if you have implemented Access Manager session failover. CR# 6440648: com.iplanet.am.lbcookie.name property assumes default value of amlbcookieBy 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 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 deprecatedAccess Manager no longer supports 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 caseAfter 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 loginWhen 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 with Access Manager installed in the default directory on Solaris systems: # /opt/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 URLAn 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. To override the “goto” URL after the authentication is complete, set the property shown in the following example in the SSOToken. You set this property using the onLoginSuccess method of the PostProcess class implementing the AMPostAuthProcessInterface. For example, OverridingURL is the URL that overrides the “goto”URL: public class <..> implements AMPostAuthProcessInterface {
...
public void onLoginSuccess(...) {
try {
ssoToken.setProperty("PostProcessSuccessURL", OverridingURL);
} catch (Exception ...) {
... }
...
}
CR# 6385184: Re-direct from within a custom authentication module when SSO Token is still in invalid stateNew RedirectCallback for custom authentication module allows redirection to an external Web site via the Authentication UI to get a user validated. If the authentication is successful, the user is then redirected back to the original Access Manager server URL. Sample files include:
To implement this feature:
The user name and password are redirected to the external Web site for validation. If the name and password are valid, the authentication is successful and the user is then redirected back to the original Access Manager server URL. For example, consider this scenario, where the deployment is using a custom authentication module to access a provisioning/credit card site:
CR# 6324056: Federation fails when using artifact profileWorkaround: 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 2Access Manager 7 2005Q4 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 in Patch 2 Known Issues and Limitations in Patch 2
New Properties for the User Management, Identity Repository, and Service Management CachesPatch 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. Table 3 New Properties for the User Management, Identity Repository, and Service Management Caches
Using the New Caching Properties The Access Manager 7 2005Q4 patches do not automatically add the new caching properties to the AMConfig.properties file. To use the new caching properties:
New Property for Federation Service ProviderThe 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. LDAP Filter Condition SupportLDAP Filter Condition support is added in patch 2. A policy administrator can now specify an LDAP filter in the Condition while defining a policy. The Policy is 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 Configuration service. To register and use the LDAP Filter Condition, run following commands after the Access Manager 7 patch 2 is installed shown with Access Manager installed in the default directory on Solaris systems: # /opt/SUNWam/bin/amadmin -u amadmin -w amadmin_password -s /etc/opt/SUNWam/AddLDAPFilterCondition.xml # /opt/SUNWam/bin/amadmin -u amadmin -w amadmin_password -t /etc/opt/SUNWam/amPolicyConfig_mod_ldfc.xml Patch 5 Note If you added Access Manager 7 2005Q4 Patch 5 and ran the updateschema.sh script, you do not need to load these files using amadmin. For more information see New updateschema.sh script to load LDIF and XML files. CR# 6283582: Num of login failures are not shared across Access Manager instancesAfter Access Manager 7 patch 2 is installed, run following commands, shown with Access Manager installed in the default directory in Solaris systems: # cd DirectoryServer-base/shared/bin # ./ldapmodify -h DirectoryServerHost -p DirectoryServerPort -D "cn=Directory Manager" -w DirectoryMangerPassword -a -f /etc/opt/SUNWam/accountLockout.ldif # /opt/SUNWam/bin/amadmin -u amadmin -w amadmin_password -t /etc/opt/SUNWam/accountLockoutData.xml The default value of DirectoryServer-base is /var/opt/mps/serverroot on Solaris systems and /var/opt/sun/directory-server on Linux systems. Patch 5 Note If you added Access Manager 7 2005Q4 Patch 5 and ran the updateschema.sh script, you do not need to load these files using amadmin. For more information see New updateschema.sh script to load LDIF and XML files. CR# 6293673: Need to retain the original session information when sending out session timeout notificationThe new com.sun.identity.session.property.doNotTrimList property in the AMConfig.properties file can contain list of comma separated session property names. Once a session is timed out, the properties defined in this list will not be trimmed off, so that they 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 availableThe new com.sun.identity.am.cookie.check property in the AMConfig.properties file indicates whether the server should check for the cookie support / cookie enabled in the browser. A value of true causes the server to check for the cookie support / cookie enabled in the browser and to throw an error page if the browser does not support or has not enabled cookies. This value should be set to false (which is the default) if the server is expected to support cookie-less mode for authentication functionality. CR# 6236892: Image/Text place holder while CDCServlet is processing the AuthNResponse after loginThe following new properties are added to AMConfig.properties file and are read by the CDCServlet:
CR# 6363157: New property disables persistent searches if absolutely requiredThe new com.sun.am.event.connection.disable.list property in the AMConfig.properties file specifies which event connection can be disabled. Values (case insensitive) can be: aci - Changes to the aci attribute, with the search using the LDAP filter (aci=*) sm - Changes in the Access Manager information tree (or service management node), which includes objects with the sunService or sunServiceComponent marker object class. For example, you might create a policy to define access privileges for a protected resource, or you might modify the rules, subjects, conditions, or response providers for an existing policy. um - Changes in the user directory (or user management node). For example, you might change a user's name or address. For example, to disable persistent searches for changes to the Access Manager information tree (or service management node): com.sun.am.event.connection.disable.list=sm To specify multiple values, separate each value with a comma. Caution – Persistent searches cause some performance overhead on Directory Server. If you determine that removing some of this performance overhead is absolutely critical in a production environment, you can disable one or more persistent searches using the com.sun.am.event.connection.disable.list property. However, before disabling a persistent search, you should understand the limitations described above. It is strongly recommended that this property not be changed unless absolutely required. This property was introduced primarily to avoid overhead on Directory Server when multiple 2.1 J2EE agents are used, because each of these agents establishes these persistent searches. The 2.2 J2EE agents no longer establish these persistent searches, so you might not need to use this property. For more information, see Document more information about disabling persistent searches (6486927). CR# 6385696: Existing and new IDPs and SPs are not visibleThe new com.sun.identity.federation.spadapter property in the AMConfig.properties file specifies the default implementation of the federation service provider adapter where the application can get assertions and response information. For example: com.sun.identity.federation.spadapter=com.sun.identity.federation.plugins.FSDefaultSPAdapter Access Manager 7 2005Q4 Patch 1Access Manager 7 2005Q4 patch 1 (revision 01) fixed a number of problems, as listed in the README file included with the patch. Patch 1 also includes the following new features and known issues: Creation of Debug FilesAccess 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. Support for Roles and Filtered Roles in the LDAPv3 Plug-inAccess Manager 7 patch 1 adds support for roles and filtered roles in the LDAPv3 plug-in, if the data is stored in Sun Java System Directory Server. For more information, see Document the roles and filtered roles support for LDAPv3 plug-in (6365196). CR# 6320475: com.iplanet.am.session.client.polling.enable on server side must not be trueThe 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 keyIf the password encryption key contains spaces, applying the patch fails. Workaround. Use a new encryption key that includes no spaces. For the detailed steps to change the encryption key, see: Appendix B, Changing the Password Encryption Key, in Sun Java System Access Manager 7 2005Q4 Deployment Planning Guide. What’s New in This ReleaseFor a list of new features in the Access Manager patch releases, see Access Manager 7 2005Q4 Patch Releases. The initial release of Access Manager 7 2005Q4 included the following new features: Access Manager ModesAccess Manager 7 2005Q4 includes Realm mode and Legacy mode. Both modes support:
Legacy mode is required for:
New Access Manager ConsoleThe Access Manager Console has been redesigned for this release. However, if Access Manager is deployed with Portal Server, Messaging Server, Calendar Server, Instant Messaging, or Delegated Administrator, you must install Access Manager in Legacy mode and use the Access Manager 6 2005Q1 Console: For more information, see Compatibility Issues. Identity RepositoryAn Access Manager identity repository contains information pertinent to identities such as users, groups, and roles. You can create and maintain an identity repository using either Access Manager or another provisioning product such as Sun Java System Identity Manager. In the current release, an identity repository can reside in either Sun Java System Directory Server or Microsoft Active Directory. Access Manager can have read/write access or read-only access to an identity repository. Access Manager Information TreeThe Access Manager information tree contains information pertinent to system access. Each Access Manager instance creates and maintains a separate information tree in Sun Java System Directory Server. An Access Manager information tree can have any name (suffix). The Access Manager information tree includes realms (and sub-realms, if needed), as described in the following section. Access Manager RealmsA realm and any sub-realms are part of the Access Manager information tree and can contain configuration information that defines a set of users and/or groups, how users authenticate, which resources users can access, and the information that is available to applications after users are given access to resources. A realm or sub-realm can also contain other configuration information, including globalization configuration, password reset configuration, session configuration, console configuration, and user preferences. A realm or sub-realm can also be empty. You can create a realm using either the Access Manager Console or the amadmin CLI utility. For more information refer to the Console online help or the Chapter 14, The amadmin Command Line Tool, in Sun Java System Access Manager 7 2005Q4 Administration Guide. Session Failover ChangesAccess Manager provides a web container independent session failover implementation using Sun Java System Message Queue (Message Queue) as the communications broker and the Berkeley DB by Sleepycat Software, Inc. as the session store database. Access Manager 7 2005Q4 enhancements includes the amsfoconfig script to configure the session failover environment and the amsfo script to start and stop the Message Queue broker and Berkeley DB client. For more information, see Implementing Access Manager Session Failover in Sun Java System Access Manager 7 2005Q4 Deployment Planning Guide. Session Property Change NotificationThe session property change notification feature enables Access Manager to send a notification to the specific listeners when a change occurs on a specific session property. This feature takes effect when the “Enable Property Change Notifications” attribute is enabled in the Access Manager administrator Console. For example, in a single sign-on (SSO) environment, one Access Manager session can be shared by multiple applications. When a change occurs on a specific session property defined in the “Notification Properties” list, Access Manager sends a notification to all registered listeners. For more information, see Enabling Session Property Change Notifications in Sun Java System Access Manager 7 2005Q4 Deployment Planning Guide. Session Quota ConstraintsThe session quota constraints feature allows the Access Manager administrator (amadmin) to set the “Active User Sessions” attribute to limit the maximum number of concurrent sessions allowed for a user. The administrator can set a session quota constraint at the global level for all users or for an entity such as an organization, realm, role, or user that applies only to one or more specific users. By default, session quota constraints are disabled (OFF), but the administrator can enable them by setting the “Enable Quota Constraints” attribute in the Access Manager administrator Console. The administrator can also configure the behavior if a user exhausts the session constraint quota by setting the “Resulting Behavior If Session Quota Exhausted” attribute:
The “Exempt Top-Level Admins From Constraint Checking” attribute specifies whether session constraint quotas apply to the administrators who have the “Top-level Admin Role”. For more information, see Setting Session Quota Constraints in Sun Java System Access Manager 7 2005Q4 Deployment Planning Guide Distributed AuthenticationAccess Manager 7 2005Q4 includes the Distributed Authentication UI, which is a remote authentication UI component that provides for secure, distributed authentication across two firewalls in a deployment. Without the Distributed Authentication UI component, the Access Manager service URLs can be exposed to the end users. This exposure can be avoided by using a proxy server; however, a proxy server is not necessarily an acceptable solution for many deployments. The Distributed Authentication UI component is installed on one or more servers within the non-secure (DMZ) layer of an Access Manager deployment. A Distributed Authentication UI server does not run Access Manager; it exists only to provide the authentication interface to end users through a web browser. The end user sends an HTTP request to the Distributed Authentication UI, which in turn presents a login page to the user. The Distributed Authentication component then sends the user's request through the second firewall to an Access Manager server, which eliminates the need to open holes in the firewalls between the end users and the Access Manager server. For more information, see the Technical Note: Using Access Manager Distributed Authentication. Multiple Authentication Module Instances SupportAll authentication modules (out of box) are extended to support the sub-schema with Console UI support. Multiple authentication module instances can be created for each module type (module class loaded). For example, for instances with names of ldap1 and ldap2 for an LDAP module type, each instance can point to a different LDAP directory server. Module instances with the same names as their types are supported for backward compatibility. Invocation is: server_deploy_uri/UI/Login?module=module-instance-name Authentication “Named Configuration” or “Chaining” Name SpaceA separate name space is created under an Organization/Realm, which is a chain of authentication module instances. The same chain can be reused and assigned to an Organization/Realm, Role, or User. The Authentication Service instance equals the Authentication Chain. Invocation is: server_deploy_uri/UI/Login?service=authentication-chain-name Policy Module EnhancementsPersonalization Attributes In addition to Rules, Subjects, and Conditions, policies can now have personalization attributes (IDResponseProvider). The policy decision sent to the client from the policy evaluation now includes policy-based response personalization attributes in the applicable policies. Two types of personalization attributes are supported:
Policy Enforcement Points (agents) typically forward these attribute values as HTTP Header or Cookies or Request Attributes to the protected application. Access Manager 7 2005Q4 does not support custom implementations of the Response Provider interface by customers. Session Property Condition The session policy condition implementation (SessionPropertyCondition) decides whether a policy is applicable to the request based on values of properties set in a user's Access Manager session. At policy evaluation time, the condition returns “true” only if the user's Access Manager session has every property value defined in the condition. For properties defined with multiple values in the condition, it is sufficient if the user session has at least one value listed for the property in the condition. Policy Subject The policy subject implementation (Access Manager Identity Subject) allows you to use entries from the configured Identity Repository as policy subject values. Policy Export You can export policies in XML format using the amadmin command. The new GetPolices and RealmGetPolicies elements in the amAdmin.dtd file support this feature. Policy Status A policy now has a status attribute, which can be set to active or inactive. Inactive policies are ignored during policy evaluation. Site ConfigurationAccess Manager 7 2005Q4 introduces the “site concept,” which provides centralized configuration management for an Access Manager deployment. When Access Manager is configured as a site, client requests always go through the load balancer, which simplifies the deployment as well as resolves issues such as a firewall between the client and the back-end Access Manager servers. For more information, see Configuring an Access Manager Deployment as a Site in Sun Java System Access Manager 7 2005Q4 Deployment Planning Guide. Bulk FederationAccess Manager 7 2005Q4 provides bulk federation of user accounts to applications that are outsourced to business partners. Previously, federating accounts between a Service Provider (SP) and an Identity Provider (IDP) required each user to access both the SP and IDP sites, create accounts if not already there, and federate the two accounts through a web link. This process was time consuming. It was not always suitable for a deployment with existing accounts or for a site that acted as an identity provider itself or use one of its partners as an authenticating provider. For more information, see the Sun Java System Access Manager 7 2005Q4 Federation and SAML Administration Guide. Logging EnhancementsAccess Manager 7 2005Q4 includes several new logging enhancements:
Caution – Database tables tend to be larger than flat file logs. Therefore, in a given request, do not retrieve all of the records in a database table, because the quantity of data can consume all of the Access Manager server resources. Hardware and Software RequirementsThe following table shows the hardware and software that are required for this release. Table 4 Hardware and Software Requirements
If you have questions about support for other versions of these components, contact your Sun Microsystems technical representative. Supported BrowsersThe following table shows the browsers that are supported by the Sun Java Enterprise System 2005Q4 release. Table 5 Supported Browsers
System Virtualization SupportSystem virtualization is a technology that enables multiple operating system (OS) instances to execute independently on shared hardware. Functionally, software deployed to an OS hosted in a virtualized environment is generally unaware that the underlying platform has been virtualized. Sun performs testing of its Sun Java System products on select system virtualization and OS combinations to help validate that the Sun Java System products continue to function on properly sized and configured virtualized environments as they do on non-virtualized systems. For information about Sun support for Sun Java System products in virtualized environments, see http://docs.sun.com/doc/820-4651. Compatibility IssuesAccess Manager Legacy ModeIf you are installing Access Manager with any of the following products, you must select the Access Manager Legacy (6.x) mode:
You select the Access Manager Legacy (6.x) mode, depending on how you are running the Java ES installer: To determine the more for an Access Manager 7 2005Q4 installation, see Determining the Access Manager Mode. Java ES Silent Installation Using a State FileJava ES installer silent installation is a non-interactive mode that allows you to install Java ES components on multiple host servers that have similar configurations. You first run the installer to generate a state file (without actually installing any components) and then edit a copy of the state file for each host server where you plan to install Access Manager and other components. To select Access Manager in Legacy (6.x) mode, set the following parameter (along with other parameters) in the state file before you run the installer in silent mode: ... AM_REALM = disabled ... For more information about running the Java ES installer in silent mode using a state file, see the Chapter 5, Installing in Silent Mode, in Sun Java Enterprise System 2005Q4 Installation Guide for UNIX. “Configure Now” Installation Option in Graphical ModeIf you are running the Java ES Installer in graphical mode with the “Configure Now” option, on the “Access Manager: Administration (1 of 6)” panel, select “Legacy (version 6.x style)”, which is the default value. “Configure Now” Installation Option in Text-Based ModeIf you are running the Java ES Installer in text-based mode with the “Configure Now” option, for Install type (Realm/Legacy) [Legacy] select Legacy, which is the default value. “Configure Later” Installation OptionIf you ran the Java ES Installer with the “Configure Later“ option, you must run the amconfig script to configure Access Manager after installation. To select Legacy (6.x) mode, set the following parameter in your configuration script input file (amsamplesilent): ... AM_REALM=disabled ... On Windows systems, the configuration file is AccessManager-base\setup\AMConfigurator.properties. For more information about configuring Access Manager by running the amconfig script, refer to the Sun Java System Access Manager 7 2005Q4 Administration Guide. Determining the Access Manager ModeTo determine whether a running Access Manager 7 2005Q4 installation has been configured in Realm or Legacy mode, invoke: http(s)://host:port/amserver/SMSServlet?method=isRealmEnabled Results are:
Access Manager Policy AgentsThe following table shows the compatibility of Policy Agents with the Access Manager 7 2005Q4 modes. Table 6 Policy Agents Compatibility With Access Manager 7 2005Q4 Modes
Installation NotesAccess Manager installation notes include the following information: Known Issues and LimitationsThis section describes the following known issues and workarounds, if available, at the time of the release. Compatibility Issues
Incompatibility between Java ES 2004Q2 servers and IM on Java ES 2005Q4 (6309082)The following deployment scenario caused this problem:
When running the imconfig utility to configure Instant Messaging on server-4, the configuration was not successful. The Access Manager 7 2005Q4 SDK, which is used by Instant Messaging (IM) on server-4, is not compatible with the Java ES 2004Q2 release. Workaround: Ideally, the Access Manager server and Access Manager SDK should be the same release. For more information, see the Sun Java Enterprise System 2005Q4 Upgrade Guide. Incompatibilities exist in core authentication module for legacy mode (6305840)Access Manager 7 2005Q4 legacy mode has the following incompatibilities in the core authentication module from Access Manager 6 2005Q1:
Workaround: None. Agent cannot login because “Profile not in the organization” (6295074)In the Access Manager Console, create an agent in Realm Mode. If you log out and then login again using the agent name, Access Manager returns an error because the agent does not have the privileges to access the realm. Workaround: Modify the permissions to allow read/write access for the agent. Delegated Administrator commadmin utility does not create a user (6294603)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 2005Q4 but you do not upgrade Delegated Administrator. For information about upgrading Delegated Administrator, see the Sun Java Enterprise System 2005Q4 Upgrade Guide. If you do not plan to upgrade Delegated Administrator, follow these steps:
Delegated Administrator commadmin utility does not create an organization (6292104)The Delegated Administrator commadmin utility with the -S mail,cal option does not create an organization. Workaround: See the workaround for the previous problem. Installation Issues
After applying patch 1, /tmp/amsilent file allows read access for all users (6370691)After you apply patch 1, the /tmp/amsilentfile allows read access for all users. Workaround: After you apply the patch, reset the permissions for the file to allow read access only by the Access Manager administrator. On SDK install with container configuration, notification URL is not correct (6327845)If you perform an SDK installation with the container configuration (DEPLOY_LEVEL=4), the notification URL is not correct. Workaround:
Access Manager classpath refers to expired JCE 1.2.1 package (6297949)The Access Manager classpath refers to Java Cryptography Extension (JCE) 1.2.1 Package (Signing Certificate), which expired on July 27, 2005. Workaround: None. Although the package reference is in the classpath Access Manager does not use this package. Installing Access Manager on an existing DIT requires rebuilding Directory Server indexes (6268096)To improve the search performance, Directory Server has several new indexes. Workaround: After you install Access Manager with an existing Directory Information Tree (DIT), rebuild the Directory Server indexes by running the db2index.pl script. For example: # ./db2index.pl -D "cn=Directory Manager" -w password -n userRoot The db2index.pl script is available in the DS-install-directory/slapd-hostname/ directory. Log and debug directories permissions incorrect for non-root users (6257161)When a non-root user is specified in the silent install configuration file, permissions on the debug, logs, and starts directories are not set appropriately. Workaround: Change the permissions on these directories to allow access for a non-root user. Authentication service is not initialized when Access Manager and Directory Server are installed on separate machines (6229897)Although the classpath and other Access Manager web container environment variables are updated during installation, the installation process does not restart the web container. If you try to login to Access Manager after installation before the web container is restarted, the following error is returned: Authentication Service is not initialized. Contact your system administrator. Workaround: Restart the web container before you login to Access Manager. Directory Server must also be running before you login. Installer doesn't add platform entry for existing directory install (6202902)The Java ES Installer does not add a platform entry for an existing directory server installation (DIRECTORY_MODE=2). Workaround: Add the Realm/DNS aliases and platform server list entries manually. For the steps, see the Adding Additional Instances to the Platform Server List and Realm/DNS Aliases in Sun Java System Access Manager 7 2005Q4 Deployment Planning Guide. Upgrade Issues
Access Manager ampre70upgrade script does not remove localized packages (6378444)If you are upgrading Access Manager to Access Manager 7 2005Q4, the ampre70upgrade script does not remove any Access Manager localized packages that you have on your system. Workaround: Before you upgrade to Access Manager 7 2005Q4, use the pkgrm command to manually remove any localized Access Manager packages that are installed on your system. AMConfig.properties file has an old version for the web container (6316833)After Access Manager and Application Server are upgraded to Java ES 2005Q4 versions, the Access Manager AMConfig.properties file has an old version of Application Server. Workaround: Before you run the Delegated Administrator configuration program (config-commda), change the following property in the AMConfig.properties file: com.sun.identity.webcontainer=IAS8.1 Node agent server.policy file isn't updated as part of an Access Manager upgrade (6313416)After upgrading Access Manager, the node agent server.policy file isn't updated. Workaround: Replace the server.policy file for the node agent with the following file: /var/opt/SUNWappserver/domains/domain1/config/server.policy After upgrade, Session Property Condition is missing in the Condition list (6309785)After upgrading Access Manager from version 2005Q1 to version 2005Q4, the Session Property Condition is not displayed as a choice in the policy Condition list if you try to add a Condition to a policy. Workaround: Select the Session Property Condition type in the policy configuration service template at the corresponding realm. After upgrade, Identity Subject type is missing from the policy subject list (6304617)After upgrading Access Manager from version 2005Q1 to version 2005Q4, the Identity Subject, a newly added policy subject type, is not displayed as a choice in the policy subject list. Workaround: Select the Identity Subject type as a default subject type in the policy configuration service template. Access Manager upgrade failed because the classpath is not migrated (6284595)During the upgrade of Access Manager from Java ES 2004Q2 to Java ES 2005Q4, the upgrade from Java ES 2004Q2 to Java ES 2005Q1 failed. Access Manager was being deployed on Application Server, which was also being upgraded from Java ES 2004Q2 to Java ES 2005Q4. The classpath in the domain.xml file did not have Access Manager JAR file paths. Workaround: Follow these steps:
After upgrade, amadmin command returns wrong version shown (6283758)After Access Manager was upgraded from version 6 2005Q1 to version 7 2005Q4, the amadmin --version command returned the wrong version: Sun Java System Access Manager version 2005Q1. Workaround: After you upgrade Access Manager, run the amconfig script to configure Access Manager. When you run amconfig, specify the full path to the configuration (amsamplesilent) file. For example, on a Solaris system: # ./amconfig -s ./config-file or # ./amconfig -s /opt/SUNWam/bin/config-file Add ContainerDefaultTemplateRole attribute after data migration (4677779)The 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. Configuration Issues
Application Server 8.1 server.policy file must be edited when using non-default URIs (6309759)If you are deploying Access Manager 7 2005Q4 on Application Server 8.1 and you are using non-default URIs for the services, console, and password web applications, which have default URI values of amserver, amconsole, and ampassword, respectively, you must edit the application server domain's server.policy file before attempting to access Access Manager via a web browser. Workaround: Edit the server.policy file as follows:
Platform server list and FQDN alias attribute are not updated (6309259, 6308649)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 Adding Additional Instances to the Platform Server List and Realm/DNS Aliases in Sun Java System Access Manager 7 2005Q4 Deployment Planning Guide. Data validation for required attributes in the services (6308653)Access Manager 7 2005Q4 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. Document workaround for deployment on a secure WebLogic 8.1 instance (6295863)If you deploy Access Manager 7 2005Q4 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:
The amconfig script does not update the realm/DNS aliases and platform server list entries (6284161)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 Adding Additional Instances to the Platform Server List and Realm/DNS Aliases in Sun Java System Access Manager 7 2005Q4 Deployment Planning Guide. Default Access Manager mode is realm in the configuration state file template (6280844)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 URL signing failed in IBM WebSphere when using RSA key (6271087)When using an RSA key in IBM WebSphere, the signing of URL string failed with the following exception: ERROR: FSSignatureUtil.signAndReturnQueryString: FSSignatureException occured while signing query string: no such provider: SunRsaSign Workaround:The “SunRsaSign” provider is missing from the WebSphere bundled JDK. To fix this problem, edit the websphere_jdk_root/jre/lib/security/java.security file and add following line to enable “SunRsaSign” as one of the providers: security.provider.6=com.sun.rsajca.Provider Access Manager Console Issues
For SAML, duplicate Trusted Partner console edit errors (6326634)In the Access Manager Console, create SAML Trusted Partner under the Federation > SAML tab. If you try to duplicate the Trusted Partner, errors occur. Workaround: None. This problem is fixed in patch 1. See Access Manager 7 2005Q4 Patch 1 for information about applying the patch for your specific platform. Remote logging is not working for amConsole.access and amPasswordReset.access (6311786)When remote logging is configured, all logs are written to the remote Access Manager instance except amConsole.accessand amPasswordReset.access for the password reset information. The log record is not written anywhere. Workaround: None. Adding more amadmin properties in the console is changing the amadmin user password (6309830)Adding or editing some of the properties for the amadmin user in the administration console causes the amadmin user password to change. Workaround: None. This problem is fixed in patch 1. See Access Manager 7 2005Q4 Patch 1 for information about applying the patch for your specific platform. New Access Manager Console cannot set the CoS template priorities (6309262)The new Access Manager 7 2005Q4 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. Exception error occurs when adding a group to a user as a policy admin user (6299543)The Access Manager Console returns an exception error when you add a group to a user as a policy admin user. Workaround: None. In legacy mode, you cannot delete all users from a role (6293758)In legacy mode, if you try to delete all users from a role, a user is left. Workaround: Try again to delete the user from the role. Cannot add, delete, or modify Discovery Service resource offerings (6273148)The Access Manager Administration Console does not allow you to add, delete, or modify the resource offerings for a user, role, or realm. Workaround: None. This problem is fixed in patch 1. See Access Manager 7 2005Q4 Patch 1 for information about applying the patch for your specific platform. Wrong LDAP bind password should give error for the subject search (6241241)The Access Manager Administration Console is not returning an error when the wrong LDAP bind password is used. Workaround: None. Access Manager cannot create an organization under a container in legacy mode (6290720)If you create a container and then try to create an organization under the container, Access Manager returns a “uniqueness violation error”. Workaround: None. Old console appears when adding Portal Server related services (6293299)Portal Server and Access Manager are installed on the same serve. 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. Console does not return the results set from Directory Server after reaching the resource limit (6239724)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. SDK and Client Issues
Can't remove Session Service configuration for a subrealm (6318296)After creating a subrealm of the top-level realm and adding the Session Service to it, a subsequent attempt to remove the Session Service configuration caused an error message. Workaround: Remove the default top-level ID repository, AMSDK1, and then add this repository back into the configuration. This problem is fixed in patch 1. See Access Manager 7 2005Q4 Patch 1 for information about applying the patch for your specific platform. CDC servlet redirecting to the invalid login page when policy condition is specified (6311985)With the Apache agent 2.2 in CDSSO mode, when accessing the agent protected resource, the CDC servlet redirects the user to the anonymous authentication page, instead of the default login page. Workaround: None. This problem is fixed in patch 1. See Access Manager 7 2005Q4 Patch 1 for information about applying the patch for your specific platform. Clients do not get notifications after the server restarts (6309161)Applications written using the client SDK (amclientsdk.jar) do not get notifications if the server restarts. Workaround: None. SDK clients need to restart after service schema change (6292616)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. See Access Manager 7 2005Q4 Patch 1 for information about applying the patch for your specific platform. Command-Line Utilities Issues
Null attribute LDAP search returns an error when Access Manager points to Directory Proxy (6357975)If you are using Sun Java System Directory Proxy Server, a null attribute LDAP search returns an error. For example: # ldapsearch -b base-dn uid=user "" If Access Manager points directly to the LDAP director server, the same search is successful. Workaround: If you are using Directory Proxy Server, either enable null attribute searches or supply an attribute name for the search. New schema files are missing from amserveradmin script (6255110)After installation, when you need to run amserveradmin script to load the services into Directory Server, the script is missing the defaultDelegationPolicies.xml and idRepoDefaults.xml schema files. Workaround: Manually load the defaultDelegationPolicies.xml and idRepoDefaults.xml files using the amadmin CLI tool with the -toption. Cannot save XML documents with escape character in Internet Explorer 6.0 (4995100)If you add a special character (such as the string “amp;” next to an “&”) in an XML file, the file will save properly, however; if you later retrieve the XML profile using Internet Explorer 6.0, the file doesn't display properly. If you then try to save the profile again, an error is returned. Workaround: None. Authentication Issues
UrlAccessAgent SSO Token is expiring (6327691)The UrlAccessAgent SSO Token is expiring because the application module does not return the special user DN, which causes the special user DN match and hence a non-expiring token to fail. Workaround: None. This problem is fixed in patch 1. See Access Manager 7 2005Q4 Patch 1 for information about applying the patch for your specific platform. Unable to login to subrealm with LDAPV3 plugin/dynamic profile after correcting password (6309097)In realm mode, if you create an ldapv3 datastore in a realm with a “wrong” password and you later change the password as amadmin, when you try to login again as the user with the changed password, the logon fails, saying that no profile exists. Workaround: None. Incompatibility for Access Manager default configuration of Statistics Service for legacy (compatible) mode (6286628)After installation with Access Manager in legacy mode, the default configuration for the Statistics Service has changed:
Workaround: None. Attribute uniqueness broken in the top-level organization for naming attributes (6204537)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. Session and SSO Issues
Access Manager instances across time zones timeout other user sessions (6323639)Access Manager instances installed across different time zones and in the same circle of trust cause user sessions to timeout. Session failover (amsfoconfig) script has incorrect permissions on Linux 2.1 system (6298433)The session failover configuration script (/opt/sun/identity/bin/amsfoconfig) has incorrect permissions and is not executable on Linux 2.1 system. Workaround: Change the permissions to make the amsfoconfig script executable (for example, 755). This problem is fixed in patch 1. See Access Manager 7 2005Q4 Patch 1 for information about applying the patch for your specific platform. Session failover (amsfoconfig) script fails on Linux 2.1 system (6298462)The session failover configuration script (amsfoconfig) fails on Linux 2.1 server because the tab character (\t) is not being interpreted correctly. Workaround: Configure session failover manually. For the steps, see Configuring Session Failover Manually in Sun Java System Access Manager 7 2005Q4 Deployment Planning Guide. This problem is fixed in patch 1. See Access Manager 7 2005Q4 Patch 1 for information about applying the patch for your specific platform. System creates invalid service host name when load balancer has SSL termination (6245660)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"/> Using HttpSession with third-party web containers (No CR number)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. Policy IssuesDeletion of dynamic attributes in Policy Configuration Service causing issues in editing of policies (6299074)The deletion of dynamic attributes in Policy Configuration Service causes issues in editing of policies for this scenario:
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. Server Startup IssuesDebug error occurs on Access Manager startup (6309274, 6308646)Access Manager 7 2005Q4 startup returns the debug errors in amDelegation and amProfile debug files:
Workaround: None. You can ignore these messages. Using BEA WebLogic Server as a web containerIf you deploy Access Manager using BEA WebLogic Server as the web container, Access Manager might not be accessible. Workaround: Restart WebLogic Server a second time for Access Manager to be accessible. Linux OS IssuesJVM problems occur when running Access Manager on Application Server (6223676)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: 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; Federation and SAML Issues
Running the web services sample returns “Resource offering not found” (6359900)When Access Manager is configured to access the web services samples under the AccessManager-base/SUNWam/samples/phase2/wsc directory on Solaris systems or the AccessManager-base/identity/samples/phase2/wsc directory on Linux systems, querying the Discovery Service or modifying the Resource Offering returns the error message: “Resource offering not found”. AccessManager-base is the base installation directory. The default base installation directory is /opt on Solaris systems and /opt/sun on Linux systems. Workaround:
Federation fails when using Artifact profile (6324056)If you setup an identity provider (IDP) and a service provider (SP), change the communication protocol to use the browser Artifact profile, and then try to federate users between the IDP and SP, the federation fails. Workaround: None. Special characters (&) in SAML statements should be encoded (6321128)With Access Manager as the source site and destination site and SSO configured, an error occurs in the destination site, because the special character (&) in the SAML statements is not encoded and hence the parsing of assertion fails. Workaround: None. This problem is fixed in patch 1. See Access Manager 7 2005Q4 Patch 1 for information about applying the patch for your specific platform. Exception occurs when trying to add Disco Service to a role (6313437)In the Access Manager Console, if you try to add a resource offering to the Disco Service, an unknown exception occurs. Workaround: None. Auth Context attributes are not configurable until you have configured and saved other attributes (6301338)Auth Context attributes are not configurable until you have configured and saved other attributes. Workaround: Configure and save a provider profile before you configure the Auth Context attributes. EP Sample does not work if root suffix contains “&” character (6300163)If Directory Server has a root suffix that contain the “&” character and you try to add an Employee Profile Service Resource Offering, an exception is thrown. Workaround: None. Logout error occurs in Federation (6291744)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. Globalization (g11n) Issues
User locale preferences are not applied to the whole administration console (6326734)Parts of the Access Manager administration console are not following the user locale preferences but instead using the browser locale settings. This problem affects the Version, Logout and online help buttons as well as the contents of the Version and online help. Workaround: Change the browser settings to the same locale as user preferences. Online help is not fully available for European languages if Access Manager is deployed on IBM WebSphere (6325024)In all European locales (Spanish, German, and French), the online help is not fully accessible when Access Manager is deployed on an IBM WebSphere Application Server instance. The online help displays “Application Error” for these frames:
Workaround: Set your browser language setting to English and refresh the page to access the left frame. The upper frame, however, will still display “Application Error.” Version information is blank when Access Manager is deployed on IBM WebSphere (6319796)In any locale, when Access Manager is deployed on an IBM WebSphere Application Server instance, the product version is not visible when you click the Version button. A blank page is displayed instead. Workaround: None. Removing UTF-8 is not working in Client Detection (5028779)The Client Detection function is not working properly. Changes made in the Access Manager 7 2005Q4 Console are not automatically propagated to the browser. Workaround:There are two workarounds:
Multibyte characters are displayed as question marks in log files (5014120)Multibyte 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. Documentation Issues
Document that Access Manager cannot revert from Realm Mode to Legacy Mode (6508473)If you install Access Manager 7 2005Q4 in Realm Mode, you cannot revert to Legacy Mode. If you install Access Manager 7 2005Q4 in Legacy Mode, however, you can change to Realm Mode by using the amadmin command with the -M option. For example: amadmin -u cn=amAdmin,ou=People,dc=example,dc=com -w amadmin-password -M dc=example,dc=com Document more information about disabling persistent searches (6486927)Access Manager uses persistent searches to receive information about Sun Java System Directory Server entries that change. By default, Access Manager creates the following persistent search connections during server startup: aci - Changes to the aci attribute, with the search using the LDAP filter (aci=*) sm - Changes in the Access Manager information tree (or service management node), which includes objects with the sunService or sunServiceComponent marker object class. For example, you might create a policy to define access privileges for a protected resource, or you might modify the rules, subjects, conditions, or response providers for an existing policy. um - Changes in the user directory (or user management node). For example, you might change a user's name or address. Caution – Disabling persistent searches for any of these components is not recommended, because a component with a disabled persistent search does not receive notifications from Directory Server. Consequently, changes made in Directory Server for that particular component will not be notified to the component cache, and the component cache will go stale. For example, if you disable persistent searches for changes in the user directory (um), the Access Manager server will not receive notifications from Directory Server. Therefore, an agent would not get notifications from Access Manager to update its local user cache with the new values for the user attribute. Then, if an application queries the agent for the user attributes, it might receive the old value for that attribute. Use this property only in special circumstances when absolutely required. For example, if you know that Service Configuration changes (related to changing values to any of services such as Session Service and Authentication Services) will not happen in production environment, the persistent search to the Service Management (sm) component can be disabled. However, if any changes occur for any of the services, a server restart would be required. The same condition also applies to other persistent searches, specified by the aci and um values. For more information, see CR# 6363157: New property disables persistent searches if absolutely required. Document Access Manager supported and unsupported privileges (2143066)Privileges define the access permissions to administrators who are members of roles or groups that exist within a realm. Access Manager allows you to configure permissions for the following administrator types:
The following privileges are supported:
Document cookie-based sticky request routing (6476922)When Access Manager servers are deployed behind a load balancer, cookie-based sticky request routing prevents a client request from being misrouted to an incorrect Access Manager server (that is, to a server that is not hosting the session). This feature was implemented in Access Manager 7 2005Q4 patch 3. In the previous behavior, without cookie-based sticky request routing, requests from non-browser based clients (such as policy agents and clients using the remote Access Manager client SDK) were often misrouted to an Access Manager server that was not hosting the session. Then, in order to send the request to the correct server, the Access Manager server had to validate the session using back-channel communication, which usually caused some performance degradation. Cookie-based sticky request routing prevents the need for this back-channel communication and thus improves Access Manager performance. To implement cookie-based sticky request routing, the Access Manager deployment must be configured as a site. For information, see Configuring an Access Manager Deployment as a Site in Sun Java System Access Manager 7 2005Q4 Deployment Planning Guide. To configure cookie-based sticky request routing:
Document Windows Desktop SSO configuration for Windows 2003 (6487361)To configure Windows Desktop SSO on Windows 2003, as described in the Configuring Windows Desktop SSO in Sun Java System Access Manager 7 2005Q4 Administration Guide, use the following ktpass command: ktpass /out filename /mapuser username /princ HTTP/hostname.domainname /crypto encryptiontype /rndpass /ptype principaltype /target domainname For example: ktpass /out demo.HTTP.keytab /mapuser http /princ HTTP/demo.identity.sun.com@IDENTITY.SUN.COM /crypto RC4-HMAC-NT /rndpass /ptype KRB5_NT_PRINCIPAL /target IDENTITY.SUN.COM For the syntax definitions, see the following site: Document steps to set up Distributed Authentication UI server passwords (6510859)The following procedure describes how to set up the encrypted passwords for a Distributed Authentication UI server that communicates with an Access Manager server. To set up the passwords for a Distributed Authentication UI server:
Online Help for “To create a new site name” needs more information (2144543)The Access Manager Console online Help is missing the Save step for “To create new site name” under Configuration>System Properties>Platform. If you don't click Save after adding a new site name and you then try to add an instance name, the process fails. Therefore, always click Save after adding the site name, and then add the instance name. Document that administrator password configuration parameter is ADMIN_PASSWD on Windows systems (6470793)On Solaris and Linux systems, the Access Manager administrator (amadmin) password configuration parameter in the amsamplesilent file is ADMINPASSWD. On Windows systems, however, the parameter in the AMConfigurator.properties file is ADMIN_PASSWD. If you are running amconfig.bat on Windows systems, set the amadmin password in the AMConfigurator.properties file using the ADMIN_PASSWORD parameter and not ADMINPASSWD. Release Notes have wrong workaround for known issue (6422907)Step 3 of the workaround for Running the web services sample returns “Resource offering not found” (6359900) has been corrected. Document com.iplanet.am.session.protectedPropertiesList in AMConfig.properties (6351192)The com.iplanet.am.session.protectedPropertiesList parameter allows you to protect certain core or internal session properties from remote updates via the SetProperty method of the Session Service. By setting this “hidden” key security parameter, you can customize session attributes in order to participate in authorization as well as other Access Manager features. To use this parameter:
Document the roles and filtered roles support for LDAPv3 plug-in (6365196)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 CR 6349959). In the Access Manager 7 2005Q4 Administrator Console, in LDAPv3 configuration for the “LDAPv3 Plugin 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. Document unused properties in the AMConfig.properties file (6344530)The following properties in the AMConfig.properties file are not used: com.iplanet.am.directory.host com.iplanet.am.directory.port com.iplanet.am.session.client.polling.enable on server side must not be true (6320475)The com.iplanet.am.session.client.polling.enable property in the AMConfig.properties file must never be set to true on the server side. Workaround: This property is set to false by default and should never be reset to true. Default Success URL is incorrect in the console online help (6296751)The Default Success URL is incorrect in the service.scserviceprofile.iplanetamauthservice.html online help file. The Default Success URL field accepts a list of multiple values that specify the URL where users are redirected after successful authentication. The format of this attribute is clientType|URL, although you can specify only the value of the URL, which assumes a default type of HTML. The “/amconsole” default value is incorrect. Workaround: The correct default value is “/amserver/console”. Document how to enable XML encryption (6275563)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:
For more information, refer to problem ID 5110285 (XML encryption requires Bouncy Castle JAR file). Documentation UpdatesSun Java System Access Manager 7 2005Q4 CollectionThe following table lists the new and revised Access Manager 7 2005Q4 documents that have been published since the initial release. To access these documents, see the Access Manager 7 2005Q4 collection: http://docs.sun.com/coll/1292.1 Table 7 Access Manager 7 2005Q4 Documentation Update History
Sun Java System Federation Manager 7.0 2005Q4 CollectionTo access the documents in the Federation Manager 7.0 2005Q4 collection, see: http://docs.sun.com/coll/1321.1 Sun Java System Access Manager Policy Agent 2.2 CollectionThe Access Manager Policy Agent 2.2 collection is revised on an ongoing basis to document new agents. To access the documents in this collection, see: http://docs.sun.com/coll/1322.1 Redistributable FilesSun Java System Access Manager 7 2005Q4 does not contain any files that you can redistribute to non-licensed users of the product. How to Report Problems and Provide FeedbackIf you have problems with Access Manager or Sun Java Enterprise System, contact Sun customer support using one of the following mechanisms:
So that we can best assist you in resolving problems, please have the following information available when you contact support:
Sun Welcomes Your CommentsSun is interested in improving its documentation and welcomes your comments and suggestions. Go to http://docs.sun.com/ and click Send Comments. Provide the full document title and part number in the appropriate fields. The part number is a seven-digit or nine-digit number that can be found on the title page of the book or at the top of the document. For example, the part number of the Access Manager Release Notes is 819-2134-25. Additional Sun ResourcesYou can find useful Access Manager information and resources at the following locations:
Accessibility Features for People With DisabilitiesTo obtain accessibility features that have been released since the publishing of this media, consult Section 508 product assessments available from Sun upon request to determine which versions are best suited for deploying accessible solutions. Updated versions of applications can be found at http://sun.com/software/javaenterprisesystem/get.html. For information on Sun's commitment to accessibility, visit http://sun.com/access. Related Third-Party Web SitesThird-party URLs are referenced in this document and provide additional, related information. Note – Sun is not responsible for the availability of third-party Web sites mentioned in this document. Sun does not endorse and is not responsible or liable for any content, advertising, products, or other materials that are available on or through such sites or resources. Sun will not be responsible or liable for any actual or alleged damage or loss caused by or in connection with the use of or reliance on any such content, goods, or services that are available on or through such sites or resources. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||