פתרון תקלות Active Directory — המדריך המלא לטכנאי Helpdesk

מבוא: למה Active Directory הוא הלב הפועם של כל ארגון

אם Outlook הוא מלך הטיקטים ב-Helpdesk, אז Active Directory הוא זה שעומד מאחורי הקלעים ומחליט מי בכלל נכנס למערכת. כשהוא עובד — אף אחד לא שם לב אליו. אבל כשהוא מתחיל לשבור? הכול קורס איתו.

Active Directory Domain Services (AD DS) הוא שירות הזהויות המרכזי ברוב הארגונים שמריצים תשתית מיקרוסופט. הוא מטפל באימות משתמשים, ניהול הרשאות, הפצת Group Policy, שירותי DNS פנימיים, ועוד רשימה ארוכה. כשה-AD לא זמין או לא עובד כמו שצריך — משתמשים לא מצליחים להתחבר, אפליקציות מתחילות להתנהג מוזר, ואפילו Outlook (שכבר כתבנו עליו מדריך נפרד) מפסיק לשתף פעולה.

לפי נתוני 2025–2026, בערך 25% מהטיקטים ב-Helpdesk ארגוני קשורים ישירות או עקיפות לבעיות Active Directory. נעילות חשבונות, סיסמאות שפגו, Group Policy שלא מתעדכן — הכול שם. וב-2026 העניינים הפכו למורכבים עוד יותר: מיקרוסופט דוחפת בכל הכוח את Microsoft Entra ID (השם החדש של Azure AD) כשכבת הזהות העננית, וזה יוצר סביבת Hybrid Identity שדורשת מטכנאים להכיר שני עולמות במקביל.

אז מה יש במדריך הזה? אבחון שיטתי של התקלות הכי נפוצות ב-AD, פקודות PowerShell מעשיות שאפשר להעתיק ישירות, טבלת תקלות מהירה לימי לחץ, והתייחסות לשינויים הקריטיים של 2026 בעולם ה-Hybrid Identity. בואו נתחיל.

נעילות חשבונות (Account Lockouts) — התקלה מספר 1

למה חשבונות ננעלים?

נעילת חשבון היא מנגנון הגנה בסיסי: כשמשתמש מקליד סיסמה שגויה יותר מדי פעמים (מעל הסף שהוגדר ב-Account Lockout Policy), החשבון ננעל אוטומטית. מבחינת אבטחה זה הגיוני לגמרי, אבל בפועל — ובואו נהיה כנים — רוב הנעילות לא נגרמות על ידי האקרים. הן נגרמות על ידי תהליכים לגיטימיים שפשוט משתמשים בפרטי גישה ישנים.

הנה הסיבות שחוזרות שוב ושוב:

• סיסמאות שמורות (Cached Credentials) — המשתמש שינה סיסמה, אבל לפטופ או טלפון אחר עדיין תקוע על הסיסמה הישנה
• שירותי Windows — שירות שמוגדר לרוץ עם חשבון משתמש, והסיסמה של אותו חשבון השתנתה
• Scheduled Tasks — משימות מתוזמנות עם פרטי גישה ישנים (זה קורה הרבה יותר ממה שחושבים)
• Outlook ו-ActiveSync — לקוחות דואר, במיוחד בניידים, ששולחים בקשות אימות עם סיסמה שכבר פגה
• שיתופי רשת ממופים (Mapped Drives) — כוננים ממופים שנשמרו עם סיסמה ישנה
• סשנים מנותקים (Disconnected RDP Sessions) — חיבורי Remote Desktop שלא נסגרו כמו שצריך. זו סיבה שקל לפספס
• התקפות Brute Force — ניסיונות כניסה זדוניים, כולל Password Spraying. פחות שכיח, אבל כשזה קורה — זה רציני

צעד 1 — מציאת ה-PDC Emulator

כשחשבון ננעל, האירוע נרשם ב-Domain Controller הקרוב ומועבר ל-PDC Emulator — ה-DC שאחראי על עיבוד נעילות. זו נקודת ההתחלה שלכם.

