針對 Azure AD B2C 自定義原則和使用者流程進行疑難解答

開始之前,請使用 [選擇原則類型 選取器] 來選擇您要設定的原則類型。 Azure Active Directory B2C 提供兩種方法來定義使用者如何與您的應用程式互動:透過預先 定義的使用者流程 ,或透過完全可設定 的自定義原則。 本文中每個方法所需的步驟都不同。

您的應用程式必須處理來自 Azure B2C 服務的特定錯誤。 本文將重點說明一些常見的錯誤,以及如何加以處理。

密碼重設錯誤

當使用者流程中未啟用自助式密碼重設體驗,就會發生此錯誤。 因此,選取 [ 忘記密碼嗎?] 連結不會觸發密碼重設使用者流程。 相反地,錯誤碼 AADB2C90118 會傳回至您的應用程式。

此問題有 2 個解決方案:

使用者已取消作業

當使用者取消作業時,Azure AD B2C 服務也可以將錯誤傳回您的應用程式。 以下是使用者執行取消作業的案例範例:

  • 用戶原則會使用取用者本機帳戶的建議 自助式密碼重設 (SSPR) 體驗 。 用戶選取 [ 忘記密碼嗎?] 鏈接,然後在使用者流程體驗完成之前選取 [ 取消 ] 按鈕。 在此情況下,Azure AD B2C 服務會將錯誤碼 AADB2C90091 傳回您的應用程式。
  • 用戶選擇向外部識別提供者進行驗證,例如 LinkedIn。 使用者先選取 [ 取消] 按鈕,再向識別提供者本身進行驗證。 在此情況下,Azure AD B2C 服務會將錯誤碼 AADB2C90273 傳回您的應用程式。 深入瞭解 錯誤碼 Azure Active Directory B2C 服務傳回

若要處理此錯誤,請 擷取使用者的錯誤描述 ,並使用相同的使用者流程以新的驗證要求回應。

如果您使用 Azure Active Directory B2C (Azure AD B2C) 自定義原則,您可能會遇到原則語言 XML 格式或運行時間問題的挑戰。 本文說明可協助您探索和解決問題的一些工具和秘訣。

本文著重於針對 Azure AD B2C 自定義原則設定進行疑難解答。 它不會處理信賴憑證者應用程式或其身分識別連結庫。

Azure AD B2C 相互關聯標識符概觀

Azure AD B2C 相互關聯標識碼是附加至授權要求的唯一標識碼值。 它會通過用戶通過的所有協調流程步驟。 使用相互關聯識別碼,您可以:

  • 識別應用程式中的登入活動,並追蹤原則的效能。
  • 尋找登入要求的 Azure 應用程式 Insights 記錄。
  • 將相互關聯標識碼傳遞至 REST API,並用它來識別登入流程。

每次建立新的工作階段時,就會變更相互關聯標識碼。 當您對原則進行偵錯時,請確定您關閉現有的瀏覽器索引標籤,或開啟新的私用模式瀏覽器。

必要條件

取得 Azure AD B2C 相互關聯標識碼

您可以在 Azure AD B2C 註冊或登入頁面中找到相互關聯識別碼。 在您的瀏覽器中,選取 [檢視來源]。 相互關聯會顯示為頁面頂端的批注。

Screenshot of Azure AD B2C sign-in page view source.

複製相互關聯標識碼,然後繼續登入流程。 使用相互關聯標識碼來觀察登入行為。 如需詳細資訊,請參閱 使用Application Insights進行疑難解答。

回應 Azure AD B2C 相互關聯標識碼

