أستكشاف أخطاء مزامنة هوية المستخدم/المجموعة وإصلاحها في Cisco Secure Access مع DIFF IDP

مسألة

يصف هذا المستند كيفية أستكشاف أخطاء مزامنة هوية المستخدم والمجموعة وإصلاحها في Cisco Secure Access مع موفري هوية مختلفين (IDs) مثل OKTA و Microsoft Entra ID و IBM Cloud.

البيئة

• الوصول الآمن من Cisco — تكامل إمداد SCM

• ينطبق على موصل SCIM 2.0 IDp (OKTA، Azure AD)

قرار

نظرة عامة

يدعم Cisco Secure Access توفير هويات المستخدمين والمجموعات مباشرة من OKTA و Microsoft Entra ID (المعروف سابقا باسم Azure AD) باستخدام معيار SCM 2.0، الذي يزيل الحاجة لنشر موصل Active Directory (AD) محلي لمصادر الهوية الخاصة بالسحابة فقط. تعمل هذه المقالة على دمج افتراضات البنية وأساليب الفشل الشائعة وإرشادات أستكشاف المشكلات وإصلاحها التي يواجهها المهندسون والمسؤولون الميدانيون غالبا عند نشر هذا الدمج أو الحفاظ عليه.

ينقسم هذا المستند إلى أربعة أقسام:

• التكوين — أين يمكن الذهاب لتعليمات الإعداد الرسمي

• افتراضات الهندسة المعمارية التي تتسبب في الإخفاقات الصامتة أو التي يصعب تشخيصها

• المشاكل الخاصة بالمزود (Okta مقابل معرف Entra)

• مشاكل بروتوكول SCM العام التي تنطبق بغض النظر عن IdP

التكوين

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

• أحلت in order to شكلت Cisco Secure Access مع Microsoft Entra ID (Azure AD)، هذا خطوة: تزويد المستخدمين والمجموعات بإمكانية الوصول الآمن عبر معرف Entra

• أحلت in order to شكلت cisco يأمن منفذ مع OKTA، هذا خطوة: تزويد المستخدمين والمجموعات بالوصول الآمن عبر OKTA

يغطي كلا المستندين إنشاء رمز SCIM المميز ومحدد موقع المعلومات (URL) للتوفير في Secure Access، وتكوين التطبيق المتوافق في IdP، وتشغيل مزامنة الإمداد الأولية.

عمارة بريمر

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

مصدر هوية واحد في كل مرة

التوفير المتزامن لنفس المستخدمين أو المجموعات من موصل AD محلي ومعرف Cloud Id (Okta أو Entra ID) غير مدعوم ويؤدي إلى تنفيذ نهج غير متناسق. إذا قمت بالترحيل من موصل AD إلى معرف مجموعة النظراء:

• قم بإيقاف خدمة AD Connector المحلية.

• تأكد من عدم وجود مهام مزامنة متبقية قيد التشغيل قبل تمكين تزويد IdP للسحابة.

أما الأجهزة الظاهرية فهي الاستثناء

لا يمكن لمعرف Entra أو OKTA توفير تكامل الهوية للأجهزة الظاهرية (VAs)، نظرا لأن معرف P ليس له إمكانية رؤية في تعيينات IP إلى المستخدم الخاصة، والتي تتطلب VAs. لا تزال عمليات نشر VA بحاجة إلى موصل AD محلي بغض النظر عن ما يتم إستخدامه للمكونات الأخرى.

التعيين مقابل الدفع

• الإجراء: تعيين مستخدمين أو مجموعات للتطبيق

  • ما تقوم به: توفير المستخدمين الأعضاء لتلك المجموعة لتأمين الوصول

• الإجراء: دفع مجموعة (OKTA)

  • ما تقوم به: الأحكام التي يعترض عليها الفريق نفسه (لاستهداف السياسة). لا يقوم بمزامنة أي مستخدمين.

حدود المجموعة والمستخدم

لا يوجد حد ثابت لعدد المستخدمين الموفرين من أي من معرفات.

