ويندوز سيرفر
0

دليل أسئلة مقابلات Active Directory الجزء الأول

صورة
محمد عمر
اخر تحديث :
دليل أسئلة مقابلات Active Directory الجزء الأول

تُعد إدارة Active Directory من المهام الأساسية في أي بنية تحتية معلوماتية تعتمد على Windows Server، حيث تشكل الأساس لإدارة الهوية، والتحكم في الموارد، وتطبيق السياسات الأمنية عبر المؤسسة. ومع توسّع البيئات التقنية الحديثة وزيادة الاعتماد على الخدمات السحابية والتكامل مع Azure AD وMicrosoft 365، أصبحت المهارات المرتبطة بـ Active Directory أكثر أهمية وتعقيداً.
يقدم هذا المقال مجموعة شاملة من أسئلة المقابلات الفنية، مصممة لتغطية مختلف الجوانب الأساسية والمتقدمة في Active Directory، بدءاً من التصميم والإدارة اليومية ووصولاً إلى الأمان، المزامنة، واستكشاف الأخطاء.

🧭 Active Directory – Architecture & Core Concepts

في هذه التدوينة نستعرض أهم الأسئلة والإجابات النموذجية عن Architecture & Core Concepts في Active Directory، مع التركيز على بيئات Enterprise / جامعة كبيرة تعمل في نموذج Hybrid بين On-Premises AD DS وMicrosoft Entra ID (Azure AD).

🧩 السؤال 1: اشرح الفرق بين Forest, Domain, Tree داخل Active Directory.

🧠 الإجابة النموذجية:
في Active Directory لدينا ثلاث طبقات من الهيكل المنطقي:

  • Domain: أصغر وحدة إدارية وأمنية كاملة في AD. يحتوي على users, groups, computers, OUs, GPOs. له security boundary خاص (سياسات كلمات المرور، حسابات، صلاحيات) وغالبًا يحمل اسم DNS مثل it.university.edu.
  • Tree: مجموعة من Domains تشترك في contiguous DNS namespace مثل: university.edu, it.university.edu, eng.university.edu. هذه الـ Domains مرتبطة تلقائيًا بعلاقات transitive trusts.
  • Forest: أعلى مستوى منطقي، ويضم واحدًا أو أكثر من الـ Trees. هو فعليًا security & schema boundary: جميع الـ Domains بداخله تشترك في نفس Schema وGlobal Catalog. عادةً يكون اسم الـ Forest هو اسم الـ root domain الأول.

في بيئة جامعة كبيرة، غالبًا يتم استخدام Single Forest مع Single Domain أو أكثر (Domain للطلاب، Domain للموظفين) حسب متطلبات الأمن والإدارة.

✅ ما الذي يُتوقَّع من المرشح القوي أن يذكره؟

  • توضيح أن Forest هو أعلى مستوى وهو Schema & Global Catalog boundary.
  • توضيح أن Domain هو security boundary للسياسات والصلاحيات.
  • شرح أن Tree مجموعة Domains بنفس الـ DNS namespace مع transitive trusts.
  • ذكر مثال عملي مثل بناء Forest لجامعة مع أكثر من Domain.

⚠️ أخطاء شائعة:

  • الخلط بين مفهومي Forest وDomain واعتبارهما نفس الشيء.
  • اعتبار Tree مستوى أمني منفصل بينما هو مجرد تركيب DNS/هيكلي.
  • عدم ذكر دور Schema وGlobal Catalog ضمن خصائص الـ Forest.

🔍 أسئلة متابعة للمراجعة الذاتية:
• متى تختار Multi-Domain داخل Forest واحد بدلاً من Single Domain؟
• كيف يؤثر قرار إنشاء Forest جديد على تصميم الهويات والـ Trusts؟


🧩 السؤال 2: ما هو الـ Schema في Active Directory وكيف يتم تمديده (Schema Extension)؟

🧠 الإجابة النموذجية:
AD Schema هو التعريف الرسمي لجميع أنواع الكائنات (object classes) والخصائص (attributes) التي يمكن تخزينها داخل Active Directory. مثلًا: user, group, computer مع خصائص مثل displayName, mail, employeeID.

Schema Extension يعني إضافة object classes أو attributes جديدة، ويحدث عادةً في الحالات التالية:

  • تثبيت منتجات مثل Exchange Server أو Skype for Business أو حلول طرف ثالث.
  • الحاجة إلى تخزين بيانات إضافية (Custom Attributes) عن المستخدمين أو الأجهزة.

خطوات أساسية لتمديد الـ Schema:

  1. تحديد Schema Master FSMO role والاتصال به.
  2. أخذ system state / full backup قبل أي تعديل لأنه تغيير حساس.
  3. تنفيذ سكربت LDIF أو أوامر /PrepareSchema عند تثبيت منتج مثل Exchange.
  4. مراقبة Event Logs والتأكد من نجاح replication لبقية الـ Domain Controllers.

