استكشاف أخطاء Active Directory وإصلاحها — دليل عملي شامل من النسخ المتماثل إلى الهوية المختلطة 2026

مقدمة: لماذا يُعد إتقان استكشاف أخطاء Active Directory مهارة لا غنى عنها في 2026؟

إذا كنت تعمل في مجال الدعم الفني أو إدارة الأنظمة، فأنت تعرف هذا الشعور جيدًا — يتصل بك أحدهم قائلاً "لا أستطيع تسجيل الدخول" أو "الملفات المشتركة لا تعمل"، وفي الخلفية تعرف أن المشكلة غالبًا ما تعود إلى Active Directory (AD). هو فعلاً العمود الفقري لأي بيئة مؤسسية تعمل بنظام Windows — المصادقة، التفويض، سياسات المجموعة، إدارة الأجهزة، كل شيء يمر من خلاله.

وعندما يتعطل؟ تتوقف الإنتاجية في المؤسسة بأكملها.

مع إطلاق Windows Server 2025 وتزايد اعتماد المؤسسات على نماذج الهوية المختلطة (Hybrid Identity) مع Microsoft Entra ID (المعروف سابقًا بـ Azure AD)، أصبحت بيئات AD أكثر تعقيدًا من أي وقت مضى. وبصراحة، تحديثات سبتمبر وأكتوبر 2025 الأمنية زادت الطين بلة — تسببت في مشاكل مزامنة Active Directory على خوادم Windows Server 2025، مما أضاف عبئًا إضافيًا على فرق الدعم الفني.

هذا الدليل مصمم لك — سواء كنت فني دعم فني أو مسؤول نظام — ويحتوي على أدوات وتقنيات عملية لتشخيص مشاكل Active Directory وحلها بسرعة. سنغطي كل شيء من مشاكل النسخ المتماثل (Replication) إلى إغلاق الحسابات، ومن أخطاء DNS إلى تعقيدات الهوية المختلطة مع Entra ID. هيا نبدأ.

الأدوات الأساسية لتشخيص مشاكل Active Directory

أداة DCDiag — نقطة البداية لأي مشكلة

أداة DCDiag هي أول شيء أفتحه عند استكشاف أي مشكلة في Active Directory. تقوم بإجراء سلسلة من الاختبارات التشخيصية على وحدة التحكم بالمجال (Domain Controller) — تتحقق من صحة خدمات DNS، والنسخ المتماثل، وسياسات المجموعة، والاتصال بالخدمات الأخرى. باختصار، هي الطريقة الأسرع للحصول على صورة عامة عن صحة بيئة AD.

# تشغيل جميع اختبارات DCDiag على وحدة التحكم المحلية
dcdiag /v

# تشغيل DCDiag على وحدة تحكم بعيدة محددة
dcdiag /s:DC-SERVER01 /v

# اختبار DNS فقط
dcdiag /test:dns /v

# اختبار النسخ المتماثل
dcdiag /test:replications /v

# تشغيل جميع الاختبارات على جميع وحدات التحكم في الغابة
dcdiag /a /v

# حفظ النتائج في ملف للمراجعة
dcdiag /v /c /d /e > C:\Logs\dcdiag_report.txt

نصيحة عملية: عند قراءة نتائج DCDiag، ركّز على أي اختبار يظهر بحالة failed. الاختبارات الأهم هي: Advertising (هل وحدة التحكم تعلن عن نفسها بشكل صحيح)، FrsEvent و DFSREvent (حالة نسخ SYSVOL)، KccEvent (مدقق اتساق المعرفة)، و Replications. لا تُضيع وقتك على الاختبارات الناجحة.

أداة Repadmin — سلاحك الأول للنسخ المتماثل

إذا كانت DCDiag هي الفحص العام، فإن Repadmin هي المتخصصة في كل ما يتعلق بالنسخ المتماثل. وهي جزء من أدوات إدارة الخادم عن بُعد (RSAT). إليك الأوامر التي ستستخدمها يوميًا (وأعني يوميًا حرفيًا):

# عرض ملخص سريع لحالة النسخ المتماثل عبر المجال
repadmin /replsummary

# عرض تفاصيل النسخ المتماثل الواردة لوحدة تحكم محددة
repadmin /showrepl DC-SERVER01

# عرض الأخطاء فقط (مفيد جدًا في البيئات الكبيرة)
repadmin /showrepl * /errorsonly

# فرض مزامنة فورية بين جميع شركاء النسخ المتماثل
repadmin /syncall DC-SERVER01 /A /e /d /P

# عرض قائمة انتظار النسخ المتماثل
repadmin /queue DC-SERVER01

# إعادة حساب طوبولوجيا النسخ المتماثل
repadmin /kcc DC-SERVER01

# عرض البيانات الوصفية لكائن محدد (مفيد لتتبع التغييرات)
repadmin /showobjmeta DC-SERVER01 "CN=Ahmed,OU=Users,DC=company,DC=local"

أدوات PowerShell المتقدمة

