test

Sun Java System Access Manager 7.1 管理指南

認證模組類型

認證模組是一個收集使用者資訊 (如使用者 ID 和密碼) 並根據資料庫中項目檢查資訊的外掛程式。若使用者提供的資訊符合認證條件，則將對使用者授予所請求資源的存取權。若使用者提供的資訊不符合認證條件，則將拒絕使用者存取所請求的資源。Access Manager 安裝時附有下列認證模組類型：

備註 –

用作認證實例之前，某些認證模組類型需要進行預先配置。如需要，配置步驟將列於模組類型描述之中。

核心

依預設，Access Manager 提供十五種不同的認證模組，以及核心認證模組。核心認證模組為認證模組提供總體配置。增加及啟用 Active Directory、匿名、基於憑證的認證、HTTP Basic、JDBC、LDAP 等任何認證模組之前，必須先增加和啟用核心認證。對預設範圍自動啟用核心和 LDAP 認證兩種模組。

按一下 [進階特性] 按鈕顯示可為範圍定義的核心認證屬性。全域屬性不適用於範圍，因此將不顯示。

Active Directory

Active Directory 認證模組執行認證的方式與 LDAP 模組相似，但使用的是 Microsoft 的 Active Directory™ 伺服器 (而 LDAP 認證模組使用的是 Directory Server)。雖然可為 Active Directory 伺服器配置 LDAP 認證模組，但此模組可讓您在相同範圍下同時擁有 LDAP 和 Active Directory 兩種認證。

備註 –

在此發行版本中，Active Directory 認證模組僅支援使用者認證。只有 LDAP 認證模組會支援密碼策略。

匿名

依預設，啟用此模組時，使用者能以 anonymous 使用者的身份登入 Access Manager。藉由配置 [有效匿名使用者清單] 屬性，亦可定義此模組的匿名使用者清單。授予匿名存取權意味著無需提供密碼即可進行存取。可以將匿名存取權限制為特定類型的存取權 (例如，讀取存取權或搜尋存取權)，或限制在目錄內的子樹狀結構或個別項目中。

憑證

基於憑證的認證需要使用個人數位憑證 (personal digital certificate, PDC) 來識別和認證使用者。可以將 PDC 配置為需要與儲存在 Directory Server 中的 PDC 相符，並要根據憑證撤銷清單進行驗證。

在對範圍加入基於憑證的認證模組之前，需要完成許多工作。首先，需要確保與 Access Manager 一同安裝之 Web 容器的安全，並對其進行配置，以用於基於憑證的認證。

備註 –

若要以啟用了 SSL 的 Sun Java System Web Server 6.1 實例來配置 Access Manager 憑證認證，並希望將 WebServer 定義成接受基於憑證以及不基於憑證的認證請求，您必須在 WebServer 的 obj.conf 檔案中設定下列值︰

PathCheck fn="get-client-cert" dorequest="1" require="0"

這是因為設定這種運作方式的選擇性屬性時，在 WebServer 主控台中有限制。

於啟用基於憑證的模組之前，請參閱「Sun ONE Web Server 6.1 管理員指南」中的第 6 章「使用證書和金鑰」，以取得 Web Server 的初始配置步驟。此文件位於以下位置：

http://docs.sun.com/app/docs/coll/S1_websvr61_en

或者，參閱位於下列位置的「Sun ONE Application Server Administrator’s Guide to Security」：

http://docs.sun.com/db/prod/s1appsrv#hic

備註 –

每一位要使用基於憑證的模組進行認證的使用者，必須請求用於使用者瀏覽器的 PDC。根據所使用的瀏覽器不同，會有不同的說明。請參閱您瀏覽器的說明文件，以取得更多資訊。

為了加入此模組，您必須以範圍管理員的身份登入 Access Manager，並配置 Access Manager 和 Web 容器，以使用 SSL 並啟用用戶端認證。如需更多資訊，請參閱「Access Manager Post Installation Guide」中的「Configuring Access Manager in SSL Mode」。

