AD Account Lockout: Οδηγός Εντοπισμού Πηγής μέσω Event 4740 (2026)

Τελευταία ενημέρωση: 07 Ιουλίου 2026

Ένας λογαριασμός Active Directory κλειδώνει συνεχώς όταν επαναλαμβανόμενες αποτυχημένες προσπάθειες σύνδεσης ξεπερνούν το όριο του lockout policy. Για να εντοπίσετε την πηγή, ανοίξτε το Security event log του Domain Controller που κρατάει τον ρόλο PDC Emulator και βρείτε το πιο πρόσφατο Event ID 4740, όπου το πεδίο Caller Computer Name αποκαλύπτει το μηχάνημα που έστειλε τα λάθος διαπιστευτήρια. Από εκεί, ο έλεγχος γίνεται στοχευμένος: cached credentials στο Credential Manager, mapped drives, scheduled tasks, Windows services, mobile Outlook/ActiveSync profiles ή stale RDP sessions. Αυτός ο οδηγός καλύπτει PowerShell scripts, event correlation με 4625/4771/4776, hybrid Entra ID Smart Lockout και συμβατότητα με Windows Server 2025.

• Το Event ID 4740 καταγράφεται μόνο στον Domain Controller με ρόλο PDC Emulator, όχι στο μηχάνημα-πηγή του lockout.
• Το πεδίο Caller Computer Name του 4740 δείχνει το μηχάνημα που έστειλε τα λάθος διαπιστευτήρια, όχι απαραίτητα εκείνο που ο χρήστης προσπαθεί ενεργά να χρησιμοποιήσει.
• Οι πιο συχνές αιτίες επίμονων lockouts είναι cached credentials στο Credential Manager, mapped drives, scheduled tasks, Windows services και mobile Outlook/ActiveSync profiles.
• Το Windows Server 2025 έχει προεπιλογή lockout threshold 5 αποτυχημένων προσπαθειών και reset counter after 10 λεπτά, με το Allow Administrator Account Lockout ενεργό.
• Το Microsoft Entra Smart Lockout είναι πάντα ενεργό (default threshold 10, duration 60 δευτερόλεπτα) και φιλτράρει επιθέσεις πριν φτάσουν στο on-premises AD.
• Το PowerShell cmdlet Search-ADAccount -LockedOut επιστρέφει άμεσα όλους τους κλειδωμένους λογαριασμούς σε ολόκληρο το domain.

Γιατί κλειδώνει συνεχώς ένας λογαριασμός Active Directory;

Ειλικρινά, στην εμπειρία μου, το 90% των tickets «ο λογαριασμός μου κλειδώνει κάθε δέκα λεπτά» δεν αφορούν επίθεση. Αφορούν ξεχασμένα credentials κάπου στην υποδομή. Όταν ο χρήστης αλλάζει κωδικό, το AD τον ενημερώνει άμεσα, αλλά υπάρχουν δεκάδες σημεία όπου ο παλιός κωδικός εξακολουθεί να είναι αποθηκευμένος. Κάθε αποτυχημένη προσπάθεια αυθεντικοποίησης από αυτά τα σημεία μετρά προς το lockout threshold, και όταν φτάσει το όριο, ο λογαριασμός κλειδώνει. Ξανά και ξανά.

Οι αιτίες lockout χωρίζονται πρακτικά σε δύο κατηγορίες. Οι operational lockouts είναι σχεδόν πάντα αποτέλεσμα stale credentials: cached passwords σε Credential Manager, mapped drives, scheduled tasks που δημιουργήθηκαν πριν την αλλαγή κωδικού, Windows services που τρέχουν με domain account, disconnected RDP sessions, και (σε τηλεργασία που πλέον είναι νόρμα το 2026) mobile Outlook clients ή ActiveSync profiles που δεν έχουν πάρει τον νέο κωδικό. Οι security lockouts, από την άλλη, οφείλονται σε brute force, password spraying, ή σε τυχαία «γείτονα» IP που δοκιμάζει την ίδια θύρα RDP που έχετε εκθέσει σε δημόσιο δίκτυο.

