استكشاف أخطاء Microsoft Azure Active Directory B2C المستخدمين والتدفقات النهج المخصصة

مقالة
04/21/2022
قراءة خلال 13 دقائق

قبل أن تبدأ، استخدم المنتقي Choose a policy type لاختيار نوع السياسة التي تقوم بإعدادها. يوفر Azure Active Directory B2C طريقتين لتحديد كيفية تفاعل المستخدمين مع تطبيقاتك: من خلال تدفقات محددة مسبقا للمستخدمين أو من خلال سياسات مخصصة قابلة للتكوين بشكل كامل. تختلف الخطوات المطلوبة في هذه المقالة لكل أسلوب.

يحتاج تطبيقك إلى معالجة أخطاء معينة قادمة من خدمة Azure B2C. تسلط هذه المقالة الضوء على بعض الأخطاء الشائعة وكيفية التعامل معها.

خطأ في إعادة تعيين كلمة المرور

يحدث هذا الخطأ عندما لا يتم تمكين self-service password reset experience في تدفق المستخدم. وبالتالي، فإن تحديد الرابط ?Forgot your password لا يؤدي إلى تدفق إعادة تعيين كلمة المرور للمستخدم. بدلاً من ذلك، يتم إرجاع رمز الخطأ AADB2C90118 إلى التطبيق الخاص بك.

يوجد حلان لهذه المشكلة:

الرد بطلب مصادقة جديد باستخدام تدفق مستخدم إعادة تعيين كلمة مرور Microsoft Azure Active Directory B2C.
استخدام التجربة الموصى بها لاختبار كلمة مرور الخدمة الذاتية (SSPR).

ألغى المستخدم العملية

يمكن لخدمة Microsoft Azure Active Directory B2C أيضاً إرجاع خطأ إلى التطبيق الخاص بك عندما يقوم المستخدم بإلغاء عملية. فيما يلي أمثلة على السيناريوهات التي يقوم فيها المستخدم بعملية إلغاء:

تستخدم نهج المستخدم التجربة الموصى بها لاختبار كلمة مرور الخدمة الذاتية (SSPR) مع حساب المستهلك المحلي. يحدد المستخدم الرابط ?Forgot your password، ثم يحدد الزر Cancel قبل اكتمال تجربة تدفق المستخدم. في هذه الحالة، تقوم خدمة Microsoft Azure Active Directory B2C بإرجاع رمز الخطأ AADB2C90091 إلى التطبيق الخاص بك.
يختار المستخدم المصادقة مع موفر هوية خارجي مثل LinkedIn. حدد المستخدم الزر Cancel قبل المصادقة إلى موفر الهوية نفسه. في هذه الحالة، تقوم خدمة Microsoft Azure Active Directory B2C بإرجاع رمز الخطأ AADB2C90273 إلى التطبيق الخاص بك. تعرف على المزيد حول رموز الخطأ التي ترجعها خدمة Microsoft Azure Active Directory B2C.

لمعالجة هذا الخطأ، أحضر error description للمستخدم ورد مرة أخرى بطلب مصادقة جديد باستخدام نفس تدفق المستخدم.

إذا كنت تستخدم النُّهج المخصصة لدى Azure Active Directory B2C (Microsoft Azure Active Directory B2C)، فقد تواجه تحديات في استخدام تنسيق XML للغة النهج أو مشكلات تتعلق بوقت التشغيل. توضح هذه المقالة بعض الأدوات والنصائح التي يمكن أن تساعدك على اكتشاف المشكلات وحلها.

تركز هذه المقالة على استكشاف أخطاء تكوين النهج المخصص لدى Microsoft Azure Active Directory B2C. لا تتناول تطبيق جهة الاعتماد أو مكتبة الهوية الخاصة به.

نظرة عامة على معرف ارتباط Microsoft Azure Active Directory B2C

