使用 Active Directory Federation Services (AD FS 進行 SSO 問題的疑難排解)

本文可協助您解決使用 Active Directory Federation Services (AD FS) 的單一登入 (SSO) 問題。

根據您所遇到的問題類型,選取下列其中一節。

適用于:   Active Directory Federation Services 原始 KB 號碼:   4034932

NTLM 或以表單為基礎的驗證提示

在疑難排解單一登入時 (使用 Active Directory Federation Services (AD FS) 的 SSO) 問題,如果使用者收到非預期的 NTLM 或表單驗證的驗證提示,請依照本文中的步驟進行,以解決此問題。

檢查 Windows 整合驗證設定

若要解決此問題,請查看用戶端瀏覽器、AD FS 設定和驗證要求參數中 Windows 整合驗證設定。

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

在 [網際網路選項] 中檢查下列設定:

  • 在 [高級] 索引標籤上,確定已啟用 [啟用整合式 Windows 驗證] 設定。
  • 遵循 安全性 > 本機內部 網路 > 網站[ > 高級],確定 AD FS URL 位於網站清單中。
  • 下列 安全性 > 本機內部網路 > 自訂層級,請確定已選取 [ 僅限內部網路區域的自動登入 ] 設定。

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

檢查 AD FS 設定

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

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

    Get-ADFSGlobalAuthenticationPolicy
    
  3. 檢查 WindowsIntegratedFallbackEnbaled 屬性的值。

如果值為 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 要求,請檢查要求是否包含 samlp: AuthnCoNtextClassRef 元素,其值為 urn: oasis:名稱: tc: SAML:2.0: ac:類別: Password

如需詳細資訊,請參閱 AD FS 登入頁面的驗證處理常式概述

檢查應用程式是否為 Office 365 的 Microsoft Online 服務

如果您想要存取的應用程式不是 Microsoft 線上服務,則您的經驗應與傳入驗證要求的控制。 與應用程式擁有者合作,以變更行為。

如果應用程式是 Microsoft 線上服務,您體驗的功能可能會由受信任的領域物件的 PromptLoginBehavior 設定所控制。 此設定會控制是否 Azure AD 承租人傳送 prompt = 登入至 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: Azure AD 會將 wauth 和 wfresh 傳送至 AD FS,而不是 prompt = login。 這會導致驗證要求使用以表單為基礎的驗證。
    2. NativeSupport: prompt = login 參數的傳送方式是 AD FS。
    3. Disabled:不會將任何內容傳送至 AD FS。

若要深入瞭解 Set-MSOLDomainFederationSettings 命令,請參閱 Active Directory Federation Services prompt = login parameter support

Azure Active Directory (Azure AD) 案例

如果傳送至 Azure AD 的驗證要求包含prompt = login 參數,請執行下列命令以停用 prompt = 登入功能:

Set-MsolDomainFederationSettings –DomainName DomainName -PromptLoginBehavior Disabled

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

非 Azure AD 案例

在驗證要求中要求參數(例如 WAUTHRequestedAuthNCoNtext )可以指定驗證方法。 檢查是否有強制執行意外驗證提示的其他要求參數。 若是,請修改要求參數,以使用預期的驗證方法。

檢查是否已停用 SSO

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

多重要素驗證提示

若要解決此問題,請檢查是否已正確設定信賴憑證方的宣告規則以進行多重要素驗證。

多重要素驗證可以在 AD FS 伺服器、信賴憑證者或驗證要求參數中所指定的位置啟用。 請檢查設定,查看是否正確設定。 如果需要多重要素驗證,但您重複提示,請檢查信賴憑證者發行規則,以查看是否要將多重要素驗證宣告傳遞至應用程式。

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

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

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

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

    Get-ADFSAdditionalAuthenticationRule
    

    若要檢查信賴憑證方的設定,請執行下列命令:

    Get-ADFSRelyingPartyTrust -TargetName RelyingParty | Select -ExpandProperty AdditionalAuthenticationRules
    

    注意

    如果命令傳回 nothing,則不會設定其他驗證規則。 略過本節。

  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"