資料存放區

「資料存放區」認證模組也允許使用範圍的「識別儲存庫」登入，以認證使用者。如果要根據相同的資料存放區儲存庫進行認證，則使用「資料存放區」模組可以不必撰寫認證外掛程式模組、載入及配置認證模組。此外，您不需要撰寫範圍中對應儲存庫需要純文字檔認證的自訂認證模組。

此認證類型在配置 Access Manager 認證時提供某些程度的方便性。在 Access Manager 7.1 之前的發行版本中，如果您想讓 LDAPv3 資料存放區中的使用者能夠認證到他們的範圍，您必須︰

「資料存放區」認證模組可讓定義於範圍識別儲存庫中的使用者進行認證。不需要配置 LDAP 認證。例如，假設有個範圍的識別儲存庫包含一個 LDAPv3 資料存放區，且同一個範圍使用資料存放區認證。在此情況下，定義於識別儲存庫中的任何使用者都可以認證到該範圍。

HTTP Basic

此模組使用基本認證，它是 HTTP 通訊協定內建的認證支援。Web 伺服器發出要求提供使用者名稱和密碼的用戶端請求，並將這些資訊作為授權請求的一部分傳回伺服器。Access Manager 會擷取該使用者名稱和密碼，並從內部將使用者認證至 LDAP 認證模組。為使 HTTP Basic 正常工作，必須加入 LDAP 認證模組 (僅加入 HTTP Basic 模組將不起作用)。一旦使用者認證成功，其無需提供使用者名稱和密碼即可重新進行認證。

JDBC

Java Database Connectivity (JDBC) 認證模組提供一種機制，可讓 Access Manager 經由提供 JDBC 技術啟用驅動程式的 SQL 資料庫來認證使用者。SQL 資料庫的連線可以直接透過 JDBC 驅動程式或透過 JNDI 連線池。

備註 –

此模組已在 MySQL4.0 和 Oracle 8i 上通過測試。

LDAP

如果使用 LDAP 認證模組，當使用者登入時，他們必須以特定的使用者 DN 和密碼連結至 LDAP Directory Server。此為所有基於範圍的認證之預設認證模組。若使用者提供 Directory Server 中的使用者 ID 和密碼，系統將允許此使用者存取有效的 Access Manager 階段作業，並使用該階段作業進行設定。對預設範圍自動啟用核心和 LDAP 認證兩種模組。

成員身份

成員身份認證的實作類似於個人化網站，例如：my.site.com 或 mysun.sun.com。啟用此模組時，使用者無需借助管理員，即可建立帳號並對其進行個人化設定。對於這個新帳號，使用者能以已加入使用者的身份來存取它。還可以存取檢視器介面，此介面作為授權資料和使用者偏好設定儲存在使用者設定檔資料庫中。

MSISDN

Mobile Station Integrated Services Digital Network (MSISDN) 認證模組會使用如行動電話等裝置相關的行動用戶 ISDN 來啟用認證。這是非互動式模組。此模組擷取用戶 ISDN 並根據 Directory Server 進行驗證，以找到符合該號碼的使用者。

RADIUS

Access Manager 可以配置為搭配已安裝的 RADIUS 伺服器使用。如果您的企業使用舊有的 RADIUS 伺服器進行認證，這會很有用。啟用 RADIUS 認證模組需要執行兩個步驟：

  1. 配置 RADIUS 伺服器。

    如需詳細說明，請參閱 RADIUS 伺服器的文件。

  2. 註冊和啟用 RADIUS 認證模組。

與 Sun Java System Application Server 一起配置 RADIUS

RADUIS 用戶端與其伺服器形成通訊端連線時，依預設，Application Server 的 server.policy 檔案中，只允許有 SocketPermissions 的連線權限。為了使 RADUIS 認證正常運作，需要為以下動作授予權限：

