針對 #D56DDE48C0C4243AC9AAB332C0C24F46F (AD FS) 的 SSO 問題進行疑難解答

本文可協助您解決單一登錄 (SSO) Active Directory 同盟服務 (AD FS) 的問題。

根據您遇到的問題類型，選取下列其中一個區段。

適用於：Active Directory 同盟服務
原始 KB 編號： 4034932

NTLM 或窗體型驗證提示

針對單一登錄 (SSO) #DDF2EF6D1247048588933A5501EDCAA9E (AD FS) 的問題進行疑難解答期間，如果使用者收到非預期的 NTLM 或表單型驗證提示，請遵循本文中的步驟來針對此問題進行疑難解答。

檢查 Windows 整合式驗證設定

若要針對此問題進行疑難解答，請檢查客戶端瀏覽器中的 Windows 整合式驗證設定、AD FS 設定和驗證要求參數。

檢查使用者的用戶端瀏覽器

在 [因特網選項] 中檢查下列設定：

• 在 [ 進階 ] 索引標籤上，確定已啟用 [ 啟用整合式 Windows 驗證 ] 設定。
• 遵循 安全>性近端內部網路>網站>進階，確定AD FSURL位於網站清單中。
• 在 [ 安全 > 性近端內部網路 > 自定義層級] 下方，確定已選取 [ 僅在內部網路區域自動登 入] 設定。

如果您使用 Firefox、Chrome 或 Safari，請確定已啟用這些瀏覽器中的對等設定。

檢查 AD FS 設定

檢查 WindowsIntegratedFallback 設定

1. 使用 [以系統管理員身分執行] 選項開啟 Windows PowerShell。

2. 執行下列命令以取得全域驗證原則：

   Get-ADFSGlobalAuthenticationPolicy | fl WindowsIntegratedFallbackEnabled
   

3. 檢查 WindowsIntegratedFallbackEnabled 屬性的值。

如果值為 True，則預期會進行窗體型驗證。 這表示驗證要求來自不支援 Windows 整合式驗證的瀏覽器。 請參閱下一節，瞭解如何支援您的瀏覽器。

如果值為 False，則應該要有 Windows 整合式驗證。

檢查 WIASupportedUsersAgents 設定

1. 執行下列命令以取得支援的使用者代理程式清單：

   Get-ADFSProperties | Select -ExpandProperty WIASupportedUserAgents
   

2. 檢查命令傳回的使用者代理程式字串清單。

確認您瀏覽器的使用者代理程式字串是否在清單中。 如果沒有，請遵循下列步驟來新增使用者代理程式字串：

1. 移至 http://useragentstring.com/ 可偵測並顯示瀏覽器使用者代理程式字串的 。

2. 執行下列命令以取得支援的使用者代理程式清單：

   $wiaStrings = Get-ADFSProperties | Select -ExpandProperty WIASupportedUserAgents
   

3. 執行下列命令，以新增瀏覽器的使用者代理程式字串：

   $wiaStrings = $wiaStrings+"NewUAString"
   

   例如:

   $wiaStrings = $wiaStrings+" =~Windows\s*NT.*Edge"+"Mozilla/5.0"
   

4. 執行下列命令來更新 WIASupportedUserAgents 設定：

   Set-ADFSProperties -WIASupportedUserAgents $wiaStrings
   

檢查驗證要求參數

檢查驗證要求是否將表單型驗證指定為驗證方法

1. 如果驗證要求是 WS-Federation 要求，請檢查要求是否包含 wauth= urn：oasis：names：tc：SAML：1.0：am：password。
2. 如果驗證要求是 SAML 要求，請檢查要求是否包含值為 urn：oasis：names：tc：SAML：2.0：ac：classes：Password 的 samlp：AuthnContextClassRef 元素。

如需詳細資訊，請參閱 AD FS登入頁面的驗證處理程式概觀。

檢查應用程式是否為適用於 Office 365 的 Microsoft Online Services

如果您想要存取的應用程式不是 Microsoft Online Services，您所遇到的體驗會受到傳入驗證要求的預期和控制。 請與應用程式擁有者合作來變更行為。

注意事項

自 2024 年 3 月 30 日起，Azure AD 和 MSOnline PowerShell 模組已被取代。 若要深入瞭解，請閱讀 淘汰更新。 在此日期之後，這些模組的支援僅限於 Microsoft Graph PowerShell SDK 的移轉協助和安全性修正。 已淘汰的模組會繼續運作到 2025 年 3 月 30 日。

建議您移轉至 Microsoft Graph PowerShell，以與 Microsoft Entra ID (先前的 Azure AD) 互動。 如需常見的移轉問題，請參閱 移轉常見問題。 注意： 1.0.x 版的 MSOnline 可能會在 2024 年 6 月 30 日之後中斷。

如果應用程式是 Microsoft Online Services，您所體驗的內容可能會由受信任領域物件的 PromptLoginBehavior 設定所控制。 此設定可控制 Microsoft Entra 租使用者是否將 prompt=login 傳送至 AD FS。 若要設定 PromptLoginBehavior 設定，請遵循下列步驟：

1. 使用 [以系統管理員身分執行] 選項開啟 Windows PowerShell。

2. 執行下列命令以取得現有的網域同盟設定：

   Get-MSOLDomainFederationSettings -DomainName DomainName | FL *
   

3. 執行下列命令來設定 PromptLoginBehavior 設定：

   Set-MSOLDomainFederationSettings -DomainName DomainName -PromptLoginBehavior <TranslateToFreshPasswordAuth|NativeSupport|Disabled> -SupportsMFA <$TRUE|$FALSE> -PreferredAuthenticationProtocol <WsFed|SAMLP>
   

   PromptLoginBehavior 參數的值為：

   1. TranslateToFreshPasswordAuth：Microsoft Entra ID 傳送 wauth 和 wfresh 至 AD FS，而不是 prompt=login。 這會導致驗證要求使用表單型驗證。
   2. NativeSupport:p rompt=login 參數會以原樣傳送至 AD FS。
   3. 已停用：不會將任何專案傳送至 AD FS。

若要深入瞭解 Set-MSOLDomainFederationSettings 命令，請參閱 Active Directory 同盟服務 prompt=login 參數支援。

Microsoft Entra 案例

如果傳送至 Microsoft Entra ID 的驗證要求包含 prompt=login 參數，請執行下列命令來停用 prompt=login 功能：

Set-MsolDomainFederationSettings –DomainName DomainName -PromptLoginBehavior Disabled

執行此命令之後，Office 365 應用程式不會在每個驗證要求中包含 prompt=login 參數。

非 Microsoft Entra 案例

驗證要求中的 WAUTH 和 RequestedAuthNContext 等要求參數可以指定驗證方法。 檢查其他要求參數是否強制執行非預期的驗證提示。 如果是，請修改要求參數以使用預期的驗證方法。

檢查 SSO 是否已停用

如果停用 SSO，請加以啟用，並測試問題是否已解決。

多重要素驗證提示

若要針對此問題進行疑難解答，請檢查信賴憑證者中的宣告規則是否已正確設定為多重要素驗證。

多重要素驗證可以在AD FS伺服器、信賴憑證者端啟用，或在驗證要求參數中指定。 檢查組態以查看是否已正確設定。 如果預期要進行多重要素驗證，但系統會重複提示您進行驗證，請檢查信賴憑證者發行規則，以查看多重要素驗證宣告是否傳遞至應用程式。

如需AD FS中多重要素驗證的詳細資訊，請參閱下列文章：

• ADFS 中 Multi-Factor Authentication 的幕後教學課程 – 第 1 部分：原則
• ADFS 中 Multi-Factor Authentication 的幕後教學課程 – 第 2 部分：MFA 感知信賴憑證者

檢查AD FS伺服器和信賴憑證者上的設定

