繼續進行疑難排解,來檢查與信賴憑證者的合作對象的潛在問題。

繼續信賴中其他的檢查。

繼續進行疑難排解檢查 SSL 憑證。

繼續進行疑難排解檢查 proxy 之間的信任關係 Web 應用程式 Proxy,AD FS。

繫結可能與 AD FS 憑證繫結連接埠 443 上衝突。

使用 SSO 將使用者遭遇在有什麼問題?

在 AD FS 登入網頁或應用程式端,就會發生這個問題。

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

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

您不要在碰到這個問題?

這個問題會影響所有使用者嗎?

也能使用者存取任何的信賴憑證者的合作對象?

這個問題會發生在 Azure 的 AD 案例中?

也能使用者存取任何的信賴憑證者的合作對象?

如果用 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

如果權杖簽署憑證或語彙基元解密憑證是自我簽署的這些憑證上的預設會啟用 AutoCertificateRollover,並快到期時,AD FS 會管理憑證的自動更新。

如果要判斷如果您使用自我簽署的憑證,請依照下列步驟執行:

  1. 執行下列命令:
    Get-ADFSCerticate -CertificateType "token-signing"
    Get-ADFSCertificate

  2. 檢查憑證屬性。
    如果主旨和發行者屬性這兩個以開始 「 CN = ADFS 簽章...」,憑證是自我簽署的形式,由 AutoCertRollover 所管理。

若要確認是否憑證自動更新,請依照下列步驟執行:

  1. 執行下列命令:
    Get-ADFSProperties | FL AutoCertificateRollover
    Get-ADFSProperties

  2. 檢查 AutoCertificateRollover 屬性。

    • 如果AutoCertificateRollover = TRUE,AD FS 自動產生新的憑證 (在預設的到期之前的 30 天),並將它們設定為主要的憑證 (在到期之前的 25 天)。

    • 如果AutoCertificateRollover =,您必須手動取代的憑證。

憑證碼符合嗎?

若要檢查是否有不相符,請依照下列步驟執行:

  1. 判斷信賴憑證者藉由執行下列命令使用的演算法:取得- ADFSRelyingPartyTrust -Name RPName | FL SignatureAlgorithm

    可能的值SHA1SHA256.

  2. 請洽詢應用程式端上使用之演算法的應用程式擁有者。

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

不存在的不相符