以下是需要針對非 workplace join 裝置及各自的外部網路存取使用多重要素驗證的範例:

  • 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.txt 或 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 要求,請檢查要求是否包含值的 samlp: AuthnCoNtextClassRef 元素 http://schemas.microsoft.com/claims/multipleauthn

如需詳細資訊,請參閱 AD FS 登入頁面的驗證處理常式概述

檢查應用程式是否為 Office 365 的 Microsoft Online 服務

若要存取的應用程式為 Office 365 的 Microsoft Online 服務,請檢查 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 服務無法使用」或其他一些錯誤訊息。 錯誤頁面的 URL 會顯示 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 Federation Services狀態 是否 正在 執行。

然後,使用 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 Federation Services狀態 是否 正在 執行。

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

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

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

  3. 找出端點,並確認 [ 啟用 ] 欄上的狀態是否已啟用。

    Double 檢查是否已啟用所有 D F S 端點的狀態。

然後,檢查是否已安裝 Azure AD 連線。 建議您使用 Azure AD 連線讓 SSL 憑證管理變得更簡單。

如果已安裝 Azure AD 連線,請確定您使用它來管理和更新 SSL 憑證

若未安裝 Azure AD 連線,請檢查 SSL 憑證是否符合下列 AD FS 需求:

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

    AD FS 要求 SSL 憑證來自受信任的憑證授權單位單位。 如果 AD FS 是從未加入網域的電腦存取,我們建議您使用來自信任的協力廠商憑證授權單位單位的 SSL 憑證,例如 DigiCert、VeriSign 等等。如果 SSL 憑證不是來自受信任的憑證授權單位單位,則 SSL 通訊可能會中斷。

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

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

  • 未撤銷憑證。

    檢查憑證吊銷。 如果吊銷憑證,則不能信任 SSL 連線,而是由用戶端封鎖。