✅ ما الذي يُتوقَّع من المرشح القوي أن يذكره؟

  • أن Schema يعرّف كل الكائنات والـ attributes داخل AD.
  • أنه مشترك على مستوى Forest وليس لكل Domain على حدة.
  • أن Schema Extension يتم غالبًا مع منتجات مثل Exchange.
  • أهمية النسخ الاحتياطي قبل أي تعديل على الـ Schema.

⚠️ أخطاء شائعة:

  • الظن أن كل Domain له Schema خاص به.
  • تنفيذ Schema Extension مباشرة في Production بدون اختبار في بيئة Test.
  • عدم إدراك أن بعض تعديلات الـ Schema لا يمكن التراجع عنها بسهولة.

🔍 أسئلة متابعة للمراجعة الذاتية:
• كيف تتحقق من Schema Version بعد تثبيت Exchange أو منتج آخر؟
• ماذا تفعل لو فشل Schema Extension في منتصف التنفيذ؟


🧩 السؤال 3: ما هو دور Global Catalog Server ولماذا هو مهم؟

🧠 الإجابة النموذجية:
Global Catalog (GC) هو دور (Role) على Domain Controller يحتوي على:

  • نسخة كاملة من كائنات الـ Domain الخاص به.
  • نسخة جزئية (Partial Attribute Set) من كائنات جميع Domains في الـ Forest.

أهم وظائفه:

  • Universal Group Membership: يعتمد تسجيل الدخول في بيئة متعددة الـ Domains على GC لمعرفة عضوية المستخدم في Universal Groups.
  • Directory Searches: تسريع عمليات البحث في كامل الـ Forest (مثل البحث عن مستخدم أو مجموعة).
  • دعم تطبيقات مثل Exchange في البحث عن عناوين البريد على مستوى الـ Forest.

في بيئات جامعية كبيرة، يُنصَح بوجود أكثر من Global Catalog موزّعين على الـ Sites الرئيسية لتحسين أداء تسجيل الدخول والبحث.

✅ ما الذي يُتوقَّع من المرشح القوي أن يذكره؟

  • أن GC يحتوي على Partial Attribute Set لكل الكائنات في الـ Forest.
  • أهميته في Logon وUniversal Group Membership.
  • أثره على عمليات البحث، خصوصًا مع Exchange.
  • الحاجة إلى أكثر من GC في Sites مختلفة لخفض الـ latency.

⚠️ أخطاء شائعة:

  • اعتبار GC نوع مختلف من Domain Controller وليس مجرد Role مضاف.
  • وجود GC واحد فقط في Forest كبير مما يسبب مشاكل في التسجيل والبحث.
  • عدم إدراك تأثير غياب GC على تسجيل الدخول في بيئة Multi-Domain.

🔍 أسئلة متابعة للمراجعة الذاتية:
• ماذا يحدث لو لم يكن هناك GC متاح أثناء logon في بيئة تحتوي على عدة Domains؟
• كيف تجعل Domain Controller يعمل كـ Global Catalog من خلال GUI أو PowerShell؟


🧩 السؤال 4: ما وظيفة FSMO Roles ولماذا لا يمكن توزيع بعضها؟

🧠 الإجابة النموذجية:
على الرغم من أن Active Directory يعتمد على multi-master replication، إلا أن بعض العمليات الحساسة تحتاج إلى single-master لتجنب التعارض، وهنا تأتي أدوار FSMO (Flexible Single Master Operations).

الأدوار الخمسة:

  • Forest-wide:
    • Schema Master: مسؤول عن تعديل الـ Schema.
    • Domain Naming Master: مسؤول عن إضافة/حذف Domains وApplication Partitions في الـ Forest.
  • Domain-wide:
    • PDC Emulator: مسؤول عن time sync, password changes, account lockout والتوافق مع NT4.
    • RID Master: يوزّع RID pools على DCs لإنشاء SIDs جديدة بدون تعارض.
    • Infrastructure Master: يُحدّث المراجع بين الكائنات عبر Domains (مثل عضوية المجموعات).

لا يمكن توزيع هذه الأدوار على أكثر من DC في نفس الوقت لأنها مصممة لتكون unique. لو كان هناك أكثر من مالك لنفس الدور قد يحدث تعارض في إنشاء Domains جديدة أو في إصدار SIDs.

✅ ما الذي يُتوقَّع من المرشح القوي أن يذكره؟

  • ذكر الأدوار الخمسة وتقسيمها إلى Forest-wide وDomain-wide.
  • شرح دور PDC Emulator وRID Master بوضوح.
  • الإشارة إلى أوامر مثل netdom query fsmo أو PowerShell لمعرفة الأدوار.

⚠️ أخطاء شائعة:

  • عدم معرفة وظائف الأدوار الخمسة أو الخلط بينها.
  • نقل FSMO Roles عشوائيًا أو دون سبب واضح.
  • ترك كل الأدوار على Domain Controller قديم أو غير مستقر.

🔍 أسئلة متابعة للمراجعة الذاتية:
• ما الفرق بين transfer وseize لـ FSMO Roles؟ ومتى تحتاج لكل منهما؟
• ما تأثير توقف PDC Emulator على البيئة اليومية؟


🧩 السؤال 5: ما الفرق بين Logical Structure وPhysical Structure في AD؟