若要檢查 AD FS 伺服器上的設定，請驗證全域其他驗證規則。 若要檢查信賴憑證者的設定，請驗證信賴憑證者信任的其他驗證規則。

1. 若要檢查 AD FS 伺服器上的設定，請在 Windows PowerShell 視窗中執行下列命令。

   Get-ADFSAdditionalAuthenticationRule
   

   若要檢查信賴憑證者的設定，請執行下列命令：

   Get-ADFSRelyingPartyTrust -TargetName RelyingParty | Select -ExpandProperty AdditionalAuthenticationRules
   

   注意事項

   如果命令未傳回任何內容，則不會設定其他驗證規則。 略過本節。

2. 觀察已設定的宣告規則集。

確認宣告規則集中是否已啟用多重要素驗證

宣告規則集由下列各節組成：

• condition 語句： C:[Type=``…,Value=…]
• issue 語句： => issue (Type=``…,Value=…)

如果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/2012/01/devicecontext/claims/isregistereduser", 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/2012/01/insidecorporatenetwork", Value == "false"] => issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn")

檢查信賴憑證者發行規則

如果使用者在執行第一次驗證之後重複收到多重要素驗證提示，則回復方可能不會透過多重要素驗證宣告傳遞至應用程式。 若要檢查驗證宣告是否通過，請遵循下列步驟：

1. 在 Windows PowerShell 中執行下列命令：

   Get-ADFSRelyingPartyTrust -TargetName ClaimApp
   

2. 觀察IssuanceAuthorizationRules 或IssuanceAuthorizationRulesFile 屬性中定義的規則集。

規則集應包含下列發行規則，以通過多重要素驗證宣告：
C:[Type==http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod, Value==" http://schemas.microsoft.com/claims/multipleauthn"]=>issue(claim = c)

檢查驗證要求參數

檢查驗證要求是否指定多重要素驗證作為驗證方法

• 如果驗證要求是 WS-Federation 要求，請檢查要求是否包含 wauth= http://schemas.microsoft.com/claims/multipleauthn。
• 如果驗證要求是 SAML 要求，請檢查要求是否包含值http://schemas.microsoft.com/claims/multipleauthn為 的 samlp：AuthnContextClassRef 元素。

如需詳細資訊，請參閱 AD FS登入頁面的驗證處理程式概觀。

檢查應用程式是否為適用於 Office 365 的 Microsoft Online Services

如果您想要存取的應用程式是適用於 Office 365 的 Microsoft Online Services，請檢查 SupportsMFA 網域同盟設定。

1. 執行下列命令以取得目前的 SupportsMFA 網域同盟設定：

   Get-MSOLDomainFederationSettings -DomainName DomainName | FL *
   

2. 如果 SupportsMFA 設定為 FALSE，請執行下列命令，將它設定為 TRUE：

   Set-MSOLDomainFederationSettings -DomainName DomainName -SupportsMFA $TRUE
   

檢查 SSO 是否已停用

如果停用 SSO，請加以啟用，並測試問題是否已解決。

用戶無法登入目標網站或服務

此問題可能會發生在 AD FS 登入頁面或應用程式端。

如果問題發生在 AD FS 登入頁面，您會收到「發生錯誤」、「HTTP 503 服務無法使用」或其他錯誤訊息。 錯誤頁面的網址會顯示AD FS 服務名稱，例如 fs.contoso.com。

如果問題發生在應用程式端，則錯誤頁面的URL會顯示目標服務的IP位址或月臺名稱。

根據您遇到此問題的位置，遵循下一節中的步驟。

此問題發生在AD FS登入頁面

若要針對此問題進行疑難解答，請檢查所有使用者是否都受到此問題的影響，以及使用者是否可以存取所有信賴憑證者。

所有用戶都會受到此問題的影響，且使用者無法存取任何信賴憑證者

讓我們使用IdpInitiatedSignOn檢查內部登入功能。 若要這樣做，請使用 IdpInititatedSignOn 頁面來確認 AD FS 服務是否已啟動並執行，且驗證功能是否正常運作。 若要開啟 [IdpInitiatedSignOn] 頁面，請遵循下列步驟：

1. 在AD FS 伺服器上執行下列命令，以啟用 IdpInitiatedSignOn 頁面：

   Set-AdfsProperties -EnableIdPInitiatedSignonPage $true
   

2. 從您網路內的電腦，瀏覽下列頁面：
   https://<FederationInstance>/adfs/ls/idpinitiatedsignon.aspx

3. 在登入頁面上輸入有效用戶的正確認證。

登入成功

如果登入成功，請檢查AD FS服務狀態是否正在執行。

1. 在AD FS 伺服器上開啟 [伺服器管理員]。
2. 在 伺服器管理員 中，按兩下 [工具>服務]。
3. 檢查 Active Directory 同盟服務 的狀態是否為執行中。

然後，使用 IdpInitiatedSignOn 檢查外部登入功能。 使用 [IdpInititatedSignOn] 頁面快速確認 AD FS 服務是否已啟動並執行，且驗證功能是否正常運作。 若要開啟 [IdpInitiatedSignOn] 頁面，請遵循下列步驟：

1. 在AD FS 伺服器上執行下列命令，以啟用 IdpInitiatedSignOn 頁面：

   Set-AdfsProperties -EnableIdPInitiatedSignonPage $true
   

2. 從您網路外部的電腦，瀏覽下列頁面：
   https://<FederationInstance>/adfs/ls/idpinitiatedsignon.aspx

3. 在登入頁面上輸入有效用戶的正確認證。

如果登入失敗，請參閱檢查 AD FS 相關的元件和服務和檢查 Proxy 信任關係。

如果登入成功，請繼續進行疑難解答，並執行 所有使用者都受到問題影響中的步驟，而且使用者可以存取部分信賴憑證者。

登入失敗

如果登入失敗， 請檢查AD FS相關的元件和服務。

檢查 AD FS 服務狀態是否正在執行。

1. 在AD FS 伺服器上開啟 [伺服器管理員]。
2. 在 伺服器管理員 中，按兩下 [工具>服務]。
3. 檢查 Active Directory 同盟服務 的狀態是否為執行中。

檢查端點是否已啟用。 AD FS 針對不同的功能和案例提供各種端點。 預設不會啟用所有端點。 若要檢查端點的狀態，請遵循下列步驟：

1. 在AD FS 伺服器上，開啟AD FS管理主控台。

2. 展開 [服務>端點]。

3. 找出端點，並確認 [已啟用] 資料行上的狀態是否已啟 用 。

   

然後，檢查是否已安裝 Microsoft Entra Connect。 建議您使用 Microsoft Entra Connect，讓 SSL 憑證管理更容易。

如果已安裝 Microsoft Entra Connect，請確定您使用它來管理和更新 SSL 憑證。

如果未安裝 Microsoft Entra Connect，請檢查 SSL 憑證是否符合下列 AD FS 需求：

• 憑證來自受信任的跟證書授權單位。

  AD FS 要求 SSL 憑證來自受信任的跟證書授權單位。 如果 AD FS 是從未加入網域的電腦存取，建議您使用來自受信任第三方跟證書授權單位的 SSL 憑證，例如 DigiCert、VeriSign 等。如果 SSL 憑證不是來自受信任的跟證書授權單位，則 SSL 通訊可能會中斷。

• 憑證的主體名稱是有效的。

  主體名稱應該符合同盟服務名稱，而不是AD FS伺服器名稱或其他名稱。 若要取得同盟服務名稱，請在主要 AD FS 伺服器上執行下列命令：
  Get-AdfsProperties | select hostname

• 憑證不會被撤銷。

  檢查憑證撤銷。 如果憑證遭到撤銷，則無法信任 SSL 連線，而且會遭到客戶端封鎖。

如果 SSL 憑證不符合這些需求，請嘗試取得 SSL 通訊的合格憑證。 建議您使用 Microsoft Entra Connect，讓 SSL 憑證管理更容易。 請參閱更新 Active Directory 同盟服務 (AD FS) 伺服器陣列的 TLS/SSL 憑證。

