الفرق بين Active Directory وMicrosoft Entra ID
تظهر المشكلة عندما تتعامل شركة لديها خوادم داخلية وحسابات Microsoft 365 مع النظامين على أنهما نسخة واحدة. ينتج عن ذلك حسابات مكررة، وأسماء دخول غير متطابقة، وسياسات لا تُطبّق على الأجهزة، وصعوبة في معرفة المكان الصحيح لإدارة المستخدم أو كلمة المرور.
فهم الفرق بين Active Directory وMicrosoft Entra ID مهم لفني الدعم الفني ومسؤول السيرفرات، لأن طريقة تسجيل الدخول وإدارة الأجهزة وتطبيق السياسات واستعادة الحسابات تختلف بينهما اختلافاً جوهرياً.
ستتعرف في هذا الدليل على وظيفة كل نظام، والفروق التقنية بينهما، ومتى تختار البيئة المحلية أو السحابية أو الهجينة، إضافة إلى خطوات التجهيز والتشخيص وأفضل الممارسات داخل الشركات.
ما هو Active Directory وMicrosoft Entra ID ومتى تحتاجهما؟
خدمة الدليل النشط، والمقصود بها عادةً خدمات مجال الدليل النشط (Active Directory Domain Services)، هي خدمة دليل تعمل على خوادم Windows Server داخل بيئة الشركة. تخزّن المستخدمين والأجهزة والمجموعات والوحدات التنظيمية، وتوفر المصادقة المركزية وإدارة الصلاحيات وسياسات المجموعة.
يعتمد النظام على وحدات تحكم المجال (Domain Controllers)، وعلى نظام أسماء النطاقات الداخلي (DNS)، وبروتوكولات مثل Kerberos وLDAP. عند انضمام جهاز إلى المجال، يستطيع المستخدم تسجيل الدخول بحساب الشركة، بينما يطبق قسم تقنية المعلومات إعدادات الأمان والطابعات والبرامج وجدار الحماية عبر سياسات المجموعة.
Microsoft Entra ID هو نظام مايكروسوفت السحابي لإدارة الهوية والوصول، وكان يُعرف سابقاً باسم Azure Active Directory. يدير حسابات المستخدمين والمجموعات والتطبيقات السحابية، ويوفر تسجيل الدخول الموحد (Single Sign-On) والمصادقة متعددة العوامل (MFA) وسياسات الوصول المشروط (Conditional Access).
لا يحتاج Entra ID إلى وحدات تحكم مجال داخلية كي يعمل. تتصل الأجهزة والتطبيقات به عبر الإنترنت باستخدام بروتوكولات مصادقة حديثة مثل OAuth وOpenID Connect وSAML. وهو المسؤول عن هويات المستخدمين عند الوصول إلى Microsoft 365 وكثير من تطبيقات البرمجيات كخدمة (SaaS).
| العنصر | وظيفته | الفائدة العملية |
|---|---|---|
| وحدة تحكم المجال | تستضيف قاعدة بيانات Active Directory وتنفذ المصادقة داخل الشبكة. | تسجيل دخول مركزي وإدارة أجهزة وخوادم ويندوز. |
| سياسة المجموعة (Group Policy) | تطبق الإعدادات على المستخدمين والأجهزة المنضمة إلى المجال. | فرض إعدادات الأمان والبرامج والطابعات بطريقة مركزية. |
| مستأجر Entra ID | يمثل هوية المؤسسة وبيانات مستخدميها ومجموعاتها في السحابة. | إدارة حسابات Microsoft 365 والتطبيقات السحابية. |
| الوصول المشروط | يتخذ قرار السماح أو المنع وفق المستخدم والجهاز والموقع والمخاطر. | حماية الحسابات عند العمل من خارج شبكة الشركة. |
| المزامنة الهجينة | تنقل الهويات المطلوبة من Active Directory إلى Entra ID. | استخدام هوية متناسقة للخدمات المحلية والسحابية. |
Active Directory يفترض غالباً وجود جهاز داخل شبكة الشركة أو متصل بها عبر شبكة افتراضية خاصة (VPN)، ويستخدم بنية المجال التقليدية. أما Entra ID فيفترض أن المستخدم قد يعمل من أي مكان، ويقيم طلب الوصول إلى تطبيق سحابي باستخدام هوية المستخدم وحالة الجهاز وعوامل الأمان المتاحة.
أفضل الإعدادات والخيارات حسب بيئة العمل
لا يبدأ القرار من سؤال: أيهما أفضل؟ بل من مكان وجود التطبيقات والأجهزة، وطريقة عمل الموظفين، وحاجة الشركة إلى بروتوكولات قديمة أو سياسات محلية.
| حالة بيئة العمل | الخيار الأنسب | سبب الاختيار |
|---|---|---|
| خوادم ملفات وتطبيقات داخلية وأجهزة ويندوز ثابتة | Active Directory | الحاجة إلى المجال وKerberos وLDAP وسياسات المجموعة. |
| شركة تعتمد كلياً على Microsoft 365 وتطبيقات سحابية | Microsoft Entra ID | لا توجد تطبيقات محلية تحتاج إلى مجال تقليدي. |
| خوادم داخلية مع بريد وتطبيقات سحابية | بيئة هجينة | الحفاظ على الخدمات المحلية مع توحيد الهوية في السحابة. |
| موظفون عن بُعد وأجهزة محمولة لا تدخل شبكة المكتب | Entra ID مع إدارة أجهزة سحابية | إدارة الهوية والجهاز عبر الإنترنت دون اعتماد دائم على VPN. |
| تطبيقات قديمة تتطلب LDAP أو Kerberos داخل Azure | حل مجال مُدار أو تصميم هجين | توفير البروتوكولات التقليدية دون افتراض أن Entra ID يقدمها مباشرةً. |
| جانب المقارنة | Active Directory | Microsoft Entra ID |
|---|---|---|
| مكان التشغيل | على خوادم الشركة أو آلات افتراضية تديرها المؤسسة. | خدمة هوية سحابية تدير مايكروسوفت بنيتها الأساسية. |
| إدارة الأجهزة | انضمام إلى المجال وسياسات المجموعة. | انضمام سحابي وتكامل مع حلول إدارة الأجهزة. |
| المصادقة | Kerberos وNTLM بصورة أساسية. | مصادقة حديثة ورموز وصول للتطبيقات السحابية. |
| دليل التطبيقات | LDAP والاعتماد على الشبكة الداخلية. | OAuth وOpenID Connect وSAML وتسجيل الدخول الموحد. |
| السياسات | سياسات المجموعة المرتبطة بالموقع والمجال والوحدة التنظيمية. | الوصول المشروط وسياسات الهوية، مع إدارة الجهاز عبر Intune. |
| العمل من الخارج | قد يحتاج إلى VPN للوصول إلى موارد المجال. | مصمم للوصول الآمن عبر الإنترنت. |
| التوافر والنسخ | مسؤولية المؤسسة عن التكرار والمراقبة والاستعادة. | البنية السحابية الأساسية مسؤولية مايكروسوفت، مع بقاء مسؤولية المؤسسة عن الحسابات والسياسات. |
- جهاز منضم إلى Active Directory: مناسب للأجهزة التي تعتمد على الشبكة الداخلية وسياسات المجموعة.
- جهاز منضم إلى Entra ID: مناسب للأجهزة الحديثة التي تعتمد على التطبيقات السحابية والإدارة عبر الإنترنت.
- جهاز هجين: منضم إلى المجال المحلي ومسجل أيضاً في Entra ID للاستفادة من الخدمات السحابية.
- جهاز مسجل فقط: جهاز شخصي يُضاف إليه حساب العمل دون اعتباره جهازاً مملوكاً ومداراً بالكامل من الشركة.
طريقة التجهيز والاستخدام والتنظيم
- اجمع متطلبات البيئة: احصر المستخدمين والأجهزة والخوادم والتطبيقات، وحدد التطبيقات التي تعتمد على LDAP أو Kerberos أو حسابات المجال.
- حدد مصدر الهوية الأساسي: قرر هل ستنشأ الحسابات في Active Directory ثم تُزامن، أم ستُدار مباشرةً داخل Entra ID.
- وحّد أسماء تسجيل الدخول: اجعل اسم المستخدم الرئيسي (UPN) متوافقاً مع نطاق الشركة العام، مثل user@company.com.
- جهز Active Directory عند الحاجة: استخدم وحدتي تحكم مجال على الأقل، واضبط DNS الداخلي والمواقع والشبكات الفرعية والوحدات التنظيمية.
- جهز مستأجر Entra ID: أضف نطاق الشركة وتحقق من ملكيته، ثم أنشئ المجموعات والأدوار الإدارية المطلوبة.
- اختبر المزامنة على نطاق صغير: ابدأ بوحدة تنظيمية ومجموعة مستخدمين تجريبية قبل مزامنة جميع الحسابات.
- حدد طريقة المصادقة: اختر طريقة تناسب متطلبات الشركة، مع تفضيل التصميم الأبسط القابل للمراقبة والاستعادة.
- طبّق الأمان تدريجياً: فعّل المصادقة متعددة العوامل، واختبر سياسات الوصول المشروط قبل فرضها على الجميع.
- حدد استراتيجية الأجهزة: قرر أي الأجهزة ستكون منضمة إلى المجال وأيها ستكون منضمة إلى Entra ID وأيها هجينة.
- وثّق دورة حياة الحساب: الإنشاء وتغيير القسم وإضافة الصلاحيات وتعطيل الحساب وحذف التراخيص والمراجعة الدورية.
Identity Design
|
+-- Active Directory
| +-- OU=Users
| +-- OU=Workstations
| +-- OU=Servers
| +-- OU=Service Accounts
| +-- OU=Sync-Pilot
|
+-- Microsoft Entra ID
+-- Group-Employees
+-- Group-IT-Admins
+-- Group-MFA-Pilot
+-- Group-Cloud-Devices
+-- Emergency-Access-Accounts# فحص العثور على Domain Controller
nltest /dsgetdc:corp.example.com
# فحص القناة الآمنة مع المجال
nltest /sc_verify:corp.example.com
# عرض حالة انضمام الجهاز المحلية والسحابية
dsregcmd /status
# عرض السياسات المطبقة
gpresult /r
# فحص اتصال HTTPS بخدمة تسجيل الدخول
Test-NetConnection login.microsoftonline.com -Port 443
# فحص حالة Replication بين Domain Controllers
repadmin /replsummaryالتشغيل وحل المشاكل الشائعة
نجاح تسجيل الدخول المحلي لا يعني بالضرورة نجاح الوصول السحابي، والعكس صحيح. لذلك يجب أولاً تحديد مكان المشكلة: جهاز المستخدم، أم Active Directory، أم المزامنة، أم Entra ID، أم التطبيق المطلوب.
| المشكلة | السبب المحتمل | الحل المقترح |
|---|---|---|
| المستخدم يدخل إلى الكمبيوتر ولا يدخل إلى Microsoft 365 | الحساب غير متزامن، أو الترخيص غير مضاف، أو اسم الدخول مختلف. | تحقق من وجود المستخدم في Entra ID وحالة المزامنة وUPN والترخيص. |
| المستخدم يدخل إلى السحابة ولا يستطيع دخول جهاز المجال | كلمة المرور المحلية مختلفة، أو الجهاز لا يصل إلى وحدة تحكم المجال. | افحص DNS والاتصال والوقت والقناة الآمنة، ثم حدد مصدر كلمة المرور. |
| ظهور حسابين للمستخدم نفسه | إنشاء حساب سحابي يدوياً قبل مزامنة الحساب المحلي أو عدم تطابق الهوية. | قارن UPN والبريد والخصائص، ثم عالج المطابقة وفق خطة موثقة قبل الدمج. |
| الجهاز يظهر مسجلاً بدلاً من منضم | تمت إضافة حساب العمل فقط، أو فشلت عملية الانضمام السحابي. | راجع نتيجة dsregcmd وحدد نوع الجهاز المطلوب قبل إعادة التسجيل. |
| سياسات المجموعة لا تُطبق | الجهاز غير منضم إلى المجال، أو OU غير صحيحة، أو مشكلة DNS وReplication. | استخدم gpresult وراجع موقع حساب الجهاز ووصوله إلى SYSVOL. |
| سياسة الوصول المشروط تمنع الجميع | تطبيق السياسة مباشرةً دون مجموعة تجريبية أو استثناء وصول طارئ. | راجع سجلات تسجيل الدخول، وعطّل السياسة عبر حساب الطوارئ، ثم أعد اختبارها تدريجياً. |
| تأخر ظهور المستخدم أو تغيير كلمة المرور | توقف خدمة المزامنة أو خطأ في النطاق المتزامن أو الاتصال. | افحص خادم المزامنة وسجلات الأخطاء وحالة آخر دورة مزامنة. |
| التطبيق القديم لا يعمل مع Entra ID | التطبيق يحتاج LDAP أو Kerberos ولا يدعم المصادقة الحديثة. | احتفظ بخدمة مجال مناسبة أو استخدم وسيطاً مدعوماً بدلاً من إجبار التطبيق على Entra ID. |
| تسجيل الدخول بطيء داخل الشركة | DNS خارجي على جهاز المجال، أو وحدة تحكم مجال بعيدة، أو سياسات ثقيلة. | استخدم DNS الداخلي، وراجع المواقع والشبكات الفرعية والسياسات وسجلات الجهاز. |
- تأكد من اسم المستخدم الكامل والجهاز والتطبيق المتأثر.
- حدد هل المشكلة محلية أم سحابية أم موجودة في الجهتين.
- افحص DNS والوقت والاتصال بوحدة تحكم المجال عند وجود Active Directory.
- افحص نوع انضمام الجهاز وحالة رمز تسجيل الدخول الأساسي.
- راجع آخر مزامنة وخصائص المستخدم والمجموعات والتراخيص.
- راجع سجلات تسجيل الدخول ونتيجة سياسة الوصول المشروط.
- نفذ تغييراً واحداً فقط، ثم اختبر وسجل النتيجة.
Best Practices لفنيي IT Support
- استخدم حساباً عادياً للعمل اليومي وحساباً إدارياً منفصلاً للمهام الحساسة.
- لا تمنح المستخدمين صلاحيات مباشرة؛ استخدم مجموعات واضحة مرتبطة بالوظيفة أو المورد.
- أنشئ حسابي وصول طارئ سحابيين، واحمهما جيداً وراقب أي استخدام لهما.
- فعّل المصادقة متعددة العوامل للحسابات، وابدأ بالحسابات الإدارية.
- اختبر الوصول المشروط على مجموعة تجريبية وفي وضع المراقبة قبل فرضه.
- لا تضع حسابات الخدمات داخل وحدات تنظيمية تُزامن تلقائياً دون حاجة واضحة.
- وحّد UPN مع نطاق الشركة لتقليل ارتباك المستخدم بين اسم المجال والبريد.
- استخدم وحدتي تحكم مجال على الأقل، وراقب DNS وReplication والنسخ الاحتياطي.
- راجع الحسابات غير النشطة وعضوية المجموعات الإدارية والتطبيقات المرتبطة دورياً.
- سجّل مالك كل تطبيق، وطريقة مصادقته، ومكان إنشاء الحساب، وتأثير تعطيله.
- لا تعتبر المزامنة نسخة احتياطية؛ فهي تنقل بعض التغييرات والأخطاء أيضاً.
- أنشئ إجراءً واضحاً لمغادرة الموظف يشمل الحساب المحلي والسحابي والجلسات والأجهزة والتراخيص.
Monthly Identity Checklist
[ ] Active Directory replication is healthy
[ ] Internal DNS is healthy
[ ] Entra synchronization completed successfully
[ ] Privileged groups were reviewed
[ ] Emergency access accounts were tested
[ ] Inactive users were reviewed
[ ] Disabled employees have no active sessions
[ ] MFA registration status was reviewed
[ ] Conditional Access changes were documented
[ ] Device join and compliance reports were reviewed
[ ] Domain Controller backup was verified
[ ] Account recovery procedure was testedمثال عملي من بيئة شركة
لنفترض وجود شركة متوسطة تضم 80 موظفاً. لديها خادم ملفات ونظام محاسبة يعملان داخل المكتب، وأجهزة ويندوز منضمة إلى المجال، بينما يستخدم الموظفون البريد وMicrosoft Teams والتخزين السحابي. بعض الموظفين يعملون من المنزل ويحتاجون إلى وصول آمن دون الاعتماد الكامل على VPN.
كانت الشركة تنشئ المستخدم مرة داخل Active Directory ومرة أخرى داخل Microsoft 365. أدى ذلك إلى اختلاف كلمات المرور، ووجود حسابات مكررة، وتأخر تعطيل حساب الموظف بعد مغادرته.
تم اعتماد تصميم هجين تكون فيه حسابات الموظفين الدائمين منشأة ومنظمة داخل Active Directory، ثم تُزامن إلى Entra ID. جرى توحيد UPN مع نطاق البريد، وإنشاء مجموعات منفصلة للموظفين والإدارة والمصادقة التجريبية. بقيت الخوادم والأجهزة المكتبية ضمن المجال، بينما جرى تجهيز الحواسيب المحمولة الجديدة للانضمام السحابي والإدارة عبر الإنترنت.
| المكوّن | طريقة الإدارة | الهدف |
|---|---|---|
| خادم الملفات والمحاسبة | Active Directory ومجموعات أمان | الحفاظ على Kerberos وصلاحيات الملفات والتطبيق الداخلي. |
| Microsoft 365 | Entra ID | تسجيل دخول موحد ومصادقة متعددة العوامل. |
| الأجهزة المكتبية | انضمام إلى المجال وسياسات المجموعة | إدارة ثابتة داخل شبكة الشركة. |
| الحواسيب المحمولة | انضمام سحابي وإدارة أجهزة | إدارة الموظفين عن بُعد دون اتصال دائم بالمكتب. |
| إيقاف الموظف | إجراء موحد للحساب والجلسات والتراخيص | إغلاق الوصول المحلي والسحابي بصورة متناسقة. |
الخلاصة العملية: لم تستبدل الشركة Active Directory بـEntra ID، بل أعطت كل نظام الدور الذي يناسبه. بقي المجال مسؤولاً عن الموارد المحلية، وأصبح Entra ID مسؤولاً عن الوصول السحابي، مع عملية موحدة لإدارة دورة حياة المستخدم.
الأسئلة الشائعة
هل Microsoft Entra ID هو نفسه Active Directory؟
لا. كلاهما يدير الهوية، لكن Active Directory خدمة مجال محلية، بينما Entra ID خدمة هوية ووصول سحابية تستخدم نموذج مصادقة مختلفاً.
هل Microsoft Entra ID هو الاسم الجديد لـAzure Active Directory؟
نعم، تم تغيير اسم Azure Active Directory إلى Microsoft Entra ID، مع بقاء دوره الأساسي في إدارة الهوية والوصول السحابي.
هل يمكن الاستغناء عن Domain Controller واستخدام Entra ID فقط؟
نعم إذا كانت التطبيقات والأجهزة تعتمد على الخدمات السحابية ولا تحتاج إلى LDAP أو Kerberos أو سياسات المجموعة أو موارد مجال داخلية.
هل تطبق Group Policy على الأجهزة المنضمة إلى Entra ID؟
لا تُطبق سياسات المجموعة التقليدية عليها بالطريقة نفسها. تُستخدم عادةً حلول إدارة الأجهزة مثل Microsoft Intune لتوزيع الإعدادات والسياسات.
ما الفرق بين Entra Join وHybrid Join؟
الجهاز في Entra Join ينضم مباشرةً إلى الهوية السحابية، بينما الجهاز الهجين يبقى منضماً إلى Active Directory ويُسجل أيضاً داخل Entra ID.
هل مزامنة Active Directory إلى Entra ID تُعد نسخة احتياطية؟
لا. المزامنة تنقل بيانات وتغييرات محددة، وقد تنقل الحذف أو الخطأ أيضاً. تحتاج Active Directory إلى نسخ احتياطي واختبارات استعادة مستقلة.
أيهما أفضل لشركة صغيرة: Active Directory أم Entra ID؟
يعتمد القرار على التطبيقات. إذا كانت الشركة سحابية بالكامل فقد يكفي Entra ID. أما إذا لديها خوادم وتطبيقات داخلية تعتمد على المجال، فستحتاج إلى Active Directory أو تصميم هجين.
الخاتمة
يُستخدم Active Directory لإدارة هوية وأجهزة وموارد بيئة ويندوز المحلية، بينما يُستخدم Microsoft Entra ID لإدارة الوصول إلى الخدمات والتطبيقات السحابية من أي مكان.
لا تتعامل مع Entra ID بوصفه وحدة تحكم مجال موجودة على الإنترنت، ولا تعتبر Active Directory وحده كافياً لحماية الوصول السحابي. لكل نظام بروتوكولاته وأدواته ونطاق مسؤوليته.
ابدأ بحصر التطبيقات والأجهزة، ثم حدد مصدر الهوية ونوع انضمام كل جهاز. إذا كانت لديك موارد محلية وخدمات سحابية، فطبّق تصميماً هجيناً تدريجياً بعد توحيد UPN وتجربة المزامنة وسياسات الأمان على مجموعة صغيرة.