🧠 الإجابة النموذجية:
في Active Directory نميز بين:

  • Logical Structure: تشمل Forest, Trees, Domains, OUs, Groups, GPOs، أي تنظيم الكائنات إداريًا وأمنيًا.
  • Physical Structure: تشمل Sites, Subnets, Site Links, Domain Controllers، وتمثل البنية الفيزيائية للشبكة (مواقع، روابط WAN، سرعات الاتصال) وتأثيرها على replication وclient logon.

التصميم الجيد يفصل بين المنطق الإداري (مثل OUs المبنية على الهيكل التنظيمي) وبين البنية الفيزيائية (Sites & Subnets) مع الربط بينهما فقط لتحسين الأداء.

✅ ما الذي يُتوقَّع من المرشح القوي أن يذكره؟

  • تحديد عناصر الـ Logical: Forest, Domain, OU, GPO.
  • تحديد عناصر الـ Physical: Sites, Subnets, DCs.
  • توضيح أن OUs لا تعكس سرعة الشبكة بينما Sites تعكس topology الشبكة.

⚠️ أخطاء شائعة:

  • بناء OUs بناءً على المواقع الجغرافية بدلاً من الهيكل الإداري.
  • الخلط بين OU وSite واستخدام OU لعزل الـ traffic الفيزيائي.

🔍 أسئلة متابعة للمراجعة الذاتية:
• كيف تربط Subnets بالـ Sites لضمان تسجيل الدخول على أقرب Domain Controller؟
• أعطِ مثالًا لتصميم OU مبني على structure إداري لجامعة (Students, Staff, IT).


🧩 السؤال 6: كيف تعمل Sites and Subnets في تحسين Replication؟

🧠 الإجابة النموذجية:
Sites تمثل مواقع فيزيائية (مبانٍ، مدن، فروع) تحتوي عادة على شبكة داخلية سريعة، بينما Subnets تمثل نطاقات IP يتم ربطها بـ Site معيّن.

أهم الفوائد:

  • Replication Control: من خلال Site Links يمكن ضبط schedule وcost لـ Inter-Site Replication بحيث يتم replication عبر روابط WAN البطيئة في أوقات محددة وبشكل أقل تكرارًا.
  • Client Logon Optimization: العميل يستخدم الـ Subnet لتحديد الـ Site الخاص به ثم يتصل بأقرب Domain Controller في نفس الـ Site.
  • تحسين استهلاك الـ WAN links وتقليل الحمل على الشبكة بين الفروع.

✅ ما الذي يُتوقَّع من المرشح القوي أن يذكره؟

  • ربط Subnets بالـ Sites لاختيار أقرب Domain Controller.
  • استخدام Site Links للتحكم في Inter-Site Replication.
  • ضبط cost وschedule للروابط البطيئة (WAN).

⚠️ أخطاء شائعة:

  • نسيان ربط Subnet بـ Site مما يؤدي لاختيار DC عشوائي.
  • استخدام Site واحد فقط في بيئة متعددة الفروع وإلغاء ميزة التحكم في Replication.

🔍 أسئلة متابعة للمراجعة الذاتية:
• كيف تتحقق أن client يستخدم الـ Site الصحيح؟
• كيف تضبط Replication بين موقعين متصلين برابط WAN بطيء؟


🧩 السؤال 7: ما الفرق بين Domain Functional Level وForest Functional Level؟

🧠 الإجابة النموذجية:
Functional Levels تحدد مجموعة المزايا المتاحة في Active Directory بناءً على إصدارات Windows Server المستخدمة كـ Domain Controllers.

  • Domain Functional Level (DFL): يحدد المزايا داخل Domain معين، مثل دعم Fine-Grained Password Policies أو DFS-R لـ SYSVOL. يعتمد على أقل نسخة Windows مستخدمة كـ DC داخل هذا الـ Domain.
  • Forest Functional Level (FFL): يحدد المزايا على مستوى الـ Forest بالكامل، مثل بعض أنواع Forest Trusts أو ميزات Cross-Forest. يعتمد على أقل DFL بين جميع Domains في الـ Forest.

عند رفع الـ Functional Level يجب التأكد من عدم وجود Domain Controllers بإصدارات أقدم، وغالبًا لا يمكن الرجوع للخلف بسهولة بعد عملية الرفع.

✅ ما الذي يُتوقَّع من المرشح القوي أن يذكره؟

  • DFL على مستوى Domain، وFFL على مستوى Forest.
  • الإشارة إلى أن كلاهما يعتمد على إصدارات Domain Controllers.
  • ذكر مثال لميزة تحتاج مستوى وظيفي معين مثل DFS-R for SYSVOL.

⚠️ أخطاء شائعة:

  • الاعتقاد أن Functional Level يتعلق بإصدارات أجهزة الـ Clients وليس DCs.
  • رفع Functional Level بدون التأكد من ترقية جميع DCs.

🔍 أسئلة متابعة للمراجعة الذاتية:
• كيف تتحقق من DFL وFFL باستخدام GUI أو PowerShell؟
• ما المخاطر العملية عند رفع FFL في بيئة تحتوي على عدة Domains؟


