test

Sun Java System Access Manager 7 2005Q4 发行说明

Access Manager 7 2005Q4 修补程序发行版

可从 SunSolve Online 找到可供下载的 Access Manager 7 2005Q4 修补程序的最新版本，网址为：http://sunsolve.sun.com。最新的修补程序 ID 是：

注 –

Access Manager 7 2005Q4 修补程序是累积的。您可在未安装修补程序 1、2、3、4、5 或 6 的情况下安装修补程序 7。不过，如果您没有安装早期的修补程序，请查阅关于早期修补程序章节中的新功能和问题，以确定是否有适用于您的部署的功能和问题。

有关 Access Manager 7 2005Q4 修补程序的信息包括：

Access Manager 7 2005Q4 修补程序 7

Access Manager 7 修补程序 7（修订版 07）可修复一系列的问题，其随附的自述文件中列出了具体内容。

修补程序 7 包含以下更改：

CR# 6637806：Access Manager 在重新启动后发送无效的应用程序 SSO 令牌给代理

Access Manager 服务器重新启动后，Access Manager 客户机 SDK 现在会发送有意义的异常给代理，所以代理可重新验证其自身以得到新的应用程序会话。此前，在应用 Access Manager 7 2005Q4 修补程序 5 后，Access Manager 客户机 SDK 会在 Access Manager 服务器重新启动后发送无效的应用程序 SSO 令牌到代理。

该问题已通过重复的 CR 6496155 修复。修补程序 7 也提供了（comp.iplanet.dpro.session.dnRestrictionOnly 属性）选项以在限制性环境中发送应用程序 SSO 令牌。默认情况下，代理会发送安装代理的服务器的 IP 地址，但是如果要求严格的 DN 检查，则按以下方法在 AMConfig.properties 文件中设置此属性：

com.iplanet.dpro.session.dnRestrictionOnly=true

CR# 6612609：如果网络电缆与 Message Queue 服务器的连接断开，则会话故障转移便会发挥作用。

在会话故障转移部署中，如果每个 Access Manager 实例和 Message Queue 代理安装在相同服务器上，则会话故障转移会在网络电缆与服务器之一的连接断开时发挥作用。默认情况下，Message Queue imqAddressListBehavior 连接的出厂属性设置为 PRIORITY，这会使 Message Queue 按照地址在代理地址列表中出现的顺序来尝试地址（例如：localhost:7777,server2:7777,server3:7777）。如果将属性设置为 RANDOM，则 Message Queue 会以随机顺序尝试地址。

要将此属性设置为 RANDOM，请在 amsessiondb 脚本中设置以下参数：

-DimqAddressListBehavior=RANDOM

有关 Message Queue 的 PRIORITY 和 RANDOM 属性的信息，请参见《Sun Java System Message Queue 3.7 UR1 管理指南》中的“代理地址列表”。

CR# 6570409：负载平衡器后方的交互服务可作为身份提供者正常工作

如果部署中有两台服务器与负载平衡器相连并作为单一身份提供者运行，您必须在 AMConfig.properties 文件中设置以下属性：

com.sun.identity.liberty.interaction.lbWspRedirectHandler
com.sun.identity.liberty.interaction.trustedWspRedirectHandlers

com.sun.identity.liberty.interaction.interactionConfigClass 是目前唯一支持的类。因此，在默认情况下，与 Federation Liberty 捆绑的交互配置类用于访问交互配置参数。

CR# 6545176：在后期验证处理 SPI 插件中可动态设置重定向 URL

现在可在后期验证处理 SPI 插件中为登录成功、登录失败和注销动态设置重定向 URL。如果未执行后期处理插件，则不使用后期处理 SPI 中设置的重定向 URL，而像以前一样执行以其他方式设置的重定向 URL。

有关信息，请参见 com.iplanet.am.samples.authentication.spi.postprocess.ISAuthPostProcessSample.java 范例。

安装前注意事项

备份文件

重要 如果当前安装中有自定义的文件，则在安装修补程序之前备份这些文件。安装修补程序后，将备份文件和此修补程序安装的新文件进行比较，以标识出自定义部分。将自定义部分合并到新文件中，然后进行保存。有关如何处理自定义文件的详细信息，阅读以下的信息。

安装修补程序前，也请备份以下文件。

Solaris 系统

  • AccessManager-base/SUNWam/bin/amsfo

  • AccessManager-base/SUNWam/lib/amsfo.conf

  • /etc/opt/SUNWam/config/xml/template/ 目录中的文件：

    idRepoService.xml、amSOAPBinding.xml、amDisco.xml、amAuthCert.xml、amAuth.xml、amSession.xml

  • AccessManager-base/SUNWam/locale/ 目录中的文件：

    amConsole.properties、amIdRepoService.properties、amAuthUI.properties、amAuth.properties、amPolicy.properties、amPolicyConfig.properties、amSessionDB.properties、amSOAPBinding.properties、amAdminCLI.properties、amSDK.properties、amAuthLDAP.properties、amSession.properties、amAuthContext.properties、amSAML.properties、amAuthCert.properties

Linux 和 HP-UX 系统

  • AccessManager-base/identity/bin/amsfo

  • AccessManager-base/identity/lib/amsfo.conf

  • /etc/opt/sun/identity/config/xml/template/ 目录中的文件：

    idRepoService.xml、amSOAPBinding.xml、amDisco.xml、amAuthCert.xml、amAuth.xml、amSession.xml

  • AccessManager-base/identity/locale/ 目录中的文件：

    amConsole.properties、amIdRepoService.properties、amAuthUI.properties、amAuth.properties、amPolicy.properties、amPolicyConfig.properties、amSessionDB.properties、amSOAPBinding.properties、amAdminCLI.properties、amSDK.properties、amAuthLDAP.properties、amSession.properties、amAuthContext.properties、amSAML.properties、amAuthCert.properties

Windows 系统

  • AccessManager-base\identity\setup\AMConfigurator.properties

  • AccessManager-base\identity\bin\amsfo

  • AccessManager-base\identity\lib\amsfo.conf

  • AccessManager-base\identity\config\xml\template 目录中的文件：

    idRepoService.xml、amSOAPBinding.xml、amDisco.xml、amAuthCert.xml、amAuth.xml、amSession.xml

  • AccessManager-base\identity\locale 目录中的文件：

    amConsole.properties、amIdRepoService.properties、amAuthUI.properties、amAuth.properties、amPolicy.properties、amPolicyConfig.properties、amSessionDB.properties、amSOAPBinding.properties、amAdminCLI.properties、amSDK.properties、amAuthLDAP.properties、amSession.properties、amAuthContext.properties、amSAML.properties、amAuthCert.properties

AccessManager-base 是基安装目录。默认的基安装目录取决于平台：

  • Solaris 系统：/opt

  • Linux 和 HP-UX 系统：/opt/sun

  • Windows 系统：javaes-install-directory\AccessManager。例如：C:\Program Files\Sun\AccessManager

安装和配置 Access Manager

本文档中描述的 Access Manager 修补程序不会安装 Access Manager。安装修补程序前，服务器上必须安装有 Access Manager 7 2005Q4。有关安装的信息，参见《Sun Java Enterprise System 2005Q4 Installation Guide for UNIX》。

如果要在 Windows 系统上安装修补程序，参见《Sun Java Enterprise System 2005Q4 Installation Guide for Microsoft Windows》。

您还应当熟悉如何运行 amconfig 脚本来部署、重新部署和配置 Access Manager，如《Sun Java System Access Manager 7 2005Q4 管理指南》中的第 1  章 “Access Manager 7 2005Q4 配置脚本”中所述。

有关因此修补程序的推出而过时的 Access Manager 修补程序列表，以及在安装此修补程序之前必须安装的所有修补程序，参阅本修补程序随附的自述文件。

注意 – 注意 –

Access Manager 修补程序（如同任何其他修补程序一样）在应用于生产环境之前，应当在分阶段系统或前期部署系统中进行测试。另外，修补程序的安装程序可能无法正确升级自定义 JSP 文件，所以可能需要在这些文件中进行手动更改，以使 Access Manager 正常运行。

修补程序安装说明

Solaris 系统的修补程序安装说明

在安装 Solaris 修补程序之前，请确保已备份安装前注意事项中列出的文件。

要在 Solaris 系统上添加或删除修补程序，使用此 OS 提供的 patchadd 和 patchrm 命令。

patchadd 命令

使用 patchadd 命令可在独立计算机系统中安装修补程序。例如：

# patchadd /var/spool/patch/120954-07
注 –

如果要在 Solaris 10 全局区域上安装 Solaris 修补程序，则调用 patchadd 命令，参数为 -G。例如：

patchadd -G /var/spool/patch/120954-07

除非是在只安装了 Access Manager SDK 组件的系统中，否则 postpatch 脚本会显示关于重新部署 Access Manager 应用程序的消息。

postpatch 脚本会在以下目录中创建 amsilent 文件：

AccessManager-base 是基安装目录。Solaris 系统的默认基安装目录是 /opt，而 Linux 系统则是 /opt/sun。

amsilent 基于 amsamplesilent 文件，但根据系统中的 Access Manager 配置文件设置了某些必需的参数。但是，密码参数包含默认值。根据部署需要，取消注释并修改每个密码参数的值，仔细检查此文件中的其他参数值。

COMMON_DEPLOY_URI 参数（通用域 Web 应用程序的 URI 前缀）也包含一个默认值。如果为该 URI 选择了非默认值，则确保更新该值。否则，使用 amconfig 和修补程序生成的 amsilent 文件重新部署 Web 应用程序将会失败。

然后，运行以下命令（以安装在默认目录下的 Access Manager 为例）：

# cd /opt/SUNWam/bin 
# ./amconfig -s /opt/SUNWam/amsilent
注意 – 注意 –

amsilent 文件包含纯文本格式的敏感数据（例如管理员密码），因此确保适当地保护此文件以进行部署。

运行 amconfig 脚本后，执行 updateschema.sh 脚本以加载 XML 和 LDIF 文件。安装修补程序 7 后，便可在以下目录中找到 updateschema.sh 脚本：

