Active Directory: الدليل المرجعي الشامل لإدارة Windows Server
عندما تكبر بيئة Windows داخل أي شركة، تظهر مشكلة الإدارة اليدوية بسرعة: حسابات محلية متفرقة، كلمات مرور مختلفة، صلاحيات غير موحدة، أجهزة لا يمكن التحكم بها، وسياسات أمنية يصعب فرضها. في بيئة Workgroup قد تستطيع إدارة خمسة أو عشرة أجهزة بشكل مقبول، لكن عند عشرات أو مئات الأجهزة تصبح الإدارة اليدوية عبئاً أمنياً وتشغيلياً.
هنا يأتي دور Active Directory Domain Services أو AD DS. فهو خدمة دليل مركزية وموزعة في الوقت نفسه: مركزية من ناحية الإدارة والمنطق الأمني، وموزعة لأن البيانات يتم نسخها بين أكثر من Domain Controller لضمان الاستمرارية والتوافر. من خلال AD DS يمكن للمستخدم تسجيل الدخول بحساب واحد، ويمكن لفريق IT إدارة المستخدمين والأجهزة والمجموعات والسياسات والصلاحيات من نقطة تحكم موحدة.
هذا المقال مصمم ليكون مرجعاً: ستجد شرحاً للمفاهيم الأساسية، ثم البنية الداخلية، ثم البروتوكولات، ثم أفضل تصميم، ثم أوامر الإدارة والتشخيص، ثم الأمن والنسخ الاحتياطي والمشاكل الشائعة. الهدف أن تستخدمه كدليل مراجعة أثناء بناء بيئة Active Directory أو تشخيص مشكلة في بيئة قائمة.
ما هو Active Directory ومتى تحتاجه؟
Active Directory هو Directory Service من Microsoft يستخدم لتخزين معلومات عن كائنات الشبكة مثل المستخدمين، الأجهزة، المجموعات، الطابعات، الخوادم، والسياسات. يتم تخزين هذه المعلومات ضمن بنية هرمية ومنطقية، ويستطيع المستخدمون والتطبيقات الوصول إليها حسب الصلاحيات المحددة.
الخادم الذي يستضيف دور Active Directory Domain Services يسمى Domain Controller. في بيئة إنتاجية لا يُنصح أبداً بالاعتماد على Domain Controller واحد فقط؛ الأفضل وجود اثنين على الأقل حتى لا يصبح تسجيل الدخول وDNS وGroup Policy نقطة فشل واحدة.
| العنصر | وظيفته | الفائدة العملية لفريق IT |
|---|---|---|
| Domain Controller | يستضيف AD DS ويقدّم المصادقة وDNS غالباً | تسجيل دخول مركزي وإدارة موحدة للمستخدمين والأجهزة. |
| Domain | وحدة إدارية وأمنية تحتوي Users وComputers وGroups وGPOs | تنظيم البيئة وتطبيق سياسات موحدة. |
| Organizational Unit | حاوية تنظيمية قابلة لربط GPO وتفويض الإدارة | تقسيم المستخدمين والأجهزة حسب الأقسام أو الوظائف. |
| Security Group | تجميع المستخدمين أو الأجهزة أو المجموعات | منح الصلاحيات للمجموعة بدل منحها لكل مستخدم منفرد. |
| Group Policy | تطبيق إعدادات وسياسات على الأجهزة والمستخدمين | فرض Password Policy وFirewall وBitLocker والطابعات والإعدادات الأمنية. |
من المهم تصحيح فكرة شائعة: لا يوجد رقم سحري يقول إن Workgroup يدعم 20 جهازاً فقط في كل الحالات. الرقم 20 يظهر غالباً في سياقات قيود اتصالات Windows Client أو حدود عملية في بيئات صغيرة، وليس كحد هندسي لـ Workgroup نفسها. عملياً، Workgroup مناسب للبيئات الصغيرة جداً، بينما Domain مناسب عندما تحتاج إلى إدارة مركزية وسياسات وصلاحيات قابلة للتوسع.
| الجانب | Workgroup | Active Directory Domain |
|---|---|---|
| إدارة الحسابات | محلية على كل جهاز | مركزية عبر Domain Controllers متعددة. |
| تسجيل الدخول | كل جهاز يتحقق محلياً | مصادقة عبر Kerberos/NTLM حسب الحالة. |
| السياسات | يدوية أو Local Policy | Group Policy على مستوى Site/Domain/OU. |
| التوسع | مناسب عملياً لعدد صغير جداً | مناسب لعشرات أو آلاف الأجهزة عند التصميم الصحيح. |
| الأمان | غير مركزي ويصعب تدقيقه | مركزي مع Auditing وGroups وDelegation. |
البنية المنطقية والفيزيائية في Active Directory
لفهم AD بعمق، يجب التمييز بين البنية المنطقية والبنية الفيزيائية. البنية المنطقية تشمل Forest وDomain وOU وObjects. أما البنية الفيزيائية فتشمل Domain Controllers وSites وSubnets وReplication Links.
الـ Forest هي أعلى حاوية في Active Directory وتمثل حدوداً أمنية مهمة. كل Domains داخل نفس Forest تشترك في Schema وConfiguration وGlobal Catalog وعلاقات Trust داخلية. لذلك لا تنشئ أكثر من Forest إلا عند وجود سبب أمني أو تنظيمي قوي، مثل فصل كامل بين شركتين أو متطلبات قانونية تمنع الثقة الكاملة.
الـ Domain هو المكان الذي توجد فيه حسابات المستخدمين والأجهزة والمجموعات والسياسات. في معظم الشركات الصغيرة والمتوسطة، Domain واحد مصمم جيداً أفضل من عدة Domains معقدة. يمكن حل كثير من متطلبات التنظيم باستخدام OUs وGroups وDelegation بدلاً من إنشاء Domains إضافية.
الـ Organizational Unit ليست مجرد مجلد شكلي. قيمتها الأساسية أنها تسمح بربط GPO وتفويض إدارة جزء محدد من الدومين. مثلاً يمكن إعطاء مسؤول فرع صلاحية Reset Password لمستخدمي فرعه فقط دون منحه صلاحيات Domain Admin.
corp.example.com
├── OU=Users
│ ├── OU=IT
│ ├── OU=Finance
│ ├── OU=HR
│ └── OU=Sales
├── OU=Computers
│ ├── OU=Workstations
│ └── OU=Laptops
├── OU=Servers
│ ├── OU=Domain Controllers
│ ├── OU=File Servers
│ └── OU=Application Servers
├── OU=Groups
└── OU=Service Accountsالحاويات الافتراضية مثل CN=Users وCN=Computers لا توفر نفس مرونة OUs في ربط السياسات والتفويض. لذلك من أفضل الممارسات إنشاء OUs خاصة بك ثم استخدام أوامر مثل redircmp وredirusr لتغيير مكان إنشاء الأجهزة والمستخدمين الجدد افتراضياً.
redircmp "OU=Workstations,OU=Computers,DC=corp,DC=example,DC=com"
redirusr "OU=Users,DC=corp,DC=example,DC=com"
Kerberos وLDAP وDNS: قلب عمل الدومين
ثلاثة مكونات يجب فهمها جيداً: DNS ليجد الجهاز Domain Controller والخدمات، Kerberos لتسجيل الدخول والحصول على Tickets، وLDAP لقراءة وكتابة بيانات الدليل.
DNS في بيئة AD ليس مجرد ترجمة أسماء إلى IP. أجهزة الدومين تعتمد على سجلات SRV Records لاكتشاف Domain Controllers وخدمات LDAP وKerberos. إذا كان DNS غير صحيح، ستظهر مشاكل مثل فشل Join Domain، بطء Login، عدم تطبيق GPO، أو فشل Replication.
nslookup -type=SRV _ldap._tcp.dc._msdcs.corp.example.com
nslookup -type=SRV _kerberos._tcp.corp.example.com
ipconfig /all
nltest /dsgetdc:corp.example.comKerberos هو بروتوكول المصادقة الأساسي في AD. بدلاً من إرسال كلمة المرور عبر الشبكة، يستخدم مفهوماً يعتمد على Tickets. عند تسجيل الدخول، يتواصل الجهاز مع KDC الموجود على Domain Controller ويحصل على Ticket Granting Ticket. لاحقاً، عند الوصول إلى File Server أو SQL Server، يتم طلب Service Ticket للخدمة المطلوبة.
LDAP هو البروتوكول المستخدم للاستعلام عن بيانات الدليل: المستخدمين، المجموعات، الخصائص، Distinguished Names، وغيرها. ليس كل استخدام لـ LDAP عبر المنفذ 389 خطأ بحد ذاته؛ المشكلة الأساسية هي Simple Bind غير مشفر أو اتصالات LDAP غير موقعة. في البيئات الحديثة يوصى بتفعيل LDAP Signing وChannel Binding، واستخدام LDAPS أو StartTLS عند الحاجة.
| البروتوكول | المنفذ | الاستخدام | التوصية |
|---|---|---|---|
| LDAP | 389 | استعلامات LDAP عادية أو SASL | لا تستخدم Simple Bind غير مشفر. فعّل Signing أو StartTLS. |
| LDAPS | 636 | LDAP فوق TLS/SSL | مناسب للتطبيقات التي تحتاج اتصالاً مشفراً واضحاً. |
| Global Catalog | 3268 | بحث عبر Forest | استخدم 3269 إذا احتجت TLS. |
| Global Catalog LDAPS | 3269 | بحث مشفر عبر Forest | مفيد لتطبيقات Identity وDirectory Search. |
CN=Ali Hasan,OU=IT,OU=Users,DC=corp,DC=example,DC=comReplication وSites وGlobal Catalog
Active Directory يستخدم نموذج Multi-Master Replication، أي أن أكثر من Domain Controller قابل للكتابة يمكنه استقبال التغييرات، ثم يتم نسخها إلى باقي الـ DCs. هذا يعطي مرونة عالية لكنه يحتاج DNS سليم، وقت مضبوط، واتصال شبكي مستقر.
كل تغيير في AD يحصل على Metadata تساعد الـ DCs على معرفة ما الذي تغيّر ومن أين أتى. يتم استخدام مفاهيم مثل USN وHigh-Watermark وUp-to-Dateness Vector لتجنب نسخ كل شيء في كل مرة. كما يقوم KCC بإنشاء Replication Topology تلقائياً داخل Sites وبين Sites حسب Site Links والتكاليف والجداول.
ليس صحيحاً تبسيط التعارض دائماً إلى "آخر كتابة تفوز" فقط. في AD توجد Metadata لكل Attribute، ويُستخدم Version Number وTimestamp ومعرّفات أخرى عند الحاجة لحسم التعارض. لذلك الأفضل تجنب تعديلات متزامنة على نفس Attribute من أكثر من مكان، خصوصاً في الأدوات الآلية Scripts.
الـ Site يمثل موقعاً شبكياً سريع الاتصال داخلياً، وليس مجرد فرع إداري. يجب ربط كل Subnet بالـ Site الصحيح حتى يستطيع Client Locator توجيه الأجهزة إلى أقرب DC. إذا لم تُعرّف Subnets بشكل صحيح، قد يسجل جهاز في فرع بعيد الدخول عبر DC في موقع آخر، مما يسبب بطء Login وGPO.
Get-ADReplicationSite -Filter *
Get-ADReplicationSubnet -Filter * | Select Name,Site
Get-ADReplicationSiteLink -Filter * | Select Name,Cost,ReplicationFrequencyInMinutesGlobal Catalog يحتوي نسخة كاملة من كائنات الدومين المحلي ونسخة جزئية من كائنات الدومينات الأخرى داخل Forest. فائدته تظهر في البحث عبر Forest والتحقق من Universal Group Membership. في Forest بدومين واحد، من الشائع والمفيد إبقاء كل DCs كـ Global Catalog، أما في Forest متعددة الدومينات فيجب التخطيط لمكان GC حسب المواقع والحاجة.
Get-ADDomainController -Filter {IsGlobalCatalog -eq $true} | Select HostName,Site,IsGlobalCatalog
Get-ADDomainController -Identity DC01 | Select HostName,IsGlobalCatalogFSMO Roles والعمليات الحرجة في الدومين
رغم أن AD يدعم Multi-Master Updates، توجد خمس عمليات خاصة لا يمكن إدارتها من أكثر من DC في الوقت نفسه. هذه الأدوار تسمى FSMO Roles أو Operations Master Roles.
| الدور | المستوى | وظيفته العملية | متى يصبح مهماً؟ |
|---|---|---|---|
| Schema Master | Forest | تعديل Schema مثل إضافة Classes وAttributes | عند تثبيت Exchange أو تطبيقات توسع Schema. |
| Domain Naming Master | Forest | إضافة أو حذف Domains وApplication Partitions | عند تغيير بنية Forest. |
| RID Master | Domain | توزيع RID Pools لإنشاء SIDs فريدة | عند إنشاء Users/Groups/Computers بكثرة. |
| PDC Emulator | Domain | مرجع الوقت، Password Changes، Lockout، بعض مهام GPO | دائماً مهم ويجب مراقبته جيداً. |
| Infrastructure Master | Domain | تحديث مراجع الكائنات بين Domains | مهم في Forest متعددة الدومينات. |
netdom query fsmo
Get-ADDomain | Select PDCEmulator,RIDMaster,InfrastructureMaster
Get-ADForest | Select SchemaMaster,DomainNamingMasterاستخدم Transfer عندما يكون صاحب الدور القديم يعمل ومتصل. استخدم Seize فقط عندما يكون DC القديم مفقوداً نهائياً ولن يعود إلى الشبكة. بعد Seize، لا تعيد DC القديم إلى الشبكة قبل تنظيفه أو إعادة تثبيته، لأن عودته قد تسبب مشاكل خطيرة.
Move-ADDirectoryServerOperationMasterRole -Identity "DC02" -OperationMasterRole PDCEmulator,RIDMaster,InfrastructureMasterGroup Policy: التطبيق والترتيب والتشخيص
Group Policy تسمح بتطبيق إعدادات على Computers وUsers مركزياً. يتم تطبيق GPOs بالترتيب المعروف LSDOU: Local ثم Site ثم Domain ثم OU. وفي OUs المتداخلة، تطبق سياسة الـ Parent OU قبل Child OU، والسياسة الأقرب للكائن تفوز غالباً عند التعارض.
| الترتيب | المستوى | ملاحظات |
|---|---|---|
| Local | الجهاز المحلي | أضعف مستوى غالباً. |
| Site | AD Site | يفيد عند وجود فروع مختلفة. |
| Domain | الدومين بالكامل | استخدمه للسياسات العامة فقط. |
| OU | الوحدة التنظيمية | الأفضل لمعظم السياسات العملية. |
يمكن استخدام Block Inheritance لمنع وراثة GPOs من مستويات أعلى، لكن Enforced يتجاوز Block Inheritance. لذلك لا تستخدم Enforced إلا بحذر، لأن كثرة استخدامها تجعل التشخيص معقداً.
gpupdate /force
gpresult /r
gpresult /h C:\Temp\gp-report.html
Get-GPO -All | Select DisplayName,GpoStatus,CreationTime
Get-GPInheritance -Target "OU=Workstations,DC=corp,DC=example,DC=com"تصميم Active Directory بطريقة صحيحة
التثبيت سهل؛ التصميم هو الجزء الصعب. أغلب مشاكل AD طويلة الأمد تأتي من تصميم غير منظم: DC واحد، DNS خاطئ، OUs بلا منطق، GPOs متداخلة، حسابات Admin مستخدمة يومياً، أو عدم وجود Backup قابل للاستعادة.
| نوع البيئة | التصميم المقترح | ملاحظات |
|---|---|---|
| شركة صغيرة | Domain واحد + اثنان DCs + DNS داخلي | لا تستخدم DC واحد فقط. |
| شركة متوسطة | Domain واحد + OUs منظمة + GPOs حسب الوظيفة | افصل Users وComputers وServers وAdmins. |
| عدة فروع | Sites/Subnets + Site Links + DC في الفروع المهمة | تجنب تسجيل دخول المستخدمين عبر WAN دون حاجة. |
| بيئة حساسة | Tier Model + PAW + Auditing + LAPS/gMSA | حماية Domain Admins وDomain Controllers أولوية. |
| فروع صغيرة غير آمنة | RODC عند الحاجة | مفيد عندما لا تريد تخزين كل أسرار الدومين في الفرع. |
في البيئات الحديثة يفضّل استخدام Subdomain مملوك للشركة مثل ad.company.com أو corp.company.com. تجنب الأسماء العشوائية أو غير المملوكة. استخدام .local كان شائعاً قديماً، لكنه قد يسبب تعارضات مع mDNS وبعض التكاملات الحديثة.
- اجعل كل DC يملك Static IP.
- اضبط DNS Client على DC ليشير إلى DC آخر كأولوية أولى ثم نفسه كبديل، أو حسب تصميمك المعتمد.
- اضبط Forwarders على DNS Server للخروج إلى الإنترنت.
- عرّف Subnets في Sites and Services.
- اختبر SRV Records بعد إضافة أي DC جديد.
أمان Active Directory
Active Directory غالباً أهم أصل أمني في بيئة Windows. من يسيطر على Domain Admin أو على DC يستطيع عملياً التحكم بمعظم البيئة. لذلك يجب التعامل مع AD كمنظومة Tier 0 وليس كخادم عادي.
- Tier 0: Domain Controllers، Enterprise Admins، Domain Admins، PKI الحساسة، Azure AD Connect/Entra Connect إن وجد.
- Tier 1: Member Servers، قواعد البيانات، تطبيقات الإنتاج.
- Tier 2: Workstations وأجهزة المستخدمين.
القاعدة الذهبية: لا تستخدم حساب Tier 0 على جهاز Tier 1 أو Tier 2. لا تسجل دخول Domain Admin على جهاز مستخدم عادي أبداً. استخدم حسابات منفصلة للإدارة اليومية، ويفضل استخدام Privileged Access Workstation للإدارة الحساسة.
مجموعة Protected Users تضيف قيوداً مهمة مثل منع NTLM لأعضاء المجموعة، استخدام AES في Kerberos، منع بعض أشكال Delegation، وتقليل مدة TGT إلى 4 ساعات. لكنها قد تكسر تطبيقات قديمة، لذلك لا تضف Domain Admins إليها دفعة واحدة قبل الاختبار.
حسابات الخدمة ذات كلمات المرور الضعيفة من أكثر نقاط الخطر. استخدم Group Managed Service Accounts حيث أمكن، لأنها تدير كلمة المرور تلقائياً وتقلل خطر Kerberoasting. وعند استخدام حساب خدمة عادي، اجعل كلمة المرور طويلة جداً، وامنع Interactive Logon، ووثق SPNs الخاصة به.
Get-ADGroupMember "Domain Admins" | Select Name,SamAccountName
Search-ADAccount -AccountInactive -TimeSpan 90.00:00:00 -UsersOnly
Get-ADUser -Filter {PasswordNeverExpires -eq $true} -Properties PasswordNeverExpires | Select Name,SamAccountName
Get-ADUser -LDAPFilter "(servicePrincipalName=*)" -Properties servicePrincipalName | Select Name,servicePrincipalNameفعّل مراقبة LDAP غير الآمن أولاً، ثم انتقل تدريجياً إلى Require Signing وChannel Binding بعد اختبار التطبيقات. راقب Event IDs الخاصة بـ LDAP على Domain Controllers، خصوصاً التطبيقات القديمة التي تستخدم Simple Bind.
Backup وRecovery وSnapshots
نسخ Active Directory ليس مثل نسخ ملف عادي. يجب استخدام أدوات تدعم System State وVSS-aware Backup. في حالة الاستعادة، يجب فهم الفرق بين Non-Authoritative Restore وAuthoritative Restore، ومعرفة مخاطر USN Rollback عند استخدام صور أو Snapshots بطريقة غير مدعومة.
- Active Directory database: NTDS.dit.
- SYSVOL.
- Registry.
- Boot files ومكونات النظام الحرجة.
- Certificate Services إذا كان الخادم CA.
wbadmin start systemstatebackup -backuptarget:E:
wbadmin get versions
wbadmin get items -version:MM/DD/YYYY-HH:MMفي الإصدارات الحديثة من Windows Server مع Hypervisor يدعم VM-Generation ID، أصبح التعامل مع بعض سيناريوهات الرجوع بالـ Snapshot أكثر أماناً من الماضي. لكن هذا لا يعني أن Snapshot بديل عن System State Backup. Snapshot غير مدعوم أو Restore بطريقة Image قد يؤدي إلى USN Rollback أو Replication Issues، خصوصاً في بيئات قديمة أو Hypervisor لا يدعم المطلوب.
فعّل AD Recycle Bin في البيئات الحديثة بعد التأكد من المتطلبات. هذه الميزة تسهّل استعادة الكائنات المحذوفة مثل Users وOUs مع خصائصها المهمة، لكنها لا تغني عن Backup كامل.
Get-ADOptionalFeature -Filter 'Name -like "Recycle Bin Feature"'
Enable-ADOptionalFeature 'Recycle Bin Feature' -Scope ForestOrConfigurationSet -Target corp.example.comأوامر الإدارة والتشخيص المهمة
هذه الأوامر تصلح كمرجع يومي لمسؤول AD. نفّذها دائماً بصلاحيات مناسبة وعلى جهاز يحتوي RSAT أو على Domain Controller حسب الحاجة.
dcdiag /v
dcdiag /test:dns /v
repadmin /replsummary
repadmin /showrepl * /errorsonly
netdom query fsmo
nltest /dsgetdc:corp.example.com
nltest /sc_verify:corp.example.comImport-Module ActiveDirectory
Get-ADDomain
Get-ADForest
Get-ADDomainController -Filter * | Select HostName,Site,IPv4Address,IsGlobalCatalog,OperationMasterRolesGet-ADUser -Filter * -Properties Department,Enabled,LastLogonDate | Select Name,Department,Enabled,LastLogonDate
Get-ADGroupMember "Domain Admins" | Select Name,SamAccountName,ObjectClass
New-ADGroup -Name "GG_Finance_Users" -GroupScope Global -GroupCategory Security -Path "OU=Groups,DC=corp,DC=example,DC=com"
Add-ADGroupMember -Identity "GG_Finance_Users" -Members "ahasn"Search-ADAccount -AccountInactive -TimeSpan 90.00:00:00 -UsersOnly | Select Name,LastLogonDate
Search-ADAccount -AccountDisabled -UsersOnly | Select Name,SamAccountName
Search-ADAccount -LockedOut | Select Name,SamAccountNamegpupdate /force
gpresult /r
gpresult /h C:\Temp\gp-report.html
Get-GPO -All | Select DisplayName,GpoStatus,Owner
Backup-GPO -All -Path "D:\GPO-Backup"المشاكل الشائعة وحلولها
عند حدوث مشكلة في AD، لا تبدأ بالتخمين. اتبع منهجية ثابتة: DNS، الوقت، الاتصال بالـ DC، Replication، Kerberos، Group Policy، ثم Event Viewer.
| المشكلة | السبب المحتمل | أوامر التشخيص | الحل العملي |
|---|---|---|---|
| جهاز لا يدخل الدومين | DNS خاطئ، وقت غير مضبوط، اسم مكرر، أو اتصال مقطوع | nslookup, nltest, ping, Test-NetConnection | اضبط DNS الداخلي، تحقق من SRV Records، وأعد Join إذا لزم. |
| Group Policy لا تطبق | OU خاطئة، Security Filtering، WMI Filter، Replication | gpresult /h, gpupdate /force, Event Viewer | راجع Scope وDelegation وLink Order وتأكد من وصول SYSVOL. |
| Replication Errors | DNS، Firewall، RPC، وقت، Site Links | repadmin /replsummary, dcdiag /v | حل DNS/RPC أولاً ثم نفّذ syncall بعد إصلاح السبب. |
| Account Lockout متكرر | كلمة مرور قديمة محفوظة في خدمة أو هاتف أو Scheduled Task | Event ID 4740, Get-ADUser LockedOut | حدد الجهاز المصدر، ثم صحح Credential المخزنة. |
| بطء تسجيل الدخول | DNS، DC بعيد، GPO ثقيلة، Logon Scripts، Roaming Profile | gpresult, Event Viewer, nltest /dsgetdc | عرف Sites/Subnets، قلل GPO، راجع Scripts وProfile. |
| LDAP App لا يتصل | Certificate، Port، Bind DN، Signing/Channel Binding | ldp.exe, Test-NetConnection, Event IDs 2886/2887 | استخدم LDAPS صحيحاً، أصلح الشهادة، واضبط التطبيق على SASL أو TLS. |
| FSMO Owner مفقود | DC قديم سقط نهائياً | netdom query fsmo, dcdiag | إذا لن يعود، نفّذ Seize ثم Metadata Cleanup. |
wevtutil qe Security /q:"*[System[EventID=4740]]" /c:10 /f:text
Get-ADUser -Identity "ahasn" -Properties LockedOut,BadLogonCount,LastBadPasswordAttempt
Unlock-ADAccount -Identity "ahasn"klist
klist purge
w32tm /query /status
w32tm /query /source
nltest /sc_verify:corp.example.comBest Practices لمسؤولي Windows Server
- استخدم Domain Controllerين على الأقل: ويفضل توزيعهما على مضيفين مختلفين ومخازن مختلفة.
- احمِ DNS: DNS الخاطئ يعني AD غير مستقر.
- لا تستخدم DC كخادم ملفات أو تطبيقات: قلل الخدمات المثبتة على Domain Controllers.
- افصل حسابات الإدارة: حساب يومي عادي وحساب Admin منفصل.
- استخدم Groups للصلاحيات: لا تمنح صلاحيات NTFS مباشرة لمستخدمين.
- طبّق AGDLP: Accounts → Global Groups → Domain Local Groups → Permissions.
- فعّل Windows LAPS: لإدارة كلمات مرور Local Admin على الأجهزة.
- استخدم gMSA للخدمات: خصوصاً الخدمات ذات SPN.
- راقب Replication يومياً: repadmin /replsummary يجب أن يكون جزءاً من الروتين.
- راجع Domain Admins: لا تجعل العضوية دائمة إلا للضرورة.
- اختبر GPO قبل النشر: سياسة واحدة خاطئة قد تعطل عشرات الأجهزة.
- اختبر Backup/Restore: نفّذ اختبار استعادة دوري في Lab.
- وثّق البيئة: أسماء DCs، FSMO owners، Sites، Subnets، GPOs، Service Accounts.
Monthly AD Health Checklist
[ ] repadmin /replsummary clean
[ ] dcdiag /v reviewed
[ ] DNS SRV records verified
[ ] Domain Admins membership reviewed
[ ] Inactive users older than 90 days reviewed
[ ] Stale computers reviewed
[ ] GPO backup completed
[ ] System State backup verified
[ ] Restore test scheduled or completed
[ ] Event IDs 4625, 4672, 4720, 4726, 4732, 4740 reviewedمثال عملي من بيئة شركة
شركة لديها 150 موظفاً وفرعان وخدمات داخلية مثل File Server وERP وVPN وPrint Server. كانت تعمل سابقاً بنظام Workgroup مع حسابات محلية. المشاكل كانت واضحة: Passwords غير موحدة، صعوبة تعطيل حساب موظف مغادر، صلاحيات ملفات غير منظمة، وعدم وجود سياسة موحدة للأجهزة.
| المرحلة | الإجراء | النتيجة |
|---|---|---|
| التخطيط | اختيار corp.company.com وتصميم OUs وGroups | تجنب الفوضى قبل إنشاء المستخدمين. |
| البنية | DC01 وDC02 مع DNS داخلي وForwarders | توفر تسجيل الدخول وDNS. |
| الأجهزة | Join Domain للأجهزة ونقلها إلى OUs حسب النوع | إدارة GPO أفضل. |
| الصلاحيات | تطبيق AGDLP على File Server | صلاحيات قابلة للتدقيق والتوسع. |
| الأمان | حسابات Admin منفصلة، LAPS، GPO للأمان، Auditing | تقليل مخاطر الاختراق وسوء الاستخدام. |
| الفروع | تعريف Sites وSubnets وربط الفرع بأقرب DC | تحسين Login وGPO عبر WAN. |
بعد التنفيذ أصبح لدى الشركة حساب موحد لكل موظف، سياسات موحدة، إمكانية تعطيل الحسابات فوراً، ومراجعة مركزية للأحداث. الأهم أن فريق IT أصبح يعمل وفق Standard واضح بدلاً من حلول فردية مؤقتة.
الأسئلة الشائعة
ما الفرق بين Active Directory وDomain Controller؟
Active Directory أو AD DS هو الخدمة وقاعدة البيانات والمنطق الإداري. أما Domain Controller فهو الخادم الذي يشغل هذه الخدمة ويحتوي نسخة من بيانات الدومين.
هل أحتاج أكثر من Domain Controller؟
نعم في أي بيئة إنتاجية. وجود DC واحد يجعل المصادقة وDNS وGPO نقطة فشل واحدة. الحد العملي الآمن هو اثنان على الأقل.
هل يمكن تشغيل Domain Controller كـ Virtual Machine؟
نعم وهذا شائع جداً، لكن يجب استخدام Backup صحيح، وتجنب Snapshots غير المدعومة، وضمان أن الـ Hypervisor يدعم ممارسات آمنة للـ Virtualized DCs.
ما أهم سبب لمشاكل Active Directory؟
DNS غير صحيح هو السبب الأكثر شيوعاً عملياً. لذلك أول خطوة في أي تشخيص هي فحص DNS Client Settings وSRV Records وDC Locator.
ما الفرق بين OU وGroup؟
OU للتنظيم وتطبيق GPO وتفويض الإدارة. Group لتجميع المستخدمين أو الأجهزة ومنح الصلاحيات. لا تستخدم OU بدلاً من Group للصلاحيات.
هل يجب تفعيل AD Recycle Bin؟
يفضل تفعيله في البيئات الحديثة بعد التحقق من المتطلبات، لأنه يسهل استعادة الكائنات المحذوفة. لكنه لا يغني عن Backup.
هل يجب تعطيل NTLM بالكامل؟
الهدف الأمني الجيد هو تقليل NTLM تدريجياً، لكن تعطيله الكامل يحتاج Audit واختبار لأن تطبيقات قديمة قد تعتمد عليه. ابدأ بالمراقبة ثم المعالجة ثم enforcement.
الخاتمة
Active Directory هو قلب بيئة Windows Server. قوته لا تأتي من واجهة إنشاء المستخدمين فقط، بل من تكامل DNS وKerberos وLDAP وReplication وGroup Policy وSecurity Groups وFSMO وBackup. لذلك يجب التعامل معه كبنية تحتية حرجة وليس كخادم عادي.
المقال المرجعي الجيد عن AD يجب أن لا يكتفي بالتعريفات؛ يجب أن يشرح كيف تعمل المصادقة، كيف يجد الجهاز DC، كيف تنتشر التغييرات، كيف تطبق GPO، كيف تحمي الحسابات الحساسة، وكيف تستعيد البيئة عند الكارثة. لهذا تم توسيع المقال ليكون قابلاً للاستخدام كمرجع أثناء العمل اليومي.
الخلاصة العملية: صمم ببساطة، استخدم DCين على الأقل، اضبط DNS وSites، راقب Replication، لا تستخدم Domain Admin يومياً، اعتمد Groups للصلاحيات، فعّل Backup حقيقي، واختبر Restore. بهذه الطريقة يصبح Active Directory أداة تنظيم وقوة، لا مصدر مشاكل وفوضى.