استكشاف الأخطاء وإصلاحها لأخطاء خدمات الدليل ووعي المستخدم

توضح هذه المقالة مشكلات خدمات الدليل ووعي المستخدم الشائعة والحلول المقترحة. لمزيد من المعلومات، راجع تهيئة Windows Server لخدمات الدليل.

خطأ: غير قادر على الاتصال بوحدة تحكم المجال

تحدي

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

حل

تحقق من أنك قمت بإدخال إعدادات اتصال مصادقة LDAP (Login DN وBase DN وكلمة المرور) بشكل صحيح في تطبيق Cato Management (الوصول > خدمات الدليل).

خطأ: NT_STATUS_ACCESS_DENIED

تحدي

تشير رسالة الخطأ هذه إلى مشكلة في الأذونات. يُخطرك تطبيق Cato Management عند عدم تمكنه من الوصول إلى وحدة DC. عادةً ما تتبع رسالة الخطأ هذه الحدث: “DC_Connectivity_Failure” في قسم التحليلات. يولد تطبيق Cato Management هذا الحدث (مرة كل ساعة) عندما يفشل الاتصال بوحدة DC.

الحل

اتبع هذه الخطوات لاستكشاف هذه المشكلة:

1. تحقق من اسم المستخدم وكلمة المرور. تحقق من أنك أدخلت DN تسجيل الدخول وكلمة المرور الصحيحة. تحقق من أن Cato Socket يرسل اسم المستخدم الصحيح في محاولة الاتصال عن طريق التقاط حزم البيانات (PCAP) على واجهة LAN الخاصة بـ Socket أو وحدة DC نفسها.

2. تحقق من أذونات المستخدم لقراءة سجل الحدث من إعدادات وحدة تحكم المجال. اتبع الدليل الإرشادي عبر الإنترنت - تكوين Windows.

3. إذا قمت بتمكين مزامنة الدليل اليومية لمجموعات وخدمات المستخدم (وعي المستخدم)، تحقق من أنك قمت بتكوين وحدات التحكم بالنطاق لمزامنة الوقت الحقيقي. انقر على "اختبار الاتصال" وتحقق مما إذا كنت تحصل على نتيجة "الاتصال ناجح".

4. تحقق من الأحداث في قسم الأحداث في قسم المراقبة. يمكنك تصفية الأحداث بناءً على نوع الحدث: النظام ونوع الحدث الفرعي: خدمات الدليل والبحث عن أخطاء الاتصال بـ DC أو المزامنة.

5. اتبع الدليل الإرشادي عبر الإنترنت وتحقق من إعدادات تكوين وحدة تحكم المجال.

6. تحقق مما إذا كانت حركة المرور لا يتم حظرها بواسطة جدار الحماية للإنترنت أو WAN. يمكن لقواعد جدار الحماية التي تحظر المستخدمين غير المعرفين أن تحظر مستخدم مزامنة Cato وتحظر خدمات الدليل.

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

خطأ: NT_STATUS_UNSUCCESSFUL

تحدي

يولد تطبيق Cato Management هذا الخطأ عندما لا يتمكن PoP من الوصول إلى DC للمزامنة الفورية. يظهر هذا الخطأ عند النقر فوق الزر "عرض الحالة" في قسم وحدات تحكم المجال للمزامنة الفورية أو عبر البريد الإلكتروني إلى المسؤولين عن الحساب.

الحل

عادة ما يشير هذا الخطأ إلى خطأ في تكوين إعدادات ميزة وعي المستخدم. يمكن أن يحدث أيضًا بسبب تكوين جدار الحماية أو التوجيه. اتبع هذه الخطوات لاستكشاف المشكلة:

1. تحقق من الأحداث وتأكد من وجود أحداث للمستخدمين غير المعرفين.

2. تحقق مما إذا كانت حركة المرور لا يتم حظرها بواسطة جدار حماية الإنترنت/WAN بسبب عدم التعرف على المستخدمين.

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

4. تأكد من أن الDC يعمل.

5. قم بتشغيل التقاط حركة المرور من واجهة Socket UI، ملتقطًا حزم البيانات (PCAP) على واجهة LAN الخاصة بـ Socket. انقر على زر عرض الحالة. أوقف الالتقاط وابحث عن استفسار WMI من Cato PoP واستجابة الخادم في ملف الالتقاط (باستخدام أي أداة تحليل شبكة مثل Wireshark). إذا كان مركز البيانات (DC) وراء موقع IPsec، قم بتنفيذ الالتقاط على مركز البيانات نفسه.

