Active Directory 同盟服務的新功能

  • 發行項

Windows Server 2019 的 Active Directory 同盟服務中的新功能

本文說明對 Active Directory 同盟服務 (AD FS) 所做的新變更。

受保護的登入

以下是 Active Directory 同盟服務 (AD FS) 2019 中可用受保護登入更新的簡短摘要：

  • 以外部驗證提供者作為主要因素。 客戶現在可以使用第三方驗證產品作為第一個因素，而不將密碼公開為第一個因素。 在外部驗證提供者可以證明雙因素的情況下，即可宣告 MFA。
  • 以密碼驗證作為額外的驗證。 客戶有完全支援的內建選項，只有在無密碼選項作為第一個因素之後，才使用密碼作為額外因素。 此選項可改善客戶使用 AD FS 2016 的體驗；過去，客戶必須下載依現狀支援的 GitHub 配接器。
  • 可插式風險評估模組。 客戶現在可以建立自己的外掛程式模組，以在預先驗證階段封鎖特定類型的要求。 此功能可讓客戶更輕鬆地使用身分識別保護之類的雲端智慧來封鎖風險性使用者的登入或有風險的交易。 如需詳細資訊，請參閱使用 AD FS 2019 風險評估模型建置外掛程式。
  • ESL 改進。 藉由新增下列功能改善 2016 中的 ESL 快速修正工程 (QFE)：
    • 可讓客戶處於稽核模式，同時受到 AD FS 2012R2 之後提供的「傳統」外部網路鎖定功能的保護。 目前的 2016 客戶在稽核模式下不受保護。
    • 針對熟悉的位置啟用獨立的鎖定閾值。 此功能可讓您使用共同服務帳戶執行的多個應用程式執行個體，以在最少的影響下變換密碼。

其他安全性改善

AD FS 2019 中提供下列安全性改善：

  • 使用智慧卡登入的遠端 PowerShell。 客戶現在可以使用智慧卡透過 PowerShell 從遠端連線至 AD FS，然後使用該服務來管理所有 PowerShell 功能，包括多節點 Cmdlet。
  • HTTP 標頭自訂。 客戶現在可以自訂在 AD FS 回應期間發出的 HTTP 標頭，包含下列標頭：
    • HSTS：此標頭會傳達只能在 HTTPS 端點上使用以強制執行相容瀏覽器的 AD FS 端點。
    • x-frame-options：可讓 AD FS 系統管理員允許特定的信賴憑證者內嵌 AD FS 互動式登入頁面的 iFrame。 此標頭應謹慎使用，且限用於 HTTPS 主機上。
    • 未來標頭：您也可以設定其他未來的標頭。

如需詳細資訊，請參閱使用 AD FS 2019 自訂 HTTP 安全性回應標頭。

驗證/原則功能

以下是 AD FS 2019 中的驗證/原則功能：

  • 針對每個 RP的其他驗證指定驗證方法。 客戶現在可以使用宣告規則來決定要叫用哪些其他驗證提供者進行其額外的驗證。 這項功能適用於兩個使用案例：
    • 客戶要從一個其他的驗證提供者轉換到另一個。 如此，當他們將使用者上架至較新的驗證提供者時，將可使用群組來控制要呼叫哪個額外的驗證提供者。
    • 針對特定應用程式，客戶需要特定的額外驗證提供者 (例如憑證)。
  • 將傳輸層安全性 (TLS) 型裝置驗證限定於有需要的應用程式。 客戶現在可以將用戶端 TLS 型裝置驗證限定於執行裝置條件式存取的應用程式。 此選項可以避免對不需要 TLS 型裝置驗證的應用程式發出任何不必要的裝置驗證提示 (或避免在用戶端應用程式無法處理時發生失敗的狀況)。
  • 多重要素驗證 (MFA) 有效期限支援。 AD FS 現在支援根據第二因素認證的有效期限重新執行第二因素認證的功能。 此功能可讓客戶先透過二個因素執行初始交易，而其後僅定期發出第二個因素的提示。 此功能僅適用於可在要求中提供額外參數的應用程式，且在 AD FS 中並非可設定的設定。 當您設定 [記住我的 MFA X 天]，並且在 Azure AD 同盟網域信任設定上將 'supportsMFA' 旗標設定為 true 時，Azure AD 才會支援此參數。

單一登入改善

