0x18 Failure Code | Stop Kerberos Login Failures Fast

You spot a burst of failed sign-ins on a domain controller, a SIEM alert pings right away, and the same hex value keeps showing up. That pattern can feel noisy on sight, yet it’s also one of the cleanest clues Windows gives you. If you treat it like a breadcrumb trail instead of a mystery, you can usually find the exact device, service, or stored credential that’s tripping authentication.

This guide sticks to what the event data can tell you, then turns that into fixes you can apply with confidence. You’ll get a triage flow, targeted remediations for the common root causes, and a simple way to separate harmless misconfigurations from real password-guessing activity.

What The 0x18 Failure Code In Kerberos Sign-In Logs Means

In Active Directory domains, most interactive logons and many service-to-service requests use Kerberos. When a client asks a domain controller for a Ticket Granting Ticket (TGT), the domain controller checks pre-authentication data first. If that check fails, Windows records a Kerberos pre-authentication failure and tags it with a failure status.

For failure status 0x18, Microsoft maps it to “KDC_ERR_PREAUTH_FAILED,” which means the pre-authentication information was invalid. That often translates to “the password presented for that account did not match.” That mismatch can come from a real person typing the wrong password, a service running under an old password, cached credentials on a workstation, or a machine account that lost its trust relationship.

One detail matters a lot. The event is written on the domain controller, not on the client. So the event is your server-side receipt. Your job is to use the fields inside it to trace the client and the account that attempted the request.

Where You’ll Run Into This Error And What To Read First

Most teams first see this in the domain controller Security log as Event ID 4771. Some SIEMs also normalize it into a generic “Kerberos pre-auth failed” alert. Either way, the same core fields show up and they’re worth reading in a consistent order.

• Confirm The Account — Note the target user name and whether it’s a person, a service account, or a computer account ending in $.
• Check The Client IP — Use the IP to tie the request to a workstation, server, or appliance.
• Scan The Service Name — Many events show krbtgt, which is normal for TGT requests; service tickets can point at a specific SPN.
• Read The Pre-Auth Type — Type 2 is typical password pre-auth; smart card and FAST scenarios use other values.
• Look For Repetition — Same account plus same IP at steady intervals often hints at a scheduled task or service.

If you’re in a hurry, start with the IP and account name. That pair usually narrows the search to one box and one credential store.

Triage Steps To Pinpoint The Source In Minutes

Kerberos failures can pile up fast, so it helps to work from the data you already have. The goal is to identify the process or stored credential that keeps presenting a bad secret.

Start With A Single Representative Event

• Pick One Clean Sample — Choose an event with a clear client IP and the account you care about.
• Record The Timestamp — You’ll use it to line up client-side logs, task runs, and service restarts.
• Note The Domain Controller — Multi-DC environments can show failures on one controller first due to site affinity.

Identify The Client System Behind The IP

• Resolve The IP To A Host — Use DNS, DHCP leases, or your CMDB to map the IP to a device name.
• Verify It’s The Real Source — NAT, proxies, and log forwarders can mask origin; confirm with network teams if needed.
• Check If It’s A Shared Box — Jump hosts, RDS servers, and VDI pools often generate failures for many users.

Decide What Kind Of Account Is Failing

• Spot A Computer Account — Names ending with $ point to machine trust issues or stale computer passwords.
• Spot A Service Account — Short names used by apps, scheduled tasks, or middleware often break after a password change.
• Spot A Human Account — Think cached creds, mapped drives, old Wi-Fi profiles, or repeated sign-ins from one device.

Correlate With Client-Side Evidence

• Check The Windows Event Logs — On the client, look for logon failures, service start errors, or task failures at the same time.
• Inspect Credential Storage — Review Windows Credential Manager entries, saved RDP sessions, and app-specific vaults.
• Match The Interval — A failure every 15 minutes is rarely a person; it’s a timer, a task, or a keep-alive.

Fixes That Clear The Problem Without Guesswork

Once you know the client and the account type, you can use the shortest fix that matches the pattern. The sections below are written so you can jump straight to the scenario that fits your event data.

If A User Password Was Changed Recently

• Update Saved Credentials — Replace old passwords in Credential Manager, mapped drives, and saved RDP profiles on the client.
• Recreate Persistent Mappings — Remove and re-add mapped drives and “reconnect at sign-in” shares that still hold the old secret.
• Sign Out And Back In — A full sign-out clears more cached state than a quick lock-screen cycle.