🧩 السؤال 8: كيف يتم تصميم Multi-Forest Architecture في بيئات الجامعات؟

🧠 الإجابة النموذجية:
يتم اللجوء إلى Multi-Forest عندما توجد حدود قوية في الملكية أو الأمان أو المتطلبات القانونية بين كيانات مختلفة (مثل: الجامعة، المستشفى الجامعي، مراكز بحثية مستقلة).

سيناريوهات شائعة:

  • Resource Forest + Account Forest: Forest للحسابات (students, staff) وآخر للتطبيقات الحرجة مثل Exchange أو أنظمة الهوية.
  • Forest منفصل للمستشفى الجامعي لأسباب أمنية وامتثال قوانين صحية، مع وجود Forest Trust مع Forest الجامعة.
  • Forest خاص بالـ Test/Development معزول عن Production لأغراض الاختبار.

عند تصميم Multi-Forest يجب التخطيط لـ:

  • Trusts (الاتجاه، نوع المصادقة، selective vs full).
  • Identity Management Strategy (sync أو separate identities أو both).
  • تأثير ذلك على SSO والتطبيقات المشتركة وAzure AD Connect.

✅ ما الذي يُتوقَّع من المرشح القوي أن يذكره؟

  • أن Multi-Forest يُستخدم لحدود أمان/ملكية قوية بين الكيانات.
  • ذكر نماذج مثل Resource/Account Forest model.
  • الحاجة إلى Forest Trust وتخطيط SSO وهجرة الهويات.

⚠️ أخطاء شائعة:

  • إنشاء Multi-Forest دون سبب قوي مما يزيد التعقيد الإداري والتقني.
  • عدم التخطيط لهوية موحدة أو آلية Sync بين Forests.

🔍 أسئلة متابعة للمراجعة الذاتية:
• متى تفضّل إنشاء Domain جديد داخل Forest بدلاً من Forest جديد؟
• كيف يؤثر Multi-Forest على تصميم Azure AD Connect في بيئة Hybrid؟


🧩 السؤال 9: ما هو الفرق بين AD DS وAD LDS؟

🧠 الإجابة النموذجية:
AD DS (Active Directory Domain Services):

  • الخدمة الأساسية التي توفّر Domains, Forests, Kerberos/NTLM, Group Policy.
  • تُستخدم لإدارة هويات المستخدمين والأجهزة في بيئة Windows Domain.
  • أساس بيئة On-Premises للأجهزة المنضمة إلى Domain.

AD LDS (Active Directory Lightweight Directory Services):

  • Directory خفيف لا يعرض Domains أو Forests بنفس نموذج AD DS.
  • مخصص للتطبيقات التي تحتاج Directory مستقل عن بنية الـ Domain.
  • يمكن تشغيل عدة instances على نفس السيرفر، وكل instance له Schema خاص.

باختصار: AD DS لإدارة بيئة Windows Domain، بينما AD LDS خيار مرن لتطبيقات تحتاج Directory بدون بنية Domain كاملة.

✅ ما الذي يُتوقَّع من المرشح القوي أن يذكره؟

  • أن AD DS يوفر Domain/Forest + Kerberos + GPO.
  • أن AD LDS خفيف وموجه للتطبيقات، ومستقل عن Domain join.
  • إمكانية وجود عدة AD LDS instances على نفس السيرفر.

⚠️ أخطاء شائعة:

  • اعتبار AD LDS بديلًا كاملًا عن AD DS كـ Domain Controller.
  • الخلط بين أدوار AD DS وAD LDS في تصميم الحلول.

🔍 أسئلة متابعة للمراجعة الذاتية:
• اذكر مثالًا لاستخدام AD LDS في تطبيق جامعي أو نظام بوابة طلابية.
• ما الفرق في إدارة Schema بين AD DS وAD LDS؟


🧩 السؤال 10: اشرح مفهوم Trust Relationships وأنواعها.

🧠 الإجابة النموذجية:
Trust Relationship هي علاقة ثقة بين Domains أو Forests تسمح للمستخدم من جهة معينة بالوصول إلى موارد الجهة الأخرى وفقًا للصلاحيات.

أنواع رئيسية:

  • Parent-Child Trust: تلقائي بين Domain رئيسي وفرعي في نفس الـ Forest، يكون عادة two-way transitive.
  • Tree-Root Trust: تلقائي بين Trees داخل نفس Forest، أيضًا two-way transitive.
  • External Trust: بين Domain في Forest وآخر في Forest مختلف أو NT4 domain، وغالبًا non-transitive.
  • Forest Trust: بين Forestين مختلفين، يمكن أن يكون one-way أو two-way transitive بينهما.
  • Shortcut Trust: لتقليل مسار المصادقة بين Domains متباعدة في نفس Forest أو بين Forests.
  • Realm Trust: بين AD Domain وKerberos Realm (مثل بيئات Unix).

يجب أيضًا فهم الفرق بين: transitive vs non-transitive وone-way vs two-way لضبط الثقة حسب مبدأ least privilege.