您可以在 Azure AD B2C 令牌中包含相互關聯識別碼。 若要包含相互關聯識別碼:

  1. 開啟原則的延伸模組檔案。 例如: SocialAndLocalAccounts/TrustFrameworkExtensions.xml

  2. 搜尋 BuildingBlocks 元素。 如果專案不存在,請加以新增。

  3. 找出 ClaimsSchema 元素。 如果專案不存在,請加以新增。

  4. 將相互關聯標識碼宣告新增至 ClaimsSchema 元素。

    <!-- 
    <BuildingBlocks>
      <ClaimsSchema> -->
        <ClaimType Id="correlationId">
          <DisplayName>correlation ID</DisplayName>
          <DataType>string</DataType>
        </ClaimType>
      <!-- 
      </ClaimsSchema>
    </BuildingBlocks>-->
    
  5. 開啟原則的信賴憑證者檔案。 例如, SocialAndLocalAccounts/SignUpOrSignIn.xml 檔案。 成功使用者旅程圖並傳送至應用程式之後,輸出宣告將會新增至令牌。 修改信賴憑證者區段中的技術配置文件專案,將 新增 correlationId 為輸出宣告。

    <RelyingParty>
      <DefaultUserJourney ReferenceId="SignUpOrSignIn" />
      <TechnicalProfile Id="PolicyProfile">
        <DisplayName>PolicyProfile</DisplayName>
        <Protocol Name="OpenIdConnect" />
        <OutputClaims>
          ...
          <OutputClaim ClaimTypeReferenceId="correlationId" DefaultValue="{Context:CorrelationId}" />
        </OutputClaims>
        <SubjectNamingInfo ClaimType="sub" />
      </TechnicalProfile>
    </RelyingParty>
    

使用 Application Insights 進行疑難解答

若要診斷自定義原則的問題,請使用 ApplicationInsights。 Application Insights 會追蹤自定義原則使用者旅程圖的活動。 它提供一種方式來診斷例外狀況,並觀察 Azure AD B2C 與各種宣告提供者之間的宣告交換。 宣告提供者是由技術配置檔所定義,例如識別提供者、API 型服務、Azure AD B2C 用戶目錄和其他服務。

我們建議安裝適用於 VS CodeAzure AD B2C 擴充功能。 使用 Azure AD B2C 擴充功能時,記錄會依原則名稱、相互關聯標識元(Application Insights 呈現相互關聯標識碼的第一位數)和記錄時間戳來為您組織。 此功能可協助您根據本機時間戳尋找相關的記錄,並查看 Azure AD B2C 所執行的使用者旅程圖。

注意

  • 在 Application Insights 中看到新的記錄之前,延遲通常少於 5 分鐘。
  • 社群已針對 Azure AD B2C 開發 Visual Studio Code 擴充功能,以協助身分識別開發人員。 Microsoft 不支援此延伸模組,而且會嚴格依目前提供。

單一登錄流程可以發出多個 Azure 應用程式 Insights 追蹤。 在下列螢幕快照中 ,B2C_1A_signup_signin 原則有三個記錄。 每個記錄都代表登入流程的一部分。

下列螢幕快照顯示適用於 VS Code 的 Azure AD B2C 擴充功能,其中包含 Azure 應用程式 Insights 追蹤總管。

Screenshot of Azure AD B2C extension for VS Code with Azure Application Insights trace.

篩選追蹤記錄檔

將焦點放在 Azure AD B2C 追蹤總管上,開始輸入相互關聯標識碼的第一個數位,或您想要尋找的時間。 您會看到 Azure AD B2C 追蹤總管右上角的篩選方塊,其中顯示您到目前為止已輸入的內容,並醒目提示相符的追蹤記錄。

Screenshot of Azure AD B2C extension Azure AD B2C trace explorer filter highlighting.

將滑鼠停留在篩選方塊上,然後選取 [在類型上啟用篩選] 只會顯示相符的追蹤記錄。 使用 [X] [清除] 按鈕來清除篩選。

Screenshot of Azure AD B2C extension Azure AD B2C trace explorer filter.

Application Insights 追蹤記錄詳細數據

當您選取 Azure 應用程式 Insights 追蹤時,擴充功能會開啟 Application Insights 詳細數據視窗,其中包含下列資訊:

  • Application Insights - 追蹤記錄的一般資訊,包括原則名稱、相互關聯標識碼、Azure 應用程式 Insights 追蹤標識碼,以及追蹤時間戳。
  • 技術設定檔 - 追蹤記錄中顯示的技術配置檔清單。
  • 宣告 - 追蹤記錄檔及其值中顯示的宣告依字母順序排列的清單。 如果具有不同值的宣告多次出現在追蹤記錄檔中,則 => 符號會指定最新的值。 您可以檢閱這些宣告,以判斷預期的宣告值是否已正確設定。 例如,如果您有檢查宣告值的前置條件,宣告區段可協助您判斷預期流程的行為為何不同。
  • 宣告轉換 - 追蹤記錄檔中出現的宣告轉換清單。 每個宣告轉換都包含輸入宣告、輸入參數和輸出宣告。 宣告轉換區段可讓您深入瞭解在 中傳送的數據,以及宣告轉換的結果。
  • 令牌 - 出現在追蹤記錄中的令牌清單。 令牌包括基礎同盟 OAuth 和 OpenId 連線 識別提供者的令牌。 同盟識別提供者的令牌提供識別提供者如何將宣告傳回至 Azure AD B2C 的詳細數據,讓您可以對應識別提供者技術配置文件輸出宣告。
  • 例外狀況 - 追蹤記錄檔中出現的例外狀況或嚴重錯誤清單。
  • Application Insights JSON - 從 Application Insights 傳回的原始數據。

