共用方式為

配置 AD FS 支持使用者憑證驗證

本文說明如何在 Active Directory 同盟服務 （AD FS） 中啟用使用者憑證驗證。 它也提供這類驗證常見問題的疑難解答資訊。

用戶憑證驗證有兩個主要使用案例：

  • 使用者正在使用智慧卡來登入其AD FS系統。
  • 使用者正在使用預配置至行動裝置的憑證。

先決條件

  • 使用 AD FS 支援替代主機名的憑證驗證中所述的其中一種模式，判斷您想要啟用的 AD FS 使用者憑證驗證模式。
  • 請確定所有 AD FS 和 Web 應用程式 Proxy （WAP） 伺服器都已安裝並信任您的用戶憑證信任鏈結，包括任何中繼證書頒發機構單位。 您通常會透過 AD FS 和 WAP 伺服器上的組策略物件 （GPO） 來執行此動作。
  • 請確保用戶憑證的信任鏈結的根憑證已存放在 Active Directory 的 NTAuth 存儲區中。
  • 如果您在替代憑證驗證模式中使用AD FS，請確定您的AD FS和 WAP 伺服器具有安全套接字層 （SSL） 憑證，其中包含前置詞為 「certauth」 的 AD FS 主機名。例如 certauth.fs.contoso.com。 也請確保允許此主機名稱的網路流量通過防火牆。
  • 如果您是從外部網路使用憑證驗證，請確定您憑證中指定的清單中至少有一個授權單位資訊存取 （AIA） 和至少一個 CRL 發佈點 （CDP） 或在線憑證狀態通訊協定 （OCSP） 位置可從因特網存取。
  • 如果您要設定 AD FS 進行Microsoft Entra 憑證驗證，請確定您已設定憑證簽發者和序號所需的 Microsoft Entra 設定 和 AD FS 宣告規則 。
  • 如果您對 Exchange ActiveSync 用戶端使用 Microsoft Entra 憑證驗證，用戶端憑證必須在 Exchange Online 中的 主體替代名稱 欄位內，擁有使用者的可路由電子郵件地址，這可以出現在 主要名稱 值或 RFC822 名稱 值中。 Microsoft Entra ID 會將 RFC822 值對應至目錄中的 Proxy 位址屬性。

備註

AD FS 不支援智慧卡或憑證型驗證的用戶名稱提示。

啟用用戶憑證驗證

使用AD FS管理主控台或 PowerShell Cmdlet Set-AdfsGlobalAuthenticationPolicy，在 AD FS 中將使用者憑證驗證啟用為內部網路或外部網路驗證方法。

選擇性考慮包括：

  • 如果您想要除了 EKU 宣告類型之外，還要根據憑證字段和延伸模組使用宣告， https://schemas.microsoft.com/2012/12/certificatecontext/extension/eku請在 Active Directory 宣告提供者信任上設定更多宣告傳遞規則。 請參閱本文稍後部分的可用憑證宣告完整清單。

  • 如果您需要根據憑證類型限制存取，您可以在應用程式的 AD FS 發行授權規則中使用憑證上的其他屬性。 常見案例是只允許行動裝置管理 （MDM） 提供者布建的憑證，或只允許智慧卡憑證。

    這很重要

    使用裝置程式碼流程進行驗證並且使用除了 Microsoft Entra ID 以外的識別提供者（例如 AD FS）執行裝置驗證的客戶，將無法強制執行基於裝置的 Microsoft Entra 資源存取。 例如，他們不能只允許使用第三方 MDM 服務來管理的裝置。

    為了協助保護Microsoft Entra標識符中公司資源的存取，並防止數據外泄，請設定 Microsoft Entra 裝置型條件式存取。 例如，使用 [要求裝置標示為投訴] 來授與Microsoft Entra 條件式存取中的控制權。

    在 Schannel SSP 技術概觀中，依據「管理受信任的簽發者以進行客戶端驗證」的指引來設定客戶端憑證的允許發行證書頒發機構。

  • 請考慮修改登入頁面，以符合使用者在進行憑證驗證時的需求。 常見的案例是將 使用 X509 憑證登入 變更為更方便使用者使用的專案。

在 Windows 桌面上設定 Chrome 瀏覽器的無縫憑證驗證

當計算機有多個用戶憑證（例如 Wi-Fi 憑證），以滿足客戶端驗證目的時，Windows 桌面上的 Chrome 瀏覽器會提示使用者選取正確的憑證。 此提示可能會讓使用者感到困惑。 若要優化此體驗，您可以設定 Chrome 的原則，以自動選取正確的憑證。

您可以藉由進行登錄變更來手動設定此原則，也可以透過 GPO 自動設定此原則（設定登錄機碼）。 這需要您的使用者用戶端憑證在 AD FS 認證時，具有不同於其他使用案例的簽發者。

如需設定 Chrome 憑證驗證的詳細資訊，請參閱 Chrome 企業原則清單。

