Dela via

Felsökningsvägledning för Kerberos-autentisering

Den här guiden innehåller grundläggande begrepp som du kan följa när du felsöker Problem med Kerberos-autentisering.

Viktigt!

Den här artikeln innehåller allmänna riktlinjer. Du kan behöva anpassa de procedurer och exempel som visas här för att fungera för din specifika konfiguration.

Checklista för felsökning

Kerberos-protokollet förlitar sig på flera infrastrukturkomponenter och tjänster. Om någon av dessa komponenter eller tjänster inte är tillgängliga eller inte fungerar kan det uppstå autentiseringsproblem.

1. Kontrollera händelser och loggar

Kontrollera händelseloggarna för att få information om ett problem. Använd Händelseloggen för att granska säkerhets- och systemloggarna på de system som är inblandade i autentiseringsåtgärden.

  • Den autentiserande klienten
  • Målservern eller tjänsten
  • Domänkontrollanten

Leta särskilt efter händelser från källor som kan relatera till Kerberos-autentisering eller de tjänster som den förlitar sig på, till exempel följande källor:

  • Kerberos
  • Nyckeldistributionscenter (KDC)
  • LSA (LsaSrv)
  • Netlogon

På målservern kontrollerar du säkerhetsloggen om det finns felgranskningar. Sådana fel kan visa att Kerberos-protokollet används när ett autentiseringsfel inträffar.

Vissa händelser eller fel indikerar specifika problem. Om någon av de berörda datorerna registrerade någon av följande händelser eller fel väljer du länken för mer detaljerad felsökningsinformation.

Händelse eller fel Felsökningsinformation
Händelse-ID 4, det fel KERB_AP_ERR_MODIFIED Klienten kunde inte dekryptera tjänstbiljetten. Eftersom fler än ett problem kan orsaka det här felet kontrollerar du om det finns relaterade händelser. Den här strängen kan till exempel innebära att klient- och målserverklockorna inte är synkroniserade eller att SPN inte är unikt. I en miljö med flera domäner kanske namnet på tjänstkontot inte är unikt i skogen (eller andra betrodda skogar).
Mer information finns i Kerberos-klienten tog emot ett KRB_AP_ERR_MODIFIED fel från servern och Kerberos genererar KDC_ERR_S_PRINCIPAL_UNKNOWN eller KDC_ERR_PRINCIPAL_NOT_UNIQUE fel.
Händelse-ID 4, fel KERB_AP_ERR_SKEW Kontrollera att datorklockorna är synkroniserade
Händelse-ID 14 "Etype-fel som inte stöds" vid åtkomst till en resurs i en betrodd domän
Händelse-ID 16 eller händelse-ID 27 KDC-händelse-ID 16 eller 27 loggas om DES för Kerberos är inaktiverat
Händelse-ID 27 KDC-fel på Windows Server 2003-domänkontrollanter
Fel 1069 Tjänstinloggningar misslyckas på grund av felaktigt inställda SPN:
Händelse-ID 5719, fel 1311 eller fel 1355 Händelse-ID 5719, fel 1311 eller fel 1355 – Domänkontrollant eller domän hittades inte

Om du kontrollerar ett problem som du vet hur du åtgärdar kan du först åtgärda problemet och sedan försöka igen för att autentisera innan du fortsätter.

2. Kontrollera infrastrukturen

a. Kontrollera att klientappen och måltjänsten inte finns på samma dator

Om klientappen och måltjänsten är installerade på en enda dator inaktiveras Kerberos som standard. Om du inte kan installera klientprogrammet och måltjänsten på separata datorer måste du ändra specifika säkerhetsrelaterade inställningar i Windows. Dessutom kan du behöva ändra en registernyckel. Mer information om de problem som är relaterade till det här scenariot och de specifika inställningar som påverkar det finns i Felmeddelande när du försöker komma åt en server lokalt.

Om du har gjort några ändringar kan du försöka igen för att autentisera innan du fortsätter.

b) Kontrollera att klientdatorn, målservern och resursservrarna är anslutna till lämpliga domäner

Om det behövs ansluter du klientdatorn eller målservern till en lämplig domän. Försök sedan igen för att autentisera.

Kommentar

I det här sammanhanget är "lämpliga domäner" domäner i en enda skog eller inom en uppsättning skogar som har förtroenderelationer.

Punkt c Kontrollera hälsotillståndet för målservern och dess stödtjänster

Kontrollera att program- eller klientdelstjänster (till exempel webbtjänster) och serverdelstjänster (till exempel SQL Server-tjänsten) körs.

Kommentar