المجموعات لها حدود قصوى. وتاريخيا، كانت هذه 200 مجموعة لكل منظمة من معرف أوكتا أو إنترا؛ وتبين بعض الوثائق الحالية أن هناك حدا أقصى أعلى (يصل إلى 1 000) بالنسبة إلى أوكتا تحديدا. تعامل مع الرقم الدقيق على أنه مستقل عن البيئة وتأكد باستخدام مركز المساعدة التقنية (TAC) من Cisco أو وثائق Cisco الحالية. لا يتم توفير المجموعات التي تتجاوز الحد الأقصى بصمت، ولا يظهر أي خطأ.

إذا كنت بحاجة إلى تغطية أوسع، أستخدم مجموعة "جميع المستخدمين" (معرف Entra) أو "الجميع" (OKTA) بدلا من محاولة دفع كل مجموعة بشكل فردي.

دورة حياة الرمز المميز ل SCM

في Cisco Secure Access، يتم إنشاء الرموز المميزة عندما تختار Connect > المستخدمين، المجموعات وأجهزة نقطة النهاية > إدارة التكوين > دليل التكامل. يتم عرض الرمز المميز مرة واحدة فقط عند الإنشاء.

عند إعادة إنشاء الرمز المميز، فإنه يوقف التشغيل على الفور للتوفير على جانب IdP حتى يتم إدخال الرمز المميز الجديد في تكوين التوفير لمعرف Microsoft Entra أو Okta. لا توجد فترة سماح، وغالبا ما يكون خطأ جانب IdP عاما (فشل المصادقة) بدلا من رسالة الرمز المميز منتهية الصلاحية.

قم بتحديث الرمز المميز بشكل دوري لنظافة الأمان واختبار الاتصال على جانب IdP مباشرة بعد الدوران.

المسائل الخاصة بأوكتا

• العرض: لا تظهر المجموعات في Secure Access

  • السبب الجذري: يؤدي دفع مجموعة إلى حكم كائن المجموعة فقط؛ لا يقوم بمزامنة الأعضاء.

  • الدقة: التأكد من تعيين أعضاء المجموعة المعنيين بشكل منفصل في الطلب بموجب التعيينات.

• العرض: تم توفير المستخدمين ولكن السمات مفقودة أو خاطئة

  • السبب الجذري: لا ينطبق اسم العرض واسم المستخدم إلا على Secure Access؛ لم يتم إدراج أسماء "معطى" و"عائلة".

  • الدقة: تأكيد السمات المطلوبة محددة بشكل صريح للمزامنة؛ لا يفترض أن كافة حقول ملف تعريف Okta يتم نشرها.

• العرض: لا يؤدي التوفير بصمت إلى أي شيء

  • السبب الجذري: لم يتم تمكين "إنشاء مستخدمين" أو "تحديث سمات المستخدم" أو "إلغاء تنشيط تبديل المستخدمين".

  • الدقة: دققت كل ثلاثة فحصت تحت التزويد > إلى تطبيق في ال OKTA مدير وحدة طرفية للتحكم.

• العرض: ObjectGUID أو السمة المخصصة التي لا تتزامن

  • السبب الجذري: لا تتم إضافة السمة وتخصيصها من خلال تعيين ملف تعريف المستخدم.

  • الدقة: أضف سمة objectGUID وقم بإنشاء تعيين ملف التعريف المطابق إذا كان هذا المعرف مطلوبا.

• العرض: توقفت المزامنة بعد دوران الرمز المميز

  • السبب الجذري: تم إعادة إنشاء الرمز المميز ل SCM أو API في Secure Access ولكن لم يتم تحديثه في Okta.

  • الدقة: أدخل الرمز المميز الجديد تحت التوفير > تكوين تكامل واجهة برمجة التطبيقات (API) وشغل بيانات اعتماد واجهة برمجة التطبيقات للاختبار مرة أخرى.

• العرض: لا يمكن تحديد سبب فشل مستخدم أو مجموعة معينة

  • السبب الجذري: لم يتم فحص السجلات أولا.

  • الدقة: تحقق من التقارير > سجل النظام في OKTA، الذي تمت تصفيته إلى تطبيق Cisco User Management Connector، قبل أن تقوم بالتصعيد.

