Active Directory fiókzárolás kivizsgálása 2026: Event ID 4740 és PowerShell útmutató

Frissítve: 2026. június 14.

Az Active Directory fiókzárolás kivizsgálásának leggyorsabb módja a Security napló Event ID 4740 bejegyzéseinek lekérdezése a PDC Emulator domain kontrolleren, mert minden lockout esemény oda replikálódik az eredeti DC-ről. A 4740 esemény tartalmazza a zárolt felhasználói fiók nevét és a Caller Computer Name mezőt, amely megmutatja, melyik eszköz küldte a rossz jelszót. Ebből az útmutatóból megtudja, hogyan találja meg pontosan a zárolás forrását PowerShell parancsokkal, mely gyakori háttérfolyamatok okozzák a problémát (gyorsítótárazott RDP munkamenetek, leképezett meghajtók, mobil eszközök, Windows szolgáltatások), és hogyan oldja fel a fiókot anélkül, hogy a hiba újra előállna.

• A 4740 Security eseményt a PDC Emulator szerepkört betöltő domain kontrolleren kell keresni, mert minden zárolás ide replikálódik, függetlenül attól, hol történt.
• A Search-ADAccount -LockedOut PowerShell parancs egy másodperc alatt listázza az összes jelenleg zárolt fiókot a tartományban.
• A 4740 esemény TargetUserName és SubjectMachineName (Caller Computer Name) mezői pontosan megmutatják, ki és melyik gépről okozta a zárolást.
• A leggyakoribb háttérben futó okok: régi gyorsítótárazott jelszó RDP munkamenetekben, leképezett hálózati meghajtók, ütemezett feladatok, Windows szolgáltatások és telefonokon konfigurált Exchange ActiveSync.
• A fiók feloldása a Unlock-ADAccount paranccsal csak átmeneti megoldás, mert a forrást is meg kell szüntetni, különben a zárolás 5–10 percen belül visszatér.
• A 2026-ban már elavult Microsoft Account Lockout and Management Tools (ALTools) helyett a beépített ActiveDirectory PowerShell modul és a Microsoft Entra ID Sign-in logs ajánlott.

Mi okozza az Active Directory fiókzárolást?

Az Active Directory fiókzárolás akkor következik be, amikor egy felhasználó (vagy egy nevében futó folyamat) az Account Lockout Threshold csoportházirendben meghatározott számszor egymás után helytelen jelszót ad meg. Ezt a házirendet a Default Domain Policy tartalmazza, és a tipikus beállítás a CIS Benchmarks 2026 ajánlása szerint 10 sikertelen kísérlet 15 perces ablakban, 15 perces zárolási időtartammal. A küszöbérték elérésekor a DC a userAccountControl attribútumon beállítja a locked bitet, és minden további bejelentkezési kísérlet azonnal elutasításra kerül.

A helpdesk szempontjából viszont a kritikus felismerés az, hogy a végfelhasználó ritkán a tényleges hibás jelszó beíró. Őszintén szólva, a saját tapasztalataim alapján a tickettek nagyjából 80 százalékában valami háttérfolyamat tárol egy régi jelszót, és a felhasználó nem is sejti. A modern Windows ökoszisztémában rengeteg ilyen háttérfolyamat van: a Credential Manager, az ütemezett feladatok, a Windows szolgáltatások, az RDP munkamenetek, a leképezett hálózati meghajtók, a böngészők elmentett jelszavai, valamint az okostelefonokon konfigurált Exchange ActiveSync vagy IMAP fiókok. Amikor a felhasználó megváltoztatja a jelszavát, ezek mindegyike megpróbálhatja a régi hitelesítő adatokkal kapcsolódni, gyakran másodpercenként többször is, percek alatt elérve a küszöböt.