Du kan få ett meddelande som liknar " En tjänst har genererat fel 1069: Tjänsten startade inte på grund av ett inloggningsfel." Om du får det här meddelandet kan du läsa Service Logons Fail Due to Incorrectly Set SPN (Tjänstinloggning misslyckas på grund av felaktigt inställda SPN).

d. Kontrollera att rätt portar är tillgängliga

Kontrollera alla brandväggar (inklusive Windows-brandväggen på varje dator) mellan klientdatorn, domänkontrollanten och målservern. Kontrollera att trafik tillåts på följande portar.

Kommentar

I den här listan används server:klientport,serverportformat.

  • DHCP: 67 (UDP), 67 (UDP)
  • DNS: 49152 -65535 (TCP, UDP), 53 (TCP, UDP)
  • HTTPS, inklusive certifikatbaserad autentisering: 443 (TCP), 443 (TCP)
  • Kerberos: 49152 -65535 (TCP, UDP), 88 (TCP, UDP)
  • Ändring av Kerberos-lösenord: 49152 -65535 (TCP), 464 (TCP, UDP)
  • LDAP, inklusive DC-positionerare: 49152 -65535 (TCP, UDP), 389 (TCP, UDP)
  • LDAP SSL: 49152 -65535 (TCP), 636 (TCP)
  • SMB: 49152 -65535 (TCP, UDP), 445 (TCP)
  • RPC-slutpunktsmappare: 49152 -65535 (TCP), 135 (TCP)
  • RPC för LSA, SAM, NetLogon: 49152 -65535 (TCP), 49152-65535 (TCP)
  • W32Time: 49152 -65535 (UDP), 123 (UDP)

Om du gör ändringar i brandväggsinställningarna kan du försöka igen för att autentisera.

e. Kontrollera att domänkontrollanter är tillgängliga