معرف ارتباط B2C AD Azure هو قيمة معرف فريدة مرفقة بطلبات التخويل. تمر عبر كافة خطوات التزامن التي يتم أخذها من خلال مستخدم. باستخدام معرف الارتباط، يمكنك:

تحديد نشاط تسجيل الدخول في التطبيق وتتبع أداء النهج.
ابحث عن سجلات Azure Application Insights لطلب تسجيل الدخول.
مرر معرف الارتباط إلى واجهة برمجة تطبيقات REST واستخدمه لتحديد تدفق تسجيل الدخول.

يتم تغيير معرف الارتباط في كل مرة يتم تقديم جلسة عمل جديدة. عند تصحيح أخطاء النهج الخاصة بك، تأكد من إغلاق علامات تبويب المتصفح الموجودة أو افتح متصفح وضع خاص جديد.

استدعاء معرف ارتباط Microsoft Azure Active Directory B2C

يمكنك العثور على معرف الارتباط في صفحة الاشتراك أو تسجيل الدخول في Microsoft Azure Active Directory B2C. في المتصفح الخاص بك، حدد view source. يظهر الارتباط كتعليق في أعلى الصفحة.

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

قم بنسخ معرف الارتباط، ثم قم بمتابعة تدفق تسجيل الدخول. استخدم معرف الارتباط لمراقبة سلوك تسجيل الدخول. لمزيد من المعلومات، راجع استكشاف أخطاء Application Insights وإصلاحها.

صدى معرف ارتباط Microsoft Azure Active Directory B2C

يمكنك تضمين معرف الارتباط في رموز Microsoft Azure Active Directory B2C المميزة. لتضمين معرف الارتباط:

افتح ملف الملحقات للنهج الخاص بك. على سبيل المثال، ⁧SocialAndLocalAccounts/TrustFrameworkExtensions.xml⁩.
ابحث عن عنصر BuildingBlocks. إذا لم يكن العنصر موجودًا، فقم بإضافته.
حدد موقع العنصر ClaimsSchema. إذا لم يكن العنصر موجودًا، قم بإضافته.

أضف مطالبة معرف الارتباط للعنصر 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 ومختلف موفري المطالبات التي يتم تحديدها من قِبل ملفات التعريف التقنية، مثل موفري الهوية والخدمات المستندة إلى API ودليل مستخدمي Microsoft Azure Active Directory B2C والخدمات الأخرى.

نوصي بتثبيت ملحق Microsoft Azure Active Directory B2C لـ VS Code. مع ملحق B2C AD Azure، يتم تنظيم السجلات لك حسب اسم النهج ومعرف الارتباط (Application Insights يعرض الرقم الأول من معرف الارتباط) والطابع الزمني للسجلات. تساعدك هذه الميزة في العثور على السجل ذي الصلة استنادًا إلى الطابع الزمني المحلي وعرض رحلة المستخدم كما تم تنفيذها بواسطة Microsoft Azure Active Directory B2C.

ملاحظة

هناك تأخير قصير، عادة أقل من خمس دقائق، قبل أن تتمكن من عرض سجلات جديدة في Application Insights.
لقد طور المجتمع ملحق Visual Studio Code لـ Microsoft Azure Active Directory B2C لمساعدة مطوري الهوية. الملحق غير معتمد من قِبل Microsoft ويتم توفيرها بشكل صارم كما هو.

يمكن أن يصدر تدفق تسجيل دخول واحد أكثر من تتبع واحد لـ Azure Application Insights. في لقطة الشاشة التالية، لدى نهج B2C_1A_signup_signin ثلاثة سجلات. يمثل كل سجل جزءًا من تدفق تسجيل الدخول.

تظهر لقطة الشاشة التالية ملحق Microsoft Azure Active Directory B2C لـ VS Code مع مستكشف تتبع Azure Application Insights.

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

تصفية سجل التتبع