下列螢幕快照顯示 Application Insights 追蹤記錄詳細數據視窗的範例。

Screenshot of Azure AD B2C extension Azure AD B2C trace report.

針對 JWT 令牌進行疑難解答

針對 JWT 令牌驗證和偵錯目的,您可以使用之類的 https://jwt.ms網站來譯碼 JWT。 建立可重新導向至 https://jwt.ms 以進行令牌檢查的測試應用程式。 如果您尚未這麼做, 請註冊 Web 應用程式 ,並 啟用識別碼權杖隱含授 與。

Screenshot of JWT token preview.

使用 [立即 執行],並 https://jwt.ms 獨立測試您的 Web 或行動應用程式的原則。 此網站的作用就像信賴憑證者應用程式。 它會顯示 Azure AD B2C 原則所產生的 JSON Web 權杖 (JWT) 內容。

針對 SAML 通訊協定進行疑難排解

若要協助設定及偵錯與服務提供者的整合,您可以使用 SAML 通訊協定的瀏覽器擴充功能,例如 Chrome 的 SAML DevTools 擴充 功能、適用于 FireFox 的 SAML 追蹤器 Edge 或 IE 開發人員工具

下列螢幕擷取畫面示範 SAML DevTools 延伸模組如何呈現 SAML 要求 Azure AD B2C 傳送至識別提供者,以及 SAML 回應。

Screenshot of SAML protocol trace log.

使用這些工具,您可以檢查應用程式與 Azure AD B2C 之間的整合。 例如:

  • 檢查 SAML 要求是否包含簽章,並判斷用來登入授權要求的演算法。
  • 檢查 Azure AD B2C 是否傳回錯誤訊息。
  • 檢查判斷提示區段是否已加密。
  • 取得宣告的名稱會傳回識別提供者。

您也可以使用 Fiddler 追蹤用戶端瀏覽器與 Azure AD B2C 之間的訊息交換。 其可協助您取得協調流程步驟中使用者旅程失敗的指示。

針對原則有效性進行疑難排解

完成原則開發之後,您會將原則上傳至 Azure AD B2C。 您的原則可能有一些問題,但您可以在上傳原則之前驗證原則。

設定自訂原則最常見的錯誤是格式不正確的 XML。 良好的 XML 編輯器幾乎至關重要。 它會以原生方式顯示 XML、色彩代碼內容、預先填入一般詞彙、讓 XML 元素編制索引,並可針對 XML 架構進行驗證。

我們建議使用 Visual Studio Code 。 然後安裝 XML 延伸模組,例如 Red Hat 的 XML 語言支援。 XML 延伸模組可讓您先驗證 XML 架構,再使用自訂原則 XSD 架構定義來上傳 XML 檔案。

您可以使用 XML 檔案關聯策略,將下列設定新增至 VS Code settings.json 檔案,將 XML 檔案系結至 XSD。 若要這麼做︰

  1. 從 VS Code 選取 [ 檔案 > 喜好設定 > 設定 ]。 如需詳細資訊,請參閱 使用者和工作區設定

  2. 搜尋 fileAssociations ,然後在 [延伸模組 ] 底下 選取 XML

  3. 選取 settings.json 中的 [編輯]。

    Screenshot of VS Code XML schema validation.

  4. 在 settings.json 中,新增下列 JSON 程式碼:

    "xml.fileAssociations": [
      {
        "pattern": "**.xml",
        "systemId": "https://raw.githubusercontent.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack/master/TrustFrameworkPolicy_0.3.0.0.xsd"
      }
    ]
    
  5. 儲存變更。

下列範例顯示 XML 驗證錯誤。 當您將滑鼠移至專案名稱上方時,延伸模組會列出預期的元素。

Screenshot of VS Code XML schema validation error indicator.