如果 SSL 憑證不符合這些需求,請嘗試取得適用于 SSL 通訊的合格憑證。 建議您使用 Azure AD 連線讓 SSL 憑證管理變得更簡單。 請參閱 更新 Active Directory Federation Services (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 搭配 Device Registration Service (DRS) ,請改為輸入 nt service\drs
    3. 授與「 讀取 」許可權,然後按一下 [確定]
檢查是否已在 AD FS 中設定 Device Registration Service (DRS)

如果您已使用 DRS 設定 AD FS,請確定已正確地為 RDS 設定 SSL 憑證。 例如,如果有兩個 UPN 尾碼 contoso.com fabrikam.com ,則憑證必須具有和的 enterpriseregistration.contoso.com enterpriseregistration.fabrikma.com 主體替代名稱 (SANs) 。

若要檢查 SSL 憑證是否有正確的 San,請遵循下列步驟:

  1. 執行下列命令,列出組織中使用的所有 UPN 尾碼:

    Get-AdfsDeviceRegistratrionUpnSuffix
    
  2. 確認 SSL 憑證是否已設定必要的 SANs。

  3. 如果 SSL 憑證沒有正確的 DRS 名稱為 SANs,請取得具有正確的 DRS SANs 的新 SSL 憑證,然後使用此憑證做為 AD FS 的 SSL 憑證。

然後,檢查 WAP 伺服器和回退系結上的憑證設定:

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

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

    2. 執行下列命令,以取得 WAP 使用的 SSL 憑證:

      Get-WebApplicationProxySslCertificate
      
    3. 如果 SSL 憑證錯誤,請執行下列命令來設定正確的 SSL 憑證:

      Set-WebApplicationProxySslCertificate -Thumbprint Thumbprint
      
  • 檢查憑證系結,並視需要更新。

    若要支援非 SNI 案例,管理員可以指定 fallback 系結。 不是標準 federationservicename:443系結,請在下列應用程式下尋找 fallback 系結 IDs:

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

    例如,如果已為 fallback 系結(如0.0.0.0)指定 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 Text Wizard 中的「From 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>

請在解碼的值內執行下列檢查:

  • 檢查 [目的地] 值中的主機名稱是否符合 AD FS 主機名稱。
  • 檢查發行人的值是否符合 $rp.Identifier

SAML 的其他附注:

  • $rp。SamlEndpoints:顯示所有類型的 SAML 端點。 從 AD FS 的回應會傳送至端點中設定的對應 URLs。 SAML 端點可以使用重新導向、帖子或專案系結進行郵件傳輸。 您可以在 AD FS 中設定所有這些 URLs。
  • $rp。SignedSamlRequestsRequired:如果設定值,則必須簽署從信賴憑證方傳送的 SAML 要求。 "SigAlg" 和 "Signature" 參數必須存在於要求中。
  • $rp。RequestSigningCertificate:這是用來在 SAML 要求上產生簽章的簽署憑證。 請確定憑證是有效的,並且要求應用程式擁有者符合憑證。
檢查加密憑證

如果 $rp.EncryptClaims 已啟用,則會啟用信賴憑證方加密。 AD FS 使用加密憑證來加密宣告。 請執行下列檢查:

  • $rp。EncryptionCertificate:使用此命令取得憑證,並檢查其是否有效。
  • $rp。 EncryptionCertificateRevocationCheck:使用此命令來檢查憑證是否符合吊銷檢查要求。
先前的兩種方法不起作用

若要繼續進行疑難排解,請參閱 使用 Dump Token 應用程式

並非所有使用者都受此問題影響,而且使用者無法存取任何信賴憑證方。

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

檢查使用者是否已停用

在 Windows PowerShell 或 UI 中檢查使用者狀態。 若使用者已停用,請啟用使用者。

使用 Windows PowerShell 檢查使用者狀態
  1. 登入任何網域控制站。

  2. 開啟 [Windows PowerShell]。

  3. 執行下列命令以檢查使用者狀態:

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

    使用 Get-ADUser 命令,檢查使用者啟用狀態。

在 UI 中檢查使用者狀態
  1. 登入任何網域控制站。

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

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

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

  5. 在 [ 帳戶選項] 下,確認已選取 [ 帳戶已停用 ]。

    請加倍檢查是否已勾選 [帳戶] 選項。

  6. 如果已勾選此選項,請將其取消選取。

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

如果在 Active Directory 中更新使用者的任何屬性,則會在使用者物件的中繼資料中產生變更。 檢查 user metadata 物件,以查看最近更新的屬性。 如果找到變更,請確定相關的服務將其挑選。 若要檢查使用者是否有屬性變更,請遵循下列步驟:

  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 屬性採用的是比其他屬性(表示使用者物件中繼資料的變更)的更新日期。

    Repadmin showobjmeta 命令的輸出。

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

在多樹系 AD FS 環境中,需要在部署 AD FS 的樹系之間進行雙向樹系信任,並使用 AD FS 部署進行驗證。 若要驗證樹系之間的信任是否如預期般運作,請遵循下列步驟:

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

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

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

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

  5. 在 [ 受此網域信任的網域] 底下 ()信任此網域 (內向信任) 的網域] 底下,按一下要驗證的信任,然後按一下 [ 屬性]。

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

    • 如果您選取 [ ],我們建議您對互惠網域重複相同的程式。

    • 如果您選取 [是],請提供互惠網域的系統管理使用者認證。 不需要對互惠網域執行相同的程式。

      在 [Active Directory 網域服務] 對話方塊中驗證傳入信任。

如果這些步驟無法協助您解決問題,請繼續進行疑難排解,並繼續進行疑難排解,但 [不是所有使用者的步驟都會影響問題,而且使用者可以存取部分 信賴憑證者 ] 區段。

並非所有使用者都受問題影響,而且使用者可以存取部分信賴憑證方。

在此案例中,請在 Azure AD 案例中檢查是否發生此問題。 如果是的話,請執行這些檢查以解決此問題。 如果不是,請參閱 使用 Dump Token 應用程式 來疑難排解此問題。

檢查使用者是否已同步處理至 Azure AD

如果使用者嘗試登入 Azure AD,將會重新導向 AD FS 以驗證同盟網域。 失敗登入的其中一個可能原因是使用者尚未同步處理至 Azure AD。 在 ad fs 上初次驗證嘗試之後,您可能會看到從 Azure AD 到 ad fs 的迴圈。 若要判斷使用者是否已同步處理至 Azure AD,請遵循下列步驟:

  1. 下載並安裝適用于 Windows PowerShell 的 Azure AD PowerShell 模組。
  2. 使用 [以系統管理員身分執行] 選項開啟 Windows PowerShell。
  3. 執行下列命令,以啟動對 Azure AD 的連接:
    Connect-MsolService
  4. 為連線提供全域系統管理員認證。
  5. 執行下列命令,以取得 Azure AD 中的使用者清單:
    Get-MsolUser
  6. 確認使用者是否在清單中。