مع تطور PowerShell، أصبح لديك مجموعة قوية من الأوامر المخصصة لإدارة وتشخيص Active Directory. هذه السكربتات أستخدمها شخصيًا بشكل متكرر:

# التحقق من حالة خدمات AD DS على جميع وحدات التحكم
Get-ADDomainController -Filter * | ForEach-Object {
    $dc = $_.HostName
    $services = @('NTDS', 'DNS', 'kdc', 'Netlogon', 'W32Time')
    foreach ($svc in $services) {
        $status = Get-Service -ComputerName $dc -Name $svc -ErrorAction SilentlyContinue
        [PSCustomObject]@{
            DomainController = $dc
            Service = $svc
            Status = if ($status) { $status.Status } else { "Not Found" }
        }
    }
} | Format-Table -AutoSize

# فحص صحة النسخ المتماثل عبر PowerShell
Get-ADReplicationPartnerMetadata -Target * -Partition * |
    Select-Object Server, Partition, Partner, LastReplicationSuccess,
    LastReplicationResult, ConsecutiveReplicationFailures |
    Where-Object { $_.ConsecutiveReplicationFailures -gt 0 } |
    Format-Table -AutoSize

# عرض أحدث أحداث النسخ المتماثل في سجل الأحداث
Get-WinEvent -LogName 'Directory Service' -MaxEvents 50 |
    Where-Object { $_.Id -in @(1864, 1865, 1311, 1388, 1988, 2042) } |
    Format-Table TimeCreated, Id, Message -Wrap

استكشاف أخطاء النسخ المتماثل (Replication) وإصلاحها

كيف يعمل النسخ المتماثل — الأساسيات أولاً

قبل أن نغوص في حل المشاكل، دعني أوضح كيف يعمل النسخ المتماثل. عندما يتم تغيير أي كائن (مستخدم، مجموعة، سياسة) على وحدة تحكم بالمجال، يجب نسخ هذا التغيير إلى جميع وحدات التحكم الأخرى. الآلية المسؤولة عن ذلك تسمى مدقق اتساق المعرفة (KCC - Knowledge Consistency Checker) وهو يحسب تلقائيًا أفضل طوبولوجيا للنسخ.

النسخ المتماثل يعمل على مستويين:

• النسخ المتماثل داخل الموقع (Intra-site): بين وحدات التحكم في نفس موقع AD. يحدث خلال 15 ثانية من أي تغيير — سريع جدًا.
• النسخ المتماثل بين المواقع (Inter-site): بين وحدات التحكم في مواقع مختلفة. يتم وفق جدول زمني (افتراضيًا كل 180 دقيقة) ويمكن ضغط البيانات لتوفير النطاق الترددي.

المشكلة الأولى: فشل النسخ المتماثل مع خطأ 8453

خطأ 8453 (Replication access was denied) — هذا من أكثر الأخطاء التي ستقابلها. يحدث عادةً بسبب مشاكل في الأذونات، وللأسف كثير من المسؤولين يقضون ساعات في البحث عن أسباب معقدة قبل أن يكتشفوا أن المشكلة ببساطة في الصلاحيات.

# التحقق من ظهور الخطأ
repadmin /showrepl DC-SERVER01 | findstr "8453"

# التحقق من أذونات النسخ المتماثل على قسم المجال
# افتح ADSI Edit واتصل بالقسم المتأثر
# تحقق من وجود الأذونات التالية لمجموعة Enterprise Domain Controllers:
# - Replicating Directory Changes
# - Replicating Directory Changes All
# - Replicating Directory Changes In Filtered Set

# إعادة تعيين الأذونات عبر PowerShell
Import-Module ActiveDirectory
$domainDN = (Get-ADDomain).DistinguishedName
$edcSID = (Get-ADGroup "Enterprise Domain Controllers").SID
dsacls $domainDN /G "${edcSID}:CA;Replicating Directory Changes;"
dsacls $domainDN /G "${edcSID}:CA;Replicating Directory Changes All;"

المشكلة الثانية: خطأ 1722 (RPC Server Unavailable)

هذا الخطأ يعني ببساطة أن وحدات التحكم لا تستطيع التواصل مع بعضها. الأسباب الشائعة؟ مشاكل شبكة، جدار حماية يحجب الاتصال، أو خدمات RPC متوقفة. من تجربتي، جدار الحماية هو الجاني في أغلب الحالات.

# التحقق من اتصال الشبكة
Test-NetConnection -ComputerName DC-SERVER02 -Port 135
Test-NetConnection -ComputerName DC-SERVER02 -Port 389
Test-NetConnection -ComputerName DC-SERVER02 -Port 636
Test-NetConnection -ComputerName DC-SERVER02 -Port 3268

# التحقق من خدمة RPC
Get-Service -ComputerName DC-SERVER02 -Name RpcSs

# التحقق من قواعد جدار الحماية
Get-NetFirewallRule -DisplayGroup "Active Directory Domain Services" |
    Select-Object DisplayName, Enabled, Direction, Action |
    Format-Table -AutoSize

