已知問題和限制

本節說明 Access Manager 7.1 版本發行時的已知問題和解決方法 (如有提供)。

• 安裝問題

• 升級問題

• 相容性問題

• 配置問題

• 效能問題

• Access Manager 主控台問題

• 指令行問題

• SDK 與用戶端問題

• 認證問題

• 階段作業與 SSO 問題

• 策略問題

• 伺服器啟動問題

• AMSDK 問題

• SSL 問題

• 範例問題

• Linux OS 問題

• Windows 與 HP-UX 問題

• 聯合與 SAML 問題

• 全球化 (g11n) 問題

• 文件問題

安裝問題

Java System Enterprise 安裝問題的相關資訊包含於 JES5 版本說明中。請參閱「Sun Java Enterprise System 5 Release Notes for UNIX」中的「Access Manager Installation Issues」一節。

本節包含下列已知問題：

• 在 WebLogic 上的 Access Manager 單一 WAR 部署需要 JAX-RPC 1.0 JAR 檔案才可與用戶端 SDK 通訊 (6555040)

• JES 5 安裝程式為 Websphere 5.1 產生的單一 WAR 需要其他 .jar 檔案 (6550261)

• Websphere 的單一 WAR 部署必須變更 server.xml 才能與用戶端 SDK 通訊 (6554379)

• 分散式認證必須變更才能與 Weblogic 及 Websphere 的 Access Manager 單一 War 配合使用 (6554372)

在 WebLogic 上的 Access Manager 單一 WAR 部署需要 JAX-RPC 1.0 JAR 檔案才可與用戶端 SDK 通訊 (6555040)

部署於 Weblogic 8.1 上的單一 WAR 在 JAX-RPC 初始化過程中會出現已知問題。為了讓 Access Manager 與用戶端 SDK 通訊，需要以 JAX-RPC 1.0 jar 檔案替代 JAX-RPC 1.1 jar 檔案。

解決方法：

有兩種方法可取得 WAR 檔案。一種是透過將 Access Manager 設定為 [以後配置] 選項執行 Java Enterprise System 5 安裝程式，另一種是透過 Sun 下載網站。

如果您已透過選擇 [以後配置] 選項執行 JES 5 安裝程式產生 WAR 檔：

1. 從 AccessManager-base/SUNWam/web-src/WEB-INF/lib 移除下列 JAXRPC 1.1 .jar 檔案：

   • jaxrpc-api.jar

   • jaxrpc-spi.jar

   • jaxrpc-impl.jar

2. 將下列 .jar 檔案從其各自的位置複製到 AccessManager-base/SUNWam/web-src/WEB-INF/lib：

   • /opt/SUNWam/lib/jaxrpc 1.0 中的 jaxrpc-api.jar

   • /opt/SUNWam/lib/jaxrpc 1.0 中的 jaxrpc_ri.jar

   • /opt/SUNWmfwk/lib 中的 commons-logging.jar

3. 移至 AccessManager-base/SUNWam/bin/ 並執行下列指令：

   amconfig —s samplesilent

   如需使用 amconfig 程序檔配置 Access Manager 的詳細資訊，請參閱「Access Manager Post Installation Guide」中的「Running the Access Manager amconfig Script」。