När klienten försöker kontakta en tjänst eller ett program (kallas "målservern" måste både klienten och målservern ha en domänkontrollant för att underlätta autentisering, auktorisering och delegering.

Öppna en kommandotolk med förhöjda rättigheter på klientdatorn och kör sedan följande kommando:

nltest /dsgetdc:<DomainName> /force /kdc

Kommentar

I det här kommandot <representerar DomainName> namnet på domänen för den dator som du frågar från.

Kommandot nltest hämtar en lista över tillgängliga domänkontrollanter (även om listan kanske inte innehåller alla tillgängliga domänkontrollanter). Registrera de fullständigt kvalificerade domännamnen och IP-adresserna för dessa domänkontrollanter för användning i senare procedurer.

Om klienten eller målservern inte kan kontakta en domänkontrollant får du ett meddelande som liknar följande (ibland märkt "fel 1355"):

Antingen finns inte den angivna domänen eller så kunde den inte kontaktas.

Om du får det här meddelandet läser du Händelse-ID 5719, Fel 1311 eller Fel 1355 – Domänkontrollant eller domän hittades inte för mer felsökningsinformation. Annars kan du fortsätta med den här checklistan.

f. Kontrollera att DNS fungerar mellan klienten och målservern

Öppna ett administrativt kommandotolksfönster på klientdatorn och kör sedan följande kommando:

nslookup <TargetName>

Kommentar

I det här kommandot <representerar TargetName> NetBIOS-namnet på målservern.

nslookup Om kommandot matchar målservernamnet korrekt är DNS-konfigurationen korrekt. Om kommandot inte löser målservernamnet följer du dessa steg för att kontrollera klientdatorns nätverkskortkonfiguration:

  1. Kör följande kommando på klientdatorn:

    ipconfig /all

  2. I kommandoutdata avgör du vilket nätverkskort som används. Kontrollera följande adapterinställningar:

    • Klientens IP-adress

    • Nätmask

    • Standardgateway

    • Anslutningsspecifikt DNS-suffix

    • IP-adresser för DNS-server

      Registrera IP-adresserna och notera vilken DNS-server som föredras och vilken som är sekundär. Den här informationen är användbar för senare felsökning.

    Om någon av de här inställningarna är felaktiga kan du åtgärda dem eller kontakta DNS-administratören om du behöver hjälp. Om du har gjort några ändringar kör du nslookup <TargetName> igen.

Om DNS fortfarande inte fungerar korrekt följer du dessa steg:

  1. Kör följande kommando på klientdatorn:

    nslookup <ClientName> <DNSIPAddress>

    Kommentar

    I det här kommandot <representerar ClientName> NetBIOS-namnet på klientdatorn och <DNSIPAddress> representerar IP-adressen för en AV DE DNS-servrar som klienten är konfigurerad att använda. Börja med att använda IP-adressen för den önskade DNS-servern som du registrerade i föregående procedur. Om kommandot inte fungerar kan du försöka igen med hjälp av IP-adressen för klientens sekundära DNS-server.

    Om till exempel klientdatorns namn är "client1" och IP-adressen för klientens önskade DNS-server är 10.0.0.1 kör du följande kommando:

    nslookup client1 10.0.0.1

  2. Kör samma kommando från målservern. Det liknar nu följande kommando:

    nslookup <TargetName> <DNSIPAddress>

    Kommentar

    I det här kommandot <representerar TargetName> NetBIOS-namnet på målservern, och <DNSIPAddress> representerar IP-adressen för en av de DNS-servrar som målservern är konfigurerad att använda. Börja med att använda IP-adressen för den önskade DNS-servern som du registrerade i föregående procedur. Om kommandot inte fungerar första gången du kör det kan du försöka igen med hjälp av IP-adressen för målserverns sekundära DNS-server.

    Om målserverns namn till exempel är "WebServer1" och IP-adressen för målserverns önskade DNS-server är 10.0.0.1 kör du följande kommando:

    nslookup WebServer1 10.0.0.1

    I följande tabell sammanfattas de möjliga resultaten av nslookup frågorna och deras konsekvenser.

    Målfråga
    Lyckas    		 Målfråga
    Misslyckas
    Klientfråga
    Lyckas    		 Inget DNS-problem Problem som påverkar målet eller minst en DNS-server
    Klientfråga
    Misslyckas    		 Problem som påverkar klienten eller minst en DNS-server Problem som påverkar en eller flera DNS-servrar

Om frågeresultaten visar att du har ett DNS-problem kan du läsa följande artiklar för mer hjälp:

Om du löser DNS-problemet men Kerberos-problemet kvarstår kan du prova följande felsökningsmetoder.

g. Kontrollera att datorklockorna är synkroniserade

Klientdatorn eller målservern kan cachelagra biljetter för framtida användning. Varje biljett har dock tidsstämplar som avgör dess livslängd (TTL). Tjänsten Kerberos Key Distribution Center, som körs på domänkontrollanterna, anger tidsstämplarna.

Tidsskillnaden mellan domänkontrollanten och klientdatorn eller målservern måste vara mindre än fem minuter. Om klockorna inte synkroniseras kan Windows vanligtvis synkronisera om dem automatiskt. Det finns två fall där du kan behöva vidta åtgärder:

  • Klockorna är osynkroniserade med mer än 48 timmar.
  • Den osynkroniserade klockan använder inte en domänkontrollant i sin domän som en tidsserver, eller använder inte samma tidsserver som dessa domänkontrollanter gör.

För att lösa det här problemet måste den berörda datorn kontrollera nätverket igen efter tidsservrar och sedan synkronisera om sin egen klocka. Om du vill aktivera dessa åtgärder öppnar du ett administrativt kommandotolkfönster och kör sedan följande kommando:

w32tm /resync /computer:<Target> /rediscover

Kommentar

I det här kommandot <representerar Target> den dator som du konfigurerar. Alternativet /rediscover instruerar datorn att kontrollera nätverket efter nya eller uppdaterade tidskällor.

Mer information om de alternativ som är tillgängliga för kommandot finns i w32tmVerktyg och inställningar för Windows-tidstjänsten: Kommandoradsparametrar för W32Time.

Om du synkroniserar om klockorna, försök igen att autentisera.

h. Kontrollera Windows Update-status

Kontrollera att alla domänkontrollanter, klientdatorn och målservern alla har relevanta Windows-uppdateringar.

Om du har installerat några uppdateringar startar du om de berörda datorerna och försöker sedan igen för att autentisera.

i. Kontrollera programuppdateringsstatus

Kontrollera att klient- och serverprogrammen är uppdaterade på klientdatorn och målservern. Om du installerar några uppdateringar startar du om de berörda datorerna och försöker sedan igen för att autentisera.

j. Starta om datorerna

Om du inte redan har startat om klientdatorn, målservern eller domänkontrollanten startar du om dem nu. När datorerna har startats om försöker du igen för att autentisera.

Om infrastrukturen är OK och du fortfarande har problem fortsätter du till de mer avancerade felsökningsprocedurerna.

3. Samla in spårnings- och biljettdata

Följande procedurer använder det kostnadsfria verktyget Network Monitor . Ladda ned och installera verktyget på både klientdatorn och målservern. Ett exempel på hur du använder Network Monitor för att samla in spårningsdata och identifiera Kerberos-meddelanden finns i Kerberos-fel i nätverksinsamlingar.

a. Samla in samtidiga nätverksspårningar

Följ dessa steg på klientdatorn:

  1. Gör något av följande:

    • Starta om klientdatorn.
    • Logga ut från det konto som du använder för att felsöka och logga sedan in igen.
    • Stäng klientprogrammet och öppna det igen.

  2. Börja spåra. Gör detta genom att följa dessa steg:

    1. Välj Start och skriv sedan netmon.
    2. Högerklicka på Microsoft Network Monitor 3.4 i sökresultatet och välj sedan Kör som administratör (välj Ja i fönstret Kontroll av användarkonto).
    3. I Nätverksövervakaren väljer du Start.

  3. Öppna ett administrativt kommandotolkfönster och kör sedan följande kommandon i följd:

    ipconfig /flushdns
nbtstat -RR
klist purge
klist -li 0x3e7 purge

Följ dessa steg på målservern:

  1. Öppna Nätverksövervakaren som administratör och välj sedan Starta.

  2. Öppna ett administrativt kommandotolkfönster och kör sedan följande kommandon i följd:

    ipconfig /flushdns
nbtstat -RR
klist purge
klist -li 0x3e7 purge

Försök återskapa problemet och stoppa och spara sedan spårningarna på både klientdatorn och målservern. Det gör du genom att välja Stoppa i Nätverksövervakaren och sedan Spara som.

b) Registrera biljettinformation

