test

Sun Java System Access Manager 7 2005Q4 版本說明

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

用於載入 LDIF 和 XML 檔案的新 updateschema.sh 程序檔

修補程式 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/SUMWam/logs/AM70Patch.upgrade.schema. timestamp

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

  6. 在程序檔結束之後，重新啟動 Access Manager Web 容器。

備註 如果您取消修補程式 5 作業，由 updateschema.sh 程序檔增加的模式變更並不會從 Directory Server 移除。不過您也不需要手動移除這些模式變更，因為在取消修補程式作業之後，這些變更並不會影響 Access Manager 的功能或可用性。

對特定應用程式閒置階段作業逾時值的支援

修補程式 5 允許不同的應用程式具有不同的階段作業閒置逾時值。在企業中，某些應用程式所需的階段作業閒置逾時值可能要少於在階段作業服務中指定的階段作業閒置逾時。例如，您已在階段作業服務中指定階段作業的閒置逾時值為 30 分鐘，但在使用 HR 應用程式時，如果使用者已閒置超過 10 分鐘時就應視為逾時。

使用此功能的條件為：

若要使用此功能：

例如，使用下列認證方案條件來考量策略 http://host.sample.com/hr/*：

如果已定義多重策略來保護 HR 應用程式的資源，您必須將該條件加入所有策略中。

當個別階段作業中的使用者嘗試存取由 Access Manager 代理程式所保護的 HR 應用程式時，系統會提示該使用者需取得 LDAP 方案的認證 (如果使用者尚未取得認證)。

如果使用者已取得 LDAP 方案的認證，則只有在上次認證之後的 10 分鐘以內，或在使用者上次存取 HR 應用程式時間後的 10 分鐘以內，該使用者才被允許進行存取。否則，系統會提示該使用者需再次取得 LDAP 方案的認證才能存取應用程式。

CDC Servlet 可部署在分散式認證 UI 伺服器上

CDC Servlet 能與分散式認證 UI 伺服器並存於 DMZ 中以啟用跨網域單次登入 (Cross-Domain Single Sign-On, CDSSO)。Access Manager 伺服器可部署在防火牆之後，分散式認證 UI 伺服器中的 CDC Servlet 會處理為達成 CDSSO 而對 Access Manager 進行的所有存取。若要啟用 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。

同樣地，對於含有 CMT 處理器 (採用 CoolThreads 技術) 的 Solaris SPARC 系統，我們建議您在 /etc/opt/SUNWam/config/AMConfig.properties 檔案的結尾加入以下特性：

com.sun.am.concurrencyRate=value

預設 value 為 16，但您可以根據 Sun Fire T1000 或 T2000 伺服器中的核心數將此特性設為較低的值。

IIS 6.0 策略代理程式的基本認證

若要在 Microsoft 網際網路資訊服務 (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：移除修補程式後，XML 檔案的 amldapuser 密碼成為明文形式

如果您從 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 修補程式中，BEA WebLogic Server 的 Access Manager 配置程序檔 (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 為基底安裝目錄。Solaris 系統上的預設值為 /opt，Linux 和 HP-UX 系統上的預設值為 /opt/sun。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. 以 DEPLOY_LEVEL=14 執行 amconfig 程序檔以解除安裝 SDK 並取消配置 Web 容器。

  2. 以 DEPLOY_LEVEL=4 執行 amconfig 程序檔以重新安裝 SDK 並重新配置 Web 容器。

CR# 6515502：LDAPv3 儲存庫外掛程式無法總是正確處理別名搜尋屬性

對於大部分的搜尋來說，此問題已獲得修正。不過，在設定別名搜尋屬性時必須特別小心。別名搜尋屬性的值在組織中必須是唯一的。如果設定了多個別名搜尋屬性，則有可能資料存放區的一個項目與一個屬性相符，而另一個項目與另一個屬性相符。在此情況中，Access Manager 伺服器會丟出以下錯誤：

發生內部認證錯誤。請與您的系統管理員連絡。

解決方法：無

CR# 6515383: 無法在同一 Web 容器中使用分散式認證和 J2EE 代理程式

如果分散式認證 UI 伺服器和 J2EE 策略代理程式安裝在相同的 Web 容器中，它們將無法運作。

解決方法：再建立一個 Web 容器實例並將分散式認證 UI 伺服器和 J2EE 策略代理程式部署在該容器的不同實例中。

CR# 6508103：Application Server 在 Windows 系統中時，線上說明會傳回應用程式錯誤

如果您將 Access Manager 部署在 Windows 系統中的 Sun Java System Application Server 上，在範圍模式的說明螢幕左面板中按一下 [說明] 將傳回應用程式錯誤。

解決方法：將 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 系統上，無法在主控台線上說明中搜尋多位元組字元

若 Access Manager 安裝於使用多位元組字元語言環境 (如日文) 的 Windows 或 HP-UX 系統上，無法在主控台線上說明中使用透過多位元組字元輸入的關鍵字進行搜尋。

解決方法：無

修補程式 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 容器以使該新值生效。