如果您已透過 Sun 下載網站 (http://www.sun.com/download/index.jsp) 取得 WAR 檔案：

1. 取得 ZIP_ROOT/applications/jdk14/amserver.war 檔案，並將其解壓縮至暫存位置，例如 /tmp/am-staging。

2. 從 /tmp/am-staging/WEB-INF/lib 中移除下列 JAXRPC 1.1 .jar 檔案：

   • jaxrpc-api.jar

   • jaxrpc-spi.jar

   • jaxrpc-impl.jar

3. 將位於 ZIP_ROOT/applications/jdk14/jarFix 目錄中的下列 JAXRPC 1.0 .jar 檔案與共用記錄 .jar 檔案複製到 /tmp/am-staging/WEB-INF/lib：

   • jaxrpc-api.jar

   • jaxrpc-ri.jar

   • commons-logging.jar

4. 重新建立與部署 Access Manager WAR。如需詳細資訊，請參閱「Access Manager Post Installation Guide」中的「Deploying Access Manager as a Single WAR File」。

JES 5 安裝程式為 Websphere 5.1 產生的單一 WAR 需要其他 .jar 檔案 (6550261)

如果透過選擇 [以後配置] 選項執行 JES 5 安裝程式來產生 Access Manager 單一 WAR，則需要其他 .jar 檔案才能部署 Websphere 5.1。

解決方法：

1. 從 /usr/share/lib 中將 jsr173_api.jar 複製到 AcessManager-base/opt/SUNWam/web-src/WEB-INF/lib 目錄。

2. 移至 AccessManager-base/SUNWam/bin/ 並執行下列指令：

   amconfig —s samplesilent

   如需使用 amconfig 程序檔來配置 Access Manager 的詳細資訊，請參閱「Access Manager Post Installation Guide」中的「Running the Access Manager amconfig Script」。

Websphere 的單一 WAR 部署必須變更 server.xml 才能與用戶端 SDK 通訊 (6554379)

為了讓 Websphere 5.1 的 Access Manager 單一 WAR 部署與用戶端 SDK 成功通訊，您必須變更 server.xml 檔案。

解決方法：

若要正確變更 server.xml 檔案，請參閱下列步驟：

1. 取得 amserver.war 檔案。有兩種方法可取得單一 WAR 檔案：透過選擇 [以後配置] 選項執行 JES 5 安裝程式，或透過 Sun 下載網站。

   ---

   備註 –

   如果您已透過 JES 5 安裝程式產生 WAR 檔案，請確定您已完成已知問題 #6550261 中所述的步驟。

   ---

2. 將 Access Manager WAR 解壓縮至暫存位置，例如 /tmp/am-staging。

3. 將下列共用 .jar 檔案從 /tmp/am-staging/WEB-INF/lib 複製到共用位置 (例如 /export/jars)：

   jaxrpc-api.jar         jaxrpc-spi.jar                jaxrpc-impl.jar              saaj-api.jar
   saaj-impl.jar           xercesImpl.jar               namespace.jar                xalan.jar
   dom.jar                     jax-qname.jar               jaxb-api.jar                     jaxb-impl.jar
   jaxb-libs.jar            jaxb-xjc.jar                    jaxr-api.jar                     jaxr-impl.jar
   xmlsec.jar                swec.jar                          acmecrypt.jar                  iaik_ssl.jar
   iaik_jce_full.jar       mail.jar                             activation.jar                   relaxngDatatype.jar
   xsdlib.jar                   mfwk_instrum_tk.jar   FastInfoset.jar                jsr173_api.jar

4. 從暫存位置的 /tmp/am-staging/WEB-INF/lib 中移除相同的 .jar 檔案。

5. 更新 Websphere 實例的 server.xml。如果 server.xml 中的 jvmEntries 的預設實例位置是 /opt/WebSphere/AppServer/config/cells/node-name/nodes/node-name/servers/server1，請如下所示進行變更：

   <classpath>/export/jars/jaxrpc-api.jar:/export/jars/jaxrpc-spi.jar:
           /export/jars/jaxrpc-impl.jar:/export/jars/saaj-api.jar:
           /export/jars/saaj-impl.jar:/export/jars/xercesImpl.jar:
           /export/jars/namespace.jar:/export/jars/xalan.jar:/export/jars/dom.jar:
           /export/jars/jax-qname.jar:/export/jars/jaxb-api.jar:/export/jars/jaxb-impl.jar:
           /export/jars/jaxb-libs.jar:/export/jars/jaxb-xjc.jar:/export/jars/jaxr-api.jar:
           /export/jars/jaxr-impl.jar:/export/jars/xmlsec.jar:/export/jars/swec.jar:
           /export/jars/acmecrypt.jar:/export/jars/iaik_ssl.jar:
           /export/jars/iaik_jce_full.jar:/export/jars/mail.jar:
           /export/jars/activation.jar::/export/jars/relaxngDatatype.jar:
           /export/jars/xsdlib.jar:/export/jars/mfwk_instrum_tk.jar:
           /export/jars/FastInfoset.jar:/export/jars/jsr173_api.jar</classpath>

6. 重新啟動容器。

7. 從 /tmp/am-staging 重新建立與部署 Access Manager WAR。如需詳細資訊，請參閱「Access Manager Deployment Planning Guide」中的「Deploying Access Manager as a Single WAR File」。

分散式認證必須變更才能與 Weblogic 及 Websphere 的 Access Manager 單一 War 配合使用 (6554372)

因為容器版本是 JDK14，所以分散式認證 WAR 需要其他 jar 檔案才能為 Weblogic 8.1 與 Websphere 5.1 進行剖析。JDK14 .jar 檔案位於 .zip 檔案的下列目錄中：

ZIP-ROOT/applications/jdk14/jarFix

解決方法：

針對 Weblogic 8.1：

1. 使用設定程序檔來配置分散式認證。請參閱「Access Manager Post Installation Guide」中的「Deploying a Distributed Authentication UI Server」。

2. 將更新的分散式認證 WAR 解壓縮至暫存位置，例如 /tmp/dist-auth。

3. 將 xercesImpl.jar、dom.jar 與 xalan.jar 從 ZIP-ROOT/applications/jdk14/jarFix 複製到 /tmp/dist_auth/WEB-INF/lib 目錄。

4. 從暫存位置重新產生分散式認證 WAR 並部署它。如需詳細資訊，請參閱「Access Manager Post Installation Guide」中的「Deploying a Distributed Authentication UI Server WAR File」。

針對 Websphere 5.1：

1. 使用設定程序檔配置分散式認證。請參閱「Access Manager Post Installation Guide」中的「Deploying a Distributed Authentication UI Server」。

2. 將更新的分散式認證 WAR 解壓縮至暫存位置，例如 /tmp/dist_auth/。

3. 將 xercesImpl.jar、dom.jar 與 xalan.jar 從 ZIP-ROOT/applications/jdk14/jarFix 複製到 /tmp/dist_auth/WEB-INF/lib 目錄。

4. 編輯 WEB-INF/web.xml 檔案並以 http://java.sun.com/dtd/web-app_2_3.dtd 取代 jar://web-app_2_3.dtd。

5. 從暫存位置重新產生分散式認證 WAR 並部署它。如需詳細資訊，請參閱「Access Manager Post Installation Guide」中的「Deploying a Distributed Authentication UI Server WAR File」。

單一 WAR 配置程式在 DS 上失敗 (6562076)

部署為單一 WAR 的 Access Manager 在使用單一元件根尾碼 (例如 dc=example) 的 Directory Server 6 上配置會失敗，不過，使用多個元件根尾碼 (例如 dc=example,dc=com) 便可以成功配置。

解決方法：使用多個元件根尾碼，例如 dc=example,dc=com。

在相同主機上進行 AM 單一 WAR 的多伺服器配置會丟出異常 (6490150)

如果在相同主機上針對 Directory Server 配置 Access Manager 單一 WAR 的第二個實例，則會在更新組織別名時丟出異常。如果配置的第二個實例是在不同的主機上時，就不會發生此問題。

升級問題

升級問題的相關資訊包含在「Sun Java Enterprise System 5 Release Notes for UNIX」中的「Upgrade Issues」一節中。

相容性問題

• Access Manager 單次登入在通用 Web 用戶端上失敗 (6367058、6429573)

• 在 64 位元模式中執行的 Web Server 7.0 上發生 StackOverflowError (6449977)

• 舊有模式下核心認證模組中存有的不相容問題 (6305840)

• Delegated Administrator commadmin 公用程式未建立使用者 (6294603)

• Delegated Administrator commadmin 公用程式未建立組織 (6292104)

Access Manager 單次登入在通用 Web 用戶端上失敗 (6367058、6429573)

如果安裝了 Access Manager、Messaging Server 及 Calendar Server，將它們配置成共同運作，然後安裝 JES5 120955-01 修補程式，就會發生這個問題。使用者遇到登入錯誤。錯誤原因在於 Policy Agent 2.1 特性與 AMSDK 之間不相容。目前沒有解決方法。

在 64 位元模式中執行的 Web Server 7.0 上發生 StackOverflowError (6449977)

如果 Access Manager 是配置在使用 64 位元 JVM 的 Web Server 7.0 實例上，則使用者在存取主控台登入頁面時，會遇到 [伺服器錯誤] 訊息。Web Server 錯誤記錄包含 StackOverflowError 異常。

解決方法：遵循下列步驟來修改 Web Server 配置：

1. 以 Web Server 管理員的身份登入 Web Server 管理主控台。

2. 按一下 [編輯配置]。

   在 [平台] 欄位中選取 [64]，再按一下 [儲存]。

3. 按一下 [Java] 標籤，再按一下 [JVM 設定] 標籤。

   • 在 [選項] 下尋找最小堆疊儲存區大小項目 (例如：-Xms)。最小堆疊儲存區大小的值應該至少為 512m。例如，如果堆疊儲存區大小的值不等於或小於 -Xms512m，則請將這個值改成至少 -Xms512m。

   • 最大堆疊儲存區大小的值應該至少為 768m。如果最大堆疊儲存區大小不等於或小於 -Xmx768m，則請將這個值改成至少 -Xmx768m。

   • 使用 -Xss512k 或 -Xss768k 將 Java 堆疊大小設定為 512k 或 768k。在 Solaris Sparc 上您可以將它留為空白，以將它保留為 64 位元 JVM 之預設大小 (1024k)。

4. 按一下 [效能] 標籤，再按一下連結 [執行緒池設定]。

   將堆疊大小的值改為至少 261144，然後按一下 [儲存]。

5. 按一下螢幕右上角的 [部署擱置] 連結。

   在 [配置部署] 頁面中，按一下 [部署] 按鈕。

6. 在 [結果] 視窗中，按一下 [確定] 以重新啟動 Web Server 實例。

   在重新啟動 Web Server 之後，按一下 [結果] 視窗中的 [關閉]。

舊有模式下核心認證模組中存有的不相容問題 (6305840)

Access Manager 7.1 舊有模式的核心認證模組與 Access Manager 6 2005Q1 存有下列不相容問題：

• 在舊有模式下會將組織認證模組移除。

• [管理員認證配置] 與 [組織認證配置] 的表示已變更。在 Access Manager 7.1 主控台中，預設會選取下拉式清單中的 ldapService。在 Access Manager 6 2005Q1 主控台中，會提供 [編輯] 按鈕，預設不會選取 LDAP 模組。

解決方法：無。

Delegated Administrator commadmin 公用程式未建立使用者 (6294603)

Delegated Administrator commadmin 公用程式 (具 -S mail,cal 選項) 未在預設網域內建立使用者。

解決方法：若將 Access Manager 升級至版本 7.1，但未將 Delegated Administrator 升級，就會發生此問題。

若不打算升級 Delegated Administrator，請遵循下列步驟執行：

1. 在 UserCalendarService.xml 檔案中，將 mail、icssubcribed 與 icsfirstday 屬性標示為可選的而非必需的。依預設，此檔案位於 Solaris 系統上的 /opt/SUNWcomm/lib/services/ 目錄中。

2. 在 Access Manager 中，透過執行 amadmin 指令移除現存的 XML 檔案，如下所示：

   # ./amadmin -u amadmin -w password -r UserCalendarService

3. 在 Access Manager 中，加入更新後的 XML 檔案，如下所示：

   # ./amadmin -u amadmin -w password 
   -s /opt/SUNWcomm/lib/services/UserCalendarService.xml

4. 重新啟動 Access Manager Web 容器。

Delegated Administrator commadmin 公用程式未建立組織 (6292104)

Delegated Administrator commadmin 公用程式 (具 -S mail,cal 選項) 未建立組織。

解決方法：請參閱上一個問題之解決方法。

配置問題

• 無 Web 容器的 Access Manager SDK 安裝需要更新通知 URL (6491977)

• 變更密碼時，「密碼重設」服務報告通知錯誤 (6455079)

• 平台伺服器清單與 FQDN 別名屬性未更新 (6309259、6308649)

• 驗證服務中必需屬性的資料 (6308653)

• 於安全 WebLogic 8.1 實例中的部署解決方法 (6295863)

• amconfig 程序檔未更新範圍/DNS 別名及平台伺服器清單項目 (6284161)

• 配置狀態檔範本中的預設 Access Manager 模式為範圍 (6280844)

負載平衡器後方出現主控台重新導向不正確 (6480354)

如果 Access Manager 實例部署於負載平衡器後方，登入 Access Manager 主控台可能會重新導向至其中一個 Access Manager 實例，而非負載平衡器。瀏覽器中的 URL 也會變更為 Access Manager 實例。例如，如果您使用下列 URL 來登入主控台，就會發生此問題：

http://loadbalancer.example.com/amserver/realm

此重新導向在 [範圍] 模式與 [舊有] 模式部署中都可能發生。

針對此問題，有兩種解決方法：您可任選一種：

1. 使用下列任一 URL 來登入：

   http://loadbalancer/amserver/UI/Login

   http://loadbalancer/amserver

2. 在 AMConfig.properties 中，將 com.sun.identity.loginurl 特性設定為負載平衡器的名稱。這需要在負載平衡器後方的每個 Access Manager 實例上完成。

無 Web 容器的 Access Manager SDK 安裝需要更新通知 URL (6491977)

如果您執行 Java ES 5 安裝程式，並以 [立即配置] 選項來安裝無 Web 容器的 Access Manager SDK，則 AMConfig.properties 檔案中的 com.iplanet.am.notification.url 特性會設為 NOTIFICATION_URL 。如果您不要執行任何額外的 Web 容器配置，使用者不會收到遠端 Access Manager 伺服器的任何通知。

解決方法：重設此特性如下： com.iplanet.am.notification.url=""

變更密碼時，「密碼重設」服務報告通知錯誤 (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

解決方法：變更 /opt/SUNWam/locale/amPasswordResetModuleMsgs.properties 中的配置。

• 變更 [從] 位址。將 fromAddress.label=<Identity-Server> 變更為 fromAddress.label=<IdentityServer@myhost.company.com>

• 變更特性 lockOutEmailFrom，以確保封鎖通知使用正確的 [從] 位址。

平台伺服器清單與 FQDN 別名屬性未更新 (6309259、6308649)

在多重伺服器部署中，若將 Access Manager 安裝在第二個 (以及後續的) 伺服器上，平台伺服器清單與 FQDN 別名屬性不會更新。

解決方法：手動加入「範圍/DNS」別名與平台伺服器清單項目。如需步驟，請參閱「Sun Java System Access Manager 7.1 Postinstallation Guide」中的「Adding Additional Instances to the Platform Server List and Realm/DNS Aliases」。

驗證服務中必需屬性的資料 (6308653)

Access Manager 7.1 會強制服務 XML 檔案中的必需屬性必須具備預設值。

解決方法：如果服務的必需屬性沒有值，請為屬性加入值後，重新載入服務。

於安全 WebLogic 8.1 實例中的部署解決方法 (6295863)

若將 Access Manager 7.1 部署至安全 (啟用 SSL) BEA WebLogic 8.1 SP4 實例，則會在部署每個 Access Manager Web 應用程式時發生異常。

解決方法：依照以下步驟：

1. 套用 WebLogic 8.1 SP4 修補程式 JAR CR210310_81sp4.jar ，其可從 BEA 取得。

2. 在 /opt/SUNWam/bin/amwl81config 程序檔 (Solaris 系統) 或 /opt/sun/identity/bin/amwl81config 程序檔 (Linux 系統) 中，更新 doDeploy 函數與 undeploy_it 函數，將修補程式 JAR 的路徑前置於 wl8_classpath 之前 (此變數包含用來部署與解除部署 Access Manager Web 應用程式的 classpath)。

   尋找下列包含 wl8_classpath 的指令行：

   wl8_classpath= ...

3. 在步驟 2 中找到的指令行後加入下列指令行：

   wl8_classpath=path-to-CR210310_81sp4.jar:$wl8_classpath

amconfig 程序檔未更新範圍/DNS 別名及平台伺服器清單項目 (6284161)

在多重伺服器部署中，amconfig 程序檔未更新其他 Access Manager 實例的範圍/DNS 別名及平台伺服器清單項目。

解決方法：手動加入「範圍/DNS」別名與平台伺服器清單項目。如需步驟，請參閱「Sun Java System Access Manager 7.1 Postinstallation Guide」中的「Adding Additional Instances to the Platform Server List and Realm/DNS Aliases」。

配置狀態檔範本中的預設 Access Manager 模式為範圍 (6280844)

依預設，會啟用配置狀態檔範本中的 Access Manager 模式 (AM_REALM 變數)。

解決方法：若要在「舊有」模式下安裝或配置 Access Manager，請重設狀態檔中的變數：

AM_REALM = disabled

效能問題

在範圍模式中，建立新群組時會產生帶有 ACI 的群組管理員，而這些 ACI 永遠不會被使用 (6485695)

如果 Access Manager 安裝於範圍模式下，則不論何時建立新群組，Access Manager 都會動態建立一個群組管理員，且該管理員具有管理群組所需的 ACI。在範圍模式中，不會使用這些群組管理員 ACI。然而，Directory Server 處理尾碼下的項目時，仍會評估它們，這樣可能會降低 Access Manager 的效能，特別是在部署建立了大量群組時。

解決方法：針對此問題的解決方法包含兩個部分：

• 防止 Access Manager 在建立新群組時建立群組管理員與對應的 ACI

• 從 Directory Server 移除所有現存的 ACI

防止建立群組管理員 ACI

下列程序會防止 Access Manager 在建立新群組時，建立群組管理員與對應的 ACI。

此程序會永遠防止在建立新群組時，建立群組管理員與對應的 ACI。僅在此行為適用於您的特定部署時，才使用此程序。

1. 備份 amAdminConsole.xml 檔案。此檔案位於下列目錄中，視您的平台而定：

   • Solaris 系統：/etc/opt/SUNWam/config/xml

   • Linux 與 HP-UX 系統：/etc/opt/sun/identity/config/xml

   • Windows 系統：javaes-install-dir\identity\config\xml

     javaes-install-dir 代表 Java ES 5 安裝目錄。預設值是 C:\Program Files\Sun\JavaES5。

2. 在 amAdminConsole.xml 檔案中，移除下列顯示於註釋行間的群組管理員項目：

   <AttributeSchema name="iplanet-am-admin-console-dynamic-aci-list"
       type="list"
       syntax="string"
       i18nKey="g111">
       <DefaultValues>
   ...
   # Beginning of entry to delete
                   <Value>Group Admin|Group Admin Description|ORGANIZATION:aci: 
   (target="ldap:///GROUPNAME")(targetattr = "*") 
   (version 3.0; acl "Group and people container admin role"; 
   allow (all) roledn = "ldap:///ROLENAME";)##ORGANIZATION:aci: 
   (target="ldap:///ORGANIZATION")
   (targetfilter=(&amp;FILTER(!(|(nsroledn=cn=Top-level Admin Role,dc=iplanet,dc=com)
   (nsroledn=cn=Top-level Help Desk Admin Role,dc=iplanet,dc=com)
   (nsroledn=cn=Top-level Policy Admin Role,dc=iplanet,dc=com)
   (nsroledn=cn=Organization Admin Role,ORGANIZATION)
   (nsroledn=cn=Container Admin Role,ORGANIZATION)
   (nsroledn=cn=Organization Policy Admin Role,ORGANIZATION)))))
   (targetattr != "iplanet-am-web-agent-access-allow-list || 
   iplanet-am-web-agent-access-not-enforced-list|| 
   iplanet-am-domain-url-access-allow || 
   iplanet-am-web-agent-access-deny-list ||nsroledn")
   (version 3.0; acl "Group admin's right to the members"; allow (read,write,search) 
   roledn = "ldap:///ROLENAME";)</Value>
   # End of entry to delete
   ...
       </DefaultValues>
   </AttributeSchema>

3. 使用 amadmin 從 Access Manager 刪除 Admin Console 服務。例如，在 Solaris 系統上：

   # cd /opt/SUNWam/bin
   # ./amadmin -u amadmin -w amadmin_password 
   --deleteService iPlanetAMAdminConsoleService

4. 使用 amadmin 將 Admin Console 服務從步驟 2 中已編輯的 amAdminConsole.xml 檔案重新載入至 Access Manager 。例如：

   # ./amadmin -u amadmin -w amadmin_password 
   -t /etc/opt/SUNWam/config/xml/amAdminConsole.xml

5. 重新啟動 Access Manager Web 容器。(如果您如下一程序所描述，規劃從目錄伺服器刪除 ACI，請在完成該程序後，等候並重新啟動 Web 容器。)

移除現存的群組管理員 ACI

下列程序使用 ldapsearch 與 ldapmodify 公用程式來搜尋與移除群組管理員 ACI。如果您的部署是使用 Directory Server 6.0，則也可以使用 Directory Server Control Center (DSCC) 或 dsconf 指令來實現這些功能。如需詳細資訊，請參閱 Directory Server 6.0 文件：

http://docs.sun.com/app/docs/coll/1224.1 及 http://docs.sun.com/app/docs/coll/1632.1

下列程序會移除已經存在於 Directory Server 中的群組管理員 ACI。

1. 建立 LDIF 檔案以配合 ldapmodify 使用來移除群組管理員 ACI。若要找到這些 ACI，請使用 ldapsearch (或您偏好的目錄搜尋工具)。

   例如，在名為 Remove_Group_ACIs.ldif 的 LDIF 檔案範例中的下列項目會移除群組名稱為 New Group 的 ACI：

   dn: ROOT_SUFFIX
   changetype: modify
   delete: aci
   aci: (target="ldap:///cn=New Group,ou=Groups,o=isp")(targetattr = "*") 
   (version 3.0; acl "Group and people container admin role"; allow (all) 
   roledn = "ldap:///cn=cn=New Group_ou=Groups_o=isp,o=isp";)
   
   dn: ROOT_SUFFIX
   changetype: modify
   delete: aci
   aci: (target="ldap:///ou=People,o=isp")(targetattr="nsroledn")
   (targattrfilters="add=nsroledn:(!(nsroledn=*)),
   del=nsroledn:(!(nsroledn=*))") (version 3.0; 
   acl "Group admin's right to add user to people container"; allow (add) 
   roledn = "ldap:///cn=cn=New Group_ou=Groups_o=isp,o=isp";)
   
   dn: ROOT_SUFFIX
   changetype: modify
   delete: aci
   aci: (target="ldap:///o=isp")
   (targetfilter=(&(|(memberof=*cn=New Group,ou=Groups,o=isp)
   (iplanet-am-static-group-dn=*cn=New Group,ou=Groups,o=isp))
   (!(|(nsroledn=cn=Top-level Admin Role,o=isp)
   (nsroledn=cn=Top-level Help Desk Admin Role,o=isp)
   (nsroledn=cn=Top-level Policy Admin Role,o=isp)
   (nsroledn=cn=Organization Admin Role,o=isp)(
   nsroledn=cn=Container Admin Role,o=isp)
   (nsroledn=cn=Organization Policy Admin Role,o=isp)))))
   (targetattr != "iplanet-am-web-agent-access-allow-list || 
   iplanet-am-web-agent-access-not-enforced-list || 
   iplanet-am-domain-url-access-allow || 
   iplanet-am-web-agent-access-deny-list ||nsroledn")
   (version 3.0; acl "Group admin's right to the members"; 
   allow (read,write,search) 
   roledn = "ldap:///cn=cn=New Group_ou=Groups_o=isp,o=isp";) 
   aci: (target="ldap:///o=isp")(targetattr="*")
   (version 3.0; acl "S1IS special dsame user rights for all under the root suffix"; 
   allow (all) userdn = "ldap: ///cn=dsameuser,ou=DSAME Users,o=isp"; )

2. 使用 ldapmodify 配合前一個步驟中的 LDIF 檔案來從 Directory Server 中移除群組 ACI。例如：

   # ldapmodify -h ds-host -p 389 -D "cn=Directory Manager" 
   -w ds-bind-password -f Remove_Group_ACIs.ldif

3. 重新啟動 Access Manager Web 容器。

Access Manager 主控台問題

• 新的 Access Manager 主控台無法設定 CoS 範本優先權 (6309262)

• 加入 Portal Server 相關服務時出現舊的主控台 (6293299)

• 達到資源限制後，主控台未傳回 Directory Server 設定的結果 (6239724)

• 於資料遷移之後新增 ContainerDefaultTemplateRole 屬性 (4677779)

新的 Access Manager 主控台無法設定 CoS 範本優先權 (6309262)

新的 Access Manager 7.1 主控台無法設定或修改服務類別 (Class of Service，CoS) 範本優先權。

解決方法：登入 Access Manager 6 2005Q1 主控台以設定或修改 CoS 範本優先權。

加入 Portal Server 相關服務時出現舊的主控台 (6293299)

Portal Server 與 Access Manager 安裝於同一伺服器上。在「舊有」模式下安裝 Access Manager 後，使用 /amserver 登入新的 Access Manager 主控台。在您選擇現存使用者後嘗試加入服務 (如 NetFile 或 Netlet) 時，會突然出現舊的 Access Manager 主控台 (/amconsle)。

解決方法：無。目前版本的 Portal Server 必須搭配 Access Manager 6 2005Q1 主控台使用。

達到資源限制後，主控台未傳回 Directory Server 設定的結果 (6239724)

使用現存的 DIT 選項安裝 Directory Server ，然後安裝 Access Manager。登入 Access Manager 主控台並建立群組。編輯群組中的使用者。例如，使用篩選器 uid=*999* 增加使用者。產生的清單方塊是空的，但主控台未顯示任何錯誤、資訊或警告訊息。

解決方法：群組成員不得大於 Directory Server 搜尋大小限制。如果群組成員大於搜尋大小限制，請據此變更搜尋大小限制。

於資料遷移之後新增 ContainerDefaultTemplateRole 屬性 (4677779)

在 [舊有] 模式中，對不是在 Access Manager 中建立的組織，不會顯示該組織的使用者角色。在除錯模式中，會顯示下列訊息：

錯誤：DesktopServlet.handleException()
com.iplanet.portalserver.desktop.DesktopException:
DesktopServlet.doGetPost(): 無權限可執行桌面

此錯誤在執行 Java ES 安裝程式遷移程序檔時會更明顯。當組織是由現存目錄資訊樹 (Directory Information Tree, DIT) 或其他來源中遷移出來，ContainerDefaultTemplateRole 屬性不會自動新增至組織中。

解決方法：使用 [Directory Server] 主控台來複製其他 Access Manager 組織的 ContainerDefaultTemplateRole 屬性，然後將其新增至受影響的組織。

指令行問題

組織管理員角色無法使用 amadmin 指令行公用程式建立新的使用者 (6480776)

因為錯誤的登入權限，指定了組織管理員角色的管理員無法使用 amadmin 指令行公用程式建立新的使用者。

解決方法：組織管理員和頂層管理員均可設定權限。請透過管理主控台來進行設定：

1. 移至組織管理員所屬的組織。

2. 按一下 [權限] 標籤。

3. 按一下 [組織管理員角色] 連結。

4. 選取 [對所有記錄檔的讀取和寫入存取] 或 [對所有記錄檔的寫入存取]。

5. 按一下 [儲存]。

SDK 與用戶端問題

• 伺服器重新啟動後，用戶端沒有收到通知 (6309161)

• 服務模式變更後，SDK 用戶端必須重新啟動 (6292616)

伺服器重新啟動後，用戶端沒有收到通知 (6309161)

使用用戶端 SDK (amclientsdk.jar) 撰寫的應用程式在伺服器要重新啟動時，不會收到通知。

解決方法：無。

服務模式變更後，SDK 用戶端必須重新啟動 (6292616)

若修改了任何服務模式，ServiceSchema.getGlobalSchema 會傳回舊的模式而非新的模式。

解決方法：服務模式變更後重新啟動用戶端。

這個問題會在修補程式 1 中修正。

認證問題

• 當應用程式使用者的權限不足時，「分散式認證 UI」伺服器效能降低 (6470055)

• 在舊有 (相容) 模式下，Access Manager 統計服務的預設配置不相容 (6286628)

• 頂層組織中命名屬性的屬性唯一性遭破壞 (6204537)

當應用程式使用者的權限不足時，「分散式認證 UI」伺服器效能降低 (6470055)

使用預設的應用程式使用者來部署「分散式認證 UI」伺服器時，效能會因為預設應用程式使用者的權限有限而大幅降低。

解決方法：使用適當的權限建立新使用者。

遵循下列步驟使用適當的 ACI 建立新使用者：

1. 在 Access Manager 主控台中建立新使用者。例如，建立稱為 AuthUIuser 的使用者。

2. 在 Directory Server 主控台中加入下列 ACI。

   dn:ou=1.0,ou=SunAMClientData,ou=ClientData,<ROOT_SUFFIX> changetype:modifyadd:aci aci: (target="ldap:///ou=1.0,ou=SunAMClientData,ou=ClientData,<ROOT_SUFFIX>") (targetattr = "*"(version 3.0; acl "SunAM client data anonymous access"; allow (read, search, compare) userdn = "ldap:///<AuthUIuser's DN>";)

   請注意，userdn 是設為「ldap:///<AuthUIuser's DN>」。

3. 請參閱「Sun Java System Access Manager 7.1 Postinstallation Guide」中的「To Install and Configure a Distributed Authentication UI Server」，以取得關於編輯 amsilent 檔案和執行 amadmin 指令的指示。

4. 在 amsilent 檔案中，設定下列特性：

   APPLICATION_USER

   輸入 AuthUIuser。

   APPLICATION_PASSWD

   輸入 AuthUIuser 的密碼。

5. 儲存檔案。

6. 使用新的配置檔案執行 amconfig 程序檔。例如，在 Access Manager 安裝於預設目錄的 Solaris 系統上：

   # cd /opt/SUNWam/bin

   # ./amconfig -s ./DistAuth_config

7. 在「分散式認證 UI」伺服器上重新啟動 Web 容器。

在舊有 (相容) 模式下，Access Manager 統計服務的預設配置不相容 (6286628)

在舊有模式下安裝 Access Manager 後，「統計服務」的預設配置已變更：

• 依預設，會開啟服務 (com.iplanet.services.stats.state=file )。之前它是關閉的。

• 預設間隔 (com.iplanet.am.stats.interval) 已從 3600 變更為 60。

• 預設的 stats 目錄 (com.iplanet.services.stats.directory ) 已從 /var/opt/SUNWam/debug 變更為 /var/opt/SUNWam/stats。

解決方法：無。

頂層組織中命名屬性的屬性唯一性遭破壞 (6204537)

安裝 Access Manager 之後，以 amadmin 身份登入，並將 o、sunPreferredDomain、associatedDomain、sunOrganizationAlias、uid 與 mail 屬性加入 [唯一的屬性清單]。若要建立兩個名稱相同的新組織，作業會失敗，但 Access Manager 會顯示 [組織已存在] 訊息，而不是按預期顯示 [違反屬性唯一性] 訊息。

解決方法：無。忽略不正確的訊息。Access Manager 運作正常。

階段作業與 SSO 問題

• 負載平衡器之 SSL 終止時，系統會建立無效的服務主機名稱 (6245660)

• 搭配協力廠商的 Web 容器使用 HttpSession

負載平衡器之 SSL 終止時，系統會建立無效的服務主機名稱 (6245660)

如果部署 Access Manager 的 Web 容器為 Web Server，其負載平衡器終止了 SSL，則用戶端將不會被導向至正確的 Web Server 頁面。按一下 Access Manager 主控台中的 [階段作業] 標籤會傳回錯誤訊息，因為主機無效。

解決方法：在下列範例中，Web Server 會使用連接埠 3030 偵聽。負載平衡器則使用連接埠 80 偵聽，並將請求重新導向至 Web Server。

在 web-server-instance-name/config/server.xml 檔案中，視您使用的 Web Server 版本而定，編輯 servername 屬性以指向負載平衡器。

針對 Web Server 6.1 Service Pack (SP) 版本，以如下方式編輯 servername 屬性：

<LS id="ls1" port="3030" servername="loadbalancer.example.com:80" 
defaultvs="https-sample" security="false" ip="any" blocking="false" 
acceptorthreads="1"/>

Web Server 6.1 SP2 (或更新版本) 可將通訊協定從 http 切換為 https，或從 https 切換為 http。因此，請以如下方式編輯 servername：

<LS id="ls1" port="3030" 
servername="https://loadbalancer.example.com:443" defaultvs="https-sample" 
security="false" ip="any" blocking="false" acceptorthreads="1"/>

搭配協力廠商的 Web 容器使用 HttpSession

維護認證階段作業的預設方法是「內部階段作業」，而不是 HttpSession。3 分鐘的預設無效階段作業最大時間值已經足夠。amtune 程序檔會將 Web Server 或 Application Server 的該值設為一分鐘。然而，若您是使用協力廠商 Web 容器 (IBM WebSphere 或 BEA WebLogic Server) 和選用的 HttpSession，可能需要限制 Web 容器的最大 HttpSession 時間限制以避免效能發生問題。

策略問題

• 刪除策略配置服務中的動態屬性會導致策略編輯發生問題 (6299074)

刪除策略配置服務中的動態屬性會導致策略編輯發生問題 (6299074)

刪除 [策略配置服務] 中的動態屬性會導致編輯以下方案的策略時發生問題：

1. 在 [策略配置服務] 中建立兩個動態屬性。

2. 建立策略並在回應提供者中選取動態屬性 (來自步驟 1)。

3. 移除 [策略配置服務] 中的動態屬性，然後再建立兩個屬性。

4. 試著編輯於步驟 2 建立的策略。

結果為：[錯誤：設定了無效的動態特性。]依預設，清單中不會顯示任何策略。完成搜尋後，策略會顯示出來，但您無法編輯或刪除現存策略，或建立新策略。

解決方法：從 [策略配置服務] 移除動態屬性之前，請先從策略移除對這些屬性的參照。

伺服器啟動問題

• Access Manager 啟動時發生除錯錯誤 (6309274、6308646)

Access Manager 啟動時發生除錯錯誤 (6309274、6308646)

Access Manager 7.1 啟動時傳回 amDelegation 與 amProfile 除錯檔案中的除錯錯誤：

• amDelegation：無法取得委派的外掛程式實例

• amProfile：出現委派異常

解決方法：無。您可忽略這些訊息。

AMSDK 問題

• 執行 AMIdentity.modifyService 時出現錯誤 (6506448)

• 群組成員沒有顯示在選取的清單中 (6459598)

• Access Manager 登入 URL 傳回訊息 [找不到這樣的組織] (6430874)

• 使用 amadmin 時無法從 Access Manager 建立子組織 (5001850)

執行 AMIdentity.modifyService 時出現錯誤 (6506448)

使用 AMIdentity.modifyService 在範圍中設定桌面服務動態屬性時，Access Manager 會傳回空指標異常。

解決方法：將以下特性增加至 AMConfig.properties，再重新啟動伺服器:

com.sun.am.ldap.connnection.idle.seconds=7200

群組成員沒有顯示在選取的清單中 (6459598)

在下列情況下會發生這個問題：

1. 使用下列範圍配置來定義範圍：

   • 頂層範圍是 amroot。子範圍是 example.com。

   • 子範圍 example.com 有兩個資料存放區：exampleDB 及 exampleadminDB。

   • 資料存放區 exampleDB 包含開頭為 dc=example,dc=com 的所有使用者。支援的 LDAPv3 作業設為 user=read,write,create,delete,service。

   • 資料存放區 exampleadminDB 包含範圍的管理群組。管理群組是 DN: cn=example.com Realm Administrators,ou=Groups,dc=example,dc=com。這個群組有個單一成員 scarter。支援的 LDAPv3 作業設為 group=read,write,create,delete。

2. 按一下 [主體] 標籤，再按一下 [群組]，然後按一下 example.com Realm Administrators 的項目。

3. 按一下 [使用者] 標籤。

在 exampleDB 資料存放區中的所有使用者都會顯示為可用，但 scarter 不會顯示在 [選取的] 欄位中。

解決方法：將作業 user=read 加入 exampleadminDB 資料存放區中支援的 LDAPv3 作業。

Access Manager 登入 URL 傳回訊息 [找不到這樣的組織] (6430874)

這個問題原因可能是在完全合格網域名稱 (Fully Qualified Domain Name, FQDN) 中使用了大小寫混合 (同時包括大寫與小寫) 的字元。

範例：HostName.PRC.Example.COM

解決方法：在安裝之後，不要使用預設的 Access Manager 登入 URL。而是在登入 URL 中包括預設組織的 LDAP 位置。例如：

http://HostName.PRC.Example.COM/amserver/UI/Login?org=dc=PRC,dc=Example,dc=COM

一旦順利登入到 Access Manager 之後，即可免除每次登入 Access Manager 都要輸入使用者組織完整路徑的需要。依照以下步驟：

1. 進入 [範圍] 模式下的 [範圍] 標籤，或進入 [舊有] 模式下的 [組織] 標籤。

2. 按一下預設的範圍或組織名稱。

   在此範例中，按一下 prc。

3. 將範圍/DNS 別名值中的所有大寫字元改為小寫字元。

   在此範例中，將所有小寫值 hostname.prc.example.com 加入清單，然後從清單中移除混合大小寫的 HostName.PRC.Example.COM 值。

4. 按一下 [儲存]，並登出 Access Manager 主控台。

您現在可以使用下列任何一個 URL 登入：

• http://hostname.PRC.Example.COM/amserver/UI/Login

• http://hostname.PRC.Example.COM/amserver

• http://hostname.PRC.Example.COM/amserver/console

使用 amadmin 時無法從 Access Manager 建立子組織 (5001850)

在兩個 Directory Server 之間啟用多個主伺服器複製並嘗試使用 amadmin 公用程式建立子組織時，就會發生這個問題。

解決方法：在這兩個 Directory Server 中，將 nsslapd-lookthroughlimit 特性設為 -1。

SSL 問題

• 當 SSL 憑證過期時，amconfig 程序檔失敗。(6488777)

當 SSL 憑證過期時，amconfig 程序檔失敗。(6488777)

如果 Access Manager 容器是在 SSL 模式中執行，而且容器的 SSL 憑證已過期，則 amconfig會失敗，並可能導致類別路徑毀損。

解決方法：如果您使用了過期憑證來執行 amconfig，且類別路徑已毀損，則應該先取得有效的 SSL 憑證。復原為類別路徑未毀損的原始 domain.xml 檔案，或該檔案的副本。然後重新執行 amconfig 指令：

/opt/SUNWam/bin/amconfig -s $PWD/amsamplesilent

範例問題

• Clientsdk 範例目錄包含不要的 makefile (6490071)

Clientsdk 範例目錄包含不要的 makefile (6490071)

範例檔案包含於用戶端 SDK 中。這些範例示範如何撰寫獨立程式，以及如何撰寫 Web 應用程式。這些範例位於您產生 Makefile.clientsdk 的目錄下，以及下列子目錄中：

.../clientsdk-samples/

.../clientsdk-webapps/

Clientsdk-samples 包括認證、記錄、策略和 SAML 獨立程式的範例。Clientsdk-webapps 包括使用者管理、服務管理和策略程式的範例。每個範例都有 Readme.html 檔案，其中包含編譯和執行範例程式的指示。

為了編譯範例，makefile 應在對應的子目錄中執行。頂層 makefile 不會編譯子目錄中的範例。

Linux OS 問題

• 在 Application Server 上執行 Access Manager 時發生 JVM 問題 (6223676)

在 Application Server 上執行 Access Manager 時發生 JVM 問題 (6223676)

若您是在 Red Hat Linux 上執行 Application Server 8.1，Red Hat OS 為 Application Server 所建立之執行緒的堆疊大小為 10 MB，當 Access Manager 使用者階段作業達到 200 時，這會造成 JVM 資源問題。

解決方法：在您啟動 Application Server 之前先執行 ulimit 指令，將 Red Hat OS 作業堆疊大小設為較小的值，如 2048，甚至是 256 KB。在您將用來啟動 Application Server 的同一主控台上執行 ulimit 指令。例如：

# ulimit -s 256;

Windows 與 HP-UX 問題

• 在 zh_TW 和 es 語言環境上安裝時，Access Manager 自動配置失敗 (6515043)

• 完整安裝 JES 時，HP-UX 需要 AM 的 gettext 二進位 (6497926)

在 zh_TW 和 es 語言環境上安裝時，Access Manager 自動配置失敗 (6515043)

解決方法：在 HP-UX 平台的 zh_TW 和 es 語言環境中，Access Manager 只能在「以後配置」模式中進行配置。啟動 JavaES 安裝程式，安裝 Access Manager 產品並結束 JavaES 安裝程式。接著呼叫 Access Manager 配置程式，如下所示：

1. LANG=C

2. export LANG

3. 編輯 accessmanager-base/bin/amsamplesilent 檔案

4. 執行 accessmanager-base/bin/amconfig -s amsamplesilent

完整安裝 JES 時，HP-UX 需要 AM 的 gettext 二進位 (6497926)

目前沒有此問題的解決方法。

聯合與 SAML 問題

• 聯合過程中發生登出錯誤 (6291744)

聯合過程中發生登出錯誤 (6291744)

在範圍模式下，若您聯合識別提供者 (IDP) 與服務提供者 (SP) 上的使用者帳號，然後在終止聯合後登出，會發生以下錯誤：[錯誤：找不到子組織。]

解決方法：無。

全球化 (g11n) 問題

• 在 zh 語言環境中，管理主控台元件以英文顯示 (6470543)

• 「目前的值」和「新的值」在主控台中顯示錯誤 (6476672)

• 必須根據英文習慣指定策略條件日期 (6390856)

• 在「用戶端偵測」中無法移除 UTF-8 (5028779)

• 記錄檔中多位元組字元以問號顯示 (5014120)

在 zh 語言環境中，管理主控台元件以英文顯示 (6470543)

設定瀏覽器的語言環境為 zh 時，管理主控台元件以英文顯示，例如 [Version] (版本)、[Help] (說明) 和 [Logout] (登出) 按鈕。

解決方法：將瀏覽器語言環境設定設定為 zh-cn，而非 zh。

「目前的值」和「新的值」在主控台中顯示錯誤 (6476672)

在主控台的本土化版本中，「目前的值」和「新的值」兩個屬性的標籤分別錯誤顯示為 label.current.value 和 label.new.value。

必須根據英文習慣指定策略條件日期 (6390856)

在中文語言環境下的策略條件日期格式標籤不會根據中文習慣顯示。標籤所使用的日期格式類似英文日期格式。相關欄位也接受英文日期格式值。

解決方法：對於每一個欄位，請遵循在欄位標籤中指定的日期格式範例。

在「用戶端偵測」中無法移除 UTF-8 (5028779)

「用戶端偵測」功能無法正常運作。在 Access Manager 7.1 主控台中所做的變更未自動傳遞至瀏覽器。

解決方法：有二種解決方法：

• 在 [用戶端偵測] 區段中進行變更後，重新啟動 Access Manager Web 容器。

  或

• 在 Access Manager 主控台中依照以下步驟執行：

  1. 按一下 [配置] 標籤下的 [用戶端偵測]。

  2. 按一下 genericHTML 的 [編輯] 連結。

  3. 按一下 HTML 標籤下的 genericHTML 連結。

  4. 在字元集清單中輸入下列項目：UTF-8;q=0.5 (請確定 UTF-8 q 因子小於語言環境中的其他字元集。)

  5. 儲存、登出後再登入一次。

記錄檔中多位元組字元以問號顯示 (5014120)

/var/opt/SUNWam/logs 目錄下的記錄檔中，多位元組訊息以問號 (?) 顯示。記錄檔為原生編碼且不一定是 UTF-8 格式。在特定語言環境啟動 Web 容器實例時，該語言環境的記錄檔將使用原生編碼格式。若切換至其他語言環境並重新啟動 Web 容器實例，後續的訊息將以該語言環境的原生編碼呈現，但使用先前編碼方式的訊息將以問號顯示。

解決方法：確定每次均使用同一種原生編碼啟動任何 Web 容器實例。

文件問題

• 記錄可支援 LDAPv3 外掛程式的角色和已篩選角色 (6365196)

• 記錄 AMConfig.properties 檔案中未使用的特性 (6344530)

• 記錄如何啟用 XML 加密 (6275563)

記錄可支援 LDAPv3 外掛程式的角色和已篩選角色 (6365196)

若資料是儲存在 Sun Java System Directory Server 中，套用修補程式後，您可為 LDAPv3 外掛程式配置角色和已篩選角色 (可修正問題 ID 6349959)。在 Access Manager 7.1 管理主控台中，在 [LDAPv3 外掛程式支援的類型和作業] 欄位的 LDAPv3 配置中，輸入下列值：

role: read,edit,create,delete
filteredrole: read,edit,create,delete

您可輸入上述項目之一或二者皆輸入，依您計劃在 LDAPv3 配置中使用的角色和已篩選角色而定。

記錄 AMConfig.properties 檔案中未使用的特性 (6344530)

AMConfig.properties 檔案中未使用下列特性：

com.iplanet.am.directory.host
com.iplanet.am.directory.port

記錄如何啟用 XML 加密 (6275563)

若要啟用 Access Manager 或 Federation Manager 的 XML 加密 (使用 Bouncy Castle JAR 檔來產生傳輸的金鑰)，依下列步驟操作：

1. 若您使用的 JDK 版本低於 JDK 1.5，從 Bouncy Castle 網站 (http://www.bouncycastle.org/) 下載 Bouncy Castle JCE 提供者。例如，若使用 JDK 1.4，則下載 bcprov-jdk14-131.jar 檔。

2. 若您已依前述步驟下載 JAR 檔，將檔案複製到 jdk_root/jre/lib/ext 目錄中。

3. 有關各國的 JDK 版本資訊，從 Sun 網站 (http://java.sun.com) 下載針對您的 JDK 版本的 JCE Unlimited Strength Jurisdiction Policy Files。若使用 IBM WebSphere，前往相應的 IBM 網站下載所需的檔案。

4. 將下載的 US_export_policy.jar 和 local_policy.jar 檔案複製到 jdk_root/jre/lib/security 目錄。

5. 如果您使用的 JDK 版本低於 JDK 1.5，請編輯 jdk_root/jre/lib/security/java.security 檔案，並加入 Bouncy Castle 做為提供者之一。例如：

   security.provider.6=org.bouncycastle.jce.provider.BouncyCastleProvider

6. 在 AMConfig.properties 檔案中將下列特性設定為 true：

   com.sun.identity.jss.donotInstallAtHighestPriority=true

7. 重新啟動 Access Manager Web 容器。

如需更多資訊，請參考問題 ID 5110285 (XML 加密需有 Bouncy Castle JAR 檔)。