# מציאת ה-PDC Emulator בדומיין
Get-ADDomainController -Filter * | Where-Object {
    $_.OperationMasterRoles -contains "PDCEmulator"
} | Select-Object HostName, IPv4Address

צעד 2 — בדיקת סטטוס נעילה

לפני שרצים לחפש את מקור הנעילה, שווה לוודא שהחשבון אכן נעול ומתי בדיוק זה קרה:

# בדיקת סטטוס חשבון
Get-ADUser -Identity "username" -Properties LockedOut, AccountLockoutTime, BadLogonCount, LastBadPasswordAttempt |
    Select-Object Name, LockedOut, AccountLockoutTime, BadLogonCount, LastBadPasswordAttempt

# רשימת כל החשבונות הנעולים כרגע
Search-ADAccount -LockedOut | Select-Object SamAccountName, LockedOut, LastLogonDate

צעד 3 — מציאת מקור הנעילה (Event ID 4740)

כל אירוע נעילה יוצר Event ID 4740 ביומן האבטחה של ה-DC. המידע הקריטי שם הוא Caller Computer Name — המכונה שממנה הגיעו ניסיונות הכניסה הכושלים. זה הזהב שלכם.

# סקריפט מלא למציאת מקור נעילה
$UserName = "username"
$PDC = (Get-ADDomainController -Filter * |
    Where-Object {$_.OperationMasterRoles -contains "PDCEmulator"}).HostName

$Events = Get-WinEvent -ComputerName $PDC -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4740
} -ErrorAction SilentlyContinue |
    Where-Object { $_.Properties[0].Value -eq $UserName }

$Events | ForEach-Object {
    [PSCustomObject]@{
        TimeCreated    = $_.TimeCreated
        UserName       = $_.Properties[0].Value
        CallerComputer = $_.Properties[1].Value
        DomainController = $_.MachineName
    }
} | Sort-Object TimeCreated -Descending | Format-Table -AutoSize

הפלט ייתן לכם את שם המחשב שממנו הגיעו הניסיונות הכושלים. משם ממשיכים לחקור.

צעד 4 — חקירת המחשב המקורי (Event ID 4625)

זיהיתם את המחשב? מצוין. עכשיו חפשו בו Event ID 4625 (כניסה כושלת) כדי לאתר את התהליך הספציפי שגורם לבעיה:

# חיפוש אירועי כניסה כושלת במחשב הספציפי
Get-WinEvent -ComputerName "COMPUTER-NAME" -FilterHashtable @{
    LogName = 'Security'
    Id      = 4625
} -MaxEvents 20 | ForEach-Object {
    [PSCustomObject]@{
        Time       = $_.TimeCreated
        Account    = $_.Properties[5].Value
        LogonType  = $_.Properties[10].Value
        Process    = $_.Properties[18].Value
        SourceIP   = $_.Properties[19].Value
    }
} | Format-Table -AutoSize

שימו לב ל-Logon Type — הוא מספר לכם בדיוק מאיפה הגיע הניסיון:

Logon Type	משמעות	חשוד טיפוסי
2	Interactive (כניסה מקומית)	משתמש ליד המחשב
3	Network	כונן ממופה, שיתוף רשת
4	Batch	Scheduled Task
5	Service	שירות Windows
7	Unlock	פתיחת מסך נעילה
10	RemoteInteractive	RDP

צעד 5 — פתיחת הנעילה

אחרי שמצאתם את מקור הבעיה ותיקנתם אותו — אפשר לפתוח את הנעילה:

# פתיחת נעילה למשתמש ספציפי
Unlock-ADAccount -Identity "username"

# אימות שהנעילה נפתחה
Get-ADUser -Identity "username" -Properties LockedOut | Select-Object Name, LockedOut

טעות נפוצה: טכנאים פותחים את הנעילה ועוברים לטיקט הבא. אם הנעילה חוזרת תוך דקות — הבעיה לא נפתרה, והמשתמש פשוט יינעל שוב. תמיד תמצאו את המקור לפני שאתם פותחים.

טיפ מקצועי: ניקוי Credentials שמורים

