KERBEROS_PREAUTH_FAILED

Event ID 4771: Kerberos Pre-Authentication Failed

Complete troubleshooting guide for Exchange Server Event ID 4771 Kerberos authentication failures affecting Outlook connectivity, internal communications, and service operations.

Medha Cloud
Medha Cloud Exchange Server Team
Exchange Database Recovery Team8 min read

Table of Contents

Reading Progress
0 of 10

Error Overview

Event ID 4771: Kerberos Pre-Authentication Failed

"Kerberos pre-authentication failed. Account Information: Security ID: CONTOSO\john.doe. Account Name: john.doe. Service Information: Service Name: krbtgt/CONTOSO. Failure Information: Failure Code: 0x18. Pre-Authentication Type: 2."

What This Error Means

Event ID 4771 is logged on domain controllers when Kerberos pre-authentication fails. This is the first step in obtaining a Kerberos ticket - if it fails, the user cannot authenticate using Kerberos. Exchange relies on Kerberos for internal operations, so these failures can impact Outlook connectivity and server-to-server communication.

Common Failure Codes

  • • 0x18: Wrong password
  • • 0x17: Password expired
  • • 0x12: Account disabled
  • • 0x25: Clock skew (time issue)
  • • 0x6: Client not found

Exchange Kerberos Usage

  • • Outlook MAPI connections
  • • RPC over HTTP internal
  • • Server-to-server auth
  • • Service accounts
  • • EWS impersonation
⚠️

Version Notice

This guide applies to Exchange Server 2016, 2019, and Subscription Edition in Active Directory environments. Kerberos is fundamental to Windows authentication and Exchange integration with AD.

Symptoms & Detection

User-Reported Symptoms

  • Outlook repeatedly prompts for password
  • Account locked out frequently
  • "Cannot connect to Exchange" error
  • Services failing to start
  • Cross-forest operations failing

Administrator Detection

  • Event ID 4771 on Domain Controllers
  • Event ID 4768 failures (TGT request)
  • Exchange service authentication errors
  • SPN registration issues
  • Time sync warnings

Event Log Entry Example

Log Name:      Security
Source:        Microsoft-Windows-Security-Auditing
Event ID:      4771
Level:         Information
Keywords:      Audit Failure
Description:   Kerberos pre-authentication failed.

Account Information:
    Security ID:        CONTOSOjohn.doe
    Account Name:       john.doe

Service Information:
    Service Name:       krbtgt/CONTOSO

Network Information:
    Client Address:     ::ffff:10.0.1.50
    Client Port:        52431

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

Certificate Information:
    Certificate Issuer Name:
    Certificate Serial Number:
    Certificate Thumbprint:

Failure Code Reference:
0x18 = KDC_ERR_PREAUTH_FAILED (Wrong password)

Common Causes

1

Wrong Password (0x18)

Most common cause - user or service account password is incorrect. Often caused by cached credentials in Outlook, browsers, or services after a password change.

Resolution: Update password everywhere it's cached - credential manager, Outlook profile, scheduled tasks, services.
2

Time Synchronization Issues (0x25)

Kerberos requires time to be synchronized within 5 minutes between client and KDC. Clock skew beyond this threshold causes authentication to fail immediately.

Check: Verify NTP configuration on all domain members and that PDC is syncing to reliable time source.
3

Account Disabled/Expired (0x12)

The account attempting to authenticate is disabled in Active Directory or has passed its expiration date. Often affects service accounts that were disabled during account reviews.

Verify: Check account status in AD - Enabled, AccountExpires, and any account restrictions.
4

Password Expired (0x17)

Account password has expired based on domain password policy. User must change password before Kerberos authentication will succeed.

Service Accounts: Set "Password never expires" for managed service accounts or use Group Managed Service Accounts (gMSA).
5

SPN Issues

Service Principal Name (SPN) misconfiguration can cause Kerberos failures for Exchange services. Duplicate SPNs or missing SPNs prevent proper ticket requests.

Check: Use setspn -X to find duplicate SPNs, verify Exchange server SPNs are correctly registered.

Diagnostic Steps

Step 1: Query Kerberos Failure Events

# Query Event ID 4771 on Domain Controllers
# Run this on DC or specify -ComputerName

$dcName = (Get-ADDomainController).Name
$startTime = (Get-Date).AddHours(-24)

