AD FS 的常見問題集 (FAQ)

您可以透過完成下列其中一篇連結文章中的步驟來升級/移轉 AD FS：

• Windows Server 2012 R2 AD FS 升級至 Windows Server 2016 AD FS 或更新版本。 (如果您從 Windows Server 2016 AD FS 升級至 Windows Server 2019 AD FS，則程序會相同。)
  • 使用 WID 資料庫升級至 Windows Server 2016 中的 AD FS
  • 使用 SQL 資料庫的 Windows Server 2016 中的 AD FS
• Windows Server 2012 AD FS 升級至 Windows Server 2012 R2 AD FS：
  • 遷移到 Windows Server 2012 R2 上的 AD FS
• AD FS 2.0 升級至 Windows Server 2012 AD FS：
  • 遷移到 Windows Server 2012 上的 AD FS
• AD FS 1.x 升級至 AD FS 2.0：
  • 從 AD FS 1.x 升級至 AD FS 2.0

如果您需要從 AD FS 2.0 或 2.1 (Windows Server 2008 R2 或 Windows Server 2012) 升級，請使用內建指令碼 (位於 C:\Windows\ADFS)。

Windows Server 2016 已新增 HTTP/2 支援，但 HTTP/2 無法用於用戶端憑證驗證。 許多 AD FS 案例都使用用戶端憑證驗證。 而許多用戶端不支援使用 HTTP/1.1 重試要求。 因此，AD FS 伺服器陣列組態會將本機伺服器的 HTTP 設定重新設定為 HTTP/1.1。 此重新設定需要重新啟動伺服器。

支援此設定，但不支援新的 AD FS 2016 功能。 此設定在從 AD FS 2012 R2 移轉至 AD FS 2016 期間是暫時的。 它不應該長時間使用。

是的，但有一個副作用：

• 您需要手動管理更新權杖簽署憑證，因為 Azure AD 將無法存取同盟中繼資料。 如需有關手動更新權杖簽署憑證的詳細資訊，請參閱更新 Office 365 和 Azure Active Directory 的同盟憑證。
• 您將無法使用舊版驗證流程 (例如，ExO Proxy 驗證流程)。

AD FS 是無狀態系統，因此負載平衡對於登入來說相當簡單。這裡是負載平衡系統的一些重要建議：

• 負載平衡器不應設定 IP 親和性。 在某些 Exchange Online 案例中，IP 親和性可能會對部分伺服器造成過度負載。
• 負載平衡器不得終止 HTTPS 連線並啟動與 AD FS 伺服器的新連線。
• 負載平衡器應確保正在連線的 IP 位址在傳送至 AD FS 時，應該轉譯為 HTTP 封包中的來源 IP。 如果負載平衡器無法在 HTTP 封包中傳送來源 IP，則負載平衡器必須將 IP 位址新增至 X-Forwarded-For 標頭。 您必須執行此步驟才能正確處理與某些 IP 相關的功能 (例如禁用 IP 和外部網路智慧鎖定)。 如果未正確實作此設定，則安全性可能會降低。
• 負載平衡器應支援 SNI。 如果不支援，請確保 AD FS 已設定為建立 HTTPS 繫結，以處理不支援 SNI 的用戶端。
• 負載平衡器應使用 AD FS HTTP 健康情況探查端點來偵測 AD FS 或 Web 應用程式 Proxy 伺服器是否正在執行。 如果未傳回 200 OK，則應該加以排除。

AD FS 支援多個多樹系設定。 且其依賴基礎 AD DS 信任網路來驗證橫跨多個受信任領域的使用者。 我們強烈建議使用雙向樹系信任，因為它們更容易設定，這有助於確保信任系統正常運作。

此外：

• 如果您有單向樹系信任，例如包含合作夥伴身分識別的周邊網路 (也稱為 DMZ) 樹系，建議您在公司樹系中部署 AD FS。 將周邊網路樹系視為另一個透過 LDAP 連線的本機宣告提供者信任。 在此情況下，Windows 整合式驗證不適用於周邊網路樹系使用者。 他們需要使用密碼驗證，因為這是 LDAP 唯一支援的機制。

  如果您無法使用此選項，則必須在周邊網路樹系中設定另一台 AD FS 伺服器。 然後在公司樹系的 AD FS 伺服器中，將其新增為宣告提供者信任。 使用者必須進行主領域探索，但 Windows 整合式驗證和密碼驗證都會正常執行。 在周邊網路樹系的 AD FS 中，對發行規則進行適當的變更，因為公司樹系中的 AD FS 將無法從周邊網路樹系取得使用者的詳細資訊。

