重要
2025 年 5 月 1 日より、Azure AD B2C は新規のお客様向けに購入できなくなります。 詳細については、FAQ を参照してください。
開始する前にこのページの上部にある ポリシーの種類 セレクターを使用して、設定するポリシーの種類を選択します。 Azure Active Directory B2C には、ユーザーがアプリケーションを操作する方法を定義する 2 つの方法 (定義済みのユーザー フローを使用する、または完全に構成可能なカスタム ポリシーを使用する) があります。 この記事で必要な手順は、方法ごとに異なります。
アプリケーションでは、Azure B2C サービスからの特定のエラーを処理する必要があります。 この記事では、一般的なエラーとその処理方法について説明します。
パスワードリセットエラー
このエラーは、 セルフサービス パスワード リセット エクスペリエンス がユーザー フローで有効になっていない場合に発生します。 したがって、[ パスワードを忘れた場合 ] リンクを選択しても、パスワード リセット ユーザー フローはトリガーされません。 代わりに、エラー コード AADB2C90118
がアプリケーションに返されます。
この問題には2つの解決策があります。
- Azure AD B2C パスワード リセット ユーザー フローを使用して、新しい認証要求で応答します。
- 推奨される セルフサービス パスワード リセット (SSPR) エクスペリエンスを使用します。
ユーザーが操作をキャンセルしました
Azure AD B2C サービスは、ユーザーが操作をキャンセルしたときに、アプリケーションにエラーを返すこともできます。 ユーザーがキャンセル操作を実行するシナリオの例を次に示します。
- ユーザー ポリシーでは、コンシューマー ローカル アカウントで推奨される セルフサービス パスワード リセット (SSPR) エクスペリエンス を使用します。 ユーザーは [ パスワードを忘れた場合] リンクを選択し、ユーザー フロー エクスペリエンスが完了する前に [キャンセル] ボタンを選択します。 この場合、Azure AD B2C サービスはエラー コード をアプリケーションに返
AADB2C90091
。 - ユーザーは、 LinkedIn などの外部 ID プロバイダーで認証することを選択します。 ユーザーは、ID プロバイダー自体に認証する前に [キャンセル] ボタンを選択します。 この場合、Azure AD B2C サービスはエラー コード をアプリケーションに返
AADB2C90273
。 Azure Active Directory B2C サービスから返されるエラー コードの詳細を確認してください。
このエラーを処理するには、ユーザーの エラーの説明 をフェッチし、同じユーザー フローを使用して新しい認証要求で応答します。
Azure Active Directory B2C (Azure AD B2C) カスタム ポリシーを使用する場合、ポリシー言語の XML 形式やランタイムの問題で問題が発生する可能性があります。 この記事では、問題の検出と解決に役立つツールとヒントについて説明します。
この記事では、Azure AD B2C カスタム ポリシー構成のトラブルシューティングについて説明します。 信頼パーティアプリケーションまたはそのアイデンティティライブラリには対応していません。
Azure AD B2C 関連付け ID の概要
Azure AD B2C 関連付け ID は、承認要求にアタッチされる一意の識別子値です。 これは、ユーザーが実行するすべてのオーケストレーション手順を通過します。 関連付け ID を使用すると、次のことができます。
- アプリケーション内のサインイン アクティビティを特定し、ポリシーのパフォーマンスを追跡します。
- サインイン要求の Azure Application Insights ログを見つけます。
- 関連付け ID を REST API に渡し、それを使用してサインイン フローを識別します。
相関 ID は、新しいセッションが確立されるたびに変更されます。 ポリシーをデバッグするときは、既存のブラウザタブを閉じるか、新しいプライベートモードブラウザを開いてください。
[前提条件]
- 「Active Directory B2C でのカスタム ポリシーの概要」の手順を完了してください。
Azure AD B2C 関連付け ID を取得する
関連付け ID は、Azure AD B2C のサインアップまたはサインイン ページで確認できます。 ブラウザで、「 ソースの表示」を選択します。 相関関係は、ページの上部にコメントとして表示されます。
関連付け ID をコピーし、サインイン フローを続行します。 関連付け ID を使用して、サインイン動作を観察します。 詳細については、「 Application Insights によるトラブルシューティング」を参照してください。
Azure AD B2C 関連付け ID をエコーします
関連付け ID は、Azure AD B2C トークンに含めることができます。 関連付け ID を含めるには、次のようにします。
ポリシーの拡張ファイルを開きます。 たとえば、
SocialAndLocalAccounts/
TrustFrameworkExtensions.xml
のようにします。BuildingBlocks 要素を検索します。 要素が存在しない場合は、追加します。
ClaimsSchema 要素を見つけます。 要素が存在しない場合は、追加します。
関連付け ID 要求を ClaimsSchema 要素に追加します。
<!-- <BuildingBlocks> <ClaimsSchema> --> <ClaimType Id="correlationId"> <DisplayName>correlation ID</DisplayName> <DataType>string</DataType> </ClaimType> <!-- </ClaimsSchema> </BuildingBlocks>-->
ポリシーの証明書利用者ファイルを開きます。 たとえば、
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 によるトラブルシューティング
カスタム ポリシーの問題を診断するには、 Application Insights を使用します。 Application Insights は、カスタム ポリシーのユーザー体験のアクティビティをトレースします。 これにより、例外を診断し、Azure AD B2C とさまざまな要求プロバイダーとの間の要求の交換を観察する方法が提供されます。 要求プロバイダーは、ID プロバイダー、API ベースのサービス、Azure AD B2C ユーザー ディレクトリ、その他のサービスなどの技術プロファイルによって定義されます。
VS Code 用の Azure AD B2C 拡張機能をインストールすることをお勧めします。 Azure AD B2C 拡張機能を使用すると、ログはポリシー名、関連付け ID (Application Insights では関連付け ID の最初の桁が表示されます)、およびログのタイムスタンプごとに整理されます。 この機能は、ローカル タイムスタンプに基づいて関連するログを検索し、Azure AD B2C によって実行されたユーザー体験を確認するのに役立ちます。
注
- Application Insights に新しいログが表示されるまでに、短い遅延 (通常は 5 分未満) があります。
- コミュニティでは、ID 開発者を支援するために、Azure AD B2C 用の Visual Studio Code 拡張機能が開発されました。 この拡張機能は Microsoft によってサポートされておらず、厳密に現状有姿のまま提供されています。
シングル サインイン フローでは、複数の Azure Application Insights トレースを発行できます。 次のスクリーンショットでは、 B2C_1A_signup_signin ポリシーに 3 つのログがあります。 各ログは、サインイン フローの一部を表します。
次のスクリーンショットは、Azure Application Insights トレース エクスプローラーを使用した VS Code の Azure AD B2C 拡張機能を示しています。
トレースログをフィルターする
Azure AD B2C トレース エクスプローラーにフォーカスを当てて、関連付け ID の最初の桁、または検索する時刻の入力を開始します。 Azure AD B2C トレース エクスプローラーの右上に、これまでに入力した内容を示すフィルター ボックスが表示され、一致するトレース ログが強調表示されます。
フィルター・ボックスにカーソルを合わせて「 タイプでフィルターを使用可能 」を選択すると、一致するトレース・ログのみが表示されます。 「X」クリアボタンを使用して、フィルターをクリアします。
Application Insights トレース ログの詳細
Azure Application Insights トレースを選択すると、拡張機能によって Application Insights の詳細 ウィンドウが開き、次の情報が表示されます。
- Application Insights - ポリシー名、関連付け ID、Azure Application Insights トレース ID、トレース タイムスタンプなど、トレース ログに関する一般的な情報。
- 技術プロファイル - トレースログに表示される技術プロファイルのリスト。
-
要求 - トレース ログに表示される要求とその値のアルファベット順の一覧。 要求が異なる値でトレース ログに複数回表示される場合は、
=>
記号で最新の値を示します。 これらの要求を確認して、予想される要求値が正しく設定されているかどうかを判断できます。 たとえば、クレーム値をチェックする前提条件がある場合、クレームセクションは、予想されるフローが異なる動作をする理由を判断するのに役立ちます。 - 要求変換 - トレース ログに表示される要求変換の一覧。 各要求変換には、入力要求、入力パラメーター、および出力要求が含まれます。 請求変換セクションでは、送信されたデータと請求変換の結果に関する分析情報を提供します。
- トークン - トレース ログに表示されるトークンの一覧。 トークンには、基になるフェデレーション OAuth と OpenId Connect ID プロバイダーのトークンが含まれます。 フェデレーション ID プロバイダーのトークンは、ID プロバイダーが要求を Azure AD B2C に返す方法の詳細を提供し、ID プロバイダーの技術プロファイル出力要求をマップできるようにします。
- [例外] - トレース・ログに表示される例外または致命的なエラーのリスト。
- Application Insights JSON - Application Insights から返される生データ。
次のスクリーンショットは、Application Insights トレース ログの詳細ウィンドウの例を示しています。
JWT のトラブルシューティング
JWT の検証とデバッグの目的で、 https://jwt.ms のようなサイトを使用して JWT をデコードできます。 トークン検査のために https://jwt.ms
にリダイレクトできるテスト アプリケーションを作成します。 まだ行っていない場合は、 Web アプリケーションを登録して、 ID トークンの暗黙的な許可を有効にします。
[今すぐ実行] と [https://jwt.ms
] を使用して、ウェブ アプリケーションやモバイル アプリケーションとは無関係にポリシーをテストします。 この Web サイトは、依存パーティアプリケーションとして機能します。 Azure AD B2C ポリシーによって生成される JSON Web トークン (JWT) の内容が表示されます。
SAML プロトコルのトラブルシューティング
サービスプロバイダーとの統合の設定とデバッグに役立てるために、SAML プロトコルのブラウザ拡張機能 (Chrome の SAML DevTools 拡張機能 、Firefox の SAML-tracer 、 Edge や Internet Explorer の開発者ツールなど) を使用できます。
次のスクリーンショットは、SAML DevTools 拡張機能が Azure AD B2C が ID プロバイダーに送信する SAML 要求と SAML 応答を表示する方法を示しています。
これらのツールを使用すると、アプリケーションと Azure AD B2C の統合を確認できます。 例えば次が挙げられます。
- SAML 要求に署名が含まれているかどうかを確認し、承認要求のサインインに使用されるアルゴリズムを決定します。
- Azure AD B2C がエラー メッセージを返すかどうかを確認します。
- アサーション セクションが暗号化されているかどうかを確認します。
- ID プロバイダーを返す要求の名前を取得します。
Fiddler を使用して、クライアント ブラウザーと Azure AD B2C との間のメッセージの交換をトレースすることもできます。 これは、ユーザー体験がオーケストレーション ステップのどこで失敗しているかを示すのに役立ちます。
ポリシーの有効性のトラブルシューティング
ポリシーの開発が完了したら、ポリシーを Azure AD B2C にアップロードします。 ポリシーに問題がある可能性がありますが、アップロードする前にポリシーを検証できます。
カスタム ポリシーの設定で最も一般的なエラーは、XML の形式が正しくありません。 優れたXMLエディタは、ほぼ不可欠です。 XML をネイティブに表示し、コンテンツを色分けし、一般的な用語を事前入力し、XML 要素のインデックスを作成し、XML スキーマに対して検証できます。
Visual Studio Code を使用することをお勧めします。 次に、 Red Hat の XML 言語サポートなどの XML 拡張機能をインストールします。 XML 拡張機能を使用すると、カスタム ポリシー XSD スキーマ定義を使用して、XML ファイルをアップロードする前に XML スキーマを検証できます。
XML ファイルの関連付け戦略を使用して XML ファイルを XSD にバインドするには、VS Code settings.json
ファイルに次の設定を追加します。 これを行うには、次の手順を実行します。
VS Code から、 File(ファイル)>Preferences>Settings(設定)を選択します。 詳細については、「 ユーザーとワークスペースの設定」を参照してください。
fileAssociationsを検索し、 [拡張子] で XML を選択します。
「 settings.jsonで編集 」を選択します。
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" } ]
変更を保存します。
次の例は、XML 検証エラーを示しています。 要素名の上にマウスを移動すると、拡張機能に予想される要素が一覧表示されます。
次の場合は、 DisplayName
要素が正しいです。 しかし、順番が間違っています。
DisplayName
は Protocol
要素の前に配置する必要があります。 この問題を解決するには、マウスを DisplayName
要素の上に移動して、要素の正しい順序にします。
アップロード ポリシーとポリシーの検証
XML ポリシー・ファイルの検証は、アップロード時に自動的に実行されます。 ほとんどのエラーにより、アップロードは失敗します。 検証には、アップロードするポリシー・ファイルが含まれます。 また、アップロード ファイルが参照するファイルのチェーン (証明書利用者ポリシー ファイル、拡張ファイル、および基本ファイル) も含まれます。
ヒント
Azure AD B2C は、証明書利用者ポリシーの追加の検証を実行します。 ポリシーに問題がある場合は、拡張ポリシーのみを編集する場合でも、証明書利用者ポリシーもアップロードすることをお勧めします。
このセクションでは、一般的な検証エラーと考えられる解決策について説明します。
スキーマ検証エラーが見つかりました...無効な子要素 '{name}' があります
ポリシーに無効な XML 要素が含まれているか、XML 要素は有効であるが順序が正しくないようです。 このタイプのエラーを修正するには、「 ポリシーの有効性のトラブルシューティング 」セクションを確認してください。
重複するキー シーケンス '{number}' があります
ユーザー 体験 または サブ体験 は、順番に実行されるオーケストレーション ステップの順序付きリストで構成されます。 ジャーニーを変更した後、1 から N までの整数をスキップせずに、ステップの番号を順番に付け直します。
ヒント
Azure AD B2C extension for VS Code(Shift+Ctrl+r)
コマンドを使用して、ポリシー内のすべてのユーザー体験とサブ体験のオーケストレーション ステップの番号を付け直すことができます。
...順序が "{number}" の手順が想定されていますが、見つかりませんでした...
前のエラーを確認してください。
ユーザー体験 "{name}" のオーケストレーション手順の順序 "{number}"...は、後にクレーム プロバイダー選択手順が続き、要求の交換である必要がありますが、型は...
オーケストレーション ステップの種類は ClaimsProviderSelection
で、 CombinedSignInAndSignUp
には、ユーザーが選択できるオプションの一覧が含まれています。 この後には、1 つまたは複数の要求の交換を行う ClaimsExchange
型が続く必要があります。
次のオーケストレーション手順では、この種類またはエラーが発生します。 2 番目のオーケストレーション ステップは、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
または ClaimsProviderSelection
でない限り、CombinedSignInAndSignUp
1 つが必要です。 次のオーケストレーション手順では、この種類のエラーが発生します。 6 番目のステップには、2 つのクレーム交換が含まれています。
<!--
<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> -->
この種類のエラーを修正するには、2 つのオーケストレーション手順を使用します。 オーケストレーションの各ステップには、1 つの要求の交換を使用します。
<!--
<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}' があります
ユーザー体験に同じ ClaimsExchange
を持つ複数の Id
があります。 次の手順では、このタイプのエラーが発生します。 ID AADUserWrite は、ユーザー体験で 2 回表示されます。
<!--
<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> -->
この種類のエラーを修正するには、オーケストレーションの 8 番目のステップの要求交換を一意の名前 ( 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> -->
...id "{claim name}" で ClaimType を参照しますが、ポリシーにもその基本ポリシーにもそのような要素は含まれていません。
この種類のエラーは、 ポリシーが要求スキーマで宣言されていない要求を参照している場合に発生します。 要求は、ポリシー内の少なくとも 1 つのファイルで定義されている必要があります。
たとえば、 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> -->
ID... を持つ ClaimsTransformation への参照が作成されます...
このエラーの原因は、要求エラーの原因と似ています。 前のエラーを確認してください。
ユーザーは現在、'yourtenant.onmicrosoft.com' テナントのユーザーとしてログインしています...
アップロードしようとするポリシーとは異なるテナントのアカウントでサインインします。 たとえば、 admin@contoso.onmicrosoft.com でサインインし、ポリシー TenantId
が fabrikam.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>
-
TenantId
要素と<TrustFrameworkPolicy\>
要素の<BasePolicy\>
値が、ターゲットの 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>
この種類のエラーを修正するには、出力要求が少なくとも 1 つのオーケストレーション ステップの技術プロファイル出力要求コレクションに表示されていることを確認します。 ユーザー ジャーニーでクレームを出力できない場合は、証明書利用者の技術プロファイルで、例えば空の文字列のような既定値を設定します。
<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}" には、ID が "{name}" のポリシーが既にあります。 同じ ID を持つ別のポリシーを保存できません
テナントにポリシーをアップロードしようとしましたが、同じ名前のポリシーが既にテナントにアップロードされています。
このタイプのエラーを修正するには、ポリシーをアップロードするときに、[ カスタムポリシーがすでに存在する場合は上書きする ] チェックボックスをオンにします。