Event ID 5805: Netlogon Session Setup Failed to Authenticate

Short answer: Netlogon event 5805 is logged on a domain controller when a computer tries to set up its secure channel and fails to authenticate, usually with “Access is denied.” The computer’s machine account password no longer matches the one in Active Directory. Common reasons are a VM snapshot revert, a restore from backup, a deleted or reset computer object, or two machines using one name. Fix it on the named computer with Test-ComputerSecureChannel -Repair (or Reset-ComputerMachinePassword) and a restart. Rejoin it if the object is gone.

Commands checked against the official documentation (linked below) on 7 October 2026; not yet run on our lab servers.

What event ID 5805 means

Property	Value
Log	System
Source (provider)	NETLOGON
Level	Error
Logged on	The domain controller that received the session setup

The message, with placeholders:

The session setup from the computer <ComputerName> failed to authenticate. The following error occurred: <error text>

The error text is most often “Access is denied.” Microsoft Learn has no current reference page for 5805. The text above matches the event as quoted in a Microsoft Q&A thread (linked below). The causes and repair steps come from Microsoft’s secure channel troubleshooting articles.

Background: every domain member has a machine account password that it changes itself, every 30 days by default. Microsoft’s Netdom article explains that Windows keeps the current and previous password. If the computer and AD drift more than one change apart, the computer can no longer authenticate.

Common causes

• VM reverted to an old snapshot, or a machine restored from an image or bare-metal backup taken before the last password change.
• System restore to an old restore point, or an unexpected shutdown just after a password change on some embedded or VDI builds.
• Computer object deleted, reset or recreated in AD while the machine kept running.
• Duplicate computer names: a cloned or rebuilt machine joined with the same name, so the old one now holds the wrong password.
• Non-persistent VDI pools whose image carries an old machine password.
• Decommissioned devices that are still powered on somewhere and keep trying.

How to find the cause

On a DC, list which computers are failing and how often. The regular expression reads the computer name from the message text, so it works for 5805 and the related 5723:

Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='NETLOGON'; Id=5805,5722,5723; StartTime=(Get-Date).AddDays(-2)} -ErrorAction SilentlyContinue |
  ForEach-Object {
    [pscustomobject]@{
      Time     = $_.TimeCreated
      Id       = $_.Id
      Computer = if ($_.Message -match 'computer (\S+) failed') { $Matches[1] } else { '?' }
      Error    = ($_.Message -split "`r?`n" | Where-Object { $_ -match '\S' } | Select-Object -Last 1)
    }
  } | Group-Object Computer | Sort-Object Count -Descending | Format-Table Count, Name

Check the computer object in AD and where its name points:

Get-ADComputer PC01 -Properties Enabled, PasswordLastSet, whenCreated, whenChanged, IPv4Address, OperatingSystem
Resolve-DnsName PC01.contoso.local
repadmin /showobjmeta * "CN=PC01,OU=Workstations,DC=contoso,DC=local" > C:\Temp\PC01-meta.txt

In the repadmin output, compare pwdLastSet across DCs. It should be the same everywhere. A recent whenCreated on an old machine means the object was recreated. Two different devices answering for the same name means a duplicate.

On the affected computer (Windows PowerShell 5.1, elevated):

Test-ComputerSecureChannel -Verbose
nltest /sc_query:contoso.local
Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='NETLOGON'; Id=5823,3210} -MaxEvents 5 |
  Format-Table TimeCreated, Id, Message -Wrap
Get-WinEvent -FilterHashtable @{LogName='System'; Id=12,41,6008} -MaxEvents 10 | Format-Table TimeCreated, Id, ProviderName

Event 5823 marks the last successful machine password change. Microsoft’s guidance is to compare it with PasswordLastSet in AD; if AD is newer, the machine went back in time. Events 12, 41 and 6008 show boots and unclean shutdowns. A big gap in the log suggests a snapshot or backup restore.

In the console: on the DC, Event Viewer > Windows Logs > System > Filter Current Log, source NETLOGON, IDs 5805,5722,5723.

How to fix it

Machine password mismatch (computer still reachable)

Sign in with a local administrator account if domain logons fail. In Windows PowerShell 5.1 (not PowerShell 7, which does not include these cmdlets):

Test-ComputerSecureChannel -Repair -Credential CONTOSO\admin
# or reset the password against a chosen DC:
Reset-ComputerMachinePassword -Server dc01.contoso.local -Credential CONTOSO\admin

Then restart. Microsoft’s article on this scenario also gives nltest /sc_reset:contoso.local from an elevated command prompt with domain admin rights.

Domain controllers

Test-ComputerSecureChannel gives false results on DCs; Microsoft says to use netdom or nltest there. The Netdom procedure stops the KDC service on the affected DC, then runs netdom resetpwd /s:dc02 /ud:CONTOSO\admin /pd:* against a healthy DC, then restarts. Follow Microsoft’s article step by step; it is a DC-level change.

Computer object deleted or recreated

Rejoin the machine: move it to a workgroup, restart, join the domain again and restart. If someone deleted the object by mistake and the AD Recycle Bin is on, restoring the object is cleaner because group memberships come back with it. Do the restore before you rejoin.

Duplicate names and leftover devices

Rename one of the two machines, or turn off the leftover device. Remove stale DNS records that point the name at the wrong IP; our AD DNS scavenging guide shows how to keep them clean.

Snapshots and VDI

Avoid reverting domain-joined VMs to snapshots older than the last machine password change. If you must, repair the secure channel straight after the revert. For non-persistent VDI, follow your VDI vendor’s guidance on machine password handling.

Check that it worked

On the computer, Test-ComputerSecureChannel should return True. nltest /sc_verify:contoso.local (elevated) should report a successful trust verification. On the DC, rerun the grouping query with StartTime set to the fix time; the computer should no longer appear. Domain logons and gpupdate /force should work again.

Common problems

• Repair fails with access denied: the credential you passed cannot reset that computer object. Use an account with rights on the object or OU.
• The error comes back after a few days: something is still reverting the machine (snapshot schedule, restore tool, VDI image), or a second machine shares the name.
• 5805 names a computer that no longer exists: find it by the IP in DNS or DHCP and switch it off, or delete the stale DNS record.

Related events

Event ID	Logged on	What it means
5722	DC	Session setup failed to authenticate; also names the account referenced in the security database and the error.
5723	DC	Session setup failed because there is no trust account in the security database for that computer (object missing).
3210	Member	This computer could not authenticate with a DC; another computer may use the same name or its password is not recognized.
5719	Member	Could not set up a secure session with a DC (often no DC reachable).
5823	Member	The system successfully changed its machine password on a DC.

Official documentation: Active Directory has a newer password value than the client · Test-ComputerSecureChannel · Use Netdom.exe to reset a DC machine account password · Microsoft Q&A: event text for 5805

Related: Trust Relationship Failed: Fix Workstation Domain Problems · dcdiag repadmin Health Check: 7 Critical Tests Explained · AD DNS Scavenging: Safe Aging Setup with PowerShell

See also: Event ID 1129: Group Policy Failed, No Connectivity to a DC · Event ID 4771: Kerberos Pre-Authentication Failed (Codes)

Frequently asked questions