• العرض: يتجاوز عدد المجموعات الحد الأقصى، بعضها مفقود بدون أخطاء

  • السبب الجذري: تحتوي المؤسسة على مجموعات في نطاق أكبر من مجموعات دعم الوصول الآمن.

  • الدقة: قم بتقليل النطاق إلى المجموعات ذات الصلة بالسياسات فقط، أو قم بإشراك Cisco TAC للحصول على دعم مجموعة أعلى مستوى.

المشاكل الخاصة بمعرف Microsoft Entra

• العرض: لا تعكس عضوية المجموعة الديناميكية في ميزة الوصول الآمن

  • السبب الجذري: قاعدة المجموعة الديناميكية غير مكونة بشكل صحيح، أو أن المجموعة ليست في النطاق المزود.

  • الدقة: تحقق من صحة قاعدة العضوية الديناميكية مباشرة في معرف Entra قبل افتراض خطأ مزامنة الوصول الآمن.

• العرض: توقع SAML SSO تشغيل هوية SWG

  • السبب الجذري: لا يدعم AnyConnect Secure Web Gateway (SWG) مصادقة لغة تمييز تأكيد الأمان (SAML) مقابل معرف Entra؛ وهو يستخدم نفس آلية المصادقة الخاملة مثل AD المحلي.

  • الدقة: لا تصمم حول SAML-Driven SWG هوية لمعرف Entra؛ أستخدم المصادقة السلبية كموثقة.

• العرض: يظهر المستخدم بشكل غير صحيح إلغاء التنشيط

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

  • الدقة: تحقق ما إذا كان قد تمت إزالة المستخدم من مجموعة ذات نطاق؛ تحقق من التعيين النشط (يجب عادة التقييم على أنه NOT([isSoftDelete])).

• العرض: تم عزل التطبيق وتوقف جميع عمليات الإمداد

  • السبب الجذري: قام التطبيق الهدف بإرجاع استجابات متكررة غير متوافقة مع SCIM.

  • الدقة: تحقق من حالة توفير تطبيق المؤسسة لعلامة عزل قبل أن تفترض حدوث حالات فشل فردية للمستخدم.

• العرض: فشل دورة الإمداد الأولية بشكل تام

  • السبب الجذري: فشل المزامنة العابرة في التشغيل الأول.

  • الدقة: انقر فوق إعادة تشغيل التوفير من صفحة النظرة العامة لإجبار معرف Entra على محاولة إجراء المزامنة الأولية مرة أخرى.

• العرض: تم دمج المستخدمين المكرر بشكل غير متوقع

  • السبب الجذري: تشترك هويتان مصدرتان في نفس البريد الإلكتروني أو اسم المستخدم الأساسي (UPN).

  • الدقة: ضمان تفرد البريد الإلكتروني و UPN في دليل المصدر؛ تحقق من أن سمة البريد تأتي من مجال تم التحقق منه.

• العرض: توقف السمة عن التحديث بعد تغيير المخطط

  • السبب الجذري: تم تغيير نوع السمة على الجانب الهدف (على سبيل المثال، سلسلة إلى قيمة منطقية) ولكن لم يتم تحديث تعيين معرف Entra.

  • الدقة: تصحيح النوع يدويا في الإعدادات المتقدمة ضمن تعيينات السمات.

• العرض: لا يتم ملء مرجع المدير أبدا

  • السبب الجذري: كان المستخدم في النطاق قبل أن يكون مديره؛ لا يحذف الإمداد تلقائيا.

  • الدقة: إعادة تشغيل الإمداد لفرض إعادة تقييم كاملة لكافة المستخدمين في النطاق.

تحقق أمان IBM من مشاكل محددة

• العرض: توفير المستخدمين ولكن لا تظهر المجموعات أبدا في Secure Access

  • السبب الجذري: تحقق من أن موصل SCM المخصص يصدر عمليات المستخدم فقط؛ لا يتم إرسال مكالمات POST /Groups على الإطلاق (فجوة قدرة تزويد الحساب، وليس خطأ تعيين).

  • الدقة: التقاط تتبع موصل والتحقق مما إذا كانت مكالمات /مجموعات تحدث؛ في حالة عدم وجود أي منها، يتم توفير المجموعات عبر موصل AD من Cisco أو إستيراد CSV أو برنامج نصي مجدول مقابل نقطة نهاية SCM للوصول الآمن.