במקרים רבים הפתרון הסופי הוא פשוט לנקות פרטי גישה ישנים שנתקעו במחשב:

# פתיחת Credential Manager דרך שורת הפקודה
rundll32 keymgr.dll, KRShowKeyMgr

# או דרך Windows Credential Manager
control /name Microsoft.CredentialManager

כנסו גם ל-Credential Manager ב-Control Panel ומחקו כל ערך ישן שקשור לדומיין או לשרתים הפנימיים. מניסיון — זה פותר הרבה מקרים שנראים מסתוריים.

תקלות DNS — השורש הנסתר של רוב בעיות ה-AD

למה DNS כל כך קריטי ל-Active Directory?

Active Directory תלוי ב-DNS באופן מוחלט. ממש הכול — אימות, שכפול, חיפוש Group Policy, איתור Domain Controllers — עובר דרך רשומות DNS. כשה-DNS לא תקין, AD מתחיל להתפרק, ולפעמים בצורה שקשה לזהות כי הודעות השגיאה לא בהכרח מצביעות על DNS.

הכלל שלי פשוט: אם משהו מוזר קורה ב-AD ואין לכם מושג למה — תבדקו DNS קודם. תמיד DNS קודם.

בדיקות DNS בסיסיות

# בדיקה שרשומות SRV של ה-DC קיימות
nslookup -type=srv _ldap._tcp.dc._msdcs.DOMAIN.LOCAL

# בדיקת רשומת SRV של Kerberos
nslookup -type=srv _kerberos._tcp.DOMAIN.LOCAL

# בדיקה שה-DC יכול לפתור את עצמו
nslookup DC-SERVER-NAME

# בדיקה מקיפה עם dcdiag
dcdiag /test:dns /v

אם nslookup לא מחזיר רשומות SRV — מצאתם את הבעיה. בלי רשומות SRV, המחשבים ברשת פשוט לא יכולים למצוא את ה-Domain Controller. ככה זה.

רישום מחדש של רשומות DNS

רשומות SRV חסרות? אפשר לרשום אותן מחדש בקלות:

# ב-Domain Controller — הפעלה מחדש של שירות Netlogon לרישום SRV
net stop netlogon && net start netlogon

# רישום מחדש של רשומות DNS מהלקוח
ipconfig /registerdns

# ניקוי מטמון DNS
ipconfig /flushdns

בדיקת הגדרות DNS בתחנות הלקוח

טעות קלאסית שאני רואה כל הזמן: תחנות עבודה שמוגדרות עם שרת DNS חיצוני (בדרך כלל 8.8.8.8 של Google) במקום שרת ה-DNS הפנימי. מה שקורה? התחנה לא מצליחה למצוא את ה-Domain Controller כי Google DNS לא מכיר את הרשומות הפנימיות של הארגון. פשוט ככה.

# בדיקת הגדרות DNS בתחנת הלקוח
Get-DnsClientServerAddress -AddressFamily IPv4 |
    Select-Object InterfaceAlias, ServerAddresses |
    Format-Table -AutoSize

# הגדרות DNS צריכות להצביע על ה-DC הפנימי, לא על 8.8.8.8!

שכפול AD נכשל (Replication Failures)

למה שכפול חשוב?

בסביבה עם יותר מ-Domain Controller אחד (וזה המצב ברוב הארגונים), כל שינוי — סיסמה חדשה, חשבון חדש, שינוי GPO — צריך לעבור שכפול בין כל ה-DCs. כששכפול נכשל, נוצר מצב בלתי אפשרי: DC אחד מכיר סיסמה אחת ו-DC אחר מכיר סיסמה אחרת.

מתכון לכאוס מוחלט.

אבחון שכפול עם repadmin

# סיכום מצב שכפול בכל ה-DCs
repadmin /replsummary

# הצגת שכפול נכשל בלבד
repadmin /showrepl * /errorsonly

# בדיקת מטה-דאטה של שכפול
repadmin /showrepl DC-SERVER-NAME

# אילוץ שכפול מיידי
repadmin /syncall /AdeP

הדגלים בפקודה האחרונה (כי אני יודע שתשאלו):