Μια συχνή περίπτωση που βλέπω στη service desk: ο χρήστης λέει «δεν άγγιξα τίποτα, ξαφνικά κλείδωσε». Και στο 4740 βρίσκουμε ένα smartphone σε λογαριασμό Exchange. Ξέχασε να ενημερώσει τον κωδικό στο mail app του κινητού μετά την πολιτική ανανέωσης 90 ημερών. Πάντα ρωτάμε πρώτα «άλλαξες πρόσφατα κωδικό;» και «σε ποιες συσκευές έχεις προσωπικό ή εργασιακό email;». Οι δύο αυτές ερωτήσεις γλυτώνουν κατά μέσο όρο 15 λεπτά ανά ticket.

Πώς λειτουργεί το Event ID 4740 και ο ρόλος του PDC Emulator

Το Event ID 4740 γεννιέται στο Security log τη στιγμή που ένας λογαριασμός κλειδώνει επίσημα. Το κρίσιμο σημείο που πολλοί junior admins αγνοούν είναι ότι το event γράφεται μόνο στον Domain Controller που κρατάει τον ρόλο PDC Emulator, όχι σε όλους τους DCs, και σίγουρα όχι στο μηχάνημα του χρήστη. Ο PDC Emulator είναι ο κεντρικός συντονιστής για password changes και lockouts σε ολόκληρο το domain, οπότε όλες οι lockout πληροφορίες συγκεντρώνονται εκεί.

Τα βασικά πεδία μέσα στο 4740 που θα ελέγξετε πρώτα είναι:

• Account Name / Security ID: ο κλειδωμένος χρήστης.
• Caller Computer Name: το μηχάνημα από το οποίο ήρθαν τα λάθος credentials. Είναι το πιο σημαντικό πεδίο, αλλά προσοχή: δεν είναι πάντα το μηχάνημα που «κάθεται μπροστά» ο χρήστης.
• Time Created: η ώρα του lockout. Χρησιμοποιήστε τη για να συσχετίσετε με Event ID 4625 στον ίδιο χρόνο.

Για να καταγράφεται καθόλου το 4740, πρέπει να έχετε ενεργοποιήσει audit policy στους DCs. Ανοίξτε GPMC, επεξεργαστείτε το Default Domain Controllers Policy και ενεργοποιήστε Computer Configuration → Policies → Windows Settings → Security Settings → Advanced Audit Policy Configuration → Account Management → Audit User Account Management σε Success και Failure. Αν το logging δεν είναι ενεργό, δεν θα βρείτε ποτέ την πηγή. Δείτε επίσης τα Event IDs 4771 (Kerberos pre-auth failed) και 4776 (NTLM credential validation failed). Καταγράφονται και αυτά στον PDC και σας δίνουν context για το authentication protocol που απέτυχε.

Πώς βρίσκω την πηγή του lockout με PowerShell;

Η γρήγορη μέθοδος για να δείτε ποιοι λογαριασμοί είναι αυτή τη στιγμή κλειδωμένοι είναι το built-in AD cmdlet, χωρίς επιπλέον εργαλεία:

# Επιστρέφει όλους τους κλειδωμένους λογαριασμούς στο domain
Import-Module ActiveDirectory
Search-ADAccount -LockedOut | Select-Object Name, SamAccountName, LockedOut, LastLogonDate

# Ξεκλείδωμα ενός συγκεκριμένου χρήστη
Unlock-ADAccount -Identity jdoe

# Bulk ξεκλείδωμα όλων των κλειδωμένων λογαριασμών
Search-ADAccount -LockedOut | Unlock-ADAccount

Για να βρείτε την πηγή, στοχεύστε τον PDC Emulator απευθείας και τραβήξτε τα 4740 events:

# 1. Βρες τον PDC Emulator του domain
$PDC = (Get-ADDomain).PDCEmulator

# 2. Πάρε τα τελευταία 50 lockout events από τον PDC
Get-WinEvent -ComputerName $PDC -FilterHashtable @{
    LogName = 'Security'
    Id      = 4740
} -MaxEvents 50 |
Select-Object TimeCreated,
    @{Name='LockedUser';     Expression={$_.Properties[0].Value}},
    @{Name='CallerComputer'; Expression={$_.Properties[1].Value}} |
Format-Table -AutoSize