如果 SSL 憑證符合這些需求，請檢查下列 SSL 憑證設定。

檢查 SSL 憑證是否已正確安裝

SSL 憑證應該安裝到伺服器數位中每個同盟伺服器上本機電腦 的個人 存放區。 若要安裝憑證，請按兩下 。憑證的 PFX 檔案，並遵循精靈。

若要確認憑證是否安裝到正確的位置，請遵循下列步驟：

1. 執行下列命令，列出本機計算機 個人 存放區中的憑證：
   dir Cert:\LocalMachine\My
2. 檢查憑證是否在清單中。

檢查是否使用正確的 SSL 憑證

取得用於 SSL 通訊的憑證指紋，並確認指紋是否符合預期的憑證指紋。

若要取得使用中憑證的指紋，請在 Windows PowerShell 中執行下列命令：

Get-AdfsSslCertificate

如果使用錯誤的憑證，請執行下列命令來設定正確的憑證：

Set-AdfsSslCertificate –Thumbprint CorrectThumprint

檢查 SSL 憑證是否設定為服務通訊憑證

SSL 憑證必須設定為AD FS伺服器陣列中的服務通訊憑證。 這不會自動發生。 若要檢查是否已設定正確的憑證，請遵循下列步驟：

1. 在AD FS管理控制台中，展開 [服務>憑證]。
2. 確認 [ 服務通訊 ] 下所列的憑證是否為預期的憑證。

如果列出錯誤的憑證，請設定正確的憑證，然後將憑證的 讀 取許可權授與 AD FS 服務。 如果要執行這項操作，請依照下列步驟執行：

1. 設定正確的憑證：

   1. 以滑鼠右鍵按兩下 [憑證]，然後按兩下 [ 設定服務通訊憑證]。
   2. 選取正確的憑證。

2. 確認 AD FS 服務是否具有憑證的 讀 取權限：

   1. 將本機計算機帳戶的 憑證 嵌入式管理單元新增至 Microsoft Management Console (MMC) 。
   2. 展開 [本機計算機] () >[個人>憑證] 的 [憑證]。
   3. 以滑鼠右鍵按兩下 SSL 憑證，然後按兩下 [所有工作>管理私鑰]。
   4. 確認 adfssrv 是否列在具有 [讀取] 許可權的 [群組] 和 [用戶名稱] 底下。

3. 如果未列出 adfssrv，請將憑證的 讀 取許可權授與 AD FS 服務：

   1. 依序按兩下 [新增]、[ 位置]、[伺服器]，然後按兩下 [ 確定]。
   2. 在 [輸入要選取的對象名稱] 下，輸入 nt service\adfssrv，按兩下 [檢查名稱]，然後按兩下 [ 確定]。
      如果您使用 AD FS 搭配裝置註冊服務 (DRS) ，請改為輸入 nt service\drs 。
   3. 授與 [讀取] 許可權，然後按兩下 [ 確定]。

檢查是否已在AD FS 中設定裝置註冊服務 (DRS)

如果您已使用 DRS 設定 AD FS，請確定 SSL 憑證也已針對 RDS 正確設定。 例如，如果有兩個 UPN 後綴 contoso.com 和 fabrikam.com，憑證必須具有 enterpriseregistration.contoso.com 和 enterpriseregistration.fabrikma.com 作為主體別名 (SAN) 。

若要檢查 SSL 憑證是否有正確的 SAN，請遵循下列步驟：

1. 執行下列命令，列出組織中使用的所有 UPN 後綴：

   Get-AdfsDeviceRegistratrionUpnSuffix
   

2. 確認 SSL 憑證是否已設定必要的 SAN。

3. 如果 SSL 憑證沒有正確的 DRS 名稱作為 SAN，請取得具有適用於 DRS 之正確 SAN 的新 SSL 憑證，然後使用它作為 AD FS 的 SSL 憑證。

然後，檢查 WAP 伺服器上的憑證設定和後援系結：

• 檢查是否已在所有 WAP 伺服器上設定正確的 SSL 憑證。

  1. 請確定 SSL 憑證已安裝在每部 WAP 伺服器上本機電腦 的個人 存放區中。

  2. 執行下列命令，以取得 WAP 所使用的 SSL 憑證：

     Get-WebApplicationProxySslCertificate
     

  3. 如果 SSL 憑證錯誤，請執行下列命令來設定正確的 SSL 憑證：

     Set-WebApplicationProxySslCertificate -Thumbprint Thumbprint
     

• 檢查憑證系結，並視需要加以更新。

  若要支援非 SNI 案例，系統管理員可以指定後援系結。 除了標準 federationservicename：443 系結之外，請在下列應用程式標識符下尋找後援系結：

  • {5d89a20c-beab-4389-9447-324788eb944a}：這是 AD FS 的應用程式標識符。
  • {f955c070-e044-456c-ac00-e9e4275b3f04}：這是 Web 應用程式 Proxy 的應用程式標識符。

  例如，如果為 0.0.0.0：443 之類的後援系結指定 SSL 憑證，請確定當 SSL 憑證更新時，系結會隨之更新。

所有用戶都會受到此問題的影響，而且使用者可以存取部分信賴憑證者

首先，讓我們取得信賴憑證者和 OAuth 客戶端資訊。 如果您使用傳統信賴憑證者，請遵循下列步驟：

1. 在主要 AD FS 伺服器上，使用 [以系統管理員身分執行] 選項開啟 Windows PowerShell。

2. 執行下列命令，將AD FS 2.0元件新增至 Windows PowerShell：

   Add-PSSnapin Microsoft.Adfs.PowerShell
   

3. 執行下列命令以取得信賴憑證者資訊：

   $rp = Get-AdfsRelyingPartyTrust RPName
   

4. 執行下列命令以取得 OAuth 用戶端資訊：

   $client = Get-AdfsClient ClientName
   

如果您在 Windows Server 2016 中使用應用程式群組功能，請遵循下列步驟：

1. 在主要 AD FS 伺服器上，使用 [以系統管理員身分執行] 選項開啟 Windows PowerShell。

2. 執行下列命令以取得信賴憑證者資訊：
   $rp = Get-AdfsWebApiApplication ResourceID

3. 如果 OAuth 用戶端是公用的，請執行下列命令來取得用戶端資訊：

   $client = Get-AdfsNativeClientApplication ClientName
   

   如果客戶端是機密用戶端，請執行下列命令來取得客戶端資訊：

   $client = Get-AdfsServerApplication ClientName
   

現在繼續進行下列疑難解答方法。

檢查信賴憑證者和客戶端的設定

信賴憑證者標識碼、用戶端標識碼和重新導向 URI 應由應用程式和客戶端的擁有者提供。 不過，擁有者提供的內容與 AD FS 中設定的內容之間可能仍然不相符。 例如，錯字可能造成不相符。 檢查擁有者所提供的設定是否符合AD FS中設定的設定。 上一頁中的步驟可讓您透過PowerShell在AD FS中設定設定。

擁有者提供的設定	在AD FS 中設定的設定
信賴憑證者標識碼	$rp。標識碼
信賴憑證者重新導向 URI	的前置詞或通配符相符專案 $rp。WS-Fed 信賴憑證者的 WSFedEndpoint $rp。SAML 信賴憑證者的 SamlEndpoints
用戶端識別碼	$client。ClientId
用戶端重新導向 URI	$client的前置詞比對。RedirectUri

如果數據表中的專案相符，請另外檢查這些設定是否符合傳送至 AD FS 之驗證要求中顯示的內容，以及在 AD FS 中設定的專案。 嘗試重現您在應用程式傳送至 AD FS 的驗證要求上擷取 Fiddler 追蹤的問題。 檢查要求參數，根據要求類型執行下列檢查。

OAuth 要求