Tipikus jel: a felhasználó arra panaszkodik, hogy „semmit nem csináltam, csak megérkeztem reggel és már zárolva voltam”. Ez szinte mindig azt jelenti, hogy a háttérben fut egy szolgáltatás vagy egy mobil eszköz a régi jelszóval. A 4740 esemény nyomozása nélkül a feloldás csak ideiglenes javítás.

Miért a PDC Emulátoron kell keresni az Event ID 4740 eseményt?

Amikor egy domain kontroller fogadja a lockout-küszöböt elérő sikertelen jelszót, azonnal továbbítja a zárolási kérést a PDC Emulator FSMO szerepkört betöltő DC-nek. A PDC Emulator hivatalos referenciaként szolgál a fiókzárolási és jelszóváltási eseményekhez, így a teljes tartomány zárolási előzménye egyetlen szerveren összegyűlik. Ez azt jelenti, hogy nem kell minden DC Security naplóját átfésülnie, elég a PDC-t lekérdezni.

Egy korábbi projektemben, amikor egy 12 DC-s környezetben próbáltam egyenként végigmenni az eseménynaplókon, négy órát vesztettem el, mire rájöttem erre a működésre. Ne ismételje meg a hibámat. A PDC Emulator azonosítását PowerShell-ben így végezheti el:

# A jelenlegi PDC Emulator megkeresése a domainben
Get-ADDomain | Select-Object PDCEmulator

# Példa kimenet:
# PDCEmulator
# -----------
# DC01.contoso.local

A 4740 esemény minden zárolásnál naplózásra kerül a PDC Emulator Security naplójába (feltéve, hogy az Audit Account Management és Audit User Account Management alkategóriák engedélyezve vannak; modern Windows Server 2022 és 2025 telepítéseken alapértelmezetten igen). Az esemény legfontosabb mezői a kivizsgálásban:

• TargetUserName: a zárolt felhasználó sAMAccountName értéke.
• TargetDomainName: a forrásgép neve, ahonnan a sikertelen kísérlet érkezett. Ez a kulcs az igazi tettes megtalálásához.
• SubjectUserName: annak a DC-nek a számlafiókja, amely a zárolást kiváltotta.
• TimeCreated: a zárolás pontos időbélyege UTC-ben.

A Microsoft hivatalos dokumentációja részletes leírást ad az eseményről: Audit User Account Management és 4740 esemény részletek. Érdemes elolvasni, mert a mezők sorrendje és típusa eltér a 4625 eseménytől.

PowerShell parancsok a zárolás forrásának megtalálásához

Na, most jöjjön a gyakorlat. A legtisztább módszer az Event ID 4740 eseményeinek programozott lekérdezése PowerShell-lel közvetlenül a PDC Emulator naplójából. Ehhez ki kell zárni a régóta nem támogatott Microsoft ALTools (LockoutStatus.exe, AcctInfo.dll) használatát, mert ezek 2026-ban már nem kompatibilisek a Windows Server 2022/2025 LSA-architektúrájával. Helyette használja a beépített ActiveDirectory és Microsoft.PowerShell.Diagnostics modulokat.

Az alábbi szkript az elmúlt 24 óra zárolási eseményeit listázza a PDC-ről, beleértve a forrásgépet:

# Az elmult 24 ora osszes 4740 esemenye a PDC Emulatorrol
$pdc = (Get-ADDomain).PDCEmulator
$since = (Get-Date).AddHours(-24)

Get-WinEvent -ComputerName $pdc -FilterHashtable @{
    LogName = 'Security'
    Id      = 4740
    StartTime = $since
} | ForEach-Object {
    [PSCustomObject]@{
        Time          = $_.TimeCreated
        LockedUser    = $_.Properties[0].Value
        SourceComputer = $_.Properties[1].Value
        DomainController = $_.MachineName
    }
} | Format-Table -AutoSize

