Kerberos AD Felsökning: SPN & 4771 (2026)

Q: Hur ser jag mina Kerberos-biljetter i Windows?

Kör klist i CMD eller PowerShell för att lista alla aktiva biljetter för den inloggade användaren. Kommandot klist tickets ger samma resultat, och klist purge raderar dem så att nya biljetter måste utfärdas. Vill du se biljetter för ett tjänstekonto måste du köra kommandot i den kontextens process, till exempel via PsExec -s för SYSTEM.

Uppdaterad: 6 september 2026

Kerberos-felsökning i Active Directory börjar nästan alltid med tre kontroller: klockavvikelse mellan klient och KDC, dubbla Service Principal Names (SPN) och Event 4771 på domänkontrollanten. När någon av dessa är trasig får användaren "The user name or password is incorrect" trots att lösenordet stämmer, eller en tyst NTLM-fallback som senare bryter en applikation. I den här guiden går jag igenom den ordning jag själv använder på helpdesk, kommando för kommando, med förväntad utdata, så att du kan lösa 90 % av Kerberos-ärenden på under 20 minuter.

Kerberos misslyckas oftast på grund av klockavvikelse över 5 minuter, dubbla SPN eller felaktig krypteringstyp (RC4 vs AES).
Event ID 4771 loggas på domänkontrollanten när pre-authentication misslyckas. Felkoden 0x18 betyder felaktigt lösenord, 0x25 betyder klockavvikelse.
klist och setspn -X är de två viktigaste kommandona för att se biljetter respektive hitta duplicerade SPN.
KRBTGT-lösenordet bör roteras två gånger med 10–24 timmars mellanrum, aldrig oftare, annars invalideras alla aktiva biljetter samtidigt.
RC4-HMAC (etype 23) fasas ut av Microsoft under 2026; migrera till AES256 (etype 18) via Group Policy och kontrollera msDS-SupportedEncryptionTypes.
Constrained delegation med protocol transition (S4U2Self/S4U2Proxy) är säkrare än unconstrained delegation och bör användas för alla nya tjänstekonton.

Hur Kerberos fungerar i AD, snabb repetition

Innan vi felsöker: Kerberos i Active Directory bygger på tre parter, nämligen klienten, KDC-tjänsten (Key Distribution Center, som körs på varje domänkontrollant) och den tjänst användaren vill nå (till exempel en SQL Server eller en webbserver). Autentiseringen sker i två steg. Först begär klienten en Ticket Granting Ticket (TGT) från KDC med sitt lösenord som bevis, sedan använder klienten den TGT:n för att be om en Service Ticket (TGS) för den specifika tjänsten. Service Ticket presenteras för tjänsten, som verifierar den lokalt utan att prata med KDC.

Det innebär att om en användare kan logga in på sin dator men inte nå en applikation, är TGT:n troligen giltig men TGS-utfärdandet misslyckas, och då pekar spåret nästan alltid mot SPN eller encryption type på målservern. Om själva inloggningen misslyckas är det TGT-steget som fallerar, och då är det Event 4771 på PDC-emulatorn du vill titta på först. Microsofts Kerberos authentication overview beskriver protokollet i detalj om du vill gräva ner dig ordentligt.

Snabb triage: fem kommandon som avgör felet

När ett Kerberos-ärende landar hos mig kör jag alltid samma fem kommandon på klientens dator, i den här ordningen. Förväntad utdata står under varje kommando. Det är det enda sättet att veta vad "normalt" ser ut som när något går fel.

# 1. Kolla klockavvikelse mot domänkontrollanten (får inte vara över 5 min)
w32tm /monitor /computers:dc01.contoso.local
# Förväntat: NTP: +/-00.0000000s offset from dc01.contoso.local

# 2. Lista alla Kerberos-biljetter för användaren
klist
# Förväntat: minst en krbtgt/CONTOSO.LOCAL-biljett med KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96

# 3. Rensa cache och tvinga ny TGT (utan att logga ut)
klist purge
# Förväntat: Ticket(s) purged!

# 4. Testa om användaren kan begära en TGS för en specifik tjänst
klist get MSSQLSvc/sqlprod01.contoso.local:1433
# Förväntat: KerbTicket Encryption Type: AES-256... om detta misslyckas är SPN trasigt

# 5. Kolla på DC:n vilken krypteringstyp kontot stödjer
Get-ADUser tjanstekonto -Properties msDS-SupportedEncryptionTypes | Format-List
# Förväntat värde: 24 (AES128 + AES256) eller 28 (AES128 + AES256 + RC4)