مع التركيز على مستكشف التتبع Microsoft Azure Active Directory B2C، ابدأ بكتابة الرقم الأول من معرف الارتباط، أو الوقت الذي تريد العثور عليه. سترى مربع تصفية في أعلى يمين مستكشف التتبع Microsoft Azure Active Directory B2C يعرض ما كتبته حتى الآن، وسيتم تمييز سجلات التتبع المتطابقة.

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

سيؤدي التمرير فوق مربع التصفية وتحديد تمكين عامل التصفية على النوع إلى إظهار سجلات التتبع المتطابقة فقط. استخدم زر 'X' Clear لمسح عامل التصفية.

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

تفاصيل سجل تتبع Application Insights

عند تحديد تتبع Azure Application Insights، يفتح الملحق إطار تفاصيل Application Insights بالمعلومات التالية:

Application Insights - معلومات عامة حول سجل التتبع، بما في ذلك اسم النهج معرف الارتباط ومعرّف تتبع Azure Application Insights والطابع الزمني.
ملفات التعريف الفنية - قائمة التشكيلات الفنية التي تظهر في سجل التتبع.
المطالبات - القائمة الأبجدية للمطالبات التي تظهر في سجل التتبع وقيمها. إذا ظهرت مطالبة في سجل التتبع عدة مرات بقيم مختلفة، تعين علامة => أحدث قيمة. يمكنك مراجعة هذه المطالبات لتحديد ما إذا تم تعيين قيم المطالبة المتوقعة بشكل صحيح. على سبيل المثال، إذا كان لديك شرط مسبق يتحقق من قيمة المطالبة، في حين يمكن أن يساعدك قسم المطالبات في تحديد سبب عمل التدفق المتوقع بشكل مختلف.
تحويل المطالبات - قائمة تحويلات المطالبات التي تظهر في سجل التتبع. يحتوي كل تحويل مطالبات على مطالبات الإدخال ومعلمات الإدخال ومطالبات الإخراج. ويعطي قسم تحويل المطالبات تفاصيل على البيانات المرسلة ونتائج تحويل المطالبات.
الرموز المميزة - قائمة الرموز المميزة التي تظهر في سجل التتبع. تتضمن الرموز المميزة OAuth الموحد الأساسي ورموز مميزة لموفري هوية OpenId Connect. يعطي الرمز المميز لموفري الهوية الموحد تفاصيل حول كيفية إرجاع موفر الهوية للمطالبات إلى Microsoft Azure Active Directory B2C حتى تتمكن من تعيين مطالبات إخراج ملف التعريف التقني لموفر الهوية.
استثناءات - قائمة الاستثناءات أو الأخطاء الفادحة التي تظهر في سجل التتبع.
Application Insights JSON - البيانات الأولية المرتجعة من Application Insights.

تظهر لقطة الشاشة التالية مثالًا على إطار تفاصيل سجل تتبع Application Insights.

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

استكشاف أخطاء رموز JWT المميزة وإصلاحها

لأغراض التحقق من صحة الرمز المميز JWT وتصحيح الأخطاء، يمكنك فك تشفير رموز JWT المميزة باستخدام موقع مثل https://jwt.ms. إنشاء تطبيق اختبار يمكنه إعادة توجيه إلى https://jwt.ms لفحص الرمز المميز. إذا لم تكن قد فعلت ذلك بالفعل، سجّل تطبيق الويب، ووتمكين المنح المضمن لرمز التعريف.

Screenshot of JWT token preview.

استخدم تشغيل الآن وhttps://jwt.ms لاختبار نهجك بشكل مستقل عن تطبيق الويب أو الجوال. يعمل هذا الموقع مثل تطبيق جهة اعتماد. يعرض محتويات الرمز المميز للويب JSON (JWT) الذي يتم إنشاؤه بواسطة نهج Microsoft Azure Active Directory B2C.

استكشاف أخطاء بروتوكول SAML وإصلاحها