# اختبار اتصال RPC المفصل
portqry -n DC-SERVER02 -e 135 -p tcp

# التحقق من تسجيل SPN الصحيح
setspn -L DC-SERVER02 | findstr "ldap"

حل سريع: في كثير من الحالات، المشكلة ببساطة أن ملف تعريف جدار الحماية تغيّر من Domain إلى Public بعد تحديث. هذه مشكلة معروفة في تحديثات أبريل 2025 لـ Windows Server 2025، وقد أصدرت Microsoft التصحيح KB5060842 لمعالجتها. تحقق من ملف تعريف الشبكة:

# التحقق من ملف تعريف الشبكة الحالي
Get-NetConnectionProfile

# إذا كان الملف "Public" بدلاً من "DomainAuthenticated"
# أعد تشغيل خدمة NLA
Restart-Service NlaSvc

# أو عيّن الملف يدويًا (كحل مؤقت)
Set-NetConnectionProfile -InterfaceAlias "Ethernet" -NetworkCategory DomainAuthenticated

المشكلة الثالثة: كائنات عالقة (Lingering Objects)

الكائنات العالقة — وهي من أكثر المشاكل المزعجة صراحةً. تحدث عندما يُحذف كائن من وحدة تحكم لكن لا يصل الحذف إلى وحدات التحكم الأخرى (عادةً بسبب انقطاع النسخ المتماثل لفترة تتجاوز عمر شاهد القبر — Tombstone Lifetime). النتيجة؟ تناقضات في قاعدة البيانات تسبب صداعًا حقيقيًا.

# الكشف عن الكائنات العالقة
repadmin /removelingeringobjects DC-SERVER01 DC-SERVER02_GUID dc=company,dc=local /advisory_mode

# إزالة الكائنات العالقة بعد التأكد
repadmin /removelingeringobjects DC-SERVER01 DC-SERVER02_GUID dc=company,dc=local

# للحصول على GUID وحدة التحكم
repadmin /showrepl DC-SERVER02 | findstr "DSA object GUID"

# تفعيل الحماية من الكائنات العالقة (Strict Replication Consistency)
repadmin /regkey DC-SERVER01 +strict

استكشاف أخطاء DNS المتعلقة بـ Active Directory

لماذا DNS هو أساس كل شيء في AD

هناك مقولة شهيرة في عالم الدعم الفني: "إنها دائمًا مشكلة DNS." وفي حالة Active Directory، هذا صحيح بنسبة كبيرة. يعتمد AD بشكل كامل على DNS للعثور على وحدات التحكم بالمجال، والمصادقة، والنسخ المتماثل، وتطبيق سياسات المجموعة.

إذا كان DNS معطلاً أو مُعدًّا بشكل خاطئ، فكل شيء آخر سيتعطل. بلا استثناء.

الخطأ الأكثر شيوعًا: وحدة التحكم تشير إلى DNS خارجي

صدق أو لا تصدق، واحدة من أكثر المشاكل انتشارًا هي أن وحدة التحكم بالمجال تشير إلى خادم DNS خارجي مثل 8.8.8.8 (Google DNS) بدلاً من خادم DNS داخلي. هذا يعني أن الجهاز لن يجد سجلات SRV الضرورية لتحديد موقع وحدات التحكم. مشكلة بسيطة لكن عواقبها كبيرة.

# التحقق من إعدادات DNS على وحدة التحكم
Get-DnsClientServerAddress -InterfaceAlias "Ethernet" |
    Select-Object InterfaceAlias, ServerAddresses

# التحقق من تسجيل سجلات SRV الضرورية
nslookup -type=SRV _ldap._tcp.dc._msdcs.company.local
nslookup -type=SRV _kerberos._tcp.dc._msdcs.company.local

# التحقق من سجل A لوحدة التحكم
nslookup DC-SERVER01.company.local

# فحص DNS المتكامل مع DCDiag
dcdiag /test:dns /v /f:C:\Logs\dns_diag.txt

تنظيف سجلات DNS القديمة (Stale Records)

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

# تفعيل تنظيف السجلات القديمة (Scavenging) على خادم DNS
# أولاً على مستوى الخادم
Set-DnsServerScavenging -ScavengingState $true -ScavengingInterval 7.00:00:00

# ثم على مستوى المنطقة
Set-DnsServerZoneAging -Name "company.local" -Aging $true -RefreshInterval 7.00:00:00 -NoRefreshInterval 7.00:00:00

# عرض السجلات القديمة قبل الحذف
Get-DnsServerResourceRecord -ZoneName "company.local" -RRType A |
    Where-Object { $_.Timestamp -and $_.Timestamp -lt (Get-Date).AddDays(-30) } |
    Select-Object HostName, RecordType, Timestamp |
    Format-Table -AutoSize

# تشغيل التنظيف يدويًا
Start-DnsServerScavenging -Force