$kerbFailures = Get-WinEvent -ComputerName $dcName -FilterHashtable @{
    LogName = 'Security'
    Id = 4771
    StartTime = $startTime
} -ErrorAction SilentlyContinue

Write-Host "=== Kerberos Pre-Auth Failures (Last 24 Hours) ==="24 Hours) ===" -ForegroundColor Cyan
Write-Host "Total failures: $($kerbFailures.Count)"

# Group by failure code
Write-Host "`n=== Failures by Error Code ===" -ForegroundColor Yellow
$kerbFailures | ForEach-Object {
    $xml = [xml]$_.ToXml()
    ($xml.Event.EventData.Data | Where-Object {$_.Name -eq 'FailureCode'}).'#text'
} | Group-Object | Select-Object @{N='FailureCode';E={$_.Name}},
    @{N='Description';E={
        switch ($_.Name) {
            '0x6' {'Client not found in database'}
            '0x12' {'Account disabled'}
            '0x17' {'Password expired'}
            '0x18' {'Pre-auth failed (wrong password)'}
            '0x25' {'Clock skew too great'}
            default {'Unknown'}
        }
    }}, Count | Format-Table -AutoSize

# Group by account name
Write-Host "`n=== Failures by Account ===" -ForegroundColor Yellow
$kerbFailures | ForEach-Object {
    $xml = [xml]$_.ToXml()
    ($xml.Event.EventData.Data | Where-Object {$_.Name -eq 'TargetUserName'}).'#text'
} | Group-Object | Sort-Object Count -Descending | Select-Object Name, Count -First 15 |
    Format-Table -AutoSize

Step 2: Check Account Status

# Check AD account status for affected user/service
$accountName = "john.doe"

$account = Get-ADUser -Identity $accountName -Properties *

Write-Host "=== Account Status for $accountName ===" -ForegroundColor Cyan

[PSCustomObject]@{
    'Display Name' = $account.DisplayName
    'UPN' = $account.UserPrincipalName
    'Enabled' = $account.Enabled
    'Locked Out' = $account.LockedOut
    'Lockout Time' = $account.AccountLockoutTime
    'Bad Password Count' = $account.badPwdCount
    'Password Last Set' = $account.PasswordLastSet
    'Password Expired' = $account.PasswordExpired
    'Password Never Expires' = $account.PasswordNeverExpires
    'Account Expires' = $account.AccountExpirationDate
    'Last Logon' = $account.LastLogonDate
} | Format-List

# Check effective password policy
Get-ADUserResultantPasswordPolicy -Identity $accountName |
    Select-Object Name, MaxPasswordAge, MinPasswordLength, LockoutThreshold | Format-List

# Check if account is a service account with issues
if ($account.ServicePrincipalNames) {
    Write-Host "`n=== Service Principal Names ===" -ForegroundColor Yellow
    $account.ServicePrincipalNames | ForEach-Object { Write-Host "  $_" }
}

Step 3: Verify Time Synchronization

# Check time synchronization status

# On Exchange server
Write-Host "=== Local Time Status ===" -ForegroundColor Cyan
w32tm /query /status

# Check time against DC
Write-Host "`n=== Time Source Configuration ===" -ForegroundColor Yellow
w32tm /query /configuration

# Check time offset
Write-Host "`n=== Time Offset from Source ===" -ForegroundColor Yellow
w32tm /stripchart /computer:$(Get-ADDomainController).HostName /samples:3 /dataonly

# Check all Exchange servers' time
$exchangeServers = Get-ExchangeServer | Select-Object -ExpandProperty Name

Write-Host "`n=== Exchange Server Time Comparison ===" -ForegroundColor Cyan
foreach ($server in $exchangeServers) {
    try {
        $remoteTime = Invoke-Command -ComputerName $server -ScriptBlock { Get-Date } -ErrorAction Stop
        $localTime = Get-Date
        $offset = ($remoteTime - $localTime).TotalSeconds

        $color = if ([Math]::Abs($offset) -lt 60) {"Green"} elseif ([Math]::Abs($offset) -lt 300) {"Yellow"} else {"Red"}
        Write-Host "$server : Offset = $([math]::Round($offset,1)) seconds"$offset,1)) seconds" -ForegroundColor $color
    } catch {
        Write-Host "$server : Unable to check - $_"$_" -ForegroundColor Red
    }
}

# Kerberos max clock skew is 5 minutes (300 seconds) by default300 seconds) by default
Write-Host "`nNote: Kerberos max clock skew is 5 minutes (300 seconds)"300 seconds)" -ForegroundColor Cyan