للمساعدة في تكوين وتصحيح التكامل مع مزود الخدمة الخاص بك، يمكنك استخدام ملحق متصفح لبروتوكول SAML، على سبيل المثال، ملحق SAML DevTools لـ Chrome، أو SAML-tracer لـ FireFox، أو Edge أو أدوات IE Developer.

توضح لقطة الشاشة التالية كيفية لملحق SAML DevTools أن يقدم طلب SAML الذي يرسله Microsoft Azure Active Directory B2C إلى موفر الهوية واستجابة SAML.

Screenshot of SAML protocol trace log.

باستخدام هذه الأدوات، يمكنك التحقق من التكامل بين التطبيق الخاص بك وMicrosoft Azure Active Directory B2C. على سبيل المثال:

تحقق مما إذا كان طلب SAML يحتوي على توقيع وحدد الخوارزمية المستخدمة لتسجيل الدخول في طلب التفويض.
تحقق مما إذا كان Microsoft Azure Active Directory B2C يُرجع رسالة خطأ.
تحقق مما إذا كان مقطع التأكيد مشفرًا.
استدعاء اسم المطالبات التي تُرجع موفر الهوية.

يمكنك أيضا تتبع تبادل الرسائل بين متصفح العميل وMicrosoft Azure Active Directory B2C، مع Fiddler. يمكن أن تساعدك في الحصول على إشارة إلى أين تفشل رحلتك في خطوات التزامن الخاصة بك.

استكشاف أخطاء صلاحية النهج وإصلاحها

بعد الانتهاء من تطوير النهج الخاص بك، يمكنك تحميل النهج إلى Microsoft Azure Active Directory B2C. قد يكون هناك بعض المشكلات مع نهجك. استخدم الطرق التالية لضمان تكامل البيانات/صلاحية النهج الخاص بك.

الخطأ الأكثر شيوعًا في إعداد النهج المخصصة هو XML منسق بشكل غير صحيح. محرر XML جيد أمر ضروري تقريبًا. يعرض أصالة XML، ومحتوى رموز الألوان، وتعبئة المصطلحات الشائعة مسبقًا، ويحتفظ عناصر XML المفهرسة، ويمكن التحقق من الصحة مقابل مخطط XML.

نوصي باستخدام Visual Studio Code. ثم قم بتثبيت ملحق XML، مثل دعم لغة XML باستخدام Red Hat. ملحق XML يمكنك من التحقق من صحة مخطط XML قبل تحميل ملف XML الخاص بك باستخدام تعريف مخطط XSD للنهج المخصص.

يمكنك استخدام استراتيجية إقران ملف XML لربط ملف XML XSD بإضافة الإعدادات التالية إلى ملف VS Code settings.json. للقيام بذلك:

من VS Code، انقر فوق Settings. لمزيد من المعلومات، راجع إعدادت مساحة العمل والمستخدم.
ابحث عن fileAssociations، ثم ضمن Extension، حدد XML.
حدد Edit in settings.json.

في settings.js، أشف التعليمات البرمجية 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. عند تحريك الماوس فوق اسم العنصر تكون قائمة الملحقات هي العناصر المتوقعة.

Screenshot of VS Code XML schema validation error indicator.

في الحالة التالية، العنصر DisplayName صحيح. ولكنه، في الترتيب الخاطئ. يجب أن يكون DisplayName قبل العنصر Protocol. لإصلاح المشكلة، حرك الماوس فوق العنصر DisplayName إلى الترتيب الصحيح للعناصر.

Screenshot of VS Code XML schema validation order error.

تحميل النهج والتحقق من صحتها

يتم إجراء التحقق من صحة ملف نهج XML تلقائيًا عند التحميل. تتسبب معظم الأخطاء في فشل التحميل. يتضمن التحقق من الصحة ملف النهج الذي تقوم بتحميله. كما يتضمن سلسلة الملفات التي يشير إليها ملف التحميل (ملف نهج جهة الاعتماد، وملف الملحقات، والملف الأساسي).

تلميح