运行 updateschema 脚本后，重新启动 Access Manager 进程。例如：

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

然后，重新启动 Access Manager Web 容器。

patchrm 命令

使用 patchrm 命令可从独立计算机系统中删除修补程序。例如：

# patchrm 120954-03

除非是在只安装了 Access Manager SDK 组件的系统中，否则 backout 脚本会显示一条与 patchadd 命令所显示的消息类似的消息。

删除修补程序后，使用 AccessManager-base /SUNWam 目录中的 amsilent 文件重新部署 Access Manager 应用程序，其中，AccessManager-base 是基安装目录。Solaris 系统的默认基安装目录是 /opt。

根据部署需要，设置 amsilent 文件中的参数。

然后运行以下命令（以将 Access Manager 安装在 Solaris 系统上的默认目录中为例）：

# cd /opt/SUNWam/bin
# ./amconfig -s /opt/SUNWam/amsilent

有关 patchadd 和 patchrm 命令的其他信息和示例，参见对应的 Solaris 手册页。

有关详细信息，另请参见安装后注意事项。

Solaris 10 区域

Solaris 10 操作系统引进了“区域 (Zone)”的新概念。因而，patchadd 命令也包含了新的 -G 选项，该选项只将修补程序添加到全局区域。默认情况下，patchadd 命令在需要修补的软件包的 pkginfo 中查找 SUNW_PKG_ALLZONES 变量。但是，对所有 Access Manager 软件包来说，SUNW_PKG_ALLZONES 变量都未设置，并且如果 Access Manager 7 2005Q4 安装于全局区域，则 -G 选项是必需的。如果 Access Manager 7 2005Q4 安装于本地区域，则 patchadd -G 选项没有任何作用。

如果是在 Solaris 系统上安装 Access Manager 7 2005Q4 修补程序，建议使用 -G 选项。例如：

 # patchadd -G AM7_patch_dir

与此类似，如果 Access Manager 安装于全局区域，则运行 patchrm 命令时必须使用 -G 选项。例如：

# patchrm -G 120954-07

Linux 系统的修补程序安装说明

在安装 Linux 修补程序前，确保已备份安装前注意事项中列出的文件。

installpatch 可在独立的 Linux 系统中安装修补程序。例如：

# ./installpatch

postpatch 脚本输出的消息类似于 Solaris 系统中的消息。但是，Linux 系统中回退修补程序的过程与 Solaris 系统不同。没有回退 Linux 修补程序的通用脚本。如果之前安装了低版本的修补程序，可重新安装该版本，然后遵循修补程序安装后说明，通过运行 amconfig 脚本重新部署 Access Manager 应用程序。

运行 amconfig 脚本后，执行 updateschema.sh 脚本（修补程序 5 及更高版本）以加载 XML 和 LDIF 文件。安装修补程序 7 后，便可在 patch-home-directory/120956-07/scripts 目录中找到 updateschema.sh 脚本。

运行 amconfig 和 updateschema.sh 脚本后，重新启动 Access Manager Web 容器。

如果修补程序安装在 Access Manager 7 2005Q4 RTM 发行版上，而您想要删除修补程序并将系统恢复到 RTM 状态，则必须使用 reinstallRTM 脚本重新安装 Access Manager RTM 软件包。此脚本使用 Access Manager RTM RPM 存储位置的路径，并在已修补的 RPM 基础上覆盖安装 RTM RPM。例如：

# ./scripts/reinstallRTM path_of_AM7_RTM_RPM_directory

运行 reinstallRTM 脚本后，通过运行 amconfig 脚本来重新部署 Access Manager 应用程序并重新启动 Web 容器。

有关详细信息，另请参见安装后注意事项。

Windows 系统的修补程序安装说明

安装 Windows 修补程序的要求包括：

安装 Windows 修补程序

在安装 Windows 修补程序之前，确保已备份安装前注意事项中列出的文件。

输入指向修补程序脚本的基目录路径时，使用反斜线 (\)。例如：c:\sun

要安装 Windows 修补程序：

  1. 以管理员组成员的身份登录到 Windows 系统。

  2. 创建一个目录用于下载和解压缩 Windows 修补程序文件。例如：AM7p7

  3. 将 124296-07.zip 文件下载并解压缩到上一步所创建的目录中。

  4. 停止所有 Java ES 2005Q4 服务。

  5. 运行 AM7p7\scripts\prepatch.pl 脚本。

  6. 运行 AM7p7\124296-07.exe 以安装修补程序。

  7. 运行 AM7p7\scripts\postpatch.pl 脚本。

  8. 重新启动 Java ES 2005Q4 服务。

  9. 重新部署 Access Manager 应用程序。有关详细信息，请参见安装后注意事项。

  10. 运行 AM7p7\scripts\updateschema.pl 脚本以更新 Directory Server 服务模式。脚本会验证您的输入内容，然后加载文件。脚本还会写入以下日志文件：

    javaes-install-directory\AccessManager\AM70Patch-upgrade-schema- timestamp

  11. 重新启动 Java ES 2005Q4 服务。

回退 Windows 修补程序

要回退 Windows 修补程序：

  1. 以管理员组成员的身份登录到 Windows 系统。

  2. 运行 Uninstall_124296-07.bat 文件。

  3. 运行 AM7p7\scripts\postbackout.pl 脚本。

  4. 重新部署 Access Manager 应用程序。

  5. 重新启动 Java ES 2005Q4 服务。

注意：如果您回退修补程序，不会从 Directory Server 中删除由 AM7p7\scripts\updateschema.pl 脚本添加的模式更改。不过，您不需要手动删除这些模式更改，因为它们并不会在回退修补程序后影响 Access Manager 的功能性和可用性。

HP-UX 系统的修补程序安装说明

要安装或删除 HP-UX 修补程序，使用 swinstall 和 swremove 命令。例如，可使用以下命令在独立系统上安装修补程序：

# swinstall /var/spool/patch/126371-07

或者使用以下命令删除独立系统上的修补程序：

# swremove 126371-07

有关 swinstall 和 swremove 命令的信息，参阅 swinstall 和 swremove 手册页。

安装或删除修补程序后，您必须按照安装后注意事项一节中所述来重新部署 Access Manager 应用程序。

重新部署 Access Manager 应用程序后，执行 updateschema.sh 脚本（修补程序 5 及更高版本）以加载 XML 和 LDIF 文件。安装修补程序 7 后，便可在 patch-home-directory/120956-07/scripts 目录中找到 updateschema.sh 脚本。运行 amconfig 和 updateschema.sh 脚本后，重新启动 Access Manager Web 容器。

注意：如果删除修补程序，不会从 Directory Server 中删除由 updateschema.sh 脚本添加的模式更改。不过，您不需要手动删除这些模式更改，因为它们并不会在删除修补程序后影响 Access Manager 的功能性和可用性。

有关在 HP-UX 系统上部署 Access Manager 的详细信息，参见《Sun Java System Access Manager 7 2005Q4 Release Notes for HP-UX》。

安装后注意事项

安装 Access Manager 7 2005Q4 修补程序后，应注意的事项包括：

CR# 6254355：Access Manager 修补程序在 postpatch 脚本中不会部署 Access Manager 应用程序

修补程序的安装程序可能不会保留某些自定义 WAR 文件，而是用非自定义版本文件替换它们。为帮助标识 WAR 文件的自定义内容以及随后手动更新这些内容，请参考下列步骤 。

在以下示例中，AccessManager-base 是基安装目录。Solaris 系统的默认基安装目录是 /opt，而 Linux 系统则是 /opt/sun。

在 Windows 系统上，AccessManager-base 是 javaes-install-directory\AccessManager。例如： C:\Program Files\Sun\AccessManager

修补的 WAR 文件有：

这些文件位于 AccessManager-base/SUNWam（Solaris 系统）和 AccessManager-base/identity（Linux 系统）。

在 Windows 系统上：修补后的 WAR 文件位于 AccessManager-base\。

WAR 文件中可更改的内容包括：

要确保所有自定义更改都被保留，遵循以下这些步骤。在更改文件之前，总是首先备份。

  1. 安装修补程序。

  2. 将 WAR 文件解压缩到临时目录。例如，将 Access Manager 安装在 Solaris 系统上的默认目录中时：

    # cd temporary-directory 
# jar -xvf /opt/SUNWam/console.war
# jar -xvf /opt/SUNWam/services.war
# jar -xvf /opt/SUNWam/password.war

  3. 检查解压缩后的文件，查看修补程序的安装程序是否对自定义文件进行了任何更改，然后在临时目录中向更改过的文件手动添加原来的自定义更改。对于 AccessManager-base/web-src/ 目录下您所修改过的文件，若修补的 WAR 文件中不包含这些文件，则无需重新进行更改。

  4. 用修改后的文件更新 WAR 文件。例如，将 Access Manager 安装在 Solaris 系统上的默认目录中时：

    # cd temporary-directory
# jar -uvf /opt/SUNWam/console.war $path/$modified file
# jar -uvf /opt/SUNWam/services.war $path/$modified file
# jar -uvf /opt/SUNWam/password.war $path/$modified file

    例如，对步骤 2-4：

    # mkdir /tmp/war.tmp 
# cd /tmp/war.tmp
# jar -xvf /opt/SUNWam/services.war
# vi index.html
# jar -uvf /opt/SUNWam/services.war index.html

  5. 重新使用修补程序生成的无提示配置文件 (amsilent) 或者根据 amsamplesilent 模板文件创建一个新的无提示配置文件，然后在文件中设置适当的配置变量，包括：

    • DEPLOY_LEVEL=21

    • DIRECTORY_MODE=5

    • DS_DIRMGRPASSWD、ADMINPASSWD 和 AMLDAPUSERPASSWD 的密码

    • Access Manager Web 容器变量

    在 Windows 系统上，重新使用 postpatch.pl 脚本生成的无提示配置文件 (amsilent)，并确保 AccessManager-base\setup\AMConfigurator.properties-tmp 具有有效值。然后将此文件重命名为 AccessManager-base \setup\AMConfigurator.properties。

    有关 Web 容器变量的详细信息，参见 amsamplesilent 文件。在 Solaris 系统中，此文件位于 /opt/SUNWam/bin 目录下，在 Linux 系统中，此文件位于 /opt/sun/identity/bin 目录下。

    在 Windows 系统上，配置文件是 AccessManager-base\setup\AMConfigurator.properties。

  6. 按如下所示运行 amconfig 脚本。运行 amconfig 前，必须运行 Directory Server 和 Access Manager Web 容器。例如，要在 Access Manager 安装于默认基安装目录的 Solaris 系统上运行 amconfig：

    # cd /opt/SUNWam/bin 