若要授予通訊端連線的權限，您必須在 Application Server 的 server.policy 檔案中加入一個項目。SocketPermission 由主機規格和一組指定與該主機連線方式的動作組成。主機依如下方式指定：

host = hostname | IPaddress:portrange:portrange = portnumber 
| -portnumberportnumber-portnumber

主機表示為 DNS 名稱、數字 IP 位址或本地主機 (針對本端機器)。DNS 名稱主機規格中可使用一次萬用字元「*」。如果包含萬用字元，它必須位於最左側，如：*.example.com。

連接埠 (或連接埠範圍) 為選擇性的。形式為 N- 的連接埠規格 (其中 N 為連接埠號碼)，表示號碼為 N 及 N 以上的所有連接埠。形式為 -N 的連接埠規格則表示號碼為 N 及 N 以下的所有連接埠。

偵聽動作僅在與本地主機搭配使用時才有意義。如果存在任何其他動作，則暗含解析 (解析主機/IP 名稱服務查找) 動作。

例如，建立 SocketPermissions 時請注意，如果將以下權限授予某程式碼，則該權限可讓程式碼與 machine1.example.com 上的 port 1645 連線，並接受該連接埠上的連線：

permission java.net.SocketPermission machine1.example.com:1645, "connect,accept";

同樣，如果將以下權限授予某程式碼，則該權限可讓程式碼接受本地主機上 1024 至 65535 之間任一連接埠上的連線，並可連線或偵聽這些連接埠：

permission java.net.SocketPermission "machine1.example.com:1645", "connect,accept";
permission java.net.SocketPermission "localhost:1024-", "accept,connect,listen";
備註 –

因為有害的程式碼可以更容易在不擁有資料存取權的多方中傳輸和共用這些資料，所以將接受或建立與遠端主機連線的權限授予程式碼可能會引發問題。請確保僅透過指定精確的連接埠號 (而不是指定連接埠號範圍) 授予適當的權限。

SafeWord

可配置 Access Manager 以處理對安全運算的 SafeWord™ 或 SafeWord PremierAccess™ 認證伺服器的 SafeWord 認證請求。Access Manager 會提供 SafeWord 認證的用戶端。SafeWord 伺服器可以存在於安裝有 Access Manager 的系統，或是單獨的系統上。

與 Sun Java System Application Server 一起配置 SafeWord

SafeWord 用戶端與其伺服器形成通訊端連線時，依預設，Application Server 的 server.policy 檔案中，只允許有 SocketPermissions 的 connect 權限。為了使 SafeWord 認證正常工作，需要為以下動作授予權限：

若要授予通訊端連線的權限，您必須在 Application Server 的 server.policy 檔案中加入一個項目。SocketPermission 由主機規格和一組指定與該主機連線方式的動作組成。主機依如下方式指定：

host = (hostname | IPaddress)[:portrange] portrange = 
portnumber | -portnumberportnumber-[portnumber]

主機表示為 DNS 名稱、數字 IP 位址或本地主機 (針對本端機器)。DNS 名稱主機規格中可使用一次萬用字元「*」。如果包含萬用字元，它必須位於最左側，如：*.example.com。

連接埠 (或 portrange) 為選擇性的。形式為 N- 的連接埠規格 (其中 N 為連接埠號碼)，表示號碼為 N 及 N 以上的所有連接埠。形式為 -N 的規格則表示號碼為 N 及 N 以下的所有連接埠。

偵聽動作僅在與本地主機搭配使用時才有意義。如果存在任何其他動作，則暗含解析 (解析主機/IP 名稱服務查找) 動作。

例如，建立 SocketPermissions 時請注意，如果將以下權限授予某程式碼，則該權限可讓程式碼與 machine1.example.com 上的連接埠 1645 連線，並接受該連接埠上的連線：

permission java.net.SocketPermission machine1.example.com:5030, "connect,accept";