Step 4: Check SPNs for Exchange

# Check Exchange server SPNs
$exchangeServer = $env:COMPUTERNAME

Write-Host "=== SPNs for Exchange Server $exchangeServer ===" -ForegroundColor Cyan

# Get computer account SPNs
$computerSPNs = Get-ADComputer -Identity $exchangeServer -Properties ServicePrincipalNames |
    Select-Object -ExpandProperty ServicePrincipalNames

$computerSPNs | Where-Object {$_ -match "exchange|http|smtp"} | Sort-Object

# Check for duplicate SPNs (causes Kerberos failures)
Write-Host "`n=== Checking for Duplicate SPNs ===" -ForegroundColor Yellow
setspn -X

# Common Exchange SPNs that should exist:
Write-Host "`n=== Expected Exchange SPNs ===" -ForegroundColor Cyan
@(
    "HTTP/$exchangeServer",
    "HTTP/$exchangeServer.domain.com",
    "exchangeRFR/$exchangeServer",
    "exchangeRFR/$exchangeServer.domain.com",
    "exchangeAB/$exchangeServer",
    "exchangeAB/$exchangeServer.domain.com",
    "exchangeMDB/$exchangeServer",
    "exchangeMDB/$exchangeServer.domain.com"
) | ForEach-Object { Write-Host "  $_" }

# Verify specific SPN exists
$checkSPN = "HTTP/mail.domain.com"
$result = setspn -Q $checkSPN
if ($result -match "No such SPN found") {
    Write-Host "`nWARNING: SPN '$checkSPN' not found" -ForegroundColor Red
} else {
    Write-Host "`nSPN '$checkSPN' found:" -ForegroundColor Green
    $result
}
💡

Pro Tip

Use "klist" command on the affected client to view current Kerberos tickets. "klist purge" clears cached tickets, forcing a fresh authentication. This can help after password changes or when troubleshooting ticket issues.

Quick Fix

Immediate Kerberos Issue Resolution

Quick fixes based on the failure code:

# Step 1: Identify the failure code and take appropriate action

# For 0x18 (Wrong Password):
# Clear cached credentials and re-authenticate
# On client machine:
klist purge  # Clear Kerberos tickets
cmdkey /list  # List stored credentials
# cmdkey /delete:target_name  # Remove specific credential

# Step 2: For locked account
$targetUser = "john.doe"
Unlock-ADAccount -Identity $targetUser
Write-Host "Account $targetUser unlocked" -ForegroundColor Green

# Step 3: For password expired
Set-ADUser -Identity $targetUser -ChangePasswordAtLogon $true
# Or reset password:
# Set-ADAccountPassword -Identity $targetUser -NewPassword (Read-Host -AsSecureString "New Password") -Reset-Identity $targetUser -NewPassword (Read-Host -AsSecureString "New Password") -Reset

# Step 4: For disabled account
Enable-ADAccount -Identity $targetUser
Write-Host "Account $targetUser enabled" -ForegroundColor Green

# Step 5: For time sync issues (0x25)
# Force time sync immediately
w32tm /resync /force

# Restart time service if needed
Restart-Service w32time -Force
w32tm /resync

# Step 6: For service accounts - verify password in services.msc
Get-WmiObject Win32_Service | Where-Object {$_.StartName -match $targetUser} |
    Select-Object Name, State, StartName | Format-Table -AutoSize

Write-Host "`nAfter fix, test authentication:" -ForegroundColor Cyan
Write-Host "klist get krbtgt/DOMAIN.COM  # Request new TGT"

Note: After fixing the underlying issue, users may need to log off and on, or run "klist purge" to clear old tickets and obtain new ones.

Detailed Solutions

Solution 1: Fix Service Account Authentication

Service accounts with Kerberos failures need careful remediation:

# Identify services using the affected account
$serviceAccount = "CONTOSOsvc_exchange"

# Check Windows services
Write-Host "=== Windows Services Using Account ===" -ForegroundColor Cyan
Get-WmiObject Win32_Service | Where-Object {$_.StartName -match $serviceAccount.Split('')[1]} |
    Select-Object Name, State, StartMode | Format-Table -AutoSize