AD FS 2019 做了下列單一登入 SSO 改善：

  • 具有置中主題的分頁 UX。 AD FS 現已移至分頁 UX 流程，讓 AD FS 能夠進行驗證，並提供更流暢的登入體驗。 AD FS 現在會使用置中的 UI (而非位於畫面右側)。 您可能需要較新的標誌和背景影像，才能與此體驗協調。 此變更也會反映 Azure AD 中提供的功能。
  • 錯誤修正：執行主要重新整理權杖 (PRT) 驗證時，Win10 裝置的持續 SSO 狀態。這項變更可解決 MFA 狀態在針對 Windows 10 裝置使用 PRT 驗證時不會保存的問題。 此問題會導致使用者經常收到第二因素認證 (MFA) 的提示。 此修正也使透過用戶端 TLS 和透過 PRT 機制順利執行的裝置驗證能有一致的體驗。

建置新式企業營運應用程式的支援

AD FS 2019 新增了下列建置新式企業營運 LOB 應用程式的支援：

  • Oauth 裝置流程/設定檔。 AD FS 現已支援 OAuth 裝置流程設定檔，以登入沒有 UI 介面區域可支援豐富登入體驗的裝置。 此功能可讓使用者在不同的裝置上完成登入體驗。 這是 Azure Stack 中的 Azure CLI 體驗所需的功能，而且也可在其他情況下使用。
  • 移除「資源」參數。 AD FS 現已不再需要指定內嵌於目前 Oauth 規格中的資源參數。 用戶端現在除了要求的權限以外，也可提供信賴憑證者信任識別碼作為範圍參數。
  • AD FS 回應中的跨原始資源共用 (CORS) 標頭。 客戶現在可以建置單頁應用程式，以允許用戶端 JavaScript 程式庫從 AD FS 上 OpenID Connect (OIDC) 探索文件中查詢簽署金鑰，藉以驗證 id_token 的簽章。
  • Proof Key for Code Exchange (PKCE) 支援。 AD FS 新增了 PKCE 支援，以在 OAuth 中提供安全的驗證碼流程。 此功能可提高此流程的安全性層級，以避免程式碼遭到不同用戶端的攔截並加以重新執行。
  • 錯誤修正：傳送 x5t 和 kid 宣告。 這項變更是次要的錯誤修正。 AD FS 現在會額外傳送「kid」宣告，以提供用來驗證簽章的金鑰識別碼提示。 過去，AD FS 只會傳送「x5t」宣告。

支援能力的改進

下列支援能力的改善現在屬於 AD FS 2019：

  • 將錯誤詳細資料傳送給 AD FS 系統管理員。 可讓系統管理員設定使用者，以傳送其與使用者驗證失敗有關、且要儲存為壓縮欄位以便取用的偵錯記錄。 系統管理員也可設定簡易郵件傳送通訊協定 (SMTP) 連線，以將壓縮檔案自動傳送至分級電子郵件帳戶，或根據電子郵件自動建立票證。

部署更新

AD FS 2019 現在包含下列部署更新：

  • 伺服器陣列行為層級 2019。 如同 AD FS 2016，若要啟用文章稍後所述的新功能，必須要有新的伺服器陣列行為層級版本。 此更新可行的途徑如下：
    • Windows Server 2012 R2 上的 AD FS 到 Windows Server 2016 上的 AD FS。
    • Windows Server 2016 上的 AD FS 到 Windows Server 2019 上的 AD FS。

SAML 更新

下列安全性聲明標記語言 (SAML) 更新位於 AD FS 2019 中：

  • 錯誤修正：修正彙總同盟中的 Bug。 在彙總同盟支援 (例如 InCommon) 方面有許多 Bug 修正。 下欄區域已獲得修正：
    • 改善了在彙總同盟中繼資料文件中調整大量實體的效能。過去，調整會失敗並出現「ADMIN0017」錯誤。
    • 透過 Get-AdfsRelyingPartyTrustsGroup PowerShell Cmdlet 使用 'ScopeGroupID' 參數進行查詢。
    • 處理關於 entityID 重複的錯誤狀況。

範圍參數中的 Azure AD 樣式資源規格

過去，無論在任何驗證要求中，AD FS 都需要將所需的資源和範圍放在個別的參數中。 例如，下列 OAuth 要求看起來可能會像您通常會傳送：

https://fs.contoso.com/adfs/oauth2/authorize?response_type=code&client_id=claimsxrayclient&resource=urn:microsoft:adfs:claimsxray&scope=oauth&redirect_uri=https://adfshelp.microsoft.com/
ClaimsXray/TokenResponse&prompt=login