När du har återskapat problemet och slutat spåra kontrollerar du Kerberos-biljetterna som genererades medan du spelade in spårningsdata. Kör följande kommando i kommandotolken på klientdatorn och på målservern:

klist tickets

Det här kommandot genererar en lista över biljetter. Du kan kopiera den här informationen till ett annat program (till exempel Anteckningar) så att du kan använda den i senare felsökningsprocedurer.

4. Kontrollera spårningsdata för Kerberos-meddelanden

Du kan använda Network Monitor för att granska, filtrera och söka efter data i insamlingsfiler. I synnerhet letar du efter händelser som är märkta med hjälp av "KerberosV5". Dessa händelser ger statusinformation. De kan också lista namn eller IP-adresser för domänkontrollanter som har kontaktats och tjänstens huvudnamn (SPN) för tjänsten som klienten försökte nå.

Händelsebeskrivningar som innehåller strängar som liknar följande är en del av vanliga Kerberos-funktioner:

  • KerberosV5:KRB_Error -KDC_ERR_PREAUTH_REQUIRED
  • KerberosV5: AS-begäran
  • KerberosV5:AS-svar
  • KerberosV5:TGS-begäran
  • KerberosV5:TGS-svar
  • KerberosV5: AP-begäran
  • KerberosV5:AP-svar

Kommentar

Du kan också använda Network Monitor för att kontrollera spårningsdata för biljettinformation i HTTP GET-begäranden. Om biljettinformationen saknas i GET-begäran uppstod ett problem med att använda Kerberos-autentisering.

Händelsebeskrivningar som innehåller strängar som liknar följande innebär att det finns ett problem. Följande lista innehåller några av de vanligaste felen. Om du ser någon av dessa strängar noterar du eventuella servernamn, IP-adresser och SPN:er för senare användning.

  • KDC_ERR_PRINCIPAL_NOT_UNIQUE eller KDC_ERR_S_PRINCIPAL_UNKNOWN. Det begärda SPN:t är associerat med fler än ett konto eller är inte associerat med något konto. Hjälp med att lösa dessa problem finns i Kerberos genererar felmeddelandena KDC_ERR_S_PRINCIPAL_UNKNOWN eller KDC_ERR_PRINCIPAL_NOT_UNIQUE.

  • KRB_AP_ERR_MODIFIED. Klienten kunde inte dekryptera tjänstbiljetten. Mer än ett problem kan orsaka det här felet. Granska spårningsdata för andra fel som medföljer KRB_AP_ERR_MODIFIED. Kontrollera händelseloggarna för händelse-ID 4 och andra relaterade händelser enligt beskrivningen i 1. Kontrollera händelser och loggar.

  • ERB_AP_ERR_SKEW. Klient- och målserverklockorna är inte synkroniserade. Mer information finns i Kontrollera att datorklockorna är synkroniserade.

  • KDC_ERR_ETYPE_NOTSUPP. En eller flera av de komponenter som ingår i autentiseringen använder en krypteringstyp som är inaktiverad för andra komponenter. Kontrollera händelseloggarna för mer information om vilka komponenter och vilka krypteringstyper som ingår, enligt beskrivningen i 1. Kontrollera händelser och loggar.

Kända problem och lösningar

HTTP 400 – Problem med felaktig begäran (begärandehuvudet är för långt)