憑證驗證故障排除

當您為使用者設定 AD FS 進行憑證驗證時，請使用下列資訊來針對常見問題進行疑難解答。

檢查憑證信任的發行者是否已在所有 AD FS 和 WAP 伺服器中正確設定

如果憑證信任的簽發者未正確設定，常見的徵兆是 HTTP 204 錯誤：「沒有來自 https://certauth.adfs.contoso.com."的內容;

AD FS 會使用基礎 Windows 作業系統來證明用戶憑證的擁有權，並藉由驗證憑證信任鏈，確保它符合受信任的簽發者。 若要與受信任的簽發者匹配，您必須確定所有根和中繼授權機構都在本機存放區中設定為電腦證書授權中心的受信任簽發者。

若要自動驗證此專案，請使用 AD FS診斷分析器工具。 此工具會查詢所有伺服器，並確保正確配置合適的憑證。

  1. 下載並執行工具。
  2. 上傳結果並檢閱是否有任何失敗。

檢查 AD FS 驗證原則中是否已啟用憑證驗證

AD FS 預設會在埠 49443 上執行使用者憑證驗證，其主機名與 AD FS 相同（例如：）。 adfs.contoso.com 您也可以使用替代 SSL 系結，將 AD FS 設定為使用埠 443（預設 HTTPS 連接埠）。 不過，此組態中使用的 URL 是 certauth.<adfs-farm-name> （例如： certauth.contoso.com。 如需詳細資訊，請參閱 AD FS支援替代主機名系結以進行憑證驗證。

備註

在 Windows Server 2016 上的 AD FS 中，現在支援兩種模式。 第一個模式會使用具有埠 443 和 49443 的主機 adfs.contoso.com 。 第二個模式使用主機 adfs.contoso.com 和 certauth.adfs.contoso.com，並使用 443 埠。 您需要 SSL 憑證，才能支援 certauth.\<adfs-service-name> 作為替代主體名稱。 您可以在建立伺服場時，或稍後透過 PowerShell 執行此動作。

最常見的網路連線問題案例是防火牆設定不正確，並封鎖用戶憑證驗證的流量。 通常，當發生此問題時，您會看到空白畫面或 500 伺服器錯誤。 若要修正此問題：

  1. 記下您在AD FS 中設定的主機名和埠。
  2. 請確定 AD FS 或 WAP 前面的任何防火牆都已設定為允許 hostname:port 組合，以支援您的 AD FS 伺服器陣列。 您的網路工程師必須執行此步驟。

檢查 CRL 連線狀況

證書吊銷清單（CRL）是作為執行運行時撤銷檢查的端點，被編碼到用戶憑證中。 例如，如果包含憑證的裝置遭竊，系統管理員可以將憑證新增至已撤銷的憑證清單。 任何先前接受此憑證的端點現在都會失敗驗證。

每個 AD FS 和 WAP 伺服器都必須連線到 CRL 端點，以驗證提供給它的憑證是否仍然有效且尚未撤銷。 CRL 驗證可以透過 HTTPS、HTTP、LDAP 或 OCSP 進行。 如果AD FS和 WAP 伺服器無法連線到端點，驗證將會失敗。 請使用以下步驟進行故障排除：

  1. 請洽詢公鑰基礎結構 （PKI） 工程師，以判斷要使用哪些 CRL 端點來撤銷 PKI 系統的用戶憑證。
  2. 在每個 AD FS 和 WAP 伺服器上，確定 CRL 端點可透過所使用的通訊協定連線（通常是 HTTPS 或 HTTP）。
  3. 若要進行進階驗證，請在每個 AD FS 和 WAP 伺服器上 啟用 CAPI2 事件記錄 。
  4. 檢查 CAPI2 作業記錄中的事件識別碼 41 （驗證撤銷）。
  5. 檢查<Result value="80092013">The revocation function was unable to check revocation because the revocation server was offline.</Result>。

小提示

您可以將 DNS 解析（Windows 上的主機檔案）設定為指向特定伺服器，以將單一 AD FS 或 WAP 伺服器作為目標，以便更輕鬆地進行疑難解答。 這項技術可讓您以伺服器為目標來啟用追蹤。

檢查 SNI 問題

AD FS 需要用戶端裝置（或瀏覽器）和負載平衡器才能支援伺服器名稱指示（SNI）。 某些客戶端裝置（例如舊版 Android）可能不支援 SNI。 此外，負載平衡器可能不支援 SNI，或可能未針對 SNI 進行設定。 在這些情況下，您可能會發生使用者驗證失敗。

若要修正此問題，請與您的網路工程師合作，以確保AD FS和WAP的負載平衡器支援 SNI。 如果無法支援 SNI，請在 AD FS 中使用下列因應措施：

  1. 在主要 AD FS 伺服器上開啟管理員模式命令提示字元視窗。
  2. 輸入 Netsh http show sslcert。
  3. 複製同盟服務的應用程式 GUID 和憑證哈希。
  4. 輸入 netsh http add sslcert ipport=0.0.0.0:{your_certauth_port} certhash={your_certhash} appid={your_applicationGUID}。