同樣，如果將以下權限授予某程式碼，則該權限可讓程式碼接受本地主機上 1024 至 65535 之間任一連接埠上的連線，並可連線或偵聽這些連接埠：

permission java.net.SocketPermission "machine1.example.com:5030", "connect,accept";
permission java.net.SocketPermission "localhost:1024-", "accept,connect,listen";
備註 –

因為有害的程式碼可以更容易在不擁有資料存取權的多方中傳輸和共用這些資料，所以將接受或建立與遠端主機連線的權限授予程式碼可能會引發問題。請確保僅透過指定精確的連接埠號 (而不是指定連接埠號範圍) 授予適當的權限。

SAML

安全指定標記語言 (Security Assertion Markup Language, SAML) 認證模組接收並驗證目標伺服器上的 SAML 指定。只有在此模組是配置於目標機器上時 (包括升級後，例如：Access Manager 2005Q4 升級至 Access Manager 7.1)，SAML SSO 才有作用。

SecurID

Access Manager 可以配置為能處理對 RSA 的 ACE/Server 認證伺服器提出之「SecurID 認證」請求。Access Manager 會提供 SecurID 認證的用戶端。ACE/Server 可以存在於安裝有 Access Manager 的系統，或是單獨的系統上。若要對本機管理的使用者 ID 進行認證 (請參閱 admintool (1M))，則需要超級使用者存取權限。

「SecurID 認證」使用認證輔助程式 amsecuridd，它是 Access Manager 主程序以外的單獨程序。此輔助程式會在啟動時偵聽某連接埠，以取得配置資訊。若安裝了 Access Manager 並以 nobody 的身份或超級使用者以外的使用者 ID 執行，則仍必須以超級使用者的身份執行 AccessManager-base/SUNWam/share/bin/amsecuridd 程序。如需關於 amsecuridd 輔助程式的更多資訊，請參閱「Access Manager Administration Reference」中的「The amSecurID Helper」。

備註 –

在此版本的 Access Manager 中，「SecurID 認證」模組不適用於 Linux 或 Solaris x86 平台，且不應在這兩個平台上註冊、配置或啟用。它僅適用於 SPARC 系統。

UNIX

Access Manager 可以配置為根據安裝有 Access Manager 的 Solaris 或 Linux 系統上已知的 Unix 使用者 ID 和密碼，處理認證請求。雖然 Unix 認證只有一個範圍屬性和幾個全域屬性，但仍有一些針對系統的考量。若要對在本機管理的使用者 ID 進行認證 (請參閱 admintool (1M))，需要超級使用者存取權限。

「Unix 認證」使用認證輔助程式 amunixd，它是 Access Manager 主程序以外的單獨程序。此輔助程式會在啟動時偵聽某連接埠，以取得配置資訊。每個 Access Manager 只有一個 Unix 輔助程式以供其所有範圍使用。

如果安裝了 Access Manager 並以 nobody 身份或非超級使用者的使用者 ID 執行，必須仍以超級使用者身份執行 AccessManager-base/SUNWam/share/bin/amunixd 程序。Unix 認證模組透過開啟 localhost:58946 的通訊端來呼叫 amunixd 常駐程式，以偵聽 Unix 認證請求。若要在預設連接埠上執行 amunixd 輔助程式程序，請輸入以下指令：

./amunixd

若要在非預設連接埠上執行 amunixd，請輸入以下指令：

./amunixd [-c portnm] [ipaddress]

IP 位址與連接埠埠號位於 AMConfig.properties 的 UnixHelper.ipadrs 屬性 (IPV4 格式) 和 UnixHelper.port 屬性中。您可透過 amserver 指令行公用程式執行 amunixd (amserver 會自動執行此程序，從 AMConfig.properties 擷取連接埠號和 IP 位址)。

/etc/nsswitch.conf 檔案中的 passwd 項目會決定是參考 /etc/passwd 和 /etc/shadow 檔案，還是參考 NIS 來進行認證。

