دفتر تشغيل شبكة XOps - فشل توفير SCIM

تُعتبر مزامنات SCIM أساسية لتوجيه المستخدمين إلى CMA، مما يضمن عملية توظيف سلسة ووصولاً متسقًا إلى الموارد. تعتمد تكرارية التزامن على مزود الهوية المستخدم، كما هو موضح في توفير مستخدم SCIM. 

عندما يفشل توفير SCIM، قد لا يتمكن المستخدمون الذين تم إنشاؤهم حديثًا من الاتصال أو الوصول إلى الخدمات المطلوبة، وقد لا يتم تنفيذ سياسات الأمان بشكل صحيح. للمساعدة في ضمان الكشف السريع والحل، يتم إنشاء قصة XOps تلقائيًا كلما حدث فشل في التوفير بين IdP وCMA.

عند الرد على قصص XOps للشبكة، من الضروري التعامل مع المشكلة بطريقة منهجية. أولاً، تحقق من أن المشكلة مستمرة، ثم قم بحلها، وأخيراً تأكد من أن المشكلة قد تم حلها.

الخطوة 1 - التحقق من فشل مزامنة SCIM

فيما يلي الطرق المختلفة التي يمكن لمشرف تطبيق إدارة Cato التحقق منها بأن مزامنة SCIM قد فشلت. 

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

باستخدام الحدث

تحدد هذه القسم الأدوات المتاحة في Cato لأسلوب استكشاف الأخطاء وإصلاحها المنظم للحوادث من هذا النوع. بينما يُقصد بالخطوات عمومًا أن يتم اتباعها بترتيبها، إلا أن نتائج كل فحص قد تؤثر على الخطوة التالية في العملية.

• لتحديد ما إذا كانت المشكلة حدثًا فرديًا، قم بتنفيذ التوفير عند الطلب من منصة IdP. بالنسبة لـ Azure، انتقل إلى تطبيقات المؤسسات > Cato Networks Provisioning > توفير وانقر على "التوفير عند الطلب."
  
• اختر مستخدمًا أو مجموعة مخصصة للتطبيق وانقر على زر "توفير".
• إذا اكتملت مزامنة SCIM بنجاح، فقد يشير ذلك إلى أن فشل مزامنة SCIM كان حادثًا مستقلًا. يجب أن يتحقق المشرف مما إذا كانت هناك انقطاعات مزود الخدمة أو أنشطة صيانة Cato تزامنت مع وقت مزامنة SCIM.
• إذا فشلت مزامنة SCIM أيضًا، فإن ذلك يشير إلى أن المشكلة مستمرة وأن التزامن مع IdP لا يكتمل بنجاح. في هذه الحالة، قم بمراجعة أي تغييرات حديثة في التكوين قد تكون أدت إلى المشكلة.
   

• راجع التغييرات في صفحة مسار التدقيق لتحديد ما إذا كان تغيير التكوين هو سبب هذه المشكلة. هذه الخطوة مهمة بشكل خاص إذا كانت المزامنة المجدولة تعمل بشكل طبيعي ولكنها توقفت عن العمل بشكل غير متوقع.
• لعرض أي تغييرات تم إجراؤها على تكوين النطاق، قم بتصفية لوحة التدقيق عن طريق تعيين نوع النموذج إلى النطاق. اضبط الإطار الزمني حسب الحاجة لمطابقة وقت حدوث المشكلة.
  
• على سبيل المثال، توضح الشاشة أدناه أن المسؤول قام بإجراء تغييرات في تكوين توفير SCIM لـ Okta. إذا كان توقيت هذا النشاط متزامنًا مع فشل مزامنة SCIM، يمكن للمسؤول إعادة التغييرات لتحديد ما إذا كانت التغييرات هي السبب. 
  
• عامل آخر يمكن أن يؤثر على اتصال SCIM هو التغييرات في التطبيق على جانب IdP. بالنسبة لـ Azure، انتقل إلى تطبيقات المؤسسات > توفير شبكات Cato وتحقق من سجلات التدقيق وسجلات التوفير لتحديد ما إذا كان تغيير التكوين قد أثار فشل SCIM.
  

تحديث بيانات المسؤول

• للتحقق من فشل الاعتماد مع IdP، قم بإنشاء رمز جديد من CMA تحت خدمات الدليل > SCIM. انقر على "إنشاء رمز" وانسخ الرمز الجديد.

• بالنسبة لـ Azure، انتقل إلى تطبيقات المؤسسات > Cato Networks Provisioning > Provisioning وقم بتوسيع التوفير > بيانات المسؤول. أدخل الرمز الذي تم إنشاؤه من CMA وانقر على "اختبار الاتصال".
  

• إذا نجح التحقق، فقد تكون المشكلة متعلقة بعدم تطابق الرمز بين IdP وCMA.

   

بعد تحديد المشكلة وحلها التي تسببت في فشل مزامنة SCIM، تحقق من أن المزامنة تظهر الآن على أنها تم حلها في القصة. 

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

رفع حالات إلى دعم Cato

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