In office environments, printers and file shares are common culprits. A device that retries a share connection with a stored password can generate failures long after the person thinks they’re done.

If A Scheduled Task Or Windows Service Uses The Account

• Search Task Scheduler — On the client server, list tasks “Run as” the failing account and update the stored password.
• Check Services.msc — For services running under a domain identity, update the logon password and restart the service.
• Scan For App Pools — In IIS, review application pool identities and update any that use the same credentials.

After updating a service account password, make one change at a time and watch for the error stream to stop. That quick feedback is your confirmation.

If The Failing Name Ends With A Dollar Sign

• Test Domain Trust — On the client machine, use a trust test or attempt a domain resource access to confirm the break.
• Reset The Computer Account Password — Rejoin the domain or use a supported repair method to refresh the machine secret.
• Reboot After Repair — A restart ensures services pick up the repaired secure channel state.

Machine trust breaks can show up after restores from snapshots, cloning, or manual resets of the computer object. If you see a steady stream from a single host with a computer account, treat it as a trust repair task.

If The Source Is A Non-Windows Device Or Appliance

• Verify The Joined Identity — Check the device’s domain join status and the account it uses for authentication.
• Update The Stored Secret — Appliances often keep a local copy of the password; align it with Active Directory.
• Confirm Time Sync — Kerberos is time sensitive; keep the device close to domain time to avoid cascaded failures.

When the source is an appliance, the fix is often in its own admin panel, not in Windows. The event data still gives you the account and the client IP that you need to track it down.

Quick Table Of Patterns And The Fix That Fits

When It Signals An Attack Versus A Misconfiguration

A wrong password pattern can be harmless, yet it can also be the start of account lockouts or a sign of password guessing. The difference is usually visible in the shape of the activity.

• Watch The Account Spread — Many different accounts from one client ip points to spraying, scanning, or a broken collector.
• Watch The Rate — Bursts that climb quickly are more suspicious than a steady trickle tied to a scheduler.
• Watch The Targets — Failures against admin or service accounts deserve faster escalation and tighter containment.
• Check For Lockouts — Pair pre-auth failures with lockout events to see if the attempts are progressing.

If your logs show repeated attempts against a high-value account, treat it as a containment job. Block the source IP at the edge, disable legacy protocols that still allow weak auth paths, and rotate the credential once you’ve found where it was stored.

Steps That Prevent The Same Failure From Coming Back

Once you’ve stopped the noise, take a few minutes to reduce the odds of a repeat. Most recurring cases come from password changes that don’t get propagated to all the places a credential is stored.

Credential Hygiene That Works In Real Networks

• Use Managed Service Accounts — Group managed service accounts cut down on manual password updates for services.
• Limit Where Passwords Are Saved — Prefer modern auth where possible and remove old stored entries on shared servers.
• Rotate With A Checklist — When a service account password changes, update tasks, services, app pools, scripts, and connectors in one pass.

Logging And Alerting That Stays Actionable

• Alert On Spikes — Trigger alerts on sudden increases per account or per client ip, not on every single event.
• Keep A Known-Noise List — Document expected sources like log collectors, then fix them instead of muting them forever.
• Tag High-Risk Accounts — Apply tighter monitoring to admin and service identities where failures carry more risk.

Close The Loop With A Final Verification

• Confirm The Stream Stops — After the change, watch the domain controller log for that account and IP for at least one full schedule interval.
• Test The Real Workload — Run the task, restart the service, or sign in from the device to ensure it succeeds.
• Document The Fix — Capture the root cause and the exact location of the stale credential so the next rotation is smoother.

If you still see the same failures after updating the obvious credential store, widen the search to scripts, connectors, and third-party agents. Many tools keep their own credential cache outside Windows. When you find it, update it once, then re-check your logs. A clean log after that is your closure signal.

As a final note, if you’re writing internal runbooks, keep a copy of the event fields you rely on most: target account, client IP, pre-auth type, and the domain controller name. Those four lines are often enough to resolve the alert without a long back-and-forth.

By treating the event data as a set of coordinates, you can clear the 0x18 failure code quickly, stop lockouts, and keep your authentication noise under control again.

Send us your feedbackTell us what you thought about this post

Name * Email *

Your comment *

Quick check — what is …? *

Send feedback