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，則會以隨機順序嘗試位址。

若要將此屬性設定為 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：重新導向 URL 可在認證後續處理 SPI 外掛程式中動態設定

重新導向 URL 現在可在認證後續處理 SPI 外掛程式中，針對登入成功、登入失敗與登出進行動態設定 。如果未執行後續處理外掛程式，就不會使用在後續處理 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 修補程式安裝在 Solaris 10 全域區域中，請呼叫含有 -G 引數的 patchadd 指令。例如：

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

postpatch 程序檔會顯示關於重新部署 Access Manager 應用程式的訊息，除非系統中只安裝了 Access Manager SDK 元件。

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

backout 程序檔顯示的訊息與 patchadd 指令的類似，除非系統中只安裝了 Access Manager SDK 元件。

移除修補程式後，請使用 AccessManager-base/SUNWam 目錄中的 amsilent 檔案重新部署 Access Manager 應用程式，其中 AccessManager-base 為基底安裝目錄。在 Solaris 系統上，預設基底安裝目錄為 /opt。

依照您的部署需求在 amsilent 檔案中設定參數。

然後執行下列指令 (以安裝在 Solaris 系統上預設目錄中的 Access Manager 為例)：

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

如需有關 patchadd 及 patchrm 指令的附加資訊及範例，請參閱對應的 Solaris 線上手冊。

另請參閱安裝後注意事項，以瞭解更多資訊。

Solaris 10 區域

Solaris 10 作業系統推出了「區域」新概念。因此，patchadd 指令也包含新的 -G 選項，該選項只將修補程式加入全域區域。依預設，patchadd 指令在要修補之套裝軟體的 pkginfo 中尋找 SUNW_PKG_ALLZONES 變數。但是，對於所有 Access Manager 套裝軟體，SUNW_PKG_ALLZONES 變數都沒有設定。如果 Access Manager 7 2005Q4 安裝於全域區域，則需要 -G 選項。如果 Access Manager 安裝於本機區域，則 patchadd -G 選項沒有效果。

如果您要在 Solaris 系統上安裝 Access Manager 7 2005Q4 修補程式，建議您使用 -G 選項。例如：

 # patchadd -G AM7_patch_dir

同樣地，如果 Access Manager 安裝於全域區域，則需要 -G 選項才能執行 patchrm 指令。例如：

# patchrm -G 120954-07

適用於 Linux 系統的修補程式安裝說明

在您安裝 Linux 修補程式之前，請確定已備份列於安裝前注意事項中的檔案。

installpatch 可以在獨立式 Linux 系統上安裝修補程式。例如：

# ./installpatch

postpatch 程序檔輸出與 Solairs 系統上的訊息類似的訊息。但是，在 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 儲存位置的路徑，並安裝 RTM RPM 將修補的 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 服務。

備註：如果您取消修補程式，由 AM7p7\scripts\updateschema.pl 程序檔所增加的模式變更不會從 Directory Server 中移除。不過您也不需要手動移除這些模式變更，因為在取消修補程式作業之後，這些變更並不會影響 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 容器。

備註：如果您移除修補程式，由 updateschema.sh 程序檔所增加的模式變更不會從 Directory Server 中移除。不過您也不需要手動移除這些模式變更，因為在移除修補程式之後，這些變更並不會影響 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 檔案為：

在 Solaris 系統中這些檔案位於 AccessManager-base/SUNWam 下，在 Linux 系統中則位於 AccessManager-base/identity 下。

在 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 容器變數的更多資訊，請參閱 Solaris 系統上 /opt/SUNWam/bin 目錄下，或 Linux 系統上 /opt/sun/identity/bin 目錄下的 amsamplesilent 檔案。

    在 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 檔案均位於 Solaris 系統的 AccessManager-base/SUNWam/web-src/ (或 Linux 系統的 AccessManager-base/identity/web-src/) 目錄下的適當子目錄中，並已備份所有的自訂檔案。

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

用於載入 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 容器以使該新值生效。

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 檔案在 Solaris 系統上是位於 AccessManager-base/SUNWam/locale 目錄，在 Linux 系統上是位於 AccessManager-base/identity/locale 目錄。

    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 用作 WCS 時，如果無法依據傳入訊息或資源提供確定 Liberty ID-WSF 架構，則 com.sun.identity.liberty.wsf.version 特性可確定 Liberty ID-WSF 架構。特性值可以是 1.0 或 1.1。預設值是 1.1。