• /A — כל ה-Partitions
• /d — זיהוי לפי Distinguished Name
• /e — כולל Sites אחרים (Enterprise)
• /P — Push (דחיפת שינויים)

בדיקת בריאות ה-DC עם dcdiag

# בדיקה מקיפה של בריאות ה-Domain Controller
dcdiag /v /c /d /e /s:DC-SERVER-NAME

# בדיקות ספציפיות
dcdiag /test:replications
dcdiag /test:connectivity
dcdiag /test:services

אם dcdiag מדווח על כשלים בשכפול — תבדקו DNS קודם (כמו שכבר אמרנו) ואז חיבוריות רשת בין ה-DCs. ודאו שהפורטים הבאים פתוחים: 389 (LDAP), 636 (LDAPS), 3268 (GC), ו-88 (Kerberos).

Group Policy לא מיושם (GPO Not Applying)

זרימת העבודה לאבחון GPO

Group Policy הוא אחד הכלים החזקים ביותר ב-Active Directory — ואחד המתסכלים ביותר כשהוא מחליט לא לעבוד. יש תהליך שיטתי שחוסך הרבה כאב ראש.

צעד 1 — gpresult לאבחון ראשוני

# יצירת דוח GPO מפורט בפורמט HTML
gpresult /h C:\GPReport.html /f
start C:\GPReport.html

# הצגה מהירה בקונסול
gpresult /r

# עבור מחשב מרוחק
gpresult /s COMPUTER-NAME /h C:\GPReport.html /f

הדוח מראה בדיוק אילו GPOs הוחלו ואילו נדחו — כולל הסיבה. חפשו את הסעיף "The following GPOs were not applied because they were filtered out". שם בדרך כלל מתחבא התשובה.

צעד 2 — בדיקת סיבות נפוצות

GPO לא מיושם? הנה הרשימה שכדאי לעבור עליה (מהנפוץ לנדיר):

• Security Filtering שגוי — ה-GPO מקושר נכון, אבל למשתמש או למחשב חסרות הרשאות Read + Apply Group Policy. הטעות הקלאסית: מסירים Authenticated Users מה-Security Filtering בלי להוסיף הרשאת Read לקבוצה החלופית
• WMI Filter — פילטר WMI שנכשל בשקט. השאילתה לא מחזירה תוצאות, וה-GPO נדחה בלי שום הודעה ברורה
• Block Inheritance — ה-OU חוסם ירושה מ-OU עליון
• קישור לא פעיל — ה-GPO מקושר אבל הקישור עצמו מושבת (Link Enabled = No). קל לפספס את זה
• בעיית SYSVOL — קבצי ה-GPO חסרים מתיקיית SYSVOL

צעד 3 — אילוץ עדכון GPO

# עדכון GPO מיידי בתחנת הלקוח
gpupdate /force

# עדכון GPO מרחוק למחשב ספציפי (דורש PowerShell 3.0+)
Invoke-GPUpdate -Computer "COMPUTER-NAME" -Force -RandomDelayInMinutes 0

צעד 4 — בדיקת SYSVOL

# בדיקה שתיקיית SYSVOL נגישה
dir \\DOMAIN.LOCAL\SYSVOL\DOMAIN.LOCAL\Policies

# בדיקת SYSVOL בכל ה-DCs
$DCs = Get-ADDomainController -Filter *
foreach ($DC in $DCs) {
    $Path = "\\$($DC.HostName)\SYSVOL"
    $Accessible = Test-Path $Path
    Write-Output "$($DC.HostName): SYSVOL Accessible = $Accessible"
}

צעד 5 — GPO Modeling לאבחון מתקדם

עדיין תקועים? פתחו את gpmc.msc והשתמשו ב-Group Policy Modeling כדי לדמות את תוצאות ה-GPO עבור משתמש או מחשב ספציפי. זה נותן תמונה מלאה — ירושה, פילטרים, דריסות, הכול.

שינויי 2026: Entra ID, Hybrid Identity ומה שטכנאים חייבים לדעת