Om steg 1 visar en avvikelse större än 300 sekunder: sluta här och fixa tidssynkronisering först. Kerberos vägrar rent principiellt att fungera med större klockskillnad, och alla andra fel du ser är sekundära symptom. Om steg 4 returnerar KDC_ERR_S_PRINCIPAL_UNKNOWN är SPN antingen felstavat eller finns inte alls. Returnerar det KDC_ERR_ETYPE_NOTSUPP är det en krypteringskonflikt och du hoppar direkt till avsnittet om krypteringstyper.

Hur läser du Event 4771 och 4768?

De två viktigaste Kerberos-eventen i Security-loggen på domänkontrollanten är 4768 (TGT-begäran) och 4771 (pre-authentication misslyckades). När en användare klagar på inloggningsproblem är 4771 nästan alltid det första du ska titta på. Loggen ligger som vanligt under Windows Logs → Security och du kan filtrera med denna PowerShell:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4771} -MaxEvents 50 |
    Where-Object { $_.Properties[0].Value -eq 'anna.andersson' } |
    Select-Object TimeCreated,
        @{n='FailureCode';e={$_.Properties[6].Value}},
        @{n='ClientIP';e={$_.Properties[9].Value}} |
    Format-Table -AutoSize

De vanligaste felkoderna du kommer se, hexadecimalt:

0x6: Client not found. Kontot finns inte eller är felstavat.
0x12: Client disabled, expired eller lockout. Se vår guide för att spåra AD-kontoutlåsning via Event 4740 för att hitta källan.
0x17: Password expired. Klienten behöver ändra lösenord vid nästa inloggning.
0x18: Pre-authentication failed. Fel lösenord. Absolut vanligast.
0x25: Clock skew. Klienten och DC:n är mer än 5 minuter osynkade.
0x37: Kontot är låst på grund av policy.

Event 4768 loggas vid varje lyckad TGT-begäran, inklusive Encryption Type i fält 11. Om du ser 0x17 (RC4-HMAC) för ett tjänstekonto som borde använda AES har du hittat kontot att uppgradera. Fältnummer refererar till XML-viewn av eventet. Event Viewer visar dem i friendly format, men PowerShell-scriptet ovan ger dig råvärdena.

Dubbla SPN, den vanligaste tysta orsaken

Duplicerade Service Principal Names är den överlägset vanligaste orsaken till Kerberos-fel som "fungerar ibland" eller "fungerar för vissa användare". När två konton (till exempel både datorobjektet och ett tjänstekonto) har samma SPN, faller Kerberos tillbaka till NTLM utan att logga något tydligt fel på klientens sida. Applikationen fortsätter fungera för de flesta men bryts vid Single Sign-On, delegering eller MFA-krav. Jag har själv suttit en hel eftermiddag och jagat en "sporadisk" SSO-bugg som det visade sig var en dubblett från en gammal migrering 2019.

Så här hittar och rensar du dem:

# Hitta alla duplicerade SPN i skogen
setspn -X -F
# Förväntat: "found 0 group of duplicate SPNs." allt annat är dåligt

# Lista alla SPN registrerade på ett konto
setspn -L CONTOSO\svc_sqlprod
# Förväntat: en lista med MSSQLSvc/host:port-poster

# Ta bort en dublett från fel konto
setspn -D MSSQLSvc/sqlprod01.contoso.local:1433 CONTOSO\gammalt-konto

# Lägg till den på rätt konto
setspn -S MSSQLSvc/sqlprod01.contoso.local:1433 CONTOSO\svc_sqlprod

Notera skillnaden mellan -A (add utan dublettkontroll) och -S (add med automatisk dublettkontroll). Använd alltid -S. Flaggan -A är gammal och skapar bara mer arbete för dig senare. När du har rensat SPN måste alla klienter köra klist purge eller vänta ut TGS-cachens livstid (10 timmar som standard), annars fortsätter de använda den gamla, felaktiga biljetten.

Klockavvikelse och tidsserverproblem

Kerberos använder en tidsstämpel i pre-authentication-paketet för att förhindra replay-attacker. Standardtoleransen är 5 minuter (300 sekunder) och styrs av Maximum tolerance for computer clock synchronization i Default Domain Policy. När klockan glider isär loggas Event 4771 med felkod 0x25 och användaren får kryptiska "Access denied" som inte alls antyder att problemet är tidsrelaterat.