✅ ما الذي يُتوقَّع من المرشح القوي أن يذكره؟

  • التمييز الواضح بين one-way وtwo-way، وtransitive وnon-transitive.
  • معرفة الأنواع: Parent-Child, Forest, External, Shortcut, Realm.
  • ربط Forest Trust بالسيناريوهات بين مؤسستين مختلفتين أو جامعة ومزود خارجي.

⚠️ أخطاء شائعة:

  • افتراض أن وجود Trust يعني صلاحيات كاملة تلقائيًا بين الطرفين.
  • إنشاء Trusts كثيرة دون تخطيط مما يعقّد مسارات المصادقة.

🔍 أسئلة متابعة للمراجعة الذاتية:
• كيف تتحقق من Trusts الحالية بين Domains باستخدام GUI أو أوامر مثل netdom؟
• ما تأثير تكوين Trust خاطئ على تسجيل الدخول العابر بين Forests؟

-------------------------

🧭 Active Directory – Identity Lifecycle & Provisioning

في هذه التدوينة نستعرض أهم الأسئلة والإجابات النموذجية المتعلقة بـ Identity Lifecycle & Provisioning داخل Active Directory في بيئات Enterprise / جامعات كبيرة، حيث يتم إدارة عشرات الآلاف من الحسابات (Students, Staff, Services) مع تكامل مع HR Systems وMicrosoft Entra ID.

🧩 السؤال 1: صف الـ Identity Lifecycle من Provisioning إلى Deprovisioning داخل AD.

🧠 الإجابة النموذجية:
دورة حياة الهوية Identity Lifecycle داخل Active Directory تمر عادة بالمراحل التالية:

  1. Provisioning (Create): إنشاء حساب المستخدم بناءً على مصدر موثوق مثل HR System أو نظام القبول للطلاب. يتم تعيين username, UPN, email, groups, OU تلقائيًا حسب السياسات.
  2. Update (Move / Change): تعديل خصائص الحساب مع تغيّر حالة الشخص (ترقية وظيفية، انتقال قسم، تغيير كلية، إلخ) مثل نقل الحساب إلى OU جديدة، تحديث department, title، تعديل group membership.
  3. Enable / Disable: أثناء الإجازات الطويلة أو الإيقاف المؤقت يمكن Disable Account بدون حذفه، للحفاظ على البيانات مع منع الوصول.
  4. Deprovisioning (Offboarding): عند انتهاء علاقة الشخص بالمؤسسة (تخرج / استقالة / انتهاء عقد) يتم:
    • تعطيل الحساب (Disable) ونقل الحساب إلى OU خاصة بالحسابات غير النشطة.
    • إزالة الحساب من جميع المجموعات الحساسة.
    • إعادة تعيين Home Folder وMailbox (أرشفة / نقل للمدير).
  5. Delete / Archive: بعد فترة احتفاظ محددة (Retention Period) يتم حذف الحساب نهائيًا مع الاحتفاظ بالـ logs والـ backups حسب سياسات الـ Compliance.

في بيئات احترافية تُدار هذه الدورة غالبًا عبر Identity Management / IAM System وأتمتة باستخدام PowerShell أو Identity Governance.

✅ ما المتوقع من المرشح القوي؟

  • ذكر المراحل الأساسية: Create, Update, Disable, Deprovision, Delete.
  • ربط العملية بمصدر بيانات مثل HR أو Student Information System.
  • الإشارة إلى الأتمتة (PowerShell, Scripts, IDM Tools).
  • توضيح أهمية Retention قبل الحذف النهائي.

⚠️ أخطاء شائعة:

  • حذف الحساب مباشرة بعد مغادرة الشخص بدون فترة احتفاظ.
  • الاعتماد على إجراءات يدوية بالكامل (عدم وجود عملية موحدة).
  • ترك الحساب مفعّل بعد مغادرة الموظف لفترة طويلة.

🔍 أسئلة مراجعة:
• كيف تربط AD مع HR System لضمان Provisioning أوتوماتيكي؟
• ماذا تفعل بحسابات الطلاب بعد التخرج في جامعة كبيرة؟


🧩 السؤال 2: ما مبادئ AGDLP / AGUDLP لإدارة الـ Group Membership؟

🧠 الإجابة النموذجية:
مبدأ AGDLP / AGUDLP نمط تصميم (Best Practice) لإدارة الصلاحيات في بيئة Active Directory بطريقة منظمة وقابلة للتوسع.

AGDLP: اختصار لـ:

  • A = Accounts (User/Computer Accounts)
  • G = Global Groups
  • DL = Domain Local Groups
  • P = Permissions on Resources

الفكرة: Accounts تُضاف إلى Global Groups بناءً على الدور الوظيفي (Role/Department)، ثم تُضاف هذه Global Groups إلى Domain Local Groups المرتبطة بالـ Resources (مثل مجلدات على File Server)، ثم تُطبَّق Permissions على Domain Local Groups فقط.

AGUDLP يضيف Universal Groups في بيئات Multi-Domain داخل نفس Forest، حيث:

  • Accounts → Global Group → Universal Group → Domain Local Group → Permissions