# Check scheduled tasks
Write-Host "`n=== Scheduled Tasks Using Account ===" -ForegroundColor Yellow
Get-ScheduledTask | ForEach-Object {
    $principal = $_.Principal
    if ($principal.UserId -match $serviceAccount.Split('')[1]) {
        [PSCustomObject]@{
            TaskName = $_.TaskName
            TaskPath = $_.TaskPath
            RunAs = $principal.UserId
            State = $_.State
        }
    }
} | Format-Table -AutoSize

# Check IIS App Pools
Import-Module WebAdministration -ErrorAction SilentlyContinue
Get-ChildItem IIS:AppPools | ForEach-Object {
    $identity = $_.processModel.userName
    if ($identity -match $serviceAccount.Split('')[1]) {
        Write-Host "App Pool: $($_.Name) - Identity: $identity"$identity"
    }
}

# Update service account password everywhere
$newPassword = Read-Host "Enter new password for $serviceAccount" -AsSecureString

# Update AD account
Set-ADAccountPassword -Identity ($serviceAccount.Split('')[1]) -NewPassword $newPassword -Reset

# Update Windows services (example)
# sc.exe config "ServiceName" obj= "$serviceAccount" password= "password""$serviceAccount" password= "password"

Write-Host "`n=== Post-Update Actions ===" -ForegroundColor Cyan
Write-Host "1. Restart affected services"
Write-Host "2. Recycle affected IIS app pools"
Write-Host "3. Update scheduled tasks with new password"
Write-Host "4. Update any application configuration files"

Solution 2: Fix Time Synchronization

Ensure proper time synchronization across the domain:

# Configure proper time hierarchy:
# External NTP -> PDC Emulator -> Other DCs -> Domain Members

# Step 1: Configure PDC Emulator to sync with external source
$pdcEmulator = (Get-ADDomain).PDCEmulator
Write-Host "PDC Emulator: $pdcEmulator" -ForegroundColor Cyan

# On PDC Emulator, run:
# w32tm /config /manualpeerlist:"time.windows.com,0x9 time.nist.gov,0x9" /syncfromflags:manual /reliable:yes /update
# Restart-Service w32time
# w32tm /resync

# Step 2: Other DCs should sync from domain hierarchy
# w32tm /config /syncfromflags:domhier /update
# Restart-Service w32time

# Step 3: Verify time config on Exchange servers
Write-Host "`n=== Exchange Server Time Configuration ===" -ForegroundColor Yellow
$exchangeServers = Get-ExchangeServer | Select-Object -ExpandProperty Name

foreach ($server in $exchangeServers) {
    Write-Host "`n--- $server ---"
    Invoke-Command -ComputerName $server -ScriptBlock {
        w32tm /query /status | Select-String "Source|Stratum|Last Successful"
    } -ErrorAction SilentlyContinue
}

# Step 4: Force immediate sync on all Exchange servers
foreach ($server in $exchangeServers) {
    Write-Host "Syncing time on $server..."
    Invoke-Command -ComputerName $server -ScriptBlock {
        w32tm /resync /force
    } -ErrorAction SilentlyContinue
}

# Step 5: Verify sync after fix
Start-Sleep -Seconds 10
Write-Host "`n=== Time Verification ===" -ForegroundColor Green
foreach ($server in $exchangeServers) {
    $remoteTime = Invoke-Command -ComputerName $server -ScriptBlock { Get-Date }
    $offset = ($remoteTime - (Get-Date)).TotalSeconds
    Write-Host "$server : Offset = $([math]::Round($offset,1)) seconds"$offset,1)) seconds"
}

Solution 3: Fix SPN Issues

Correct SPN configuration for Exchange servers:

# Check and fix Exchange SPNs

# Step 1: Find duplicate SPNs (major issue)
Write-Host "=== Checking for Duplicate SPNs ===" -ForegroundColor Yellow
setspn -X

# Step 2: Check SPNs for Exchange server
$exchangeServer = $env:COMPUTERNAME
$serverFQDN = [System.Net.Dns]::GetHostByName($exchangeServer).HostName

Write-Host "`n=== Current SPNs on $exchangeServer ===" -ForegroundColor Cyan
setspn -L $exchangeServer

# Step 3: Add missing Exchange SPNs
$requiredSPNs = @(
    "HTTP/$exchangeServer",
    "HTTP/$serverFQDN",
    "exchangeRFR/$exchangeServer",
    "exchangeRFR/$serverFQDN",
    "exchangeAB/$exchangeServer",
    "exchangeAB/$serverFQDN",
    "exchangeMDB/$exchangeServer",
    "exchangeMDB/$serverFQDN"
)