Så här verifierar du hela tidshierarkin:

# På klientdatorn
w32tm /query /status
# Förväntat: Source: dc01.contoso.local, Last Successful Sync Time under 60 min sedan

# På vilken DC som helst
w32tm /query /configuration
# Förväntat: Type: NT5DS (för domänmedlemmar) eller NTP (för PDC-emulatorn)

# På PDC-emulatorn (top of the tree)
w32tm /query /source
# Förväntat: en pålitlig extern NTP-server, till exempel time.windows.com eller pool.ntp.org

# Tvinga omedelbar resynkronisering
w32tm /resync /force
# Förväntat: The command completed successfully.

I moderna virtualiserade miljöer är den vanligaste orsaken att Hyper-V eller VMware Time Synchronization är påslaget på DC:n samtidigt som DC:n själv är NTP-klient. De två slåss om att sätta klockan. Regeln är enkel: domänkontrollanter ska aldrig ta tid från hypervisorn. Stäng av Time Sync-integrationen på DC:n eller ändra den till att bara aktivera vid uppstart och migrering. Windows Server 2025 slår som standard av VMIC Time Synchronization för domänkontrollanter, men äldre versioner måste konfigureras manuellt.

RC4, AES och "KDC has no support for encryption type"

Microsoft har fasat ut RC4-HMAC i flera steg sedan 2020, och i november 2024 kom en säkerhetsuppdatering (KB5020805) som gjorde AES obligatoriskt för AS-REQ i förvalt läge. Under 2026 fortsätter utfasningen. RC4 kan fortfarande aktiveras men triggar varningar och blockeras av CVE-2022-37967-mitigationer som standard. Symptomet är felmeddelandet KDC_ERR_ETYPE_NOTSUPP eller Event 14 (source: Kerberos-Key-Distribution-Center).

Attributet msDS-SupportedEncryptionTypes på användar- och datorobjekt styr vilka krypteringstyper KDC får utfärda biljetter med. Värdet är en bitmask:

Värde	Krypteringstyp	Etype-nummer	Rekommendation 2026
0x1	DES-CBC-CRC	1	Aldrig (bruten)
0x2	DES-CBC-MD5	3	Aldrig (bruten)
0x4	RC4-HMAC	23	Endast för legacy-tjänster
0x8	AES128-CTS-HMAC-SHA1-96	17	OK, minimum
0x10	AES256-CTS-HMAC-SHA1-96	18	Rekommenderat
0x20	AES256-CTS-HMAC-SHA384-192	20	Server 2025 / Windows 11 24H2+

För att sätta ett tjänstekonto till "endast AES" använder du:

# Slå på AES128 + AES256, stäng av RC4
Set-ADUser svc_sqlprod -Replace @{'msDS-SupportedEncryptionTypes'=24}

# För datorobjekt (till exempel en filserver)
Set-ADComputer FS01 -Replace @{'msDS-SupportedEncryptionTypes'=24}

# Kontrollera resultatet
Get-ADUser svc_sqlprod -Properties msDS-SupportedEncryptionTypes |
    Select-Object Name, msDS-SupportedEncryptionTypes

Efter ändringen måste kontot ändra lösenord eller kontonyckeln regenereras, annars finns bara den gamla RC4-nyckeln i AD och biljetter kan inte krypteras med AES. För tjänstekonton kör du Set-ADAccountPassword; för datorkonton händer detta automatiskt vid nästa machine password change (30 dagar). Vår kompletta guide för Active Directory-felsökning går djupare in på hur du massuppgraderar många konton på en gång.

Kerberos-delegering: unconstrained, constrained och RBCD

Delegering låter en tjänst agera för en användares räkning mot en annan tjänst. Det är så en webbserver kan hämta data från en SQL-databas med användarens identitet snarare än sin egen. Det finns tre varianter, i ökande grad av säkerhet:

Unconstrained delegation: den ursprungliga varianten. Servern får hela användarens TGT och kan agera som användaren mot vilken tjänst som helst. Extremt farligt. Om servern komprometteras har angriparen alla TGT:s som cachats där. Använd aldrig i nya miljöer.
Constrained delegation (KCD): servern får bara delegera till en explicit lista av tjänster som du konfigurerar via msDS-AllowedToDelegateTo. Kräver protocol transition om användaren autentiseras med något annat än Kerberos.
Resource-based constrained delegation (RBCD): konfigureras på måltjänsten istället för källtjänsten (msDS-AllowedToActOnBehalfOfOtherIdentity). Detta är rätt val för alla nya driftsättningar och det enda som fungerar över skogsgränser.