使用 Server 2019 上的 AD FS，您現在可以傳遞範圍參數中內嵌的資源值。 此變更也與您對 Azure AD 執行驗證的方式相一致。

範圍參數現在可以組織成以空格分隔的清單，其中的每個項目都會建構為資源/範圍。

注意

在驗證要求中只能指定一個資源。 如果要求中包含多個資源，AD FS 將會傳回錯誤，且驗證將會失敗。

OAuth 的 Proof Key for Code Exchange (PKCE) 支援

使用授權碼授與的 OAuth 公用用戶端很容易遭受授權碼攔截攻擊。 這項攻擊在 RFC 7636 中有詳細說明。 為了緩解此攻擊，Server 2019 中的 AD FS 支援 OAuth 授權碼授與流程的 Proof Key for Code Exchange (PKCE)。

為了使用 PKCE 支援，此規格對 OAuth 2.0 授權和存取權杖要求新增了額外的參數。

用戶端與 AD FS 2019 之間的 PKCE 關聯圖表。

A。 用戶端建立並記錄名為「code_verifier」的密碼，並衍生轉換後的版本「t(code_verifier)」(名為「code_challenge」)。 祕密會在 OAuth 2.0 授權要求中連同「t_m」轉換方法一起傳送。

B. 授權端點如常回應，但記錄了「t(code_verifier)」和轉換方法。

C. 接著，用戶端如常傳送存取權杖要求中的授權碼，但其中包含在 (A) 產生的「code_verifier」祕密。

D. AD FS 會轉換 "code_verifier"，並將其與 (B) 中的 "t(code_verifier)" 進行比較。 如果兩者不相同，則會拒絕存取。

如何在 2019 中選擇額外的驗證提供者

AD FS 已經支援根據宣告規則原則觸發額外的驗證。 這些原則可以在特定 RP 或全域層級設定。 您可以使用 Cmdlet Set-AdfsRelyingPartyTrust (AD FS) | Microsoft Docs 來設定特定 RP 的額外驗證原則，方法是傳遞 AdditionalAuthenticationRules 或 AdditionalAuthenticationRulesFile 參數。 若要全域設定，系統管理員可以使用 Cmdlet Set-AdfsAdditionalAuthenticationRule (AD FS) | Microsoft Docs。

例如，2012 R2 及更新版本的系統管理員可以撰寫下列規則，以在要求來自外部網路時提示額外的驗證。

Set-AdfsAdditionalAuthenticationRule -AdditionalAuthenticationRules 'c:[type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", value == "false"] => issue(type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", value = "http://schemas.microsoft.com/claims/multipleauthn" );'

在 2019 中，客戶現在可以使用宣告規則來決定要叫用哪些其他驗證提供者來進行額外的驗證。 這項功能適用於兩個案例：

客戶要從一個其他的驗證提供者轉換到另一個。 如此，當他們將使用者上架至較新的驗證提供者時，將可使用群組來控制要呼叫哪個額外的驗證提供者。

客戶針對特定應用程式需要特定的額外驗證提供者 (例如憑證)，但針對其他應用程式使用不同的方法(Azure AD 多重要素驗證)。

透過從其他驗證原則發出宣告 http://schemas.microsoft.com/claims/authnmethodsproviders，即可達成此設定。 此宣告的值應該是驗證提供者的「名稱」。

在 2019 中，現在他們可以修改先前的宣告規則，以根據其案例選擇驗證提供者。

從一個其他驗證提供者轉換到另一個驗證提供者：您可以修改先前提到的規則，為群組 SID S-1-5-21-608905689-872870963-3921916988-12345 中的使用者選擇 Azure AD 多重要素驗證。 例如，您可以針對企業管理的群組使用此修改，以追蹤已註冊 Azure AD 多重要素驗證的使用者。 這項修改也適用於系統管理員想要對其使用憑證驗證的其餘使用者。

'c:[type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] => issue(type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn" ); 

 c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value == "S-1-5-21-608905689-872870963-3921916988-12345"] => issue(Type = "http://schemas.microsoft.com/claims/authnmethodsproviders", Value = "AzureMfaAuthentication"); 

not exists([Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value=="S-1-5-21-608905689-872870963-3921916988-12345"]) => issue(Type = "http://schemas.microsoft.com/claims/authnmethodsproviders", Value = "CertificateAuthentication");’

此範例示範如何為兩個不同的應用程式設定兩個不同的驗證提供者：

