共用方式為

適用於 Windows Server 的 AD FS 需求

以下是部署 AD FS 時必須符合的各種需求：

憑證需求

憑證在同盟伺服器、Web 應用程式 Proxy、宣告感知 (Claims-Aware) 應用程式及 Web 用戶端之間進行安全通訊時扮演最重要的角色。 憑證的需求會根據您是否設定同盟伺服器或 Proxy 電腦而有所不同，如本節所述。

同盟伺服器憑證

憑證類型 需求、支援與須知事項
安全通訊端層 (SSL) 憑證這是這是標準的 SSL 憑證，可用來保護同盟伺服器與用戶端之間的通訊安全。 - 此憑證必須是公開信任* X509 v3 憑證。
- 所有存取任何 AD FS 端點的用戶端都必須信任此憑證。 強烈建議使用由公開 (第三方) 憑證授權單位單位 (CA) 簽發的憑證。 您可以在測試實驗室環境中的同盟伺服器上成功使用自我簽署的 SSL 憑證。 不過，針對生產環境，建議您從公用 CA 取得憑證。
- 支援 Windows Server 2012 R2 針對 SSL 憑證支援的任何金鑰大小。
- 不支援使用 CNG 金鑰的憑證。
- 與加入工作場所網路/裝置註冊服務搭配使用時，AD FS 服務的 SSL 憑證主體別名必須包含值 enterpriseregistration，後面接著貴組織的使用者主體名稱 (UPN) 尾碼，例如 enterpriseregistration.contoso.com。
- 支援萬用字元憑證。 當您建立 AD FS 伺服器陣列時，系統會提示您提供 AD FS 服務的服務名稱 (例如，adfs.contoso.com。
- 強烈建議針對 Web 應用程式 Proxy 使用相同的 SSL 憑證。 不過，當透過 Web 應用程式 Proxy 支援 Windows 整合式驗證端點，以及開啟擴充保護驗證 (預設設定) 時，這必須相同。
- 此憑證的主體名稱可用來表示您部署的每個 AD FS 執行個體的同盟服務名稱。 基於這個理由，您可能想要考慮在任何 CA 簽發的新憑證上，選擇對合作夥伴而言最能代表貴公司或組織名稱的主體名稱。
憑證的身分識別必須符合同盟服務名稱 (例如，fs.contoso.com)。身分識別是 dNSName 類型的主體別名延伸模組，如果沒有主體別名項目，則指定為一般名稱的主體名稱。 憑證中可以有多個主體別名項目，前提是其中一個項目符合同盟服務名稱。
- 重要事項：在 AD FS 伺服器陣列的所有節點上及在 AD FS 伺服器陣列的所有 Web 應用程式 Proxy 伺服器上，強烈建議使用相同的 SSL 憑證。
服務通訊憑證：這個憑證會啟用 WCF 訊息安全性，來保護同盟伺服器之間的通訊。 - 根據預設，SSL 憑證會用來做為服務通訊憑證。 但您也可以選擇將另一個憑證設定為服務通訊憑證。
- 重要事項：如果您使用 SSL 憑證作為服務通訊憑證，當 SSL 憑證到期時，請務必將更新的 SSL 憑證設定為服務通訊憑證。 這不會自動發生。
- 此憑證必須由使用 WCF 訊息安全性之 AD FS 的用戶端信任。
- 我們建議使用公開 (第三方) 憑證授權單位 (CA) 所簽發的伺服器驗證憑證。
- 服務通訊憑證不能是使用 CNG 金鑰的憑證。
- 您可以使用 AD FS 管理主控台來管理此憑證。
權杖簽署憑證：這是標準的 X509 憑證，可以用來安全地簽署同盟伺服器簽發的所有權杖。 - 根據預設，AD FS 會建立具有 2048 位元金鑰的自我簽署憑證。
- 也支援 CA 發行的憑證，而且可以使用 AD FS 管理嵌入式管理單元來變更
- CA 發行的憑證必須透過 CSP 密碼編譯提供者儲存和存取。
- 權杖簽署憑證不能是使用 CNG 金鑰的憑證。
- AD FS 不需要外部註冊的憑證來進行權杖簽署。
AD FS 會在這些自我簽署憑證到期之前自動更新，先將新的憑證設定為次要憑證，讓合作夥伴取用它們，然後在稱為自動憑證變換的程序中翻轉至主要憑證。建議您使用預設、自動產生的憑證進行權杖簽署。
如果您的組織有原則需要為權杖簽署設定不同的憑證，您可以使用 PowerShell (使用 Install-AdfsFarm Cmdlet 的 –SigningCertificateThumbprint 參數) 在安裝時指定憑證。 安裝之後，您可以使用 AD FS 管理主控台或 PowerShell Cmdlet Set-AdfsCertificate 和 Get-AdfsCertificate 來檢視和管理權杖簽署憑證。
當外部註冊的憑證用於權杖簽署時，AD FS 不會執行自動憑證更新或變換。 此程序必須由系統管理員執行。
若要在一個憑證即將到期時允許憑證變換，可以在 AD FS 中設定次要權杖簽署憑證。 根據預設，所有權杖簽署憑證都會在同盟中繼資料中發佈，但 AD FS 只會使用主要權杖簽署憑證來實際簽署權杖。
權杖解密/加密憑證：這是用來解密/加密任何傳入權杖的標準 X509 憑證。 它也會在同盟中繼資料中發佈。 - 根據預設，AD FS 會建立具有 2048 位元金鑰的自我簽署憑證。
- 也支援 CA 發行的憑證，而且可以使用 AD FS 管理嵌入式管理單元來變更
- CA 發行的憑證必須透過 CSP 密碼編譯提供者儲存和存取。
- 權杖解密/加密憑證不能是使用 CNG 金鑰的憑證。
- 根據預設，AD FS 會產生並使用自己的內部產生和自我簽署憑證進行權杖解密。 AD FS 不需要外部註冊的憑證來達到此目的。
此外，AD FS 會在這些自我簽署憑證到期之前自動更新。
建議您使用預設、自動產生的憑證進行權杖解密。
如果您的組織有原則需要為權杖解密設定不同的憑證，您可以使用 PowerShell (使用 Install-AdfsFarm Cmdlet 的 –DecryptionCertificateThumbprint 參數) 在安裝時指定憑證。 安裝之後，您可以使用 AD FS 管理主控台或 PowerShell Cmdlet Set-AdfsCertificate 和 Get-AdfsCertificate 來檢視和管理權杖解密憑證。
當外部註冊的憑證用於權杖解密時，AD FS 不會執行自動憑證更新。 此程序必須由系統管理員執行.
- AD FS 服務帳戶必須有權存取本機電腦個人存放區中之權杖簽署憑證的私鑰。 這會由安裝程式處理。 如果您隨後變更權杖簽署憑證，您也可以使用 AD FS 管理嵌入式管理單元來確保此存取權。

警告

用來進行權杖簽署和權杖解密/加密的憑證對於同盟服務的穩定性而言相當重要。 管理自有權杖簽署和權杖解密/加密憑證的客戶應確保這些憑證已完成備份，並可在復原事件期間獨立取得。

注意

在 AD FS 中，您可以將用於數位簽章的安全雜湊演算法 (SHA) 等級變更為 SHA-1 或 SHA-256 (較安全)。 AD FS 不支援將憑證與其他雜湊方法搭配使用，例如 MD5 (可與 Makecert.exe 命令列工具搭配使用的預設雜湊演算法)。 基於安全性最佳作法的考量，建議您針對所有簽章使用 SHA-256 (此為預設設定)。 建議您只有在必須與不支援使用 SHA-256 進行通訊的產品相互操作的情況下使用 SHA-1，例如，非 Microsoft 產品或 AD FS 的舊版版本。

注意

在您收到來自 CA 的憑證之後，請確定會將所有憑證匯入本機電腦的個人憑證存放區。 您可以使用 [憑證] MMC 嵌入式管理單元，將憑證匯入個人存放區。

硬體需求

下列最低和建議的硬體需求適用於 Windows Server 2012 R2 中的 AD FS 同盟伺服器：

硬體需求 最低需求 建議需求
CPU 速度 1.4 Ghz 64 位元處理器 四核心，2 GHz
RAM 512 MB 4 GB
磁碟空間 32 GB 100 GB

軟體需求

下列 AD FS 需求適用於 Windows Server® 2012 R2 作業系統內建的伺服器功能：

  • 若要能夠存取外部網路，您必須部署 Web 應用程式 Proxy 角色服務 - Windows Server® 2012 R2 遠端存取伺服器角色的一部分。 Windows Server® 2012 R2 中的 AD FS 不支援舊版同盟伺服器 Proxy。

  • 同盟伺服器和 Web 應用程式 Proxy 角色服務無法安裝在同一部電腦上。

AD DS 需求

網域控制站需求

所有使用者網域中的網域控制站和加入 AD FS 伺服器的網域都必須執行 Windows Server 2008 或更新版本。

注意

Windows Server 2003 網域控制站的所有環境支援都將在 Windows Server 2003 的延伸支援結束日期之後結束。 強烈建議客戶儘快升級其網域控制站。 如需 Microsoft 支援服務生命週期的其他資訊，請瀏覽此頁面。 針對 Windows Server 2003 網域控制站環境特有的問題，僅針對安全性問題並且可以在 Windows Server 2003 的延伸功能支援到期之前發出修正，才會發出修正。

注意

AD FS 需要完整的可寫入網域控制站才能運作，而不是唯讀網域控制站。 如果規劃的拓撲包含唯讀網域控制站，則唯讀網域控制站可用於驗證，但 LDAP 宣告處理將需要連線至可寫入的網域控制站。

網域功能層級需求

所有使用者帳戶的網域以及 AD FS 伺服器所加入的網域，都必須在 Windows Server 2003 或更新版本的網域功能等級上運作。

大部分的 AD FS 功能不需要進行 AD DS 功能等級修改，就能成功運作。 但是，如果憑證明確對應到 AD DS 中的使用者帳戶，則用戶端憑證驗證需要 Windows Server 2008 網域功能等級或更高等級才能成功運作。

結構描述需求

  • AD FS 不需要對 AD DS 進行結構描述變更或功能層級修改。

  • 若要使用加入工作場所網路功能，AD FS 伺服器加入的樹系結構描述必須設定為 Windows Server 2012 R2。

服務帳戶需求

  • 任何標準的服務帳戶都可以作為 AD FS 的服務帳戶。 也支援群組受管理的服務帳戶。 這至少需要一個執行 Windows Server 2012 或更高版本的網域控制站 (建議部署兩個或多個網域控制站)。

  • 若要讓 Kerberos 驗證在已加入網域的用戶端與 AD FS 之間運作，'HOST/<adfs_service_name>' 必須在服務帳戶上註冊為 SPN。 根據預設，如果 AD FS 有足夠的權限可執行這項作業，AD FS 會在建立新的 AD FS 伺服器陣列時進行此設定。

  • AD FS 服務帳戶必須信任向 AD FS 服務進行驗證的使用者所在的每個網域。

網域需求

  • 所有 AD FS 伺服器都必須加入 AD DS 網域。

  • 伺服器陣列中的所有 AD FS 伺服器都必須部署在單一網域中。

  • AD FS 伺服器加入的網域必須信任包含驗證 AD FS 服務之使用者的每個使用者帳戶網域。

多樹系需求

  • AD FS 伺服器加入的網域必須信任包含驗證 AD FS 服務之使用者的每個使用者帳戶網域或樹系。

  • AD FS 服務帳戶必須信任向 AD FS 服務進行驗證的使用者所在的每個網域。

設定資料庫需求

以下是根據設定存放區類型所套用的需求和限制：

WID

  • 如果您有 100 個或更少的信賴憑證者信任，WID 伺服器陣列會有 30 部同盟伺服器的限制。

  • WID 設定資料庫中不支援 SAML 2.0 中的成品解析設定檔。 WID 設定資料庫中不支援權杖重新執行偵測。 這項功能僅適用於 AD FS 作為同盟提供者並從外部宣告提供者取用安全性權杖的案例。

  • 只要伺服器數目不超過 30，即可在不同的資料中心部署 AD FS 伺服器以進行容錯移轉或地理負載平衡。

下表提供使用 WID 伺服器陣列的摘要。 使用其來規劃您的實作。

1-100 個 RP 信任 超過 100 個 RP 信任
1-30 個 AD FS 節點：支援 WID 1-30 個 AD FS 節點：不支援使用 WID - 需要 SQL
超過 30 個 AD FS 節點：不支援使用 WID - 需要 SQL 超過 30 個 AD FS 節點：不支援使用 WID - 需要 SQL

SQL Server

針對 Windows Server 2012 R2 中的 AD FS，您可以使用 SQL Server 2008 和更新版本

瀏覽器需求

透過瀏覽器或瀏覽器控制項執行 AD FS 驗證時，您的瀏覽器必須符合下列需求：

  • 必須啟用 JavaScript

  • 必須開啟 Cookie

  • 必須支援伺服器名稱指示 (SNI)

  • 若要驗證使用者憑證和裝置憑證 (工作場所加入功能)，瀏覽器必須支援 SSL 用戶端憑證驗證

數個主要瀏覽器和平台已進行轉譯和功能的驗證，詳細資料如下所列。 如果瀏覽器和裝置符合上述需求，仍可支援下表未涵蓋的瀏覽器和裝置：

瀏覽器 平台
IE 10.0 Windows 7、Windows 8.1、Windows Server 2008 R2、Windows Server 2012、Windows Server 2012 R2
IE 11.0 Windows7、Windows 8.1、Windows Server 2008 R2、Windows Server 2012、Windows Server 2012 R2
Windows Web 驗證代理人 Windows 8.1
Firefox [v21] Windows 7、Windows 8.1
Safari [v7] iOS 6、Mac OS-X 10.7
Chrome [v27] Windows 7、Windows 8.1、Windows Server 2012、Windows Server 2012 R2、Mac OS-X 10.7

重要

已知問題 - Firefox：使用裝置憑證識別裝置的加入工作場所網路功能無法在 Windows 平台上運作。 Firefox 目前不支援使用佈建至 Windows 用戶端上使用者憑證存放區的憑證來執行 SSL 用戶端憑證驗證。

Cookie

AD FS 會建立以工作階段為基礎的永續性 Cookie，這類 Cookie 必須儲存於用戶端電腦上，以提供登入、登出、單一登入 (SSO) 及其他功能。 因此，用戶端瀏覽器必須設定為接受 Cookie。 用來驗證的 Cookie 一律為安全超文字傳輸通訊協定 (HTTPS) 工作階段 Cookie，它們是針對原始伺服器所撰寫的。 如果未將用戶端瀏覽器設定為允許這些 Cookie，AD FS 就無法正確運作。 永續性 Cookie 可用來保留宣告提供者的使用者選項。 您可以在適用於 AD FS 登入頁面的設定檔中使用組態設定來停用它們。 基於安全理由，需要支援 TLS/SSL。

外部網路需求

若要提供 AD FS 服務的外部網路存取權，您必須將 Web 應用程式 Proxy 角色服務部署為 Proxy 驗證要求的安全方式提供給 AD FS 服務的外部網路對應角色。 這會隔離 AD FS 服務端點，以及隔離來自網際網路要求的所有安全性金鑰 (例如權杖簽署憑證)。 此外，軟體外部網路帳戶鎖定等功能需要使用 Web 應用程式 Proxy。 如需 Web 應用程式 Proxy 的詳細資訊，請參閱 Web 應用程式 Proxy。 `

網路需求

適當地設定以下網路服務，是在組織中成功部署 AD FS 的要素：

設定公司防火牆

位於 Web 應用程式 Proxy 與同盟伺服器陣列之間的防火牆，以及位於用戶端與 Web 應用程式 Proxy 之間的防火牆，都必須啟用 TCP 連接埠 443 的輸入。

此外，如果用戶端使用者憑證驗證 (使用 X509 使用者憑證的 clientTLS 驗證) 是必要的，則 Windows Server 2012 R2 中的 AD FS 會要求在用戶端與 Web 應用程式 Proxy 之間的防火牆上，啟用 TCP 連接埠 49443 的輸入。 Web 應用程式 Proxy 與同盟伺服器之間的防火牆則不需要這麼做。

注意

 也請確定 AD FS 和 Web 應用程式 Proxy 伺服器上的任何其他服務不會使用連接埠 49443。

設定 DNS

  • 若要能夠存取內部網路，所有存取內部公司網路 (內部網路) 內 AD FS 服務的用戶端都必須能夠將 AD FS 服務名稱 (由 SSL 憑證提供名稱) 解析到一或多個 AD FS 伺服器的負載平衡器。

  • 若要能夠存取外部網路，從公司網路外部 (外部網路/網際網路) 存取 AD FS 服務的所有用戶端都必須能夠將 AD FS 服務名稱 (由 SSL 憑證提供名稱) 解析到一或多個 Web 應用程式 Proxy 伺服器的負載平衡器。

  • 若要讓外部網路存取正常運作，DMZ 中的每個 Web 應用程式 Proxy 伺服器都必須能夠將 AD FS 服務名稱 (由 SSL 憑證提供名稱) 解析到 AD FS 伺服器或 AD FS 伺服器的負載平衡器。 使用 DMZ 網路中的替代 DNS 伺服器，或使用 HOSTS 檔案變更本機伺服器解析，即可達成此目的。

  • 若要讓 Windows 整合式驗證在網路內部和網路外部運作，以取得透過 Web 應用程式 Proxy 公開的端點子集，您必須使用 A 記錄 (而非 CNAME) 來指向負載平衡器。

如需為同盟服務和裝置註冊服務設定公司 DNS 的相關資訊，請參閱設定同盟服務和 DRS 的公司 DNS。

如需設定 Web 應用程式 Proxy 公司 DNS 的詳細資訊，請參閱步驟 1：設定 Web 應用程式 Proxy 基礎結構中的「設定 DNS」一節。

有關如何使用 NLB 設定叢集 IP 位址或叢集 FQDN 的詳細資訊，請參閱 http://go.microsoft.com/fwlink/?LinkId=75282 的指定叢集參數。

屬性存放區需求

AD FS 要求至少有一個屬性存放區可用來驗證使用者，以及擷取這些使用者的安全性宣告。 如需 AD FS 支援的屬性存放區清單，請參閱屬性存放區角色。

注意

根據預設，AD FS 會自動建立「Active Directory」屬性存放區。 屬性存放區需求需視您的組織是帳戶夥伴 (主控同盟使用者) 或資源夥伴 (主控同盟應用程式) 而定。

LDAP 屬性存放區

當您使用其他以輕量型目錄存取通訊協定 (LDAP) 為基礎的屬性存放區時，必須連線到支援 Windows 整合式驗證的 LDAP 伺服器。 LDAP 連線字串也必須以 LDAP URL 的格式來書寫，如 RFC 2255 中所述。

AD FS 服務的服務帳戶也必須有權擷取 LDAP 屬性存放區中的使用者資訊。

SQL Server 屬性存放區

若要讓 Windows Server 2012 R2 中的 AD FS 成功運作，裝載 SQL Server 屬性存放區的電腦必須執行 Microsoft SQL Server 2008 或更高版本。 當您使用以 SQL 為基礎的屬性存放區時，也必須設定連線字串。

自訂屬性存放區

您可以開發自訂屬性存放區，以啟用進階案例。

  • AD FS 內建的原則語言可以參考自訂屬性存放區，因此能夠增強下列任一個案例：

    • 建立適用於本機驗證使用者的宣告

    • 補充適用於外部驗證使用者的宣告

    • 授權使用者取得權杖

    • 授權服務代表使用者取得權杖

    • 在 AD FS 所簽發的安全性權杖中，向信賴憑證者發出其他資料。

  • 所有自訂屬性存放區都必須建置在 .NET 4.0 或更高版本之上。

當您使用自訂屬性存放區時，可能也必須設定連接字串。 在此情況下，您可以輸入您選擇的自訂程式碼，以啟用自訂屬性存放區的連線。 在此情況下，連接字串是一組名稱/值組，會解譯為自訂屬性存放區由開發人員實作。如需開發和使用自訂屬性存放區的詳細資訊，請參閱屬性存放區概觀。

應用程式需求

AD FS 支援使用下列通訊協定的宣告感知應用程式：

  • WS-同盟

  • WS-Trust

  • 使用 IDPLite、SPLite 和 eGov1.5 設定檔的 SAML 2.0 通訊協定。

  • OAuth 2.0 授權授與設定檔

AD FS 也支援 Web 應用程式 Proxy 所支援之任何非宣告感知應用程式的驗證和授權。

驗證需求

AD DS 驗證 (主要驗證)

針對內部網路存取，支援下列 AD DS 的標準驗證機制：

  • 使用支援 Kerberos 與 NTLM 的 Negotiate 的 Windows 整合式驗證

  • 使用使用者名稱/密碼的表單驗證

  • 使用對應至 AD DS 中使用者帳戶的憑證進行憑證驗證

針對外部網路存取，以下是支援的驗證機制：

  • 使用使用者名稱/密碼的表單驗證

  • 使用對應至 AD DS 中使用者帳戶的憑證進行憑證驗證

  • 針對接受 Windows 整合式驗證的 WS-Trust 端點，使用交涉 (僅限 NTLM) 進行 Windows 整合式驗證。

針對憑證驗證：

  • 延伸至受 PIN 保護的智慧卡。

  • 使用者輸入其 PIN 的 GUI 不是由 AD FS 提供，而且必須是使用用戶端 TLS 時所顯示的用戶端作業系統一部分。

  • 智慧卡的讀取器和密碼編譯服務提供者 (CSP) 必須在瀏覽器所在的電腦上運作。

  • 智慧卡憑證必須鏈結至所有 AD FS 伺服器和 Web 應用程式 Proxy 伺服器上的受信任根目錄。

  • 憑證必須使用下列任一個方法，對應到 AD DS 中的使用者帳戶：

    • 憑證主體名稱會對應到 AD DS 中使用者帳戶的 LDAP 辨別名稱。

    • 憑證主體 altname 延伸含有 AD DS 中使用者帳戶的使用者主體名稱 (UPN)。

針對在內部網路中使用 Kerberos 的無縫 Windows 整合式驗證，

  • 服務名稱必須是受信任網站或近端內部網路網站的一部分。

  • 此外，必須在 AD FS 伺服器陣列執行的服務帳戶上設定 HOST/<adfs_service_name> SPN。

多重要素驗證

AD FS 支援其他驗證 (除了 AD DS 支援的主要驗證之外)，使用提供者模型，讓廠商/客戶可以建置自己的多重要素驗證配接器，讓系統管理員可以在登入期間註冊及使用。

每個 MFA 配接器都必須建置在 .NET 4.5 之上。

如需詳細資訊，請參閱 透過其他多因素驗證管理機密應用程式的風險。

裝置驗證

AD FS 支援在使用者工作場所加入其裝置時，使用裝置註冊服務所佈建的憑證進行裝置驗證。

加入工作場所網路需求

終端使用者可以使用 AD FS 將裝置加入工作場所網路。 AD FS 中的裝置註冊服務支援此功能。 因此，終端使用者可透過 AD FS 所支援的應用程式取得 SSO 的額外優點。 此外，系統管理員可以藉由將應用程式存取限制為僅限已加入工作場所網路的裝置，來管理風險。 以下是啟用此案例的下列需求。

  • AD FS 支援 Windows 8.1 和 iOS 5+ 裝置的加入工作場所網路

  • 若要使用加入工作場所網路功能，AD FS 伺服器加入的樹系結構描述必須為 Windows Server 2012 R2。

  • AD FS 服務 SSL 憑證的主體別名必須含有 enterpriseregistration 值，隨後再加上組織的使用者主體名稱 (UPN) 尾碼 (如 enterpriseregistration.corp.contoso.com)。

密碼編譯需求

下表提供 AD FS 權杖簽署、權杖加密/解密功能的其他密碼編譯支援資訊：

演算法 金鑰長度 通訊協定/應用程式/註解
TripleDES – 預設 192 (支援 192 – 256) - http://www.w3.org/2001/04/xmlenc#tripledes-cbc >= 192 支援解密安全性權杖的演算法。 不支援使用此演算法加密安全性權杖。
AES128 - http://www.w3.org/2001/04/xmlenc#aes128-cbc 128 支援解密安全性權杖的演算法。 不支援使用此演算法加密安全性權杖。
AES192 - http://www.w3.org/2001/04/xmlenc#aes192-cbc 192 支援解密安全性權杖的演算法。 不支援使用此演算法加密安全性權杖。
AES256 - http://www.w3.org/2001/04/xmlenc#aes256-cbc 256 Default。 支援加安全性權杖的演算法。
TripleDESKeyWrap - http://www.w3.org/2001/04/xmlenc#kw-tripledes .NET 4.0+ 支援的所有金鑰大小 加密對稱金鑰以加密安全性權杖的支援演算法。
AES128KeyWrap - http://www.w3.org/2001/04/xmlenc#kw-aes128 128 加密對稱金鑰以加密安全性權杖的支援演算法。
AES192KeyWrap - http://www.w3.org/2001/04/xmlenc#kw-aes192 192 加密對稱金鑰以加密安全性權杖的支援演算法。
AES256KeyWrap - http://www.w3.org/2001/04/xmlenc#kw-aes256 256 加密對稱金鑰以加密安全性權杖的支援演算法。
RsaV15KeyWrap - http://www.w3.org/2001/04/xmlenc#rsa-1_5 1024 加密對稱金鑰以加密安全性權杖的支援演算法。
RsaOaepKeyWrap - http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p 1024 預設。 加密對稱金鑰以加密安全性權杖的支援演算法。
SHA1-http://www.w3.org/PICS/DSig/SHA1_1_0.html N/A AD FS 伺服器在成品 SourceId 產生中使用：在此案例中，STS 會使用 SHA1 (根據 SAML 2.0 標準中的建議)，為成品 sourceiD 建立簡短的 160 位元值。

AD FS Web 代理程式 (WS2003 時間範圍中的舊版元件) 也會使用識別「上次更新」時間值中的變更，以便知道何時從 STS 更新資訊。
SHA1withRSA-

http://www.w3.org/PICS/DSig/RSA-SHA1_1_0.html

 N/A 在 AD FS 伺服器驗證 SAML AuthenticationRequest 簽章、簽署成品解析要求或回應、建立權杖簽署憑證時使用。

在這些情況下，SHA256 是預設值，而且只有在合作夥伴 (信賴憑證者) 無法支援 SHA256 且必須使用 SHA1 時，才會使用 SHA1。

權限需求

執行安裝和 AD FS 初始設定的系統管理員必須在本機網域 (也就是同盟伺服器加入的網域) 中擁有網域系統管理員權限。

另請參閱

Windows Server 2012 R2 中的 AD FS 設計指南