# إعادة تسجيل سجلات DNS لوحدة التحكم
ipconfig /registerdns
net stop netlogon && net start netlogon

مشكلة مناطق DNS المتكاملة مع AD

في البيئات التي تستخدم مناطق DNS المتكاملة مع Active Directory، قد تصادف مشكلة ظهور سجلات في حاوية CNF (تعارض). يحدث هذا عندما يُعدَّل نفس السجل على وحدتي تحكم مختلفتين قبل اكتمال النسخ المتماثل بينهما. ليست شائعة جدًا، لكنها مربكة عندما تحدث.

# البحث عن كائنات التعارض في AD
Get-ADObject -Filter 'Name -like "*CNF:*"' -SearchBase "DC=company,DC=local" -Properties WhenCreated |
    Select-Object Name, DistinguishedName, WhenCreated |
    Format-Table -AutoSize

# البحث في منطقة DNS المتكاملة عن السجلات المتعارضة
Get-ADObject -Filter 'Name -like "*CNF:*"' -SearchBase "DC=DomainDnsZones,DC=company,DC=local" |
    Format-Table Name, DistinguishedName

استكشاف أخطاء إغلاق الحسابات (Account Lockouts)

لماذا تُغلق الحسابات باستمرار؟

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

• بيانات اعتماد محفوظة قديمة: خرائط محركات أقراص الشبكة، أو مهام مجدولة، أو تطبيقات تستخدم كلمات مرور قديمة تم تغييرها.
• أجهزة محمولة: الهواتف والأجهزة اللوحية المتصلة بـ Exchange أو Wi-Fi المؤسسي بكلمة مرور قديمة (هذا السبب الأكثر شيوعًا في تجربتي).
• جلسات RDP مفصولة: جلسات سطح المكتب البعيد المفصولة — وليست المُنهاة — تحاول تجديد تذاكر Kerberos بكلمة المرور القديمة.
• حسابات الخدمة: خدمات Windows تعمل بحسابات مستخدمين تم تغيير كلمات مرورها دون تحديث الخدمة.
• محاولات اختراق: هجمات القوة الغاشمة من داخل الشبكة أو خارجها. لا تستبعد هذا الاحتمال أبدًا.

تتبع مصدر الإغلاق خطوة بخطوة

الخطوة الأولى والأهم: حدد أين يحدث الإغلاق. أحداث الإغلاق تُسجَّل دائمًا على وحدة التحكم التي تحمل دور PDC Emulator — ابدأ البحث من هناك.

# تحديد وحدة التحكم التي تحمل دور PDC Emulator
Get-ADDomain | Select-Object PDCEmulator

# البحث عن أحداث الإغلاق (Event ID 4740) على PDC
$PDC = (Get-ADDomain).PDCEmulator
Get-WinEvent -ComputerName $PDC -FilterHashtable @{
    LogName = 'Security'
    Id = 4740
} -MaxEvents 20 | ForEach-Object {
    [PSCustomObject]@{
        Time = $_.TimeCreated
        User = $_.Properties[0].Value
        CallerComputer = $_.Properties[1].Value
    }
} | Format-Table -AutoSize

# البحث عن محاولات تسجيل الدخول الفاشلة (Event ID 4625)
Get-WinEvent -ComputerName $PDC -FilterHashtable @{
    LogName = 'Security'
    Id = 4625
} -MaxEvents 50 | ForEach-Object {
    [PSCustomObject]@{
        Time = $_.TimeCreated
        TargetUser = $_.Properties[5].Value
        SourceIP = $_.Properties[19].Value
        LogonType = $_.Properties[10].Value
        FailureReason = $_.Properties[8].Value
    }
} | Format-Table -AutoSize

استخدام PowerShell بدلاً من أداة Account Lockout Status

أداة LockoutStatus.exe من Microsoft لا تزال مفيدة، لكن يمكنك الحصول على نفس المعلومات (وأكثر) عبر PowerShell مباشرةً:

# عرض حالة الإغلاق لمستخدم محدد عبر جميع وحدات التحكم
$username = "ahmed.hassan"
Get-ADDomainController -Filter * | ForEach-Object {
    $dc = $_.HostName
    try {
        $user = Get-ADUser $username -Server $dc -Properties `
            LockedOut, LockoutTime, BadLogonCount, `
            LastBadPasswordAttempt, PasswordLastSet
        [PSCustomObject]@{
            DC = $dc
            LockedOut = $user.LockedOut
            LockoutTime = $user.LockoutTime
            BadLogonCount = $user.BadLogonCount
            LastBadAttempt = $user.LastBadPasswordAttempt
            PasswordLastSet = $user.PasswordLastSet
        }
    } catch {
        [PSCustomObject]@{
            DC = $dc
            LockedOut = "Error: $_"
            LockoutTime = $null
            BadLogonCount = $null
            LastBadAttempt = $null
            PasswordLastSet = $null
        }
    }
} | Format-Table -AutoSize