OAuth 要求看起來如下所示：

https://sts.contoso.com/adfs/oauth2/authorize?response_type=code&client_id=ClientID&redirect_uri=https://www.TestApp.com&resource=https://www.TestApp.com

檢查要求參數是否符合AD FS 中設定的設定。

要求參數	在AD FS 中設定的設定
client_id	$client。ClientId
redirect_uri	的前置詞相符專案 @client_RedirectUri

“resource” 參數應該代表 AD FS 中有效的信賴憑證者。 執行下列其中一個命令來取得信賴憑證者資訊。

• 如果您使用傳統信賴憑證者，請執行下列命令：
  Get-AdfsRelyingPartyTrust -Identifier "ValueOfTheResourceParameter"
• 如果您在 Windows Server 2016 中使用應用程式群組功能，請執行下列命令：
  Get-AdfsWebApiApplication "ValueOfTheResourceParameter"

WS-Fed 要求

WS-Fed 要求如下所示：

https://fs.contoso.com/adfs/ls/?wa=wsignin1.0&wtrealm=https://claimsweb.contoso.com&wctx=rm=0&id=passive&ru=/&wct=2014-10-21T22:15:42Z

檢查要求參數是否符合AD FS 中設定的設定：

要求參數	在AD FS 中設定的設定
wtrealm	$rp。標識碼
wreply	$rp的前置詞比對或通配符比對。WSFedEndpoint

SAML 要求

SAML 要求如下所示：

https://sts.contoso.com/adfs/ls/?SAMLRequest=EncodedValue&RelayState=cookie:29002348&SigAlg=http://www.w3.org/2000/09/Fxmldsig#rsa-sha1&Signature=Signature

使用 Fiddler 文字精靈中的 [從 DeflatedSAML] 選項譯碼 SAMLRequest 參數的值。 譯碼的值如下所示：

<samlp:AuthnRequest ID="ID" Version="2.0" IssueInstant="2017-04-28T01:02:22.664Z" Destination="https://TestClaimProvider-Samlp-Only/adfs/ls" Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified" ForceAuthn="true" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"><Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">http://fs.contoso.com/adfs/services/trust</Issuer><samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" AllowCreate="true" /></samlp:AuthnRequest>

在已譯碼的值內執行下列檢查：

• 檢查 Destination 值中的主機名是否符合 AD FS 主機名。
• 檢查簽發者的值是否符合 $rp.Identifier。

SAML 的其他注意事項：

• $rp。SamlEndpoints：顯示所有類型的 SAML 端點。 AD FS 的回應會傳送至端點中設定的對應URL。 SAML 端點可以使用重新導向、張貼或成品系結來傳輸訊息。 所有這些 URL 都可以在 AD FS 中設定。
• $rp。SignedSamlRequestsRequired：如果已設定值，則必須簽署從信賴憑證者傳送的 SAML 要求。 要求中必須有 「SigAlg」 和 「Signature」 參數。
• $rp。RequestSigningCertificate：這是用來在 SAML 要求上產生簽章的簽署憑證。 請確定憑證有效，並要求應用程式擁有者符合憑證。

檢查加密憑證

如果 $rp.EncryptClaims 傳回 Enabled，則會啟用信賴憑證者加密。 AD FS 會使用加密憑證來加密宣告。 執行下列檢查：

• $rp。EncryptionCertificate：使用此命令來取得憑證，並檢查其是否有效。
• $rp。 EncryptionCertificateRevocationCheck：使用此命令來檢查憑證是否符合撤銷檢查需求。

前兩種方法無法運作

若要繼續進行疑難解答，請 參閱使用傾印令牌應用程式。

並非所有使用者都受到此問題的影響，而且用戶無法存取任何信賴憑證者

在此案例中，請執行下列檢查。

檢查使用者是否已停用

檢查 Windows PowerShell 或UI中的用戶狀態。 如果停用使用者，請啟用使用者。

使用 Windows PowerShell 檢查用戶狀態

1. 登入任何域控制器。

2. 開啟 [Windows PowerShell]。

3. 執行下列命令來檢查用戶狀態：

   Get-ADUser -Identity <samaccountname of the user> | Select Enabled
   

   

檢查UI中的用戶狀態

1. 登入任何域控制器。

2. 開啟 Active Directory 使用者和電腦 管理主控台。

3. 按兩下 [ 使用者] 節點，以滑鼠右鍵按下右窗格中的使用者，然後按兩下 [ 屬性]。

4. 按兩下 [ 帳戶] 索引 標籤。

5. 在 [ 帳戶選項] 下方，檢查 [帳戶是否已停 用]。

   

6. 如果已核取選項，請取消核取它。

檢查使用者屬性最近是否已更新

如果 Active Directory 中已更新使用者的任何屬性，則會導致用戶物件的元數據變更。 檢查使用者元數據物件，以查看最近更新的屬性。 如果找到變更，請確定相關服務會挑選變更。 若要檢查使用者是否有屬性變更，請遵循下列步驟：

1. 登入域控制器。

2. 開啟 [Windows PowerShell]。

3. 執行下列命令來取得使用者物件的元資料：
   repadmin /showobjmeta <destination DC> "user DN"

   命令的範例如下：
   repadmin /showobjmeta localhost "CN=test user,CN=Users,DC=fabidentity,DC=com"

4. 在元數據中，檢查每個屬性的時間/日期數據行，以取得變更的任何線索。 在下列範例中，userPrincipleName 屬性所採用的日期比代表用戶物件元數據變更的其他屬性還要新。

   

如果使用者屬於另一個樹系，請檢查樹系信任

在多樹系AD FS環境中，部署AD FS的樹系與其他利用AD FS部署進行驗證的樹系之間需要雙向樹系信任。 若要確認樹系之間的信任是否如預期般運作，請遵循下列步驟：

1. 登入部署AD FS之樹系中的域控制器。

2. 開啟 [Active Directory 網域與信任] 管理控制台。

3. 在管理控制台中，以滑鼠右鍵按兩下包含您想要驗證之信任的網域，然後按兩下 [ 屬性]。

4. 按兩下 [ 信任] 索引標籤 。

5. 在 [受此網域信任的網域] 下， () 或 信任此網域的網域 (連入信任) ，按兩下要驗證的信任，然後按兩下 [ 屬性]。

6. 按兩下 [驗證]。
   在 [Active Directory 網域服務] 對話框中，選取其中一個選項。

   • 如果您選取 [否]，建議您針對互連網域重複相同的程式。

   • 如果您選取 [ 是]，請提供對等網域的系統管理用戶認證。 不需要為互動式網域執行相同的程式。

     

如果這些步驟無法協助您解決問題，請繼續進行疑難解答，並使用 「並非所有使用者都受到問題影響」一節中的步驟，使用者可以存取部分信賴憑證者 一節。

並非所有用戶都會受到此問題的影響，而且使用者可以存取部分信賴憑證者

在此案例中，請檢查此問題是否發生在 Microsoft Entra 案例中。 如果是，請執行這些檢查以針對此問題進行疑難解答。 如果沒有，請 參閱使用傾印令牌應用程式 來針對此問題進行疑難解答。

檢查使用者是否已同步至 Microsoft Entra ID

如果用戶嘗試登入 Microsoft Entra ID，系統會將他們重新導向至 AD FS 以進行同盟網域的驗證。 登入失敗的其中一個可能原因是使用者尚未同步至 Microsoft Entra ID。 在 AD FS 第一次嘗試驗證之後，您可能會看到從 Microsoft Entra ID 到 Active Directory FS 的迴圈。 若要判斷使用者是否同步至 Microsoft Entra ID，請遵循下列步驟：

1. 下載並安裝適用於 Windows PowerShell 的 Azure AD PowerShell 模組。
2. 使用 [以系統管理員身分執行] 選項開啟 Windows PowerShell。
3. 執行下列命令來起始與 Microsoft Entra ID 的連線：
   Connect-MsolService