• العرض: فشل تحديث عضوية المجموعة برقم 400 أو 404

  • السبب الجذري: الأعضاء[]. مراجع القيمة تحقق من معرفات المستخدم الداخلية بدلا من Secure Access الذي تم إرجاعه عند إنشاء المستخدم.

  • الدقة: قم بتصحيح تعيين الأعضاء لاستخدام معرف SCM للوصول الآمن ثم قم بتشغيل مزامنة كاملة مرة أخرى.

• العرض: تظهر المجموعات ولكنها فارغة

  • السبب الجذري: تم الدفع بالمجموعة قبل وجود مستخدميها الأعضاء في Secure Access؛ أشار تصحيح العضوية إلى مستخدمين غير معروفين.

  • الدقة: قم بتشغيل مزامنة كاملة مرة أخرى الآن مع وجود المستخدمين؛ التأكد من أن ترتيب المزامنة يقوم بإنشاء مستخدمين قبل المجموعات.

• العرض: حلقات تسجيل الدخول إلى SAML أو عمليات إعادة التوجيه المتكررة

  • السبب الجذري: تحقق من أن نقطة نهاية IdP تم تمثيلها أو فك تشفيرها بواسطة SWG، والذي يكسر تدفق المصادقة.

  • الدقة: تجاوز محدد موقع معلومات التحقق من IdP من SAML أو فك التشفير (قائمة المجالات الخارجية أو فك التشفير الانتقائي).

• العرض: مصادقة المستخدم عبر SAML ولكن لا توجد تطابقات في النهج المستند إلى المستخدم

  • السبب الجذري: لا يتطابق SAML NameID مع AuthName للمستخدم المزود .

  • الدقة: محاذاة NameID > تنسيق في تطبيق Verify SAML مع تعيين سمة AuthName (عادة بريد إلكتروني أو UPN)؛ قم بالإختبار مرة أخرى.

• العرض: يتوقف الإمداد عن العمل بعد مرور أسابيع أو أشهر من الاستقرار

  • السبب الجذري: تم تدوير الرمز المميز SCIM أو انتهت صلاحيته في Secure Access ولكن لم يتم تحديثه في Verify Connector.

  • الدقة: قم بتحديث الرمز المميز في Secure Access وتحديثه في تطبيق التحقق المخصص؛ تقويم عملية تحديث البيانات.

• العرض: مستخدمون مكرر تم إنشاؤهم عند إعادة المزامنة

  • السبب الجذري: ExternalId المعين لسمة قابلة للتغيير أو سمة غير فريدة (على سبيل المثال، اسم العرض، البريد الإلكتروني القابل للتغيير).

  • الدقة: تعيين ExternalId إلى معرف غير قابل للتغيير (التحقق من معرف المستخدم أو objectGUID)؛ تنظيف التكرارات والمزامنة مرة أخرى.

• العرض: يظل مستخدمو "التحقق" الذين تم إلغاء تنشيطهم نشطين في الوصول الآمن

  • السبب الجذري: لم يتم تعيين إجراء الإيقاف المؤقت إلى active:false، أو تم تعطيل عملية إلغاء التنشيط في الموصل.

  • الدقة: تمكين عملية إلغاء التنشيط وتعيين الإيقاف المؤقت إلى active:false؛ التحقق باستخدام مستخدم إختبار.

• العرض: تغييرات السمة في Verify لا يتم نشرها

  • السبب الجذري: تم تعطيل عملية التحديث بواسطة المستخدم أو السمة خارج نطاق نهج التوفير.

  • الدقة: مراجعة سياسة أو إستحقاقات توفير التطبيقات؛ تمكين التحديثات؛ تشغيل المزامنة اليدوية.

• العرض: يرفض Secure Access الطلبات ذات المخطط أو أخطاء النمط 501

  • السبب الجذري: حمولة غير متوافقة مع SCIM (صفيف مخططات مفقود، URN خاطئ، عملية غير مدعومة).

  • الدقة: النسخ باستخدام إختبار التفاف الخط الأساسي؛ تصحيح الحمولة أو التعيين؛ التصعيد إلى IBM إذا قام الموصل بإرسال الطلب الذي تم تكوينه بشكل غير صحيح.