# ./amconfig -s /opt/SUNWam/amsilent

  7. 运行 amconfig 脚本后，重新启动 Access Manager 进程。例如：

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

  8. 确保所有的自定义 JSP 文件位于 AccessManager-base/SUNWam/web-src/ 目录（Solaris 系统）或 AccessManager-base /identity/web-src/ 目录（Linux 系统）下的适当子目录中，并且已备份所有的自定义文件。

    在 Windows 系统上，文件位于 AccessManager-base\web-src\。

  9. 重新启动 Access Manager Web 容器。

有关运行 amconfig 脚本的详细信息，参见：《Sun Java System Access Manager 7 2005Q4 管理指南》中的第 1  章 “Access Manager 7 2005Q4 配置脚本”。

CR# 6436409：重新部署分布式验证和客户机 SDK WAR 文件

如果使用分布式验证或者客户机 SDK，则安装修补程序后，重新创建并重新部署分布式验证 WAR 文件和/或客户机 SDK WAR 文件。有关信息，参见以下文档：

Access Manager 7 2005Q4 修补程序 6

Access Manager 7 修补程序 6（修订版 06）可修复一系列问题，其随附的自述文件中列出了具体内容。修补程序 6 还包括以下新功能、问题和文档更新。

修补程序 6 的新增功能

修补程序 6 的已知问题和限制

注 –

在安装修补程序 6 之前，建议先升级或修补以下组件：

Access Manager 支持 JDK 1.5 HttpURLConnection setReadTimeout 方法

为支持 setReadTimeout 方法，AMConfig.properties 文件新增以下属性以便于您设置读取超时值：

com.sun.identity.url.readTimeout

如果 Web 容器使用 JDK 1.5，为避免打开过多 HttpURLConnection 而造成服务器挂起，请为此属性设置适当的值以使连接超时。默认值是 30000 毫秒（30 秒）。

如果 AMConfig.properties 文件中不存在 com.sun.identity.url.readTimeout 属性或该属性设置为空字符串，则 setReadTimeout 方法会被忽略。

主服务器恢复后，Access Manager SDK 会回退至主 Directory Server

如果 Sun Java System Directory Server 配置为多主复制 (multi-master replication, MMR)，Access Manager SDK 会在发生故障的主服务器恢复以后回退至主 Directory Server。之前，即使主服务器已恢复，Access Manager SDK 仍继续访问辅助 Directory Server。

为支持这一新行为，Access Manager 的 AMConfig.properties 文件中新增了以下属性：

com.sun.am.ldap.fallback.sleep.minutes

该属性设置了主服务器恢复后，辅助 Directory Server 实例在回退至主服务器之前休眠的时间（以分钟为单位）。默认值为 15 分钟。

com.sun.am.ldap.fallback.sleep.minutes 属性是隐藏的。要将此属性设置为默认值（15 分钟）以外的值，可将其显式地添加到 AMConfig.properties 文件。例如，将该值设置为 7 分钟：

com.sun.am.ldap.fallback.sleep.minutes=7

重新启动 Access Manager Web 容器才能使新值生效。

多个 Access Manager 实例会记录到单独的日志文件

通过设置 AMConfig.properties 文件中的以下新属性，运行于同一台主机服务器上的多个 Access Manager 实例可记录到不同日志记录子目录下的单独的日志文件中：

com.sun.identity.log.logSubdir

除非在“管理控制台”中更改默认日志记录目录，否则默认日志记录目录为：

第一个 Access Manager 实例始终会记录到默认日志记录目录中。要为其他 Access Manager 实例指定不同的日志记录子目录，可在 AMConfig.properties 文件中为其他每个 Access Manager 实例设置 com.sun.identity.log.logSubdir 属性。

例如，如果您有三个实例（am-instance-1、am-instance-2 和 am-instance-3），且全部运行于同一台 Solaris 主机服务器上，可按照以下所示设置属性：

com.sun.identity.log.logSubdir=am-instance-2
com.sun.identity.log.logSubdir=am-instance-3

com.sun.identity.log.logSubdir 属性是隐藏的。您必须根据需要将此属性显式地添加到 AMConfig.properties 文件中，并重新启动 Access Manager Web 容器使子目录值生效。

然后 Access Manager 实例会记录到以下目录：

/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 允许多个 cookie 域

为支持多个 cookie 域，Access Manager 新增了以下属性：

com.sun.identity.authentication.setCookieToAllDomains

默认值为 true。此新属性是隐藏的。要将此值设置为 false，可将该属性显式地添加到 AMConfig.properties 文件，并重新启动 Access Manager Web 容器。

Microsoft IIS 6.0 后期验证插件支持 SharePoint Server

Microsoft Internet 信息服务 (Internet Information Services, IIS) 6.0 验证插件现在支持 Microsoft Office SharePoint Server。用户可使用用户 ID 或登录名称登录 Access Manager。但是 SharePoint Server 只接受登录名称，导致用户在指定用户 ID 时会出错。

为了允许登录 SharePoint Server，后期验证插件 (ReplayPasswd.java) 现使用以下新属性：

com.sun.am.sharepoint_login_attr_name

该新属性指示 SharePoint Server 用于验证的用户属性。例如，以下属性指定用于验证的通用名称 (common name, cn)：

com.sun.am.sharepoint_login_attr_name=cn

后期验证插件读取 com.sun.am.sharepoint_login_attr_name 属性，并从 Directory Server 获取相应的用户属性值。然后该插件设置授权标头以允许用户访问 SharePoint Server。

此属性是隐藏的。要设置该属性，将其显式地添加到 AMConfig.properties 文件，然后重新启动 Access Manager Web 容器使该值生效。

Access Manager 支持 Internet Explorer 7

Access Manager 7 2005Q4 修补程序 6 现在可支持 Microsoft Windows Internet Explorer 7。

CR# 6379325 在会话故障转移时访问控制台会抛出空指针异常

在此情况下，多个 Access Manager 服务器部署为会话故障转移模式且位于负载平衡器后方，而负载平衡器配置为基于 cookie 的粘性请求路由选择。Access Manager 管理员通过负载平衡器访问 Access Manager 控制台。管理员登录到控制台时，会在其中一个 Access Manager 服务器上创建会话。如果该服务器关闭，控制台会话会按照预期故障转移到另一个 Access Manager 服务器。但是，有时管理员会在浏览器或 Web 容器错误日志中遇到间歇性空指针异常。

此问题只在故障转移时影响活动的 Access Manager 控制台会话，而不会影响 Access Manager 服务器的功能。

解决方法：阻止出现这些间歇性空指针异常的方法是：

CR# 6508103：在 Windows 上，单击“管理控制台”中的“帮助”会返回应用程序错误

在 Windows 2003 Enterprise Edition 上，如果在非英文语言环境中将 Access Manager 部署在 Sun Java System Application Server 上，单击“领域模式的管理控制台窗口”中的“帮助”会返回应用程序错误。

解决方法：

  1. 将 javaes-install-dir\share\lib\jhall.jar 文件复制到 %JAVA_HOME%\jre\lib\ext 目录。

    其中，javaes-install-dir 为 Windows 安装目录

  2. 重新启动 Application Server 实例。

CR# 6564877：Access Manager 7 修补程序安装覆写 SAML v2 文件

如果安装了 SAML v2 插件，修补程序安装会覆写与 SAML v2 相关的文件，postpatch 脚本会显示此消息：

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.

解决方法：安装修补程序并运行 amconfig 脚本后，为使用 SAML v2 插件的 Federation Manager 或 Access Manager 部署重新创建并重新部署 amserver.war 文件。

有关具体步骤，参见《Sun Java System SAML v2 Plug-in for Federation Services User’s Guide》中的第 2  章 “Installing the SAML v2 Plug-in for Federation Services”。

Access Manager 7 2005Q4 修补程序 5

Access Manager 7 修补程序 5（修订版 05）可修复一系列的问题，其随附的自述文件中列出了具体内容。修补程序 5 还包括以下新功能、问题和文档更新。

修补程序 5 的新增功能

修补程序 5 的已知问题和限制

全球化 (Globalization, g11n) 问题

文档更新

支持 HP-UX 系统

修补程序 126371 提供对 HP-UX 系统的支持。有关更多信息，请参见：

有关 HP-UX 系统上的安装的信息，参见《Sun Java Enterprise System 2005Q4 Installation Guide for UNIX》。

支持 Microsoft Windows 系统

修补程序 124296 提供对 Windows 系统的支持。有关更多信息，请参见：

有关 Windows 系统上的安装的信息，参见《Sun Java Enterprise System 2005Q4 Installation Guide for Microsoft Windows》。

提供新的 updateschema.sh 脚本来加载 LDIF 和 XML 文件

修补程序 5（及更高版本）包含 updateschema.sh 脚本，从而可加载下列文件以更新 Directory Server 服务模式：

在以前的 Access Manager 修补程序版本中，您需要手动加载这些文件。

要运行 updateschema.sh 脚本：

  1. 以超级用户 (root) 身份登录或成为超级用户。

  2. 转至修补程序目录。

  3. 运行该脚本。例如，在 Solaris 系统上：

    # cd /120954-07 
# ./updateschema.sh

    在 Windows 系统上，脚本为 updateschema.pl。

  4. 在脚本提示时，输入以下各项：

    • Directory Server 主机名和端口号

    • Directory Server 管理员用户 DN 和密码

    • amadmin DN 和密码

  5. 脚本会验证您的输入内容，然后加载文件。脚本还会写入以下日志文件：

    • Solaris 系统：/var/opt/SUNWam/logs/AM70Patch.upgrade.schema. timestamp

    • Linux 系统：/var/opt/sun/identity/logs/AM70Patch.upgrade.schema. timestamp

  6. 脚本结束后，重新启动 Access Manager Web 容器。

