How to troubleshoot the Kerberos error 4771 and locked user accounts

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.

 

 

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.

 

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.

 

Now we will choose an event with the same time as first Kerberos event. We will see details for this event:

 

 

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.