將應用程式 A 設定為使用 Azure AD 多重要素驗證以作為額外的驗證提供者：

Set-AdfsRelyingPartyTrust -TargetName AppA -AdditionalAuthenticationRules 'c:[type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] => issue(type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn" ); 

c:[] => issue(Type = "http://schemas.microsoft.com/claims/authnmethodsproviders", Value = "AzureMfaAuthentication");'

將應用程式 B 設定為使用憑證以作為額外的驗證提供者：

Set-AdfsRelyingPartyTrust -TargetName AppB -AdditionalAuthenticationRules 'c:[type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] => issue(type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn" ); 

c:[] => issue(Type = "http://schemas.microsoft.com/claims/authnmethodsproviders", Value = "CertificateAuthentication");'

系統管理員也可以制定規則，以允許多個額外的驗證提供者。 在此情況下，AD FS 會顯示已發出的驗證方法提供者，而且使用者可以選擇其中任何一個提供者。 若要允許多個額外的驗證提供者，他們應該發出多個宣告 http://schemas.microsoft.com/claims/authnmethodsproviders。

如果宣告評估未傳回任何驗證提供者，AD FS 會回復以顯示系統管理員在 AD FS 上設定的所有額外驗證提供者。 使用者必須接著選取適當的驗證提供者。

若要取得允許的所有其他驗證提供者，系統管理員可以使用 Cmdlet (Get-AdfsGlobalAuthenticationPolicy).AdditionalAuthenticationProvider。 宣告 http://schemas.microsoft.com/claims/authnmethodsproviders 的值應該是先前提及 Cmdlet 所傳回的其中一個提供者名稱。

如果 RP 使用 AD FS Windows Server 2016 中的存取控制原則 | Microsoft Docs，則不支援觸發特定的額外驗證提供者。當您將應用程式從存取控制原則移開時，AD FS 會將對應的原則從存取控制原則複製到 AdditionalAuthenticationRules 和 IssuanceAuthorizationRules。 因此，如果系統管理員想要使用特定的驗證提供者，他們可以選擇不使用存取控制原則，然後修改 AdditionalAuthenticationRules 以觸發特定的驗證提供者。

常見問題集

如何解決 AD FS 系統管理事件記錄錯誤：「收到無效的 Oauth 要求。 已禁止用戶端 'NAME' 存取範圍為 'ugs' 的資源。」？

請遵循下列步驟來補救問題：

  1. 啟動 AD FS 管理主控台。 移至 [服務 > 範圍描述]。
  2. 在 [範圍描述] 上選取更多選項，然後選取 [新增範圍描述]。
  3. 在 [名稱] 底下，輸入「ugs」，然後選取 [套用 > 確定]。
  4. 以系統管理員身分啟動 PowerShell。
  5. 執行命令 Get-AdfsApplicationPermission。 尋找具有 ClientRoleIdentifier 的 ScopeNames :{openid, aza}。 記下 ObjectIdentifier。
  6. 執行命令 Set-AdfsApplicationPermission -TargetIdentifier <ObjectIdentifier from step 5> -AddScope 'ugs'。
  7. 重新啟動 AD FS 服務。
  8. 在用戶端上，重新啟動戶端。 系統應該會提示您設定 Windows Hello 企業版 (WHFB)。
  9. 如果設定視窗未彈出，則您需要收集追蹤記錄並進一步進行疑難排解。

我可以將資源值當作範圍值的一部分傳遞，如同對 Azure AD 進行要求一樣嗎？

使用 Server 2019 上的 AD FS，您現在可以傳遞範圍參數中內嵌的資源值。 範圍參數現在可以組織成以空格分隔的清單，其中的每個項目都會建構為資源/範圍。 例如：<create a valid sample request>

AD FS 是否支援 PKCE 擴充功能？

Server 2019 中的 AD FS 支援 OAuth 授權碼授與流程的 Proof Key for Code Exchange (PKCE)。

Windows Server 2016 的 Active Directory 同盟服務中的新功能

如果您要尋找舊版 AD FS 的相關資訊，請參閱下列文章：Windows Server 2012 或 2012 R2 中的 AD FS 與 AD FS 2.0。

AD FS 在各種不同的應用程式 (包括 Office 365、雲端式 SaaS 應用程式，和公司網路上的應用程式) 上均提供存取控制和單一登入。

  • 對於 IT 組織，此服務可讓您根據同一組認證和原則，對任何電腦上的新式和舊版應用程式提供登入和存取控制。
  • 對於使用者，則會提供採用相同、慣用帳戶憑證的無縫登入。
  • 對於開發人員，此服務提供了簡單的方式可對身分識別位於組織目錄中的使用者進行驗證，讓您得以專注於應用程式，而不是驗證或身分識別。

