Readers help support Windows Report. We may get a commission if you buy through our links.
Read our disclosure page to find out how can you help Windows Report sustain the editorial team. Read more
The Kerberos pre-authentication failed error indicates that the user cannot log in to Windows or any other network resource. This error occurs when there’s a problem with the Kerberos pre-authentication process.
It can occur if you use an incorrect username or password if your computer is offline or not connected to the network, or if an error occurs when connecting to a domain controller.
Why am I getting the Event ID 4771 error?
This error means that you tried to connect to a server using Kerberos pre-authentication, but the server did not respond to your request. In Windows, Kerberos pre-authentication verifies a user’s credentials before the KDC authenticates them.
If the pre-authentication fails, the user will be prompted for their password. For some users, the error code was Event ID 4771. Kerberos pre-authentication failed 0x18 on their PCs. For this code, the issue is a bad password. However, for Event ID 4771, this can happen for several reasons:
- Server clock mismatch – The likely cause is that your computer’s clock is out of sync with the server’s clock. This can happen if your computer was offline for a long time and returned online but failed to synchronize its clock.
- Incorrect password – Most users who encountered the Event ID 4771 error admitted to having recently changed their passwords. However, for unique IDs such as Event ID 4771 status 0x12, it means that the user’s credentials have been revoked.
- Cached credentials – Cached credentials are used to reduce login times and to improve security because they’re obtained automatically from the directory server. However, when you changed passwords, they may cause conflicts.
- Wrong domain – Make sure that you’re logging on to an account from the same domain as the computer you’re connecting from; otherwise, there will be no way for Active Directory to verify your credentials correctly.
How can I solve the Event ID 4771 error?
1. Enable failed logon auditing
- Hit the Windows + R keys to open the Run command.
- Type secpol.msc in the dialog box and hit Enter.
- Navigate to the following location:
Security settings/Local Policy/Audit Policies/Audit Logon Events
- Double-click on Audit logon events, select Success/Failure, then click on Apply and OK.
This will generate a security event whenever a user attempts to log into a domain-joined computer and fails. Failed logon auditing will allow you to see when users have attempted to log onto the network unsuccessfully and to identify any duplicates.
Then, you can rename the accounts with duplicate names on one or more servers, or create new accounts for them with unique names.
2. Delete cached passwords
- Hit the Windows key, type cmd in the search bar and click Open.
- Type the following commands and hit Enter after each one:
psexec -i -s -d cmd.exerundll32 keymgr.dll KRShowKeyMgr - A list of stored usernames and passwords will appear. Delete them from your server and restart your PC.
This happens because the Kerberos subsystem caches the old password in memory. When you change the password, it doesn’t get cleared from memory until it expires.
The Kerberos client then tries to use the old cached password, which doesn’t work because it has been changed on the domain controller.
- Microsoft’s hotpatching for Windows Server 2025 to be subscription-based starting July
- Microsoft releases the Windows Server Build 26360, introducing the WDAC for enhanced security
- How to Fix ERROR_SCRUB_DATA_DISABLED on Windows Server
- Windows Server 2025 and System Center 2025 have entered general availability
3. Enable audit logon
- Hit the Windows key, type Powershell in the search bar and click Run as administrator.
- Type the following command and hit Enter:
auditpol /set /subcategory:”logon” /failure:enable
When you enable logon auditing, it helps you determine if someone is trying to gain unauthorized access to your systems by guessing passwords or attempting other brute-force attacks.
Hopefully, you have bypassed the Event ID 4771 Kerberos pre-authentication failed error with one of these methods.
You may also come across an Event ID 4768, where your Kerberos authentication ticket is requested. If so, don’t hesitate to check out our expert article.
In the comment section below, let us know what solution fixed this error for you.
Claire Moraa
Windows Software Expert
Claire has a knack for solving problems and improving the quality of life for those around her. She’s driven by rationality, curiosity, and simplicity, and always eager to learn more about Microsoft’s products.
With a background in teaching and reviewing, she breaks down complex topics into easily understandable articles, focusing mostly on Windows 11, errors, and software.
Last Updated on February 28, 2025 by Satyendra
What is Kerberos?
Kerberos is a network authentication protocol used in Windows domains. It is used to verify the identity of users and computers across an untrusted network such as the internet. Kerberos support is built into all major computer operating systems, including Microsoft Windows.
Pre-authentication is an initial step in the Kerberos process where the client proves its identity to the Key Distribution Center (KDC).
Since Windows 2000, the Kerberos protocol has been used by Microsoft as the default authentication method, and it is a fundamental part of the Windows Active Directory (AD) service.
What is Event ID 4771?
Event ID 4771, “Kerberos pre-authentication failed,” is a common security event in Windows environments.
This event generates every time the Key Distribution Center (KDC) fails to issue a Kerberos Ticket Granting Ticket (TGT) and indicates that the Key Distribution Center (KDC) could not validate the client’s initial identity claim. The event is logged on domain controllers.
Note that this event is not generated if the “Do not require Kerberos preauthentication” option is set for the account.
The following are some of the common causes for event ID 4771 to be generated:
| Causes | Description |
|---|---|
| Incorrect Password | This is the most frequent cause |
| Expired Password | The user’s password has expired |
| Locked-Out Account | The user’s account has been locked due to too many failed login attempts |
| Disabled Account | The user’s account has been disabled in Active Directory. |
How Lepide Auditor Helps
It is essential that an administrator has visibility over what is happening in their Active Directory. This ensures that any suspicious activity relating to potential security threats is identified and can be responded to immediately.
The Lepide Active Directory Auditing Tool enables effective monitoring, auditing, and reporting on all Active Directory states and changes including account logon events. The Lepide Auditor includes pre-configured account logon reports to help identify malicious users attempting to logon to machines that require elevated privileges.
- Active Directory
| Operating Systems |
Windows 2008 R2 and 7
Windows 2012 R2 and 8.1 Windows 2016 and 10 Windows Server 2019 and 2022 |
|
Category • Subcategory |
Account Logon • Kerberos Authentication Service |
| Type | Failure |
|
Corresponding events in Windows 2003 and before |
675
|
4771: Kerberos pre-authentication failed
On this page
- Description of this event
- Field level details
- Examples
This event is logged on domain controllers only and only failure instances of this event are logged.
At the beginning of the day when a user sits down at his or her workstation and enters his domain username and password, the workstation contacts a local DC and requests a TGT. If the username and password are correct and the user account passes status and restriction checks, the DC grants the TGT and logs event ID 4768 (authentication ticket granted).
If the ticket request fails Windows will either log this event, failure 4771, or 4768 if the problem arose during «pre-authentication». In Windows Kerberos, password verification takes place during pre-authentication.
The User field for this event (and all other events in the Audit account logon event category) doesn’t help you determine who the user was; the field always reads N/A. Rather look at the Account Information: fields, which identify the user who logged on and the user account’s DNS suffix. The User ID field provides the SID of the account.
Windows logs other instances of event ID 4768 when a computer in the domain needs to authenticate to the DC typically when a workstation boots up or a server restarts. In these instances, you’ll find a computer name in the User Name and fields. Computer generated kerberos events are always identifiable by the $ after the computer account’s name.
Result codes:
| Result code | Kerberos RFC description | Notes on common failure codes |
| 0x1 | Client’s entry in database has expired | |
| 0x2 | Server’s entry in database has expired | |
| 0x3 | Requested protocol version # not supported | |
| 0x4 | Client’s key encrypted in old master key | |
| 0x5 | Server’s key encrypted in old master key | |
| 0x6 | Client not found in Kerberos database | Bad user name, or new computer/user account has not replicated to DC yet |
| 0x7 | Server not found in Kerberos database | New computer account has not replicated yet or computer is pre-w2k |
| 0x8 | Multiple principal entries in database | |
| 0x9 | The client or server has a null key | administrator should reset the password on the account |
| 0xA | Ticket not eligible for postdating | |
| 0xB | Requested start time is later than end time | |
| 0xC | KDC policy rejects request | Workstation restriction |
| 0xD | KDC cannot accommodate requested option | |
| 0xE | KDC has no support for encryption type | |
| 0xF | KDC has no support for checksum type | |
| 0x10 | KDC has no support for padata type | |
| 0x11 | KDC has no support for transited type | |
| 0x12 | Clients credentials have been revoked | Account disabled, expired, locked out, logon hours. |
| 0x13 | Credentials for server have been revoked | |
| 0x14 | TGT has been revoked | |
| 0x15 | Client not yet valid — try again later | |
| 0x16 | Server not yet valid — try again later | |
| 0x17 | Password has expired | The user’s password has expired. |
| 0x18 | Pre-authentication information was invalid | Usually means bad password |
| 0x19 | Additional pre-authentication required* | |
| 0x1F | Integrity check on decrypted field failed | |
| 0x20 | Ticket expired | Frequently logged by computer accounts |
| 0x21 | Ticket not yet valid | |
| 0x21 | Ticket not yet valid | |
| 0x22 | Request is a replay | |
| 0x23 | The ticket isn’t for us | |
| 0x24 | Ticket and authenticator don’t match | |
| 0x25 | Clock skew too great | Workstation’s clock too far out of sync with the DC’s |
| 0x26 | Incorrect net address | IP address change? |
| 0x27 | Protocol version mismatch | |
| 0x28 | Invalid msg type | |
| 0x29 | Message stream modified | |
| 0x2A | Message out of order | |
| 0x2C | Specified version of key is not available | |
| 0x2D | Service key not available | |
| 0x2E | Mutual authentication failed | may be a memory allocation failure |
| 0x2F | Incorrect message direction | |
| 0x30 | Alternative authentication method required* | |
| 0x31 | Incorrect sequence number in message | |
| 0x32 | Inappropriate type of checksum in message | |
| 0x3C | Generic error (description in e-text) | |
| 0x3D | Field is too long for this implementation |
Free Security Log Resources by Randy
- Free Security Log Quick Reference Chart
- Windows Event Collection: Supercharger Free Edtion
- Free Active Directory Change Auditing Solution
- Free Course: Security Log Secrets
Description Fields in
4771
Account Information:
- Account Name: logon name of the account that just authenticated
- Supplied Realm Name: domain name of the account
- User ID: SID of the account
Service Information:
- Service Name: always «krbtgt»
- Service ID:
Network Information:
- Client Address: IP address where user is present
- Client Port: source port
Additional Information:
- Ticket Options: unknown. Please start a discussion if you have information to share on this field.
- Failure Code: error if any — see table above
- Pre-Authentication Type: unknown. Please start a discussion if you have information to share on this field.
Certificate Information:
This information is only filled in if logging on with a smart card.
- Certificate Issuer Name:
- Certificate Serial Number:
- Certificate Thumbprint:
Supercharger Free Edition
Your browser does not support video
Examples of 4771
Kerberos pre-authentication failed.
Account Information:
Security ID: ACME\administrator
Account Name: Administrator
Service Information:
Service Name: krbtgt/acme
Network Information:
Client Address: ::ffff:10.42.42.224
Client Port: 50950
Additional Information:
Ticket Options: 0x40810010
Failure Code: 0x18
Pre-Authentication Type: 2
Certificate Information:
Certificate Issuer Name:
Certificate Serial Number:
Certificate Thumbprint:
Certificate information is only provided if a certificate was used for pre-authentication.
Pre-authentication types, ticket options and failure codes are defined in RFC 4120.
If the ticket was malformed or damaged during transit and could not be decrypted, then many fields in this event might not be present.
Top 10 Windows Security Events to Monitor
Free Tool for Windows Event Collection
- Insider Gone Bad: Tracking Their Steps and Building Your Case with the Security Log
- Building a Security Dashboard for Your Senior Executives
- 27 Most Important Windows Security Events
- 5 Ways to Reduce Information Overload from Your Log Management/SIEM
- Daily Security Log Check for the SMB IT Admin
- Integrating Splunk with native Windows Event Collection (WEC) and Optional 2-Stage Noise Filtering
- How to do Logon Session Auditing with the Windows Security Log
- Top Windows Security Log Events for User Behavior Analysis
- 4 Threat Detections using Active Directory Authentication Events from the Windows Security Log
- Understanding Active Directory Authentication Events in the Windows Security Log and Beyond
- Security Log Deep Dive: Mapping Active Directory Authentication and Account Management Events to MITRE ATT&CK TTPs
- Detecting and Preventing AD Authentication Risks: Golden Tickets, NTLM, Pass-the-Hash and Beyond
- Windows Security Log Deep Dive: Understanding Kerberos Authentication Events from Domain Controllers
- Assessing the Security of Your Active Directory: User Accounts
- The Changing Landscape of Authentication and Logon Tracking in Hybrid Environments of Entra and AD
4771 — Kerberos Failure
https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4771
Event ID 4771 is a critical event in Windows security auditing, indicating a Kerberos pre-authentication failure. This event is logged on the domain controller that receives the pre-authentication request and plays a vital role in monitoring and diagnosing issues related to Kerberos authentication processes. Understanding the details and substatus codes of Event ID 4771 is crucial for identifying authentication issues, potential attack vectors, and maintaining secure access controls.
Key Details of Event ID 4771
-
Log Location: Security log on domain controllers.
-
Category: Audit Kerberos Authentication Service
Event ID 4771 is logged when a Kerberos pre-authentication request fails. This can occur in various scenarios, such as:
-
Incorrect user password entries.
-
Attacks attempting to guess passwords.
-
Configuration or communication issues between the client and the domain controller.
Information Contained in the Log
An Event ID 4771 log contains several pieces of information crucial for diagnosing authentication issues:
-
Client Address: Shows the IP address of the client from which the logon attempt was made.
-
Client Port: Indicates the port number used by the client machine for the connection.
-
Pre-authentication Type: Specifies the type of pre-authentication used, often indicating the use of passwords (type 2).
-
Failure Code: A key element that specifies why the pre-authentication failed.
-
User Name: The name of the user for whom the logon attempt was made.
-
Service Name: The name of the service that was requested, typically the Kerberos Ticket Granting Service (TGS).
-
Ticket Options: Specifies various flags related to the ticket that was requested.
Common Failure Codes and Their Meanings
Understanding the failure codes provided in Event ID 4771 logs is essential for diagnosing and addressing authentication issues:
-
0x18: Pre-authentication information was invalid. This often indicates an incorrect password was entered.
-
0x12: Account restrictions are preventing this user from signing in. For example: not allowed to log in from this computer, logon hours restrictions, or account disabled.
-
0x25: The user has to reset their password.
-
0x1F: An unspecified error has occurred.
Event ID 4771 is instrumental in security monitoring for several reasons:
-
Detecting Brute-Force Attacks: Multiple 4771 events with failure code 0x18 from the same client address may indicate a brute-force password guessing attack.
-
Identifying Configuration Issues: Failures related to account restrictions (code 0x12) can highlight misconfigurations that may inadvertently prevent legitimate access.
-
Password Attack Detection: An unusually high volume of 4771 events across various accounts might signal a more extensive password spray attack.
Tools and Strategies for Analysis
-
Windows Event Viewer: Manually inspect the Security log on domain controllers for 4771 events.
-
PowerShell: Automate the extraction and analysis of 4771 events from domain controllers’ logs.
-
SIEM Systems: Aggregate and correlate 4771 events with other security logs to detect patterns indicative of attacks or systemic issues.
When user try to login on the workstation, he or she needs to provide correct username and password. Workstation will contact a domain controller (DC) and try to obtain a Kerberos ticket for the user. In case that an username and a password are correct, DC will return a Kerberos ticket on ticket or TGT to that workstation. After that, user have TGT associated with his username across whole Active Directory (AD) site.
However, more interesting problem arise when an user didn’t provide correct username or a password. After few wrong passwords, often 3, the account will be locked. And then we need to either wait some time for system to unlock that account automatically or we must manually unlock an user account.
Such error is recorded in DC Security log as the Kerberos error 4771 on the Kerberos Authentication Service.
If such error appears randomly and for different users, then we can spoke about wrong typing. In my experience, most of such problems arise when an user have more then one e-mail client and an e-mail server using AD infrastructure for the user authentication. In such scenario we need to investigate a root of the problem.
Investigating System log on the primary DC server
We have a report about locked account for some user User01 in our AD domain Company or company.com. Now, we should log on to the primary DC server and to open the Security log.
We can access all system logs either through the Server manager > Diagnostics > Event Viewer or from All Programs > Administrative tools > Event Viewer. Inside the Event Viewer application we should navigate to the Windows logs and eventually to the Security log.
The Security log can have a lot of the lines and the events. There fore, we will choose option to filter it. On right side of the Event viewer window we can find a panel with action buttons.
We will choose option Filter Current Log… and a new dialog window will appear on the screen. We will choose event 4771 and keyword Audit Failure.
Now we will have filtered list of the events. We can also use a time interval to narrow down this list further. We can’t use field User as this event doesn’t contain that value. We’ll see that later.
![clip_image002[5]](https://mivilisnet.wordpress.com/wp-content/uploads/2016/03/clip_image0025_thumb.jpg?w=659&h=292 "clip_image002[5]")
We will now review this list searching for the event related to our user user01. To find more details about any event in the list, we should select it. Details about this event will appear In the window below list.
![clip_image002[7]](https://mivilisnet.wordpress.com/wp-content/uploads/2016/03/clip_image0027_thumb.jpg?w=646&h=394 "clip_image002[7]")
In the event details we will find text similar to this one:
Kerberos pre-authentication failed.
Account Information:
Security ID: COMPANY\user01
Account Name: user01
Service Information:
Service Name: krbtgt/company.com
Network Information:
Client Address: ::ffff:192.168.88.11
Client Port: 65305
Additional Information:
Ticket Options: 0x40810010
Failure Code: 0x18
Pre-Authentication Type: 2
Certificate Information:
Certificate Issuer Name:
Certificate Serial Number:
Certificate Thumbprint:
Certificate information is only provided if a certificate was used for pre-authentication.
Pre-authentication types, ticket options and failure codes are defined in RFC 4120.
If the ticket was malformed or damaged during transit and could not be decrypted, then many fields in this event might not be present.
As we can see, there is no username information, there fore a field User can’t be used. However, an user related information is stored in section Account information. With this information we can identify the user who generated this event.
Second important field is an IP address of the client workstation involved in this event. That information can be seen in Network Information > Client Address.
Now, if we have an IP address of some workstation or some server other then DC, we should check all relevant services on it. Some application on that network computer probably relays on Kerberos and AD for an user authentication.
User himself can raise this event if continuously typing wrong password. This can also indicate an attack on the account. But for attack on the account with brute force method we must have tens or hundreds of the events related to the same username and same workstation.
However, many times we will see here an IP address of some other DC server in the network. Then we need to log on to that DC and check it’s Security log.
Checking log on other DC server
We will perform same process on this DC, like we done on the first DC. We need to locate an event happens on same time as one we noticed before.
Now we will check part Additional Information and value Failure Code. If value of this field is 0x18, that usually means Bad password. We can see that same information is also in event description on the first DC.
Kerberos pre-authentication failed.
Account Information:
Security ID: COMPANY\user01
Account Name: user01
Service Information:
Service Name: krbtgt/company.com
Network Information:
Client Address: ::ffff:192.168.88.19
Client Port: 38449
Additional Information:
Ticket Options: 0x40810010
Failure Code: 0x18
Pre-Authentication Type: 2
Certificate Information:
Certificate Issuer Name:
Certificate Serial Number:
Certificate Thumbprint:
Certificate information is only provided if a certificate was used for pre-authentication.
Pre-authentication types, ticket options and failure codes are defined in RFC 4120.
If the ticket was malformed or damaged during transit and could not be decrypted, then many fields in this event might not be present.
Now we can see an IP address of the server who send request. This information is again in the field Network Information > Client Address. In our example, this address is an IP address of the e-mail server.
In my experience, this happens mostly when an user have an e-mail clients on the computer and the mobile phone in same time. Often user forgot to update a password on the phone or some other computer. E-mail client software is active in the background, trying continuously to connect with an old password and eventually lock the account.
Investigating an e-mail server Security log
We’re now logged on the company’s e-mail server and again we’ll navigate to the Security log.
Again, we should filter log events. However, this is not AD server and we don’t have Kerberos events. Now we have Login failure event. This event have id of 4625 and category Logon. The keyword is again Audit Failure.
![clip_image002[9]](https://mivilisnet.wordpress.com/wp-content/uploads/2016/03/clip_image0029_thumb.jpg?w=646&h=256 "clip_image002[9]")
Now we will choose an event with the same time as first Kerberos event. We will see details for this event:
![clip_image002[11]](https://mivilisnet.wordpress.com/wp-content/uploads/2016/03/clip_image00211_thumb.jpg?w=640&h=437 "clip_image002[11]")
Here is an example of full text for this event:
An account failed to log on.
Subject:
Security ID: SYSTEM
Account Name: MAIL$
Account Domain: COMPANY
Logon ID: 0x3e7
Logon Type: 8
Account For Which Logon Failed:
Security ID: NULL SID
Account Name: user01
Account Domain: company.com
Failure Information:
Failure Reason: Unknown user name or bad password.
Status: 0xc000006d
Sub Status: 0xc000006a
Process Information:
Caller Process ID: 0x63b8
Caller Process Name: C:\Windows\System32\inetsrv\w3wp.exe
Network Information:
Workstation Name: MAIL
Source Network Address: 192.168.25.78
Source Port: 59539
Detailed Authentication Information:
Logon Process: Advapi
Authentication Package: Negotiate
Transited Services: -
Package Name (NTLM only): -
Key Length: 0
This event is generated when a logon request fails. It is generated on the computer where access was attempted.
The Subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.
The Logon Type field indicates the kind of logon that was requested. The most common types are 2 (interactive) and 3 (network).
The Process Information fields indicate which account and process on the system requested the logon.
The Network Information fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.
The authentication information fields provide detailed information about this specific logon request.
- Transited services indicate which intermediate services have participated in this logon request.
- Package name indicates which sub-protocol was used among the NTLM protocols.
- Key length indicates the length of the generated session key. This will be 0 if no session key was requested.
Inside all those information we should check field Network Information > Source Network Address. There we can see source IP address from which request came.
In our example, the address that appears is from WLAN range. We concluding that an e-mail client on the mobile phone is root of the problem.