• العرض: معرف SWG مفقود للمستخدمين المتجولين بالرغم من عمل SAML

• السبب الجذري: من المتوقع أن يقوم SAML بتشغيل الهوية لوضع نشر يستخدم هوية سلبية أو قائمة على وكيل.

• الدقة: تأكيد طريقة الحصول على الهوية لكل وضع نشر مقابل وثائق الوصول الآمن؛ لا تصمم SAML كمصدر الهوية الوحيد.

القضايا العامة ل SCM

وهذه ليست خاصة ب Cisco، ولكنها تظهر باستمرار في عمليات نشر Secure Access لأن النقل الأساسي هو SCIM 2.0 القياسي:

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

• تعارض 409 في إلغاء التنشيط: نمط شائع حيث يحاول IdP إلغاء تنشيط مستخدم بينما يقوم الهدف بإثارة تعارض. عادة ما يكون هذا تعيين سمة نشط أو مشكلة في نطاق المجموعة، وليس خطأ نظام صحيح.

• لا يتم نشر الحقول الفارغة أو التي تم المسح دائما: تحتفظ بعض عمليات تنفيذ خادم SCM بالقيمة الأخيرة غير الخالية؛ عندما تقوم بمسح حقل في المعرفات، فإنه قد يتطلب منك دفع قيمة المواضع المؤقتة من خلال الأول.

• يؤدي تغييرات التكوين أو عنوان URL إلى إبطال المصادقة بشكل صامت: يتطلب أي تغيير على عنوان URL لنقطة نهاية SCIM عادة توفير الرمز المميز لحامله مرة أخرى. تظهر الأخطاء كعنوان URL غير صالح حتى عندما تكون المشكلة الحقيقية رمزا مميزا غير صحيح.

• لا يوجد ويب خطاف أصلي أو دفق حدث: يجب أن يقوم الأتمتة التي تتوقع إعلامات بالدفع في الوقت الفعلي على المستخدم أو تغييرات السياسة باستطلاع واجهة برمجة تطبيقات التقارير أو الدمج عبر Cisco XDR بدلا من ذلك. لا يقوم Secure Access بإرسال تعليقات ويب الخاصة بالإمداد الصادر.

التصعيد إلى Cisco TAC مع سجلات الإمداد من جانب IdP إذا لم تحل الخطوات السابقة المشكلة. تتطلب سجلات الإمداد الخلفية على جانب الوصول الآمن بشكل عام وصول TAC لسحب.

السبب

فشل تكامل توفير SCIM في دفع سجل واحد أو أكثر بسبب رمز مميز لحامل منتهي الصلاحية أو عدم تطابق تعيين السمة أو مجموعة هدف مفقودة أو نطاق تزويد غير كاف.

المحتوى ذي الصلة

• Cisco: تزويد المستخدمين والمجموعات بإمكانية الوصول الآمن عبر معرف Entra

• Cisco: تزويد المستخدمين والمجموعات بالوصول الآمن عبر OKTA

• التعلم من Microsoft: المشاكل المعروفة المتعلقة بالتوافق مع بروتوكول SCIM 2.0 - معرف Microsoft Entra

• التعلم من Microsoft: أستكشاف أخطاء واجهة برمجة التطبيقات الخاصة ب Microsoft Entra ID SCM وإصلاحها

• تكوين SAML SSO في موفر الهوية: https://www.ibm.com/docs/en/security-verify?topic=sign-configuring-saml-single-in-identity-provider

• الإمداد للتطبيقات المخصصة (SCIM): https://www.ibm.com/docs/en/security-verify?topic=endpoints-configuring-provisioning-custom-applications

• نظرة عامة على الإدارة والإمداد (موصل SCIM عام): https://docs.verify.ibm.com/verify/docs/use-cases-provisioning-and-governance

• جسر الإمداد المحلي (مصادر AD/LDAP): https://docs.verify.ibm.com/verify/docs/on-premises-provisioning

محفوظات المراجعة

المراجعة	تاريخ النشر	التعليقات
1.0	30-Oct-2026	الإصدار الأولي