foreach ($spn in $requiredSPNs) {
    $check = setspn -Q $spn
    if ($check -match "No such SPN found") {
        Write-Host "Missing SPN: $spn - Adding..." -ForegroundColor Yellow
        # Uncomment to add:
        # setspn -S $spn $exchangeServer$spn $exchangeServer
    } else {
        Write-Host "SPN exists: $spn" -ForegroundColor Green
    }
}

# Step 4: If you have a load balancer or CAS array name
$loadBalancerName = "mail.domain.com"
Write-Host "`n=== Checking Load Balancer SPNs ===" -ForegroundColor Cyan

# HTTP SPN for load balancer - should be on service account or specific server
setspn -Q "HTTP/$loadBalancerName"

# Step 5: Fix Autodiscover SPN if using internal hostname
$autodiscoverName = "autodiscover.domain.com"
setspn -Q "HTTP/$autodiscoverName"

Write-Host "`n=== SPN Best Practices ===" -ForegroundColor Cyan
Write-Host "1. Each SPN should exist on only ONE account"
Write-Host "2. Use setspn -S (not -A) to prevent duplicates"-S (not -A) to prevent duplicates"
Write-Host "3. For load balanced names, use a service account"
Write-Host "4. Document all custom SPN configurations"

Solution 4: Implement Group Managed Service Accounts

Use gMSA to eliminate service account password management issues:

# Group Managed Service Accounts (gMSA) automatically manage passwords

# Step 1: Create KDS root key (if not exists) - only needed once per forest
# For production (wait 10 hours for replication):
# Add-KdsRootKey -EffectiveImmediately-EffectiveImmediately
# For testing only:
# Add-KdsRootKey -EffectiveTime ((Get-Date).AddHours(-10))-EffectiveTime ((Get-Date).AddHours(-10))

# Step 2: Create the gMSA account
$gMSAName = "gMSA_Exchange"
$dnsHostName = "$gMSAName.contoso.com"
$exchangeServers = Get-ExchangeServer | Select-Object -ExpandProperty Name

# Get Exchange servers as computer objects
$principals = Get-ADComputer -Filter {Name -like "EXCH*"}

New-ADServiceAccount -Name $gMSAName -DNSHostName $dnsHostName -PrincipalsAllowedToRetrieveManagedPassword $principals -ServicePrincipalNames "HTTP/mail.contoso.com","HTTP/autodiscover.contoso.com"

# Step 3: Install gMSA on Exchange servers
foreach ($server in $exchangeServers) {
    Invoke-Command -ComputerName $server -ScriptBlock {
        param($name)
        Install-ADServiceAccount -Identity $name
        Test-ADServiceAccount -Identity $name
    } -ArgumentList $gMSAName
}

# Step 4: Configure service to use gMSA
# In Services.msc, set service account to: CONTOSOgMSA_Exchange$
# Password field should be left BLANK (gMSA manages it automatically)

# Step 5: Verify gMSA is working
Get-ADServiceAccount -Identity $gMSAName -Properties * |
    Select-Object Name, DNSHostName, PrincipalsAllowedToRetrieveManagedPassword,
    ServicePrincipalNames, PasswordLastSet | Format-List

Write-Host "`n=== gMSA Benefits ===" -ForegroundColor Cyan
Write-Host "1. Password automatically managed by AD"
Write-Host "2. Password changes automatically (120 days by default)"120 days by default)"
Write-Host "3. No password storage or rotation needed"
Write-Host "4. No Kerberos failures from expired service passwords"
🚨

Danger Zone

Removing or modifying SPNs incorrectly can break Kerberos authentication for Exchange services. Always document current SPNs before making changes and test in non-production first. setspn -X should show zero duplicates.

Verification Steps

Verify Kerberos Authentication

# Comprehensive Kerberos verification

# Step 1: Test Kerberos ticket acquisition
Write-Host "=== Testing Kerberos Ticket Acquisition ===" -ForegroundColor Cyan
klist purge > $null
klist get krbtgt/$env:USERDNSDOMAIN

# Step 2: Check current tickets
Write-Host "`n=== Current Kerberos Tickets ===" -ForegroundColor Yellow
klist

