ISA Server 2006 中的驗證
本文件說明 Microsoft® Internet Security and Acceleration (ISA) Server 2006 如何管理驗證。其中提供的資訊包含 ISA Server 所支援的新驗證和委派方法，以及 ISA Server 如何處理驗證處理程序等相關資訊。
本文件提供
| • | 這個版本中新驗證功能的概觀。 |
| • | ISA Server 2006 中的驗證處理程序和可用驗證選項的描述。 |
| • | 彙總如何搭配使用驗證選項的表格。 |
新功能
ISA Server 2006 提供下列新驗證功能：
| • | 單一登入 (SSO)，這讓使用者只要向 ISA Server 驗證一次，就可以存取在 ISA Server 後面的任意數目的伺服器，而無需重新驗證。 |
| • | 使用表單型驗證和用戶端憑證的兩個因素的驗證方式。 |
| • | 發行任何 Web 伺服器的表單型驗證支援。 |
| • | 表單型驗證的可自訂表單以及行動用戶端的表單，並使用每一使用者代理程式驗證配置。 |
| • | 針對非瀏覽器用戶端從表單型驗證使用基本驗證作為後援。 |
| • | 使用 NTLM 或 Kerberos 驗證委派認證。 |
| • | Kerberos 限制委派。 |
| • | 認證快取。 |
| • | 密碼管理，ISA Server 可在其中檢查使用者的 帳戶狀態並向使用者報告。此功能還可以設定為讓使用者變更密碼。 |
| • | 安全通訊端層 (SSL) 用戶端憑證限制。 |
| • | 指派不同的數位憑證給網路介面卡上每個 IP 位址的能力。 |
| • | 新的表單型驗證類型：使用者名稱 PASSCODE/密碼，其中 PASSCODE 適用於 ISA Server 驗證，而密碼則適用於驗證委派。 |
| • | 支援使用輕量型目錄存取通訊協定 (LDAP) 的 Active Directory® 目錄服務驗證，因此當 ISA Server 位於工作群組中或是使用者帳戶所在樹系以外的樹系中時，就可以使用 Active Directory 驗證。ISA Server 也支援多重樹系設定，因而可在不同的 LDAP 伺服器組中驗證使用者。 |
| • | 一次有效密碼支援「遠端驗證撥入使用者服務」(RADIUS)。在 ISA Server 2004 中，僅針對 RSA SecurID 提供這項支援。 |
| • | 預設封鎖驗證委派。 |
下列各節會詳細說明單一登入、兩個因素的驗證方式及認證快取。稍後在本文件內一般 ISA Server 驗證概念的相關內容中會說明許多其他新功能。
單一登入
單一登入 (SSO) 可讓使用者向 ISA Server 驗證一次，然後即可存取 ISA Server 在特定接聽程式上發行，具相同網域尾碼的所有 Web 伺服器，而無需重新驗證。Web 伺服器可包含 Microsoft Outlook® Web Access 伺服器和執行 Microsoft Office SharePoint® Portal Server 2003 的伺服器，以及執行網際網路資訊服務 (IIS) 的標準伺服器。
單一登入 (SSO) 的典型範例為登入 Outlook Web Access 的使用者在表單上提供認證。在使用者接收到的其中一封電子郵件訊息中，會有 SharePoint Portal Server 中所儲存文件的連結。使用者按一下連結，文件就會開啟，而不會有其他驗證要求。此範例會借助使用持續的 Cookie，如 ISA Server 說明中所述。
安全性注意事項
| • | 只要使用者的瀏覽器處理程序仍在執行中，該使用者就是登入狀態。例如，使用者登入 Outlook Web Access。使用者從 Microsoft Internet Explorer® 功能表開啟新的瀏覽器視窗，然後瀏覽至另一個站台。關閉 Outlook Web Access 視窗並不會結束工作階段，而且使用者仍為登入狀態。 |
| • | 啟用單一登入 (SSO) 時，請務必提供特定的 SSO 網域。假設一般網域 (例如 .co.uk) 允許網頁瀏覽器將 ISA Server 單一登入 (SSO) Cookie 傳送到該網域中的任何網站，這樣會帶來安全性風險。 |
| • | 假設您建立使用表單型驗證和 RSA SecurID 的網頁接聽程式，並在表單中啟用 [在表單中收集其他委派認證]，在此情況下，ISA Server 不會驗證使用者針對其他認證輸入相同或不同的名稱。 |
附註:並不支援不同網頁接聽程式之間的單一登入 (SSO)。已發行伺服器必須共用相同的網域名稱系統 (DNS) 尾碼。例如，發行 mail.fabrikam.com 和 team.fabrikam.com 時，您可以設定單一登入 (SSO)。發行 mail.fabrikam.com 和 mail.contoso.com 時，則無法設定單一登入 (SSO)。DNS 尾碼的開頭是點，後面接著完整的字串。例如，您應該使用 DNS 尾碼 contoso.com，在 mail.detroit.contoso.com 和 mail.cleveland.contoso.com 之間設定單一登入 (SSO)。
兩個因素的驗證方式
兩個因素的驗證方式提供更高的安全性，因為它會要求使用者必須符合兩項驗證準則：使用者名稱/密碼組合及權杖或憑證，也就是使用者所知資訊和所擁有的項目。在下列實例中，ISA Server 會支援兩個因素的驗證方式：
| • | 使用者具備憑證。 |
| • | 使用者具備提供密碼的 SecurID 權杖。 |
| • | 使用者具備提供密碼的一次有效密碼權杖。 |
智慧卡的使用是具備憑證的兩個因素之驗證方式的典型範例。ISA Server 可以使用智慧卡所含的憑證，與儲存使用者和憑證資訊的伺服器進行驗證。藉由比較使用者資訊 (使用者名稱和密碼) 與所提供的憑證，伺服器會驗證認證，而 ISA Server 會驗證使用者。
重要:工作群組中的 ISA Server 部署並不支援使用用戶端憑證之兩個因素的驗證方式。
認證快取
ISA Server 2006 可以快取基本及表單型使用者認證，因而改善針對其他用戶端要求重新驗證認證的效能。使用認證快取時，ISA Server 會在每個 TCP 工作階段驗證一次認證，也就是針對工作階段的第一個 HTTP 要求進行驗證，並於驗證後快取認證。而 ISA Server 會將後續 HTTP 要求的認證與第一個要求中所快取的已驗證認證相互比較，藉此進行驗證。
您可以在網頁接聽程式內容中啟用認證快取。依預設，此功能是停用的。
只有針對 Active Directory 驗證、透過 LDAP 進行驗證、RADIUS 驗證，以及當用戶端使用 HTTP 基本驗證或表單型驗證提供認證時，才會支援認證快取。
驗證處理程序
ISA Server 中的驗證處理程序具有三項元件：
| • | 收到用戶端認證。 |
| • | 向 Active Directory、RADIUS 或 SecurID 驗證管理員等驗證提供者驗證用戶端認證。 |
| • | 將驗證委派給 ISA Server 後面的 Web 伺服器，例如執行 SharePoint Portal Server 2003 的伺服器。 附註:前兩項元件會在接收用戶端要求的網頁接聽程式上進行設定。第三項元件則是設定於發行規則上。這表示您可以針對不同規則使用相同的接聽程式，並且可以具有不同的委派類型。 |
下圖會示範表單型驗證的驗證處理程序。請注意，這只是描述主要相關步驟的簡化說明。
步驟 1，接收用戶端認證：用戶端會傳送要求以連線至公司內部網路的 Outlook Web Access 伺服器。用戶端會在 HTML 表單中提供認證。
步驟 2 和 3，傳送認證：ISA Server 會傳送認證給驗證提供者，例如進行 Active Directory 驗證的網域控制站，或是 RADIUS 伺服器，並從驗證提供者接收已驗證使用者的認可訊息。
步驟 4，驗證委派：ISA Server 會將用戶端的要求轉送到 Outlook Web Access 伺服器，並使用用戶端的認證向 Outlook Web Access 伺服器自我驗證。Outlook Web Access 伺服器將重新驗證那些認證，而且通常是使用相同的驗證提供者。
附註:Web 伺服器必須設為使用與 ISA Server 所使用委派方法相符的驗證配置。
步驟 5，伺服器回應：Outlook Web Access 伺服器會傳送回應給用戶端，而 ISA Server 會攔截此回應。
步驟 6，轉寄回應：ISA Server 會將回應轉送至用戶端。
附註:| • | 如果您並未限制已驗證使用者的存取權，則當允許存取的規則套用至所有使用者時，ISA Server 將不會驗證使用者的認證。ISA Server 會依據設定的委派方法，使用使用者的認證向 Web 伺服器進行驗證。 |
| • | 建議您將每個發行規則套用至所有已驗證的使用者或特定使用者組，而不是在網頁接聽程式上選取需要驗證所有使用者，因為後者會要求任何透過接聽程式連線的使用者進行驗證。 |
收到用戶端認證的用戶端驗證方
ISA Server 網頁接聽程式接受下列來自用戶端的驗證類型：
| • | 沒有驗證 |
| • | 表單型驗證 |
| • | HTTP 驗證 (在 HTTP 標頭接收) |
| • | 用戶端憑證驗證 |
沒有驗證
您可以選擇不需要進行驗證。如果這樣做，您將無法在使用此網頁接聽程式的規則上設定委派方法。
表單型驗證
ISA Server 2006 中的表單型驗證可用於發行任何 Web 伺服器。ISA Server 有三種可用的表單型驗證類型：
| • | 密碼表單。使用者會在表單上輸入使用者名稱和密碼。這是 Active Directory、LDAP 和 RADIUS 認證驗證所需的認證類型。 |
| • | Passcode 表單。使用者會在表單上輸入使用者名稱和密碼 (Passcode)。這是 SecurID 和 RADIUS 一次有效密碼驗證所需的認證類型。 |
| • | Passcode / 密碼表單。使用者會輸入使用者名稱和 PASSCODE 及使用者名稱和密碼。使用者名稱和 PASSCODE 適用於使用 SecurID 或 RADIUS 一次有效密碼驗證方法向 ISA Server 進行驗證，而使用者名稱和密碼則適用於委派。 |
以基本驗證為後援
依預設，表單型驗證無法用於特定用戶端時，ISA Server 就需要改用基本驗證。此項目設定於使用者代理程式對應集合 FPCRuleElements.UserAgentMappings 中的 ISA Server COM。如需相關資訊，請參閱 ISA Server SDK 文件。
行動用戶端的表單
ISA Server 會針對各種行動用戶端提供表單。這些表單是在 CHTML 和 XHTML (代表 XHTML-MP 表單) 資料夾中，位於 ISA Server Installation Directory\CookieAuthTemplates\ISA 底下。ISA Server 會依據行動用戶端提供的使用者代理程式標頭，判斷要提供的表單類型。
表單型驗證中的密碼管理
使用表單型驗證時，ISA Server 可讓您警告使用者密碼即將過期 (在您設定的天數之後)，並允許使用者變更密碼。這兩項功能可分開或搭配使用。例如，您可以警告使用者密碼即將過期，但是不允許他們變更密碼。或是您可以允許他們變更密碼，但是不提供密碼即將過期的警告。
允許使用者變更密碼時，便可在登入表單上使用該選項。當您將 ISA Server 設定為警告使用者密碼即將過期，使用者會收到個別的警告頁面，並在其上選擇是否變更密碼。
附註
| • | 您可以完全自訂表單型驗證的 HTML 表單。 |
| • | 將 ISA Server 設定為需要驗證時，由於發行規則會套用至特定使用者組或「所有已驗證的使用者」，或是將網頁接聽程式設定為「需要驗證所有使用者」，因此 ISA Server 會先驗證認證，然後再轉送要求。 |
| • | 依預設，用戶端瀏覽器的語言設定會決定 ISA Server 所提供表單的語言。ISA Server 提供 26 種語言的表單。ISA Server 也可以設定以特定語言處理表單，不管瀏覽器語言而何。 |
安全性注意事項
| • | 當您針對表單型驗證設定逾時，建議要比已發行伺服器施行的逾時短。如果已發行伺服器比 ISA Server 先逾時，使用者可能會誤認為工作階段結束。因為工作階段會保持開啟直到使用者主動關閉或 ISA Server 按照表單設定啟動逾時，這樣可讓攻擊者使用工作階段。 |
| • | 您應先確定已將網頁應用程式設計為抵抗工作階段行進攻擊 (也稱為跨網站張貼、跨網站要求偽造或引誘攻擊)，然後再使用 ISA Server 發行該 Web 應用程式。由於用戶端必須針對透過發行 ISA Server 防火牆存取的所有網站，使用相同信任層級，因此這點對於透過 ISA Server 發行的 Web 伺服器而言尤其重要。 |
| • | 在需要用戶端憑證，但使用者拒絕提供憑證的表單型驗證實例中，使用者將存取登入表單。然後 ISA Server 會因為缺少用戶端憑證而拒絕登入。 |
| • | 表單自訂涉及修改 Strings.txt 檔。如果您提供 Strings.txt 檔給協力廠商進行修改，請確認檔案中沒有新增任何文字，因為這些文字可能會提供攻擊網路的管道。 |
HTTP 驗證
下列是支援的 HTTP 驗證類型：
| • | 基本驗證 |
| • | 摘要和 WDigest 驗證 |
| • | 整合式 Windows 驗證 |
基本驗證
基本驗證方法是廣為使用的工業標準方法，適用於收集使用者名稱及密碼資訊。基本驗證會以可讀取的文字字元格式傳送及接收使用者資訊。雖然密碼及使用者名稱已編碼，但不會搭配使用基本驗證與加密。
附註:經由基本驗證傳輸的密碼是不安全的，並且可在傳輸期間讀取它們。如果是使用基本驗證，建議您使用 SSL 加密流量。
下列步驟簡述使用基本驗證來驗證用戶端的方式：
1. | 會提示使用者輸入 Windows 帳戶使用者名稱及密碼，也稱為認證。 |
2. | ISA Server 會接收含有認證的 HTTP 要求，並且會視規則所需，透過指定的驗證提供者驗證認證。 |
3. | 將 HTTP 要求傳到 Web 伺服器時，ISA Server 會依據設定的委派方法，使用認證向 Web 伺服器進行驗證。Web 伺服器必須設為使用與 ISA Server 所使用委派方法相符的驗證配置。純文字密碼在網路上傳送之前會以 Base64 加以編碼。 附註:Base64 編碼不是加密。如果以 Base64 編碼的密碼在網路上被網路探聽者攔截到，未經授權的使用者就可以解碼並重新利用密碼。 |
4. | 當 ISA Server 確認使用者名稱和密碼對應到有效的 Windows 使用者帳戶 (Active Directory 或 LDAP) 或 RADIUS 帳戶時，就會建立連線。 |
基本驗證的好處是由於它屬於 HTTP 規格的一部份，而且所有 HTTP 用戶端都支援它。壞處是使用基本驗證的網頁瀏覽器會以未加密的形式傳輸密碼。藉由監視您網路上的通訊，攻擊者或有惡意的使用者可以使用隨手可得的工具來攔截及解碼這些密碼。因此，除非您確信連線是安全的 (例如專線或 SSL 連線)，否則不建議您使用基本驗證。
摘要和 WDigest 驗證
HTTP 驗證包含摘要驗證及新版的摘要驗證，也就是 WDigest 驗證。
摘要驗證
摘要驗證提供與基本驗證相同的功能，但它在傳輸驗證認證時會使用不同的方法：
1. | 驗證認證會通過一個單向程序，通常稱為「雜湊」。這個程序的結果就稱為雜湊或訊息摘要，而且它很難解密，亦即無法從雜湊解譯原始文字。 |
2. | 在雜湊處理之前會先將其它資訊新增到密碼中，如此一來，任何人都無法截取密碼雜湊，並用它來模仿真正的使用者。 |
3. | 系統會新增一些值來協助識別使用者、使用者的電腦，以及使用者所屬的網域。 |
4. | 也會新增時間戳記來防止使用者在密碼撤銷之後還繼續使用。這明顯優於基本驗證，因為未獲授權的人將無法攔截及使用密碼。 |
摘要驗證依賴 HTTP 1.1 通訊協定，這些通訊協定定義在全球資訊網協會 (W3C) 網站 (英文) 上的 RFC 2617 規格中。因為摘要驗證需要 HTTP 1.1 相容性，因此並非所有瀏覽器都支援它。如果於摘要驗證啟用時，有個與 HTTP 1.1 不相容的瀏覽器要求檔案，則會因為用戶端不支援摘要驗證，而拒絕要求。
摘要驗證只能在 Windows 網域中使用。摘要驗證只會和 Microsoft Windows Server® 2003 和 Windows® 2000 Server 網域帳戶搭配使用，而且可能會要求帳戶將密碼儲存為加密的純文字。
重要:只有在網域控制站具有提出要求之使用者密碼的可回復加密 (純文字) 複本 (儲存在 Active Directory 中) 時，才能夠完成摘要驗證。若要允許以純文字儲存密碼，則必須啟動 Active Directory 中使用者之 [帳戶] 索引標籤上的 [使用可回復加密來存放密碼] 設定。或者，您可以設定群組原則來啟用這個功能。在進行這項設定之後，您需要設定新密碼來啟用此功能，因為已無法判定舊密碼。
WDigest 驗證
與一般的摘要驗證不同，WDigest 不需要以可復原的加密來儲存密碼。ISA Server 2006 所支援的 WDigest 是摘要驗證的新版本。
若使用 WDigest，使用者名稱及網域名稱有區分大小寫。使用者必須完全按照儲存於 Active Directory 的資料鍵入使用者名稱 (和網域名稱)。這與摘要、基本及整合的 Windows 驗證不同，它們只有密碼要區分大小寫。
當 ISA Server 及網域都是使用 Windows Server 2003 作業系統時，預設驗證是 WDigest。這表示當您在 Windows Server 2003 環境中選取摘要驗證時，實際上是選取 WDigest。
用戶端驗證處理程序
下列步驟簡述使用摘要驗證來驗證用戶端的方式：
1. | 用戶端提出要求。 |
2. | ISA Server 拒絕要求，並請用戶端提供驗證資訊。 |
3. | 網域控制站通知 ISA Server 驗證結果。 |
4. | 如果用戶端通過驗證，則 ISA Server 會檢查防火牆原則，來判定是否應視需要取得物件。 |
整合式 Windows 驗證
整合式 Windows 驗證使用 NTLM、Kerberos 及交涉驗證機制。這些驗證是安全的驗證形式，因為在透過網路傳送使用者名稱和密碼之前，會雜湊使用者名稱和密碼。當您啟用 NTLM、Kerberos 及交涉驗證時，使用者的瀏覽器將透過與您 Web 伺服器的密碼編譯交換 (包括雜湊) 來證明它知道密碼。
附註:使用 Windows 整合式驗證時，一律必須搭配使用者名稱來提供使用者的網域，格式為 domain\username。
用戶端驗證處理程序
下列步驟概述使用整合式 Windows 驗證來驗證用戶端的方式：
1. | 根據瀏覽器設定，此驗證起初不會提示使用者輸入名稱及密碼。用戶端電腦上的現行 Windows 使用者資訊是供此驗證使用。 |
2. | 如果驗證交換起初無法識別使用者，則瀏覽器將提示使用者輸入 Windows 帳戶使用者名稱及密碼，它會使用整合式 Windows 驗證來處理它們。 |
3. | 網頁瀏覽器會繼續提示使用者，直到使用者輸入有效的使用者名稱和密碼，或是關閉提示對話方塊。 |
安全性注意事項
| • | 外部連線的驗證將會使用 NTLM 驗證，因此建議您針對 ISA Server 和用戶端之間的流量使用 SSL 加密。NTLM 驗證是針對每個連線，而且加密會防止過時的 Proxy 裝置在 Intern0065t 上不適當地重複使用連線。 |
| • | 請注意，整合式 Windows 驗證依賴 Active Directory 伺服器來驗證用戶端憑證。每當需要用戶端驗證時，ISA Server 即會與 Active Directory 伺服器通訊。基於這個理由，我們建議您為 Active Directory 和 ISA Server 建立一個保護網路，來防止使用者 (包括外部及內部) 存取通訊。 |
用戶端憑證驗證
在用戶端憑證實例中，憑證由用戶端提供，ISA Server 根據該憑證驗證用戶端。這可能是嵌入智慧卡的憑證，或行動裝置使用的憑證，以便連線到 Microsoft ActiveSync®。
驗證用戶端認證的方法
您可以設定 ISA Server 驗證用戶端認證的方法。ISA Server 支援以下提供者和通訊協定：
| • | 沒有驗證 (允許內部伺服器處理驗證) |
| • | Windows Active Directory |
| • | 透過 LDAP 通訊協定的 Active Directory |
| • | RADIUS |
| • | RADIUS 一次有效密碼 |
| • | SecurID |
附註:如果發行規則具備使用認證驗證特定表單的網頁接聽程式，則必須使用與該驗證表單一致的使用者組。例如，發行規則具備使用 LDAP 認證驗證的網頁接聽程式，也必須使用由 LDAP 使用者組成的使用者組。它無法包含 Active Directory 使用者。
設定用戶端認證的接收及驗證
您可以在發行規則的網頁接聽程式上，設定用戶端認證的接收及驗證。
在新增網頁接聽程式定義精靈中，使用 [驗證設定] 頁面，並在網頁接聽程式內容中，使用 [驗證] 索引標籤。
重要:當您使用相同的網頁接聽程式在相同網域中發行多個應用程式時，已驗證可使用某應用程式的使用者也將可以存取其他應用程式，即使尚未啟用單一登入也一樣。
Windows Active Directory
在 Windows Active Directory 驗證中，會將用戶端輸入的認證傳給網域控制站，以便依據 Active Directory 的使用者清單檢查認證。因此用戶端必須採用這些格式之一，輸入網域控制站可辨識的認證：
| • | SAM 帳戶名稱 (domain\username) |
| • | 使用者主要名稱 (username@domain.com) |
| • | 辨別名稱 |
只有當 ISA Server 是網域成員 (在網域控制站的相同網域或信任的網域中) 時，才會進行 Active Directory 驗證。
透過 LDAP 通訊協定的 Active Directory
此驗證方法類似 Windows Active Directory 驗證。在此方法中，ISA Server 會透過 LDAP 通訊協定連接 LDAP 伺服器 (支援 LDAP、LDAPS、LDAP-GC 和 LDAPS-GC)。請注意，每個網域控制站都是 LDAP 伺服器。LDAP 伺服器具備 Active Directory 使用者認證的存放區。每個網域控制站只會在自己的網域中驗證使用者，因此依預設 ISA Server 會查詢通用類別目錄，以取得樹系資料來驗證使用者認證。
用戶端必須使用以下其中一種格式，輸入 Active Directory 可辨識的認證：
| • | SAM 帳戶名稱 (domain\username) |
| • | 使用者主要名稱 (username@domain.com) |
| • | 辨別名稱 |
RADIUS
RADIUS 是用來提供認證驗證。當 ISA Server 擔任 RADIUS 用戶端時，會以 RADIUS 訊息的格式，將使用者認證和連線參數資訊傳送到 RADIUS 伺服器。RADIUS 伺服器會驗證 RADIUS 用戶端要求，並傳回 RADIUS 訊息回應。
因為除了驗證用戶端認證外，RADIUS 伺服器還可授權它們，所以 ISA Server 從 RADIUS 伺服器收到的回應 (指出未核准用戶端認證)，實際上可能是指出 RADIUS 伺服器並未授權用戶端。即使已驗證認證，ISA Server 仍有可能根據 RADIUS 伺服器授權原則，來拒絕用戶端要求。
附註:當 RADIUS 使用者提供認證給 ISA Server 時，認證必須以 domain\user 形式傳遞，而不是 user@domain。
您可以設定 ISA Server 來使用特定的 RADIUS 伺服器，它們將負責執行 RADIUS 使用者驗證。
連出要求的 RADIUS 驗證
當使用網際網路驗證服務 (IAS) 做為您的 RADIUS 伺服器時，請確定在 ISA 遠端存取原則的撥入設定檔中啟用未加密的驗證，即「密碼驗證通訊協定 (PAP)」。在每個設定檔 IAS 設定上為 PAP 啟用 IAS。所有符合原則條件的 RADIUS 用戶都將能夠使用 PAP 連接至 IAS 伺服器。
設定 ISA Server 以供 RADIUS 驗證
當您在 ISA Server 上設定網頁接聽程式時，請選取 RADIUS 驗證作為驗證提供者。新增 RADIUS 伺服器時，必須設定下列項目：
| • | 伺服器名稱。 RADIUS 伺服器的主機名稱或 IP 位址。 |
| • | 機密。 RADIUS 用戶端和 RADIUS 伺服器會共用機密，將在彼此之間傳送的訊息加密。您必須在 ISA Server 和 IAS 伺服器上設定相同的共用機密。 |
| • | 驗證連接埠。 ISA Server 會使用 RADIUS 伺服器正在其上接聽的使用者資料包通訊協定 (UDP) 連接埠 傳送其驗證要求。當您正在使用 IAS 的預設安裝充當 RADIUS 伺服器時，不需要變更預設值 1812。 |
附註:當設定 ISA Server 進行 RADIUS 驗證時，RADIUS 伺服器的設定將套用至使用 RADIUS 驗證的所有規則或網路物件。
安全性考量
「RADIUS 使用者密碼」隱藏機制可能無法為密碼提供足夠的安全性。RADIUS 隱藏機制會使用 RADIUS 共用機密及「要求驗證者」，並使用 MD5 雜湊演算法來加密「使用者密碼」及其他屬性，例如「通道密碼」及「MS-CHAP-MPPE 金鑰」。RFC 2865 會指出評估威脅環境並決定是否應使用其他安全性的潛在需要。
您可以使用具有封裝安全承載 (ESP) 的網際網路通訊協定安全性 (IPsec) 及加密演算法 (例如三重 DES (3DES))，來為隱藏的屬性提供其他保護，為整個 RADIUS 訊息提供資料機密性。請遵循這些方針：
| • | 使用 IPsec 為 RADIUS 用戶端及伺服器提供額外的安全性。 |
| • | 要求使用嚴密的使用者密碼。 |
| • | 使用驗證計數及帳戶鎖定，以協助來保護使用者密碼免受字典攻擊。 |
| • | 使用由字母、數字與標點之隨機序列所組成的長共用機密。經常變更它以協助保護您的 IAS 伺服器。 |
| • | 當您使用密碼型驗證時，請加強網路上的嚴密密碼原則，以使其不易受到字典攻擊。 |
RADIUS 一次有效密碼
ISA Server 可以使用 RADIUS 一次有效密碼進行認證驗證。一次有效密碼機制通常由可攜式裝置 (實體權杖) 和伺服器組成。伺服器和裝置每個都會根據給定頻率產生新密碼 (passcode)。PASSCODE 是每個裝置特有的。(沒有裝置能共用相同密碼)。伺服器會驗證 PASSCODE 已安裝於 RADIUS 伺服器上，而且可與現有 RADIUS 使用者清單相關聯。每個密碼只能使用一次。
使用者會在 ISA Server 提供的表單上，輸入可攜式裝置提供的使用者名稱和密碼。ISA Server 將使用者名稱和密碼傳送給 RADIUS 伺服器進行驗證。
由於無法再次使用密碼，因此 ISA Server 不會針對每個要求重新驗證認證。相反的，ISA Server 會向用戶端發出 Cookie，允許持續通訊而無需重新驗證。
如果使用者登入失敗超過指定次數，某些 RADIUS 伺服器會封鎖該使用者的登入。如果惡意使用者故意使用合法的使用者名稱及錯誤的密碼多次嘗試登入，系統就會封鎖該使用者，直到您重設該使用者的存取為止。建議您在 RADIUS 一次有效密碼伺服器上停用鎖定功能，以避免發生這種情形。ISA Server [每分鐘，每一 IP 位址的 HTTP 要求數] 設定 (可於 ISA Server 的洪水安全防護功能內容上設定) 能減輕猛烈的密碼猜測攻擊，因此您可以安全地停用 RADIUS 鎖定功能。
SecurID
ISA Server 也會使用 SecurID 進行認證驗證。RSA 提供的 SecurID 產品強制要求遠端使用者必須提供下列資訊，才能存取受保護的資源：
| • | 個人識別碼 (PIN) Personal identification number (PIN) |
| • | 產生具時效的一次有效密碼的實體權杖 |
PIN 及權杖產生的一次有效密碼無法在彼此隔離的情況下取得存取權。這兩者都是必要的。
當使用者嘗試存取 RSA SecurID 保護的網頁時，ISA Server 電腦將代表受它保護的伺服器 (執行 IIS) 檢查是否有 Cookie。僅在最近驗證了使用者時，這個 Cookie 才會存在，但不會持續存在。如果缺少使用者的 Cookie，將提示使用者輸入 SecurID 的使用者名稱及密碼。密碼包括使用者的 PIN 及權杖碼組合。ISA Server 電腦上的 RSA ACE/Agent® 將傳遞這些認證到 RSA ACE/Server® 電腦以進行驗證。如果已順利驗證認證，將把 Cookie 傳遞到使用者的瀏覽器，以在工作階段期間進行後續的活動，而且授與使用者存取內容的權限。
附註
| • | 若是 SecurID 委派，ISA Server 會產生與 RSA Authentication Agent 5.0 相容的 Cookie。使用 SecurID 委派時，必須設定驗證代理程式電腦以信任那些 Cookie。若要這樣做，請在驗證代理程式電腦登錄，將 Agent50CompatibleCookies 字串值新增到 HKLM\Software\SDTI\RSAAgent 底下。 |
| • | 若以多重網路介面卡來設定 ISA Server，並以啟用的 RSA SecurID 驗證來建立網頁接聽程式，則您應明確設定網路介面卡位址，讓 ISA Server 進行驗證時可以透過其連線至 RSA ACE/Server。否則，ISA Server 可能無法執行 SecurID 驗證。請在登錄機碼 HKEY_LOCAL_MACHINE\SOFTWARE\SDTI\AceClient\PrimaryInterfaceIP 中指定 IP 位址，作為字串值。 |
| • | 建議您使用 SSL 加密用戶端與 ISA Server 之間的通訊。 |
| • | 若需 RSA ACE/Server 安裝、設定及驗證概念的相關資訊，請參閱 RSA 網站上所提供的說明文件，網址為 http://www.rsasecurity.com |
| • | RSA SecurID 是以 RSA Security Inc. 提供的技術為基礎。 |
RSA SecurID 的驗證如何運作
本節中將使用下列術語：
| • | RSA 驗證管理員： 此電腦將保留使用者、群組、主機及權杖的相關資訊。對於每一位使用者而言，RSA ACE/伺服器能維護使用者可以登入的主機清單，以及可用來區別主機的登入名稱。 |
| • | RSA ACE/Agent： 此電腦會提供網頁內容 (ISA Server 電腦或陣列)，並且要求使用者提供 RSA SecurID 的認證。 |
| • | 用戶端： 這通常是接受網頁內容的網頁瀏覽器。 |
當用戶端將 GET /x 要求傳送到 ISA Server 時，下列處理程序即會發生：
1. | 表單型驗證的 ISA Server 網頁篩選器 (表單型驗證篩選器) 會攔截要求，並傳回 RSA SecurID 驗證表單給用戶端。 | ||||||
2. | 用戶端需要利用登入名稱及密碼來填寫表單。有時還可能選擇需要用戶端提供其他認證以用來進行委派。 | ||||||
3. | 瀏覽器使用 HTTP POST 方法，將表單傳回給網頁篩選器。 | ||||||
4. | 表單型驗證篩選器會跟 RSA 驗證管理員溝通這些細節，以確認允許該使用者使用 ISA Server 電腦進行存取。如果答案是確定的，網頁篩選器將傳回一個包括 Set-Cookie 標頭的回應到用戶端。 | ||||||
5. | Set-Cookie 標頭會將一個 Cookie 寫入瀏覽器的記憶體。此 Cookie 包含使用者的相關資訊。這個資訊是利用僅 ISA Server 知道的秘密來簽署的。這表示其他使用者無法修改 Cookie。 | ||||||
6. | 回應包含一個 Refresh 標頭，指示瀏覽器將原始 GET /x 要求重新傳送到伺服器。 | ||||||
7. | 當網頁篩選器利用 Cookie 接受要求時，它會驗證 Cookie 是否有效，方法為檢查：
|
驗證委派
驗證認證之後，可以設定發行規則，使用下列其中一個方法將認證委派給已發行的伺服器：
| • | 沒有委派，用戶端無法直接驗證 |
| • | 沒有委派，但用戶端可以直接驗證 |
| • | 基本 |
| • | NTLM |
| • | NTLM/Kerberos (交涉) |
| • | SecurID |
| • | Kerberos 限制委派 |
設定驗證委派
用戶端認證的委派已設定於發行規則上。在 [發行規則精靈] 中，於 [驗證委派] 頁面設定此項目。在發行規則內容中，驗證設定是位於 [驗證委派] 索引標籤上。
沒有委派，用戶端無法直接驗證
這是 ISA Server 2006 中的新功能，其中並未委派認證。這是為了防止意外將認證委派到組織中，從而在此處遭到探聽。這是部分 ISA Server 發行精靈中的預設設定，因此若想委派認證，則必須變更預設值。
沒有委派，但用戶端可以直接驗證
當您選取 [沒有委派，但用戶端可以直接驗證] 委派方法時，使用者的認證會傳送到目的地伺服器，而無需對 ISA Server 部分執行任何其他動作。然後，用戶端與目的地伺服器會交涉驗證。
基本
在「基本」委派中，認證以純文字轉寄到需要認證的伺服器。如果驗證失敗，ISA Server 會以網頁接聽程式使用的驗證類型取代委派。如果伺服器需要不同類型的認證，會觸發 ISA Server 警示。
NTLM
在 NTLM 委派中，ISA Server 會使用 NTLM 挑戰/回應驗證通訊協定委派認證。如果驗證失敗，ISA Server 會以網頁接聽程式使用的驗證類型取代委派。如果伺服器需要不同類型的認證，會觸發 ISA Server 警示。
NTLM/Kerberos (交涉)
當您選取 [交涉] 作為委派方法時，ISA Server 會先嘗試從網域控制站取得用戶端的 Kerberos 票證。如果 ISA Server 未收到 Kerberos 票證，則會使用交涉配置透過 NTLM 委派認證。如果 ISA Server 收到 Kerberos 票證，則會使用交涉配置透過 Kerberos 委派認證。如果驗證失敗，ISA Server 會為用戶端提供伺服器的失敗通知。如果伺服器需要不同類型的認證，會觸發 ISA Server 警示。
用於取得票證的預設服務主要名稱 (SPN) 為 http/internalsitename。若為伺服器陣列，服務主要名稱 (SPN) 為陣列名稱。您可以在規則的 [驗證委派] 索引標籤的 [ISA Server 管理] 中變更預設服務主要名稱 (SPN)。
附註:在 Microsoft Exchange Server 2003 中，IIS 是在網路服務帳戶下執行。ISA Server 會使用萬用字元服務主要名稱 (SPN) HTTP\*，並以已發行站台的主機名稱取代星號。
SecurID
用戶端提供 SecurID 認證時，您可以使用 SecurID 驗證委派。ISA Server 會將專屬 SecurID Cookie 傳送到發行伺服器。請注意，ISA Server 與已發行伺服器必須具有相同的網域機密與 Cookie 名稱。
Kerberos 限制委派
ISA Server 2006 採用 Kerberos 限制委派，Kerberos 通訊協定轉換與限制委派 (英文) 中有相關說明。在沒有 Kerberos 限制委派的情況下，ISA Server 只能在使用 [基本] 或表單型驗證接收用戶端認證時委派認證。在 Kerberos 限制委派的情況下，ISA Server 可以接受其他類型的用戶端認證，如用戶端憑證。網域控制站必須啟用 ISA Server，才能使用 Kerberos 限制委派 (限制為特定服務主要名稱)。
如果驗證失敗，ISA Server 會為用戶端提供伺服器的失敗通知。如果伺服器需要不同類型的認證，會觸發 ISA Server 警示。
附註
| • | 使用 Kerberos 限制委派會要求您設定 Active Directory，將 ISA Server 識別為信任以進行委派。 |
| • | 用於取得票證的服務主要名稱 (SPN) 為 http/internalsitename。若為伺服器陣列，服務主要名稱 (SPN) 為陣列名稱。您可以在規則的 [驗證委派] 索引標籤的 [ISA Server 管理] 中變更預設服務主要名稱 (SPN)。 |
| • | 若要使用 Kerberos 限制委派，網域必須於 Windows Server 2003 網域作用層級中執行。 |
| • | Kerberos 驗證需視通常會片段化的 UDP 封包而定。如果 ISA Server 電腦或陣列 (在 Enterprise Edition 中) 位於網域中，並已針對 IP 片段啟用封鎖，則 Kerberos 驗證將會失敗。例如，如果電腦在使用者登入期間使用 Kerberos 進行驗證，則登入將會失敗。在使用 Kerberos 驗證的實例中，建議您不要針對含有 IP 片段的封包啟用封鎖。 |
| • | 依預設 SharePoint Portal Server 2003 已停用 Kerberos，因此 NTLM/Kerberos (交涉) 和 Kerberos 限制委派將不會與 SharePoint 發行搭配使用。若要啟用 Kerberos，請遵循 Microsoft 說明及支援上的指示。 |
| • | 在 Microsoft Exchange Server 2003 中，IIS 是在網路服務帳戶下執行，而 ISA Server 會使用萬用字元服務主要名稱 (SPN) HTTP\*，並以已發行站台的主機名稱取代星號。 |
用戶端認證與委派方法的有效組合
並非每個委派方法對特殊的用戶端認證類型都有效。下表摘要說明有效組合。
| 收到的用戶端認證 | 驗證提供者 | 委派 |
表單型驗證 (僅有密碼) 基本 | Active Directory (Windows) Active Directory (LDAP) RADIUS | 沒有委派，但用戶端可以直接驗證 沒有委派，用戶端無法直接驗證 基本 NTLM 交涉 Kerberos 限制委派 |
摘要 整合式 | Active Directory (Windows) | 沒有委派，但用戶端可以直接驗證 沒有委派，用戶端無法直接驗證 Kerberos 限制委派 |
使用密碼的表單型驗證 | SecurID RADIUS 一次有效密碼 | 沒有委派，但用戶端可以直接驗證 沒有委派，用戶端無法直接驗證 SecurID Kerberos 限制委派 |
表單型驗證 (PASSCODE 和密碼) | SecurID RADIUS 一次有效密碼 | 沒有委派，但用戶端可以直接驗證 沒有委派，用戶端無法直接驗證 基本 NTLM 交涉 SecurID |
用戶端憑證 | Active Directory (Windows) | 沒有委派，但用戶端可以直接驗證 沒有委派，用戶端無法直接驗證 Kerberos 限制委派 |