注意：如果您回退修补程序 5，那么不会从 Directory Server 中删除由 updateschema.sh 脚本添加的模式更改。不过，您不需要手动删除这些模式更改，因为它们并不会在回退修补程序后影响 Access Manager 的功能性和可用性。

支持特定的应用程序闲置会话超时值

修补程序 5 允许不同的应用程序拥有不同的会话闲置超时值。在企业中，某些应用程序可能需要比会话服务中指定的会话闲置超时更短的会话闲置超时值。例如，您在会话服务中将会话的闲置超时值指定为 30 分钟，但 HR 应用程序应在用户闲置超过 10 分钟后即超时。

使用此功能的要求如下：

要使用此功能：

例如，考虑具有如下“验证模式条件”的策略 http://host.sample.com/hr/*：

如果定义了多个策略来保护 HR 应用程序的资源，则您必须将该“条件”添加到所有策略。

当不同会话中的用户尝试访问 Access Manager 代理所保护的 HR 应用程序时，系统会提示该用户进行 LDAP 模式验证（如果用户尚未通过验证）。

如果用户已通过 LDAP 模式验证，则仅当距上次验证的时间小于 10 分钟或距用户上次访问 HR 应用程序的时间小于 10 分钟时，才允许用户执行访问。否则，系统会再次提示用户进行 LDAP 模式验证以访问应用程序。

可在分布式验证 UI 服务器上部署 CDC Servlet

CDC Servlet 可与分布式验证 UI 服务器在 DMZ 中共存以启用跨域单点登录 (Cross-Domain Single Sign-On, CDSSO)。可将 Access Manager 服务器部署在防火墙之后，所有访问 Access Manager 以实现 CDSSO 的操作均由分布式验证 UI 服务器中的 CDC Servlet 处理。要启用 CDSSO，参阅特定的策略代理文档并执行以下附加步骤：

可在 CDC servlet 重定向至 Access Manager 登录 URL 时指定领域

现在，您可将领域名称指定给 CDC servlet，这样在重定向至 Access Manager 登录 URL 时，领域名称便会包括在其中，而且用户可登录到特定领域。例如：

com.sun.am.policy.agents.config.cdcservlet.url=
    http://lb.example.com/amserver/cdcservlet?org=realm1

证书验证可使用 UPN 值来映射用户配置文件

以前，证书验证只使用 subjectDN 中的 dn 组件来映射用户配置文件。现在，Access Manager 允许使用 SubjectAltNameExt 中的用户主体名称 (user principal name, UPN) 值来执行配置文件映射。

在多服务器环境中对注销操作进行后期验证处理

现在，当用户在多服务器环境中从一个与最初登录的服务器不同的服务器注销时，会进行后期验证处理（无论是否配置了会话故障转移）。

SAML 支持新的名称标识符 SPI

SAML 现在支持新的名称标识符服务提供者接口 (service provider interface, SPI)，以便站点可自定义 SAML 声明中的名称标识符。站点可实现新的 NameIdentifierMapper 接口以将用户帐户映射到 SAML 声明主题中的名称标识符。

站点监视的新配置属性

Access Manager 站点监视功能包括以下新属性以允许您指定站点状态检查的行为。

属性 

描述 

com.sun.identity.urlchecker.invalidate.interval

用于识别停止或非响应站点的时间间隔（单位为毫秒）。 

默认值：70000 毫秒（70 秒）。 

com.sun.identity.urlchecker.sleep.interval

站点状态检查应休止的时间间隔（单位为毫秒）。 

默认值：30000 毫秒（30 秒）。 

com.sun.identity.urlchecker.targeturl

用于检查 Access Manager 进程状态的不同目标 URL。 

默认值：“/amserver/namingservice”。

修补程序没有将这些属性添加到 AMConfig.properties 文件中。若要以默认值以外的其他值使用这些新属性，请执行下列操作：

  1. 将属性及其值添加到 AMConfig.properties 文件。对于策略代理，将这些属性添加到 AMAgents.properties 文件。

  2. 重新启动 Access Manager Web 容器以使这些值生效。

用户不必再在验证链中验证两次

考虑以下情况。站点配置一个具有三个 LDAP 模块的验证链。所有模块均设为 SUFFICIENT，并且 iplanet-am-auth-shared-state-enabled 和 iplanet-am-auth-store-shared-state-enabled 选项设为 true。例如：

<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>

修补程序 5 向模块选项添加了新的 iplanet-am-auth-shared-state-behavior-pattern 选项，可能值为以下两者：tryFirstPass（默认值）和 useFirstPass。

为避免用户必须输入两次用户 ID 和密码才能通过验证（如之前的情况所述），对于此链中的所有模块，将此新选项设为 useFirstPass。以前，仅存在于第三个 LDAP 实例中的用户需输入两次用户 ID 和密码才能通过验证。

对性能调节脚本的更改

修补程序 5 包括以下对性能调节脚本的更改：

另请参见 CR# 6527663：com.sun.identity.log.resolveHostName 属性的默认值应为 false 而不是 true。

调节脚本支持密码文件

修补程序 5 允许您在文本文件中为调节脚本指定密码。以前，您只能将密码作为命令行参数输入，这样可能导致安全问题。要使用密码文件，在文件中根据需要设置以下变量：

DS_ADMIN_PASSWORD=DirectoryServer-admin-password
AS_ADMIN_PASSWORD=ApplicationServer8-admin-password

例如，要调节 Application Server 8：

# ./amtune-as8 password-file

其中，password-file 包含设为 Application Server 8 管理员密码的 AS_ADMIN_PASSWORD 。

调节脚本在调用 ldapmodify、ldapsearch、db2index 和 dsconf Directory Server 实用程序时使用 -j password-file 选项。

调节脚本从 Directory Server 中删除不必要的 ACI

如果在“领域模式”下安装 Access Manager 7 2005Q4，则使用委托权限来确定访问权限，因此某些 Directory Server ACI 为不必要。Access Manager 7 2005Q4 修补程序 5 允许您通过 amtune-prepareDSTuner 脚本来删除不必要的 ACI。此脚本从 remacis.ldif 文件读取 ACI 列表，然后调用 ldapmodify 实用程序来删除它们。

可运行 amtune-prepareDSTuner 脚本来删除 Solaris、Linux、HP-UX 和 Windows 系统上不必要的 ACI。有关详细信息（包含如何运行该脚本），参见《Technical Note: Sun Java System Access Manager ACI Guide》。

调节脚本可调节分布式验证 UI 服务器的 Web 容器

在 Web 容器上部署分布式验证 UI 服务器后，可通过运行 Access Manager 调节脚本来调节 Web 容器。以下调节脚本会为各 Web 容器设置 JVM 及其他调节选项：

表 2 Access Manager Web 容器调节脚本

Web 容器 

调节脚本 

amtune-ws61

Web Server 6.1 

amtune-as7

Application Server 7 

amtune-as8

Application Server Enterprise Edition 8.1 

要调节分布式验证 UI 服务器的 Web 容器：

  1. 由于 Access Manager 服务器未安装在部署了分布式验证 UI 服务器的系统上，因此从 Access Manager 服务器安装中复制相应的 Web 容器调节脚本（如上表中所示）、amtune-env 配置文件和 amtune-utils 脚本。如果您想要调节 Solaris 或 Linux 操作系统，则还需复制 amtune-os 脚本。

  2. 编辑 amtune-env 配置文件中的参数以指定 Web 容器和调节选项。要在 REVIEW 模式下运行脚本，请在 amtune-env 文件中设置 AMTUNE_MODE=REVIEW。

  3. 在 REVIEW 模式下运行 Web 容器调节脚本。在 REVIEW 模式下，脚本会根据 amtune-env 文件建议调节更改，但不会对部署做任何实际更改。

  4. 查看调试日志文件中的调节建议。如有需要，根据本次运行情况对 amtune-env 文件执行更改。

  5. 要执行调节更改，在 amtune-env 文件中设置 AMTUNE_MODE=CHANGE。

  6. 在 CHANGE 模式下运行调节脚本以对部署执行调节更改。

有关运行调节脚本以调节 Access Manager Web 容器的详细信息，参见《Sun Java System Access Manager 7 2005Q4 Performance Tuning Guide》中的第 2  章 “Access Manager Tuning Scripts”。

单个 amtune-os 脚本可调节 Solaris OS 和 Linux OS

修补程序 5 包括可调节 Solaris OS 和 Linux OS 的单个 amtune-os 脚本。此脚本使用 uname -s 命令来确定 OS 类型。以前，Access Manager 提供单独的 amtune-os 脚本来调节各种 OS。

在 Solaris 10 本地区域中调节脚本可以完整执行

如果 Access Manager 安装在 Solaris 10 本地区域中，则除 amtune-os 以外的所有调节脚本均可在本地区域中运行。在本地区域中，amtune-os 脚本显示一条警告消息，但不调节 OS。接下来，脚本会继续运行您已请求的任何其他调节脚本。以前，在本地区域中，amtune-os 会异常中止，并且不会运行任何您已请求的后续调节脚本。

在 Solaris 10 全局区域中，amtune 脚本会调用 amtune-os 来调节 OS 以及您已请求运行的任何其他脚本。

Windows 系统可使用调节脚本

修补程序 5 包括以下用于 Windows 系统的调节脚本。在 Windows 系统上运行调节脚本与在 Solaris 系统或 Linux 系统上运行脚本类似，但有以下区别：

Sun Fire T1000 和 T2000 服务器的调节注意事项

如果 Access Manager 安装在 Sun Fire T1000 或 T2000 服务器上，则适用于 Web Server 6.1 和 Application Server 8 的修补程序 5 调节脚本将 JVM GC ParallelGCThreads 参数设为 8：

-XX:ParallelGCThreads=8