خطأ: NT_RPC_NT_CALL_FAILED

التحدي

يشير الخطأ NT_RPC_NT_CALL_FAILED إلى أن خدمة RPC على DC لا تستجيب. يظهر هذا الخطأ عند النقر على الزر "إظهار الحالة" في وحدات التحكم بالنطاق لمزامنة الوقت الحقيقي.

حل

1. تحقق من أن وحدة التحكم بالنطاق تعمل، وافحص وحدة المعالجة المركزية والذاكرة. أحيانًا تؤدي زيادة وحدة المعالجة المركزية أو الذاكرة إلى تحميل زائد على الخادم.

2. تحقق من أن خدمات Windows الخاصة بDC قد بدأت وتم تعيينها لبدء التشغيل التلقائي:

   • خادم

   • تسجيل النطاق البعيد

   • WMI

خطأ: NT Code 0x80010111

التحدي

يعني هذا الخطأ أن PoP لا يمكنه التواصل مع DC بسبب عدم تطابق رأس RPC بين PoP و DC.

الحل

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

خطأ مزامنة UA رمز NT 0xc002001b

المسألة

سيظهر الخطأ 0xc002001b NT code 0xc002001b عندما تفشل خدمة RPC على وحدة التحكم في المجال بالاستجابة.

يمكن لهذا الخطأ أن يظهر عند النقر على "اختبار الاتصال" ضمن الوصول > وعي المستخدم > LDAP أو عند إرسال البريد الإلكتروني إلى المسؤولين عن الحساب.

قد يسبب هذا المشكلة:

• لن يتم تحديد المستخدمين في الأحداث والتحليلات.

• تم حظر حركة المرور بواسطة جدار الحماية الإنترنت/WAN بسبب عدم التعرف على المستخدمين.

• إعداد جديد للعميل لوعي المستخدم وتلقي أخطاء مزامنة DC.

السبب المحتمل

قد تحدث هذه المشكلة بسبب استنفاد الموارد على وحدة التحكم بالنطاق.

\u0627\u0644\u0645\u062b\u0627\u0648\u064a\u0627\u062a

الخطوات التالية هي خطوات استكشاف الأخطاء وإصلاحها التي يمكن اتباعها:

• تحقق من أن وحدة تحكم المجال تعمل وأنها غير مستنفدة (لا وجود لارتفاعات في وحدة المعالجة المركزية أو ذاكرة الوصول العشوائي).

  • زيادة كمية الذاكرة ووحدات المعالجة المركزية على الخادم إذا كان ذلك ممكنًا.

  • إذا كان غير ممكن إضافة المزيد من الموارد المادية للخادم، اتبع الخطوات أدناه لزيادة ذاكرة خدمة موفر WMI والتعامل مع الحصص وتقليل حجم سجلات الأحداث الأمنية:

    • زيادةWMIMemoryPerHostvalue(راجعزيادة خصائص حصة WMI إلى القيم القصوى)

    اتبع الخطوات أدناه لتقليل حد حجم سجل الأمان إلى 1 ميغابايت:

    1. افتح عارض الأحداث

    2. انتقل إلى عارض الأحداث > سجلات Windows > الأمان

    3. انقر بزر الماوس الأيمن الأمان وانقر على خصائص

    4. اضبط حجم السجل الأقصى (بالكيلوبايت) على 1024

    5. عند الوصول إلى الحد الأقصى لحجم سجل الأحداث اختر الكتابة فوق الأحداث حسب الحاجة (الأحداث الأقدم أولاً) أو أرشفة السجل عند الامتلاء، لا تكتب فوق الأحداث.

    6. انقر على موافق