2026 היא שנת מפנה רצינית בעולם ניהול הזהויות של מיקרוסופט. אם אתם טכנאי Helpdesk, יש כמה דברים שאתם חייבים להכיר — כי הם ישפיעו ישירות על העבודה היומיומית שלכם.

חסימת SyncJacking — יוני 2026

החל מ-1 ביוני 2026, Microsoft Entra תחסום ניסיונות Hard Match בין משתמש מקומי ב-AD לבין חשבון ענן שמחזיק בתפקידים מורשים (Privileged Roles). זוהי הגנה מפני טכניקת התקפה שנקראת SyncJacking — בגדול, מישהו מנצל את תהליך הסנכרון כדי לגנוב זהויות ענניות.

מה זה אומר בפועל? אם אתם עושים מיגרציה של משתמשים מ-AD מקומי ל-Entra ID, ומשתמש הענן הוא Global Admin או משהו דומה — הסנכרון ייכשל. הפתרון: הסירו זמנית את התפקיד המורשה, בצעו סנכרון, והחזירו את התפקיד.

חובת שדרוג Entra Connect — עד ספטמבר 2026

מיקרוסופט דורשת שדרוג Microsoft Entra Connect (לשעבר Azure AD Connect) לגרסה 2.5.79.0 לפחות עד 30 בספטמבר 2026. ארגונים שלא ישדרגו עלולים לגלות יום בהיר אחד שהסנכרון פשוט הפסיק לעבוד.

# בדיקת גרסת Entra Connect הנוכחית
Get-ADSyncGlobalSettings | Select-Object -ExpandProperty Parameters |
    Where-Object {$_.Name -eq "Microsoft.Synchronize.ServerConfigurationVersion"}

Passkeys כברירת מחדל — מרץ 2026

החל ממרץ 2026, מיקרוסופט מפעילה אוטומטית Passkey Profiles ומריצה קמפיינים לרישום Passkeys בכל ה-Tenants. בפועל, משתמשים יתחילו לראות הנחיות להגדרת Passkey — ותתכוננו למבול של שאלות מבולבלות.

כמה דברים שכדאי להכין מראש:

• מדריך קצר למשתמשים שמסביר מה זה Passkey ואיך מגדירים (ברמה של דף אחד)
• ודאו שמדיניות Conditional Access תואמת ל-Passkey enrollment
• חשבו על תרחיש שבו משתמש מאבד את ה-Passkey — מה תהליך השחזור אצלכם?

MFA חובה לכל גישה ל-Azure Portal — אוקטובר 2026

מ-1 באוקטובר 2026, מיקרוסופט תדרוש MFA לכל כניסה ל-Azure Portal. כולל Global Administrators. אין פטורים, אין דרך לעקוף. ארגונים שלא הפעילו MFA לאדמינים עד אז פשוט יחסמו.

ציר זמן — שינויי Entra ID ב-2026

תאריך	שינוי	השפעה על Helpdesk
פברואר 2026	זיהוי מכשירים פרוצים ב-Authenticator	משתמשים עם מכשירים פרוצים יחסמו
מרץ 2026	Passkey Profiles מופעלים אוטומטית	שאלות ובלבולים מצד משתמשים
יוני 2026	חסימת SyncJacking (Hard Match)	כשלי סנכרון בהעברת חשבונות מורשים
ספטמבר 2026	דדליין לשדרוג Entra Connect	הפסקות סנכרון אם לא משדרגים
אוקטובר 2026	MFA חובה ל-Azure Portal	חסימת אדמינים ללא MFA

טבלת תקלות מהירה — AD Quick Reference

הטבלה הזו? שמרו אותה בסימניות. כשנוחת טיקט שקשור ל-AD, תתחילו מכאן:

תסמין	בדיקה ראשונה	פקודה
משתמש נעול	מקור הנעילה (Event 4740)	Get-WinEvent -FilterHashtable @{LogName='Security';Id=4740}
לא מצליח להתחבר לדומיין	DNS — רשומות SRV	nslookup -type=srv _ldap._tcp.dc._msdcs.DOMAIN
GPO לא מיושם	דוח gpresult	gpresult /h C:\GPReport.html /f
שינויי סיסמה לא מתעדכנים	מצב שכפול	repadmin /replsummary
כניסה איטית	GPO Processing + DNS	gpresult /r + dcdiag /test:dns
מחשב נפל מהדומיין	איפוס חשבון מחשב	Reset-ComputerMachinePassword -Credential (Get-Credential)
Entra Connect לא מסנכרן	גרסה + לוגים	Get-ADSyncScheduler + Event Viewer > Application

כלי אבחון חיוניים — ערכת הכלים של טכנאי AD

אלה הכלים שכל טכנאי Helpdesk שנוגע ב-Active Directory חייב להכיר. אין דרך לעקוף את זה:

כלי	שימוש	הערות
Active Directory Users and Computers (ADUC)	ניהול משתמשים, קבוצות, OUs	הממשק הגרפי הבסיסי — כל טכנאי מכיר
Group Policy Management Console (GPMC)	ניהול GPOs, Modeling, Results	gpmc.msc
dcdiag	בדיקת בריאות Domain Controllers	חובה להריץ ראשון בכל חקירה
repadmin	אבחון ושליטה בשכפול AD	כשיש חשד לבעיית שכפול — זה הכלי
PowerShell AD Module	כל פעולות AD דרך סקריפטים	Import-Module ActiveDirectory
Event Viewer	יומני אבטחה ואירועים	Event IDs: 4740, 4625, 4771
LockoutStatus.exe	סטטוס נעילה בכל ה-DCs	כלי Microsoft חינמי (Account Lockout Tools)
nslookup / Resolve-DnsName	אבחון DNS	תמיד תבדקו DNS ראשון

שאלות נפוצות (FAQ)

איך מוצאים את המחשב שגורם לנעילת חשבון ב-Active Directory?

חפשו Event ID 4740 ביומן האבטחה של ה-PDC Emulator. האירוע מכיל שדה "Caller Computer Name" שמזהה את המכונה שממנה הגיעו ניסיונות הכניסה הכושלים. הריצו ב-PDC: Get-WinEvent -FilterHashtable @{LogName='Security';Id=4740}

מה ההבדל בין Active Directory לבין Microsoft Entra ID?

Active Directory (AD DS) הוא שירות זהויות מקומי שרץ על שרתי Windows Server בארגון. Microsoft Entra ID (לשעבר Azure AD) הוא שירות זהויות ענני. רוב הארגונים ב-2026 משתמשים בשניהם במה שנקרא Hybrid Identity, כאשר Entra Connect מסנכרן חשבונות בין הסביבה המקומית לענן.

למה Group Policy לא מיושם על מחשב ספציפי?

הסיבות הנפוצות: Security Filtering שגוי (חסרות הרשאות Read + Apply), WMI Filter שנכשל, חסימת ירושה (Block Inheritance) ב-OU, קישור GPO מושבת, או בעיית DNS שמונעת מהמחשב למצוא את ה-Domain Controller. התחילו עם gpresult /h C:\GPReport.html /f — זה יגלה לכם הכול.

כמה זמן לוקח לשכפול Active Directory להתעדכן בכל ה-Domain Controllers?

באותו Site — שכפול מתבצע תוך 15 שניות בממוצע (עם עד 3 שניות השהייה בין DCs). בין Sites שונים — תלוי בתצורה שהגדרתם, בדרך כלל בין 15 דקות לשעה. שינויי סיסמה הם חריגים — הם מועברים ל-PDC Emulator מיד כדי למנוע נעילות מיותרות.

מה לעשות כשמחשב "נופל" מהדומיין (trust relationship failed)?

השגיאה "The trust relationship between this workstation and the primary domain has failed" מופיעה כשסיסמת חשבון המחשב ב-AD יצאה מסנכרון. הפתרון המהיר: התחברו עם חשבון לוקאלי (לא דומיין), פתחו PowerShell כאדמין והריצו Reset-ComputerMachinePassword -Credential (Get-Credential). לא עבד? הסירו את המחשב מהדומיין וצרפו מחדש.