ربط نظام إدارة الزوار
مع Active Directory

أول سؤال يطرحه مدير تقنية المعلومات في أي مشروع نظام زوّار: من أين يأتي دليل الموظفين؟ لأن نظام الزوّار بلا قائمة مضيفين محدّثة يتحول إلى نموذج إلكتروني — الزائر يكتب اسم من يقصده، ولا أحد يتحقق أنه موجود أصلًا.

وإدخال قائمة الموظفين يدويًا ليس حلًا: تتقادم خلال أسابيع، ولا تعكس المغادرين، وتصبح مصدر أخطاء بدل أن تكون مصدر ثقة. هذا الدليل يشرح الربط مع Active Directory: ما يُزامَن، وما يتطلبه، وأين تقع المشاكل.

لماذا يبدأ التكامل من دليل الموظفين؟

ما الذي يُزامَن فعليًا؟

الصف الأخير قبل الأخير هو الأهم أمنيًا: حالة الحساب. الموظف الذي غادر المنشأة يجب أن يفقد قدرته على استضافة زوّار تلقائيًا — لا أن يبقى مضيفًا صالحًا في نظام الزوّار لأشهر بعد مغادرته.

اتجاه المزامنة

القاعدة: المزامنة أحادية الاتجاه من AD إلى نظام الزوّار. نظام الزوّار يقرأ ولا يكتب. وأي نظام يطلب صلاحية كتابة على الدليل يجب أن يُسأل عن السبب — لأن الكتابة تفتح مخاطرة لا يبررها أي متطلب في إدارة الزوّار.

والاستثناء الوحيد المقبول: كتابة سمة مخصصة واحدة لا علاقة لها بالهوية، وحتى هذه يمكن تجنّبها بالتخزين المحلي في نظام الزوّار.

المستخدمون الذين لا يوجدون في الدليل

مشكلة عملية تُغفل في التخطيط: حرس الأمن وموظفو الاستقبال قد لا يملكون حسابات في الدليل أصلًا — خصوصًا إن كانوا من شركة أمن متعاقدة.

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

Entra ID والبيئات السحابية

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

واسأل المزوّد صراحةً عن البيئة الهجينة إن كانت لديك، لأن المزامنة من بيئتين تحتاج تعريفًا واضحًا لأيهما المصدر الموثوق. راجع تكامل حَصين مع Active Directory.

متطلبات الشبكة والأمان

• حساب خدمة بصلاحية قراءة فقط — لا حساب مسؤول، ولا صلاحيات كتابة.
• اتصال مشفّر بين النظام والدليل، ولا يُقبل غير ذلك.
• نطاق مزامنة محدد — وحدات تنظيمية بعينها لا الدليل كاملًا.
• تسجيل عمليات المزامنة في سجل تدقيق قابل للمراجعة.
• دورية معرّفة — كل ساعة أو كل ليلة بحسب حجم التغيّر لديك.

النطاق المحدد نقطة مهمة: مزامنة الدليل كاملًا تنقل حسابات خدمة وحسابات نظام لا علاقة لها بالمضيفين، فتلوّث قائمة الاختيار وتزيد سطح البيانات دون فائدة.

خطوات التنفيذ العملية

1. تحديد نطاق المزامنة. أي وحدات تنظيمية تحوي المضيفين فعلًا؟ استبعد حسابات الخدمة والأنظمة.
2. إنشاء حساب الخدمة بصلاحية قراءة على النطاق المحدد فقط.
3. مطابقة الحقول بين الدليل والنظام — وهنا تظهر الفروق: بعض المنشآت تخزّن الجوال في حقل غير قياسي.
4. مزامنة تجريبية على وحدة تنظيمية واحدة قبل التعميم.
5. مراجعة النتيجة — عدد المضيفين المستوردين، والحقول الفارغة، والحسابات غير البشرية التي تسللت.
6. ضبط الدورية وتفعيل المزامنة الكاملة.

الخطوة الثالثة هي الأكثر استهلاكًا للوقت في الواقع، لأن كل منشأة تستخدم حقول الدليل بطريقتها. اطلب من المزوّد قائمة الحقول المطلوبة مبكرًا لتراجعها مع فريق الدليل.

ماذا لو لم يكن لديك Active Directory؟

ليست كل منشأة تملك دليلًا مركزيًا. والبدائل بترتيب الأفضلية: الاستيراد من نظام الموارد البشرية — وهو غالبًا المصدر الأدق للموظفين على أي حال؛ أو استيراد دوري من ملف يُحدَّث شهريًا؛ أو إدارة يدوية للمنشآت الصغيرة التي لا يتجاوز موظفوها العشرات.

والخيار الأول يستحق النظر حتى لو كان لديك دليل، لأن نظام الموارد البشرية يعرف تاريخ انتهاء الخدمة مسبقًا بينما الدليل يعرفه عند التعطيل. راجع تكامل أنظمة الموارد البشرية.

أربعة أخطاء شائعة في الربط

1. مزامنة كل الدليل. ينتج قائمة مضيفين فيها آلاف الحسابات غير البشرية.
2. إغفال حالة الحساب. فيبقى المغادرون مضيفين صالحين شهورًا.
3. الاعتماد على البريد وحده للإشعار. الموظف في المصنع أو المستودع لا يقرأ بريده لحظة وصول زائره — الجوال أسرع بكثير.
4. عدم اختبار حالة التعارض. ماذا يحدث لموظف تغيّر اسمه أو قسمه؟ وهل تُنقل زياراته المستقبلية؟

تكامل حَصين مع Active Directory

في حَصين يتم الربط بمزامنة قراءة من الدليل لبناء قائمة المضيفين وتحديثها تلقائيًا، مع دعم مستخدمين محليين لفرق الأمن والاستقبال الذين قد لا يملكون حسابات في الدليل. والصلاحيات تُدار على مستوى الدور فيحدد كل دور ما يراه المستخدم وما يستطيع فعله.

تفاصيل التكامل في تكامل Active Directory، وبقية التكاملات المتاحة في صفحة التكاملات، والدخول الموحّد في تكامل SSO.

أسئلة شائعة

كيف أربط نظام الزوار بـActive Directory؟

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

هل تُزامَن بيانات الموظفين تلقائيًا؟

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

ماذا يحدث عند مغادرة الموظف؟

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

هل يدعم الربط Entra ID؟

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

هل يتطلب الربط فتح منافذ خارجية؟

مع الدليل المحلي قد يتطلب اتصالًا داخليًا مشفّرًا لا فتحًا للخارج، وذلك حسب موقع النظام — سحابي أم داخل الشبكة. ومع البيئة السحابية لا حاجة لفتح منافذ داخلية إطلاقًا. اطلب من المزوّد مخطط الاتصال قبل مراجعة أمن المعلومات لا بعدها.

ماذا عن حرس الأمن الذين لا يملكون حسابات؟

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

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

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