未預期的 NTLM 提示字元] 或 [表單架構驗證提示字元中,使用者是否已可取得?

使用者是否收到非預期的提示字元進行多因素驗證?或者,沒有使用者重複看到這個提示?

這個問題會發生在 Azure 的 AD 案例中?

驗證要求傳送至 Azure 的 AD 包含提示 = 登入參數嗎?

例如 WAUTH 和 RequestedAuthNContext 的要求參數,在驗證要求中可以有指定的驗證方法。要求參數強制執行非預期的驗證提示字元?

您可以使用下列方法進行疑難排解。

檢查 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. 在 [帳戶選項,請確認是否檢查帳戶已停用
    The "Account is disabled" option under Account options

  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 屬性會採用一個較新日期比其他的屬性表示變更的使用者物件的中繼資料。
    repadmin show user metadata

問題是否解決了?

在多樹系的 AD FS 環境中,雙向樹系信任是樹系部署 AD FS 的位置與其他的樹系的使用來進行驗證的 AD FS 部署之間需要。若要確認是否樹系之間的信任正在如預期般, 請遵循下列步驟:

  1. 登入網域控制站在樹系部署 AD FS 的位置。

  2. 開啟作用中的目錄網域和信任管理主控台.

  3. 在管理主控台,以滑鼠右鍵按一下包含您想要確認信任的網域,,然後按一下 [內容

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

  5. 在 [信任這個網域 (連出信任)信任這個網域 (連入信任) 的請按一下來加以驗證的信任,,然後按一下 [屬性

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

    • 如果您選取 [] 時,我們建議您在交互網域之重複相同的程序。

    • 如果您選取 [],請交互網域之提供可管理使用者的認證。交互網域之執行相同的程序不需要。

Active Directory Domain Services

  • 問題是否解決了?

偵錯的問題,與您聯盟的服務,以及驗證自訂宣告規則時,很有幫助傾印語彙基元的應用程式。不是官方的解決方案,但很好的偵錯獨立解決方案所建議供疑難排解之用。

使用 [語彙基元傾印的應用程式之前, 您必須:

  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 伺服器 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 伺服器 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. Check $rp.IssuanceAuthorizationRules$rp. AdditionalAuthenticationRules.

用於傾印語彙基元的應用程式診斷授權原則

  1. 設定傾印語彙基元的驗證原則,為失敗的信賴一樣。

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

    • WS-Fed: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. 在 [登入頁面登入。

所得是主張之通告使用者組。請查看是否有任何項目,明確拒絕或允許使用者根據這些宣告的授權原則中。

問題是否解決了?

  1. 在 [語彙基元傾印的應用程式中要宣告規則失敗信賴憑證者相同設定的宣告規則。

  2. 設定傾印語彙基元的驗證原則,為失敗的信賴一樣。

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

    • WS-Fed: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. 在 [登入頁面登入。

這是一組的信賴即將取得使用者的宣告。如果任何宣告遺失或未預期,查看 [發行原則,以找出原因。

如果所有的宣告會呈現,請洽詢應用程式擁有者,以查看哪些宣告是遺失或未預期。

問題是否解決了?

如果授權規則時,檢查裝置的宣告,請確認任何這些裝置宣告是否遺失的宣告就傾印語彙基元的應用程式從清單中。遺失的宣告可能會封鎖裝置驗證。若要宣告傾印語彙基元的應用程式中,請依照下列檢查授權原則,如果使用者早已受到波及的方法中的 [使用權杖傾印的應用程式,來診斷授權原則] 區段中的步驟。

以下是裝置宣告。授權規則時,可以使用其中的一部份。

  • 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

如果有遺失的宣告,請依照下列設定先有條件的存取使用註冊裝置,請確定您的環境是驗證裝置的安裝程式中的步驟。

如果所有宣告都都存在,請參閱傾印語彙基元的應用程式的宣告的值如果符合所需的授權原則中的值。

問題是否解決了?

您可以使用下列方法進行疑難排解。在每一種方法最後,請參閱是否要解決這個問題。否則,請使用其他方法。

如果使用者嘗試登入 Azure 的廣告,其會重新導向至 AD FS 進行聯盟的網域的驗證。其中一項失敗的登入的可能原因是使用者不尚未同步到 Azure 的廣告。您可能會看到在 AD FS 嘗試從 「 主要驗證後的 Azure 廣告到 AD FS 迴圈。如果要判斷是否要將使用者同步到 Azure 的廣告,請依照下列步驟執行:

  1. 下載和 Azure AD PowerShell 模組安裝 Windows PowerShell。

  2. 您可以開啟 [Windows PowerShell 與 「 以系統管理員身分執行 」 選項。

  3. 起始 Azure 的 AD 連線,執行下列命令:
    Connect-MsolService

  4. 提供全域系統管理員認證的連線。

  5. 取得 Azure AD 中的使用者清單,藉由執行下列命令:
    Get-MsolUser

  6. 請確認使用者是否在清單中。

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

問題是否解決了?

Azure 的 AD 需要 immutableID,並驗證使用者的使用者的 UPN。

注意immutableID 中的下列工具也稱為 sourceAnchor:

  • Azure 的 AD 同步

  • Azure 的 Active Directory 同步處理目錄 (同步)

系統管理員可以使用 Azure 的 AD 連線與 Azure 的 AD 的 AD FS 信任的自動管理。如果您不管理透過 Azure 的 AD 連線信任,我們建議您不要因此下載 Azure 的 AD 連線. Azure 的 AD 連線啟用自動宣告規則同步設定值為基礎的管理。

若要檢查如果 immutableID 和 UPN 宣告規則 AD FS 相符的項目中有什麼 Azure AD 就會使用,請遵循下列步驟:

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

    1. 開啟 Azure 的 AD 連線。

    2. 按一下 [檢視目前的設定]。
      Azure AD Connect -View current configuration

    3. 在 [檢閱您的方案] 頁面中,請記下來源錨點使用者主體名稱的值。
      Azure AD Connect -Review your solution

  2. Verify immutableID (sourceAnchor) 和 UPN 的對應值佔領 AD FS 伺服器中設定的規則。

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

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

    3. 使用 Azure AD,信賴憑證者的合作對象信任上按一下滑鼠右鍵,然後按一下編輯宣告發佈原則.

    4. 開啟不變的 ID 和 UPN 宣告規則。

    5. 請確認查詢中的 immutableID 和 UPN 值的變數是否相同那些 Azure 的 AD 連線中所顯示的樣子。
      Issue UPN and ImmutableID

    6. 如果有差異,請使用下列方法之一:

      • 如果 AD FS 所 Azure 的 AD 連線管理,重設信賴憑證者的合作對象信任,使用 Azure 的 AD 連線。

      • 如果 AD FS 不受 Azure 的 AD 連線,請更正具有正確的屬性宣告。
         

問題是否解決了?

資訊將會用於後續的疑難排解步驟。

 

如果您使用傳統的信賴憑證者合作對象,請依照下列步驟執行:

  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 伺服器 2016年中的應用程式群組功能,請遵循下列步驟:

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

  2. 取得信賴憑證者的合作對象資訊,藉由執行下列命令:
    $rp = Get-AdfsWebApiApplication ResourceID

  3. 如果 OAuth 用戶端是公用的請執行下列命令,取得用戶端資訊:
    $client = Get-AdfsNativeClientApplication ClientName

    如果用戶端是機密的請執行下列命令以取得用戶端資訊:
    $client = Get-AdfsServerApplication ClientName

現在繼續執行下列疑難排解方法。

信賴憑證者的合作對象識別碼、 用戶端 ID 和重新導向 URI 應提供應用程式和用戶端的擁有者。不過,可能仍有擁有者所提供,且什麼設定 AD FS 中不相符。例如,不相符的狀況可能被因打字錯誤。請檢查設定所提供的擁有者比對 AD FS 中設定。前一頁中的步驟可讓您透過 PowerShell AD FS 中的設定。

擁有者所提供的設定

AD FS 中的設定

仰賴合作對象識別碼

$rp.Identifier

信賴憑證者的合作對象重新導向 URI

前置字元或萬用字元比對的

  • $rp。WS Fed 信賴的 WSFedEndpoint

  • $rp。SAML 信賴的 SamlEndpoints

用戶端識別碼

$client.ClientId

用戶端重新導向 URI

$Client 的字首相符。RedirectUri

如果在資料表中的項目符合,此外請檢查這些設定與相符它們出現在驗證要求傳送到 AD FS 之間什麼 AD FS 中設定。請嘗試重現的問題,此時您會擷取 Fiddler 追蹤上傳送應用程式,以 AD FS 驗證要求。請檢查要求參數,執行下列檢查,視要求類型而定。

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

「 資源 」 參數應該代表 AD FS 中的有效信賴憑證者合作對象。執行下列命令的其中之一,以取得信賴憑證者的合作對象資訊。

  • 如果您使用傳統的信賴,執行下列命令:
    Get-AdfsRelyingPartyTrust -Identifier "ValueOfTheResourceParameter"

  • 如果應用程式群組功能以 Windows 伺服器 2016年上時,請執行下列命令:
    Get-AdfsWebApiApplication "ValueOfTheResourceParameter"

WS-紙匣供給的要求

WS-紙匣供給的要求看起來會如下所示:

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.Identifier

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

解碼 SAMLRequest 參數的值,使用 Fiddler 的文字精靈] 中的 「 從 DeflatedSAML"選項。已解碼的值如下所示:

<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 的回應會傳送至對應的 Url 中結束點設定。SAML 端點可以使用訊息傳輸的重新導向、 張貼或成品的繫結。AD FS 中,您可以設定所有這些 Url。

  • $rp。SignedSamlRequestsRequired: 如果設定值,則 SAML 要求寄件者信賴憑證者的合作對象必須經過簽署。必須出現在要求中的 「 SigAlg 」 和 「 簽章 」 參數。

  • $rp。RequestSigningCertificate: 這是用來產生 SAML 要求簽章的簽署憑證。請確定憑證有效,並詢問 [應用程式擁有者,以符合憑證。

問題是否解決了?

如果$rp.EncryptClaims傳回 [啟用],藉由廠商加密已啟用。AD FS 會使用加密憑證來加密的宣告。執行下列檢查:

  • $rp。EncryptionCertificate: 使用此命令來取得憑證,並確認其是否有效。

  • $rp。EncryptionCertificateRevocationCheck: 使用這個命令,以檢查憑證是否符合撤銷檢查的需求。

問題是否解決了?

如果憑證不相符時,請確定台協力電腦會使用新的憑證。AD FS 伺服器發行的聯盟中繼資料中包含憑證。

注意台協力電腦,請參閱所有您資源的組織或帳戶組織夥伴,AD FS 中由信賴憑證者的 「 合作對象 」 信任和宣告的提供者信任。

夥伴可以存取的同盟中繼資料

如果協力廠商能夠存取的同盟中繼資料,請詢問使用新的憑證的協力廠商。

台協力電腦無法存取的同盟中繼資料

在此情況下,您必須手動傳送台協力電腦的新憑證的公開金鑰。若要執行這項操作,請參考下列步驟:

  1. 為.cert 的檔案,或為要加入的整個憑證鏈結的.p7b 檔案,請匯出公開金鑰。

  2. 傳送給協力廠商的公開金鑰。

  3. 要求的夥伴使用新的憑證。

問題是否解決了?

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

  2. 信賴憑證者的合作對象信任,以滑鼠右鍵按一下,然後按一下 [內容

  3. 在 [進階] 索引標籤上選取要與應用程式的要求相符的演算法。
    Relying party trust-Hash algorithm

解決問題 ?

  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 宣告,或更新現有的規則的規則,請加入新的規則。選取名稱識別碼連入宣告類型,然後再指定應用程式所要求的格式。
      Configure claim rule

問題是否解決了?

附註: 您也可以使用 Fiddler 來解決此問題。其概念是一樣的。

偵錯的問題,與您聯盟的服務,以及驗證自訂宣告規則時,很有幫助傾印語彙基元的應用程式。不是官方的解決方案,但很好的偵錯獨立解決方案所建議供疑難排解之用。若要使用 [語彙基元傾印的應用程式,請依照下列步驟執行:

  1. 設定傾印語彙基元的應用程式使用,藉由執行下列命令:
    $authzRules = "=>issue(Type = `"http://schemas.microsoft.com/authorization/claims/permit`", Value = `"true`");"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

  2. 失敗的信賴憑證者合作對象組態所複製的發佈規則從複寫信賴憑證者 DumpToken。若要這樣做,請執行下列命令:
    Set-ADFSRelyingPartyTrust -TargetName "urn:dumptoken" -IssuanceTransformRules (Get-ADFSRelyingPartyTrust -Name <”your_SrcRP_Name”>).IssuanceTransformRules

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

    • WS-Fed:https://<Ferderation Instance>/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken

    • SAML:https://<Ferderation Instance>/adfs/ls/IdpInitiatedSignOn?LoginToRP=urn:dumptoken

    • 強迫多因素驗證:https://<Ferderation Instance>/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken&wauth=http://schemas.microsoft.com/claims/multipleauthn

  4. 取得宣告具有讓使用者登入,在 [驗證] 頁面上。

  5. 在傾印語彙基元的輸出,展開 [原始語彙基元的 XML] 區段中,然後檢閱屬性陳述式,藉由檢查下列的字串以查看它們是否相符在宣告的發行原則中的設定:

    • saml:NameIdentifier: 這會顯示 NameIdentifier 格式。

    • saml:AttributeStatement: 這會顯示每個語彙基元的宣告型別/值組。

    • saml:AuthenticationStatement: 以下範例顯示驗證方法和立即驗證。

問題是否解決了?

使用 [IdpInititatedSignOn] 頁面來確認是否 AD FS 服務已啟動且正在執行,並且驗證功能可以正常運作。若要開啟 [IdpInitiatedSignOn] 頁面,請依照下列步驟執行:

  1. AD FS 伺服器上執行下列命令,以啟用 [IdpInitiatedSignOn] 頁面:
    Set-AdfsProperties -EnableIdPInitiatedSignonPage $true

  2. 從位於網路中的電腦,請造訪下列頁面:
    https://FederationInstance/adfs/ls/idpinitiatedsignon.aspx

  3. 請輸入正確的認證是有效的使用者的登入頁面上。

是登入成功?

如果要疑難排解這個問題,請檢查下列元件與服務。

存取 AD FS 應該直接指向其中一個 AD FS 伺服器或負載平衡器前端 AD FS 伺服器。執行下列檢查:

  • Ping 聯盟服務名稱 (例如 fs.contoso.com)。如果您收到的 IP 位址會解析為其中一個 AD FS 伺服器或 AD FS 伺服器的負載平衡器的確認。

  • 檢查是否 federation service,在 [DNS 伺服器的 A 記錄。A 記錄應該指向其中一個 AD FS 伺服器或 AD FS 伺服器的負載平衡器。

問題是否解決了?

  • 檢查是否防火牆是否封鎖之間的流量:

    • AD FS 伺服器及負載平衡器。

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

  • 如果探查啟用負載平衡器上,檢查下列項目:

    • 如果您執行 Windows Server 2012 R2,確定2014 年 8 月更新彙總套件安裝。

    • 請檢查連接埠 80,是否要啟用在 WAP 伺服器和 AD FS 伺服器上的防火牆。

    • 請確定該探查設定為連接埠 80,且為端點/adfs/探查。

問題是否解決了?

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

  2. 在 [伺服器管理員 」 中,按一下 [工具] >服務

  3. 請檢查狀態Active Directory 聯盟服務是否執行

問題是否解決了?

AD FS 提供不同的功能和案例的不同端點的方式。依預設會啟用並不是所有的端點。若要檢查的狀態的端點,並依照下列步驟執行:

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

  2. 展開 [服務>端點

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

問題是否解決了?

我們建議您使用 Azure 的 AD 連線讓 SSL 憑證管理更容易。

在環境中安裝的 Azure 的 AD 連線?

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

問題是否解決了?

SSL 憑證必須符合下列需求:

  • 憑證是由受信任的根憑證授權單位。
    AD FS 需要 SSL 憑證是由受信任的根憑證授權單位。如果從非網域聯結電腦存取 AD FS,我們建議您使用 SSL 憑證從信任的協力廠商根憑證授權單位,如 DigiCert、 VeriSign 等等。如果 SSL 憑證不是來自受信任的根憑證授權單位中,可以中斷 SSL 通訊。

  • 憑證的主體名稱是否有效。
    聯盟的服務名稱,而不 AD FS 伺服器名稱或其他部份名稱,應符合的主體名稱。若要取得聯盟的服務名稱,請在主要的 AD FS 伺服器上執行下列命令:
    Get-AdfsProperties | select hostname

  • 憑證未被撤銷。
    檢查憑證被撤銷。如果憑證已撤銷,SSL 連線就會無法信任,而且會封鎖用戶端。

SSL 憑證是否符合這些需求?

若要解決您的問題,請將合格的憑證取得 SSL 通訊。

是您使用合格的 SSL 憑證之後解決問題?

請檢查下列組態的 SSL 憑證。

應該安裝 SSL 憑證至本機電腦上每個的同盟伺服器陣列中的 [個人] 存放區。要安裝憑證,按二下。憑證和遵循精靈的 PFX 檔案。

若要確認是否要將憑證安裝到正確的位置,請依照下列步驟執行:

  1. 列出憑證位於本機電腦個人存放區,執行下列命令:
    dir Cert:\LocalMachine\My

  2. 檢查憑證是否在清單中。

問題是否解決了?

取得正在進行 SSL 通訊使用的憑證指紋,並確認 [指紋是否符合預期的憑證指紋。

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

Get-AdfsSslCertificate

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

Set-AdfsSslCertificate –Thumbprint CorrectThumprint

問題是否解決了?

要設定為服務通訊的憑證,AD FS 陣列中需要 SSL 憑證。這不會自動執行。若要檢查是否要設定正確的憑證,請依照下列步驟執行:

  1. 在 AD FS 管理主控台中,展開 [服務>憑證

  2. 請確認服務通訊] 下所列出的憑證是否為預期的憑證。

如果列出錯誤的憑證,請設定正確的憑證,並再授與 AD FS 會服務對憑證的 [讀取] 權限。若要執行這項操作,請參考下列步驟:

  1. 設定正確的憑證:

    1. 憑證中,按一下滑鼠右鍵,然後按一下 [設定服務通訊的憑證

    2. 選取正確的憑證。

  2. 驗證 AD FS 服務有憑證的 [讀取] 權限:

    1. 新增本機電腦帳戶的 [憑證] 嵌入式管理單元的 Microsoft 管理主控台 (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 設定。

SSL 憑證沒有正確的 DRS 名稱為細?

若要解決這個問題,取得新的 SSL 憑證具有正確的 San 的 DRS,然後再使用它為 SSL 憑證 AD fs。

問題是否解決了?

檢查正確的 SSL 憑證,是否要將所有的 WAP 伺服器上

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

  2. 取得 SSL 憑證 WAP 由執行下列命令:
    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 憑證時繫結會一併更新。

問題是否解決了?

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

  2. 在 [伺服器管理員 」 中,按一下 [工具] >服務

  3. 請檢查狀態Active Directory 聯盟服務是否執行

問題是否解決了?

您可以使用 [IdpInititatedSignOn] 頁面來快速地確認是否 AD FS 服務已啟動,並且執行,並驗證功能可以正常運作。若要開啟 [IdpInitiatedSignOn] 頁面,請依照下列步驟執行:

  1. AD FS 伺服器上執行下列命令,以啟用 [IdpInitiatedSignOn] 頁面:
    Set-AdfsProperties -EnableIdPInitiatedSignonPage $true

  2. 從您的網路之外的電腦,請造訪下列頁面:
    https://FederationInstance/adfs/ls/idpinitiatedsignon.aspx

  3. 請輸入正確的認證是有效的使用者的登入頁面上。

是登入成功?

如果要疑難排解這個問題,請檢查下列元件與服務。

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

  • Ping 聯盟服務名稱 (例如 fs.contoso.com)。請確認如果 Ping 會解析為 IP 位址的其中一個的 WAP 伺服器或是 WAP 伺服器的負載平衡器。

  • 檢查是否 federation service,在 [DNS 伺服器的 A 記錄。A 記錄應該指向其中一個 WAP 伺服器或負載平衡器的 WAP 伺服器。

如果您供外部存取的案例中,不會實作 WAP,檢查是否ccessing AD FS 會直接指向其中一個 AD FS 伺服器或負載平衡器前端 AD FS 伺服器:

  • Ping 聯盟服務名稱 (例如 fs.contoso.com)。如果您收到的 IP 位址會解析為其中一個 AD FS 伺服器或 AD FS 伺服器的負載平衡器的確認。

  • 請檢查是否 federation service,在 [DNS 伺服器的 A 記錄。A 記錄應該指向其中一個 AD FS 伺服器或 AD FS 伺服器的負載平衡器。

問題是否解決了?

  • 檢查是否防火牆是否封鎖之間的流量:

    • AD FS 伺服器及負載平衡器。

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

  • 如果探查啟用負載平衡器上,檢查下列項目:

    • 如果您執行 Windows Server 2012 R2,確定2014 年 8 月更新彙總套件安裝。

    • 請檢查連接埠 80,是否要啟用在 WAP 伺服器和 AD FS 伺服器上的防火牆。

    • 請確定該探查設定連接埠 80 和結束點 /adfs/probe。

問題是否解決了?

  1. 檢查是否已啟用通過 TCP 連接埠 443 的輸入的流量:

    • t他防火牆 Web 應用程式 Proxy 伺服器和同盟伺服器陣列之間。

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

  2. 請檢查下列情況成立時,是否要透過 TCP 連接埠 49443 的輸入的流量啟用用戶端和 Web 應用程式 Proxy 伺服器之間的防火牆上:

    • 已啟用 TLS 使用 X.509 憑證的用戶端驗證。

    • 您使用 AD FS 會在 Windows Server 2012 R2。

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

問題是否解決了?

 

問題是否解決了?

AD FS 提供不同的功能和案例的不同端點的方式。依預設會啟用並不是所有的端點。若要檢查是否端點已啟用 proxy,依照下列步驟執行:

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

  2. 展開 [服務>端點

  3. 找出端點,確認Proxy 所啟用的資料行是否已啟用狀態。
    ADFS endpoints proxy status

 

問題是否解決了?

注意在此頁面上的資訊適用於 AD FS 2012 R2 及更新版本。

如果部署 Web 應用程式 Proxy (WAP),就必須建立 proxy 的信任關係的 WAP 伺服器和 AD FS 伺服器之間。檢查是否 proxy 的信任關係建立或啟動失敗時間,在某個時間點。

背景資訊

Proxy 的信任關係是基礎的用戶端憑證。當您執行 Web 應用程式 Proxy 後安裝精靈時,精靈就會產生自我簽署的用戶端憑證,使用您在精靈中指定的認證。然後精靈會插入 AD FS 設定資料庫中的憑證,並將它加入至 AdfsTrustedDevices 憑證存放區,AD FS 伺服器上。

任何的 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 而且稍後無關的網際網路資訊服務 (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

在傳回的繫結清單中,尋找那些具應用程式 ID 5d89a20c-beab-4389-9447-324788eb944a。以下是 [狀況良好的繫結的範例。請注意粗體組件。

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.")

偵測到的問題是什麼?

IP:port 繫結的優先順序最高。如果 IP:port 繫結位於 AD FS SSL 憑證繫結時,http.sys 永遠使用憑證的 SSL 通訊的繫結。若要解決這個問題,請使用下列方法。

方法 1: 移除 IP:port 繫結

注意您在移除後,可能會有 IP:port 繫結。例如,應用程式設定與這個 IP:port 繫結可能會自動重新建立它下一個服務啟動時。

方法 2: 使用 AD FS SSL 通訊的另一個 IP 位址

如果需要 IP:port 繫結,ADFS 服務 FQDN 解析另一個不是任何繫結的 IP 位址。如此一來,http.sys 會使用 Hostname:port 繫結的 SSL 通訊。

方法 3: 設定 AdfsTrustedDevices 作為 IP:port 繫結的 CTL 存放區

這是最後不得已的情況下,如果您不能使用上述的方法。但是最好是了解之前,您將 CTL 儲存預設值變更為 AdfsTrustedDevices,下列條件:

  • 為什麼 IP:port 繫結是否有。

  • 如果繫結則會依賴一項 CTL 儲存用戶端憑證驗證的預設值。

問題是否解決了?

如果已安裝 Azure 的 AD 連線,使用 AAD 連線設 CTL 存放區名稱 AdfsTrustedDevices 的所有 AD FS 伺服器上的 SSL 憑證繫結。如果未安裝 Azure 的 AD 連線,重新產生的 AD FS 憑證繫結,AD FS 的所有伺服器上執行下列命令。
Set-AdfsSslCertificate -Thumbprint Thumbprint

問題是否解決了?

如果發行憑證的 CA 是自我簽署的憑證會通常存在的憑證存放區中,從存放區所產生的 CTL 會只會包含發出憑證的 CA。AdfsTrustedDevices 憑證存放區是一個這類應該要有只有自我簽署的憑證的存放區。這些憑證是:

  • MS 組織存取: 用於發行工作地點聯結憑證到自我簽署的憑證。

  • 信任的 ADFS Proxy: 憑證,為每個 Web 應用程式 Proxy 伺服器的。

AdfsTrustedDevices certificates

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

問題是否解決了?

建立 proxy 的信任關係時,與 AD FS 伺服器,用戶端憑證將寫入到 AD FS 的組態資料庫中,並且加入至 AdfsTrustedDevices 憑證存放區,AD FS 伺服器上。針對 AD FS 伺服陣列部署,預期用戶端憑證進行同步處理,其他的 AD FS 伺服器。如果基於某些原因,不會同步處理,則對 AD FS 伺服器與,已建立的信任,但不是檢查其他的 AD FS 伺服器只會運作 proxy 的信任關係。

若要解決這個問題,請使用下列方法之一。

方法 1

所有的 AD FS 伺服器上,安裝更新程式詳加說明KB 2964735 。已安裝更新之後,會預期同步的用戶端憑證會自動發生。

方法 2

執行指令碼搭配 – syncproxytrustcerts 參數,以手動同步處理至 AdfsTrustedDevices 憑證存放區的 [從 AD FS 設定資料庫的用戶端憑證。指令碼,應在陣列中的所有 AD FS 伺服器上執行。

請注意這不是永久性的解決方案因為用戶端憑證會定期更新。

問題是否解決了?

請檢查是否有時間或時區的不相符。如果時間符合,但不區域的時間,proxy 信任關係也將無法建立。

問題是否解決了?

如果 SSL 終止發生 AD FS 伺服器與 WAP 伺服器之間的網路裝置上時,AD FS 和 WAP 之間的通訊將會中斷,因為通訊根據用戶端憑證。

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

問題是否解決了?

檢查用戶端瀏覽器中的 Windows 整合式驗證設定值,AD FS 設定和驗證要求的參數。

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

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

  • 在 [進階] 索引標籤中,請確定已啟用 [啟用整合式 Windows 驗證設定。

  • 下列安全性>近端內部網路>站台> [進階],請確定 AD FS URL 的網站清單。

  • 安全性 > 近端內部網路 > 自訂層級,請確定已選取 [只在內部網路區域自動登入設定。

如果您使用要在 Firefox、 色彩或 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-同盟要求、 檢查要求包含wauth = urn: 綠洲: 名稱: tc: SAML:1.0:am:password

  2. 如果驗證要求 SAML 要求,請檢查 [要求是否包含samlp:AuthnContextClassRef項目與值Urn: 綠洲: 名稱: tc: SAML:2.0:ac:classes:Password.

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

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

如果您想要存取的應用程式不是 Microsoft Online Services,預期您所遇到由連入的驗證要求和控制.使用 [應用程式擁有者 變更行為。

如果 Microsoft Online Services 應用程式,您所遇到可能由控制PromptLoginBehavior設定,從受信任的領域物件。這個設定會控制 Azure 的 AD tenants 傳送提示是否 = 登入 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 FS,而不是提示的 wauth 和 wfresh = 登入。這會導致若要使用表單架構驗證的驗證要求。

    2. NativeSupport: 提示 = 登入參數則 AD FS 會傳送。

    3. 停用: 不會傳送到 AD FS。

若要深入了解組 MSOLDomainFederationSettings 命令,請參閱Active Directory 聯盟服務提示 = 登入參數支援

問題是否解決了?

啟用 AD FS 伺服器,在信賴憑證者,或是驗證要求參數中指定多因素驗證。請檢查是否已正確設定組態。如果多因素驗證何時必須完成但您're 系統重複提示輸入它,檢查信賴憑證者的合作對象發行規則,來查看如果多因素驗證宣告都會透過傳遞至應用程式。

如需有關 AD FS 中的多因素驗證的詳細資訊,請參閱下列文件:

請檢查 AD FS 伺服器和信賴憑證者組態

若要檢查 AD FS 伺服器上的設定,驗證的全域額外的驗證規則。若要檢查信賴憑證者上的設定,驗證的信賴憑證者的合作對象信任的額外的驗證規則。

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

    若要檢查信賴憑證者上的設定,執行下列命令:
    Get-ADFSRelyingPartyTrust -TargetName RelyingParty | Select -ExpandProperty AdditionalAuthenticationRules

    注意如果命令傳回任何動作,未設定額外的驗證規則。略過本節。

  2. 請注意設定已設定的宣告規則。

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

宣告規則集合是由下列各節所組成:

  • 條件陳述式:C:[Type=…,Value=…]

  • 問題陳述式:=> issue (Type=…,Value=…)

如果問題陳述式包含下列的宣告,則指定多因素驗證。
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-同盟要求、 檢查要求包含wauth = http://schemas.microsoft.com/claims/multipleauthn

  • 如果驗證要求 SAML 要求,請檢查 [要求是否包含samlp:AuthnContextClassRef項目使用值http://schemas.microsoft.com/claims/multipleauthn.

如需詳細資訊,請參閱驗證處理常式的 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

問題是否解決了?

執行下列命令以停用的提示 = 登入能力:
Set-MsolDomainFederationSettings –DomainName DomainName -PromptLoginBehavior Disabled

執行這個命令之後,Office 365 應用程式不會在每個驗證要求中加入提示 = 登入參數。

問題是否解決了?

修改要求參數,以使用預期的驗證方法。

問題是否解決了?

如果停用 SSO,請將它啟用。

問題是否解決了?

恭喜 !SSO 問題已經解決了。

很抱歉問題仍然存在。我們非常感謝它如果您填寫問卷問題的詳細資料。

本指南的作用何在?

解析單一登入 (SSO) 發出 Active Directory 聯盟服務 (AD FS)。

它的是誰?

系統管理員協助診斷為使用者的 SSO 問題。

它的運作方式?

我們會先詢問您的使用者所面對的問題。然後我們將引導您執行一系列的疑難排解步驟專屬於您的情況。

估計的完成時間:

30-45 分鐘。

需要更多協助?

擴展您的技能
探索訓練
優先取得新功能
加入 Microsoft 測試人員

這項資訊有幫助嗎?

您對語言品質的滿意度如何?
以下何者是您會在意的事項?

感謝您的意見反應!

×