# فتح حساب مُغلق
Unlock-ADAccount -Identity $username
# التحقق من أن الحساب أصبح مفتوحًا
(Get-ADUser $username -Properties LockedOut).LockedOut

سياسات كلمات المرور الدقيقة (Fine-Grained Password Policies)

بدلاً من تطبيق سياسة إغلاق واحدة على الجميع (وهو ما يفعله كثير من المسؤولين للأسف)، يمكنك استخدام سياسات كلمات المرور الدقيقة (FGPP) لتخصيص سياسات مختلفة لمجموعات مختلفة. مثلاً، حد إغلاق أقل لحسابات المسؤولين (3 محاولات) وحد أعلى للمستخدمين العاديين (15 محاولة):

# إنشاء سياسة كلمة مرور دقيقة لحسابات المسؤولين
New-ADFineGrainedPasswordPolicy -Name "Admin-Strict-Policy" `
    -Precedence 10 `
    -LockoutThreshold 3 `
    -LockoutDuration "00:00:00" `
    -LockoutObservationWindow "00:30:00" `
    -MinPasswordLength 16 `
    -ComplexityEnabled $true `
    -MaxPasswordAge "60.00:00:00" `
    -PasswordHistoryCount 24

# ربط السياسة بمجموعة المسؤولين
Add-ADFineGrainedPasswordPolicySubject -Identity "Admin-Strict-Policy" `
    -Subjects "Domain Admins"

# التحقق من السياسة المطبقة على مستخدم محدد
Get-ADUserResultantPasswordPolicy -Identity "admin.user"

استكشاف أخطاء سياسات المجموعة (Group Policy)

أدوات التشخيص: GPResult و RSoP

عندما يشتكي مستخدم من أن سياسة معينة لا تُطبق عليه، أو يظهر سلوك غير متوقع على جهاز ما — هنا تحتاج لمعرفة ما يحدث فعلاً خلف الكواليس. GPResult و RSoP هما أداتاك الأساسيتان:

# إنشاء تقرير HTML مفصل لسياسات المجموعة المطبقة
gpresult /H C:\Logs\gp_report.html /F

# عرض ملخص نصي سريع
gpresult /R

# عرض سياسات مستخدم محدد على جهاز بعيد
gpresult /S WORKSTATION01 /USER company\ahmed /H C:\Logs\ahmed_gp.html

# التحقق من آخر وقت تطبيق لسياسات المجموعة
gpresult /R | findstr "Last time"

# فرض تحديث سياسات المجموعة
gpupdate /force /boot /logoff

ما الفرق بينهما؟ GPResult تُظهر أي سياسات تم تطبيقها وأيها تم ترشيحها ولماذا — مثالية لاستكشاف الأخطاء. أما RSoP (rsop.msc) فتعرض الحالة الراهنة لإعدادات السياسة الفعلية — أنسب للتخطيط والمراجعة.

المشكلة: تعارض سياسات Intune مع سياسات المجموعة

في البيئات المختلطة حيث تُدار الأجهزة بكل من Group Policy و Microsoft Intune، قد تواجه ما يُسمى "الدماغ المنقسم" (Split-Brain Management). ببساطة، الجهاز يتلقى تعليمات متناقضة من مصدرين مختلفين — وهذا وصفة لمشاكل لا تنتهي.

# التحقق مما إذا كان الجهاز مُدارًا بـ Intune
dsregcmd /status | findstr "AzureAdJoined\|MDMUrl\|TenantId"

# عرض سياسات Intune المطبقة (في PowerShell الحديث)
Get-MpComputerStatus | Select-Object AntivirusEnabled, RealTimeProtectionEnabled

# في حالة التعارض، حدد أيهما له الأسبقية
# القاعدة الافتراضية: Intune يفوز على Group Policy في بيئة Co-management
# يمكن التحكم في ذلك عبر إعدادات Co-management في MECM

تحديث قوالب ADMX لـ Windows Server 2025

مع كل إصدار جديد من Windows Server، تُضاف سياسات جديدة وتُعدَّل سياسات قائمة. لا تنسَ تحديث قوالب ADMX — خطوة بسيطة ينساها كثيرون لكنها ضرورية:

# تنزيل أحدث قوالب ADMX من Microsoft
# https://www.microsoft.com/en-us/download/details.aspx?id=105390

# نسخ القوالب إلى المخزن المركزي (Central Store)
# المسار: \\company.local\SYSVOL\company.local\Policies\PolicyDefinitions

# التحقق من وجود المخزن المركزي
Test-Path "\\company.local\SYSVOL\company.local\Policies\PolicyDefinitions"

# نسخ ملفات ADMX وملفات اللغة
Copy-Item "C:\PolicyDefinitions\*.admx" `
    "\\company.local\SYSVOL\company.local\Policies\PolicyDefinitions\" -Force
Copy-Item "C:\PolicyDefinitions\ar-SA\*" `
    "\\company.local\SYSVOL\company.local\Policies\PolicyDefinitions\ar-SA\" -Force
Copy-Item "C:\PolicyDefinitions\en-US\*" `
    "\\company.local\SYSVOL\company.local\Policies\PolicyDefinitions\en-US\" -Force