備註 修補程式安裝不會將 com.sun.identity.liberty.wsf.version 特性加入 AMConfig.properties 檔案 (CR# 6458184)。若要使用此新特性，請在安裝修補程式後，將它及適當的值加入 AMConfig.properties 檔案，然後重新啟動 Access Manager Web 容器。

在安裝 Access Manager 7 修補程式 3 之後，請執行下列指令來載入模式變更 (以安裝在 Solaris 系統上預設目錄中的 Access Manager 為例)：

# /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 記錄檔大小可能會擴充到數個 GB，而 Access Manager 伺服器的 amProfile_Server 記錄檔也可能增長到數個 MB。記錄檔中的異常不會導致功能失常，但會造成向使用者傳送假警報，而且記錄檔可能填滿硬碟空間。

解決方法：執行 cron 工作，如此可清空記錄檔內容。例如：

CR# 6460974 預設的分散式認證應用程式使用者不應為 amadmin

如果部署分散式認證 UI 伺服器，則分散式認證管理員不應為 amadmin。Makefile.distAuthUI 檔案中預設的分散式認證應用程式使用者是 amadmin，在用戶端部署了 distAuth.war 檔案之後，在 AMConfig.properties 檔案中也是 amadmin。amadmin 使用者具有在 amadmin 階段作業時間執行完畢之後到期的 AppSSOToken，因此會在 amSecurity 記錄檔 (預設位於 /tmp/distAuth 目錄) 中造成 FATAL ERROR。

解決方法：指定 UrlAccessAgent 做為分散式認證應用程式使用者。例如：

在用戶端 Web 容器中部署 distAuth.war 檔案之前，請變更 Makefile.distAuthUI 檔案中的下列參數：

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

或

在用戶端 Web 容器中部署 distAuth.war 檔案之後，請為每個 Access Manager 伺服器變更 AMConfig.properties 檔案中的下列特性：

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. 將毀壞的 server.xml 替代為 amconfig 程序檔所備份的副本。

    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 變更。必須在下一步執行 amupgrade 程序檔之後再套用 XML/LDIF 變更。

  7. 執行 amupgrade 程序檔。

  8. 重新部署 Access Manager Web 應用程式，因為 Access Manager 7 修補程式 3 進行了變更。

  9. 存取 Access Manager 主控台。

CR# 6452320：在用戶端 SDK 中使用輪詢會丟出異常

部署 Access Manager 用戶端 SDK (amclientsdk.jar) 並啟用輪詢時，會發生如下錯誤：

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

在部署分散式認證 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

當分散式認證 UI 伺服器或 Access Manager 用戶端 SDK 部署在具有 4GB RAM 的用戶端機器上時，請在用戶端的 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。Access Manager 現在改用伺服器 ID，伺服器 ID 配置為階段作業配置的一部份，用於代理程式要重送的 cookie 值及名稱。

CR# 6429610：無法在 ID-FF SSO 使用案例中建立 SSO 記號

設定 Liberty Identity Federation Framework (ID-FF) 範例 1 之後，聯合成功，但 SSO 失敗。

解決方法：將 dsameuser 的 uuid 加入 AMConfig.properties 檔案的 com.sun.identity.authentication.special.users 特性中。若為應用程式認證， dsameuser 需要 Access Manager 伺服器不會到期的 SSO 記號。

CR# 6389564：Access Manager 登入期間，在 LDAP v3 資料存放區中對使用者的角色成員身份進行重複不斷的查詢

當使用者登入 Access Manager 時，會對使用者的 nsRoleDN 屬性進行重複的 LDAP 搜尋。

解決方法：在安裝 Access Manager 7 修補程式 3 之後，請執行下列指令 (以安裝在 Solaris 系統上預設目錄中的 Access Manager 為例)：

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

CR# 6385185：認證模組必須可以置換「goto」URL 並指定不同的 URL

認證模組可以置換「goto」URL 並請求重新導向至其他外部網站的 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 重新導向至外部網站，以便驗證使用者。如果認證成功，則會將使用者重新導向回原來的 Access Manager 伺服器 URL。範例檔案包括：

若要實作此功能：

  1. 使用範例 LoginModuleSample.java 建立自訂認證模組。

  2. 將該模組載入 Access Manager 伺服器。

  3. 使用範例 LoginModuleSample.xml 在 XML 檔案中建構 RedirectCallback。

  4. 將範例 testExtWebSite.jsp 檔案用於外部網站，以測試該模組。

  5. 使用下列 URL 登入：

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

使用者名稱及密碼會重新導向至外部網站進行驗證。如果名稱及密碼有效，則認證成功，而且會將使用者重新導向回到原來的 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 之後執行下列指令 (以安裝在 Solaris 系統上預設目錄中的 Access Manager 為例)：

# /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 來載入這些檔案。如需更多資訊，請參閱用於載入 LDIF 和 XML 檔案的新 updateschema.sh 程序檔。

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 來載入這些檔案。如需更多資訊，請參閱用於載入 LDIF 和 XML 檔案的新 updateschema.sh 程序檔。

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。值為 true 時，伺服器將檢查瀏覽器是否支援/啟用 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 特性來停用一個或多個持續搜尋。

不過，在您停用持續搜尋之前，必須先瞭解上述限制。我們強烈建議您除非絕對必要，否則請不要變更該特性。引入此特性的主要目的是，避免在使用多個 2.1 J2EE 代理程式時由於每個代理程式都會建立這些持續搜尋而導致 Directory Server 發生超負荷。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」。