Så här sätter du upp RBCD:

# På måltjänsten (t.ex. en filserver) tillåter du att en viss webbserver
# får agera för användarens räkning
$web = Get-ADComputer WEB01
Set-ADComputer FS01 -PrincipalsAllowedToDelegateToAccount $web

# Verifiera
Get-ADComputer FS01 -Properties PrincipalsAllowedToDelegateToAccount |
    Select-Object -ExpandProperty PrincipalsAllowedToDelegateToAccount

Ändringen får effekt omedelbart för nya biljetter, inget lösenordsbyte eller replikering krävs utöver normal AD-replikering mellan DC:er. För att audita befintliga delegeringar i miljön (och hitta gamla unconstrained-konfigurationer som borde bort) kan du köra:

Get-ADObject -Filter { (msDS-AllowedToDelegateTo -like '*') -or `
    (userAccountControl -band 0x80000) -or `
    (msDS-AllowedToActOnBehalfOfOtherIdentity -like '*') } `
    -Properties samAccountName, msDS-AllowedToDelegateTo,
        userAccountControl, msDS-AllowedToActOnBehalfOfOtherIdentity |
    Format-List

Bit 0x80000 (TRUSTED_FOR_DELEGATION) i userAccountControl är flaggan för unconstrained. Har du konton med den flaggan som inte är domänkontrollanter: börja migrera dem till RBCD nu. Microsofts KCD-dokumentation har fler exempel för fler scenarier.

Rotera KRBTGT-lösenordet utan att låsa ut alla

KRBTGT är det dolda kontot som signerar alla TGT i domänen. Kompromissas dess nyckel kan en angripare tillverka Golden Tickets, alltså biljetter som är giltiga i tio år och som ger domain admin-rättigheter till vem som helst. Därför rekommenderar Microsoft att KRBTGT-lösenordet roteras minst en gång per år, och alltid två gånger i följd efter en incident.

Regeln som räddar dig från utebliven inloggning för hela företaget: rotera aldrig KRBTGT två gånger inom mindre än 10 timmar. TGT-livstiden är 10 timmar som standard, så om du roterar två gånger snabbare invaliderar du alla aktiva biljetter samtidigt och alla användare måste logga om på nytt. Rätt process ser ut så här:

Verifiera att AD-replikeringen är frisk med repadmin /replsummary. Inga fel.
Ladda ner Microsofts officiella script New-KrbtgtKeys.ps1 från GitHub. Skriv inte ett eget.
Kör i "Reset Mode" mot en enskild DC för test först.
Vänta minst 24 timmar mellan de två rotationerna i produktion.
Övervaka Event 4769 (TGS-utfärdande) för toppar i felkod 0x1F (integrity check failed), vilket tyder på att gamla biljetter används och att första rotationen inte replikerats fullt ut.

PowerShell-runbook för helpdesk

Här är den kompletta triage-scripten jag använder som första svar när en användare rapporterar "kan inte logga in" och Event 4771 finns i loggen. Kör den från en admin-arbetsstation med RSAT installerat.

function Invoke-KerberosTriage {
    param(
        [Parameter(Mandatory)][string]$SamAccountName,
        [string]$DomainController = (Get-ADDomainController -Discover).HostName[0]
    )

    Write-Host "=== Kerberos-triage för $SamAccountName ===" -ForegroundColor Cyan

    # 1. Kontostatus
    $user = Get-ADUser $SamAccountName -Properties LockedOut,
        PasswordExpired, PasswordLastSet, msDS-SupportedEncryptionTypes,
        ServicePrincipalNames -Server $DomainController
    Write-Host "LockedOut: $($user.LockedOut)"
    Write-Host "PasswordExpired: $($user.PasswordExpired)"
    Write-Host "PasswordLastSet: $($user.PasswordLastSet)"
    Write-Host "EncTypes: $($user.'msDS-SupportedEncryptionTypes')"

    # 2. SPN-lista och dublettkontroll
    if ($user.ServicePrincipalNames) {
        Write-Host "`nRegistrerade SPN:"
        $user.ServicePrincipalNames | ForEach-Object { Write-Host "  $_" }
        foreach ($spn in $user.ServicePrincipalNames) {
            $dupes = setspn -Q $spn 2>&1 | Select-String 'CN='
            if ($dupes.Count -gt 1) {
                Write-Warning "DUBLETT: $spn finns på $($dupes.Count) konton"
            }
        }
    }

    # 3. Senaste 4771 för användaren
    Write-Host "`nSenaste Event 4771:"
    Get-WinEvent -ComputerName $DomainController `
        -FilterHashtable @{LogName='Security'; Id=4771; StartTime=(Get-Date).AddHours(-24)} `
        -ErrorAction SilentlyContinue |
        Where-Object { $_.Properties[0].Value -eq $SamAccountName } |
        Select-Object -First 5 TimeCreated,
            @{n='Code';e={'0x{0:X}' -f $_.Properties[6].Value}},
            @{n='ClientIP';e={$_.Properties[9].Value}} |
        Format-Table -AutoSize

    # 4. Klockavvikelse mot DC
    $skew = w32tm /stripchart /computer:$DomainController /samples:1 /dataonly 2>&1 |
        Select-String -Pattern 'd:'
    Write-Host "Klockavvikelse mot $DomainController`: $skew"
}