4. 提供連線的全域管理員認證。
5. 執行下列命令，以取得 Microsoft Entra ID 中的使用者清單：
   Get-MsolUser
6. 確認使用者是否在清單中。

如果使用者不在清單中，請將使用者同步至 Microsoft Entra ID。

檢查發行宣告規則中的immutableID和UPN

Microsoft Entra ID 需要 immutableID 和使用者的 UPN 來驗證使用者。

注意事項

immutableID 在下列工具中也稱為 sourceAnchor：

• Azure AD 同步
• Azure Active Directory Sync (DirSync)

系統管理員可以使用 Microsoft Entra Connect，透過 Microsoft Entra ID 自動管理 AD FS 信任。 如果您不是透過 Microsoft Entra Connect 來管理信任，建議您下載 Microsoft Entra Connect Microsoft Entra Connect 會根據同步設定啟用自動宣告規則管理。

若要檢查 AD FS 中 immutableID 和 UPN 的宣告規則是否符合 Microsoft Entra ID 使用的內容，請遵循下列步驟：

1. 在 Microsoft Entra Connect 中取得 sourceAnchor 和 UPN。

   1. 開啟 Microsoft Entra Connect] 。

   2. 按兩下 [檢視目前的設定]。

      

   3. 在 [ 檢閱您的解決方案] 頁面上，記下 [來源錨 點] 和 [ 用戶主體名稱] 的值。

2. 在AD FS 伺服器中設定的對應宣告規則中，確認immutableID (sourceAnchor) 和 UPN 的值。

   1. 在AD FS 伺服器上，開啟AD FS管理主控台。

   2. 按兩下 [信賴憑證者信任]。

   3. 以滑鼠右鍵按兩下信賴憑證者信任與 Microsoft Entra ID，然後按兩下 [編輯宣告發行原則]。

   4. 開啟不可變標識碼和UPN的宣告規則。

   5. 確認查詢 immutableID 和 UPN 值的變數是否與 Microsoft Entra Connect 中顯示的變數相同。

      

3. 如果有差異，請使用下列其中一種方法：

   • 如果 AD FS 是由 Microsoft Entra Connect 管理，請使用 Microsoft Entra Connect 重設信賴憑證者信任。
   • 如果AD FS不是由 Microsoft Entra Connect 管理，請使用正確的屬性更正宣告。

如果這些檢查無法協助您解決問題，請參閱 使用傾印令牌應用程式 對此問題進行疑難解答。

此問題發生在應用程式端

如果AD FS最近更新了令牌簽署憑證，請檢查同盟合作夥伴是否已挑選新的憑證。 如果 AD FS 使用最近也更新的令牌解密憑證，也請執行相同的檢查。 若要檢查 AD FS 上目前的 AD FS 令牌簽署憑證是否符合同盟夥伴上的憑證，請遵循下列步驟：

1. 執行下列命令，在AD FS上取得目前的令牌簽署憑證：

   Get-ADFSCertificate -CertificateType token-signing
   

2. 在傳回的憑證清單中，尋找 IsPrimary = TRUE 的憑證，並記下指紋。

3. 取得同盟夥伴上目前令牌簽署憑證的指紋。 應用程式擁有者必須提供此資訊。

4. 比較兩個憑證的指紋。

請執行相同的檢查，檢查 AD FS 是否使用更新的令牌解密憑證，不同之處在於在 AD FS 上取得令牌解密憑證的命令如下所示：

Get-ADFSCertificate -CertificateType token-decrypting

兩個憑證的指紋相符

如果指紋相符，請確定合作夥伴使用新的 AD FS 憑證。

如果憑證不相符，請確定合作夥伴正在使用新的憑證。 憑證包含在AD FS 伺服器所發佈的同盟元數據中。

注意事項

合作夥伴會參考您所有的資源組織或帳戶組織合作夥伴，以信賴憑證者信任和宣告提供者信任在您的 AD FS 中表示。

• 合作夥伴可以存取同盟元數據

  如果合作夥伴可以存取同盟元數據，請要求合作夥伴使用新的憑證。

• 合作夥伴無法存取同盟元數據

  在此情況下，您必須手動將新憑證的公鑰傳送給合作夥伴。 如果要執行這項操作，請依照下列步驟執行：

  1. 將公鑰導出為 .cert 檔案，或匯出為 .p7b 檔案，以包含整個憑證鏈結。
  2. 將公鑰傳送給合作夥伴。
  3. 要求合作夥伴使用新的憑證。

兩個憑證的指紋不相符

然後，檢查是否有令牌簽署演算法不相符。 如果要執行這項操作，請依照下列步驟執行：

1. 執行下列命令來判斷信賴憑證者所使用的演算法：

   Get-ADFSRelyingPartyTrust -Name RPName | FL SignatureAlgorithm
   

   可能的值為SHA1或SHA256。

2. 請向應用程式擁有者確認應用程式端所使用的演算法。

3. 檢查兩個演算法是否相符。

如果兩個演算法相符，請檢查名稱識別碼格式是否符合應用程式所需的格式。

1. 在AD FS 伺服器上，執行下列命令來傾印發行轉換規則：

   (Get-AdfsRelyingPartyTrust -Name RPName).IssuanceTransformRules
   

2. 找出發出 NameIdentifier 宣告的規則。 如果這類規則不存在，請略過此步驟。

   以下是規則的範例：

   c:[Type == "http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"] => issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Value = c.Value, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] = "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified");

   請注意下列語法中的 NameIdentifier 格式：

   Properties["Property-type-URI"] = "ValueURI"

   可能的格式如下所示。 第一個格式是預設值。

   • urn：oasis：names：tc：SAML：1.1：nameid-format：unspecifie。
   • urn：oasis：names：tc：SAML：1.1：nameid-format：emailAddress
   • urn：oasis：names：tc：SAML：2.0：nameid-format：persistent
   • urn：oasis：names：tc：SAML：2.0：nameid-format：transient

3. 向應用程式擁有者要求應用程式所需的 NameIdentifier 格式。

4. 確認兩個 NameIdentifier 格式是否相符。

5. 如果格式不相符，請將 NameIdentifier 宣告設定為使用應用程式所需的格式。 如果要執行這項操作，請依照下列步驟執行：

   1. 開啟 AD FS 管理主控台。
   2. 按兩下 [信賴憑證者信任]，選取適當的同盟夥伴，然後按兩下 [動作] 窗格中的 [編輯宣告發行原則]。
   3. 如果沒有規則可發出 NameIdentifier 宣告，或更新現有規則，請新增規則。 選取 [傳入宣告類型的名稱標識符]，然後指定應用程式所需的格式。

   

如果兩個演算法不相符，請更新信賴憑證者信任所使用的簽署演算法。

1. 開啟 AD FS 管理主控台。

2. 以滑鼠右鍵按兩下信賴憑證者信任，然後按兩下 [ 屬性]。

3. 在 [ 進階 ] 索引標籤上，選取演算法以符合應用程式所需的演算法。

   

關於憑證自動更新

如果令牌簽署憑證或令牌解密憑證是自我簽署的，則預設會在這些憑證上啟用 AutoCertificateRollover，而且 AD FS 會在憑證即將到期時管理憑證的自動更新。

若要判斷您是否使用自我簽署憑證，請遵循下列步驟：

1. 執行下列命令：

   Get-ADFSCerticate -CertificateType "token-signing"
   

   

2. 檢查憑證屬性。

   如果 Subject 和 Issuer 屬性都是以 “CN=ADFS Signing...” 開頭，則憑證會自我簽署並由 AutoCertRollover 管理。

若要確認憑證是否自動更新，請遵循下列步驟：

1. 執行下列命令：

   Get-ADFSProperties | FL AutoCertificateRollover
   

   