Om en användare tillhör ett stort antal grupper (till exempel fler än 1 000 grupper) kan Kerberos neka användaren åtkomst eftersom begäran inte bearbetas korrekt. Mer information om det här problemet finns i följande artiklar:

Problem med tjänster

Tjänstproblem omfattar vanligtvis SPN och tjänstkontot. SPN kan till exempel vara felaktigt, saknas, konfigurerats för det felaktiga kontot eller konfigurerats för mer än ett konto. Felsökningschecklistan i den här artikeln, som nämner a. Samla in samtidiga nätverksspårningar, finns tidigare i artikeln. Om du redan har fastställt ett vanligt SPN-problem kan du läsa följande artiklar:

Problem med enkel inloggning (SSO)

Enkel inloggning är en autentiseringsmetod som gör det möjligt för användare att logga in med en uppsättning autentiseringsuppgifter till flera system eller program i ett enda intranät. För att fungera korrekt måste både måltjänsten (eller klientdelskomponenten i måltjänsten) och klienten ha rätt inställningar. Information om hur du felsöker de här inställningarna finns i Felsöka problem med enkel inloggning med Kerberos.

Delegeringsproblem

När måltjänsten har separata klientdels- och serverdelskomponenter kan Kerberos delegera klientautentiseringsuppgifter (inklusive åtkomstbehörigheter) till ett tjänstkonto. Kort sagt får klienten tillgång till frontend-tjänsten, och sedan får frontend-tjänsten tillgång till backend-tjänsten på klientens vägnar.

Kerberos stöder tre typer av delegering:

  • Obegränsad delegering. När klienten har åtkomst till klientdelstjänsten kan klientdelstjänsten komma åt andra tjänster för klientens räkning. Den här konfigurationen är den enklaste att implementera, men är också den minst säkra. Vi rekommenderar inte att obegränsad delegering inte rekommenderas eftersom den inte begränsar vilka tjänster som det autentiserade kontot kan interagera med.
  • Begränsad delegering. Klientdelstjänsten har en lista över tjänster som den kan komma åt för en klients räkning.
  • Resursbaserad begränsad delegering (RBCD). Serverdelstjänsten har en lista över tillåtna tjänster som kan begära åtkomst till serverdelstjänsten för en klients räkning.

Kommentar

Om du får ett problem när du använder begränsad delegering tillsammans med CIFS, se artikeln Begränsad delegering för CIFS misslyckas med ACCESS_DENIED-felet.

Viktigt!

  • Konfigurera inte begränsad delegering och RBCD på samma uppsättning frontend- och backend-servrar.

    Begränsad delegering och RBCD är olika konfigurationer och de är ömsesidigt uteslutande. När en klientdelstjänst begär ett ärende till en serverdelstjänst kontrollerar KDC först klientdelstjänsten för begränsad delegering. Om begränsad delegering inte har konfigurerats för klientdelstjänsten kontrollerar KDC serverdelstjänsten för resursbaserad begränsad delegering. På grund av den här sekvensen har begränsad delegering företräde framför resursbaserad delegering.

  • Microsoft Edge stöder som standard inte obegränsad delegering. Om du använder obegränsad delegering kan du läsa Kerberos obegränsad dubbelhoppsautentisering med Microsoft Edge (Chromium) för mer information om den konfiguration som du behöver.

  • Obegränsad delegering rekommenderas inte eftersom det inte begränsar vilka tjänster det autentiserade kontot kan interagera med.

Topologityper som stöds

De olika delegeringstyperna ställer olika krav på topologin. I följande tabell visas tre vanliga typer av topologi och vilka typer av delegering (om några) som stöds för varje typ.

Topologityp Obegränsad delegering Begränsad delegering RBCD
Alla tjänster finns i en enda domän Stöds (rekommenderas inte) Understödd Understödd
Front-end- och back-end-tjänster finns i olika domäner Stöds (rekommenderas inte) Stöds inte Understödd
Frontend- och backend-tjänster finns i olika (betrodda) skogsstrukturer Stöds (rekommenderas inte) Stöds inte Stöd för*

* Kontrollera att front-end-tjänstens tjänstkonto kan autentiseras över förtroendet mot den betrodda domänkontrollanten.

Felsöka specifika delegeringstyper

Konfigurationsinformationen för delegering varierar beroende på vilken typ av delegering du använder och vilken typ av konto som klientdelstjänsten använder. Mer information om hur du felsöker delegeringsproblem finns i följande artiklar efter behov:

Använda ett testscenario för logganalys för att felsöka Kerberos-autentisering

Avancerad Kerberos-testning och felsökning finns i Använda ett testscenario för logganalys för att felsöka Kerberos-autentisering.