# Användning
Invoke-KerberosTriage -SamAccountName 'anna.andersson'

Utdata från den här funktionen räcker för att avgöra om ärendet är lösenord, låst konto, klockavvikelse, dubblett-SPN eller kryptografi. För 4771-koden 0x18 (fel lösenord), verifiera med användaren och gör en Windows LAPS-lookup om det gäller ett lokalt admin-lösenord. För 0x25, kör tidssync-fixen. För allt annat, dokumentera det i ärendet och eskalera till nivå 2 med utdata från triagen bifogad. Det är vad "documentation-loving sysadmin" faktiskt betyder i praktiken: inte att skriva Word-dokument, utan att göra rätt data lättillgänglig när nästa likadana ärende kommer in.

Vanliga frågor

Vad betyder Event ID 4771 i Windows Security-loggen?

Event 4771 loggas på domänkontrollanten varje gång Kerberos pre-authentication misslyckas. Fältet "Failure Code" avgör orsaken: 0x18 är felaktigt lösenord (vanligast), 0x25 är klockavvikelse och 0x12 är låst eller inaktiverat konto. Eventet visar också klientens IP-adress vilket gör att du kan spåra vilken enhet som skickade den felaktiga inloggningen.

Hur ser jag mina Kerberos-biljetter i Windows?

Kör klist i CMD eller PowerShell för att lista alla aktiva biljetter för den inloggade användaren. Kommandot klist tickets ger samma resultat, och klist purge raderar dem så att nya biljetter måste utfärdas. Vill du se biljetter för ett tjänstekonto måste du köra kommandot i den kontextens process, till exempel via PsExec -s för SYSTEM.

Hur ofta bör KRBTGT-lösenordet roteras?

Microsofts rekommendation är minst en gång per år, och alltid två gånger i följd efter en säkerhetsincident. Rotationerna måste ske med minst 10 timmars mellanrum (helst 24), annars invalideras alla aktiva TGT samtidigt och användarna tvingas logga om. Använd alltid Microsofts officiella New-KrbtgtKeys.ps1, aldrig ett hemmasnickrat script.

Varför faller Kerberos tillbaka till NTLM utan förvarning?

Den absolut vanligaste orsaken är duplicerade Service Principal Names. När två konton har samma SPN kan inte KDC välja vilket som ska utfärda Service Ticket, så klienten faller tyst tillbaka till NTLM. Kör setspn -X -F regelbundet för att hitta dubletter, och setspn -S istället för -A när du lägger till nya SPN.

Vad är skillnaden mellan constrained och resource-based delegation?

Constrained delegation (KCD) konfigureras på källservern via msDS-AllowedToDelegateTo och kräver domain admin-rättigheter att ändra. Resource-based (RBCD) konfigureras istället på måltjänsten via msDS-AllowedToActOnBehalfOfOtherIdentity, kan hanteras av tjänsteägaren utan domain admin, och fungerar över skogsgränser. RBCD är rätt val för alla nya installationer.

Vad orsakar felet "KDC_ERR_ETYPE_NOTSUPP"?

Felet betyder att KDC inte kan hitta någon krypteringstyp som både klienten, tjänstekontot och KDC-policyn stödjer. Vanligast är att tjänstekontots msDS-SupportedEncryptionTypes bara har RC4 medan domänpolicyn kräver AES efter Microsofts säkerhetsuppdateringar 2024. Sätt värdet till 24 (AES128 + AES256) och byt lösenord på kontot så att en AES-nyckel genereras.