此参数减少垃圾回收线程数，在具备 32 线程处理能力的系统中该线程数量可能会显得不必要的高。不过，如果 32 位虚拟 CPU 计算机（如 Sun Fire T1000 或 T2000 服务器）将所有垃圾回收活动数量最小化，您仍可将该值增加到 16 甚至 20。

同时，对于带有采用 CoolThreads 技术的 CMT 处理器的 Solaris SPARC 系统，建议在 /etc/opt/SUNWam/config/AMConfig.properties 文件的结尾处添加以下属性：

com.sun.am.concurrencyRate=value

默认的 value 为 16，但可将此属性设为更低的值，具体取决于 Sun Fire T1000 或 T2000 服务器中的核心数。

IIS 6.0 策略代理中的基本验证

要在 Microsoft Internet 信息服务 (Internet Information Services, IIS) 6.0 中启用基本验证，策略代理必须获得用户名和密码。修补程序 5 包括以下新类，它们可使用用户密码的 DES 加密来启用此功能：

要在 IIS 6.0 中使用基本验证，您必须在 Access Manager 服务器端和 IIS 6.0 策略代理端上执行以下步骤。

在 Access Manager 服务器端：

  1. 执行 DESGenKey.java 生成唯一的加密密钥来对密码进行加密和解密。在 Solaris 系统上，DESGenKey.java 文件位于 com/sun/identity/common 目录下，包括在 /opt/SUNWam/lib 目录的 am_sdk.jar 中。例如，以下命令可生成加密密钥：

    # cd /opt/SUNWam/lib
# java -cp am_sdk.jar com.sun.identity.common.DESGenKey

  2. 将从步骤 1 得到的加密密钥值指定给 AMConfig.properties 文件中的 com.sun.am.replaypasswd.key 属性。

  3. 将 ReplayPasswd.java 部署为后期验证插件。配置插件时，请使用完整的类名：com.sun.identity.authentication.spi.ReplayPasswd。

在 IIS 6.0 策略代理端：

  1. 将从服务器端得到的加密密钥值指定给 AMAgent.properties 文件中的 com.sun.am.replaypasswd.key 属性。Access Manager 服务器和 IIS 6.0 策略代理必须使用相同的加密密钥。

  2. 在 IIS 6.0 Manager 中启用基本验证。

IIS 6.0 策略代理从会话响应中读取加密密码，从 com.sun.am.replaypasswd.key 属性解密密码，并设置验证标头使基本验证生效。

有关 IIS 6.0 策略代理的信息，参见《Sun Java System Access Manager Policy Agent 2.2 Guide for Microsoft Internet Information Services 6.0》。

CR# 6567746：在 HP-UX 系统上，如果超过密码重试次数，Access Manager 修补程序 5 会报告错误的 errorCode 值

当用户帐户被锁定时，如果超过密码重试次数，HP-UX 系统上的 Access Manager 7 2005Q4 修补程序 5 会报告 errorCode = null 而非 errorCode = 107。

解决方法。无。

CR# 6527663：com.sun.identity.log.resolveHostName 属性的默认值应为 false 而不是 true

在运行 amtune-identity 调节脚本之前，建议将以下设为 false 的属性添加到 AMConfig.properties 文件中：

com.sun.identity.log.resolveHostName=false

值为 false 可最小化解析主机名的影响，从而提升性能。不过，如果要在 amAuthentication.access 日志中显示客户机的主机名，则将该值设为 true。

CR# 6527528：删除修补程序会留下带明文格式 amldapuser 密码的 XML 文件

如果从 Access Manager 完整服务器安装中删除修补程序 5，则 amAuthLDAP.xml 和 amPolicyConfig.xml 文件会包含明文格式的 amldapuser 密码。根据平台的不同，这些文件会位于以下目录：

解决方法：编辑 amAuthLDAP.xml 和 amPolicyConfig.xml 文件并删除明文密码。

CR# 6527516：WebLogic 上的完整服务器要求 JAX-RPC 1.0 JAR 文件与客户机 SDK 进行通信

在 Access Manager 7 2005Q4 修补程序中，Access Manager 用于 BEA WebLogic Server 的配置脚本 (amwl81config) 将 JAX-RPC 1.1 JAR 文件添加到 WebLogic 实例的 classpath 中。尽管此修改对 Sun Java System Portal Server 之类的产品有益，但是部署在 WebLogic Server 上的完整服务器安装 (DEPLOY_LEVEL=1) 将无法与客户机 SDK 安装进行通信，并且随后会发生异常。

如果 Access Manager 7 2005Q4 服务器安装在 BEA WebLogic Server 上，则 startWebLogic.sh 脚本中的 CLASSPATH 必须设为 JAX-RPC 1.0 JAR 文件所在的位置后，它才能与 Access Manager 客户机 SDK 进行通信。

解决方法：应用 Access Manager 修补程序之前，在 startWebLogic.sh 脚本中设置 CLASSPATH 使 WebLogic Server 实例使用 JAX-RPC 1.0 JAR 文件而非 JAX-RPC 1.1 JAR 文件：

  1. 在 Access Manager 服务器上，以超级用户身份登录或成为超级用户 (root)。

  2. 编辑 startWebLogic.sh 脚本并将 CLASSPATH 替换为使用 JAX-RPC 1.0 JAR 文件。例如：

当前值：

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:

新值：

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:

其中，AccessManager-base 为基安装目录。默认值为 /opt（Solaris 系统上）或 /opt/sun（Linux 和 HP-UX 系统上）。AccessManager-package-dir 是 Access Manager 软件包目录。

5. 重新启动 WebLogic Server 实例。

CR # 6523499：修补程序 5 amsilent 文件对于 Linux 系统上的所有用户均为可读

在 Linux 系统上，postpatch 脚本会创建具有 644 权限的 /opt/sun/identity/amsilent 文件，它允许所有用户的读取访问。

解决方法：在执行 installpatch 脚本后，更改 amsilent 文件的权限，只允许所有者拥有读取和写入访问权限。例如：

# chmod 600 /opt/sun/identity/amsilent

CR# 6520326：将修补程序 5 应用到服务器上的第二个 Access Manager 实例会覆写第一个实例的 serverconfig.xml

在这种部署情况中，两个 Access Manager 实例部署在同一主机服务器上，且每个实例位于不同的 Web 容器实例上。然后执行以下步骤：

  1. 应用修补程序 5。

  2. 修改 amsilent 文件并重新部署第一个 Access Manager 实例。

  3. 再次修改第二个 Access Manager 实例的 amsilent，然后重新部署该实例。

如果在 amsilent 文件中 NEW_INSTANCE=false，则第一个 Access Manager 实例的 serverconfig.xml 文件将被来自第二个 Access Manager 实例的信息所覆盖。随后重新启动第一个 Access Manager 实例将失败。根据平台的不同，serverconfig.xml 文件将位于以下目录：

解决方法：在部署第二个 Access Manager 时，在 amsilent 文件中设置 NEW_INSTANCE=true。这样第二个 Access Manager 实例的 serverconfig.xml 文件就能更新为正确的信息，而第一个 Access Manager 实例的 serverconfig.xml 文件也不会被覆写。

CR# 6520016：修补程序 5 的仅 SDK 安装会覆写范例 makefile

将修补程序 5 应用到仅安装 SDK 的计算机会覆写范例 makefile。

解决方法：将修补程序 5 应用到仅安装 SDK 的计算机不需要重新配置；不过，如果要使用范例 makefile，请遵循以下步骤来更新范例 makefile 的 LDIF 和属性文件（即执行标记交换）：

  1. 运行 amconfig 脚本（DEPLOY_LEVEL=14）来卸载 SDK 和取消配置 Web 容器。

  2. 运行 amconfig 脚本（DEPLOY_LEVEL=4）来重新安装 SDK 并重新配置 Web 容器。

CR#6515502：LDAPv3 系统信息库插件不能始终正确处理别名搜索属性

对于大多数搜索，此问题已得到修复。不过，在设置“别名搜索属性”时需谨慎。别名搜索属性的值必须在整个组织内唯一。如果设置了多个别名搜索属性，则有可能出现数据存储库中的一个条目匹配一个属性，而另一个条目匹配另一个属性。在这种情况下，Access Manager 服务器会抛出以下错误：

出现内部验证错误。请与您的系统管理员联系。

解决方法：无

CR# 6515383：分布式验证和 J2EE 代理在同一 Web 容器上不起作用

分布式验证 UI 服务器和 J2EE 策略代理如果安装在同一 Web 容器中则不起作用。

解决方法：创建另一个 Web 容器实例，并在容器的不同实例上部署分布式验证 UI 服务器和 J2EE 策略代理。

CR# 6508103：Application Server 在 Windows 系统上时，联机帮助会返回应用程序错误

如果在 Windows 系统中的 Sun Java System Application Server 上部署 Access Manager，则单击“领域模式”控制台的帮助屏幕左面板中的“帮助”会返回一个应用程序错误。

解决方法：将 javaes-install-dir\share\lib\jhall.jar 文件复制到 JAVA_HOME\jre\lib\ext 目录，然后重新启动 Application Server。

CR# 6507383 和 CR# 6507377：分布式验证要求显式 goto URL 参数

如果未指定显式 goto URL 参数，则分布式验证 UI 服务器会尝试重定向至 Access Manager 中指定的成功 URL 上的 goto。此重定向可能会由于以下原因而失败：

解决方法：始终为分布式验证 UI 服务器指定一个显式 goto URL 参数。

CR# 6402167：LDAP JDK 4.18 导致 LDAP客户机/Directory Server 问题

在 Java ES 2005Q4 发行版中，Access Manager 7 2005Q4 是随 LDAP JDK 4.18 一起发行的，从而导致了多个 Access Manager 与 Directory Server 连接问题。

解决方法：应用以下 Sun Java System LDAP Java Development Kit 修补程序之一：

这些修补程序可从 SunSolve Online 获取：http://sunsolve.sun.com。

CR# 6352135：分布式验证 UI 服务器文件的安装位置不正确

在 Solaris 系统上，Java ES 安装程序将分布式验证 UI 服务器 Makefile.distAuthUI、README.distAuthUI 和 amauthdistui.war 文件安装在错误的位置：/opt/SUNComm/SUNWam。