2. 檢查 AutoCertificateRollover 屬性。

   • 如果 AutoCertificateRollover = TRUE，AD FS 預設會在到期前 30 天自動產生新的憑證 () ，並將它們設定為到期前 25 天 (的主要憑證) 。
   • 如果 AutoCertificateRollover = FALSE，您必須手動取代憑證。

檢查ADFS相關的元件和服務

本文介紹如何檢查 ADFS 相關的元件和服務。 當您針對登入 (SSO) Active Directory 同盟服務 (ADFS) 問題進行疑難解答時，這些步驟可能會有説明。

檢查 DNS

存取 ADFS 應該直接指向其中一個 WAP (Web 應用程式 Proxy) 伺服器或 WAP 伺服器前面的負載平衡器。 執行下列檢查：

• ping 同盟服務名稱 (例如 fs.contoso.com) 。 確認 Ping 解析為 的 IP 位址是否屬於其中一部 WAP 伺服器或 WAP 伺服器的負載平衡器。
• 檢查 DNS 伺服器中是否有同盟服務的 A 記錄。 A 記錄應該指向其中一部 WAP 伺服器或 WAP 伺服器的負載平衡器。

如果您的外部存取案例中未實作 WAP，請檢查存取 ADFS 是否直接指向 ADFS 伺服器或 ADFS 伺服器前面的負載平衡器：

• ping 同盟服務名稱 (例如 fs.contoso.com) 。 確認您取得的IP位址是否解析為其中一部ADFS伺服器或ADFS伺服器的負載平衡器。
• 檢查 DNS 伺服器中是否有同盟服務的 A 記錄。 A 記錄應該指向其中一部 ADFS 伺服器或 ADFS 伺服器的負載平衡器。

檢查負載平衡器是否已使用

檢查防火牆是否在下列項目之間封鎖流量：

• ADFS 伺服器和負載平衡器。
• 如果使用 WAP，WAP (Web 應用程式 Proxy) 伺服器和負載平衡器。

如果負載平衡器上已啟用探查，請檢查下列專案：

• 如果您執行 Windows Server 2012 R2，請確定已安裝 2014 年 8 月的更新匯總。
• 檢查是否已在 WAP 伺服器和 ADFS 伺服器的防火牆中啟用埠 80。
• 確定已針對埠 80 和端點 /adfs/probe 設定探查。

檢查防火牆設定

檢查是否已啟用透過 TCP 連接埠 443 的輸入流量：

• Web 應用程式 Proxy 伺服器與同盟伺服器數位之間的防火牆。
• 用戶端與 Web 應用程式 Proxy 伺服器之間的防火牆。

當下列條件成立時，檢查用戶端與 Web 應用程式 Proxy 伺服器之間的防火牆上是否已啟用透過 TCP 連接埠 49443 的輸入流量：

• 已啟用使用 X.509 憑證的 TLS 用戶端驗證。
• 您在 Windows Server 2012 R2 上使用 ADFS。

注意事項

Web 應用程式 Proxy 伺服器與同盟伺服器之間的防火牆上不需要設定。

檢查是否已在 Proxy 上啟用端點

ADFS 針對不同的功能和案例提供各種端點。 預設不會啟用所有端點。 若要檢查是否已在 Proxy 上啟用端點，請遵循下列步驟：

1. 在ADFS伺服器上，開啟ADFS管理主控台。

2. 展開 [服務>端點]。

3. 找出端點，並確認 [已啟用 Proxy] 資料行上的狀態是否 已啟用 。

   

檢查 Proxy 信任關係

如果已部署 Web 應用程式 Proxy (WAP) ，則必須在 WAP 伺服器與 AD FS 伺服器之間建立 Proxy 信任關係。 檢查 Proxy 信任關係是否已建立，或在某個時間點開始失敗。

注意事項

此頁面上的信息適用於AD FS 2012 R2和更新版本。

背景資訊

Proxy 信任關係是以客戶端憑證為基礎。 當您執行 Web 應用程式 Proxy 安裝後精靈時，精靈會使用您在精靈中指定的認證來產生自我簽署客戶端憑證。 然後精靈會將憑證插入AD FS組態資料庫，並將其新增至AD FS伺服器上的AdfsTrustedDevices證書存儲。

針對任何 SSL 通訊，http.sys 使用下列優先順序順序，讓 SSL 憑證系結符合憑證：

優先順序	名稱	參數	描述
1	IP	IP：port	完全符合IP和埠
2	SNI	Hostname：port	確切的主機名相符 (連線必須指定 SNI)
3	Ccs	連接埠	叫用中央證書存儲
4	IPv6 通配符	連接埠	IPv6 通配符比對 (連線必須是 IPv6)
5	IP 通配符	連接埠	IP 通配符比對 (連線可以是 IPv4 或 IPv6)

AD FS 2012 R2 和更新版本與 Internet Information Services (IIS) 無關，並在 http.sys 上以服務的形式執行。 AD FS 會使用 hostname：port SSL 憑證系結。 在用戶端憑證驗證期間，AD FS 會根據 AdfsTrustedDevices 存放區中的憑證， (CTL) 傳送憑證信任清單。 如果 AD FS 伺服器的 SSL 憑證系結使用 IP：port，或 CTL 存放區不是 AdfsTrustedDevices，則可能無法建立 Proxy 信任關係。

取得 AD FS 的 SSL 憑證系結

在AD FS 伺服器上，於 Windows PowerShell 中執行下列命令：
netsh http show sslcert

在傳回的系結清單中，尋找應用程式標識符為 5d89a20c-beab-4389-9447-324788eb944a 的系結。 以下是狀況良好的系結範例。 記下 [Ctl Store 名稱] 行。

Hostname:port : adfs.contoso.com:443
Certificate Hash : 3638de9b03a488341dfe32fc3ae5c480ee687793
Application ID : {5d89a20c-beab-4389-9447-324788eb944a}
Certificate Store Name : MY
Verify Client Certificate Revocation : Enabled
Verify Revocation Using Cached Client Certificate Only : Disabled
Usage Check : Enabled
Revocation Freshness Time : 0
URL Retrieval Timeout : 0
Ctl Identifier : (null)  
Ctl Store Name : AdfsTrustedDevices
DS Mapper Usage : Disabled
Negotiate Client Certificate : Disabled

執行腳本以自動偵測問題

若要自動偵測 Proxy 信任關係的問題，請執行下列腳本。 根據偵測到的問題，據此採取動作。