في بيئة جامعة كبيرة، هذا النمط يسهل إدارة صلاحيات المجلدات، التطبيقات، وSharePoint بناءً على الكلية أو القسم أو الدور الوظيفي (Faculty, Students, HR, Finance).

✅ ما المتوقع من المرشح القوي؟

  • شرح واضح لـ AGDLP ومعنى كل حرف.
  • الإشارة إلى AGUDLP في بيئات Multi-Domain.
  • ذكر مثال عملي لملف Resource (Shared Folder).

⚠️ أخطاء شائعة:

  • إعطاء Permissions مباشرة على Users بدلاً من Groups.
  • الفوضى في استخدام Global/Domain Local/Universal بدون سياسة واضحة.

🔍 أسئلة مراجعة:
• كيف تطبق AGDLP على Folder لبيانات قسم IT في الجامعة؟
• متى تحتاج لاستخدام Universal Groups في التصميم؟


🧩 السؤال 3: ما الفرق بين Security Groups وDistribution Groups؟

🧠 الإجابة النموذجية:
Security Group:

  • تُستخدم لمنح أو منع الوصول إلى Resources (ملفات، طابعات، تطبيقات، GPOs).
  • يمكن استخدامها أيضًا كـ mail-enabled group في Exchange.

Distribution Group:

  • تُستخدم لغرض البريد الإلكتروني فقط، مثل Mailing Lists.
  • لا يمكن استخدامها لتعيين Permissions على Resources.

في بيئة جامعة: Security Group لمجلد "Dean Documents" مثلاً، وDistribution Group

✅ ما المتوقع من المرشح القوي؟

  • تمييز واضح أن Security Group = Access Control.
  • تمييز أن Distribution Group = Email فقط.
  • ذكر أن Security يمكن أن تكون Mail-Enabled أيضاً.

⚠️ أخطاء شائعة:

  • محاولة استخدام Distribution Group للصلاحيات على مجلدات.
  • عدم وجود Naming Standard واضح يفرق بينهما.

🔍 أسئلة مراجعة:
• كيف تفرق بالتسمية بين Security وDistribution في بيئة كبيرة؟
• ماذا يحدث لو حذفت Security Group مستخدمة في Folder Permissions؟


🧩 السؤال 4: كيف تتم إدارة Student Accounts التي تتجدد سنويًا؟

🧠 الإجابة النموذجية:
في الجامعات، Student Accounts تُمثل الحجم الأكبر من الحسابات وتتغير سنويًا (دفعات جديدة، تخرج، انقطاع). إدارة فعّالة تتضمن:

  • ربط AD مع Student Information System (SIS) أو نظام القبول كـ Source of Truth.
  • إنشاء الحسابات تلقائيًا عبر scripts أو Identity Management tool بناءً على بيانات الدفعات الجديدة.
  • وضع الطلاب في OUs خاصة حسب السنة (Year), الكلية (Faculty), البرنامج (Program).
  • تعيين group memberships حسب المقررات أو الكليات (Access لـ LMS, Wi-Fi, Labs).
  • عند التخرج: نقل الحساب إلى OU "Alumni" أو "Graduated", تقييد الخدمات مع الاحتفاظ بالبريد فترة معينة.

عادة يتم تشغيل Daily/Weekly Job يقرأ من SIS ويُحدِّث حالة الطلاب (Active, Suspended, Graduated).

✅ ما المتوقع من المرشح القوي؟

  • ذكر تكامل مع SIS/ERP كمصدر رئيسي للطلاب.
  • الإشارة إلى الأتمتة وعدم الاعتماد على الإدخال اليدوي.
  • وجود OU/Groups مصممة خصيصًا للطلاب حسب الدفعة/البرنامج.

⚠️ أخطاء شائعة:

  • ترك حسابات الطلاب القديمة مفعّلة بلا رقابة بعد التخرج.
  • عدم وجود ربط آلي مع نظام أكاديمي.

🔍 أسئلة مراجعة:
• كيف تصمم OU Structure للطلاب بحسب السنة والكلية؟
• ما السياسة المناسبة لبريد الطالب بعد التخرج (حذف؟ تحويل لـ personal؟ احتفاظ؟).


🧩 السؤال 5: كيف تقوم بأتمتة User Provisioning باستخدام PowerShell؟

🧠 الإجابة النموذجية:
أتمتة User Provisioning في AD باستخدام PowerShell تعتمد على:

  1. استخدام ActiveDirectory Module (الأمر Import-Module ActiveDirectory).
  2. قراءة بيانات المستخدمين من مصدر مثل CSV, Database, API.
  3. استخدام أوامر مثل: New-ADUser لإنشاء المستخدم، Add-ADGroupMember لإضافته إلى Groups، وتعيين خصائص مثل UPN, email, department, manager.
  4. تحديد OU المستهدفة حسب الكلية/القسم/الموقع من خلال منطق داخل السكربت.
  5. توحيد Naming Convention عبر السكربت (مثل firstname.lastname أو StudentID).