# Step 3: Verify no recent failures for specific account
$testAccount = "john.doe"
$dcName = (Get-ADDomainController).Name
$recentFailures = Get-WinEvent -ComputerName $dcName -FilterHashtable @{
    LogName = 'Security'
    Id = 4771
    StartTime = (Get-Date).AddHours(-1)
} -ErrorAction SilentlyContinue | Where-Object {
    $_.Message -match $testAccount
}

if ($recentFailures.Count -eq 0) {
    Write-Host "`nNo Kerberos failures for $testAccount in last hour" -ForegroundColor Green
} else {
    Write-Host "`n$($recentFailures.Count) failures for $testAccount in last hour"$testAccount in last hour" -ForegroundColor Red
}

# Step 4: Test Exchange Kerberos connectivity
Write-Host "`n=== Testing Exchange Kerberos ===" -ForegroundColor Cyan
$exchangeServer = (Get-ExchangeServer | Select-Object -First 1).Name

# Test HTTP SPN
$httpSPN = "HTTP/$exchangeServer"
Write-Host "Testing SPN: $httpSPN"
klist get $httpSPN

# Step 5: Verify time sync
Write-Host "`n=== Time Synchronization ===" -ForegroundColor Yellow
$timeOffset = w32tm /stripchart /computer:$dcName /samples:1 /dataonly 2>&1
Write-Host $timeOffset

Write-Host "`n=== Verification Complete ===" -ForegroundColor Cyan

✓ Success Indicators

  • • TGT acquired successfully
  • • No Event ID 4771 errors
  • • Time sync within 5 minutes
  • • No duplicate SPNs

⚠ Warning Signs

  • • Occasional failures persist
  • • Time drift recurring
  • • Service accounts expiring
  • • SPN warnings

✗ Failure Indicators

  • • Cannot acquire tickets
  • • Continued 4771 events
  • • Time skew too great
  • • Duplicate SPNs found

Prevention Strategies

Kerberos Best Practices

  • Use gMSA for services

    Automatic password management

  • Monitor time sync

    Alert if skew exceeds 2 minutes

  • Audit SPN configuration

    Monthly check for duplicates

  • Monitor Event 4771

    Alert on unusual failure patterns

Kerberos Monitoring Script

# Daily Kerberos health check
$dcName = (Get-ADDomainController).Name
$threshold = 10  # Alert if more than 10 failures/hour

$failures = Get-WinEvent -ComputerName $dcName -FilterHashtable @{
    LogName = 'Security'
    Id = 4771
    StartTime = (Get-Date).AddHours(-1)
} -ErrorAction SilentlyContinue

# Check for patterns
$failuresByAccount = $failures | ForEach-Object {
    $xml = [xml]$_.ToXml()
    ($xml.Event.EventData.Data | Where-Object {$_.Name -eq 'TargetUserName'}).'#text'
} | Group-Object

$highFailures = $failuresByAccount | Where-Object {$_.Count -gt $threshold}

if ($highFailures) {
    Write-Warning "High Kerberos failures detected!"
    $highFailures | Format-Table Name, Count
}

When to Escalate

Escalate to AD/Security Specialist When:

  • Kerberos failures affecting multiple services organization-wide
  • Complex SPN issues across multiple domains/forests
  • Time synchronization problems with PDC emulator
  • Suspected Kerberos-based attack (Golden/Silver ticket)
  • Trust relationship issues affecting authentication

Need Expert Exchange Kerberos Help?

Our Exchange and Active Directory specialists can diagnose complex Kerberos issues, fix SPN configurations, and ensure seamless authentication across your environment.

15 Minutes average response time for authentication emergencies

Frequently Asked Questions

Kerberos pre-authentication is the initial step where a user proves their identity before receiving a ticket. Event ID 4771 occurs when this fails - typically due to wrong password (0x18), expired password (0x17), account disabled (0x12), or time synchronization issues (0x25). This is different from NTLM failures and specifically affects Kerberos authentication.

Can't Resolve KERBEROS_PREAUTH_FAILED?

Exchange errors can cause data loss or extended downtime. Our specialists are available 24/7 to help.

Emergency help - Chat with us
Medha Cloud

Medha Cloud Exchange Server Team

Microsoft Exchange Specialists

Our Exchange Server specialists have 15+ years of combined experience managing enterprise email environments. We provide 24/7 support, emergency troubleshooting, and ongoing administration for businesses worldwide.

15+ Years ExperienceMicrosoft Certified99.7% Success Rate24/7 Support