param
(
  [switch]$syncproxytrustcerts
)
function checkhttpsyscertbindings()
{
Write-Host; Write-Host("1 – Checking http.sys certificate bindings for potential issues")
$httpsslcertoutput = netsh http show sslcert
$adfsservicefqdn = (Get-AdfsProperties).HostName
$i = 1
$certbindingissuedetected = $false
While($i -lt $httpsslcertoutput.count)
{
        $ipport = $false
        $hostnameport = $false
        if ( ( $httpsslcertoutput[$i] -match "IP:port" ) ) { $ipport = $true }
        elseif ( ( $httpsslcertoutput[$i] -match "Hostname:port" ) ) { $hostnameport = $true }
        ## Check for IP specific certificate bindings
        if ( ( $ipport -eq $true ) )
        {
            $httpsslcertoutput[$i]
            $ipbindingparsed = $httpsslcertoutput[$i].split(":")
            if ( ( $ipbindingparsed[2].trim() -ne "0.0.0.0" ) -and ( $ipbindingparsed[3].trim() -eq "443") )
            {
                $warning = "There is an IP specific binding on IP " + $ipbindingparsed[2].trim() + " which may conflict with the AD FS port 443 cert binding." | Write-Warning
                $certbindingissuedetected = $true
            }
            $i = $i + 14
            continue
        }
        ## check that CTL Store is set for ADFS service binding
        elseif ( $hostnameport -eq $true )
        {
            $httpsslcertoutput[$i]
            $ipbindingparsed = $httpsslcertoutput[$i].split(":")
            If ( ( $ipbindingparsed[2].trim() -eq $adfsservicefqdn ) -and ( $ipbindingparsed[3].trim() -eq "443") -and ( $httpsslcertoutput[$i+10].split(":")[1].trim() -ne "AdfsTrustedDevices" ) )
            {
                Write-Warning "ADFS Service binding does not have CTL Store Name set to AdfsTrustedDevices"
                $certbindingissuedetected = $true
            }
        $i = $i + 14
        continue
        }
    $i++
}
If ( $certbindingissuedetected -eq $false ) { Write-Host "Check Passed: No certificate binding issues detected" }
}
function checkadfstrusteddevicesstore()
{
## check for CA issued (non-self signed) certs in the AdfsTrustedDevices cert store
Write-Host; Write-Host "2 – Checking AdfsTrustedDevices cert store for non-self signed certificates"
$certlist = Get-Childitem cert:\LocalMachine\AdfsTrustedDevices -recurse | Where-Object {$_.Issuer -ne $_.Subject}
If ( $certlist.count -gt 0 )
{
    Write-Warning "The following non-self signed certificates are present in the AdfsTrustedDevices store and should be removed"
    $certlist | Format-List Subject
}
Else { Write-Host "Check Passed: No non-self signed certs present in AdfsTrustedDevices cert store" }
}
function checkproxytrustcerts
{
    Param ([bool]$repair=$false)
    Write-Host; Write-Host("3 – Checking AdfsTrustedDevices cert store is in sync with ADFS Proxy Trust config")
    $doc = new-object Xml
    $doc.Load("$env:windir\ADFS\Microsoft.IdentityServer.Servicehost.exe.config")
    $connString = $doc.configuration.'microsoft.identityServer.service'.policystore.connectionString
    $command = "Select ServiceSettingsData from [IdentityServerPolicy].[ServiceSettings]"
    $cli = new-object System.Data.SqlClient.SqlConnection
    $cli.ConnectionString = $connString
    $cmd = new-object System.Data.SqlClient.SqlCommand
    $cmd.CommandText = $command
    $cmd.Connection = $cli
    $cli.Open()
    $configString = $cmd.ExecuteScalar()
    $configXml = new-object XML
    $configXml.LoadXml($configString)
    $rawCerts = $configXml.ServiceSettingsData.SecurityTokenService.ProxyTrustConfiguration._subjectNameIndex.KeyValueOfstringArrayOfX509Certificate29zVOn6VQ.Value.X509Certificate2
    #$ctl = dir cert:\LocalMachine\ADFSTrustedDevices
    $store = new-object System.Security.Cryptography.X509Certificates.X509Store("ADFSTrustedDevices","LocalMachine")
    $store.open("MaxAllowed")
    $atLeastOneMismatch = $false
    $badCerts = @()
    foreach($rawCert in $rawCerts)
    {   
        $rawCertBytes = [System.Convert]::FromBase64String($rawCert.RawData.'#text')
        $cert=New-Object System.Security.Cryptography.X509Certificates.X509Certificate2(,$rawCertBytes)
        $now = Get-Date
        if ( ($cert.NotBefore -lt $now) -and ($cert.NotAfter -gt $now))
        {
            $certThumbprint = $cert.Thumbprint
         $certSubject = $cert.Subject
         $ctlMatch = dir cert:\localmachine\ADFSTrustedDevices\$certThumbprint -ErrorAction SilentlyContinue
         if ($ctlMatch -eq $null)
         {
       $atLeastOneMismatch = $true
          Write-Warning "This cert is NOT in the CTL: $certThumbprint – $certSubject"
       if ($repair -eq $true)
       {
        write-Warning "Attempting to repair"
        $store.Add($cert)
        Write-Warning "Repair successful"
       }
                else
                {
                    Write-Warning ("Please install KB.2964735 or re-run script with -syncproxytrustcerts switch to add missing Proxy Trust certs to AdfsTrustedDevices cert store")
                }
         }
        }
    }
    $store.Close()
    if ($atLeastOneMismatch -eq $false)
    {
     Write-Host("Check Passed: No mismatched certs found. CTL is in sync with DB content")
    }
}
checkhttpsyscertbindings
checkadfstrusteddevicesstore
checkproxytrustcerts($syncproxytrustcerts)
Write-Host; Write-Host("All checks completed.")

問題 1：有 IP 特定系結

系結可能會與埠 443 上的 AD FS 憑證系結衝突。

IP：port 系結的優先順序最高。 如果 IP：port 系結位於 AD FS SSL 憑證系結中，http.sys 一律使用憑證進行 SSL 通訊的系結。 若要解決此問題，請使用下列方法。

1. 拿掉IP：port 系結

   請注意，IP：port 系結可能會在您移除之後傳回。 例如，使用此IP：port 系結設定的應用程式可能會在下一個服務啟動時自動重新建立它。

2. 使用另一個IP位址進行AD FS SSL 通訊

   如果需要IP：port系結，請將ADFS服務 FQDN 解析為未用於任何系結的另一個IP位址。 如此一來，http.sys 會使用 Hostname：port 系結進行 SSL 通訊。

3. 將 AdfsTrustedDevices 設定為 IP：port 系結的 CTL 存放區

   如果您無法使用上述方法，這是最後的手段。 但在您將預設 CTL 存放區變更為 AdfsTrustedDevices 之前，最好先瞭解下列條件：

   • IP：port 系結為何存在。
   • 如果系結依賴預設 CTL 存放區進行客戶端憑證驗證。

問題 2：AD FS 憑證系結未將 CTL 存放區名稱設定為 AdfsTrustedDevices

如果已安裝 Microsoft Entra Connect，請使用 Microsoft Entra Connect 將所有 AD FS 伺服器上 SSL 憑證系結的 CTL 存放區名稱設定為 AdfsTrustedDevices。 如果未安裝 Microsoft Entra Connect，請在所有 AD FS 伺服器上執行下列命令，以重新產生 AD FS 憑證系結。

Set-AdfsSslCertificate -Thumbprint Thumbprint

問題 3：AdfsTrustedDevices 證書存儲中存在未自我簽署的憑證

如果 CA 發行的憑證位於通常只有自我簽署憑證存在的證書存儲中，則從存放區產生的 CTL 只會包含 CA 發行的憑證。 AdfsTrustedDevices 證書存儲是應該只有自我簽署憑證的這類存放區。 這些憑證包括：

• MS-Organization-Access：用來發行工作場所聯結憑證的自我簽署憑證。
• ADFS Proxy 信任：每個 Web 應用程式 Proxy 伺服器的憑證。

因此，請從 AdfsTrustedDevices 證書存儲刪除任何 CA 發行的憑證。

問題 4：安裝KB2964735或使用 -syncproxytrustcerts 重新執行腳本

與AD FS 伺服器建立 Proxy 信任關係時，客戶端憑證會寫入AD FS組態資料庫，並新增至AD FS 伺服器上的AdfsTrustedDevices證書存儲。 針對AD FS 伺服器陣列部署，客戶端憑證應該會同步至其他AD FS 伺服器。 如果因為某些原因而未進行同步處理，Proxy 信任關係只會對建立信任的 AD FS 伺服器運作，而不會對其他 AD FS 伺服器運作。

若要解決此問題，請使用下列其中一種方法。

方法 1

在所有 AD FS 伺服器上安裝 以 KB 2964735 記錄的更新。 安裝更新之後，預期會自動同步處理客戶端憑證。

方法 2

使用 - syncproxytrustcerts 參數執行腳本，以手動將客戶端憑證從 AD FS 組態資料庫同步至 AdfsTrustedDevices 證書存儲。 腳本應該在伺服器陣列中的所有AD FS 伺服器上執行。

注意事項

這不是永久的解決方案，因為客戶端憑證會定期更新。

問題 5：所有檢查都會通過。 但問題仍然存在