مثال مبسط (بدون كود حقيقي هنا في المقال) يمكنه إنشاء الحساب، تعيين كلمة مرور مبدئية، فرض خيار User must change password at next logon، وإرساله إلى المسؤول بالبريد.

✅ ما المتوقع من المرشح القوي؟

  • الإشارة إلى ActiveDirectory Module وNew-ADUser.
  • ذكر مصدر بيانات (CSV/DB) وقراءة البيانات منه.
  • الإشارة إلى إضافة المستخدم إلى Groups المناسبة أوتوماتيكيًا.

⚠️ أخطاء شائعة:

  • إنشاء المستخدمين بشكل يدوي من ADUC دون أي أتمتة.
  • عدم التحقق من الأخطاء (Error Handling) داخل السكربت.

🔍 أسئلة مراجعة:
• كيف تتعامل مع إعادة تشغيل السكربت بدون إنشاء حسابات مكررة؟
• كيف تبني Template Standard لحسابات موظفي قسم معين؟


🧩 السؤال 6: كيف تتم إدارة Service Accounts بشكل آمن؟

🧠 الإجابة النموذجية:
Service Accounts تُستخدم لتشغيل الخدمات والتطبيقات بدلاً من الحسابات البشرية. إدارتها بشكل آمن تتضمن:

  • تمييزها بوضوح عن المستخدمين العاديين من خلال Naming Convention (مثلاً: svc_sql_app1).
  • تقليل الصلاحيات (Least Privilege) – إعطاء الحد الأدنى فقط من الحقوق اللازمة.
  • استخدام Managed Service Accounts (MSA) أو Group Managed Service Accounts (gMSA) حيث يتم إدارة كلمة المرور تلقائيًا من AD.
  • منع تسجيل الدخول التفاعلي (Interactive Logon) لهذه الحسابات (Logon locally / RDP).
  • مراقبة استخدام هذه الحسابات عبر Audit Policies وSIEM.

في الأنظمة الحديثة، الاعتماد على gMSA أصبح Best Practice لتجنب إدارة كلمات مرور يدوية معقدة وطويلة.

✅ ما المتوقع من المرشح القوي؟

  • ذكر MSA/gMSA كأفضل ممارسة.
  • التأكيد على منع Interactive Logon.
  • ذكر مبدأ Least Privilege وتحديد الصلاحيات بدقة.

⚠️ أخطاء شائعة:

  • استخدام حسابات Administrators كـ Service Accounts.
  • مشاركة كلمة المرور نفسها بين عدة خدمات وخوادم.
  • عدم تغيير كلمات المرور لفترات طويلة.

🔍 أسئلة مراجعة:
• في أي سيناريو تفضّل gMSA على Service Account عادي؟
• كيف تمنع Service Account من تسجيل الدخول على أجهزة المستخدمين؟


🧩 السؤال 7: كيف يتم التعامل مع Orphaned Accounts أو Dormant Accounts؟

🧠 الإجابة النموذجية:
Dormant / Orphaned Accounts هي حسابات غير مستخدمة أو لا تملك صاحبًا فعليًا (مثل موظف غادر). لإدارتها:

  • استخدام تقارير مثل: حسابات لم تسجّل الدخول منذ X يوم بناءً على lastLogon, lastLogonTimestamp.
  • مقارنة الحسابات مع بيانات HR/SIS واكتشاف الحسابات التي لم تعد مرتبطة بشخص فعلي.
  • تطبيق سياسة: مرحلة 1: Disable + نقل إلى OU مخصصة (Disabled_Users). مرحلة 2: بعد فترة احتفاظ، حذف الحساب نهائيًا.
  • مراقبة Dormant Admin Accounts بشكل خاص لأنها هدف شائع للهجمات.

يُفضّل أتمتة هذه العملية عبر PowerShell وScheduled Tasks أو استخدام حلول Identity Governance.

✅ ما المتوقع من المرشح القوي؟

  • استخدام lastLogonTimestamp/Reports لتحديد الحسابات غير النشطة.
  • تطبيق Disable أولاً ثم حذف بعد فترة.
  • التركيز على Dormant Privileged Accounts كمخاطر أمنية.

⚠️ أخطاء شائعة:

  • ترك الحسابات غير النشطة لسنوات في AD.
  • حذف حسابات بدون مراجعة ارتباطها بـ groups أو تطبيقات.

🔍 أسئلة مراجعة:
• ما الفترة الزمنية المناسبة لتصنيف الحساب على أنه Dormant؟
• كيف تتأكد أن حذف الحساب لن يكسر خدمة أو تطبيقًا معينًا؟


🧩 السؤال 8: ما هي أفضل Practices لتسمية الحسابات (Naming Standards)؟

🧠 الإجابة النموذجية:
Naming Standards ضرورية في بيئات كبيرة لتقليل الفوضى ومنع التكرار. بعض أفضل الممارسات:

  • توحيد صيغة username/UPN للموظفين مثل: firstname.lastname أو f.lastname.
  • للطلاب: استخدام StudentID أو صيغة مميزة مثل s123456.
  • للحسابات الخدمية (Service): بادئة ثابتة مثل svc_ أو app_.
  • للمجموعات: تضمين نوع المجموعة والغرض مثل: SG_File_HR_Read, DG_Mail_AllStudents.
  • توثيق Naming Convention في مستند رسمي ومراجعته دوريًا.