A SourceComputer oszlop megmutatja, melyik gép küldte a hibás jelszót. Ha ez egy munkaállomás vagy laptop neve, jelentkezzen be arra a gépre és vizsgálja meg a Credential Managert, a leképezett meghajtókat és az ütemezett feladatokat. Ha egy szerver vagy egy üres karakterlánc jelenik meg, akkor valószínűleg egy szolgáltatásfiók vagy egy mobil eszköz a tettes.

Konkrét felhasználó zárolási előzményének részletes kinyerése:

# Egy konkret felhasznalo lockout esemenyei az elmult 7 napban
$pdc = (Get-ADDomain).PDCEmulator
$user = 'kovacs.peter'

Get-WinEvent -ComputerName $pdc -FilterHashtable @{
    LogName = 'Security'
    Id      = 4740
    StartTime = (Get-Date).AddDays(-7)
} | Where-Object { $_.Properties[0].Value -eq $user } |
Select-Object TimeCreated,
              @{n='Caller';e={$_.Properties[1].Value}},
              @{n='DC';e={$_.MachineName}}

Ha a forrásgépen szeretne tovább nyomozni, a 4625 esemény (An account failed to log on) mutatja meg a sikertelen kísérlet pontos folyamatát, beleértve a hitelesítési csomagot (NTLM, Kerberos) és a Logon Type értéket (3 = hálózati, 8 = NetworkCleartext, 10 = RemoteInteractive). Ez segít megkülönböztetni egy IMAP-klienst egy RDP munkamenettől. Egyébként a Microsoft Learn 4625 eseményleírása sokat segít a Logon Type értelmezésében.

A leggyakoribb fiókzárolási források a gyakorlatban

A 4740 esemény forrásgép mezőjét értelmezve a következő mintázatok fedik le a helpdesk ticketek nagyjából 90 százalékát. Érdemes ezeket listaszerűen végigellenőrizni a felhasználóval, mielőtt mélyebb diagnosztikába kezdene.

Mobil eszközök (Exchange ActiveSync / Outlook Mobile)

Ha a forrásgép egy Exchange szerver vagy üres mező, és a felhasználó nemrég cserélt jelszót, gyakran a telefonján vagy táblagépén tárolt régi hitelesítő adat a hibás. A megoldás: a felhasználó eltávolítja az Exchange-fiókot a telefonjáról, majd újra felveszi az új jelszóval. Hibrid környezetben az Entra ID Sign-in logs (Diagnostic settings > SignInLogs) is megmutatja a régi tokeneket használó eszközöket.

Régi RDP munkamenetek és lecsatlakozott Remote Desktop ablakok

Egy lecsatlakozott (disconnected) RDP munkamenet a háttérben tovább próbálkozhat újracsatlakozni a régi jelszóval. Ellenőrizze az érintett szervereken a quser /server:szerver01 paranccsal, és jelentkezzen ki a régi munkamenetekből.

Leképezett hálózati meghajtók és bejelentkezési szkriptek

A net use paranccsal kódolt jelszóval leképezett meghajtók klasszikus tettesek. A megoldás a net use * /delete /y futtatása, majd a meghajtó újra leképezése. A Windows VPN csatlakozási hibák esetén is gyakori, hogy egy split-tunnel konfigurációval futó leképezés okozza a lockoutot a VPN újraindítása után.

Windows szolgáltatások és ütemezett feladatok

Egy szolgáltatás vagy ütemezett feladat, amely a felhasználó fiókjával fut, és nem frissítették a jelszót, percenként többször próbálkozik. Ellenőrizze a services.msc „Log On As” oszlopát és a schtasks /query /v /fo LIST kimenetét a forrásgépen.

Böngészőben elmentett és Credential Manager bejegyzések

A Windows Credential Manager (Hitelesítő adatok kezelője) tárolt vállalati hitelesítő adatokat hagyhat a felhasználó profiljában. Nyissa meg a control /name Microsoft.CredentialManager ablakot, és törölje a domainhez tartozó régi bejegyzéseket. (Apró trükk: a böngészők elmentett jelszavait külön is érdemes átnézni, mert ezekre gyakran nem gondol senki.)

