共用方式為

設定使用者憑證驗證的 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) 位置可從網際網路存取。
  • 如果您要配置 Microsoft Entra 證書驗證 AD FS，請確保您已經配置證書核發單位和序號所需的 Microsoft Entra 設定及 AD FS 宣告規則。
  • 如果您正與 Exchange ActiveSync 客戶進行 Microsoft Entra 證書驗證，客戶證書在主旨替代名稱欄位的主體名稱值或 RFC822 名稱值的 Exchange Online 必須要有使用者的可路由電子郵件信箱位址。 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 ID 保護對公司資源的存取，並預防任何資料外洩，請配置 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。 第二個模式會使用具有連接埠 443 的主機 adfs.contoso.com 和 certauth.adfs.contoso.com。 您需要 SSL 憑證，才能支援 certauth.\<adfs-service-name> 作為替代主體名稱。 您可以在建立伺服器陣列時或稍後透過 PowerShell 執行此動作。

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

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

檢查 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_applicaitonGUID}。

檢查用戶端裝置是否已正確佈建憑證

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

  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 ID。 Microsoft Entra ID 預設轉換為登入 AD FS 的新密碼。 因此，即使您在 AD FS 中設定憑證驗證，您的使用者也只會看到密碼登入。 若要修正這個問題：

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

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

其他疑難排解

在罕見的情況下，如果您的 CRL 清單很長，則嘗試下載時可能會達到逾時。 在此情況下，您必須更新 MaxFieldLength 和 MaxRequestByte，如 Windows 的 Http.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