如果使用者不在清單中,請將使用者同步處理至 Azure AD。

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

Azure AD 需要 immutableID 和使用者的 UPN 以驗證使用者。

注意

在下列工具中,immutableID 也稱為 sourceAnchor:

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

管理員可使用 Azure AD 連線自動管理 Azure AD 的 AD FS 信任。 如果您不是透過 Azure AD 連線管理信任,我們建議您透過下載 Azure AD 連線Azure AD,以根據同步處理設定來啟用自動宣告規則管理。

若要檢查 AD FS 中的 immutableID 和 UPN 的宣告規則是否符合 Azure AD 所使用的,請遵循下列步驟:

  1. 在 Azure AD 連線中取得 sourceAnchor 和 UPN。

    1. 開啟 Azure AD 連線。

    2. 按一下 [ View current configuration]。

      在 [Azure 連線其他工作] 頁面中,選取 [View the View current configuration]。

    3. 在 [ 複查您的解決方案 ] 頁面上,記下 來源錨點使用者主要名稱 的值。

      在 [Azure 連線] 頁面中取得來源錨點和使用者主要名稱的值。

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

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

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

    3. 以滑鼠右鍵按一下具有 Azure AD 的信賴憑證者信任,然後按一下 [編輯宣告發行原則]。

    4. 開啟不彈性識別碼和 UPN 的宣告規則。

    5. 確認查詢 immutableID 和 UPN 值的變數是否與 Azure AD 連線所顯示的變數相同。

      在 A D S 伺服器中設定對應的宣告規則,確認 immutableID 和 UPN 的值。

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

    • 如果 AD FS 是由 Azure AD 連線所管理,請使用 Azure AD 連線重設信賴憑證者信任。
    • 如果 AD FS 不是由 Azure AD 連線所管理,請使用正確的屬性修正宣告。

如果這些檢查無法協助您解決問題,請參閱 使用 Dump Token 應用程式 來疑難排解此問題。

此問題會在應用程式端發生

如果權杖簽署憑證最近由 AD FS 重新更新,請檢查是否有同盟協力廠商挑選新的憑證。 如果 AD FS 使用最近更新的權杖解密憑證,也請執行相同的檢查。 若要檢查 AD FS 上目前的 AD FS 權杖簽署憑證是否符合同盟協力廠商的憑證,請遵循下列步驟:

  1. 執行下列命令,以在 AD FS 上取得目前的 token 簽署憑證:

    Get-ADFSCertificate -CertificateType token-signing
    
  2. 在傳回憑證的清單中,尋找包含 IsPrimary = TRUE 的憑證,並記下該指紋。

  3. 在同盟協力廠商取得目前 token 簽署憑證的指紋。 應用程式擁有者必須為您提供這種情況。

  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-格式: unspecifie。
    • urn: oasis:名稱: tc: SAML:1.1: nameid-格式: emailAddress
    • urn: oasis:名稱: tc: SAML:2.0: nameid-格式: persistent
    • urn: oasis:名稱: tc: SAML:2.0: nameid-格式:暫時性
  3. 要求應用程式擁有者所需的 NameIdentifier 格式。

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

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

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

    若沒有可發出 NameIdentifier 宣告的規則,或更新現有的規則,請新增轉換宣告規則。

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

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

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

  3. 在 [ 高級 ] 索引標籤上,選取要與應用程式所需的演算法。

    在 [屬性設定] 對話方塊中,選取 [高級] 索引標籤下的 [應用程式所需的演算法]。

關於憑證自動更新

如果權杖簽署憑證或權杖解密憑證是自我簽署的憑證,則預設會在這些憑證上啟用 AutoCertificateRollover,而 AD FS 會管理憑證的自動更新(當憑證接近到期時)。