在下列案例中,元素 DisplayName 是正確的。 但是,按照錯誤的順序。 DisplayName應該在 專案之前 Protocol 。 若要修正此問題,請將滑鼠移至 DisplayName 元素的正確順序。

Screenshot of VS Code XML schema validation order error.

上傳原則和原則驗證

XML 原則檔案的驗證會在上傳時自動執行。 大部分的錯誤都會造成上傳失敗。 驗證封裝含您想要上傳的原則檔案。 它也包含上傳檔案所參考的檔案鏈結(信賴憑證者原則檔案、副檔名檔案和基底檔案)。

提示

Azure AD B2C 會針對信賴憑證者原則執行額外的驗證。 當您的原則發生問題時,即使您只編輯擴充原則,上傳信賴憑證者原則也是很好的做法。

本節包含常見的驗證錯誤和可能的解決方案。

找到架構驗證錯誤...子專案 '{name}' 無效

您的原則包含不正確 XML 元素,或 XML 元素有效,但看起來順序錯誤。 若要修正這種類型的錯誤,請參閱 疑難排解原則有效性 一節。

有重複的索引鍵序列 '{number}'

使用者 旅程圖或 子旅程 圖是由循序執行的協調流程步驟清單所組成。 變更旅程之後,請依序重新編號步驟,而不會略過任何從 1 到 N 的整數。

提示

您可以使用 適用于 VS Code (Shift+Ctrl+r) 的 Azure AD B2C 擴充功能 命令,在您的原則中重新編號所有使用者旅程圖和子旅程流程步驟。

...預期有順序為 「{number}」 的步驟,但找不到...

檢查先前的錯誤。

使用者旅程圖 「{name}」 中的協調流程步驟順序 「{number}」 ...後面接著宣告提供者選取步驟,而且必須是宣告交換,但類型為...

的協調流程步驟類型 ClaimsProviderSelection ,並 CombinedSignInAndSignUp 包含使用者可以選擇的選項清單。 它後面必須接著具有一或多個宣告交換的 ClaimsExchange 型別。

下列協調流程步驟會導致此類型或錯誤。 第二個協調流程步驟的類型必須是 ClaimsExchange ,而不是 ClaimsProviderSelection

<!-- 
<UserJourneys>
  <UserJourney Id="SignUpOrSignIn">
    <OrchestrationSteps>-->
      <OrchestrationStep Order="1" Type="CombinedSignInAndSignUp" ContentDefinitionReferenceId="api.signuporsignin">
        <ClaimsProviderSelections>
          <ClaimsProviderSelection TargetClaimsExchangeId="FacebookExchange"/>
          <ClaimsProviderSelection ValidationClaimsExchangeId="LocalAccountSigninEmailExchange"/>
        </ClaimsProviderSelections>
        <ClaimsExchanges>
          <ClaimsExchange Id="LocalAccountSigninEmailExchange" TechnicalProfileReferenceId="SelfAsserted-LocalAccountSignin-Email"/>
        </ClaimsExchanges>
      </OrchestrationStep> 

      <OrchestrationStep Order="2" Type="ClaimsProviderSelection">
        ...
      </OrchestrationStep>
      ...
    <!--
    </OrchestrationSteps>
  </UserJourney>
</UserJourneys> -->

...步驟 {number} 與 2 個宣告交換。 它前面必須有宣告提供者選取專案,才能判斷可以使用哪些宣告交換

的協調流程步驟類型 ClaimsExchange 必須具有單 ClaimsExchange 一 ,除非上一個步驟的類型為 ClaimsProviderSelectionCombinedSignInAndSignUp 。 下列協調流程步驟會導致這種類型的錯誤。 第六個步驟包含兩個宣告交換。

<!-- 
<UserJourneys>
  <UserJourney Id="SignUpOrSignIn">
    <OrchestrationSteps>-->
      ...
      <OrchestrationStep Order="5" Type="ClaimsExchange">
        ...
        <ClaimsExchanges>
          <ClaimsExchange Id="SelfAsserted-Social" TechnicalProfileReferenceId="SelfAsserted-Social"/>
        </ClaimsExchanges>
      </OrchestrationStep>
      <OrchestrationStep Order="6" Type="ClaimsExchange">
        <ClaimsExchanges>
          <ClaimsExchange Id="Call-REST-First-API" TechnicalProfileReferenceId="Call-REST-First-API"/>
          <ClaimsExchange Id="Call-REST-Second-API" TechnicalProfileReferenceId="Call-REST-Second-API"/>
        </ClaimsExchanges>
      </OrchestrationStep>
      ...
    <!--
    </OrchestrationSteps>
  </UserJourney>