• 網域層級信任受到支援，且可以運作。 但強烈建議您移至樹系層級信任模型。 您也必須確保 UPN 路由和 NetBIOS 名稱解析正常運作。

是，您可以考慮為熟悉和未知的位置使用 IPv6 位址。

AD FS 提供了可延伸的機制，讓第三方多重要素驗證提供者進行整合。 並沒有固定的認證方案。 在發行之前，假設廠商已執行必要的驗證。

這裡提供已通知 Microsoft 的廠商清單：AD FS 的多重要素驗證提供者。 其中可能有我們不知道的提供者。 當我們發現新的提供者時，會更新該清單。

是，第三方 Proxy 可以放在 AD FS 前面，但所有第三方 Proxy 都必須支援 MS-ADFSPIP 通訊協定，才能用來取代 Web 應用程式 Proxy。

我們目前知道下列第三方提供者。 其中可能有我們不知道的提供者。 當我們發現新的提供者時，會更新該清單。

• F5 存取原則管理員
• Citrix 應用程式傳遞控制器 (ADC)

您可以下載 AD FS 2016 版的試算表。 您也可以在 Windows Server 2012 R2 中將此試算表用於 AD FS。

Apple 發行了一組稱為 App Transport Security (ATS) 的需求，其可能影響來自向 AD FS 驗證之 iOS 應用程式的呼叫。 只要確定 AD FS 和 Web 應用程式 Proxy 都支援使用 ATS 進行連線的需求，即可確保 AD FS 和 Web 應用程式 Proxy 相符。 尤其是您應該確認：

• 您的 AD FS 和 Web 應用程式 Proxy 伺服器支援 TLS 1.2。
• TLS 連線的交涉加密套件將支援完全正向加密。

如需啟用和停用 SSL 2.0 和 3.0 和 TLS 1.0、1.1 和 1.2 的相關資訊，請參閱在 AD FS 中管理 SSL 通訊協定。

若要確保 AD FS 和 Web 應用程式 Proxy 只會交涉可支援 ATP 的 TLS 加密套件，您可停用不在 ATP 相容加密套件清單中的所有加密套件。 若要加以停用，請使用 Windows TLS PowerShell Cmdlet。

「sub」宣告的值是用戶端識別碼和錨點宣告值的雜湊。

重新整理權杖的存留期會是 AD FS 從遠端宣告提供者信任所取得權杖的存留期。 存取權杖的存留期會是對其發行存取權杖之信賴憑證者的權杖存留期。

您可以使用自訂的 id_token，在 id_token 本身新增相關資訊。 如需詳細資訊，請參閱自訂要在 id_token 中發出的宣告。