解决方法：将这些文件复制到正确的位置：/opt/SUNWam。

注意：任何在修补程序中修复的分布式验证 UI 服务器问题均会进入 /opt/SUNComm/SUNWam/amauthdistui.war 文件，因此，无论何时将修补程序应用到 Access Manager 服务器然后重建并部署 WAR 文件时，您还必须将这些文件复制到 /opt/SUNWam 目录。

CR# 6522720：在 Windows 和 HP-UX 系统上，无法在控制台联机帮助中搜索多字节字符

在 Windows 或 HP-UX 系统上，如果在使用多字节字符（如日文）的语言环境下安装 Access Manager，则无法在控制台联机帮助中使用通过多字节字符输入的关键字进行搜索。

解决方法：无

修补程序 6 更新：Access Manager 7 2005Q4 修补程序 6 在 Windows 系统上修复了该问题。但是，HP-UX 系统上仍然存在该问题。

CR# 6524251：在 Windows 系统上配置 Access Manager 的过程中，输出消息中的多字节字符为乱码

如果在 Windows 系统上安装使用多字节字符的语言环境（例如日文或中文）的 Access Manager，则在 Access Manager 配置过程中，终端窗口中的输出消息为乱码。

解决方法：无，但此问题不影响配置本身。

CR# 6526940：在 Windows 系统的非英文语言环境中安装修补程序 5 时会出现属性键，而不是消息文本

如果在 Windows 系统的非英文语言环境中安装修补程序 5 (124296-05)，则安装面板中的某些字符串将显示为属性键而非实际的消息文本。属性键的示例为 PRODUCT_NAME、JES_Patch_FinishPanel_Text1 和 JES_Patch_FinishPanel_Text2。

解决方法：无

CR# 6513653：与 com.iplanet.am.session.purgedelay 属性设置相关的问题

Access Manager amtune 脚本将 com.iplanet.am.session.purgedelay 属性设为 1，以便允许尽可能多的 Access Manager 会话。此属性指定清除会话操作延迟的分钟数。不过，对于诸如 Sun Java System Portal Server 之类的客户机，值为 1 可能还不够。

解决方法：运行 amtune 脚本后重置 com.iplanet.am.session.purgedelay 属性：

  1. 在 AMConfig.properties 文件中，将该属性设为新值。例如：

    com.iplanet.am.session.purgedelay=5

  2. 重新启动 Access Manager Web 容器以使新值生效。

Access Manager 7 2005Q4 修补程序 4

Access Manager 7 2005Q4 修补程序 4（修订版 04）修补了以下问题：

修补程序 4 的已知问题和限制

CR# 6470055：分布式验证 UI 服务器性能改进

要提高分布式验证 UI 服务器用户在读取、搜索和比较用户属性方面的性能，请执行以下步骤：

  1. 在 Makefile.distAuthUI 文件中，将应用程序用户名从 anonymous 更改为其他用户。例如：

    APPLICATION_USERNAME=user1

  2. 在 Directory Server 中，添加新用户（本例中为 user1）和 ACI 以允许读取、搜索和比较用户属性。以下示例添加新的 ACI：

    dn:ou=1.0,ou=SunAMClientData,ou=ClientData,dc=example,dc=com 
changetype:modify add:aci 
aci: (target="ldap:///ou=1.0,ou=SunAMClientData,ou=ClientData,dc=example,dc=com")
(targetattr = *")(version 3.0; 
acl "SunAM client data access to a Distributed Auth App User"; 
allow (read, search, compare) 
userdn =  "ldap:///uid=user1,ou=people,dc=example,dc=com";)

CR# 6455079：密码重置服务在密码更改时报告通知错误

更改密码后，Access Manager 使用无限定的发件人名称 Identity-Server 来提交电子邮件通知，这会导致 amPasswordReset 日志中出现错误条目。例如：

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

解决方法：更改“从”地址以包括 amPasswordResetModuleMsgs.properties 文件中主机服务器的全限定域名：

  1. 更改“从”地址标签。例如：

    fromAddress.label=<Identity-Server@amhost.example.com>

  2. 更改 lockOutEmailFrom 属性以确保锁定通知使用正确的“从”地址。例如：

    lockOutEmailFrom=<Identity-Server@amhost.example.com>

    amPasswordResetModuleMsgs.properties 文件位于 AccessManager-base/SUNWam/locale 目录（Solaris 系统）和 AccessManager-base/identity/locale 目录（Linux 系统）。

    AccessManager-base 是基安装目录。Solaris 系统的默认基安装目录是 /opt，而 Linux 系统的默认基安装目录是 /opt/sun。

Access Manager 7 2005Q4 修补程序 3

Access Manager 7 修补程序 3（修订版 03）可修复一系列的问题，其随附的自述文件中列出了具体内容。修补程序 3 还具有以下新增功能和已知问题：

修补程序 3 的新增功能

修补程序 3 的已知问题和限制

站点监视的新配置属性

Access Manager 站点监视功能包括以下新属性：

属性 

描述 

com.sun.identity.sitemonitor.interval

站点监视的间隔时间（单位为毫秒）。站点监视功能会在指定的时间间隔内检查每个站点的可用性。默认值：60000 毫秒（1 分钟）。 

com.sun.identity.sitemonitor.timeout

站点可用性检查的超时时间（单位为毫秒）。站点监视功能会在指定的超时时间内等待站点的响应。默认值：5000 毫秒（5 秒）。 

修补程序没有将这些属性添加到 AMConfig.properties 文件中。若要以默认值以外的其他值使用这些新属性，请执行下列操作：

  1. 将属性及其值添加到位于以下目录的 AMConfig.properties 文件中，具体目录取决于您所使用的平台：

    • Solaris 系统：/etc/opt/SUNWam/config

    • Linux 系统：/etc/opt/sun/identity/config

    对于策略代理，将这些属性添加到 AMAgents.properties 文件。

  2. 重新启动 Access Manager Web 容器以使这些值生效。

自定义实现。另外，com.sun.identity.sitemonitor.SiteStatusCheck 类允许您使用以下接口自定义用于检查站点可用性的实现：

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

每个实现类均必须使用 doCheckSiteStatus 方法。

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

Liberty Identity Web Services Framework (ID-WSF) 1.1 支持

Access Manager 7 修补程序 3 中的 ID-WSF 默认版本为 WSF1.1。除示例需使用新的安全机制外，触发 ID-WSF 不需要单独的配置。用于 ID-WSF1.1 的新安全机制为：

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

Liberty ID-WSF 支持的新属性

在 Access Manager 充当 WSC 的情况下，当无法通过入站消息或资源提供来确定 Liberty ID-WSF 框架时，com.sun.identity.liberty.wsf.version 属性可确定 Liberty ID-WSF 框架。其值可以是 1.0 或者 1.1，默认为 1.1。