</UserJourneys> -->

若要修正這種類型的錯誤,請使用兩個協調流程步驟。 每個協調流程步驟都有一個宣告交換。

<!-- 
<UserJourneys>
  <UserJourney Id="SignUpOrSignIn">
    <OrchestrationSteps>-->
      ...
      <OrchestrationStep Order="5" Type="ClaimsExchange">
        ...
        <ClaimsExchanges>
          <ClaimsExchange Id="SelfAsserted-Social" TechnicalProfileReferenceId="SelfAsserted-Social"/>
        </ClaimsExchanges>
      </OrchestrationStep>
      <OrchestrationStep Order="6" Type="ClaimsExchange">
        <ClaimsExchanges>
          <ClaimsExchange Id="Call-REST-First-API" TechnicalProfileReferenceId="Call-REST-First-API"/>
        </ClaimsExchanges>
      </OrchestrationStep>
      <OrchestrationStep Order="7" Type="ClaimsExchange">
        <ClaimsExchanges>
          <ClaimsExchange Id="Call-REST-Second-API" TechnicalProfileReferenceId="Call-REST-Second-API"/>
        </ClaimsExchanges>
      </OrchestrationStep>
      ...
    <!--
    </OrchestrationSteps>
  </UserJourney>
</UserJourneys> -->

有重複的索引鍵序列 '{name}'

一個旅程具有相同 的倍 ClaimsExchangeId 。 下列步驟會導致這種類型的錯誤。 識別碼 AADUserWrite 會在使用者旅程圖中出現兩次。

<!-- 
<UserJourneys>
  <UserJourney Id="SignUpOrSignIn">
    <OrchestrationSteps>-->
      ...
      <OrchestrationStep Order="7" Type="ClaimsExchange">
        <ClaimsExchanges>
          <ClaimsExchange Id="AADUserWrite" TechnicalProfileReferenceId="AAD-UserWriteUsingAlternativeSecurityId"/>
        </ClaimsExchanges>
      </OrchestrationStep>
      <OrchestrationStep Order="8" Type="ClaimsExchange">
        <ClaimsExchanges>
          <ClaimsExchange Id="AADUserWrite" TechnicalProfileReferenceId="Call-REST-API"/>
        </ClaimsExchanges>
      </OrchestrationStep>
      ...
    <!--
    </OrchestrationSteps>
  </UserJourney>
</UserJourneys> -->

若要修正這種類型的錯誤,請將第八個協調流程步驟的宣告交換變更為唯一名稱,例如 Call-REST-API

<!-- 
<UserJourneys>
  <UserJourney Id="SignUpOrSignIn">
    <OrchestrationSteps>-->
      ...
      <OrchestrationStep Order="7" Type="ClaimsExchange">
        <ClaimsExchanges>
          <ClaimsExchange Id="AADUserWrite" TechnicalProfileReferenceId="AAD-UserWriteUsingAlternativeSecurityId"/>
        </ClaimsExchanges>
      </OrchestrationStep>
      <OrchestrationStep Order="8" Type="ClaimsExchange">
        <ClaimsExchanges>
          <ClaimsExchange Id="Call-REST-API" TechnicalProfileReferenceId="Call-REST-API"/>
        </ClaimsExchanges>
      </OrchestrationStep>
      ...
    <!--
    </OrchestrationSteps>
  </UserJourney>
</UserJourneys> -->

...會參考識別碼為 「{claim name}」 的 ClaimType,但原則及其任何基底原則都不包含這類元素

當您的原則參考未在宣告架構 中宣告的 宣告時,就會發生這種類型的錯誤。 宣告必須在原則中的至少一個檔案中定義。

例如,具有 schoolId 輸出宣告的技術設定檔。 但是輸出宣告 schoolId 絕不會在原則或上階原則中宣告。

<OutputClaims>
  <OutputClaim ClaimTypeReferenceId="schoolId" />
  ...
</OutputClaims>