يقوم Microsoft Azure Active Directory B2C بتشغيل التحقق من صحة إضافية لنهج جهة الاعتماد. عند وجود مشكلة في نهجك، حتى إذا قمت بتحرير نهج الملحقات فقط، فمن الممارسات الجيدة تحميل نهج جهة الاعتماد أيضًا.

يحتوي هذا القسم على أخطاء التحقق من الصحة الشائعة والحلول المحتملة.

تم العثور على خطأ التحقق من صحة المخطط ... يحتوي على عنصر تابع غير صالح '{name}'

يحتوي النهج الخاص بك على عنصر XML غير صالح أو عنصر XML صالح، ولكنه يبدو أنه في الترتيب غير الصحيح. لإصلاح هذا النوع من الأخطاء، راجع قسم صلاحية نهج استكشاف الأخطاء وإصلاحها.

هناك تسلسل مفتاحي مكرر '{number}'

تتكون الرحلة أو الرحلة الفرعية من قائمة مرتبة من خطوات التزامن التي يتم تنفيذها في التسلسل. بعد تغيير رحلتك، أعد ترقيم الخطوات بشكل تسلسلي دون تخطي أي أعداد صحيحة من 1 إلى N.

تلميح

يمكنك استخدام ملحق Microsoft Azure Active Directory B2C للأمر VS Code(Shift+Ctrl+r) لإعادة ترقيم جميع رحلات المستخدم وخطوات تنسيق الرحلات الفرعية في سياستك.

... كان من المتوقع أن يكون خطوة بالترتيب "{number}" ولكن لم يتم العثور عليه...

تحقق من الخطأ السابق.

ترتيب خطوة التزامن "{number}" في الرحلة "{name}" ... يُتبع بخطوة اختيار موفر المطالبات ويجب أن يكون تبادل المطالبات، لكنه من نوع ...

نوع خطوات التزامن من 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} مع اثنين من تبادل المطالبات. يجب أن يسبقها اختيار موفر المطالبات من أجل تحديد أي تبادل للمطالبات التي يمكن استخدامها

خطوة التزامن من نوع ClaimsExchange يجب أن تكون بـ ClaimsExchange واحد، ما لم تكن الخطوة السابقة هي نوع من ClaimsProviderSelection أو CombinedSignInAndSignUp. تتسبب خطوات التزامن التالية في حدوث هذا النوع من الأخطاء. الخطوة السادسة تحتوي على اثنين بتبادل المطالبات.

<!-- 
<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}'

الرحلة لها عدة ClaimsExchange مع Id ذاته. الخطوات التالية تسبب هذا النوع من الخطأ. المعرف 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> -->

... يجعل مرجع ClaimType مع معرف "{claim name}" ولكن لا النهج ولا أي من النهج الأساسية الخاصة به تحتوي على مثل هذا العنصر

يحدث هذا النوع من الأخطاء عندما يقوم النهج الخاص بك بالرجوع إلى مطالبة لم يتم إعلانها في مخطط المطالبات. يجب تحديد المطالبات في واحد على الأقل من الملفات في النهج.

على سبيل المثال، ملف تعريف فني مع مطالبة إخراج 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'...

يمكنك تسجيل الدخول بحساب من مستأجر يختلف عن النهج الذي تحاول تحميله. على سبيل المثال، تسجيل الدخول باستخدام 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\> تطابق مستأجر Microsoft Azure Active Directory B2C المستهدف.

نوع المطالبة "{name}" هي مطالبة إخراج لملف التعريف التقني لجهة الاعتماد، ولكنه ليس مطالبة إخراج في أي من خطوات الرحلة...

في نهج جهة اعتماد، قمت بإضافة مطالبة إخراج، ولكن مطالبة الإخراج ليست مطالبة إخراج في أي من خطوات الرحلة. لا يمكن لـ Microsoft Azure Active Directory 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.

الخطوات التالية

تعلم كيفية جمع سجلات Azure Active Directory B2C باستخدام Application Insights.