Windows Desktop SSO

「Windows Desktop SSO 認證」模組是以 Kerberos 為基礎的認證外掛程式模組，用於 Windows 2000™。它可讓通過 Kerberos 分發中心 (Kerberos Distribution Center, KDC) 認證的使用者，毋需再次提交登入條件便可通過 Access Manager 的認證 (單次登入)。

使用者透過 SPNEGO (Simple and Protected GSS-API Negotiation Mechanism，簡單和受保護的 GSS-API 協商機制) 通訊協定向 Access Manager 提供 Kerberos 記號。為了經由此認證模組來執行基於 Kerberos 的單次登入 Access Manager，在用戶端的使用者必須支援 SPNEGO 通訊協定，才能自我認證。通常，任何支援此通訊協定的使用者皆應可使用這個模組以進行 Access Manager 認證。視用戶端記號的可用性而定，此模組會提供 SPENGO 記號或 Kerberos 記號 (不論那一個，通訊協定都相同)。於 Windows 2000 (或更新版本) 上執行的 Microsoft Internet Explorer (5.01 或更新版本) 目前支援此通訊協定。此外，Solaris (9 和 10) 上的 Mozilla 1.4 具有 SPNEGO 支援，但僅會傳回 KERBEROS 記號，因為 Solaris 不支援 SPNEGO。

備註 –

您必須使用 JDK 1.4 或更新版本，才能利用 Kerberos V5 認證模組的新功能和 Java GSS API，在此 SPNEGO 模組中執行基於 Kerberos 的 SSO。

Internet Explorer 的已知限制

若在 WindowsDesktopSSO 認證時使用的是 Microsoft Internet Explorer 6.x，且瀏覽器不具使用者的 kerberos/SPNEGO 記號 (符合 WindowsDesktopSSO 模組中配置的 (KDC) 範圍) 之存取權，則在瀏覽器向 WindowsDesktopSSO 模組的認證失敗後，瀏覽器對其他模組的運作也會不正確。導致此問題的直接原因在於當 Internet Explorer 向 WindowsDesktopSSO 模組認證失敗後，即使出現回呼的提示，瀏覽器也無法將回呼 (屬於其他模組) 傳遞至 Access Manager，除非瀏覽器重新啟動。由於使用者憑證為空，因此 WindowsDesktopSSO 之後的所有模組都將失敗。

請參閱下列文件以取得相關資訊：

http://support.microsoft.com/default.aspx?scid=kb;en-us;308074

http://www.wedgetail.com/jcsi/sso/doc/guide/troubleshooting.html#ieNTLM

備註 –

截至此 Access Manager 發行版本，Microsoft 已修正這個限制。如需更多資訊，請參閱下列文件︰

http://www.microsoft.com/technet/security/bulletin/ms06-042.mspx

配置 Windows Desktop SSO

啟用 Windows Desktop SSO 認證是一個具有兩個步驟的程序：

  1. 在 Windows 2000 網域控制器中建立一個使用者

  2. 設定 Internet Explorer。

Procedure要在 Windows 2000 網域控制器中建立一個使用者

  1. 在網域控制器中，為 Access Manager 認證模組建立使用者帳號。

    1. 從 [開始] 功能表移至 [程式集] > [管理工具]。

    2. 選取 [使用者與電腦]。

    3. 移至 [電腦] > [新增] > [電腦]，並增加用戶端電腦的名稱。如果您使用 Windows XP，則會在配置網域控制站帳號時自動執行這個步驟。

    4. 移至 [使用者] > [新增] > [使用者]，並以 Access Manager 主機名稱做為使用者 ID (登入名稱) 建立新使用者。Access Manager 主機名稱不應包含網域名稱。

  2. 將使用者帳號與服務提供者名稱產生關聯，並將 keytab 檔案匯出至安裝 Access Manager 的系統。若要進行上述動作，請執行下列指令：


    ktpass -princ host/hostname.domainname@DCDOMAIN -pass password -mapuser userName -out 
