Windows Event ID 4771: Kerberos Pre-Authentication Failed
- Level
- Beginner
- Reading time
- 24 min
- Concept
- Windows Event ID 4771 (Kerberos pre-authentication failed)
- Last reviewed
- July 12, 2026
Table of contents
Windows Event ID 4771 means Kerberos pre-authentication failed on a domain controller. A domain account tried to authenticate, and the Key Distribution Center, the service that hands out Kerberos tickets, turned it down. The most common reason by far is a wrong password. The event records the account name, the client IP address, the service involved, and a Failure Code that explains why the request was denied. It appears only on domain controllers, and only when Failure auditing is enabled for Kerberos authentication. A single 4771 is usually harmless, a mistyped password or a service still using an old one. A burst of them against one account can mean a brute-force attack. This guide explains what the event means, how to decode its failure codes, and how to tell noise from a real threat.
Key takeaways
- Event 4771 is logged on domain controllers when Kerberos pre-authentication fails.
- The Failure Code is the key field: 0x18 means a wrong password, the most common cause.
- It only appears when Failure auditing is on for Audit Kerberos Authentication Service.
- A single event is usually benign; many 0x18 failures fast can indicate a brute-force attack.
- Read it with events 4768, 4776, and 4740 to find the cause and source of failures.
Quick explanation
In simple terms
Event 4771 is a note in the domain controller's Security log that says a domain account failed to sign in with Kerberos. Nearly always, it means the password was wrong.
Technical definition
Event 4771 is a Windows Security audit event, in the Audit Kerberos Authentication Service subcategory, that a domain controller logs when the KDC denies an AS-REQ because pre-authentication failed. It records the target account, service name (krbtgt), client address and port, ticket options, pre-authentication type, and a Kerberos failure code.
Analogy
Think of the KDC as a gatekeeper who checks a password before handing out a day pass. Event 4771 is the gatekeeper's note that says: someone asked for a pass under this name, gave the wrong password, and was turned away, and here is the reason.
Definition
Windows Event ID 4771 is a Security audit event that a domain controller logs when Kerberos pre-authentication fails. In plain terms, someone or something tried to sign in with a domain account and the domain controller rejected it, most often because the password was wrong.
Event ID 4771, Kerberos pre-authentication failed, is a Windows Security audit event. A domain controller writes it when the Key Distribution Center (KDC), the service that issues Kerberos tickets, rejects an initial ticket request because pre-authentication failed. Pre-authentication is the step where the client proves it knows the account password before the KDC issues a ticket.
This event fires only on domain controllers, under the Audit Kerberos Authentication Service subcategory of Account Logon. Because it records a failure, you only see it if Failure auditing is turned on for that subcategory. Each event names the account, the client IP address, the service (usually krbtgt), and a Failure Code that says why the request was denied.
The most common cause is a wrong password, shown by failure code 0x18. Other codes point to a disabled or locked account, an expired password, a clock that is too far out of sync, or a smart card problem. Per Microsoft, the event is not generated for accounts that have Kerberos pre-authentication disabled, which is itself a security concern known as AS-REP roasting exposure.
Event 4771 sits alongside related events: 4768 for a ticket request, 4772 for a failed ticket request, 4776 for NTLM credential checks, and 4740 for the lockout that repeated failures can trigger. Reading them together tells you what happened and where it came from.
Why it matters
Core concepts
What Kerberos pre-authentication is
Pre-authentication is the step where a client proves it knows the password before the KDC issues a ticket.
Kerberos is the default authentication protocol in Active Directory. Before the Key Distribution Center issues a Ticket Granting Ticket, it asks the client to prove it knows the account password. The client does this by sending an encrypted timestamp, encrypted with a key derived from the password.
The KDC decrypts that timestamp with the key it has stored for the account. If the two keys match, the password was right and pre-authentication succeeds. If they don't, or another account check fails, the KDC denies the request and logs Event 4771.
Example
A user types the wrong password, so the encrypted timestamp doesn't match, and 4771 is logged.
Why it matters — Pre-authentication is exactly the check that 4771 records failing, so understanding it explains the event.
It is logged only on domain controllers
Only domain controllers run the KDC, so only they generate Event 4771.
The KDC runs on domain controllers, so pre-authentication happens there and Event 4771 is written there. You won't find it on member servers or workstations. It lands in the Security log under the Audit Kerberos Authentication Service subcategory of Account Logon.
This is useful. Because all domain Kerberos authentication passes through domain controllers, watching 4771 across your DCs gives you one place to see failed domain logons, wherever the client sits.
Example
A workstation login with a bad password produces 4771 on the DC that handled the request, not on the workstation.
Why it matters — Knowing where to look saves time, and it explains why you collect this event from domain controllers.
The Failure Code tells you why
The Failure Code field is a Kerberos error code that gives the exact reason the request was denied.
Every 4771 carries a Failure Code, a hexadecimal Kerberos error from RFC 4120. It's the field that turns a generic failure into a diagnosis. The common ones are 0x18 for a wrong password, 0x12 for a revoked account, such as disabled or locked, 0x17 for an expired password, and 0x10 for a smart card or certificate problem.
Read the code first. It points you straight at the cause, so you don't waste time guessing whether you're chasing a typo, a stale service account, or something worth a closer look.
Example
A 4771 with Failure Code 0x18 means the password was wrong; 0x12 means the account is disabled or locked.
Why it matters — The Failure Code is the single most useful field for triaging the event quickly.
Account Name and Client Address identify who and where
These fields name the account that failed and the IP address the request came from.
Two fields answer who and where. Account Name is the domain account that failed to authenticate. Client Address is the IP address the request came from. Together they tell you which account is failing and which machine is driving it.
Watch for context. A client address of ::1 means the request was local to the domain controller. A public or unexpected IP is worth attention. And the address may be a gateway or VPN device rather than the end user's own machine.
Example
Repeated 4771 for one account from a single internal IP often points to a service or scheduled task using an old password.
Why it matters — These fields let you trace a failure back to its source, which is the first step in fixing lockouts.
You must enable Failure auditing to see it
Event 4771 appears only when Failure auditing is on for Audit Kerberos Authentication Service.
Because 4771 records a failure, it only appears when Failure auditing is enabled for the Audit Kerberos Authentication Service subcategory. On server editions, Success auditing is on by default, but Failure is not always on, so you may need to turn it on to capture 4771.
Set it through Group Policy under Advanced Audit Policy Configuration, in Account Logon, or with auditpol. Without Failure auditing, the failures still happen but leave no 4771 to investigate.
Example
Enabling Failure auditing for Audit Kerberos Authentication Service starts recording 4771 events on the DC.
Why it matters — If auditing isn't configured, you have a blind spot exactly where you most need visibility.
How it works
The client sends an initial ticket request
A client sends an Authentication Service request (AS-REQ) to the KDC on a domain controller, asking for a Ticket Granting Ticket for the account.
AS-REQ
Example — A user signs in, and their machine sends an AS-REQ to the domain controller.
The KDC asks for pre-authentication
If the first request lacks pre-authentication data, the KDC replies that pre-authentication is required. This is normal, by-design behavior, not an error.
Preauth required
Example — The KDC returns KDC_ERR_PREAUTH_REQUIRED, prompting the client to include proof of the password.
The client sends an encrypted timestamp
The client resends the request with pre-authentication data: a timestamp encrypted with a key derived from the account password (pre-authentication type PA-ENC-TIMESTAMP).
Encrypted timestamp
Example — The client encrypts the current time with the password-derived key and sends it.
The KDC validates the timestamp
The KDC decrypts the timestamp using the key it holds for the account and checks the account's state, such as whether it is enabled, unlocked, and has a current password.
Validate
Example — The KDC compares its stored key against the one used to encrypt the timestamp.
The KDC denies the request and logs 4771
If the timestamp doesn't validate or an account check fails, the KDC denies the request and writes Event 4771 with a failure code, if Failure auditing is enabled.
Deny + log
Example — A wrong password fails validation, so the KDC logs 4771 with Failure Code 0x18.
The admin reads the event
An administrator or SIEM reads the Account Name, Client Address, and Failure Code to work out what happened and where it came from, then correlates with related events.
Investigate
Example — The analyst sees code 0x18 from one IP repeated many times and investigates a possible attack.
Use cases
Investigate repeated logon failures for an account
AD admins, help deskFind out why a specific domain account keeps failing to authenticate.
Filtering 4771 for one Account Name shows the failures come from a single server with code 0x18.
Benefit — Points to the exact cause and source instead of guesswork.
Track down the source of account lockouts
AD admins, MSPsIdentify the IP address driving the bad-password attempts behind a lockout.
A 4740 lockout plus 4771 events reveals a phone or scheduled task still using an old password.
Benefit — Turns a mysterious lockout into a specific machine to fix.
Detect password guessing and spraying
SOC analystsSpot brute-force or password-spray activity against Active Directory accounts.
Many 0x18 failures across accounts from one external IP suggests a password-spray attempt.
Benefit — Provides an early warning of credential attacks.
Catch stale or disabled credentials in use
AD adminsFind services or devices still authenticating with revoked or expired credentials.
A 4771 with code 0x12 for a disabled service account shows something still tries to use it.
Benefit — Surfaces configuration debt before it causes outages.
Troubleshoot smart card logon problems
AD adminsDiagnose certificate and smart card issues at the domain controller.
A 4771 with code 0x10 and a smart card pre-auth type points to a certificate problem.
Benefit — Narrows smart card failures to a certificate or KDC configuration cause.
Benefits
Pinpoints the cause with a failure code
The failure code names the exact reason, from a wrong password to a disabled account.
Code 0x18 versus 0x12 immediately separates a typo from a revoked account.
Identifies the source IP
The client address shows where the failed request came from, key to fixing lockouts.
The client address leads you to the server running an old service credential.
Central visibility at the domain controller
Because domain Kerberos auth passes through DCs, one place shows failures across the domain.
Collecting 4771 from all DCs surfaces failures no matter which client caused them.
Feeds attack detection
Patterns in 4771, like many 0x18 failures fast, drive SIEM detections for credential attacks.
A rule alerts when one account gets dozens of 0x18 failures in a minute.
Speeds up lockout root-cause analysis
Paired with the lockout event, it turns a vague lockout into a specific machine and cause.
A 4740 plus 4771 trail resolves a recurring lockout in minutes.
Limitations
Only on domain controllers, only with Failure auditing
MediumThe event appears only on domain controllers, and only when Failure auditing is enabled for the Kerberos authentication subcategory.
Workaround — Enable Failure auditing via Advanced Audit Policy and collect logs from all domain controllers.
High volume and noise
MediumOn busy domain controllers, 4771 can be high volume. Benign typos and stale credentials mix with real threats, so raw counts mislead.
Workaround — Filter by failure code and account, and alert on rate and pattern, not single events.
Does not cover NTLM
MediumNTLM authentication failures don't appear here. They show in event 4776 instead.
Workaround — Correlate 4771 with 4776 to cover both Kerberos and NTLM failures.
Client address can mislead
LowThe client address may be a NAT gateway, VPN concentrator, or proxy rather than the real device, and ::1 means local to the DC.
Workaround — Trace the address through network devices, and treat it as a lead, not a final answer.
Blind to pre-authentication-disabled accounts
MediumAccounts set to not require Kerberos pre-authentication generate no 4771, which also exposes them to AS-REP roasting.
Workaround — Audit for accounts with pre-authentication disabled and enable it wherever possible.
Architecture
Event 4771 comes out of the Kerberos Authentication Service exchange between a client and a domain controller. The pieces are the client requesting a ticket, the KDC that checks the password, the Active Directory database that stores account keys and state, and the Security event log that records the result. A SIEM often collects the event for alerting.
Client
Sends the initial ticket request and the encrypted timestamp that proves the password.
A workstation or a service account requesting a ticket at logon.
KDC Authentication Service
Validates pre-authentication and decides whether to issue a ticket; logs 4771 on failure.
The KDC on a domain controller decrypting and checking the timestamp.
Active Directory database
Stores the account's key and state (enabled, locked, password expiry) used in the check.
The directory returns the account key the KDC uses to decrypt the timestamp.
Security event log
Records Event 4771 with the account, client address, and failure code when auditing is on.
The DC's Security log entry an admin opens in Event Viewer.
SIEM or Defender for Identity
Collects 4771 across domain controllers to correlate and alert on suspicious patterns.
A SIEM rule fires when many 0x18 failures hit one account quickly.
Data flow
The client sends an AS-REQ to the KDC on a domain controller. The KDC reads the account's key and state from Active Directory and validates the encrypted timestamp. If the check fails, the KDC denies the request and, when Failure auditing is enabled, writes Event 4771 to the Security log with the account name, client address, service name, and failure code. A SIEM can then collect and correlate the event.
Integrations: Event Viewer and Windows Event Forwarding, SIEM platforms such as Microsoft Sentinel, Microsoft Defender for Identity, Account lockout troubleshooting tools, Related events 4768, 4772, 4776, and 4740
Architecture limitations
Examples
A stuck password causing lockouts
A user is locked out several times a day for no obvious reason.
You filter 4771 for that account and find a steady stream of code 0x18 failures, all from one internal IP. That server runs a scheduled task with the user's old password. Updating the saved credential stops the lockouts. The failure code and client address did the work.
A possible password spray
Your SIEM flags a spike in Kerberos failures overnight.
Reviewing 4771, you see code 0x18 failures spread across many accounts, one attempt each, from a single external IP. That pattern, many accounts and few tries each, is classic password spraying. You block the source and force resets on any account that later succeeded.
A disabled service account still in use
You disabled an old service account but want to be sure nothing still needs it.
A 4771 with code 0x12, meaning the account is revoked, appears for that account from an application server. Something there still tries to authenticate with it. You find and update the app before fully removing the account, avoiding a broken service.
Comparisons
Event 4771 vs Event 4768 vs Event 4768 (A Kerberos authentication ticket (TGT) was requested)
Both belong to the Audit Kerberos Authentication Service subcategory. Event 4768 records a ticket request, success or failure. Event 4771 records specifically that pre-authentication failed. They often relate to the same activity from different angles.
| Criterion | Event 4771 vs Event 4768 | Event 4768 (A Kerberos authentication ticket (TGT) was requested) |
|---|---|---|
| What it records | A failed pre-authentication | A ticket (TGT) request, success or failure |
| Result | Always a failure | Can be success or failure |
| Best use | Diagnosing why auth failed | Tracking ticket requests and successful logons |
When to choose — Use 4771 to see why authentication failed; use 4768 to track ticket requests overall.
Event 4771 vs Event 4776 vs Event 4776 (The computer attempted to validate the credentials for an account)
Event 4771 is a Kerberos failure; event 4776 is an NTLM credential validation, logged when NTLM is used. If Kerberos isn't in play, failures surface as 4776 instead, so you often need both.
| Criterion | Event 4771 vs Event 4776 | Event 4776 (The computer attempted to validate the credentials for an account) |
|---|---|---|
| Protocol | Kerberos | NTLM |
| Where logged | Domain controllers (KDC) | The authenticating DC or server |
When to choose — Monitor both: 4771 for Kerberos failures and 4776 for NTLM failures.
Event 4771 vs Event 4740 vs Event 4740 (A user account was locked out)
Event 4771 is a single failed authentication; event 4740 is the lockout that repeated failures trigger. The 4740 tells you a lockout happened; the 4771 events tell you the source and reason.
| Criterion | Event 4771 vs Event 4740 | Event 4740 (A user account was locked out) |
|---|---|---|
| What it marks | One failed authentication | The account being locked out |
| Investigation role | Shows source IP and failure code | Confirms the lockout occurred |
When to choose — Start from the 4740 lockout, then use the 4771 events to find the source and cause.
Myths, corrected
Myth
Event 4771 always means an attack.
Correction
Most 4771 events are benign. A mistyped password, a phone with a saved old password, a service using a stale credential, or an expired password all generate it. Judge by the failure code, the account, and the rate, not by the event alone.
Why it happens: The word failed sounds alarming, so people assume the worst.
Myth
Event 4771 covers all failed logons.
Correction
It covers only Kerberos pre-authentication failures on domain controllers. NTLM failures are event 4776, and interactive or network logon failures on member servers are event 4625. You need several events for full coverage.
Why it happens: It's the most visible failure event, so it gets treated as the only one.
Myth
The Client Address is always the user's own PC.
Correction
The client address can be a NAT gateway, VPN concentrator, or reverse proxy, not the end device. A value of ::1 means the request was local to the domain controller. Treat the address as a lead to follow.
Why it happens: The field is labeled client address, so people read it as the literal endpoint.
Myth
No 4771 events means there are no failures.
Correction
You only see 4771 if Failure auditing is enabled for Kerberos authentication. And accounts set to not require pre-authentication generate none at all, which also exposes them to AS-REP roasting. Absence can mean a blind spot, not safety.
Why it happens: People assume auditing is on and complete by default.
Practical implications
For admins
Make 4771 part of lockout and logon-failure troubleshooting. Read the failure code first, then the account and client address. Enable Failure auditing for Kerberos authentication so the events are there when you need them.
For MSPs
Across client domains, standardize auditing and log collection so 4771 is available everywhere. It turns recurring lockout tickets into quick, repeatable investigations.
For business
Faster lockout resolution means less downtime and fewer help desk hours. Better detection of credential attacks reduces the risk and cost of a breach.
For security
Treat bursts of code 0x18 failures as a possible brute-force or spray signal, especially for high-value accounts or from external IPs. Alert on rate and pattern, and audit for accounts with pre-authentication disabled.
For end users
End users never see 4771 directly. For them it shows up as a failed sign-in or a locked account, which this event helps admins explain and fix.
Cost impact
The event itself is free with Windows auditing. The cost is log storage and the tuning needed to cut noise, usually well worth it for the visibility.
Operational impact
On busy domain controllers, 4771 can be high volume, so plan log capacity and filtering. Good handling shortens incident response and lockout troubleshooting.
Decision guide
Use when
- A domain account keeps failing to authenticate and you need the cause
- You're finding the source IP behind an account lockout
- You're hunting password guessing or spraying against Active Directory
- You're troubleshooting expired passwords or smart card logon on domain controllers
Avoid when
- You're chasing NTLM failures (use event 4776)
- You're diagnosing service ticket problems (use event 4769)
- You want successful-logon tracking (use events 4768 and 4624)
- The failure is a local logon on a member server (use event 4625)
Requirements
- Domain controllers running the KDC
- Failure auditing enabled for Audit Kerberos Authentication Service
- Log collection or a SIEM to correlate across DCs
- Familiarity with Kerberos failure codes
Alternatives
- Event 4776 for NTLM credential failures
- Event 4740 to confirm account lockouts
- Event 4625 for logon failures on member servers
- Microsoft Defender for Identity for built-in credential-attack detection
Related terms
Kerberos
The default authentication protocol in Active Directory, based on tickets issued by a KDC.
Key Distribution Center (KDC)
The service on a domain controller that authenticates accounts and issues Kerberos tickets.
Pre-authentication
The step where a client proves it knows the account password before the KDC issues a ticket.
Ticket Granting Ticket (TGT)
The initial Kerberos ticket a client uses to request service tickets, issued after successful authentication.
Event 4768
The audit event for a Kerberos ticket (TGT) request, success or failure.
Event 4740
The audit event logged when a user account is locked out after repeated failures.
Frequently asked questions
What does Windows Event ID 4771 mean?
It means Kerberos pre-authentication failed on a domain controller. An account tried to authenticate and the Key Distribution Center denied it, most often because the password was wrong. The event includes a failure code explaining exactly why.
What is the most common cause of Event 4771?
A wrong password, shown by failure code 0x18 (KDC_ERR_PREAUTH_FAILED). This covers typos, a device or service using an old saved password, and password guessing. The failure code tells you which.
Where is Event 4771 logged?
Only on domain controllers, in the Security log, under the Audit Kerberos Authentication Service subcategory of Account Logon. The KDC runs on domain controllers, so the event is written there, not on clients or member servers.
How do I enable Event 4771?
Turn on Failure auditing for Audit Kerberos Authentication Service. Set it through Group Policy under Advanced Audit Policy Configuration, in Account Logon, or with auditpol, then apply it to your domain controllers.
What does failure code 0x18 mean in Event 4771?
Failure code 0x18 is KDC_ERR_PREAUTH_FAILED, which means the pre-authentication information was invalid, in other words the wrong password was provided. It's the most common code in 4771.
What's the difference between Event 4771 and Event 4768?
Event 4768 records a Kerberos ticket (TGT) request, which can succeed or fail. Event 4771 records specifically that pre-authentication failed. Use 4771 to see why authentication failed and 4768 to track ticket requests overall.
Is Event 4771 a sign of an attack?
It can be, but most are benign. Watch the pattern: many 0x18 failures for one account in a short window can mean brute forcing, and single tries across many accounts from one IP can mean password spraying, especially from external addresses.
Why do I see Event 4771 for a disabled account?
A 4771 with failure code 0x12 (KDC_ERR_CLIENT_REVOKED) appears when a disabled, locked, or expired account is used. It usually means a service, device, or scheduled task is still trying to authenticate with that account.
Conclusion
Windows Event ID 4771 is logged on domain controllers when the KDC rejects an account's initial Kerberos request because pre-authentication failed. The Failure Code is the field that matters most: 0x18 for a wrong password, 0x12 for a revoked account, 0x17 for an expired password, and 0x10 for a smart card problem. The Account Name and Client Address tell you who failed and where from.
Treat a single event as routine and a pattern as a signal. Enable Failure auditing so the events exist, collect them from every domain controller, and read them with events 4768, 4776, and 4740 to see the full picture. Done well, 4771 turns confusing lockouts and quiet credential attacks into clear, traceable problems.
Main takeaway
If you're acting on 4771, the natural next steps are a tutorial on tracing account lockouts with events 4740 and 4771, and an explainer on hardening Active Directory against password spraying and AS-REP roasting.