檢查時間或時區是否不相符。 如果時間相符，但時區不相符，則 Proxy 信任關係也無法建立。

檢查 AD FS 伺服器與 WAP 伺服器之間是否有 SSL 終止

如果在 AD FS 伺服器與 WAP 伺服器之間的網路裝置上發生 SSL 終止，AD FS 與 WAP 之間的通訊將會中斷，因為通訊是以用戶端憑證為基礎。

在AD FS與 WAP 伺服器之間的網路裝置上停用 SSL 終止。

使用傾印令牌應用程式

當您對同盟服務的問題進行偵錯，以及驗證自定義宣告規則時，傾印令牌應用程式會很有説明。 這不是官方解決方案，而是建議用於疑難解答的正確獨立偵錯解決方案。

使用傾印令牌應用程式之前

在使用傾印令牌應用程式之前，您必須：

1. 取得您想要存取之應用程式的信賴憑證者資訊。 如果已實作 OAuth 驗證，請一併取得 OAuth 客戶端資訊。
2. 設定傾印令牌應用程式。

取得信賴憑證者和 OAuth 客戶端資訊

如果您使用傳統信賴憑證者，請遵循下列步驟：

1. 在 AD FS 伺服器上，使用 [以系統管理員身分執行] 選項開啟 Windows PowerShell。

2. 執行下列命令，將AD FS 2.0元件新增至 Windows PowerShell：

   Add-PSSnapin Microsoft.Adfs.PowerShell
   

3. 執行下列命令以取得信賴憑證者資訊：

   $rp = Get-AdfsRelyingPartyTrust RPName
   

4. 執行下列命令以取得 OAuth 用戶端資訊：

   $client = Get-AdfsClient ClientName
   

如果您在 Windows Server 2016 中使用應用程式群組功能，請遵循下列步驟：

1. 在 AD FS 伺服器上，使用 [以系統管理員身分執行] 選項開啟 Windows PowerShell。

2. 執行下列命令以取得信賴憑證者資訊：

   $rp = Get-AdfsWebApiApplication ResourceID
   

3. 如果 OAuth 用戶端是公用的，請執行下列命令來取得用戶端資訊：

   $client = Get-AdfsNativeClientApplication ClientName
   

   如果 OAuth 用戶端是機密用戶端，請執行下列命令來取得用戶端資訊：

   $client = Get-AdfsServerApplication ClientName
   

設定傾印令牌應用程式

若要設定傾印令牌應用程式，請在 [Windows PowerShell] 視窗中執行下列命令：

$authzRules = "=>issue(Type = `"http://schemas.microsoft.com/authorization/claims/permit`", Value = `"true`");"
$issuanceRules = "x:[]=>issue(claim=x);"
$redirectUrl = "https://dumptoken.azurewebsites.net/default.aspx"
$samlEndpoint = New-AdfsSamlEndpoint -Binding POST -Protocol SAMLAssertionConsumer -Uri $redirectUrl
Add-ADFSRelyingPartyTrust -Name "urn:dumptoken" -Identifier "urn:dumptoken" -IssuanceAuthorizationRules $authzRules -IssuanceTransformRules $issuanceRules -WSFedEndpoint $redirectUrl -SamlEndpoint $samlEndpoint

現在繼續進行下列疑難解答方法。 在每個方法的結尾處，查看問題是否已解決。 如果沒有，請使用另一個方法。

疑難解答方法

檢查授權原則以查看使用者是否受到影響

在此方法中，您會從取得原則詳細數據開始，然後使用傾印令牌應用程式來診斷原則，以查看使用者是否受到影響。

取得原則詳細數據

$rp。IssuanceAuthorizationRules 會顯示信賴憑證者的授權規則。

在 Windows Server 2016 和更新版本中，您可以使用 $rp。 AccessControlPolicyName 以設定驗證和授權原則。 如果$rp。 AccessControlPolicyName 具有值，訪問控制原則已就緒，可控管授權原則。 在此情況下，$rp。IssuanceAuthorizationRules 是空的。 使用 $rp。ResultantPolicy 以找出訪問控制原則的詳細數據。

如果$rp。ResultantPolicy 沒有原則的詳細數據，請查看實際的宣告規則。 若要取得宣告規則，請遵循下列步驟：

1. 執行下列命令，將訪問控制原則設定為 $null：
   Set-AdfsRelyingPartyTrust -TargetRelyingParty $rp -AccessControlPolicyName $null
2. 執行下列命令以取得信賴憑證者資訊：
   $rp = Get-AdfsRelyingPartyTrust RPName
3. 檢查 $rp.IssuanceAuthorizationRules 與 $rp. AdditionalAuthenticationRules。

使用傾印令牌應用程式來診斷授權原則

1. 將傾印令牌驗證原則設定為與失敗的信賴憑證者相同。

2. 根據您設定的驗證原則，讓用戶開啟下列其中一個連結。

   • WS-Fed： https://FederationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken
   • SAML-P： https://FederationInstance/adfs/ls/IdpInitiatedSignOn?LoginToRP=urn:dumptoken
   • 強制多重要素驗證： https://FederationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken&wauth=http://schemas.microsoft.com/claims/multipleauthn

3. 登入 Sign-In 頁面。

您得到的是使用者的宣告集合。 查看授權原則中是否有任何根據這些宣告明確拒絕或允許用戶的專案。

檢查是否有任何遺漏或非預期的宣告導致資源的存取拒絕

1. 將傾印令牌應用程式中的宣告規則設定為與失敗信賴憑證者的宣告規則相同。

2. 將傾印令牌驗證原則設定為與失敗的信賴憑證者相同。

3. 根據您設定的驗證原則，讓用戶開啟下列其中一個連結。

   • WS-Fed： https://FederationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken
   • SAML-P： https://FederationInstance/adfs/ls/IdpInitiatedSignOn?LoginToRP=urn:dumptoken
   • 強制多重要素驗證： https://FederationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken&wauth=http://schemas.microsoft.com/claims/multipleauthn

4. 登入 Sign-In 頁面。

這是信賴憑證者要為使用者取得的宣告集合。 如果有任何宣告遺失或未預期，請查看發行原則以找出原因。

如果所有宣告都存在，請與應用程式擁有者確認，以查看哪個宣告遺失或未預期。

檢查是否需要裝置狀態

如果授權規則檢查裝置宣告，請確認您從傾印令牌應用程式取得的宣告清單中是否遺漏任何這些裝置宣告。 遺漏的宣告可能會封鎖裝置驗證。 若要從傾印令牌應用程式取得宣告，請遵循檢查使用者是否受到影響方法中的使用傾印令牌應用程式診斷授權原則一節中的步驟。

以下是裝置宣告。 授權規則可能會使用其中一些規則。

• http://schemas.microsoft.com/2012/01/devicecontext/claims/registrationid
• http://schemas.microsoft.com/2012/01/devicecontext/claims/displayname
• http://schemas.microsoft.com/2012/01/devicecontext/claims/identifier
• http://schemas.microsoft.com/2012/01/devicecontext/claims/ostype
• http://schemas.microsoft.com/2012/01/devicecontext/claims/osversion
• http://schemas.microsoft.com/2012/01/devicecontext/claims/ismanaged
• http://schemas.microsoft.com/2012/01/devicecontext/claims/isregistereduser
• http://schemas.microsoft.com/2014/02/devicecontext/claims/isknown
• http://schemas.microsoft.com/2014/02/deviceusagetime
• http://schemas.microsoft.com/2014/09/devicecontext/claims/iscompliant
• http://schemas.microsoft.com/2014/09/devicecontext/claims/trusttype

如果遺漏宣告，請遵循 使用已註冊的裝置設定內部部署條件式存取 中的步驟，確定已設定環境以進行裝置驗證。

如果所有宣告都存在，請查看來自傾印令牌應用程式的宣告值是否符合授權原則中所需的值。