Αν θέλετε στοχευμένη αναζήτηση για συγκεκριμένο χρήστη (π.χ. όταν ένα ticket έρχεται από τον jdoe και θέλετε ιστορικό), χρησιμοποιήστε το εξής script που ταιριάζει το SID για να αποφύγετε ambiguity με ομώνυμους λογαριασμούς:

Import-Module ActiveDirectory

$UserName = Read-Host "Δώσε το SamAccountName του κλειδωμένου χρήστη"
$UserSid  = (Get-ADUser -Identity $UserName).SID.Value
$PDC      = (Get-ADDomain).PDCEmulator

Get-WinEvent -ComputerName $PDC -FilterHashtable @{
    LogName = 'Security'
    Id      = 4740
} -ErrorAction Stop |
Where-Object { $_.Properties[2].Value -match $UserSid } |
Sort-Object TimeCreated -Descending |
Select-Object @{L='Time';            E={$_.TimeCreated}},
              @{L='User';            E={$_.Properties[0].Value}},
              @{L='CallerComputer';  E={$_.Properties[1].Value}},
              @{L='DomainController';E={$_.MachineName}} |
Format-Table -AutoSize

Μόλις έχετε το Caller Computer Name, το επόμενο βήμα είναι να τρέξετε παρόμοιο query για Event ID 4625 (failed logon) πάνω σε εκείνο το μηχάνημα, στο ίδιο χρονικό παράθυρο. Το 4625 συνήθως αποκαλύπτει τη διαδικασία (LogonType, Process Name) που έστειλε τα λάθος credentials. Για παράδειγμα, LogonType 3 σημαίνει network logon, 5 service, 10 RemoteInteractive/RDP. Αν βλέπετε LogonType 5, ψάχνετε service. Αν βλέπετε LogonType 3 από exchange server, ψάχνετε Outlook profile ή ActiveSync partnership.

Βήμα-βήμα troubleshooting workflow για επίμονα lockouts

Αυτή είναι η ρουτίνα που εφαρμόζει η ομάδα μου σε κάθε επίμονο lockout ticket. Έχει σχεδιαστεί ώστε ένας L1 tech να μπορεί να την τρέξει χωρίς αρχιτεκτονικές γνώσεις.

1. Επιβεβαίωση lockout state. Τρέξτε Search-ADAccount -LockedOut για να επαληθεύσετε ότι ο λογαριασμός είναι πράγματι κλειδωμένος (μερικές φορές ο χρήστης πληκτρολογεί λάθος κωδικό και νομίζει ότι κλείδωσε).
2. Ερώτηση στον χρήστη. «Άλλαξες πρόσφατα κωδικό; Πού έχεις εγκατεστημένο Outlook, OneDrive, VPN client; Έχεις δουλειακό email σε προσωπικό κινητό;» Καταγράψτε τις απαντήσεις, γιατί θα εξηγήσουν τα περισσότερα 4625 events που θα δείτε.
3. Εντοπισμός Caller Computer Name. Τρέξτε το PowerShell script της προηγούμενης ενότητας για τον συγκεκριμένο χρήστη στον PDC Emulator.
4. Correlation με Event 4625. Στο μηχάνημα που εντοπίσατε, φιλτράρετε Security log για Event ID 4625 γύρω από την ώρα του lockout. Σημειώστε τα πεδία LogonType, Process Name, και Source Network Address.
5. Καθαρισμός stale credentials. Στο μηχάνημα-πηγή τρέξτε rundll32.exe keymgr.dll,KRShowKeyMgr ή ανοίξτε Control Panel → Credential Manager. Αφαιρέστε όλα τα Windows Credentials που δείχνουν σε domain resources.
6. Επιθεώρηση services και scheduled tasks. Τρέξτε sc.exe query και schtasks /query /V /FO LIST, αναζητώντας ό,τι τρέχει με domain account (π.χ. DOMAIN\svc_backup) και ενημερώστε τον κωδικό.
7. Έλεγχος mobile devices και Exchange. Αν το Caller Computer Name είναι Exchange server, ελέγξτε ActiveSync partnerships για τον χρήστη και βάλτε τον να επανασυνδέσει το mail app στο κινητό.
8. Ξεκλείδωμα και επαλήθευση. Ξεκλειδώστε τον λογαριασμό και παρακολουθήστε το Security log του PDC για 30 λεπτά. Αν δεν εμφανιστεί νέο 4740, το ticket κλείνει.