檢查客戶端裝置是否已正確配置憑證

您可能會注意到某些裝置正常運作，但其他裝置並未正常運作。 在大部分情況下，這表示在某些用戶端裝置上未正確布建用戶憑證。 請遵循下列步驟：

  1. 如果問題專屬於Android裝置，最常見的原因是憑證鏈結在裝置上不完全信任。 請參閱您的 MDM 廠商，以確保憑證已正確布建，且整個鏈結在 Android 裝置上完全受信任。

    如果問題專屬於 Windows 裝置，請檢查登入使用者的 Windows 證書存儲（不是系統或計算機），以檢查憑證是否已正確布建。

  2. 將用戶端使用者憑證匯出至.cer檔案，然後執行 命令 certutil -f -urlfetch -verify certificatefilename.cer。

檢查 AD FS/WAP 伺服器與用戶端裝置之間的 TLS 版本是否相容

在罕見的情況下，用戶端裝置會更新為僅支援較高版本的 TLS（例如 1.3）。 或者，您可能會發生反向問題，其中 AD FS 和 WAP 伺服器已更新為只使用用戶端裝置不支援的較高 TLS 版本。

您可以使用在線 SSL 工具來檢查 AD FS 和 WAP 伺服器，並查看它們是否與裝置相容。 如需如何控制 TLS 版本的詳細資訊，請參閱 管理 AD FS 的 SSL/TLS 通訊協定和加密套件。

檢查 Microsoft Entra PromptLoginBehavior 是否已在同盟網域設定上正確設定

許多 Office 365 應用程式都會傳送 prompt=login 至 Microsoft Entra 識別碼。 根據預設，Microsoft Entra 識別符會將它轉換成 AD FS 的新密碼登入。 因此，即使您在AD FS 中設定憑證驗證，您的使用者也只會看到密碼登入。 若要修正這個問題：

  1. 使用 Get-MgDomainFederationConfiguration Cmdlet 取得同盟網域設定。
  2. 確定 PromptLoginBehavior 參數設定為 Disabled 或 NativeSupport。

如需詳細資訊，請參閱 AD FS prompt=login 參數支援。

其他疑難排解

在罕見的情況下，如果您的 CRL 清單非常長，嘗試下載時可能會超時。 在此情況下，您必須更新 MaxFieldLength 和 MaxRequestByte ，如 windowsHttp.sys 登錄設定中所述。

參考：完整的用戶憑證宣告類型和範例值清單

索賠類型 範例值
http://schemas.microsoft.com/2012/12/certificatecontext/field/x509version 3
http://schemas.microsoft.com/2012/12/certificatecontext/field/signaturealgorithm sha256RSA
http://schemas.microsoft.com/2012/12/certificatecontext/field/issuer CN=entca, DC=domain, DC=contoso, DC=com
http://schemas.microsoft.com/2012/12/certificatecontext/field/issuername CN=entca, DC=domain, DC=contoso, DC=com
http://schemas.microsoft.com/2012/12/certificatecontext/field/notbefore 12/05/2016 20:50:18
http://schemas.microsoft.com/2012/12/certificatecontext/field/notafter 12/05/2017 20:50:18
http://schemas.microsoft.com/2012/12/certificatecontext/field/subject E=user@contoso.com, CN=user, CN=Users, DC=domain, DC=contoso, DC=com
http://schemas.microsoft.com/2012/12/certificatecontext/field/subjectname E=user@contoso.com, CN=user, CN=Users, DC=domain, DC=contoso, DC=com
http://schemas.microsoft.com/2012/12/certificatecontext/field/rawdata {Base64 encoded digital certificate data}
http://schemas.microsoft.com/2012/12/certificatecontext/extension/keyusage DigitalSignature
http://schemas.microsoft.com/2012/12/certificatecontext/extension/keyusage KeyEncipherment
http://schemas.microsoft.com/2012/12/certificatecontext/extension/subjectkeyidentifier 9D11941EC06FACCCCB1B116B56AA97F3987D620A
http://schemas.microsoft.com/2012/12/certificatecontext/extension/authoritykeyidentifier KeyID=d6 13 e3 6b bc e5 d8 15 52 0a fd 36 6a d5 0b 51 f3 0b 25 7f
http://schemas.microsoft.com/2012/12/certificatecontext/extension/certificatetemplatename User
http://schemas.microsoft.com/2012/12/certificatecontext/extension/san Other Name:Principal Name=user@contoso.com, RFC822 Name=user@contoso.com
http://schemas.microsoft.com/2012/12/certificatecontext/extension/eku 1.3.6.1.4.1.311.10.3.4