ميزات Active Directory الجديدة في Windows Server 2025

حجم صفحة قاعدة البيانات 32K

هذه ميزة أنتظرها منذ وقت طويل. منذ Windows 2000 Server، استخدمت قاعدة بيانات Active Directory (ملف NTDS.DIT) حجم صفحة 8 كيلوبايت في محرك ESE. مع Windows Server 2025، أصبح بالإمكان استخدام حجم صفحة 32 كيلوبايت، مما يحسن الأداء بشكل ملحوظ في البيئات الكبيرة التي تحتوي على ملايين الكائنات.

تنبيه مهم: هذا التغيير يتطلب أن تكون جميع وحدات التحكم في الغابة تعمل بنظام Windows Server 2025. ولا يمكن الرجوع عنه بعد التفعيل — فتأكد تمامًا قبل الإقدام على هذه الخطوة.

حسابات الخدمة المُدارة المفوضة (dMSA)

حسابات dMSA (Delegated Managed Service Accounts) هي نوع جديد من حسابات الخدمة في Windows Server 2025. الفكرة ذكية: تربط حسابات الخدمة التقليدية بحسابات dMSA لتدوير كلمات المرور تلقائيًا، بدون الحاجة لتغييرها يدويًا. وهذا يحل مشكلة كلاسيكية طالما عانى منها مسؤولو الأنظمة.

# التحقق من مستوى وظائف الغابة
(Get-ADForest).ForestMode

# التحقق من دعم dMSA
Get-ADOptionalFeature -Filter 'Name -like "*dMSA*"'

# سياسة المجموعة الجديدة لتفعيل dMSA
# Computer Configuration > System > Kerberos > Enable Delegated Managed Service Account logons

تعزيزات الأمان الافتراضية

Windows Server 2025 يفرض عدة تحسينات أمنية افتراضية. وهنا يجب الانتباه جيدًا لأن بعض التطبيقات القديمة قد تتوقف عن العمل:

• توقيع LDAP إلزامي: جميع اتصالات LDAP تتطلب التوقيع (Signing) افتراضيًا. التطبيقات التي تستخدم Simple Bind بدون TLS ستتوقف عن العمل — وهذا تغيير كبير.
• كلمات مرور حسابات الكمبيوتر العشوائية: لم يعد بالإمكان تعيين كلمة مرور حساب الكمبيوتر لتكون اسم الكمبيوتر (وهو السلوك القديم الذي كان يعتمده كثيرون). يتم الآن إنشاء كلمات مرور عشوائية تلقائيًا.
• إلغاء دعم RC4: تشفير RC4 تم إيقاف دعمه رسميًا. تأكد من أن جميع أنظمتك تدعم AES-256 على الأقل.

# التحقق من أنواع التشفير المدعومة في البيئة
Get-ADUser -Filter * -Properties msDS-SupportedEncryptionTypes |
    Where-Object { $_.'msDS-SupportedEncryptionTypes' -band 0x4 } |
    Select-Object Name, SamAccountName, 'msDS-SupportedEncryptionTypes' |
    Format-Table -AutoSize
# القيمة 0x4 = RC4 — أي مستخدم يظهر هنا يحتاج تحديث

# التحقق من إعدادات توقيع LDAP
Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters" `
    -Name "LDAPServerIntegrity" -ErrorAction SilentlyContinue

# فحص التطبيقات التي تستخدم Simple Bind غير المشفر
# ابحث عن Event ID 2889 في سجل Directory Service
Get-WinEvent -FilterHashtable @{
    LogName = 'Directory Service'
    Id = 2889
} -MaxEvents 20 | Format-Table TimeCreated, Message -Wrap

الانتقال من الهوية المختلطة إلى Entra ID الأصلي

الواقع الحالي: الهوية المختلطة جسر وليست وجهة

دعني أكون صريحًا: في 2026، أصبح واضحًا أن الهوية المختلطة (Hybrid Identity) كانت مرحلة انتقالية وليست الوجهة النهائية. توجيهات Microsoft الأخيرة لا تترك مجالاً للشك: Entra ID Join + Intune هو النموذج المستهدف، وليس Hybrid Join.

الأسباب واضحة:

• تعقيد الإدارة: إدارة سياسات من مصدرين (Group Policy + Intune) تخلق فجوات في الرؤية وتناقضات في التكوين.
• نموذج الثقة المعدومة (Zero Trust): محرك الوصول المشروط (Conditional Access) في Entra ID يقيّم آلاف الإشارات قبل منح الوصول — مستوى خطورة المستخدم، الموقع، حساسية التطبيق، وصحة الجهاز. هذا مستوى أمان لا يمكن تحقيقه بسياسات المجموعة التقليدية.
• تحديات الامتثال: إثبات الامتثال في بيئة مختلطة فوضوي ومعقد — وأي شخص مرّ بتدقيق أمني يعرف هذا جيدًا.