Το workflow αυτό λύνει τυπικά 8 στα 10 tickets σε λιγότερο από 20 λεπτά. Για τα υπόλοιπα (συνήθως application-specific) χρειάζεται deeper packet capture ή Exchange IIS log analysis, αλλά η βάση παραμένει η ίδια: event 4740 → caller computer → 4625 correlation → stale credential source. Δείτε επίσης τον οδηγό Entra ID SSPR για τον Σεπτέμβριο 2026 αν οι χρήστες σας κλειδώνονται συχνά επειδή ξεχνούν κωδικούς και θέλετε να ενεργοποιήσετε self-service reset.

Cached credentials, mapped drives και service accounts

Αυτές οι τρεις πηγές είναι υπεύθυνες, στα δικά μου στατιστικά της τελευταίας διετίας, για πάνω από το 70% των recurrent lockouts. Αξίζει έναν αναλυτικό checklist για κάθε μία.

Credential Manager (cached passwords)

Το Credential Manager αποθηκεύει διαπιστευτήρια για SMB shares, RDP sessions, Outlook, SharePoint, και οτιδήποτε άλλο ζήτησε «Remember my credentials». Μετά από password change, όλα αυτά μπαίνουν σε κύκλο retry, και το καθένα είναι ένα 4625.

# Εμφάνιση όλων των αποθηκευμένων credentials
cmdkey /list

# Διαγραφή ενός συγκεκριμένου target
cmdkey /delete:Domain:target=fileserver01.corp.local

# Ή σβήσιμο όλων για γρήγορο cleanup
cmdkey /list | ForEach-Object {
    if ($_ -like "*Target:*") {
        $target = $_ -replace ".*Target: ", ""
        cmdkey /delete:$target
    }
}

Mapped drives

Τα mapped drives συχνά συνδέονται με «Reconnect at sign-in» και αποθηκευμένα credentials. Ελέγξτε με net use στο μηχάνημα-πηγή και disconnect ό,τι δεν χρειάζεται, μετά reconnect με τα νέα credentials. Ένα συχνό pitfall είναι τα drives που έχουν γίνει map μέσω logon script. Αλλάξτε το script αν το username έχει hardcoded κωδικό.

Service accounts

Τα Windows services που τρέχουν με domain account χρειάζονται manual password update μετά από κάθε αλλαγή. Η μακροπρόθεσμη λύση, και αυτή που συστήνω σε κάθε organisation με πάνω από δέκα tech people, είναι Group Managed Service Accounts (gMSA). Το AD διαχειρίζεται το password rotation αυτόματα κάθε 30 μέρες, και ο κωδικός δεν είναι ποτέ ορατός σε άνθρωπο.

# Δημιουργία gMSA (μία φορά, από DC)
New-ADServiceAccount -Name "gmsa_backup" `
    -DNSHostName "gmsa_backup.corp.local" `
    -PrincipalsAllowedToRetrieveManagedPassword "BackupServers"

# Εγκατάσταση στο target server
Install-ADServiceAccount -Identity gmsa_backup

# Χρήση σε service (log on as = corp\gmsa_backup$, κενό password)
sc.exe config "BackupService" obj= "corp\gmsa_backup$" password=

Για βαθύτερο troubleshooting σε cascading credential issues, δείτε τον οδηγό επίλυσης shared mailbox στο νέο Outlook 2026. Καλύπτει παρόμοιες αιτίες credential mismatch που καταλήγουν σε lockouts.

Προεπιλεγμένη Account Lockout Policy στο Windows Server 2025

Στο Windows Server 2025, η Account Lockout Policy έχει τέσσερις ρυθμίσεις, με προεπιλογές που πλέον είναι ενεργές out-of-the-box. Είναι μια σημαντική διαφορά από Server 2019/2022, όπου έπρεπε να τις ορίσετε χειροκίνητα.

Ρύθμιση	Windows Server 2025 (default)	Entra ID Smart Lockout (default)
Account lockout threshold	5 αποτυχημένες προσπάθειες	10 αποτυχημένες προσπάθειες
Account lockout duration	Δεν ορίζεται (πρόταση: 15 λεπτά)	60 δευτερόλεπτα (αυξανόμενο)
Reset account lockout counter after	10 λεπτά	Αυτόματο
Allow Administrator account lockout	Ενεργοποιημένο	Δεν ισχύει
Πάντα ενεργό	Απαιτεί manual configuration	Ναι, δεν απενεργοποιείται