若要判斷您使用的是自我簽署憑證,請遵循下列步驟:

  1. 執行下列命令:

    Get-ADFSCerticate -CertificateType "token-signing"
    

    執行 Get-ADFSCerticate Cmdlet、憑證類型 token 簽署。

  2. 檢查憑證屬性。

    如果 Subject 和 Issuer 屬性都以 "CN = ADFS 簽署 ..." 開頭,則憑證是由 AutoCertRollover 進行自我簽署和管理。

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

  1. 執行下列命令:

    Get-ADFSProperties | FL AutoCertificateRollover
    

    執行 Get-ADFSProperties Cmdlet,以確認是否自動更新憑證。

  2. 檢查 AutoCertificateRollover 屬性。

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

本文說明如何檢查與 ADFS 相關的元件和服務。 當您對使用 Active Directory Federation Services (ADFS) 的 (SSO) 問題進行疑難排解時,這些步驟可能會有所説明。

檢查 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更新彙總套件
  • 檢查 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 功能] 欄上顯示的 D F S 端點狀態。

檢查 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:埠 完全 IP 與埠相符
SNI 主機名稱:埠 完全主機名稱相符 (connection 必須指定 SNI)
3 CCS 連接埠 喚醒呼叫中央證書存放區
4 IPv6 萬用字元 連接埠 (connection 必須 IPv6 IPv6 萬用字元相符)
5 IP 萬用字元 連接埠 可以 IPv4 或 IPv6 IP 萬用字元比對 (連接)

AD FS 2012 R2 和更新版本獨立于 Internet Information Services (IIS) ,並在 http.sys 上以服務的身分執行。 主機名稱:埠 SSL 憑證系結是由 AD FS 使用。 在用戶端憑證驗證期間,AD FS 會根據 AdfsTrustedDevices 儲存區中的憑證,將憑證信任清單 (CTL) 傳送。 如果 AD FS 伺服器的 SSL 憑證系結使用 IP:埠或 CTL 存放區不是 AdfsTrustedDevices,則可能無法建立 proxy 信任關係。

取得 AD FS 的 SSL 憑證系結

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

在傳回的系結清單中,尋找具有5d89a20c-beab-4389-9447-324788eb944a 的應用程式識別碼。 以下是正常系結的範例。 請注意 "Ctl 儲存區名稱" 行。

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:埠系結具有最高優先順序。 如果 IP:埠系結位於 AD FS SSL 憑證系結中,http.sys 永遠使用此憑證進行 SSL 通訊的系結。 若要解決此問題,請使用下列方法。

  1. 移除 IP:埠系結

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

  2. 使用其他 IP 位址進行 AD FS SSL 通訊

    如果需要 IP:埠系結,請將 ADFS 服務 FQDN 解析為其他系結中未使用的 IP 位址。 如此一來,http.sys 會使用主機名稱:埠系結進行 SSL 通訊。

  3. 將 AdfsTrustedDevices 設定為 IP:埠系結的 CTL 存放區

    如果您無法使用以上的方法,這是最後的手段。 不過,在將預設的 CTL 儲存變更為 AdfsTrustedDevices 之前,最好先瞭解下列條件:

    • IP:埠系結的原因。
    • 如果系結依賴預設 CTL 存放區進行用戶端憑證驗證。

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

如果已安裝 Azure AD 連線,請使用 AAD 連線將 CTL 存放區名稱設定為 AdfsTrustedDevices,以供所有 AD FS 伺服器上的 SSL 憑證系結使用。 若未安裝 Azure AD 連線,請在所有 ad fs 伺服器上執行下列命令,以重新產生 AD fs 證書系結。

Set-AdfsSslCertificate -Thumbprint Thumbprint

問題3:非自我簽署的憑證存在於 AdfsTrustedDevices 憑證儲存區中

如果 CA 簽發的憑證位於僅有自我簽署憑證的憑證存放區中,則從該存放區產生的 CTL 只會包含 CA 簽發的憑證。 AdfsTrustedDevices 憑證儲存區是指應該只有自我簽署憑證的存放區。 這些憑證包括:

  • MS-組織存取:用來簽發 workplace join 憑證的自我簽署憑證。
  • ADFS Proxy 信任:每個 Web 應用程式 Proxy 伺服器的憑證。

每個 Web 應用程式 Proxy 伺服器的憑證。