注 安装修补程序时不会在 AMConfig.properties 文件中添加 com.sun.identity.liberty.wsf.version 属性 (CR# 6458184)。要使用此新属性，在安装修补程序后，将它和适当的值添加到 AMConfig.properties 文件中，然后重新启动 Access Manager Web 容器。

安装 Access Manager 7 修补程序 3 后，运行以下命令来加载模式更改（以将 Access Manager 安装在 Solaris 系统上的默认目录中为例）：

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

注册时，ID-WSF 搜索注册可使用这些新的安全机制。此外，WSC 在与 WSP 通信时会自动检测应使用哪个版本。要为 ID-WSF1.1 进行配置，请遵循产品随附的 Liberty ID-FF 范例 1 和 ID-WSF 范例的自述文件进行操作。

CR# 6463779 分布式验证的 amProfile_Client 日志和 Access Manager 服务器的 amProfile_Server 日志中充满了无害的异常

通过分布式验证 UI 向 Access Manager 服务器发送请求时，会触发异常并记录到 distAuth/amProfile_Client 日志和 Access Manager 服务器的 debug/amProfile_Server 日志中。经过大量会话后，amProfile_Client 日志的大小可增长到数千兆字节，而 Access Manager 服务器的 amProfile_Server 日志的大小可达数兆字节。日志中的这些异常不会对功能造成影响，但它们能导致用户接收到虚假报警，并且这些日志可能会填满整个硬盘空间。

解决方法。运行 cron 作业以清空日志文件内容。例如：

CR# 6460974 默认分布式验证应用程序用户不应该是 amadmin

如果部署的是分布式验证 UI 服务器，则分布式验证管理员不应该是 amadmin。Makefile.distAuthUI 文件中的默认分布式验证应用程序用户是 amadmin，在客户机端部署 distAuth.war 文件后，此设置也随后出现在 AMConfig.properties 文件中。amadmin 用户具有的 AppSSOToken 会在 amadmin 会话结束时过期，这将在 amSecurity 日志文件（默认情况下位于 /tmp/distAuth 目录下）中产生 FATAL ERROR。

解决方法。将 UrlAccessAgent 指定为分布式验证应用程序用户。例如：

在客户机 Web 容器中部署 distAuth.war 文件之前，更改 Makefile.distAuthUI 文件中的以下参数：

APPLICATION_USERNAME=UrlAccessAgent
APPLICATION_PASSWORD=shared-secret-password 或 amldapuser-password

或

在客户机 Web 容器中部署 distAuth.war 文件之后，在 AMConfig.properties 文件中更改每个 Access Manager 服务器的以下属性：

com.sun.identity.agents.app.username=UrlAccessAgent
com.iplanet.am.service.password=shared-secret-password 或 amldapuser-password

另请参见CR# 6440697：分布式验证应以非 amadmin 用户身份运行。

CR# 6460576 控制台联机帮助的“过滤的角色”下，没有“用户服务”的链接

Access Manager 控制台联机帮助的“过滤的角色”下没有“用户服务”链接。在联机帮助中，转至“内容”、“过滤的角色”、“创建过滤的角色”。向下翻页，根据您所选的身份类型，会显示服务列表，但其中没有“用户服务”链接。

解决方法。无

CR# 6460085 运行 reinstallRTM 并重新部署 Web 应用程序之后，无法访问 WebSphere 上的服务器

在 Red Hat Linux AS 3.0 Update 4 的 IBM WebSphere Application Server 5.1.1.6 上对 DEPLOY_LEVEL=1 的部署应用 Access Manager 7 修补程序 3 之后，运行 reinstallRTM 脚本恢复 RTM RPM。在编辑了由 reinstallRTM 脚本生成的 amsilent 文件后，重新部署 Web 应用程序。用 stopServer.sh 和 startServer.sh 脚本重新启动 WebSphere。然后，访问登录页面时，WebSphere 却显示与 amlcontroller 过滤器相关的 500 错误。

发生此问题的原因是 reinstallRTM 脚本生成的新 server.xml 文件已损坏。

解决方法。amconfig 脚本备份的 server.xml 文件仍然有效。可以按照以下步骤来使用先前的副本：

  1. 停止服务器。

  2. 用 amconfig 脚本备份的副本替换损坏的 server.xml。

    amconfig 脚本备份的 server.xml 文件的名称为 server.xml-orig- pid，其中 pid 是 amwas51config 脚本的进程 ID。此文件位于下面的目录中：

    WebSphere-home-directory/config/cells/WebSphere-cell
/nodes/WebSphere-node/servers/server-name

  3. 重新启动服务器。

CR# 6455757：升级前必须将 sunISManagerOrganization 标记类添加到组织中

在 Access Manager 7 发行之前创建的 Access Manager DIT 中的组织可能不具有 sunISManagerOrganization 对象类。而且，由 Access Manager 以外的其他产品所创建组织的定义中也不会有 sunISManagerOrganization 对象类。

解决方法。在升级到 Access Manager 7 2005Q4 前，确保 DIT 中所有组织的定义中都具有 sunISManagerOrganization 对象类。如有必要，在升级前手动添加此对象类。

CR# 6454489：Access Manager 7 2005Q4 修补程序 2 升级导致控制台“当前会话”选项卡中出错

升级导致在 Access Manager 控制台的“当前会话”选项卡中出现以下错误：

无法从指定服务器获取有效的会话

对于从根后缀格式为 o=orgname 的 Access Manager 6 版本升级的部署，均会出现此问题。

解决方法。安装 Manager 7 2005Q4 后，应用 Manager 7 修补程序 3，然后运行 amupgrade 脚本以进行数据迁移，方法如下：

  1. 备份 Access Manager 6 DIT。

  2. 运行 ampre70upgrade 脚本。

  3. 安装 Access Manager 7 2005Q4，选择“以后再配置”选项。

  4. 取消部署 Access Manager Web 应用程序。

  5. 部署 Access Manager Web 应用程序。

  6. 应用 Access Manager 7 修补程序 3，但不要应用 XML/LDIF 更改。XML/LDIF 更改必须在下一步运行 amupgrade 脚本之后再应用。

  7. 运行 amupgrade 脚本。

  8. 因为 Access Manager 7 修补程序 3 进行了更改，重新部署 Access Manager Web 应用程序。

  9. 访问 Access Manager 控制台。

CR# 6452320：在客户机 SDK 中使用轮询时抛出异常

若在部署 Access Manager 客户机 SDK (amclientsdk.jar) 后启用轮询，可能发生如下错误：

错误：发送轮询错误：
com.iplanet.am.util.ThreadPoolException：
amSessionPoller 线程池的作业队列已满。

部署分布式验证 UI 服务器、J2EE 代理后，或者在客户机上部署了 Access Manager 客户机 SDK 的情况下，均可能发生此类错误。

解决方法。如果只有数百个并发会话，则在 AMConfig.properties 文件或者 AMAgents.properties 文件中添加以下属性和值：

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

如果有数千或数万个会话，则应将值设置为与运行 amtune-identity 脚本后 Access Manager AMConfig.properties 文件中通知的值相同。例如，对于一台有 4 GB RAM 的计算机，Access Manager amtune-identity 脚本会设置以下值：

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

在拥有 4 GB RAM 的客户机上部署了分布式验证 UI 服务器或 Access Manager 客户机 SDK 后，应在客户机端的 AMAgent.properties 或 AMConfig.properties 文件中设置类似的值。

CR# 6442905 已验证用户的 SSOToken 可能会在无意中透露给流氓站点

已验证的 Access Manager 用户单击流氓站点的 URL 时，可能会在无意中将 SSOToken 透露给流氓站点。

解决方法。在 Access Manger 中总是为所有参与的策略代理创建唯一的代理用户配置文件，以确保站点不是流氓站点。同时确保这些唯一代理用户使用的密码均不与共享的秘密密码或者 amldapuser 密码相同。默认情况下，Access Manager 应用程序验证模块将策略代理验证为 UrlAccessAgent 用户。

有关使用 Access Manager 管理控制台创建代理的详细信息，参见《Sun Java System Access Manager 7 2005Q4 管理指南》中的“代理”。

CR# 6441918：站点监视时间间隔和超时属性

Access Manager 站点故障转移包括以下新属性：

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

有关详细信息，参见站点监视的新配置属性。

CR# 6440697：分布式验证应以非 amadmin 用户身份运行

要为分布式验证应用程序验证创建默认管理用户 (amadmin) 以外的分布式验证管理员，遵循以下步骤：

  1. 为分布式验证管理员创建 LDAP 用户。例如：

    uid=DistAuthAdmin,ou=people,o=am

  2. 将分布式验证管理员添加到特殊用户列表。例如：

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

    将此属性添加到所有 Access Manager 服务器的 AMConfig.properties 文件中，这样分布式验证管理员的 AppSSOToken 在会话到期后也不会过期。

CR# 6440695：包含负载平衡器的分布式验证 UI 服务器

如果您的部署中在多个分布式验证 UI 服务器之前包含负载平衡器，则在部署 WAR 文件之后设置 AMConfig.properties 文件中的以下属性。

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

CR# 6440651：Cookie 重放需要 com.sun.identity.session.resetLBCookie 属性

为使 Access Manager 会话故障转移的 cookie 重放功能正常工作，为策略代理和 Access Manager 服务器添加值为 true 的 com.sun.identity.session.resetLBCookie 属性。例如：

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

注意：仅当已实施 Access Manager 会话故障转移后需要此属性。

CR# 6440648：com.iplanet.am.lbcookie.name 属性假定默认值为 amlbcookie

默认情况下，策略代理和 Access Manager 服务器假定负载平衡器 cookie 名称为 amlbcookie。如果在后端服务器更改了此 cookie 的名称，则必须为策略代理在 AMAgent.properties 文件中使用相同的名称。同样，如果使用 Access Manager 客户机 SDK，也必须使用后端服务器所使用的同一 cookie 名称。

CR# 6440641：com.iplanet.am.lbcookie.value 属性已过时

Access Manager 不再支持服务器上的 com.iplanet.am.lbcookie.value 属性自定义负载平衡器 cookie。现在，对于由代理重放的 cookie 值及名称，Access Manager 使用配置为会话配置一部分的服务器 ID 。

CR# 6429610：在 ID-FF SSO 使用案例中无法创建 SSO 令牌

设置 Liberty Identity Federation Framework (ID-FF) 范例 1 后，联合成功，但 SSO 失败。

解决方法。在 AMConfig.properties 文件中，将 dsameuser 的 uuid 添加到 com.sun.identity.authentication.special.users 属性。对于应用程序验证，dsameuser 需要 Access Manager 服务器不会过期的 SSO 令牌。

CR# 6389564：在 Access Manager 登录期间，会在 LDAP v3 数据存储库中对用户的角色成员资格进行重复不断的查询

用户登录到 Access Manager 时，会发生对用户的 nsRoleDN 属性进行重复 LDAP 搜索的情况。

解决方法。安装 Access Manager 7 修补程序 3 后，运行以下命令（以将 Access Manager 安装在 Solaris 系统上的默认目录中为例）：

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

CR# 6385185：验证模块必须能够覆盖 "goto" URL，并指定另一不同的 URL

验证模块可覆盖 "goto" URL 并请求重定向到其他外部 Web 站点的 URL 以验证用户状态

要在验证完成后覆盖 "goto" URL，在 SSOToken 中设置以下示例中所示的属性。可使用实现 AMPostAuthProcessInterface 的 PostProcess 类的 onLoginSuccess 方法来设置此属性。 例如，在下例中 OverridingURL 即是覆盖 "goto" URL 的 URL：

public class <..> implements AMPostAuthProcessInterface {  
...
    public void onLoginSuccess(...) {
        try {
            ssoToken.setProperty("PostProcessSuccessURL", OverridingURL);
         } catch (Exception ...) {
         ...         }
...
}

CR# 6385184：当 SSO 令牌仍处于无效状态时，从自定义验证模块重定向

自定义验证模块中的新 RedirectCallback 方法允许通过验证 UI 重定向至外部 Web 站点来进行用户验证。如果验证成功，则会在之后将用户重定向回原来的 Access Manager 服务器 URL。范例文件包括：

要实现此功能：

  1. 使用范例 LoginModuleSample.java 创建自定义验证模块。

  2. 将此模块加载到 Access Manager 服务器中。

  3. 使用范例 LoginModuleSample.xml 在 XML 文件中构造 RedirectCallback。

  4. 为外部 Web 站点使用范例 testExtWebSite.jsp 文件以测试此模块。

  5. 使用以下 URL 登录：

    http://example.com/amserver/UI/Login?module=LoginModuleSample

用户名和密码均重定向至外部 Web 站点进行验证。如果用户名和密码都有效，则验证成功，然后将用户重定向回原来的 Access Manager 服务器 URL。

例如，设想一下这样的方案 - 在此方案中部署使用自定义验证模块来访问某个置备/信用卡站点：

  1. 用户调用自定义验证模块的验证进程/登录页面。

  2. 此用户输入证书（用户名和密码），然后向自定义验证模块提交请求。

  3. 自定义验证模块将用户重定向至外部置备/信用卡站点，并同时传递请求和所需的用户信息。

  4. 外部置备/信用卡站点检查用户的状态，然后返回请求以及成功或失败信息（已设为返回请求的一部分）。

  5. 自定义验证模块根据第 4 步返回的状态验证用户，并向验证服务返回相应的状态。

  6. 用户验证完成（成功或失败）。

CR# 6324056：使用辅件配置文件时联合失败

解决方法：要修复此问题，根据您所使用的平台，应用最新版本的 "Core Mobile Access" 修补程序：

应用修补程序后，重新启动 Web 容器。

Access Manager 7 2005Q4 修补程序 2

Access Manager 7 2005Q4 修补程序 2（修订版 02）可修复一系列的问题，其随附的自述文件中列出了具体内容。修补程序 2 还具有以下新增功能和已知问题：

修补程序 2 的新增功能

修补程序 2 的已知问题和限制

用户管理、身份库和服务管理高速缓存的新属性

修补程序 2 包含以下用于用户管理 (Access Manager SDK)、身份库 (Identity Repository, IdRepo) 和服务管理高速缓存的新属性。这些属性允许您基于部署要求独立地启用和禁用不同的高速缓存，以及为高速缓存条目设置生存时间 (Time To Live, TTL)。

表 3 用户管理、身份库和服务管理高速缓存的新属性

属性 

描述 

用于启用和禁用高速缓存的新属性

com.iplanet.am.sdk.caching.enabled

用于启用 (True) 或禁用 (False) 身份库 (IdRepo)、用户管理和服务管理高速缓存的全局属性。如果为 True，或者属性没有出现在 AMConfig.properties 文件中，则这三个高速缓存都会启用。

注意：仅在上述全局属性设置为 False 时，才能应用以下三个用来启用或禁用特定高速缓存的属性。

com.sun.identity.amsdk.cache.enabled

仅启用 (True) 或禁用 (False) 用户管理 (Access Manager SDK) 高速缓存。 

com.sun.identity.idm.cache.enabled

仅启用 (True) 或禁用 (False) 身份库 (IdRepo) 高速缓存。 

com.sun.identity.sm.cache.enabled

仅启用 (True) 或禁用 (False) 服务管理高速缓存。 

TTL 的新用户管理高速缓存属性.

com.iplanet.am.sdk.cache.entry.expire.enabled

启用 (True) 或禁用 (False) 用户管理高速缓存的到期时间（由以下两个属性所定义）。 

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

指定用户管理高速缓存中的用户条目在上次修改之后保持有效的时间，以分钟为单位。即，在指定的时间过去之后（上次修改或从目录读取之后），被高速缓存的条目的数据将会过期。此后，如果对这些条目的数据有新请求，则必须从目录读取数据。 

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

指定用户管理高速缓存中的非用户条目在上次修改之后保持有效的时间，以分钟为单位。即，在指定的时间过去之后（上次修改或从目录读取之后），被高速缓存的条目的数据将会过期。此后，如果对这些条目的数据有新请求，则必须从目录读取数据。TTL 的新身份库高速缓存属性 

com.sun.identity.idm.cache.entry.expire.enabled

启用 (True) 或禁用 (False) IdRepo 高速缓存的到期时间（由以下属性所定义）。 

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

指定 IdRepo 高速缓存中的非用户条目在上次修改之后保持有效的时间，以分钟为单位。即，在指定的时间过去之后（上次修改或从系统信息库读取之后），被高速缓存的条目的数据将会过期。此后，如果对这些条目的数据有新请求，则必须从系统信息库读取数据。 

使用新的高速缓存属性

Access Manager 7 2005Q4 修补程序不会自动将新的高速缓存属性添加到 AMConfig.properties 文件中。

使用新的高速缓存属性：

  1. 使用文本编辑器，将属性和它们的值添加到以下目录（由具体平台而定）的 AMConfig.properties 文件中：

    • Solaris 系统：/etc/opt/SUNWam/config

    • Linux 系统：/etc/opt/sun/identity/config

  2. 重新启动 Access Manager Web 容器以使这些值生效。

联合服务提供者的新属性

新的 com.sun.identity.federation.spadapter 属性定义了 com.sun.identity.federation.plugins.FederationSPAdapter 的实现类，该类用于在服务提供者端的联合处理期间添加特定于应用程序的处理。

另请参见CR# 6385696：现有的及新的 IDP 和 SP 不可见。

LDAP 过滤条件支持

修补程序 2 中添加了“LDAP 过滤条件”支持。策略管理员现在可以在定义策略时，在条件中指定 LDAP 过滤器。仅当用户的 LDAP 条目满足条件中指定的 LDAP 过滤器时，才会对该用户应用策略。用户的 LDAP 条目是在策略配置服务中指定的目录内进行查找。

要注册和使用“LDAP 过滤器条件”，请在安装 Access Manager 7 修补程序 2 后运行以下命令（以将 Access Manager 安装在 Solaris 系统上的默认目录中为例）：

# /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

修补程序 5 说明如果您已添加 Access Manager 7 2005Q4 修补程序 5 并运行 updateschema.sh 脚本，则您不需要使用 amadmin 来加载这些文件。有关更多信息，请参见提供新的 updateschema.sh 脚本来加载 LDIF 和 XML 文件。

CR# 6283582：Access Manager 实例之间没有共享登录失败次数

安装 Access Manager 7 修补程序 2 后，运行以下命令（以安装在 Solaris 系统的默认目录下的 Access Manager 为例）：

# 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

DirectoryServer-base 的默认值在 Solaris 系统中是 /var/opt/mps/serverroot，而在 Linux 系统中是 /var/opt/sun/directory-server。

修补程序 5 说明如果您已添加 Access Manager 7 2005Q4 修补程序 5 并运行 updateschema.sh 脚本，则您不需要使用 amadmin 来加载这些文件。有关更多信息，请参见提供新的 updateschema.sh 脚本来加载 LDIF 和 XML 文件。

CR# 6293673：发出会话超时通知时，需要保留原来的会话信息

AMConfig.properties 文件中的新 com.sun.identity.session.property.doNotTrimList 属性可包含会话属性名称的列表（以逗号分隔）。一旦会话超时，此列表中定义的属性也不会被移除，因此在清除会话前均可以访问这些属性。例如：

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

CR# 6244578：Access Manager 应当警告用户：浏览器 cookie 支持已禁用/不可用

AMConfig.properties 文件中的新 com.sun.identity.am.cookie.check 属性指示服务器是否应当检查浏览器中的 cookie 支持/cookie 启用。其值为 true 时，服务器将检查浏览器中的 cookie 支持/cookie 启用。如果浏览器不支持或没有启用 cookie，则服务器会抛出错误页面。如果希望服务器对验证功能提供无 cookie 模式支持，则应将此值设置为 false（即默认值）。

CR# 6236892：登录后，CDCServlet 处理 AuthNResponse 时显示图像/文本占位符

以下新属性被添加到 AMConfig.properties 文件中，并由 CDCServlet 读取：

CR# 6363157：如果确实需要，新属性可禁用持久性搜索

AMConfig.properties 文件中的新 com.sun.am.event.connection.disable.list 属性用于指定可禁用的事件连接。其值（不区分大小写）可为：

aci - 对 aci 属性所做的更改，且使用 LDAP 过滤器 (aci=*) 进行搜索

sm - Access Manager 信息树（或服务管理节点）中的更改，包括具有 sunService 或 sunServiceComponent 标记对象类的对象。例如，您可以创建一个策略来定义受保护资源的访问权限，或者您可以修改现有策略的规则、对象、条件或响应提供者。

um - 用户目录（或用户管理节点）中的更改。例如，您可以更改用户的名称或地址。

例如，要禁用对 Access Manager 信息树（或服务管理节点）更改的持久性搜索：

com.sun.am.event.connection.disable.list=sm

要指定多个值，请将每个值以逗号分隔。

注意 – 注意 –

持久性搜索会导致 Directory Server 上性能系统开销增加。如果您确定删除某些此类性能系统开销在生产环境中确实非常必要，可使用 com.sun.am.event.connection.disable.list 属性禁用一个或多个持久性搜索。

不过，在禁用持久性搜索前，您应该了解上述限制。强烈建议不要更改此属性，除非确实有必要。引入此属性的主要目的是避免在 Directory Server 上使用多个 2.1 J2EE 代理时产生的系统开销，因为这些代理中的每一个都会建立此类持久性搜索。2.2 J2EE 代理不再建立此类持久性搜索，因此您可能不需要使用此属性。

有关更多信息，请参见记录关于禁用持久性搜索的更多信息 (6486927)。

CR# 6385696：现有的及新的 IDP 和 SP 不可见

AMConfig.properties 文件中的新 com.sun.identity.federation.spadapter 属性可指定联合服务提供者适配器的默认实现，应用程序可从中获得声明和响应信息。例如：

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

Access Manager 7 2005Q4 修补程序 1

Access Manager 7 2005Q4 修补程序 1（修订版 01）可修复一系列的问题，其随附的自述文件中列出了具体内容。修补程序 1 还具有以下新增功能和已知问题：

创建调试文件

默认情况下，Access Manager 调试文件创建于调试目录中，即使 AMConfig.properties 文件中的 com.iplanet.services.debug.level 属性设置为 error 时也是如此。Access Manager 7 修补程序 1 发布前，仅在第一条调试消息记录到文件中时才创建调试文件。

支持 LDAPv3 插件中的角色和过滤的角色

如果数据存储在 Sun Java System Directory Server 中，则 Access Manager 7 修补程序 1 支持 LDAPv3 插件中的角色和过滤的角色。有关详细信息，参见对支持 LDAPv3 插件的角色和过滤角色的说明 (6365196)。

CR# 6320475：服务器端的 com.iplanet.am.session.client.polling.enable 不能为 true

服务器端的 AMConfig.properties 文件中的 com.iplanet.am.session.client.polling.enable 属性默认设置为 false，并且任何时候都不能将其重置为 true。

CR# 6358751：如果加密密钥包含空格，则无法应用 Access Manager 7 修补程序 1

如果密码加密密钥包含空格，则无法应用此修补程序。

解决方法。使用不包含空格的新加密密钥。有关更改加密密钥的详细步骤，参见：《Sun Java System Access Manager 7 2005Q4 Deployment Planning Guide》中的附录 B “Changing the Password Encryption Key”。