本節說明此版本發行時的已知問題和解決方法 (如有提供)。
下列部署方案造成了此問題:
server-1:Java ES 2004Q2:Directory Server
server-2:Java ES 2004Q2:Application Server、Access Manager 及 Portal Server
server-3:Java ES 2004Q2:Calendar Server 與 Messaging Server
server-4:Java ES 2005Q4:Application Server、Instant Messaging 及 Access Manager SDK
於 server-4 上執行 imconfig 公用程式配置 Instant Messaging 時,配置不成功。Access Manager 7 2005Q4 SDK 由 server-4上的 Instant Messaging (IM) 使用時,其與 Java ES 2004Q2 版本不相容。
解決方法:理論上,Access Manager 伺服器版本應與 Access Manager SDK 的版本相同。如需更多資訊,請參閱「Sun Java Enterprise System 2005Q4 Upgrade Guide」。
Access Manager 7 2005Q4 舊有模式自 Access Manager 6 2005Q1 開始,於核心認證模組中存有下列不相容問題:
在舊有模式下會將組織認證模組移除。
[管理員認證配置] 與 [組織認證配置] 的表示已變更。在 Access Manager 7 2005Q4 主控台中,預設會選取下拉式清單中的 ldapService。在 Access Manager 6 2005Q1 主控台中,會提供 [編輯] 按鈕,預設不會選取 LDAP 模組。
解決方法:無。
在 Access Manager 主控台中,於「範圍」模式下建立一個代理程式。若登出後使用代理程式名稱再次登入,Access Manager 會傳回錯誤訊息,因為代理程式不具存取該範圍的權限。
解決方法:修改權限以允許代理程式的讀取/寫入存取。
Delegated Administrator commadmin 公用程式 (具 -S mail,cal 選項) 未在預設網域內建立使用者。
解決方法:若將 Access Manager 升級至版本 7 2005Q4,但未將 Delegated Administrator 升級,就會發生此問題。如需升級 Delegated Administrator 的資訊,請參閱「Sun Java Enterprise System 2005Q4 Upgrade Guide」。
若不打算升級 Delegated Administrator,請遵循下列步驟執行:
在 UserCalendarService.xml 檔案中,將 mail、icssubcribed 及 icsfirstday 屬性標示為可選的而非必需的。依預設,此檔案位於 Solaris 系統上的 /opt/SUNWcomm/lib/services/ 目錄中。
在 Access Manager 中,透過執行 amadmin 指令移除現有的 XML 檔案,如下所示:
# ./amadmin -u amadmin -w password -r UserCalendarService
在 Access Manager 中,加入更新後的 XML 檔案,如下所示:
# ./amadmin -u amadmin -w password -s /opt/SUNWcomm/lib/services/UserCalendarService.xml
重新啟動 Access Manager Web 容器。
Delegated Administrator commadmin 公用程式 (具 -S mail,cal 選項) 未建立組織。
解決方法:請參閱上一個問題之解決方法。
要將 Access Manager 安裝於現有 DIT,必須重建 Directory Server 索引 (6268096)
將 Access Manager 和 Directory Server 安裝在不同機器上時,認證服務沒有初始化 (6229897)
在您套用修補程式 1 後,所有使用者皆有讀取 /tmp/amsilent 檔案的權限。
解決方法:在您套用修補程式後,重設檔案的權限,只允許 Access Manager 管理員的讀取權限。
使用容器配置 (DEPLOY_LEVEL=4) 執行 SDK 安裝時,通知 URL 不正確。
解決方法:
在 AMConfig.properties 檔案中設定下列特性:
com.iplanet.am.notification.url= protocol://fqdn:port/amserver/servlet/com.iplanet.services.comm.client. PLLNotificationServlet
重新啟動 Access Manager 以使新值生效。
Access Manager classpath 參照 2005 年 7 月 27 日到期的 Java Cryptography Extension (JCE) 1.2.1 套裝模組 (簽署憑證)。
解決方法:無。雖然在 classpath 中存在套裝模組參照,Access Manager 並不會使用此套裝模組。
為了改善搜尋效能,Directory Server 有數個新增的索引。
解決方法:使用現有的「目錄資訊樹 (DIT)」安裝 Access Manager 後,請執行 db2index.pl 程序檔重建 Directory Server 索引。例如:
# ./db2index.pl -D "cn=Directory Manager" -w password -n userRoot
db2index.pl 程序檔可從 DS-install-directory/slapd-hostname/ 目錄中取得。
在無訊息安裝配置檔中指定了非超級使用者時,除錯、記錄檔及啟動目錄的權限未正確設定。
解決方法:變更這些目錄的權限以讓非超級使用者可以存取。
雖然 classpath 和其他 Access Manager Web 容器環境變數會在安裝過程中更新,安裝程序不會重新啟動 Web 容器。若您在安裝後但 Web 容器尚未重新啟動之前試著登入 Access Manager,會傳回下列錯誤:
認證服務沒有初始化。請與您的系統管理員連絡。
解決方法:請先重新啟動 Web 容器,再登入 Access Manager。登入前,您還必須先執行 Directory Server。
Java ES 安裝程式未針對現有目錄伺服器安裝 (DIRECTORY_MODE=2) 加入平台項目。
解決方法:手動加入「範圍/DNS」別名與平台伺服器清單項目。如需有關步驟,請參閱「Sun Java System Access Manager 7 2005Q4 Deployment Planning Guide」中的「Adding Additional Instances to the Platform Server List and Realm/DNS Aliases」。
若您正將 Access Manager 升級到 Access Manager 7 2005Q4, ampre70upgrade 程序檔不會移除您系統上任何的 Access Manager 本土化套裝軟體。
解決方法:在您升級為 Access Manager 7 2005Q4 之前,使用 pkgrm 指令手動移除安裝在您系統上的所有本土化 Access Manager 套裝軟體。
Access Manager 與 Application Server 升級至 Java ES 2005Q4 版本後,Access Manager AMConfig.properties 檔案中的 Application Server 版本是舊的。
解決方法:執行 Delegated Administrator 配置程式 (config-commda) 之前,請先變更 AMConfig.properties 檔案中的下列特性:
com.sun.identity.webcontainer=IAS8.1
升級 Access Manager 之後,節點代理程式 server.policy 檔案未更新。
解決方法:以下列檔案取代節點代理程式的 server.policy 檔案:
/var/opt/SUNWappserver/domains/domain1/config/server.policy
將 Access Manager 從版本 2005Q1 升級至版本 2005Q4 後,若您試圖將一個條件加入策略,在 [策略條件] 清單中並未將 [階段作業特性條件] 做為一個選項顯示出來。
解決方法:選取對應範圍的策略配置服務範本中之 [階段作業特性條件] 類型。
將 Access Manager 從版本 2005Q1 升級至版本 2005Q4 後,在策略主體清單中未將新加入的策略主體類型 [識別主體] 做為一個選項顯示出來。
解決方法:在策略配置服務範本中選取 [識別主體] 類型做為預設的主體類型。
Access Manager 從 Java ES 2004Q2 升級至 Java ES 2005Q4 期間,從 Java ES 2004Q2 升級至 Java ES 2005Q1 失敗。Access Manager 已安裝在 Application Server 上,亦從 Java ES 2004Q2 升級至 Java ES 2005Q4。 domain.xml 檔案中的 classpath 沒有 Access Manager JAR 檔案路徑。
解決方法:依照以下步驟:
執行 amupgrade 程序檔之前,重新建立 Directory Server 的索引;這是 comm_dssetup.pl 程序檔發生問題所致。
將 Access Manager 的項目加入節點代理程式的 server.policy 檔案。只需要預設伺服器策略 (/var/opt/SUNWappserver/domains/domain1/config/server.policy) 的一份 server.policy 副本便已足夠。
如下所示,更新節點代理程式的 domain.xml 檔案中之 classpath。將 classpath-suffix 與相關的 classpath (取自 server.xml 檔案的 java-config 元素之 server-classpath 屬性),複製到 domain.xml 的 java-config 元素之各個屬性。java-config 元素可在 domain.xml 中的 config 元素下找到。
Access Manager 從版本 6 2005Q1 升級至版本 7 2005Q4 後,amadmin --version 指令傳回了錯誤的版本:Sun Java System Access Manager 版本 2005Q1。
解決方法:將 Access Manager 升級後,執行 amconfig 程序檔以配置 Access Manager。執行 amconfig 時,指定配置 (amsamplesilent) 檔案的完整路徑。例如,在 Solaris 系統中:
# ./amconfig -s ./config-file
或
# ./amconfig -s /opt/SUNWam/bin/config-file
對不是在 Access Manager 中建立的組織,不會顯示該組織的使用者角色。在除錯模式中,會顯示下列訊息:
錯誤:DesktopServlet.handleException() com.iplanet.portalserver.desktop.DesktopException: DesktopServlet.doGetPost(): 無權限可執行桌面
此錯誤在執行 Java ES 安裝程式遷移程序檔時會更明顯。當組織是由現有目錄資訊樹 (DIT) 或其他來源中遷移出來時,ContainerDefaultTemplateRole 屬性不會自動加入組織。
解決方法:使用 [Directory Server] 主控台來複製其他 Access Manager 組織的 ContainerDefaultTemplateRole 屬性,然後將其加入受影響的組織。
若您是將 Access Manager 7 2005Q4 部署在 Application Server 8.1 上,並對服務、主控台及密碼 Web 應用程式使用非預設 URI,但這些應用程式分別具有預設的 URI 值 amserver、amconsole 及 ampassword,則嘗試透過 Web 瀏覽器存取 Access Manager 之前,必須先編輯應用程式伺服器網域的 server.policy 檔案。
解決方法:以如下方式編輯 server.policy 檔案:
停止部署 Access Manager 的 Application Server 實例。
變更至 /config 目錄。例如:
cd /var/opt/SUNWappserver/domains/domain1/config
製作 server.policy 檔案的備份副本。例如:
cp server.policy server.policy.orig
在 server.policy 檔案中,尋找下列策略:
grant codeBase "file:\${com.sun.aas.instanceRoot}/ applications/j2ee-modules/amserver/-" { ... }; grant codeBase "file:\${com.sun.aas.instanceRoot}/ applications/j2ee-modules/amconsole/-" { ... }; grant codeBase "file:\${com.sun.aas.instanceRoot}/ applications/j2ee-modules/ampassword/-" { ... };
在下列指令行中,以服務 Web 應用程式的非預設 URI 取代 amserver:
grant codeBase "file:\${com.sun.aas.instanceRoot}/ applications/j2ee-modules/amserver/-" {
若是在舊有模式下進行安裝,請在下列指令行中,以主控台 Web 應用程式的非預設 URI 取代 amconsole:
grant codeBase "file:\${com.sun.aas.instanceRoot}/ applications/j2ee-modules/amconsole/-" {
在下列指令行中,以密碼 Web 應用程式的非預設 URI 取代 ampassword:
grant codeBase "file:\${com.sun.aas.instanceRoot}/ applications/j2ee-modules/ampassword/-" {
啟動部署 Access Manager 的 Application Server 實例。
在多重伺服器部署中,若將 Access Manager 安裝在第二個 (以及後續的) 伺服器上,平台伺服器清單與 FQDN 別名屬性不會更新。
解決方法:手動加入「範圍/DNS」別名與平台伺服器清單項目。如需有關步驟,請參閱「Sun Java System Access Manager 7 2005Q4 Deployment Planning Guide」中的「Adding Additional Instances to the Platform Server List and Realm/DNS Aliases」。
Access Manager 7 2005Q4 會強制服務 XML 檔案中的必需屬性必須有預設值。
解決方法:如果服務的必需屬性沒有值,請為屬性加入值後,重新載入服務。
若將 Access Manager 7 2005Q4 部署至安全 (使用 SSL) BEA WebLogic 8.1 SP4 實例,會在部署每個 Access Manager Web 應用程式時發生異常。
解決方法:依照以下步驟:
套用 WebLogic 8.1 SP4 修補程式 JAR CR210310_81sp4.jar ,其可從 BEA 取得。
在 /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= ...
在步驟 2 中找到的指令行後加入下列指令行:
wl8_classpath=path-to-CR210310_81sp4.jar:$wl8_classpath
在多重伺服器部署中,amconfig 程序檔未更新其他 Access Manager 實例的範圍/DNS 別名及平台伺服器清單項目。
解決方法:手動加入「範圍/DNS」別名與平台伺服器清單項目。如需有關步驟,請參閱「Sun Java System Access Manager 7 2005Q4 Deployment Planning Guide」中的「Adding Additional Instances to the Platform Server List and Realm/DNS Aliases」。
依預設,會啟用配置狀態檔範本中的 Access Manager 模式 (AM_REALM 變數)。
解決方法:若要在「舊有」模式下安裝或配置 Access Manager,請重設狀態檔中的變數:
AM_REALM = disabled
在 IBM WebSphere 中使用 RSA 金鑰時,URL 字串的簽署失敗,並有下列異常:
ERROR: FSSignatureUtil.signAndReturnQueryString: FSSignatureException occured while signing query string: no such provider: SunRsaSign
解決方法:WebSphere 隨附的 JDK 中缺少「SunRsaSign」提供者。若要修正此問題,編輯 websphere_jdk_root/jre/lib/security/java.security 檔案,加入下列內容以將「SunRsaSign」啟用為提供者之一:
security.provider.6=com.sun.rsajca.Provider
在 Access Manager 主控台中,於 [聯合] > [SAML] 標籤下建立 [SAML 可信任合作夥伴]。若您嘗試複製 [可信任合作夥伴],就會發生錯誤。
解決方法:無。此問題已在修補程式 1 中修正。有關如何針對特定平台套用修補程式的資訊,請參閱Access Manager 7 2005Q4 修補程式 1。
配置遠端記錄時,所有的記錄都會寫入遠端 Access Manager 實例,但是在 amConsole.access 與 amPasswordReset.access 中不會寫入密碼重設資訊。不會寫入該記錄檔。
解決方法:無。
在管理主控台中加入或編輯 amadmin 使用者的部分特性,導致 amadmin 使用者密碼發生改變。
解決方法:無。此問題已在修補程式 1 中修正。有關如何針對特定平台套用修補程式的資訊,請參閱Access Manager 7 2005Q4 修補程式 1。
新的 Access Manager 7 2005Q4 主控台無法設定「服務類別 (CoS)」範本優先權。
解決方法:登入 Access Manager 6 2005Q1 主控台以設定或修改 CoS 範本優先權。
當您將群組做為策略管理使用者加入使用者時,Access Manager 主控台會傳回異常錯誤。
解決方法:無。
在舊有模式下,若嘗試從角色刪除所有使用者,將會留下一位使用者。
解決方法:再次嘗試從角色刪除該使用者。
Access Manager 管理主控台不允許您加入、刪除或修改使用者、角色或範圍的資源提供。
解決方法:無。此問題已在修補程式 1 中修正。有關如何針對特定平台套用修補程式的資訊,請參閱Access Manager 7 2005Q4 修補程式 1。
使用錯誤的 LDAP 連結密碼時,Access Manager 管理主控台不會傳回錯誤訊息。
解決方法:無。
若您建立容器,然後嘗試在該容器下建立組織,Access Manager 會傳回 [唯一性違規錯誤] 訊息。
解決方法:無。
Portal Server 與 Access Manager 安裝於同一伺服器上。在「舊有」模式下安裝 Access Manager 後,使用 /amserver 登入新的 Access Manager 主控台。在您選擇現有使用者後嘗試加入服務 (如 NetFile 或 Netlet) 時,會突然出現舊的 Access Manager 主控台 (/amconsle)。
解決方法:無。目前版本的 Portal Server 必須搭配 Access Manager 6 2005Q1 主控台使用。
使用現有的 DIT 選項安裝 Directory Server ,然後安裝 Access Manager。登入 Access Manager 主控台並建立群組。編輯群組中的使用者。例如,使用篩選器 uid=*999* 加入使用者。產生的清單方塊是空的,但主控台未顯示任何錯誤、資訊或警告訊息。
解決方法:群組成員不得大於 Directory Server 搜尋大小限制。如果群組成員大於搜尋大小限制,請據此變更搜尋大小限制。
建立頂層範圍的子範圍,並對其加入階段作業服務後,後續嘗試移除階段作業服務配置時會產生錯誤訊息。
解決方法:移除預設的頂層 ID 儲存庫 AMSDK1,然後將此儲存庫加回配置中。
此問題已在修補程式 1 中修正。有關如何針對特定平台套用修補程式的資訊,請參閱Access Manager 7 2005Q4 修補程式 1。
將 Apache agent 2.2 設於 CDSSO 模式下,當存取代理程式保護的資源時,CDC servlet 重新導向使用者至匿名認證頁面,而不是預設的登入頁面。
解決方法:無。此問題已在修補程式 1 中修正。有關如何針對特定平台套用修補程式的資訊,請參閱Access Manager 7 2005Q4 修補程式 1。
使用用戶端 SDK (amclientsdk.jar) 撰寫的應用程式在伺服器要重新啟動時,沒有收到通知。
解決方法:無。
若修改了任何服務模式,ServiceSchema.getGlobalSchema 會傳回舊的模式而非新的模式。
解決方法:服務模式變更後重新啟動用戶端。
此問題已在修補程式 1 中修正。有關如何針對特定平台套用修補程式的資訊,請參閱Access Manager 7 2005Q4 修補程式 1。
如果您使用的是 Sun Java System Directory Proxy Server,則空屬性 LDAP 搜尋會傳回錯誤。例如:
# ldapsearch -b base-dn uid=user ""
若 Access Manager 直接指向 LDAP 目錄伺服器,則會成功進行相同的搜尋。
解決方法:如果您使用的是 Directory Proxy Server,則啟用空屬性搜尋或提供搜尋的屬性名稱。
安裝後,執行 amserveradmin 程序檔以將服務載入 Directory Server 時,程序檔缺少 defaultDelegationPolicies.xml 與 idRepoDefaults.xml 模式檔案。
解決方法:使用含有 -t 選項的 amadmin CLI 工具手動載入 defaultDelegationPolicies.xml 與 idRepoDefaults.xml 檔案。
若在 XML 檔案中加入特殊字元 (例如在「&」之後加上字串「amp;」),檔案會正確儲存,但是若稍後使用 Internet Explorer 6.0 擷取該 XML 設定檔,檔案無法正確顯示。如果接著嘗試再次儲存該設定檔,系統會傳回錯誤訊息。
解決方法:無。
UrlAccessAgent SSO 記號到期,因為應用程式模組未傳回特殊使用者 DN,導致特殊使用者 DN 相符而使得尚未到期的記號到期。
解決方法:無。此問題已在修補程式 1 中修正。有關如何針對特定平台套用修補程式的資訊,請參閱Access Manager 7 2005Q4 修補程式 1。
在範圍模式下,如果使用「錯誤」密碼在範圍中建立 ldapv3 資料儲存區,並稍後將密碼變更為 amadmin,則當您嘗試以使用變更後密碼的使用者身份再次登入時,登入會失敗,顯示不存在設定檔的訊息。
解決方法:無。
在舊有模式下安裝 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。
解決方法:無。
安裝 Access Manager 之後,以 amadmin 身份登入,將 o、sunPreferredDomain、associatedDomain、sunOrganizationAlias、uid 及 mail 屬性加入 [唯一的屬性清單]。若要建立兩個名稱相同的新組織,作業會失敗,但 Access Manager 會顯示 [組織已存在] 訊息,而不是按預期顯示 [違反屬性唯一性] 訊息。
解決方法:無。忽略不正確的訊息。Access Manager 運作正常。
跨不同時區安裝的 Access Manager 實例在同一個信任圈內導致使用者階段作業逾時。
階段作業容錯移轉配置程序檔 (/opt/sun/identity/bin/amsfoconfig ) 的權限不正確,無法在 Linux 2.1 系統上執行。
解決方法:變更權限以使 amsfoconfig 程序檔可執行 (例如 755)。
此問題已在修補程式 1 中修正。有關如何針對特定平台套用修補程式的資訊,請參閱Access Manager 7 2005Q4 修補程式 1。
階段作業容錯移轉配置程序檔 (amsfoconfig) 無法在 Linux 2.1 伺服器上執行,原因是未正確解析定位字元 (\t)。
解決方法:手動配置階段作業容錯移轉。如需步驟,請參閱「Sun Java System Access Manager 7 2005Q4 Deployment Planning Guide」中的「Configuring Session Failover Manually」。
此問題已在修補程式 1 中修正。有關如何針對特定平台套用修補程式的資訊,請參閱Access Manager 7 2005Q4 修補程式 1。
如果部署 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"/>
維護認證階段作業的預設方法是「內部階段作業」,而不是 HttpSession。3 分鐘的預設無效階段作業最大時間值已經足夠。amtune 程序檔會將 Web Server 或 Application Server 的該值設為一分鐘。然而,若您是使用協力廠商 Web 容器 (IBM WebSphere 或 BEA WebLogic Server) 和選用的 HttpSession,可能需要限制 Web 容器的最大 HttpSession 時間限制以避免效能發生問題。
刪除 [策略配置服務] 中的動態屬性會導致編輯以下方案的策略時發生問題:
在 [策略配置服務] 中建立兩個動態屬性。
建立策略並在回應提供者中選取動態屬性 (來自步驟 1)。
移除 [策略配置服務] 中的動態屬性,然後再建立兩個屬性。
試著編輯於步驟 2 建立的策略。
結果為:[錯誤:設定了無效的動態特性。]依預設,清單中不會顯示任何策略。完成搜尋後,策略會顯示出來,但您無法編輯或刪除現有策略,或建立新策略。
解決方法:從 [策略配置服務] 移除動態屬性之前,請先從策略移除對這些屬性的參照。
Access Manager 7 2005Q4 啟動時傳回 amDelegation 與 amProfile 除錯檔案中的除錯錯誤:
amDelegation:無法取得委託的外掛程式實例
amProfile:出現委託異常
解決方法:無。您可忽略這些訊息。
若您是使用 BEA WebLogic Server 做為 Web 容器來部署 Access Manager,就可能無法存取 Access Manager。
解決方法:再次重新啟動 WebLogic Server 以便可以存取 Access Manager。
若您是在 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;
當 Access Manager 配置為存取 Solaris 系統的 AccessManager-base/SUNWam/samples/phase2/wsc (或 Linux 系統的 AccessManager-base/identity/samples/phase2/wsc) 目錄之下的 Web 服務範例時,查詢 [探索服務] 或修改 [資源提供] 時會傳回錯誤訊息:[找不到資源提供]。
AccessManager-base 為基底安裝目錄。預設基底安裝目錄在 Solaris 系統上為 /opt,在 Linux 系統上為 /opt/sun。
解決方法:
前往下列範例目錄:Solaris 系統的 AccessManager-base/SUNWam/samples/phase2/wsc 目錄,或 Linux 系統的 AccessManager-base/identity/samples/phase2/wsc 目錄
在 index.jsp 檔中搜尋下列字串:
com.sun.org.apache.xml.security.utils.XMLUtils.outputDOM
在包含前一個步驟所找到字串的那一行之前,插入如下新的一行:
com.sun.org.apache.xml.security.Init.init();
重新執行範例。(您不需要重新啟動 Access Manager。)
若設定了識別提供者 (IDP) 與服務提供者 (SP),將通訊協定變更為使用瀏覽器的工件設定檔,然後試著在 IDP 與 SP 之間聯合使用者,結果聯合失敗。
解決方法:無。
以 Access Manager 做為來源站點與目的地站點,並且配置了 SSO,結果目的地站點中發生錯誤,原因是 SAML 敘述中的特殊字元 ( &) 未編碼,因此造成宣示的剖析失敗。
解決方法:無。此問題已在修補程式 1 中修正。有關如何針對特定平台套用修補程式的資訊,請參閱Access Manager 7 2005Q4 修補程式 1。
在 Access Manager 主控台中,若試著將資源提供加入 Disco 服務,會發生未知的異常。
解決方法:無。
除非您已配置並儲存其他屬性,否則將無法配置 Auth Context 屬性。
解決方法:先配置並儲存提供者設定檔,再配置 Auth Context 屬性。
若 Directory Server 有一個根字尾包含「&」字元,而您試著加入 [雇員配置檔服務資源提供],就會丟出一個異常。
解決方法:無。
在範圍模式下,若您聯合識別提供者 (IDP) 與服務提供者 (SP) 上的使用者帳號,然後在終止聯合後登出,會發生以下錯誤:[錯誤:找不到子組織。]
解決方法:無。
部分 Access Manager 管理主控台的元件不會遵守使用者語言環境喜好設定,而會使用瀏覽器語言環境設定。此問題會影響 [版本]、[登出] 及 [線上說明] 按鈕,以及 [版本] 和線上說明的內容。
解決方法:將瀏覽器設定變更為與使用者喜好設定相同的語言環境。
在所有歐洲語言環境 (西班牙語、德語及法語) 中,當 Access Manager 部署在 IBM WebSphere Application Server 實例上時,無法任意存取線上說明。針對以下框架,線上說明會顯示 [應用程式錯誤]:
上方框架,其中包含 [說明] 與 [關閉] 按鈕。
左方框架,其中包含 [內容]、[索引] 及 [搜尋] 按鈕。
解決方法:將瀏覽器語言設定為英語,然後重新整理頁面以便能存取左方框架。不過上方框架仍會顯示 [應用程式錯誤]。
在任何語言環境中,Access Manager 部署在 IBM WebSphere Application Server 實例上時,當您按一下 [版本] 按鈕,不會看見產品版本資訊,而會顯示空白頁面。
解決方法:無。
「用戶端偵測」功能無法正常運作。在 Access Manager 7 2005Q4 主控台中所做的變更未自動傳遞至瀏覽器。
解決方法:有二種解決方法:
在 [用戶端偵測] 區段中進行變更後,重新啟動 Access Manager Web 容器。
或
在 Access Manager 主控台中依照以下步驟執行:
按一下 [配置] 標籤下的 [用戶端偵測]。
按一下 genericHTML 的編輯連結。
按一下 HTML 標籤下的 genericHTML 連結。
在字元集清單中輸入下列項目:UTF-8;q=0.5 (請確定 UTF-8 q 因子小於語言環境中的其他字元集。)
儲存、登出後再登入一次。
/var/opt/SUNWam/logs 目錄下的記錄檔中之多位元組訊息以問號 (?) 顯示。記錄檔為原生編碼且不一定是 UTF-8 格式。在特定語言環境啟動 Web 容器實例時,該語言環境的記錄檔將使用原生編碼格式。若切換至其他語言環境並重新啟動 Web 容器實例,後續的訊息將以該語言環境的原生編碼呈現,但使用先前編碼方式的訊息將以問號顯示。
解決方法:確定每次均使用同一種原生編碼啟動任何 Web 容器實例。
記錄 AMConfig.properties 中的 com.iplanet.am.session.protectedPropertiesList (6351192)
伺服器端的 com.iplanet.am.session.client.polling.enable 不得為 true (6320475)
如果您在範圍模式下安裝 Access Manager 7 2005Q4,將無法復原為舊有模式。
不過,如果您在舊有模式下安裝 Access Manager 7 2005Q4,則可使用含 -M 選項的 amadmin 指令變更為範圍模式。例如:
amadmin -u cn=amAdmin,ou=People,dc=example,dc=com -w amadmin-password -M dc=example,dc=com
Access Manager 會使用持續搜尋來接收關於 Sun Java System Directory Server 項目變更的資訊。依預設,Access Manager 會在伺服器啟動期間建立下列持續搜尋連線:
aci - 對 aci 屬性的變更,使用 LDAP 篩選器 (aci=*) 進行搜尋
sm - 在 Access Manager 資訊樹狀結構 (或服務管理節點) 中進行的變更,其中包含 sunService 或 sunServiceComponent 記號物件類別的物件。例如,您可能需要建立策略來定義受保護資源的存取權限,或者需要修改現有策略的規則、主旨、條件或回應提供者。
um - 在使用者目錄 (或使用者管理節點) 中進行的變更。例如,您可能要變更使用者的名稱或位址。
我們不建議您停用這些元件的持續搜尋,因為停用持續搜尋後的元件將無法從 Directory Server 接收通知。因此,元件快取將不會收到 Directory Server 中該特殊元件的變更通知,使得元件快取的內容會變得比較陳舊。
例如,如果您停用使用者目錄 (um) 變更的持續搜尋,Access Manager 伺服器將不會從 Directory Server 收到通知。因此,代理程式將不會從 Access Manager 取得通知,從而不會以使用者屬性的新值來更新其本機使用者快取。然後,當應用程式查詢代理程式的使用者屬性時,它可能會收到該屬性的舊值。
只有在特殊情況下有絕對必要時才使用此特性。例如,當您知道生產環境中不會發生 [服務配置] 變更 (涉及變更諸如 [階段作業服務] 和 [認證服務] 等服務的值) 時,則可以停用 [服務管理] (sm) 元件的持續搜尋。不過,如果任何服務發生任何變更,將需要重新啟動伺服器。相同的條件也會套用到由 aci 和 um 值所指定的其他持續搜尋。
如需更多資訊,請參閱CR# 6363157:新特性會在絕對必要時停用持續搜尋。
權限用於定義做為某範圍內角色或群組成員的管理員所具備的存取權限。Access Manager 允許您配置下列管理員類型的權限:
範圍管理員可執行所有與範圍相關的作業,包括定義識別儲存庫 (資料存放區)、配置認證及定義策略。
策略管理員可配置現有範圍內的策略。
支援下列權限:
所有範圍與策略特性的讀取與寫入存取權。定義範圍管理員的讀取和寫入存取權限。
僅針對策略特性的讀取與寫入存取權。定義策略管理員的讀取和寫入存取權限。
支援的權限組合:僅針對策略特性的讀取與寫入存取權,以及資料存放區的唯讀存取權。不支援其他的權限組合。
若 Access Manager 伺服器部署在負載平衡器之後,基於 cookie 的居留式請求路由可避免將用戶端請求誤送到不正確的 Access Manager 伺服器 (也就是未代管階段作業的伺服器)。Access Manager 7 2005Q4 修補程式 3 已實作此功能。
依照以前的運作方式,若沒有基於 cookie 的居留式請求路由,則非瀏覽器式用戶端 (例如策略代理程式及使用遠端 Access Manager 用戶端 SDK 的用戶端) 請求通常都會誤送到未代管階段作業的 Access Manager 伺服器。然後,為將請求傳送到正確的伺服器,Access Manager 伺服器必須使用回返通道通訊來驗證階段作業,而這通常會造成效能降低。基於 cookie 的居留式請求路由不需要此回返通道通訊,因此可改善 Access Manager 的效能。
若要實作基於 cookie 的居留式請求路由,必須將 Access Manager 部署配置為站點。如需相關資訊,請參閱「Sun Java System Access Manager 7 2005Q4 Deployment Planning Guide」中的「Configuring an Access Manager Deployment as a Site」。
若要配置基於 cookie 的居留式請求路由:
若要指定 cookie 名稱,請設定 AMConfig.properties 檔案中的 com.iplanet.am.lbcookie.name 特性。然後 Access Manager 便會使用兩個位元組的伺服器 ID (例如 01、02 和 03) 來產生負載平衡器 cookie 值。如果不指定 cookie 名稱,Access Manager 會使用預設名稱 amlbcookie 加上兩個位元組的伺服器 ID 來產生負載平衡器 cookie 值。
如果在 Access Manager 伺服器上設定了 cookie 的名稱,則策略代理程式的 AMAgent.properties 檔案中必須使用相同的名稱。同樣,如果使用的是 Access Manager 用戶端 SDK,也必須使用與 Access Manager 伺服器相同的 cookie 名稱。
備註:請勿設定 com.iplanet.am.lbcookie.value 特性,因為 Access Manager 會使用兩個位元組的伺服器 ID 來設定 cookie 值。
使用步驟 1 中的 cookie 名稱來配置負載平衡器。您可以在 Access Manager 部署使用硬體或軟體負載平衡器。
如果已實作階段作業容錯移轉,請啟用策略代理程式和 Access Manager 伺服器的 com.sun.identity.session.resetLBCookie 特性。
若為策略代理程式,請增加並啟用 AMAgent.properties 檔案中的特性。
若為 Access Manager 伺服器,請增加並啟用 AMConfig.properties 檔案中的特性。
例如:
com.sun.identity.session.resetLBCookie='true'
如果發生容錯移轉的情況,階段作業會被路由到輔助 Access Manager 伺服器,並使用輔助 Access Manager 伺服器的伺服器 ID 來設定負載平衡器的 cookie 值。然後任何後續階段作業請求也將路由到輔助 Access Manager 伺服器。
要在 Windows 2003 上配置 Windows Desktop SSO, 如「Sun Java System Access Manager 7 2005Q4 管理指南」中的「配置 Windows Desktop SSO」中所述,請使用下列 ktpass 指令:
ktpass /out filename /mapuser username /princ HTTP/hostname.domainname /crypto encryptiontype /rndpass /ptype principaltype /target domainname
例如:
ktpass /out demo.HTTP.keytab /mapuser http /princ HTTP/demo.identity.sun.com@IDENTITY.SUN.COM /crypto RC4-HMAC-NT /rndpass /ptype KRB5_NT_PRINCIPAL /target IDENTITY.SUN.COM
如需語法定義,請參閱下列網站:
下列程序描述如何設定分散式認證 UI 伺服器與 Access Manager 伺服器進行通訊的加密密碼。
若要設定分散式認證 UI 伺服器的密碼:
在 Access Manager 伺服器中:
在分散式認證 UI 伺服器上,對 AMConfig.properties 檔案進行如下變更:
將 com.iplanet.am.service.password 特性標記為註釋。
將 com.iplanet.am.service.secret 特性設為在步驟 1a 中加密的 amadmin 密碼。
增加從步驟 1b 中複製的 am.encryption.pwd 及加密值。例如:
com.sun.identity.agents.app.username=username #com.iplanet.am.service.password=password com.iplanet.am.service.secret=AQIC0K3omEozd544XEJIg25GT2wi1D7UAQLX am.encryption.pwd=ydV8JXhJF2J35vpxjZRiGt7SH/7mUr+Y
重新啟動分散式認證 UI 伺服器。
Access Manager 主控台線上說明中,未描述在 [配置] > [系統特性] > [平台] 之下「建立新站點名稱」的 [儲存] 步驟。如果您在增加新站點名稱後沒有按一下 [儲存],當您再嘗試增加實例名稱時,該程序會失敗。因此,在增加站點名稱後請務必按一下 [儲存],然後再增加實例名稱。
在 Solaris 和 Linux 系統中,amsamplesilent 中的 Access Manager 管理員 (amadmin) 密碼配置參數為 ADMINPASSWD。不過,在 Windows 系統中,AMConfigurator.properties 檔案中的參數為 ADMIN_PASSWD。
如果您在 Windows 系統中執行 amconfig.bat,請使用 ADMIN_PASSWORD 參數而不要使用 ADMINPASSWD 設定 AMConfigurator.properties 檔案中的 amadmin 密碼。
已更正針對執行 Web 服務範例時傳回 [找不到資源提供](6359900) 之解決方法的步驟 3。
com.iplanet.am.session.protectedPropertiesList 參數讓您可以保護特定的核心或內部階段作業特性,使它們不會被階段作業服務的 SetProperty 方法從遠端更新。藉由設定此「隱藏」的關鍵安全性參數,您可自訂階段作業屬性以便參與授權以及其他的 Access Manager 功能。若要使用此參數:
使用文字編輯器,將參數加入 AMConfig.properties 檔案。
將參數設定為要保護的階段作業特性。例如:
com.iplanet.am.session.protectedPropertiesList = PropertyName1,PropertyName2,PropertyName3
重新啟動 Access Manager Web 容器以使這些值生效。
如果資料儲存於 Sun Java System Directory Server 中,則套用對應的修補程式後,可為 LDAPv3 外掛程式配置角色和已篩選角色 (可修正 CR 6349959)。在 Access Manager 7 2005Q4 管理員主控台中,在 LDAPv3 配置的 [LDAPv3 外掛程式支援的類型和作業] 欄位中,輸入下列值:
role: read,edit,create,delete filteredrole: read,edit,create,delete
您可輸入上述項目之一或二者皆輸入,依您計劃在 LDAPv3 配置中使用的角色和已篩選角色而定。
AMConfig.properties 檔案中未使用下列特性:
com.iplanet.am.directory.host com.iplanet.am.directory.port
AMConfig.properties 檔案中的 com.iplanet.am.session.client.polling.enable 特性在伺服器端永遠不可以設定為 true。
解決方法:依預設,此特性設為 false,應永遠不得重設為 true。
service.scserviceprofile.iplanetamauthservice.html 線上說明檔案中的預設成功 URL 不正確。[預設成功 URL] 欄位接受多重值清單,此清單指定認證成功後,會將使用者重新導向至的 URL。此屬性格式為 clientType|URL,您僅能指定 URL 的值,預設為 HTML 類型。
“/amconsole” 預設值不正確。
解決方法:正確的預設值為「/amserver/console」。
若要啟用 Access Manager 或 Federation Manager 的 XML 加密 (使用 Bouncy Castle JAR 檔來產生傳輸的金鑰),依下列步驟操作:
若您使用的 JDK 版本早於 JDK 1.5,從 Bouncy Castle 網站 (http://www.bouncycastle.org/) 下載 Bouncy Castle JCE 提供者。例如,若使用 JDK 1.4,則下載 bcprov-jdk14-131.jar 檔。
若您已依前述步驟下載 JAR 檔,將檔案複製到 jdk_root/jre/lib/ext 目錄中。
有關各國的 JDK 版本資訊,從 Sun 網站 (http://java.sun.com) 下載針對您的 JDK 版本的 JCE Unlimited Strength Jurisdiction Policy Files。若使用 IBM WebSphere,前往對應的 IBM 網站下載所需的檔案。
將下載的 US_export_policy.jar 和 local_policy.jar 檔案複製到 jdk_root/jre/lib/security 目錄。
若您使用的 JDK 版本早於 JDK 1.5,則編輯 jdk_root/jre/lib/security/java.security 檔案,增加 Bouncy Castle 做為提供者之一。例如:
security.provider.6=org.bouncycastle.jce.provider.BouncyCastleProvider
在 AMConfig.properties 檔案中將下列特性設定為 true:
com.sun.identity.jss.donotInstallAtHighestPriority=true
重新啟動 Access Manager Web 容器。
如需更多資訊,請參考問題 ID 5110285 (XML 加密需有 Bouncy Castle JAR 檔)。