Hogyan oldjunk fel egy zárolt Active Directory fiókot?

Miután azonosította és megszüntette a forrást, oldja fel a fiókot. Ha azonnal feloldja a forrás megszüntetése nélkül, a zárolás 5–10 percen belül visszatér, és a felhasználó panaszkodni fog a helpdesken. Ezért a feloldási parancsot mindig a forrás megszüntetése után hajtsa végre.

# A jelenleg zarolt fiokok listazasa a teljes domainben
Search-ADAccount -LockedOut | Select-Object Name, SamAccountName, LastLogonDate

# Egy konkret fiok feloldasa
Unlock-ADAccount -Identity 'kovacs.peter'

# Tobb fiok kotegelt feloldasa egy CSV alapjan
Import-Csv .\unlock-list.csv | ForEach-Object {
    Unlock-ADAccount -Identity $_.sAMAccountName -Confirm:$false
}

Ha a felhasználó elfelejtette a jelszavát is, a feloldással együtt új ideiglenes jelszót is beállíthat, és kényszerítheti a következő bejelentkezésnél a cserét:

# Jelszovaltas + feloldas + kotelezo csere a kovetkezo bejelentkezesnel
$newPassword = ConvertTo-SecureString 'Ide!Jon@AzIdeiglenes2026' -AsPlainText -Force
Set-ADAccountPassword -Identity 'kovacs.peter' -NewPassword $newPassword -Reset
Set-ADUser -Identity 'kovacs.peter' -ChangePasswordAtLogon $true
Unlock-ADAccount -Identity 'kovacs.peter'

Account Lockout Policy beállítása és megelőzés

A megelőzés a leghatékonyabb hibaelhárítás. Az Active Directory Account Lockout Policy három csoportházirend-beállításból áll, és a Default Domain Policy alatt található (Computer Configuration > Policies > Windows Settings > Security Settings > Account Policies > Account Lockout Policy). A Microsoft hivatalos referenciája a Microsoft Learn Account Lockout Policy dokumentációja.

Beállítás	Túl szigorú	CIS 2026 ajánlás	Túl megengedő
Account lockout threshold	3 kísérlet	10 kísérlet	0 (nincs zárolás)
Account lockout duration	0 perc (adminisztrátori feloldás)	15 perc	5 perc
Reset account lockout counter after	1 perc	15 perc	60 perc
Helpdesk ticket volumen	Magas (sok hamis zárolás)	Közepes	Alacsony (de brute-force kockázat)
Brute-force védelem	Erős	Erős	Gyenge

A 0 kísérletes (kapcsolva nincs zárolás) beállítás 2026-ban már nem felel meg a legtöbb biztonsági szabványnak (ISO 27001:2025, SOC 2 Type II, GDPR Art. 32), kivéve, ha az Entra ID Smart Lockout vagy hasonló cloud-alapú adaptív védelem helyettesíti. A 3 kísérletes ultra-szigorú beállítás viszont elárasztja a helpdesket, és valódi brute-force védelmi előny nélkül csak a felhasználói élményt rontja.

A megelőzés további lépései:

• Önkiszolgáló jelszóreset (SSPR) bevezetése Entra ID-val, ami drámaian csökkenti a helpdesk ticketek számát.
• Jelszó nélküli (passwordless) hitelesítés bevezetése Windows Hello for Business és FIDO2 kulcsokkal.
• A „Microsoft Authenticator number matching” engedélyezése, ami megakadályozza az MFA bombing támadásokat is, amelyek szintén okozhatnak zárolást.
• Felhasználói képzés: jelszóváltáskor távolítsák el a mobil eszközökről a vállalati fiókokat, és vegyék fel újra.

Hibrid környezet: Entra ID Smart Lockout és lokál AD együtt