استكشاف أخطاء Microsoft Entra Connect Sync

أداة Microsoft Entra Connect Sync (المعروفة سابقًا بـ Azure AD Connect) هي الجسر بين AD المحلي و Entra ID السحابي. وهي مصدر شائع للمشاكل. تحديثات سبتمبر وأكتوبر 2025 تسببت في مشاكل مزامنة المجموعات الأمنية الكبيرة (أكثر من 10,000 عضو).

# التحقق من حالة المزامنة
Start-ADSyncSyncCycle -PolicyType Delta

# عرض أخطاء المزامنة
Get-ADSyncConnectorRunStatus

# عرض الكائنات التي فشلت في المزامنة
Get-ADSyncCSObject -ConnectorName "company.local" |
    Where-Object { $_.HasSyncError -eq $true }

# التحقق من حالة خدمة المزامنة
Get-Service ADSync

# عرض سجل المزامنة
Get-EventLog -LogName Application -Source "Directory Synchronization" -Newest 20

# إعادة تشغيل مزامنة كاملة (استخدم بحذر!)
Start-ADSyncSyncCycle -PolicyType Initial

حل مشكلة مزامنة المجموعات الكبيرة

المشكلة المعروفة في تحديثات سبتمبر-أكتوبر 2025: التطبيقات التي تستخدم DirSync Control مع AD DS المحلي (مثل Entra Connect Sync) قد تؤدي إلى مزامنة غير مكتملة للمجموعات الأمنية الكبيرة. إذا واجهت هذه المشكلة، إليك ما يجب فعله:

# التحقق من تحديث Windows Server المثبت
Get-HotFix | Where-Object {
    $_.HotFixID -in @('KB5043080', 'KB5044284')
} | Select-Object HotFixID, InstalledOn

# إذا كان التحديث المسبب للمشكلة مثبتًا، حدّث لآخر إصدار تصحيحي
# أو كحل مؤقت، قسّم المجموعات الكبيرة إلى مجموعات فرعية أصغر

# التحقق من عدد أعضاء المجموعات الكبيرة
Get-ADGroup -Filter * -Properties Members |
    Where-Object { $_.Members.Count -gt 5000 } |
    Select-Object Name, @{N='MemberCount';E={$_.Members.Count}} |
    Sort-Object MemberCount -Descending |
    Format-Table -AutoSize

أفضل ممارسات المراقبة والصيانة الدورية

قائمة فحص يومية لمسؤول Active Directory

الوقاية خير من العلاج — مقولة قديمة لكنها صحيحة تمامًا هنا. إليك سكربت فحص يومي يمكنك جدولته عبر Task Scheduler وسيوفر عليك ساعات من استكشاف الأخطاء لاحقًا:

# سكربت الفحص اليومي لصحة Active Directory
# احفظه كـ Daily-AD-HealthCheck.ps1 وجدوله عبر Task Scheduler

$report = @()
$timestamp = Get-Date -Format "yyyy-MM-dd HH:mm:ss"

# 1. التحقق من خدمات AD على جميع وحدات التحكم
$dcs = Get-ADDomainController -Filter *
foreach ($dc in $dcs) {
    $services = @('NTDS','DNS','kdc','Netlogon','DFSR')
    foreach ($svc in $services) {
        $status = (Get-Service -ComputerName $dc.HostName -Name $svc -EA SilentlyContinue).Status
        if ($status -ne 'Running') {
            $report += "WARNING: $svc on $($dc.HostName) is $status"
        }
    }
}

# 2. التحقق من النسخ المتماثل
$replStatus = repadmin /replsummary /bysrc /bydest /sort:delta
if ($replStatus -match "fail") {
    $report += "WARNING: Replication failures detected"
    $report += $replStatus
}

# 3. التحقق من مساحة القرص على وحدات التحكم
foreach ($dc in $dcs) {
    $disk = Get-CimInstance Win32_LogicalDisk -ComputerName $dc.HostName `
        -Filter "DeviceID='C:'" -EA SilentlyContinue
    if ($disk) {
        $freeGB = [math]::Round($disk.FreeSpace / 1GB, 2)
        if ($freeGB -lt 10) {
            $report += "WARNING: $($dc.HostName) has only ${freeGB}GB free on C:"
        }
    }
}

# 4. التحقق من حسابات مُغلقة
$lockedAccounts = Search-ADAccount -LockedOut
if ($lockedAccounts) {
    $report += "INFO: $($lockedAccounts.Count) locked accounts found:"
    $lockedAccounts | ForEach-Object {
        $report += "  - $($_.SamAccountName) ($($_.Name))"
    }
}

# 5. التحقق من شهادات وحدات التحكم
foreach ($dc in $dcs) {
    $certs = Invoke-Command -ComputerName $dc.HostName -ScriptBlock {
        Get-ChildItem Cert:\LocalMachine\My |
            Where-Object { $_.NotAfter -lt (Get-Date).AddDays(30) }
    } -EA SilentlyContinue
    if ($certs) {
        $report += "WARNING: Certificates expiring soon on $($dc.HostName)"
    }
}

# إرسال التقرير أو حفظه
$report | Out-File "C:\Logs\AD-Health-$($timestamp.Replace(':','-')).txt"
if ($report -match "WARNING") {
    Send-MailMessage -To "[email protected]" -From "[email protected]" `
        -Subject "AD Health Alert - $timestamp" `
        -Body ($report -join "`n") -SmtpServer "mail.company.local"
}