• تحقق من أن خدمات وحدة تحكم المجال المطلوبة تعمل (افتح services.msc وتحقق من أن الخادم، السجل البعيد، وأداة إدارة Windows قد بدأت وتم تعيينها لبدء التشغيل التلقائي.

• في حالة ظهور علامات إجهاد على وحدة تحكم المجال، قد يكون من المطلوب إعادة تشغيل الخادم.

خطأ: لا يمكن الاتصال بوحدة تحكم المجال 0xc0000001 NT_STATUS_UNSUCCESSFUL

إذا رأيت رسالة الخطأ حالة غير ناجحة في تطبيق إدارة Cato كما يلي:

“لا يمكن الاتصال بوحدة تحكم المجال 0xc0000001 NT_STATUS_UNSUCCESSFUL . تحقق من أنك قمت بدمج وحدة تحكم المجال بشكل صحيح مع شبكة Cato. إذا استمرت المشكلة، اتصل بدعم Cato للحصول على المساعدة. انقر هنا للدخول على التفاصيل.

هذا خطأ عام يمكن أن يكون نتيجة أخطاء تكوين لوحدة تحكم المجال. نوصي باتباع دليل التكوين.

خطأ - لا يمكن الاتصال بوحدة تحكم المجال (الرمز 6)

إذا رأيت خطأ اتصال بالرمز 6 في تطبيق إدارة Cato، كما يلي:

هناك بعض الخطوات التي يمكنك اتخاذها لاستكشاف المشكلة.

إعادة اتصال Cato Socket

أحيانا يتم حل هذه المشكلة عند استخدام واجهة المستخدم على الويب للـ Socket لفصل وإعادة توصيل Socket بـ Cato Cloud.

تحذير!إجراء إعادة توصيل للمقبس يفصل جميع الجلسات الحالية للموقع. يعود Socket للاتصال بـ Cato Cloud في غضون بضع ثوانٍ، ثم يتم استعادة الاتصال فورًا. ومع ذلك، يتم إسقاط بعض حركة المرور الحساسة للاتصال (مثل المكالمات الهاتفية).

لإجراء إعادة اتصال على Socket:

1. اتصل بواجهة المستخدم على الويب للـ Socket، في متصفح الويب الخاص بك، أدخل https://<Cato Socket IP address>
   على سبيل المثال: https://10.0.0.26

2. أدخل اسم المستخدم وكلمة المرور.

3. حدد علامة التبويب إعدادات اتصال Cato 

4. انقر على إعادة الاتصال.

5. تسجيل الخروج من واجهة WebUI الخاصة بالمقبس.

استكشاف الاتصال بوحدة DC

بعد إجراء إعادة اتصال Socket، إذا استمرت مشكلة DC، نقدم هنا بعض الاقتراحات الإضافية لاستكشاف الاتصال بوحدة DC:

1. تحقق من اتصال DC بسحابة Cato.

2. تحقق من وجود اتصال ثنائي الاتجاه بين DC وسحابة Cato.

للتحقق من أن DC متصل بـ Cato Cloud:

1. تأكد من أن DC قيد التشغيل.

2. في تطبيق Cato Management، انتقل إلى الصفحة الرئيسية > التكوين وتأكد من أن الموقع الذي يحتوي على DC متصل بـ Cato Cloud.

3. تحقق من أنك تقوم بإرسال ping إلى مركز البيانات (DC) من مضيف في موقع مختلف، أو أثناء اتصالك بشبكة VPN الخاصة بكاتو.

4. إذا لم تتمكن من إرسال ping إلى مركز البيانات (DC)، فإليك بعض الطرق لاستكشاف المشكلة وحلها:

   • في تطبيق Cato Management، تحقق من الصفحة الرئيسية > الأحداث لحدث الحظر. هل تحتاج لتغيير سياسة جدار الحماية لـ WAN للسماح بحركة ICMP إلى DC؟

   • تحقق من جدول التوجيه على DC وتأكد من أن الحركة مرسلة إلى Cato Socket أو نفق IPsec.

   • تحقق من سياسة جدار الحماية الخاص بنظام التشغيل Windows على مركز البيانات (DC) للتأكد من أن حركة مرور ICMP ليست محظورة.

للتحقق من الاتصال بين DC و Cato Cloud:

1. قم بتشغيل التقاط الحزم إما على واجهة LAN الخاصة بـ Socket.

   • إذا كان مركز البيانات (DC) وراء موقع IPsec، قم بتنفيذ الالتقاط على مركز البيانات نفسه.

2. إذا كان هناك اتصال ثنائي الاتجاه، يمكنك رؤية اتصال على TCP/135 إلى مركز البيانات الخاص بك تم بدءه من نطاق VPN لكاتو (10.41.0.0/16 بشكل افتراضي).
   ملحوظة: يمكن لكاتو استخدام أي عنوان IP من نطاق VPN لبدء الاتصال.
   ملاحظة: بدءًا من Windows Server 2008، يجب عليك أيضًا السماح بحركة مرور TCP 49152-65535 لعملية WMI عبر أي جدار حماية. من الممكن أيضًا إضافة قاعدة جدار حماية Windows لخدمة WMI بشكل محدد.  راجع: https://docs.microsoft.com/en-us/windows/win32/wmisdk/connecting-to-wmi-remotely-starting-with-vista 

3. إذا لم تتمكن من العثور على اتصال يظهر اتصالًا ثنائي الاتجاه، فإليك بعض الخطوات لاستكشاف المشكلة وحلها.

   • إذا لم ترَ أي حركة مرور قادمة من نطاق VPN إلى DC، اتصل بدعم Cato.

   • إذا رأيت فقط حزم SYN على TCP/135 من نطاق VPN لكاتو إلى مركز البيانات الخاص بك، تحقق من الاتصال بمركز البيانات (DC):

     1. افحص جدول التوجيه في مركز البيانات وتأكد من توجيه الحركة إلى Cato Socket أو نفق IPsec.

     2. تحقق من سياسة جدار الحماية الخاص بنظام التشغيل Windows على مركز البيانات (DC) وتأكد من أن المرور غير محظور.

المستخدم غير معتمد بوعي المستخدم

التحدي

في بعض الحالات، يظهر المستخدمون على أنهم "مستخدم غير معتمد" في نافذة اكتشاف الأحداث. السبب في المستخدم غير المعتمد هو أن PoP كان قادرًا على اكتشاف اسم المستخدم في الوقت الحقيقي (باستخدام استفسارات WMI) ولكن هذا المستخدم لم يستورد أثناء مزامنة LDAP وهو غير معروف. لذلك، يظهر حقل الاسم AD للحدث كمستخدم غير معتمد.

حل

1. تحقق من انتماء المستخدم إلى المجموعة. إذا قمت بتكوين خدمات الدليل الخاصة بـ Cato لاستيراد المستخدمين والمجموعات من مركز البيانات، ولم ينتمي المستخدم إلى المجموعة المُعدّة، فسيظهر كمستخدم غير معتمد.

2. تحقق من تكوين سياسة التدقيق لمركز البيانات. لمزيد من المعلومات الرجاء مراجعة تكوين سياسة التدقيق لمراقبة المجال.

أحداث تسجيل الدخول لا تظهر في اكتشاف الأحداث

تحدي

إذا قمت بتمكين وعي المستخدم لحسابك لكن لا يمكنك رؤية أي أحداث تسجيل دخول للمستخدمين في اكتشاف الأحداث، فاتبع الخطوات الموضحة في الحل التالي.

حل

تحقق من تكوين سياسة التدقيق في مركز البيانات. لمزيد من المعلومات الرجاء مراجعة تكوين سياسة التدقيق لمراقبة المجال.

مزامنة خدمات الدليل لا تستورد المستخدمين

تحدي

مع وعي المستخدم، يظهر في الوقت الحقيقي ما هي أسماء المستخدمين للمضيفين وراء المواقع. يسمح لك برؤية أسماء المستخدمين للمضيفين وليس فقط عناوين IP في أقسام التحليل. يتم ملء المستخدمين من خلال مزامنة خدمات الدليل. تستخدم المزامنة LDAP للاستفسار عن خادم الدليل النشط (AD). في بعض الأحيان تفشل مزامنة LDAP لأسباب مختلفة. على سبيل المثال، لدى LDAP من Microsoft قدرة معلومة أنها تسمح فقط بإرجاع الكائنات التي تحتوي على أقل من 1500 عنصر في أي استفسار واحد. يمكن للمؤسسات الكبيرة بسهولة أن تملك أكثر من 1500 عضو مخصصين لمجموعة واحدة. لذلك، عندما يقوم PoP بتشغيل استفسار LDAP، فإن أي مجموعات تحتوي على أكثر من 1500 عضو ستعيد قائمة أعضاء فارغة إلى تطبيق إدارة كاتو، مما يؤدي إلى تعطيل/حذف المستخدمين في CMA.

حل

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

لحل استجابة الاستفسار الفارغة من مراقبة المجال، يمكنك اتباع هذه الخطوات:

1. تحقق من أن الخدمات التالية في مركز البيانات تعمل ومُجهزة للتشغيل التلقائي:

• خادم

• WMI

• تسجيل النطاق البعيد

2. يمكنك ضبط سمة سياسة Microsoft LDAP في مركز البيانات لقيمة MaxValRange. تتحكم هذه السمة في عدد القيم التي سيتم إرجاعها. استخدم المقالتين التاليتين لزيادة قيمة MaxValRange أو إزالة القيد بالكامل. إذا كنت لا تريد تغيير سمة AD، فيمكن لكاتو جمع المجموعات التي تحتوي على أقل من 1500 مستخدم.

مقالة MS حول كيفية ضبط MaxValRange باستخدام أداة ntdsutil:
https://support.microsoft.com/en-gb/help/315071/how-to-view-and-set-ldap-policy-in-active-directory-by-using-ntdsutil

مقالة/مدونة MS حول كيفية إزالة القيد بالكامل:
https://docs.microsoft.com/en-us/archive/blogs/qzaidi/override-the-hardcoded-ldap-query-limits-introduced-in-windows-server-2008-and-windows-server-2008-r2

الأحداث المفقودة في التدقيق عند استخدام GPO

تحدي

إذا كنت تستخدم GPO مع إعدادات سياسة التدقيق الأمني المتقدم ولم يتم تسجيل جميع معرفات الحدث، فاتبع الخطوات الموضحة في الحل.

حل

تحقق من تكوين سياسة التدقيق لمركز البيانات. لمزيد من المعلومات الرجاء مراجعة تكوين سياسة التدقيق لمراقبة المجال.

تكوين سياسة التدقيق لمراقبة المجال

يمكن تعريف سياسة التدقيق محليًا على مركز البيانات أو تطبيقها عبر GPO. تقوم GPO بتجاوز سياسة الأمان المحلية. تقوم إعدادات سياسة التدقيق المتقدم بتجاوز إعدادات سياسة التدقيق الأساسية.

تأكد من أن سياسة التدقيق مصممة مع معرفات الأحداث التي يستخدمها وعي المستخدم في سجل أمان Windows لتعيين المستخدمين إلى عناوين IP.

تحتوي القائمة التالية على معرفات الأحداث التي تستخدمها كاتو في سياسة التدقيق:

• 4768 - تم طلب تذكرة مصادقة Kerberos (TGT)

• 4769 - تم طلب تذكرة خدمة Kerberos

• 4770 - تم تجديد تذكرة خدمة Kerberos

• 4776 - حاول مراقب المجال التحقق من صحة الاعتماديات لحساب\

• 4624 - تم تسجيل الدخول إلى الحساب بنجاح

• 4648 - تم محاولة تسجيل الدخول باستخدام اعتمادات صريحة

• 5140 - تم الوصول إلى عنصر مشاركة الشبكة

• 5145 - تم التحقق مما إذا كان يمكن للعميل منح الوصول المطلوب إلى عنصر مشاركة الشبكة

لتكوين سياسة التدقيق محليًا على مركز البيانات

1. افتح سياسة الأمان المحلية.

2. انتقل إلى إعدادات الأمان > السياسات المحلية > سياسة التدقيق لتكوين سياسة التدقيق الأساسية، أو انتقل إلى إعدادات الأمان > تكوين سياسة التدقيق المتقدم > سياسة التدقيق لتكوين سياسة التدقيق المتقدم التي توفر تحكمًا أكثر دقة في السجلات.

لتكوين سياسة التدقيق باستخدام سياسة المجموعة:

1. افتح محرر إدارة سياسة المجموعة.

2. انقر بزر الفأرة الأيمن على GPO المطبق على جميع مراقبي المجال وحدد "تحرير"

3. توسيع تكوين الكمبيوتر > السياسات > إعدادات Windows > إعدادات الأمان > السياسات المحلية > سياسة التدقيق لسياسة التدقيق الأساسية أو تكوين الكمبيوتر > السياسات > إعدادات Windows > إعدادات الأمان > تكوين سياسة التدقيق المتقدم > سياسة التدقيق لسياسة التدقيق المتقدمة.

تحتوي القائمة التالية على معرفات الأحداث التي يستخدمها وعي المستخدم لكاتو:

سياسة التدقيق الأساسية

• تدقيق أحداث تسجيل الدخول - 4624، 4648

• تدقيق أحداث تسجيل الدخول إلى الحساب - 4768، 4769، 4770، 4776

• تدقيق وصول الكائن - 5140، 5145

سياسة التدقيق المتقدمة

• تسجيل الدخول إلى الحساب

  • تدقيق خدمة المصادقة Kerberos – 4768

  • تدقيق عمليات تذكرة خدمة Kerberos - 4769، 4770

  • تدقيق التحقق من صحة الاعتماديات – 4776

• تسجيل الدخول/تسجيل الخروج

  • تدقيق تسجيل الدخول - 4624، 4648

• وصول الكائن

  • تدقيق مشاركة الملفات – 5140

  • تدقيق مشاركة الملفات المفصلة - 5145

يمكنك التحقق من سياسة التدقيق الفعالة في مركز البيانات عن طريق تشغيل الأمر التالي من موجه الأوامر: auditpol /get /category:*