2026-ban a vállalatok döntő többsége hibrid identitásmodellt használ: a lokális Active Directory szinkronizálódik a Microsoft Entra ID-val a Microsoft Entra Connect Sync (korábbi nevén Azure AD Connect) szolgáltatáson keresztül. Ez két párhuzamos zárolási mechanizmust eredményez: a lokál AD klasszikus Account Lockout Policy-t, és az Entra ID adaptív Smart Lockout funkcióját, amely IP-cím alapján különböztet meg gyanús és ismert kérőket.

Az Entra ID Smart Lockout külön számláló-térrel dolgozik, és a sikertelen kísérleteket nem szinkronizálja vissza a lokál AD-be. Fordítva is igaz: a lokál AD zárolás nem akadályozza meg az Entra ID bejelentkezést, hacsak nem aktív a Password Hash Sync + Seamless SSO kombináció. Ennek következtében hibrid környezetben mindkét oldalt vizsgálni kell. Az Entra ID-oldali nyomozáshoz használja az Entra portál Sign-in logs nézetét, és szűrjön a 50053 (IdsLocked) vagy 50057 (UserDisabled) hibakódokra.

Federation vagy Pass-through Authentication (PTA) esetén egy harmadik réteg is megjelenik: a PTA agent szerveren futó eseménynapló, amely az 1119 és 1124 Application eseményeket jelzi sikertelen jelszó-továbbításkor. Ezeket is érdemes integrálni a SIEM-be a teljes láthatóság érdekében.

Gyakran ismételt kérdések

Hogyan találom meg, hogy melyik gépről történik az Active Directory fiókzárolás?

A PDC Emulator Security naplójában keresse az Event ID 4740 eseményeket. A TargetDomainName (Caller Computer Name) mező mutatja a forrásgépet. PowerShell-ben: Get-WinEvent -ComputerName (Get-ADDomain).PDCEmulator -FilterHashtable @{LogName='Security'; Id=4740}.

Mi az Event ID 4740 a Windows Security naplóban?

Az Event ID 4740 azt jelzi, hogy egy felhasználói fiókot zároltak az Account Lockout Threshold elérése miatt. Az esemény a PDC Emulator szerepkört betöltő domain kontrolleren naplózódik, és tartalmazza a zárolt felhasználó nevét, valamint a sikertelen kísérlet forrásgépét.

Miért zárolódik újra és újra a felhasználó fiókja?

Szinte mindig egy háttérben futó folyamat tárolja a régi jelszót: mobil eszközön konfigurált Exchange ActiveSync, lecsatlakozott RDP munkamenet, leképezett hálózati meghajtó, Windows szolgáltatás vagy ütemezett feladat. A forrás megszüntetése nélkül a feloldás csak 5–10 percig tart.

Hogyan oldhatok fel egy zárolt AD fiókot PowerShell-lel?

Az Unlock-ADAccount -Identity 'felhasznalonev' parancs feloldja a fiókot. A zárolt fiókok listáját a Search-ADAccount -LockedOut paranccsal kérdezheti le. Mindkét parancshoz az ActiveDirectory PowerShell modul szükséges.

Mi a különbség az Active Directory és az Entra ID fiókzárolás között?

Az AD klasszikus Account Lockout Policy fix küszöb-alapú: X sikertelen kísérlet után zárol. Az Entra ID Smart Lockout adaptív: ismert IP-címekről több próbálkozást enged, ismeretlen vagy gyanús forrásokról kevesebbet. A két rendszer külön számlál, ezért hibrid környezetben mindkettőt vizsgálni kell.

Mennyi ideig marad zárolva egy fiók alapértelmezetten?

Az Account Lockout Duration csoportházirend határozza meg, ajánlott érték 15 perc. Ha 0 értékre van állítva, a fiók addig zárolva marad, amíg egy adminisztrátor manuálisan fel nem oldja az Unlock-ADAccount paranccsal vagy az Active Directory Users and Computers konzollal.