مراقبة عدادات الأداء الجديدة في Windows Server 2025

يوفر Windows Server 2025 عدادات أداء جديدة لمراقبة DC Locator وعمليات بحث LSA. هذه العدادات تساعد في تشخيص مشاكل الأداء التي كان من الصعب تتبعها في الإصدارات السابقة:

# عرض عدادات أداء NTDS الأساسية
Get-Counter '\NTDS\DRA Inbound Bytes Total/sec',
    '\NTDS\DRA Outbound Bytes Total/sec',
    '\NTDS\LDAP Searches/sec',
    '\NTDS\LDAP Successful Binds/sec',
    '\NTDS\DS Threads In Use' -SampleInterval 5 -MaxSamples 12

# مراقبة أوقات استجابة LDAP
Get-Counter '\NTDS\LDAP Search Time' -SampleInterval 5 -MaxSamples 12

# عدادات DC Locator الجديدة في Windows Server 2025
Get-Counter '\DC Locator(*)\*' -SampleInterval 5 -MaxSamples 6

جدول الصيانة الأسبوعي والشهري

إلى جانب الفحص اليومي، هناك مهام دورية لا يجب إهمالها:

المهمة	التكرار	الوصف	الأداة
فحص صحة النسخ المتماثل	يوميًا	التحقق من عدم وجود أخطاء نسخ متماثل	repadmin /replsummary
مراجعة الحسابات المُغلقة	يوميًا	تحديد أنماط الإغلاق المتكرر	Search-ADAccount -LockedOut
تنظيف سجلات DNS القديمة	أسبوعيًا	إزالة السجلات المنتهية الصلاحية	DNS Scavenging
مراجعة سجلات الأحداث	أسبوعيًا	البحث عن أخطاء متكررة	Event Viewer / PowerShell
نسخ احتياطي لحالة النظام	أسبوعيًا	النسخ الاحتياطي لقاعدة بيانات AD	wbadmin start systemstatebackup
مراجعة عضويات المجموعات الحساسة	شهريًا	التحقق من Domain Admins وEnterprise Admins	Get-ADGroupMember
تحديث قوالب ADMX	عند الإصدار	تحديث القوالب مع كل تحديث رئيسي	نسخ يدوي إلى Central Store
مراجعة صلاحية الشهادات	شهريًا	التحقق من شهادات وحدات التحكم	certutil / PowerShell

نصائح ختامية لفرق الدعم الفني

بناء قاعدة معرفية داخلية

نصيحة من واقع التجربة: كل مشكلة تحلها هي فرصة لتوثيق الحل. أنشئ قاعدة معرفية داخلية تتضمن:

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

ستشكر نفسك لاحقًا عندما تواجه نفس المشكلة بعد ستة أشهر ولا تتذكر الحل.

متابعة التحديثات والمستجدات

بيئة Active Directory في تطور مستمر. تابع هذه المصادر بانتظام:

• مدونة فريق Windows Server في Microsoft: للإعلانات الرسمية عن الميزات الجديدة والمشاكل المعروفة.
• لوحة صحة إصدارات Windows: لمتابعة المشاكل المعروفة في التحديثات الأخيرة.
• مجتمع Microsoft Tech Community: للنقاشات التقنية وتبادل الخبرات.
• كتالوج Microsoft Update: لتنزيل التحديثات التصحيحية خارج الدورة المعتادة.

الاستعداد للمستقبل

مع توجه Microsoft نحو Entra ID كمنصة الهوية الأساسية، من المهم أن تبدأ ببناء مهاراتك في هذه المجالات:

• الوصول المشروط (Conditional Access): إنشاء وإدارة سياسات الوصول المبنية على السياق.
• Microsoft Intune: إدارة الأجهزة والسياسات من السحابة.
• تسجيل الأجهزة في Entra ID: فهم الفرق بين Entra ID Join و Hybrid Join ومتى تستخدم كلاً منهما.
• Microsoft Graph API: الأتمتة والتكامل مع خدمات Microsoft 365.

Active Directory لن يختفي قريبًا — المؤسسات الكبيرة لا تزال تعتمد عليه بشكل كبير، وسيظل جزءًا أساسيًا من البنية التحتية لسنوات قادمة. لكن الاتجاه واضح: المستقبل سحابي. ابدأ الآن ببناء قدراتك في كلا العالمين — المحلي والسحابي — لتكون مستعدًا لأي تحدٍّ.