AD FS 2016 中為此案例新增了特殊 ValueType (http://www.w3.org/2001/XMLSchema#json) 和逸出字元 (\x22)。 使用下列範例來作為發行規則和存取權杖的最終輸出。

發行規則範例：

=> issue(Type = "array_in_json", ValueType = "http://www.w3.org/2001/XMLSchema#json", Value = "{\x22Items\x22:[{\x22Name\x22:\x22Apple\x22,\x22Price\x22:12.3},{\x22Name\x22:\x22Grape\x22,\x22Price\x22:3.21}],\x22Date\x22:\x2221/11/2010\x22}");

在存取權杖中發出的宣告：

"array_in_json":{"Items":[{"Name":"Apple","Price":12.3},{"Name":"Grape","Price":3.21}],"Date":"21/11/2010"}

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

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

支援：

• aza。 如果您使用 Broker 用戶端的 OAuth 2.0 通訊協定延伸模組，且範圍參數包含 aza 範圍，則伺服器會發出新的主要重新整理權杖，並將其設定在回應的 refresh_token 欄位中。 如果強制執行，它還會將 refresh_token_expires_in 欄位設定為新主要重新整理權杖的生命週期。
• openid。 可讓應用程式要求使用 OpenID Connect 授權通訊協定。
• logon_cert。 允許應用程式要求登入憑證，這可用來以互動方式登入已驗證的使用者。 AD FS 伺服器會省略回應中的 access_token 參數，並改為提供 Base64 編碼的 CMS 憑證鏈或 CMC 完整 PKI 回應。 如需詳細資訊，請參閱處理詳細資料。
• user_impersonation。 如果您想要從 AD FS 要求代表存取權杖，則為必要項目。 如需此範圍使用方式的詳細資訊，請參閱透過使用 OAuth 搭配 AD FS 2016 的代理者 (OBO) 建置多層式應用程式。

不受支援：

• vpn_cert。 允許應用程式要求 VPN 憑證，其可用來建立使用 EAP-TLS 驗證的 VPN 連線。 不再支援此範圍。
• 電子郵件。 允許應用程式要求已登入使用者的電子郵件宣告。 不再支援此範圍。
• 設定檔。 允許應用程式要求已登入使用者的設定檔相關宣告。 不再支援此範圍。

AD FS SSL 憑證與 AD FS 管理嵌入式管理單元中的 AD FS 服務通訊憑證不同。 若要變更 AD FS SSL 憑證，您必須使用 PowerShell。 請遵循在 AD FS 和 WAP 2016 中管理 SSL 憑證中的指引。

如需停用和啟用 SSL 通訊協定和加密套件的相關資訊，請參閱在 AD FS 中管理 SSL 通訊協定。

• 如果 Proxy 用來代理使用 Windows 整合式驗證的 AD FS 要求，則 Proxy SSL 憑證必須使用與同盟伺服器 SSL 憑證相同的金鑰。
• 如果已啟用 AD FS ExtendedProtectionTokenCheck 屬性 (AD FS 中的預設設定)，則 Proxy SSL 憑證必須使用與同盟伺服器 SSL 憑證相同的金鑰。
• 否則，Proxy SSL 憑證可具有與 AD FS SSL 憑證不同的金鑰。 它必須符合相同的需求。

當應用程式明確要求的特定驗證 URI 對應至已設定並啟用的驗證方法時，AD FS 在登入畫面中只顯示一種驗證方法。 該方法會在 WS-同盟要求的 wauth 參數中傳達。 它會在 SAML 通訊協定要求的 RequestedAuthnCtxRef 參數中傳達。 僅顯示要求的驗證方法。 (例如，密碼登入。)

當 AD FS 與 Azure AD 搭配使用時，應用程式通常會將 prompt=login 參數傳送至 Azure AD。 Azure AD 預設會將此參數轉譯為要求以全新的密碼登入 AD FS。 此案例是您可能在網路中看到 AD FS 上的密碼登入，或看不到使用憑證登入選項最常見的原因。 您可以藉由變更 Azure AD 中的同盟網域設定，輕鬆地解決此問題。

如需詳細資訊，請參閱 Active Directory 同盟服務 prompt=login 參數支援。

若要變更 AD FS 服務帳戶，請使用 AD FS 工具箱服務帳戶 PowerShell 模組。 如需指示，請參閱變更 AD FS 服務帳戶。

請參閱將瀏覽器設定為使用 Windows 整合式驗證 (WIA) 搭配 AD FS。

如果您沒有以 AD FS 上的裝置為基礎的存取控制原則，或使用 AD FS 的 Windows Hello 企業版憑證註冊，您可以關閉 BrowserSsoEnabled。 BrowserSsoEnabled 可讓 AD FS 從包含裝置資訊的用戶端收集主要重新整理權杖 (PRT)。 如果沒有該權杖，AD FS 的裝置驗證將無法在 Windows 10 裝置上運作。

系統管理員通常會想知道使用者不需輸入新的認證即可取得單一登入 (SSO) 的時間長度，以及系統管理員如何控制該行為。 AD FS 單一登入設定中會說明此行為，以及控制該行為的組態設定。

以下列出各種 Cookie 和權杖的預設存留期 (以及控管存留期的參數)：

已註冊的裝置

• PRT 和 SSO Cookie：最多 90 天，由 PSSOLifeTimeMins 控管。 (如果裝置至少每 14 天使用一次。此時間範圍由 DeviceUsageWindow 控制。)

• 重新整理權杖：根據上述參數計算以提供一致的行為。

• access_token：預設為一小時，根據信賴憑證者而定。

• id_token：與 access_token 相同。

未註冊的裝置

• SSO Cookie：預設為八小時，由 SSOLifetimeMins 控管。 啟用 [讓我保持登入 (KMSI)] 時，預設值為 24 小時。 此預設值可透過 KMSILifetimeMins 進行設定。

• 重新整理權杖：預設為八小時。 如果已啟用 KMSI，則為 24 小時。

• access_token：預設為一小時，根據信賴憑證者而定。

• id_token：與 access_token 相同。

AD FS 不支援機密用戶端的隱含流程。 僅對權杖端點啟用用戶端驗證，而 AD FS 不會在沒有用戶端驗證的情況下發出存取權杖。 如果機密用戶端需要存取權杖，也需要使用者驗證，則必須使用授權碼流程。

HSTS 是 Web 安全性原則機制。 它可協助同時具有 HTTP 和 HTTPS 端點的服務降低通訊協定降級攻擊和 Cookie 劫持的風險。 其可讓網頁伺服器宣告網頁瀏覽器 (或其他相符的使用者代理程式) 只能使用 HTTPS (而不能透過 HTTP 通訊協定) 與其互動。

Web 驗證流量的所有 AD FS 端點都會以獨佔方式透過 HTTPS 開啟。 因此，AD FS 減輕了 HSTS 原則機制所造成的威脅。 (根據設計，不會降級至 HTTP，因為 HTTP 中沒有接聽程式。)AD FS 也會使用安全旗標來標記所有 Cookie，以防止 Cookie 傳送至另一部具有 HTTP 通訊協定端點的伺服器。

因此，您不需要 AD FS 伺服器上的 HSTS，因為 HSTS 無法降級。 AD FS 伺服器符合合規性需求，因為它們無法使用 HTTP，且因為 Cookie 標示為安全。

最後，AD FS 2016 (具有最新的修補程式) 和 AD FS 2019 都支援發出 HSTS 標頭。 若要設定此行為，請參閱使用 AD FS 自訂 HTTP 安全性回應標頭。

我們不建議您在 Web 應用程式 Proxy 伺服器之前執行 SSL 終止。 如果在 Web 應用程式 Proxy 伺服器前面完成，則 X-MS-Forwarded-Client-IP 將包含 Web 應用程式 Proxy 伺服器前面的網路裝置 IP。 以下是 AD FS 所支援的各種 IP 相關宣告的簡短描述：

• X-MS-Client-IP。 連線到 STS 的裝置的網路 IP。 對於外部網路要求，此宣告一律包含 Web 應用程式 Proxy 伺服器的 IP。
• X-MS-Forwarded-Client-IP。 多重值宣告，其中包含 Exchange Online 轉送至 AD FS 的任何值。 它也包含連線到 Web 應用程式 Proxy 伺服器的裝置 IP 位址。
• Userip。 對於外部網路要求，此宣告會包含 X-MS-Forwarded-Client-IP 的值。 對於內部網路要求，此宣告會包含與 X-MS-Client-IP 相同的值。

在 AD FS 2016 (具有最新修補程式) 和更新版本中，也支援擷取 X-Forwarded-For 標頭。 未在第 3 層轉寄的任何負載平衡器或網路裝置 (已保留 IP)，都應該將連入的用戶端 IP 新增至業界標準 X-Forwarded-For 標頭。

AD FS UserInfo 端點一律會傳回 OpenID 標準中所指定的主體宣告。 AD FS 不支援透過 UserInfo 端點所要求的其他宣告。 如果您需要識別碼權杖中的更多宣告，請參閱 AD FS 中的自訂識別碼權杖。

只有當網域中存在具有 FSMO PDC 角色的 Windows Server 2016 網域控制站時，才會建立此群組。 若要解決錯誤，您可以手動建立群組。 將服務帳戶新增為群組成員之後，請採取下列步驟來新增必要的權限：

1. 開啟 [Active Directory 使用者及電腦]。
2. 在左側窗格中，以滑鼠右鍵按一下您的網域名稱，然後選取 [屬性]。
3. 選取安全性。 (如果沒有 [安全性] 索引標籤，請開啟 [檢視] 功能表上的 [進階功能]。)
4. 選取 [進階]、[新增]，然後 [選取主體]。
5. [選取使用者]、[電腦]、[服務帳戶] 或 [群組] 對話方塊隨即出現。 在 [輸入物件名稱來選取] 文字方塊中，輸入 Key Admin Group。 選取 [確定]。
6. 在 [適用對象] 方塊中，選取 [子系使用者物件]。
7. 捲動到頁面底部，然後選取 [清除所有]。
8. 在 [屬性] 區段中，選取 [讀取 msDS-KeyCredentialLink] 和 [寫入 msDS-KeyCrendentialLink]。

對於使用 Android ADAL 程式庫的應用程式，同盟使用者的 Azure AD 驗證可能會失敗。 此應用程式會在嘗試顯示登入頁面時，收到 AuthenticationException。 在 Chrome 瀏覽器中，AD FS 登入頁面可能會被描述為不安全。

針對橫跨所有版本和所有裝置，Android 不支援從憑證的 authorityInformationAccess 欄位下載其他憑證。 此限制也適用於 Chrome 瀏覽器。 如果未從 AD FS 傳遞整個憑證鏈，則任何缺少中繼憑證的伺服器驗證憑證都會造成此錯誤。

您可以藉由設定 AD FS 和 Web 應用程式 Proxy 伺服器來傳送必要的中繼憑證以及 SSL 憑證，來解決此問題。

當您從一部電腦匯出 SSL 憑證，以匯入到 AD FS 和 Web 應用程式 Proxy 伺服器的電腦個人存放區時，請務必匯出私密金鑰，然後選取 [個人資訊交換 - PKCS #12]。

此外，請務必選取 [盡可能包含憑證路徑中的所有憑證]，以及 [匯出所有擴充屬性]。

在 Windows 伺服器上執行 certlm.msc，並將 *.pfx 匯入到電腦的個人憑證存放區中。 這樣做會導致伺服器將整個憑證鏈傳遞至 ADAL 程式庫。

AD FS 不支援 HEAD 要求。 應用程式不應該對 AD FS 端點使用 HEAD 要求。 使用這些要求可能會導致未預期或延遲的 HTTP 錯誤回應。 您可能也會在 AD FS 事件記錄檔中看到未預期的錯誤事件。

如果 IdP 所發行權杖的有效期間少於 1 小時，則不會發行重新整理權杖。 若要確保已發行重新整理權杖，請將 IdP 所發行權杖的有效期限增加至 1 小時以上。

RP 權杖加密會設定為 AES256。 您無法將其變更為任何其他值。

混合模式 AD FS 伺服器陣列是暫時的。 我們建議您在規劃期間在升級程序前先變換 SSL 憑證，或在更新 SSL 憑證之前完成此程序並提升伺服器陣列行為層級。 如果未遵循該建議，請使用下列指示來更新 SSL 憑證。

在 Web 應用程式 Proxy 伺服器上，您仍然可以使用 Set-WebApplicationProxySslCertificate。 在 AD FS 伺服器上，您必須使用 netsh。 完成下列步驟：

1. 選取 AD FS 2016 伺服器的子集以進行維護。

2. 在上一個步驟中選取的伺服器上，透過 MMC 匯入新的憑證。

3. 刪除現有的憑證：

   a. netsh http delete sslcert hostnameport=fs.contoso.com:443

   b. netsh http delete sslcert hostnameport=localhost:443

   c. netsh http delete sslcert hostnameport=fs.contoso.com:49443

4. 新增憑證：

   a. netsh http add sslcert hostnameport=fs.contoso.com:443 certhash=THUMBPRINT appid="{5d89a20c-beab-4389-9447-324788eb944a}" certstorename=My verifyclientcertrevocation=Enable sslctlstorename=AdfsTrustedDevices

   b. netsh http add sslcert hostnameport=localhost:443 certhash=THUMBPRINT appid="{5d89a20c-beab-4389-9447-324788eb944a}" certstorename=My verifyclientcertrevocation=Enable

   c. netsh http add sslcert hostnameport=fs.contoso.com:49443 certhash=THUMBPRINT appid="{5d89a20c-beab-4389-9447-324788eb944a}" certstorename=My verifyclientcertrevocation=Enable clientcertnegotiation=Enable

5. 在選取的伺服器上重新啟動 AD FS 服務。

6. 移除 Web 應用程式 Proxy 伺服器的子集以進行維護。

7. 在選取的 Web 應用程式 Proxy 伺服器上，透過 MMC 匯入新憑證。

8. 使用下列 Cmdlet 在 Web 應用程式 Proxy 伺服器上設定新憑證：

   • Set-WebApplicationProxySslCertificate -Thumbprint " CERTTHUMBPRINT"

9. 在選取的 Web 應用程式 Proxy 伺服器上重新啟動服務。

10. 將選取的 Web 應用程式 Proxy 和 AD FS 伺服器放回生產環境中。

以相同方式更新其餘的 AD FS 和 Web 應用程式 Proxy 伺服器。

AD FS 和 Web 應用程式伺服器支援任何不會在端點上執行 SSL 終止的防火牆。 此外，AD FS/Web 應用程式 Proxy 伺服器具有內建機制，可：

• 協助防止常見的 Web 攻擊，例如跨網站指令碼。
• 執行 AD FS Proxy。
• 滿足 MS-ADFSPIP protocol 通訊協定的所有需求。

在 AD FS 2016 中，權杖繫結會自動啟用，並導致 Proxy 和同盟案例發生多個已知問題。 這些問題會導致此事件。 若要解決此問題，請執行下列 PowerShell 命令，以移除權杖繫結支援：

Set-AdfsProperties -IgnoreTokenBinding $true

升級至 Windows Server 2019 之後，Web 應用程式 Proxy 的設定版本會繼續顯示為 Windows Server 2016。 Web 應用程式 Proxy 沒有適用於 Windows Server 2019 的新版本特定功能。 如果 AD FS 上提升了伺服器陣列行為層級，Web 應用程式 Proxy 會繼續顯示為 Windows Server 2016。 這是設計的行為。

啟用 ESL 時，AD FS 會追蹤 ADFSArtifactStore 資料庫中使用者的帳戶活動和已知位置。 此資料庫會隨著所追蹤的使用者數目和已知位置數目而相對調整。 當您打算啟用 ESL 時，可以估計 ADFSArtifactStore 資料庫會以每 100,000 位使用者最多 1 GB 的速度成長。

如果 AD FS 伺服器陣列使用 Windows 內部資料庫，則資料庫檔案的預設位置為 C:\Windows\WID\Data。 為了防止填滿此磁碟機，請務必在啟用 ESL 之前，至少有 5 GB 的可用儲存體。 除了磁碟儲存體以外，請在啟用 ESL 之後，針對總處理序記憶體進行規劃，50 萬或更少使用者人口數最多可成長額外 1GB 的 RAM。

以下是該事件的文字：

Active Directory trust enumeration was unable to enumerate one of more domains due to the following error. Enumeration will continue but the Active Directory identifier list may not be correct. Validate that all expected Active Directory identifiers are present by running Get-ADFSDirectoryProperties.

當 AD FS 嘗試列舉受信任樹系鏈結中的所有樹系並連結所有樹系，但樹系卻不受信任時，就會發生此事件。 例如，假設 AD FS 樹系 A 和樹系 B 受信任，而樹系 B 和樹系 C 受信任。 AD FS 會將這三個樹系全都列舉出來，並嘗試尋找樹系 A 和樹系 C 之間的信任。如果失敗樹系中的使用者應由 AD FS 進行驗證，則請設定 AD FS 樹系與失敗樹系之間的信任。 如果失敗樹系中的使用者不應由 AD FS 驗證，則請忽略此事件。

以下是該事件的文字：

Microsoft.IdentityServer.AuthenticationFailedException: MSIS5015: Authentication of the presented token failed. Token Binding claim in token must match the binding provided by the channel.

在 AD FS 2016 中，權杖繫結會自動啟用，並導致 Proxy 和同盟案例發生多個已知問題。 這些問題會導致此事件。 若要解決此問題，請執行下列 PowerShell 命令，並移除權杖繫結支援：

Set-AdfsProperties -IgnoreTokenBinding $true

以下是該事件的文字：

System.ServiceModel.FaultException: The formatter threw an error while trying to deserialize the message: There was an error while trying to deserialize parameter schemas.microsoft.com/ws/2009/12/identityserver/protocols/policystore:maxBehaviorLevel". The InnerException message was "Invalid enum value 'Win2019' cannot be deserialized into type 'Microsoft.IdentityServer.FarmBehavior'. Ensure that the necessary enum values are present and are marked with EnumMemberAttribute attribute if the type has DataContractAttribute attribute.

當這兩個陳述句都成立時，預期會發生此事件：

• 您有混合模式伺服器陣列。
• AD FS 2019 會將伺服器陣列行為層級上限資訊提供給主要同盟伺服器，且同盟伺服器版本 2016 無法辨識。

AD FS 2019 持續嘗試在伺服器陣列中共用 MaxBehaviorLevel 值 Win2019，直到該值在兩個月後過期，並自動從伺服器陣列中移除。 若要避免收到此事件，請將主要同盟角色移轉至最新版本的同盟伺服器。 請遵循將 AD FS 伺服器陣列升級至 Windows Server 2019 伺服器陣列行為層級中的指示。