Για να δείτε ή να αλλάξετε τις τιμές, ανοίξτε Group Policy Management, επεξεργαστείτε το Default Domain Policy (ή ένα δικό σας GPO που είναι linked στο domain root) και πηγαίνετε στο Computer Configuration → Policies → Windows Settings → Security Settings → Account Policies → Account Lockout Policy. Οι αλλαγές εφαρμόζονται σε ολόκληρο το domain και προτεραιότητα έχουν τα Fine-Grained Password Policies (FGPP) αν υπάρχουν για συγκεκριμένες groups.

Entra ID Smart Lockout και υβριδική ταυτότητα

Το Microsoft Entra Smart Lockout είναι πάντα ενεργό για όλους τους tenants. Δεν χρειάζεται licensing για την προεπιλεγμένη λειτουργία, μόνο για customization (Entra ID P1 ή υψηλότερο). Οι default τιμές είναι 10 αποτυχημένες προσπάθειες ως threshold και 60 δευτερόλεπτα initial lockout duration, με το duration να αυξάνεται εκθετικά σε επαναλαμβανόμενες επιθέσεις.

Το «smart» κομμάτι είναι τρία πράγματα που δεν κάνει το on-prem AD lockout. Πρώτον, tracking των τελευταίων τριών bad password hashes: αν κάποιος πληκτρολογεί ξανά και ξανά τον ίδιο λάθος κωδικό (τυπική human error), δεν αυξάνεται counter. Δεύτερον, geo και IP behavior analysis: επιθέσεις από γνωστά malicious IPs μπλοκάρονται πριν καν φτάσουν στο threshold, με error code AADSTS50053. Τρίτον, sync του lockout state σε όλα τα Entra data centers, δηλαδή αν κλειδωθείς σε Ευρώπη, δεν μπορείς να δοκιμάσεις ξανά από Αμερική.

Σε hybrid environments με password hash sync (PHS), η κρίσιμη ρύθμιση είναι να έχετε το on-prem AD threshold υψηλότερο από το Entra threshold. Για παράδειγμα, AD στο 15, Entra στο 10. Αυτό διασφαλίζει ότι το Entra Smart Lockout φιλτράρει τις επιθέσεις πρώτο και δεν φτάνουν ποτέ στο on-prem να προκαλέσουν lockout σε πραγματικούς εργαζόμενους. Η αντίστροφη σχέση (AD threshold χαμηλότερο από Entra) οδηγεί σε classic scenario όπου password spray κλειδώνει όλο το accounting τμήμα μέσω legacy authentication.

Για να δείτε ή να ρυθμίσετε τα Entra Smart Lockout settings, μπείτε στο Entra Admin Center → Protection → Authentication methods → Password protection. Χρειάζεστε Global Administrator ή Security Administrator role. Οι αλλαγές παίρνουν μέχρι μία ώρα να προπαγανδιστούν σε όλα τα data centers. Σημείωση: από τον Σεπτέμβριο του 2026, το Entra απαιτεί explicitly registered authentication methods για SSPR. Αν οι χρήστες δεν έχουν εγγράψει methods εκ των προτέρων, θα καταλήξουν σε lockout loops χωρίς recovery option.

Βέλτιστες πρακτικές πρόληψης lockouts

Η πρόληψη είναι πάντα φτηνότερη από το troubleshooting. Οι πρακτικές που πραγματικά κάνουν διαφορά, με σειρά ROI:

• gMSA για services. Καμία υπηρεσία δεν πρέπει να τρέχει με domain user account. Migration σε gMSA κόβει το ~30% των recurring lockouts overnight.
• Self-Service Password Reset (SSPR). Όταν οι χρήστες μπορούν να ξεκλειδώνουν οι ίδιοι και να αλλάζουν κωδικό χωρίς να καλούν τη service desk, μειώνονται τα λάθη πληκτρολόγησης και οι κλήσεις κατά 40%. Δείτε τον οδηγό Entra ID SSPR authentication methods για σωστό deployment.
• Kerberos μόνο, καθόλου NTLM. Το NTLM δεν κάνει mutual authentication και είναι ιστορικά υπεύθυνο για misdiagnosed lockouts. Απενεργοποιήστε NTLM σταδιακά με GPO auditing.
• MFA και Conditional Access. Με MFA ενεργό, το password γίνεται δευτερεύον factor και οι επιθέσεις password spray δεν φτάνουν στο threshold. Conditional Access με risk-based sign-in κόβει malicious traffic πριν καν αγγίξει authentication.
• Time sync. Όλα τα domain members πρέπει να είναι εντός 5 λεπτών από τον PDC, αλλιώς Kerberos tickets αποτυγχάνουν και δημιουργούν φαινομενικά «τυχαία» lockouts.
• Monitoring με alerts. Στήστε alert στο SIEM για burst Event 4740 από τον PDC. 3+ lockouts στα ίδια 5 λεπτά συνήθως δηλώνει είτε broken service είτε active attack.
• Documentation στο ticketing. Κάθε φορά που λύνετε lockout, καταγράψτε την πηγή στο ticket. Μετά από 20-30 tickets θα δείτε patterns, π.χ. ένα συγκεκριμένο backup software που πάντα ξεχνά credentials.

Και μία τελευταία, πρακτική σημείωση: μην αγνοείτε τους Windows updates που σπάνε τον auth stack. Κάθε cumulative update στο Server 2025 έχει τη δυνατότητα να αλλάξει LSASS behavior, οπότε κρατήστε test DC με WSUS staging πριν patch σε production. Στη service desk μου, το είχαμε ολόκληρο post-mortem πέρσι όταν ένα update σκότωσε Kerberos delegation και κλείδωσε 200 accounts μέσα σε δύο ώρες.

Συχνές ερωτήσεις

Πόσο συχνά καταγράφεται το Event 4740 και σε ποιον DC θα το βρω;

Το Event ID 4740 καταγράφεται μία φορά για κάθε lockout, μόνο στον Domain Controller που κρατάει τον ρόλο PDC Emulator. Δεν αντιγράφεται στους άλλους DCs, γι' αυτό όλα τα scripts στοχεύουν κατευθείαν τον PDC.

Γιατί το Caller Computer Name στο 4740 είναι κενό;

Συνήθως επειδή το authentication ήρθε από συσκευή που δεν στέλνει hostname, όπως RADIUS server, VPN concentrator, ή Exchange reverse proxy. Ελέγξτε τα IIS logs του Exchange, τα VPN authentication logs, ή τα RADIUS accounting records για την πραγματική πηγή IP.

Μπορώ να ξεκλειδώσω πολλούς λογαριασμούς ταυτόχρονα;

Ναι, τρέξτε Search-ADAccount -LockedOut | Unlock-ADAccount από ένα PowerShell με domain admin rights. Το cmdlet ξεκλειδώνει όλους ταυτόχρονα, αλλά αν δεν έχετε λύσει την υποκείμενη αιτία, θα ξανακλειδώσουν σε λίγα λεπτά.

Πώς διακρίνω legitimate user error από brute force attack;

Δείτε τον ρυθμό των Event 4625 πριν το 4740. Ένας μπερδεμένος χρήστης παράγει 3-5 αποτυχίες σε 2-3 λεπτά από γνωστό εσωτερικό μηχάνημα. Επίθεση παράγει δεκάδες ή εκατοντάδες αποτυχίες σε δευτερόλεπτα, συχνά από άγνωστα IPs ή σε πολλαπλά accounts παράλληλα (password spray).

Το Entra ID Smart Lockout αντικαθιστά το on-prem lockout policy;

Όχι σε hybrid environments. Τρέχουν παράλληλα. Ρυθμίστε το on-prem AD threshold υψηλότερο από το Entra threshold, ώστε το Entra Smart Lockout να φιλτράρει επιθέσεις πρώτο και να μην φτάνουν στο on-prem AD.

Ποιο audit policy πρέπει να ενεργοποιήσω για να καταγράφεται το 4740;

Στο Default Domain Controllers Policy, ενεργοποιήστε Audit User Account Management σε Success και Failure, κάτω από Advanced Audit Policy Configuration → Account Management. Χωρίς αυτό το setting, το event δεν γράφεται πουθενά.