因此,請從 AdfsTrustedDevices 憑證存放區中刪除任何 CA 簽發的憑證。

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

使用 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:已傳遞所有檢查。 但問題仍然存在

檢查是否有時間或時區不符的情況。 如果 time 符合但不符合時區,也無法建立 proxy 信任關聯。

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

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

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

使用 Dump Token 應用程式

在您的同盟服務中調試問題以及驗證自訂宣告規則時,可使用 Dump Token 應用程式。 這不是正式的解決方案,但出於疑難排解的考慮,建議使用適當的獨立調試解決方案。

使用 Dump Token 應用程式之前

在使用「轉儲 Token」應用程式之前,您必須:

  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

現在,繼續進行下列疑難排解方法。 在每個方法的結尾,查看問題是否已解決。 如果不是,請使用另一種方法。

疑難排解方法

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

在此方法中,您可以從取得原則詳細資料開始,然後使用 Dump Token 應用程式來診斷原則,以查看使用者是否受到影響。

取得原則詳細資料

$rp。Issuanceauthorizationrules.txt 顯示信賴憑證方的授權規則。

在 Windows Server 2016 和更新版本中,您可以使用 $rp。 AccessControlPolicyName 以設定驗證和授權原則。 如果 $rp。 AccessControlPolicyName 具有值,即會在適當的位置存取控制原則,以控制授權原則。 在此情況下,$rp。Issuanceauthorizationrules.txt 是空的。 使用 $rp。ResultantPolicy 以尋找存取控制原則的詳細資料。

如果 $rp。ResultantPolicy 沒有原則的詳細資料,請查看實際的宣告規則。 若要取得宣告規則,請遵循下列步驟:

  1. 執行下列命令,將存取控制原則設為 $null:
    Set-AdfsRelyingPartyTrust -TargetRelyingParty $rp -AccessControlPolicyName $null
  2. 執行下列命令以取得信賴憑證方資訊:
    $rp = Get-AdfsRelyingPartyTrust RPName
  3. 檢查 $rp.IssuanceAuthorizationRules$rp. AdditionalAuthenticationRules
使用 Dump Token 應用程式來診斷授權原則
  1. 設定轉儲權杖驗證原則,使其與失敗的信賴憑證方相同。

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

    • WS 送紙: https://FerderationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken
    • SAML-P: https://FerderationInstance/adfs/ls/IdpInitiatedSignOn?LoginToRP=urn:dumptoken
    • 強制執行多重要素驗證: https://FerderationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken&wauth=http://schemas.microsoft.com/claims/multipleauthn
  3. 在 [Sign-In] 頁面上登入。

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

檢查是否有遺失或意外的宣告導致存取權拒絕資源

  1. 設定轉儲權杖應用程式中的宣告規則,使其與失敗信賴憑證的宣告規則相同。

  2. 設定轉儲權杖驗證原則,使其與失敗的信賴憑證雙方相同。

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

    • WS 送紙: https://FerderationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken
    • SAML-P: https://FerderationInstance/adfs/ls/IdpInitiatedSignOn?LoginToRP=urn:dumptoken
    • 強制執行多重要素驗證: https://FerderationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken&wauth=http://schemas.microsoft.com/claims/multipleauthn
  4. 在 [Sign-In] 頁面上登入。

這是信賴憑證者即將取得之使用者的宣告集合。 如果有任何宣告遺失或意外,請查看發行原則,以找出原因。

若所有宣告皆存在,請與應用程式擁有者核對,以查看哪個宣告缺失或未預期。

檢查是否需要裝置狀態

如果授權規則檢查裝置宣告,請確認您從 Dump Token 應用程式取得的宣告清單中是否遺漏了任何裝置宣告。 遺漏的宣告可能會封鎖裝置驗證。 若要從轉儲權杖應用程式取得宣告,請依照 [如果使用者受到影響] 的方法,依照 [使用 Dump Token 應用程式來診斷授權原則] 區段中的步驟進行。

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

  • 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

如果有遺漏的宣告,請依照 使用已註冊裝置設定 On-Premises 條件式存取 中的步驟,確定環境已設定進行裝置驗證。

如果有所有宣告,請查看 Dump Token 應用程式宣告的值是否符合授權原則中所需的值。