الهدف هو أن يكون اسم الحساب أو الـ group واضحًا بدون الحاجة للبحث الطويل لمعرفة وظيفته.

✅ ما المتوقع من المرشح القوي؟

  • ذكر أمثلة عملية على Naming Standards.
  • التمييز بين موظفين، طلاب، Service Accounts، Groups.
  • الإشارة إلى التوثيق الرسمي للمعايير.

⚠️ أخطاء شائعة:

  • ترك التسمية عشوائية تعتمد على المسؤول.
  • استخدام أحرف عربية أو مسافات غير متسقة تسبب مشاكل في بعض الأنظمة.

🔍 أسئلة مراجعة:
• كيف تُحدِّث Naming Standard قديم دون كسر الأنظمة المتكاملة؟
• هل تعتمد نفس الـ naming للحساب On-Prem وEntra ID؟ ولماذا؟


🧩 السؤال 9: كيف يتم إدارة Shared Accounts في بيئة الجامعة؟

🧠 الإجابة النموذجية:
Shared Accounts مثل حسابات المختبر، حساب الاستقبال، حساب المعامل، تمثل تحديًا أمنيًا لأن عدة أشخاص يستخدمون نفس الهوية.

أفضل الممارسات:

  • تجنبها قدر الإمكان واستبدالها بـ individual accounts + group-based access.
  • عند الحاجة لها (مثل أجهزة Labs):
    • تقييد استخدامها لأجهزة محددة فقط (Logon To).
    • تقييد الصلاحيات لأقل مستوى ممكن.
    • تغيير كلمة المرور دوريًا وإدارتها مركزيًا.
  • عدم استخدامها للوصول إلى أنظمة حرجة أو بيانات حساسة.
  • توثيق من يملك الحق في استخدام هذا الحساب (Owner / Approver).

في كثير من الحالات يمكن استخدام حلول مثل VDI أو Session-based access بدلاً من Shared Account واحد.

✅ ما المتوقع من المرشح القوي؟

  • إظهار حساسية Shared Accounts أمنيًا.
  • اقتراح بدائل (individual + groups + proper access control).
  • تقييد الأجهزة والصلاحيات عند استخدام Shared Account.

⚠️ أخطاء شائعة:

  • استخدام حساب Shared بامتيازات عالية (مثل Local Admin على عدة أجهزة).
  • عدم تتبع من استخدم الحساب ومتى.

🔍 أسئلة مراجعة:
• كيف توفّر بيئة Lab للطلاب بدون Shared Account ذو Password واحدة للجميع؟
• ما دور Group Policy في ضبط Shared Accounts على أجهزة Labs؟


🧩 السؤال 10: ما هي Policies للاحتفاظ أو حذف الحسابات بعد التخرج أو الاستقالة؟

🧠 الإجابة النموذجية:
سياسات الاحتفاظ Account Retention Policies تختلف حسب نوع الحساب (موظف / طالب) ومتطلبات القوانين والـ Compliance (مثل قوانين التعليم، قوانين العمل).

نموذج شائع:

  • Employees:
    • تعطيل الحساب فور إنهاء العقد (Disable).
    • تحويل البريد للمدير أو قسم HR لفترة محددة.
    • الاحتفاظ بالحساب في OU خاصة لمدة 6–12 شهر لأغراض الأرشفة أو التدقيق.
    • حذف الحساب نهائيًا بعد انتهاء فترة الاحتفاظ، مع الاحتفاظ بـ logs.
  • Students:
    • تعطيل بعض الخدمات فور التخرج (مثل Wi-Fi، Labs).
    • اختياريًا: إبقاء البريد لفترة (مثلاً 1–2 سنة كـ Alumni Email).
    • بعد فترة، تعطيل الحساب بالكامل ثم حذفه وفق سياسة الجامعة.

يجب أن تكون هذه السياسات موثقة ومعتمدة من Legal, HR, IT Security ومطبقة آليًا قدر الإمكان لتجنب الأخطاء البشرية.

✅ ما المتوقع من المرشح القوي؟

  • التمييز بين سياسات الموظفين والطلاب.
  • الإشارة إلى Disabled + Retention OU قبل الحذف النهائي.
  • ربط السياسة بمتطلبات قانونية/امتثال (Compliance).

⚠️ أخطاء شائعة:

  • حذف الحساب فورًا بدون فترة احتفاظ أو أرشفة للبريد.
  • ترك الحساب مفعّل بعد التخرج أو الاستقالة لفترة غير محددة.

🔍 أسئلة مراجعة:
• كيف توثّق وتوافق على Retention Policy مع HR وLegal؟
• كيف تطبّق هذه السياسة بالتكامل مع Entra ID وM365 (Mailbox, OneDrive, Teams)؟



تعديل المقال
الأقسام

مقالات قد تهمك

تعليقات



    حجم الخط
    +
    16
    -
    تباعد السطور
    +
    2
    -