外部網路不使用密碼

AD FS 2016 啟用了三個新的無需密碼的登入選項，讓組織得以避免因網路釣魚、資料外洩或密碼遭竊而承受網路遭到入侵的風險。

使用 Azure Active Directory 多重要素驗證來登入

AD FS 2016 是以 Windows Server 2012 R2 中 AD FS 的多重要素驗證 (MFA) 功能為基礎。 您現在可以只使用 Azure AD 多重要素驗證程式碼來允許登入，而不需要先輸入使用者名稱和密碼。

  • 使用 Azure AD 多重要素驗證作為主要驗證方法時，系統會提示使用者輸入其使用者名稱，和 Azure 驗證器應用程式提供的 OTP 代碼。
  • 使用 Azure AD 多重要素驗證作為次要或額外的驗證方法時，使用者需要提供主要驗證認證。 他們可以使用 Windows 整合式驗證，並搭配使用者名稱和密碼、智慧卡或使用者或裝置憑證來登入。 然後，他們會看到文字、語音或 OTP 型 Azure AD 多重要素驗證登入的提示。
  • 有了新的內建 Azure AD 多重要素驗證配接器，使用 AD FS 進行 Azure AD 多重要素驗證的設定從此變得更簡單。
  • 組織可以在不需要內部部署 Azure AD 多重要素驗證伺服器的情況下利用 Azure AD 多重要素驗證。
  • Azure AD 多重要素驗證可進行內部網路或外部網路的設定，或作為任何存取控制原則的一部分。

如需搭配 AD FS 進行 Azure AD 多重要素驗證的詳細資訊，請參閱設定 AD FS 2016 和 Azure AD 多重要素驗證。

從相容的裝置進行無密碼存取

AD FS 2016 以先前的裝置註冊功能為建置基礎，啟用了根據裝置合規性狀態的登入和存取控制功能。 使用者可以使用裝置認證登入，而當裝置屬性變更時，即會重新評估合規性，讓您能夠隨時確保原則的強制執行。 此功能會啟用如下的原則：

  • 僅啟用受管理和/或相容的裝置所進行的存取。
  • 僅啟用受管理和/或相容的裝置所進行的外部網路存取。
  • 未受管理或不符合規範的電腦，必須進行多重要素驗證。

AD FS 在混合式案例中提供條件式存取原則的內部部署元件。 當您使用 Azure AD 註冊裝置以進行雲端資源的條件式存取時，裝置身分識別也可用於 AD FS 原則。

混合式解決方案和使用者與內部部署 Active Directory 之間的關聯圖表。

若要進一步了解如何在雲端中使用以裝置為基礎的條件式存取，請參閱 Azure Active Directory 條件式存取。

若要進一步了解如何對 AD FS 使用以裝置為基礎的條件式存取

使用 Windows Hello 企業版進行登入

注意

目前不支援將 Google Chrome 和建置於 Chromium 開放原始碼專案瀏覽器的新式 Microsoft Edge 用於 Windows Hello 企業版的瀏覽器單一登入 (SSO)。 請使用 Internet Explorer 或較舊版本的 Microsoft Edge。

Windows 10 裝置導入了 Windows Hello 和 Windows Hello 企業版，將使用者密碼取代為受到使用者手勢保護的強式裝置繫結使用者認證 (PIN 碼、指紋之類的生物識別手勢或臉部辨識)。 AD FS 2016 支援這些新的 Windows 10 功能，讓使用者無須提供密碼，即可從內部網路或外部網路登入 AD FS 應用程式。

如需在組織中使用 Windows Hello 企業版的詳細資訊，請參閱在組織中啟用 Windows Hello 企業版。

保護對應用程式的存取

下列變更會影響 AD FS 中對應用程式的安全存取。

新式驗證

AD FS 2016 支援最新的通訊協定，可針對 Windows 10 以及最新的 iOS 和 Android 裝置與應用程式提供更好的使用者體驗。

如需詳細資訊，請參閱適合開發人員使用的 AD FS 案例。

直接設定存取控制原則而無須了解宣告規則語言