若要修正這種類型的錯誤,請檢查值拼 ClaimTypeReferenceId 錯或不存在於架構中。 如果宣告是在延伸模組原則中定義,但它也會用於基底原則中。 請確定宣告已定義于其所使用的原則中,或是在上層原則中定義。

將宣告新增至宣告架構可解決這種類型的錯誤。

<!--
<BuildingBlocks>
  <ClaimsSchema> -->
    <ClaimType Id="schoolId">
      <DisplayName>School name</DisplayName>
      <DataType>string</DataType>
      <UserHelpText>Enter your school name</UserHelpText>
      <UserInputType>TextBox</UserInputType>
    </ClaimType>
  <!-- 
  </ClaimsSchema>
</BuildingBlocks> -->

...會參考識別碼為 ClaimsTransformation...

此錯誤的原因與宣告錯誤的原因類似。 檢查先前的錯誤。

使用者目前已以「yourtenant.onmicrosoft.com」租使用者的使用者身分登入...

您以與您嘗試上傳的原則不同的租使用者帳戶登入。 例如,當您的原則設定 fabrikam.onmicrosoft.com 為 時 TenantId ,使用 admin@contoso.onmicrosoft.com 登入。

<TrustFrameworkPolicy ...
  TenantId="fabrikam.onmicrosoft.com"
  PolicyId="B2C_1A_signup_signin"
  PublicPolicyUri="http://fabrikam.onmicrosoft.com/B2C_1A_signup_signin">

  <BasePolicy>
    <TenantId>fabrikam.onmicrosoft.com</TenantId>
    <PolicyId>B2C_1A_TrustFrameworkExtensions</PolicyId>
  </BasePolicy>
  ...
</TrustFrameworkPolicy>
  • 檢查 和 <TrustFrameworkPolicy\><BasePolicy\> 元素中的值是否符合 TenantId 您的目標 Azure AD B2C 租使用者。

宣告類型 「{name}」 是信賴憑證者技術設定檔的輸出宣告,但在使用者旅程圖的任何步驟中,它不是輸出宣告...

在信賴憑證者原則中,您已新增輸出宣告,但輸出宣告不是任何使用者旅程圖步驟中的輸出宣告。 Azure AD B2C 無法從宣告包讀取宣告值。

在下列範例中 ,schoolId 宣告是信賴憑證者技術設定檔的輸出宣告,但在 SignUpOrSignIn 使用者旅程圖的任何步驟 中,它不是輸出宣告。

<RelyingParty>
  <DefaultUserJourney ReferenceId="SignUpOrSignIn" />
  <TechnicalProfile Id="PolicyProfile">
    <DisplayName>PolicyProfile</DisplayName>
    <Protocol Name="OpenIdConnect" />
    <OutputClaims>
      <OutputClaim ClaimTypeReferenceId="schoolId" />
      ...
    </OutputClaims>
    <SubjectNamingInfo ClaimType="sub" />
  </TechnicalProfile>
</RelyingParty>

若要修正這種類型的錯誤,請確定輸出宣告出現在至少一個協調流程步驟的技術設定檔輸出宣告集合中。 如果您的使用者旅程圖無法輸出宣告,請在信賴憑證者技術設定檔中設定預設值,例如空字串。

<OutputClaim ClaimTypeReferenceId="schoolId" DefaultValue="" />

輸入字串的格式不正確

您將不正確的實數值型別設定為來自另一個類型的宣告。 例如,您可以定義整數宣告。

<!--
<BuildingBlocks>
  <ClaimsSchema> -->
    <ClaimType Id="age">
      <DisplayName>Age</DisplayName>
      <DataType>int</DataType>
    </ClaimType>
  <!--
  </ClaimsSchema>
</BuildingBlocks> -->

然後,您嘗試設定字串值:

<OutputClaim ClaimTypeReferenceId="age" DefaultValue="ABCD" />

若要修正這種類型的錯誤,請確定您已設定正確的值,例如 DefaultValue="0"

租使用者 「{name}」 已經有識別碼為 「{name}」 的原則。 無法儲存具有相同識別碼的另一個原則

您嘗試將原則上傳至您的租使用者,但已將具有相同名稱的原則上傳至您的租使用者。

若要修正這種類型的錯誤,當您上傳原則時,請選取 [如果自訂原則已經存在 ]核取方塊,請選取 [覆寫自訂原則]。

Screenshot that demonstrates how to overwrite the custom policy if it already exists.

下一步