hostname.host.keytab
ktpass -princ HTTP/hostname.domainname@DCDOMAIN -pass 
password -mapuser userName -out hostname.HTTP.keytab
    備註 –

    ktpass 公用程式不作為 Windows 2000 伺服器的一部分安裝。您必須從安裝光碟將它安裝到 c:\program files\support 工具目錄。

    ktpass 指令接受下列參數：

    hostname。執行 Access Manager 的主機名稱 (不含網域名稱)。

    domainname。Access Manager 網域名稱。

    DCDOMAIN。網域控制器的網域名稱。此名稱可能與 Access Manager 的網域名稱不同。

    password。使用者帳號的密碼。請確定密碼正確，因為 ktpass 不會驗證密碼。

    userName。使用者帳號 ID。它應該與 hostname 相同。

    備註 –

    請確保兩個 keytab 檔案均已做好安全措施。

    服務範本值應類似於以下範例：

    服務主體： HTTP/machine1.EXAMPLE.COM@ISQA.EXAMPLE.COM

    Keytab 檔案名稱：/tmp/machine1.HTTP.keytab

    Kerberos 範圍： ISQA.EXAMPLE.COM

    Kerberos 伺服器名稱︰machine2.EXAMPLE.com

    使用網域名稱傳回委託人：false

    認證層級︰22

    備註 –

    如果您使用 Windows 2003 或 Windows 2003 Service Pack，請使用下列 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

    如需語法定義，請參閱 http://technet2.microsoft.com/WindowsServer/en/library/64042138-9a5a-4981-84e9-d576a8db0d051033.mspx?mfr=true 網站。

  3. 重新啟動伺服器。

Procedure設定 Internet Explorer

上述步驟適用於 Microsoft Internet Explorer™ 6 及更高版本。若您是使用較早的版本，請確定 Access Manager 在瀏覽器的網際網路區域內，並啟用本機 Windows 認證。

  1. 在 [工具] 功能表中，移至 [網際網路選項] > [進階/安全性] > [安全性]。

  2. 選取 [整合 Windows 認證] 選項。

  3. 移至 [安全性] > [本機網際網路]。

    1. 選取 [自訂層級]。在 [使用者驗證/登入] 面板中，選取 [只在企業內部網路區域自動登入] 選項。

    2. 前往 [網站] 並選取所有選項。

    3. 按一下 [進階] ，並將 Access Manager 加入至本機區域 (若尚未加入的話)。

Windows NT

Access Manager 可以配置為搭配已安裝的 Windows NT/Windows 2000 伺服器使用。Access Manager 會提供 NT 認證的用戶端部分。

  1. 配置 NT 伺服器。如需詳細說明，請參閱 Windows NT 伺服器的文件。

  2. 加入和啟用 Windows NT 認證模組之前，您必須先取得和安裝 Samba 用戶端，以便與 Solaris 系統上的 Access Manager 進行通訊。

安裝 Samba Client

若要啟動 Windows NT 認證模組，必須下載 Samba Client 2.2.2，並將之安裝至下列目錄：

AccessManager-base/SUNWam/bin

Samba Client 是一種檔案與列印伺服器，用於將 Windows 和 UNIX 機器結合在一起，而無需單獨的 Windows NT/2000 Server。如需更多資訊及下載該軟體，請移至：http://wwws.sun.com/software/download/products/3e3af224.html。

Red Hat Linux 隨附 Samba 用戶端，位於下列目錄︰

/usr/bin

若要使用 Linux 的 Windows NT 認證模組進行認證，將用戶端二進位檔案複製到下列 Access Manager 目錄中：

AccessManager-base/sun/identity/bin
備註 –

如果您有多個介面，則需要額外的配置。多重介面可以透過 smb.conf 檔案中的配置設定，以傳遞到 mbclient。