Kerberos pre-authentication failed after changing domain administrator password

Question

Repeated event generation of Kerberos pre-authentication failed with event ID 4771 and failure code 0x18 and the event is generating from multiple instances targeting event source to domain controller.

The issue occurred after change the domain administrator password and unable to dig insides to find the root cause of generation. As since we already update the scheduler service in all member servers.

" Kerberos pre-authentication failed. Account Information: Security ID: S-1-5-21-16834707280-224241925-162353504729-500 Account Name: Administrator Service Information: Service Name: krbtgt/veeamsw.com Network Information: Client Address: ::ffff:172.16.36.3 Client Port: 65280 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."

Answer 1

Hello Kamesh,

Thank you for posting question on Microsoft Windows Forum.

Based on the issue description and the provided Event ID as well as error message, I would like to share my insight on the following possible causes and the suggested troubleshooting steps for the issue.

• The Event ID 4771 occurs on a domain controller when the Key Distribution Center (KDC) fails to issue a Ticket-Granting Ticket (TGT). Failure code 0x18 means “Pre-authentication information was invalid,” which almost always points to an incorrect password in the AS-REQ (initial ticket request) phase.
• Even though you have updated scheduled tasks, the Administrator account credentials are likely stored or cached in another location on the server at 172.16.36.3. The password change has invalidated these stored credentials, causing the authentication attempts to fail repeatedly.
• The service name krbtgt/veeamsw.com might be a clue. This suggests the request might relate to a Veeam service or a task initiated by Veeam software trying to authenticate as the domain administrator.

You can try to check the following points to see which service or application is still trying to authenticate using the old domain administrator password.

1. Check Services:
   • Go to services.msc on the server 172.16.36.3.
   • Sort by the "Log On As" column and carefully check for any service using the Administrator account. Pay special attention to Veeam-related services (e.g., Veeam Backup Service, Veeam Data Mover).
   • If you find one, update the password in the service's Log On properties.
2. Check IIS Application Pools:
   • If the server is running IIS, open the Internet Information Services (IIS) Manager.
   • Go to "Application Pools."
   • Check the "Identity" column for any App Pool running as the Administrator account and update its credentials.
3. Check Third-Party Applications (Especially Veeam):
   • Open the Veeam Backup & Replication console.
   • Go to the "Credentials" section (often under the main menu or "Manage Credentials").
   • Find the entry for the Administrator account and update the password.
   • Check your backup jobs, replication jobs, and managed server configurations within Veeam to ensure they are using the updated credential record.
4. Clear Cached Credentials:
   • It's possible the old credentials are just cached. Log onto the server 172.16.36.3 interactively.
   • Open a command prompt and run the command klist purge. This will delete all Kerberos tickets for the current user session.
   • You can also check for saved credentials relating to old domain Admin in the Windows Credential Manager.
5. To see SYSTEM-level hidden credentials:
   • Using psexec.exe open a command prompt (cmd.exe) as the System account.
   • psexec -i -s cmd.exe
   • In the new DOS prompt open the credential manager.
   • rundll32 keymgr.dll,KRShowKeyMgr
   • Remove any found outdated Administrator entries and restart the server to stop the repeated AS-REQ failures.

You can refer to below article for more information regarding the Event ID 4771

• https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4771

Hope the above information is helpful!