1

I'm getting kerberos preauth failures - event 4771 - between my DCs. I think it's normal behavior (it's happened for years, since I enabled the additional logging), but I can't find any explanation as to why it is happening.

A couple notes:

  • happening from domain controller WENDEL to domain controller STEVE
  • never occurs STEVE to WENDEL.
  • STEVE does hold the FSMO roles.
  • DCs are still on 2012r2, including operational level

All of the events have the same ticket details.

Ticket Options:     0x40810010
Failure Code:       0x18
Pre-Authentication Type:    2

I've done the usual dcdiag as a sanity check and nothing looked out of the ordinary.

  • According to docs.microsoft.com/en-us/windows/security/threat-protection/… failure code 0x18 means pre-authentication information was invalid. I wouldn't consider this normal behavior. I'd verify the domain trust relationship on the computer causing the event to fire. Look for related events in the System log. Also try to narrow down the scope of the problem to determine if it's only happening from some clients and not others. PS: Am I correct assuming W=Domain-joined Client and S=Domain Controller? – twconnell Mar 27 at 23:54
  • @twconnell, W is also a domain controller. – Tim Brigham Mar 28 at 1:39
  • Ugh, I hate those. Two things. 1. Is ipv6 enabled on the DCs? 2. Is there a scheduled task or service running on the DCs under a specific user context? – Trix Mar 28 at 3:07
  • I'm not familiar with the W/S abbreviations. I thought they meant Workstation/Server but now you're saying W can be a Domain Controller. Can you update the question to spell them out? – twconnell Mar 28 at 12:20
  • @twconnell they are just names. I've updated to make it clearer. – Tim Brigham Mar 28 at 13:54
0

According to the Microsoft Documentation, Kerberos authentication failure 4771 events (Failure Code 0x18 and Pre-Auth type 2) mean Kerberos pre-authentication information was invalid. This can happen when the computer has lost trust with the domain and is sending a bad password. I have seen several situations put a computer into this state: 1) Forcibly resetting the computer object password in ADU&C without re-establishing domain trust. 2) Re-creating the computer object in AD. 3) The client was off the network for a period of time and was not able to re-synchronize its computer password with a Domain Controller. These situations are more common than most people may think and are difficult to diagnose because users can continue logging on to these computers using cached credentials. Having a port authentication solution in place that validates the computer account would shut down the port for these computers and make the issue more noticeable.

You can verify the domain trust relationship on a computer causing the event to fire (Account Name in the event viewer / TargetUserName in the event XML) by running "nltest.exe /sc_query:[your_domain_name]" from the affected domain client.

Systems in this state are pretty chatty and will also generate NETLOGON error events (such as Event ID 5722 and 5805) in the System log of the Domain Controllers generating the 4771 events. You can query the DC system logs for these NETLOGON errors to determine which systems may be having domain trust issues. These events can occur under normal circumstances, so I'd only focus on repeat offenders generating more than 5 NETLOGON errors per day.

Here is a PowerShell one-liner you can run as a Domain Administrator to export a CSV containing the previous days NETLOGON errors from all your Domain Controllers.

Invoke-Command -ComputerName (Get-ADDomainController -Filter * | Sort-Object Name).Name -ScriptBlock {Get-WinEvent -FilterHashtable @{Logname="System";id=5722,5805;StartTime=(Get-Date).AddDays(-1)} | Select-Object TimeCreated,@{L='LoggedBy';E={$_.MachineName}},ProviderName,Id,Message,@{L='FailingComputer';E={($_.Message -split "\s+")[6]}}} | Export-Csv -Path "$(Get-Date -format "yyyy-MM-dd")_NETLOGON_Errors.csv" -NoTypeInformation

I would suggest re-joining one of the affected systems to the domain and see if that resolves the issue.

Note: In my experience, when the pre-authentication failure is generated on a Domain Controller which is not the PDC-Emulator, the domain PDC-Emulator will log a duplicate 4771 event containing the IP address of the Domain Controller where the failure originated from and the TargetUserName of the domain client having the bad password. In this case, focus on the TargetUserName of the event, not the IP Address.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.