過去，AD FS 管理員必須使用 AD FS 宣告規則語言來設定原則，因此難以設定和維護原則。 透過存取控制原則，系統管理員可使用內建範本來套用常用的原則，例如

  • 僅允許內部網路存取。
  • 允許所有人，並要求來自外部網路的 MFA。
  • 允許所有人，並要求特定群組的 MFA。

範本可使用精靈驅動的程序輕易自訂，以新增例外狀況或其他原則規則，並且可套用至一或多個應用程式，以強制執行一致的原則。

如需詳細資訊，請參閱 AD FS 中的存取控制原則。

啟用使用非 AD LDAP 目錄的登入

許多組織都會搭配使用 Active Directory 和第三方目錄。 在新增了對儲存在 輕量型目錄存取通訊協定 (LDAP) v3 相容目錄中的使用者進行驗證的 AD FS 支援之後，AD FS 現在已可用於：

  • 與 LDAP v3 相容的第三方目錄中包含的使用者。
  • 未設定 Active Directory 雙向信任的 Active Directory 樹系中包含的使用者。
  • Active Directory 輕量型目錄服務 (AD LDS) 中的使用者。

如需詳細資訊，請參閱 Configure AD FS to authenticate users stored in LDAP directories。

更好的登入體驗

下列變更可改善 AD FS 的登入體驗。

自訂 AD FS 應用程式的登入體驗

過去，Windows Server 2012 R2 中的 AD FS 提供了所有信賴憑證者應用程式的一般登入體驗，且能夠自訂個別應用程式的文字內容子集。 透過 Windows Server 2016，您不僅可自訂個別應用程式的訊息，也可自訂其影像、標誌和網頁佈景主題。 此外，您可以建立新的自訂網頁佈景主題，並且就個別的信賴憑證者套用這些主題。

如需詳細資訊，請參閱 AD FS 使用者登入自訂。

管理性和操作增強功能

下一節說明 Windows Server 2016 中的 Active Directory 同盟服務導入的改良操作案例。

簡化的審核程序使系統管理更為容易

在 Windows Server 2012 R2 的 AD FS 中，有許多針對單一要求而產生的稽核事件，但登入或權杖發行活動的相關資訊則付之闕如，或分散於多個稽核事件間。 AD FS 稽核事件因其資訊龐雜的特性，會預設為關閉。 隨著 AD FS 2016 的發行，稽核功能變得更精簡且不冗贅。

如需詳細資訊，請參閱 Windows Server 2016 中 AD FS 的稽核增強功能。

透過 SAML 2.0 改進互通性以參與同盟

AD FS 2016 包含更多 SAML 通訊協定支援，包括可根據包含多個實體的中繼資料匯入信任的支援。 此變更可讓您設定 AD FS 以參與同盟 (例如 InCommon 同盟) 和符合 eGov 2.0 標準的其他實作。

如需詳細資訊，請參閱使用 SAML 2.0 改進互通性。

簡化同盟 Microsoft 365 使用者的密碼管理

您可以設定 Active Directory 同盟服務 (AD FS)，以將密碼到期宣告傳送至受 AD FS 保護的信賴憑證者信任 (應用程式)。 這些宣告的使用方式取決於應用程式。 例如，若以 Office 365 作為您的信賴憑證者，Exchange 和 Outlook 已實作了相關更新，會在同盟使用者的密碼即將過期時對其發出通知。

如需詳細資訊，請參閱設定 AD FS 以傳送密碼到期宣告。

從 Windows Server 2012 R2 中的 AD FS 移至 Windows Server 2016 中的 AD FS 比以往更容易

過去，要移轉至新版本的 AD FS，必須先從舊的伺服器陣列匯出組態，然後再匯入至全新的平行伺服器陣列。

現在，從 Windows Server 2012 R2 上的 AD FS 移至 Windows Server 2016 上的 AD FS，已比以往容易。 將新的 Windows Server 2016 伺服器新增至 Windows Server 2012 R2 伺服器陣列，而伺服器陣列會在 Windows Server 2012 R2 伺服器陣列行為層級上運作。 您伺服器現在的外觀和行為就像是 Windows Server 2012 R2 伺服器陣列。

然後，將新的 Windows Server 2016 伺服器新增至伺服器陣列，並在驗證功能後，從負載平衡器移除較舊的伺服器。 在所有伺服器陣列節點均執行 Windows Server 2016 之後，您就可以將伺服器陣列行為層級升級至 2016，並開始使用新功能。

如需詳細資訊，請參閱升級至 Windows Server 2016 中的 AD FS。