Felsöka Kerberos-fel i Internet Explorer

  • Artikel

Den här artikeln hjälper dig att isolera och åtgärda orsakerna till olika fel när du kommer åt webbplatser som är konfigurerade för att använda Kerberos-autentisering i Internet Explorer. Antalet potentiella problem är nästan lika stort som antalet verktyg som är tillgängliga för att lösa dem.

Vanligt symptom när Kerberos misslyckas

Du försöker komma åt en webbplats där Windows Integrated Authenticated har konfigurerats och du förväntar dig att använda Kerberos-autentiseringsprotokollet. I den här situationen uppmanas du omedelbart att ange autentiseringsuppgifter i webbläsaren på följande sätt:

Skärmbild av uppmaningen om autentiseringsuppgifter.

Även om du anger ett giltigt användarnamn och lösenord uppmanas du igen (totalt tre frågor). Sedan visas en skärm som anger att du inte har behörighet att komma åt den önskade resursen. Skärmen visar en HTTP 401-statuskod som liknar följande fel:

Inte auktoriserad
HTTP-fel 401. Den begärda resursen kräver användarautentisering.

Skärmbild av H T T P-fel 401.

På Microsoft Internet Information Services-servern (IIS) innehåller webbplatsloggarna begäranden som slutar med statuskoden 401.2, till exempel följande logg:

#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) cs(Referer) sc-status sc-substatus sc-win32-status time-taken  
DateTime IP GET /whoami.aspx - 80 – IP Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+10.0;+WOW64;+Trident/7.0;+.NET4.0C;+.NET4.0E;+.NET+CLR+2.0.50727;+.NET+CLR+3.0.30729;+.NET+CLR+3.5.30729) - 401 2 5 1270  
DateTime IP GET /whoami.aspx - 80 - IP Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+10.0;+WOW64;+Trident/7.0;+.NET4.0C;+.NET4.0E;+.NET+CLR+2.0.50727;+.NET+CLR+3.0.30729;+.NET+CLR+3.5.30729) - 401 2 5 8

Eller så visar skärmen statuskoden 401.1, till exempel följande logg:

#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) cs(Referer) sc-status sc-substatus sc-win32-status time-taken  
DateTime IP GET /whoami.aspx - 80 - IP Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+10.0;+WOW64;+Trident/7.0;+.NET4.0C;+.NET4.0E;+.NET+CLR+2.0.50727;+.NET+CLR+3.0.30729;+.NET+CLR+3.5.30729) - 401 2 5 105  
DateTime IP GET /whoami.aspx - 80 - IP Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+10.0;+WOW64;+Trident/7.0;+.NET4.0C;+.NET4.0E;+.NET+CLR+2.0.50727;+.NET+CLR+3.0.30729;+.NET+CLR+3.5.30729) - 401 1 2148074245 18

Avgöra om Kerberos används

När du felsöker Kerberos-autentiseringsfel rekommenderar vi att du förenklar konfigurationen till ett minimum. En klient, en server och en IIS-plats som körs på standardporten. Dessutom kan du följa några grundläggande felsökningssteg. Använd till exempel en testsida för att verifiera den autentiseringsmetod som används. Om du använder ASP.NET kan du skapa den här testsidan för ASP.NET autentisering.

Om du använder klassisk ASP kan du använda följande Testkerb.asp sida:

<%
    authType=UCase(Request.ServerVariables("AUTH_TYPE"))
    authHeader=Request.ServerVariables("HTTP_AUTHORIZATION")
    response.write " Authentication Method : " & authType & "<BR>"
    LenAuthHeader = len(authHeader)
    response.write " Protocol : "
    if Len(authType ) =0 then response.write " Anonymous" else if authType<>"NEGOTIATE" then response.write authType else if LenAuthHeader>1000 then response.write "Kerberos" else response.write  "NTLM"
%>

Du kan också använda följande verktyg för att avgöra om Kerberos används:

  • Spelman
  • HttpWatch
  • Nätverksövervakare
  • Utvecklarverktygen i webbläsaren

Mer information om hur sådana spårningar kan genereras finns i spårning på klientsidan.

När Kerberos används är begäran som skickas av klienten stor (mer än 2 000 byte), eftersom HTTP_AUTHORIZATION rubriken innehåller Kerberos-biljetten. Följande begäran gäller en sida som använder Kerberos-baserad Windows-autentisering för att autentisera inkommande användare. Storleken på GET-begäran är mer än 4 000 byte.

Skärmbild av begäranden som är mer än 4 000 byte.

Om NTLM-handskakningen används blir begäran mycket mindre. Följande avbildning på klientsidan visar en NTLM-autentiseringsbegäran. GET-begäran är mycket mindre (mindre än 1 400 byte).

Skärmbild av begäranden som är mindre än 1 400 byte.

När du har fastställt att Kerberos-autentiseringen misslyckas kontrollerar du vart och ett av följande objekt i den angivna ordningen.

Saker att kontrollera om Kerberos-autentisering misslyckas

I följande avsnitt beskrivs de saker som du kan använda för att kontrollera om Kerberos-autentiseringen misslyckas.

Finns klienten och servern i samma domän

Användning av Kerberos kräver en domän eftersom en Kerberos-biljett levereras av domänkontrollanten (DC). Avancerade scenarier är också möjliga där:

  • Klienten och servern finns inte i samma domän, utan i två domäner i samma skog.
  • Klienten och servern finns i två olika skogar.

Dessa möjliga scenarier beskrivs i avsnittet Varför misslyckas Kerberos-delegering mellan mina två skogar, även om det brukade fungera i den här artikeln.

Har IIS konfigurerats för att använda integrerad autentisering

Skärmbild av inställningen Windows-autentisering.

Är integrerad autentisering aktiverat i Internet Explorer

Välj alternativet Aktivera integrerad Windows-autentisering på sidan Internetalternativ.

Matchar url:en som används till en säkerhetszon för vilken autentiseringsuppgifter kan skickas

Kör alltid den här kontrollen för följande webbplatser:

  • Webbplatser som matchas med zonen Lokalt intranät i webbläsaren.
  • Platser i zonen Betrodda platser.

Du kan kontrollera i vilken zon webbläsaren bestämmer sig för att inkludera webbplatsen. Det gör du genom att öppna Menyn Arkiv i Internet Explorer och sedan välja Egenskaper. Fönstret Egenskaper visar zonen där webbläsaren har valt att inkludera den webbplats som du bläddrar till.

Kontrollera zonen i Egenskaper för Internet Explorer.

Du kan kontrollera om zonen där webbplatsen ingår tillåter automatisk inloggning. Det gör du genom att öppna menyn Internetalternativ i Internet Explorer och välja fliken Säkerhet . När du har valt önskad zon väljer du knappen Anpassad nivå för att visa inställningarna och kontrollerar att Automatisk inloggning har valts. (Normalt är den här funktionen aktiverad som standard för zonerna Intranät och Betrodda platser).

Kontrollera om automatisk inloggning har valts.

Obs!

Även via den här konfigurationen är inte vanligt (eftersom det kräver att klienten har åtkomst till en domänkontrollant) kan Kerberos användas för en URL i Internetzonen. I det här fallet, om inte standardinställningarna ändras, kommer webbläsaren alltid att fråga användaren om autentiseringsuppgifter. Kerberos-delegering fungerar inte i Internetzonen. Det beror på att Internet Explorer endast tillåter Kerberos-delegering för en URL i zonerna Intranät och Betrodda platser.

Är IIS-servern konfigurerad för att skicka RUBRIKEN WWW-Authenticate: Negotiate

Kontrollera om IIS-servern har konfigurerats för att skicka rubriken WWW-Authenticate: Negotiate.

Om IIS inte skickar det här huvudet använder du IIS Manager-konsolen för att ange negotiate-huvudet via konfigurationsegenskapen NTAuthenticationProviders . Mer information finns i Leverantörer av <>Windows-autentisering. Du kan komma åt konsolen via inställningen Providers för Windows-autentiseringsinformationen i IIS-hanteraren.

Providers-inställningar i autentisering.

Obs!

Som standard har egenskapen NTAuthenticationProviders inte angetts . Detta gör att IIS skickar både Negotiate- och Windows NT LAN Manager-huvuden (NTLM).

Är klienten och servern installerade på samma dator?

Kerberos är som standard inte aktiverat i den här konfigurationen. Om du vill ändra det här beteendet måste du ange registernyckeln DisableLoopBackCheck . Mer information finns i KB-926642.

Kan klienten få en Kerberos-biljett

Du kan använda KLIST-verktyget (Kerberos List) för att verifiera att klientdatorn kan hämta en Kerberos-biljett för ett visst namn på tjänstens huvudnamn. I det här exemplet är tjänstens huvudnamn (SPN) http/web-server.

Obs!

KLIST är ett internt Windows-verktyg sedan Windows Server 2008 för operativsystem på serversidan och Windows 7 Service Pack 1 för operativsystem på klientsidan.

Använd KLIST-verktyget för att kontrollera att klientdatorn kan hämta en Kerberos-biljett för ett visst namn på tjänstens huvudnamn.

När Kerberos-biljettbegäran misslyckas används inte Kerberos-autentisering. NTLM-återställning kan inträffa eftersom det begärda SPN:et är okänt för domänkontrollanten. Om domänkontrollanten inte kan nås sker ingen NTLM-återställning.

Information om hur du deklarerar ett SPN finns i följande artikel:

Så här använder du SPN när du konfigurerar webbprogram som finns på Internet Information Services.

Använder webbservern en annan port än standard (80)

Internet Explorer innehåller som standard inte portnummerinformationen i det SPN som används för att begära en Kerberos-biljett. Det kan vara ett problem om du använder IIS för att vara värd för flera webbplatser under olika portar och identiteter. I den här konfigurationen kan Kerberos-autentisering endast fungera för specifika platser även om alla SPN har deklarerats korrekt i Active Directory. Du måste ange registervärdet för FEATURE_INCLUDE_PORT_IN_SPN_KB908209 att åtgärda problemet. (Information om hur du deklarerar nyckeln finns i avsnittet Internet Explorer-funktionsnycklar .) Den här inställningen tvingar Internet Explorer att inkludera portnumret i det SPN som används för att begära Kerberos-biljetten.

Använder Internet Explorer det förväntade SPN:t?

Om en webbplats nås med hjälp av ett aliasnamn (CNAME) använder Internet Explorer först DNS-matchning för att matcha aliasnamnet med ett datornamn (ANAME). Datornamnet används sedan för att skapa SPN och begära en Kerberos-biljett. Även om URL:en som anges i Internet Explorer-adressfältet är http://MYWEBSITEbegär Internet Explorer ett SPN för HTTP/MYSERVER om MYWEBSITE är ett alias (CNAME) för MYSERVER (ANAME). Du kan ändra det här beteendet med hjälp av registernyckeln FEATURE_USE_CNAME_FOR_SPN_KB911149 . (Information om hur du deklarerar nyckeln finns i Internet Explorer-funktionsnycklarna .)

En nätverksövervakarspårning är en bra metod för att kontrollera spN som är associerat med Kerberos-biljetten, som i följande exempel:

- Http: Request, GET /whoami.aspx , Using GSS-API Authorization
    Command: GET
  - URI: /whoami.aspx
     Location: /whoami.aspx
    ProtocolVersion: HTTP/1.1
    Accept:  image/gif, image/jpeg, image/pjpeg, application/x-ms-application, application/xaml+xml, application/x-ms-xbap, */*
    Accept-Language:  en-US,en;q=0.5
    UserAgent:  Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 10.0; WOW64; Trident/7.0; .NET4.0C; .NET4.0E; .NET CLR 2.0.50727; .NET CLR 3.0.30729; .NET CLR 3.5.30729)
    Accept-Encoding:  gzip, deflate
    Host:  web-server
    Connection:  Keep-Alive
  - Authorization: Negotiate
   - Authorization:  Negotiate YIILcAYGKwYBBQUCoIILZDCCC2CgMDAuBgkqhkiC9xIBAgIGCSqGSIb3EgECAgYKKwYBBAGCNwICHgYKKwYBBAGCNwICCqKCCyoEggsmYIILIgYJKoZIhvcSAQICAQBuggsRMIILDaADAgEFoQMCAQ6iBwMFACAAAACjggRtYYIEaTCCBGWgAwIBBaEOGwxPREVTU1kuTE9DQUyiKjAooAMCAQKhITAfGwRIVFRQG
      WhiteSpace:  
    - NegotiateAuthorization:
       Scheme: Negotiate
     - GssAPI: 0x1
      - InitialContextToken:
       + ApplicationHeader:
       + ThisMech: SpnegoToken (1.3.6.1.5.5.2)
       - InnerContextToken: 0x1
        - SpnegoToken: 0x1
         + ChoiceTag:
         - NegTokenInit:
          + SequenceHeader:
          + Tag0:
          + MechTypes: Prefer MsKerberosToken (1.2.840.48018.1.2.2)
          + Tag2:
          + OctetStringHeader:
          - MechToken: 0x1
           - MsKerberosToken: 0x1
            - KerberosInitToken:
             + ApplicationHeader:
             + ThisMech: KerberosToken (1.2.840.113554.1.2.2)
             - InnerContextToken: 0x1
              - KerberosToken: 0x1
                 TokId: Krb5ApReq (0x100)
               - ApReq: KRB_AP_REQ (14)
                + ApplicationTag:
                + SequenceHeader:
                + Tag0:
                + PvNo: 5
                + Tag1:
                + MsgType: KRB_AP_REQ (14)
                + Tag2: 0x1
                + ApOptions:
                + Tag3:
                - Ticket: Realm: ODESSY.LOCAL, Sname: HTTP/web-server.odessy.local
                 + ApplicationTag:
                 + SequenceHeader:
                 + Tag0:
                 + TktVno: 5
                 + Tag1:
                 + Realm: ODESSY.LOCAL
                 + Tag2: 0x1
                 + Sname: HTTP/web-server.odessy.local
                 + Tag3: 0x1
                 + EncPart:
                + Tag4:

Matchar programpoolsidentiteten det konto som är associerat med SPN

När en Kerberos-biljett skickas från Internet Explorer till en IIS-server krypteras biljetten med hjälp av en privat nyckel. Den privata nyckeln är en hash för lösenordet som används för användarkontot som är associerat med SPN. Därför kan endast ett program som körs under det här kontot avkoda biljetten.

Följande procedur är en sammanfattning av Kerberos-autentiseringsalgoritmen:

  1. Internet Explorer avgör ett SPN med hjälp av den URL som anges i adressfältet.

  2. SPN skickas via ett SSPI-API (Security Support Provider Interface) (InitializeSecurityContext) till systemkomponenten som ansvarar för Windows-säkerhet (LSASS-processen (Local Security Authority Subsystem Service). I det här skedet kan du se att Internet Explorer-koden inte implementerar någon kod för att skapa Kerberos-biljetten. Internet Explorer anropar endast SSPI-API:er.

  3. LSASS använder det SPN som skickas för att begära en Kerberos-biljett till en domänkontrollant. Om domänkontrollanten kan hantera begäran (känt SPN) skapar den en Kerberos-biljett. Sedan krypteras biljetten med hjälp av en nyckel som är konstruerad från hashen för användarkontolösenordet för det konto som är associerat med SPN. LSASS skickar sedan biljetten till klienten. När det gäller Internet Explorer är biljetten en täckande blob.

  4. Internet Explorer kapslar in Kerberos-biljetten som tillhandahålls av LSASS i Authorization: Negotiate rubriken och skickar sedan ärendet till IIS-servern.

  5. IIS hanterar begäran och dirigerar den till rätt programpool med hjälp av det angivna värdhuvudet.

  6. Programpoolen försöker dekryptera biljetten med hjälp av SSPI/LSASS-API:er och genom att följa dessa villkor:

    • Om biljetten kan dekrypteras lyckas Kerberos-autentiseringen. Alla tjänster som är associerade med biljetten (personifiering, delegering om biljetten tillåter det och så vidare) är tillgängliga.

    • Om biljetten inte kan dekrypteras returneras ett Kerberos-fel (KRB_AP_ERR_MODIFIED). Det här felet är ett allmänt fel som anger att biljetten ändrades på något sätt under transporten. Så biljetten kan inte dekrypteras. Det här felet loggas också i Windows-händelseloggarna.

Om du inte uttryckligen deklarerar ett SPN fungerar Kerberos-autentisering endast under någon av följande programpoolsidentiteter:

  • Nätverkstjänst
  • ApplicationPoolIdentity
  • Ett annat systemkonto, till exempel LOCALSYSTEM eller LOCALSERVICE

Men de här identiteterna rekommenderas inte eftersom de är en säkerhetsrisk. I det här fallet skapas Kerberos-biljetten med hjälp av ett standard-SPN som skapas i Active Directory när en dator (i det här fallet servern som IIS körs på) läggs till i domänen. Det här standard-SPN:et är associerat med datorkontot. Under IIS mappar datorkontot till Nätverkstjänst eller ApplicationPoolIdentity.

Om programpoolen måste använda en annan identitet än de listade identiteterna deklarerar du ett SPN (med SETSPN). Associera den sedan med det konto som används för din programpoolsidentitet. Ett vanligt misstag är att skapa liknande SPN:er som har olika konton. Till exempel:

  • SETSPN http/mywebsite UserAppPool1
  • SETSPN http/mywebsite UserAppPool2

Den här konfigurationen fungerar inte eftersom det inte finns något deterministiskt sätt att veta om Kerberos-biljetten för HTTP/mywebsite SPN krypteras med hjälp av lösenordet UserAppPool1 eller UserAppPool2. Den här konfigurationen genererar vanligtvis KRB_AP_ERR_MODIFIED fel. Om du vill ta reda på om du befinner dig i det här felaktiga duplicerade SPN-scenariot använder du verktygen som beskrivs i följande artikel:

Varför du fortfarande kan ha duplicerade SPN:er i AD 2012 R2 och AD 2016

Från Och med Windows Server 2008 kan du även använda en uppdaterad version av SETSPN för Windows som gör det möjligt att identifiera duplicerade SPN med hjälp setspn –X av kommandot när du deklarerar ett nytt SPN för målkontot. Mer information finns i Setspn.

Vi rekommenderar också att du läser följande artiklar:

Misslyckas Kerberos-autentisering i IIS 7 och senare versioner trots att det fungerar i IIS 6

Autentisering i kernelläge är en funktion som introducerades i IIS 7. Det ger följande fördelar:

  • Prestandan ökar eftersom övergångar i kernelläge till användarläge inte längre görs.
  • Kerberos-biljettens avkodning görs med hjälp av datorkontot, inte programpoolens identitet. Med den här ändringen kan du ha flera programpooler som körs under olika identiteter utan att behöva deklarera SPN.

Varning

Om ett SPN har deklarerats för ett specifikt användarkonto (används även som programpoolsidentitet) kan autentisering i kernelläge inte dekryptera Kerberos-biljetten eftersom den använder datorkontot. Det här problemet är typiskt i webbgruppsscenarier. Det här scenariot deklarerar vanligtvis ett SPN för det (virtuella) NLB-värdnamnet. Använd någon av följande metoder för att förhindra det här problemet:

  • Inaktivera autentisering i kernelläge. (Rekommenderas inte ur prestandasynpunkt.)
  • Ange useAppPoolCredentials till true. Detta behåller prestandafördelarna med autentisering i kernelläge, samtidigt som Kerberos-biljetten kan avkodas under programpoolens identitet. Mer information finns i Autentisering med säkerhetsautentisering<>.

Varför misslyckas delegeringen även om Kerberos-autentisering fungerar

I det här scenariot kontrollerar du följande:

  • Internet Explorer-zonen som används för URL:en. Kerberos-delegering tillåts endast för zonerna Intranät och Betrodda platser. (Med andra ord anger ISC_REQ_DELEGATE Internet Explorer flaggan när den anropar InitializeSecurityContext endast om zonen som bestäms antingen är Intranät eller Betrodda platser.)

  • Användarkontot för IIS-programpoolen som är värd för din webbplats måste ha flaggan Betrodd för delegering inställd i Active Directory.

Om delegeringen fortfarande misslyckas bör du överväga att använda Kerberos-Configuration Manager för IIS. Med det här verktyget kan du diagnostisera och åtgärda IIS-konfigurationer för Kerberos-autentisering och för associerade SPN på målkontona. Mer information finns i README.md. Du kan ladda ned verktyget härifrån.

Varför får jag dåliga prestanda när jag använder Kerberos-autentisering

Kerberos är ett begäransbaserat autentiseringsprotokoll i äldre versioner av Windows Server, till exempel Windows Server 2008 SP2 och Windows Server 2008 R2. Det innebär att klienten måste skicka Kerberos-biljetten (som kan vara en ganska stor blob) med varje begäran som görs till servern. Det strider mot autentiseringsmetoder som förlitar sig på NTLM. Som standard är NTLM sessionsbaserat. Det innebär att webbläsaren endast autentiserar en begäran när den öppnar TCP-anslutningen till servern. Varje efterföljande begäran om samma TCP-anslutning kräver inte längre autentisering för att begäran ska accepteras. I nyare versioner av IIS, från Windows 2012 R2 och senare, är Kerberos också sessionsbaserat. Endast den första begäran om en ny TCP-anslutning måste autentiseras av servern. Efterföljande begäranden behöver inte innehålla en Kerberos-biljett.

Du kan ändra det här beteendet med hjälp av egenskapen authPersistNonNTLM om du kör under IIS 7 och senare versioner. Om egenskapen är inställd på true blir Kerberos sessionsbaserad. Annars kommer den att vara begärandebaserad. Det kommer att få sämre prestanda eftersom vi måste inkludera en större mängd data som ska skickas till servern varje gång. Mer information finns i Request based versus Session based Kerberos Authentication (or the AuthPersistNonNTLM parameter).

Obs!

Det kanske inte är en bra idé att blint använda Kerberos-autentisering på alla objekt. Att använda Kerberos-autentisering för att hämta hundratals bilder med hjälp av villkorsstyrda GET-begäranden som sannolikt genererar 304 inte ändrade svar är som att försöka döda en fluga med hjälp av en hammare. En sådan metod kommer inte heller att ge uppenbara säkerhetsvinster.

Varför misslyckas Kerberos-delegeringen mellan mina två skogar även om den brukade fungera

Tänk dig följande situation:

  • Användarna av ditt program finns i en domän i skog A.
  • Programmet finns i en domän i skog B.
  • Du har en förtroenderelation mellan skogarna.

I det här scenariot kan Kerberos-delegeringen sluta fungera, även om den tidigare fungerade och du inte har gjort några ändringar i skogar eller domäner. Kerberos-autentisering fungerar fortfarande i det här scenariot. Det är bara delegeringen som misslyckas.

Det här problemet kan inträffa på grund av säkerhetsuppdateringar till Windows Server som släpptes av Microsoft i mars 2019 och juli 2019. Dessa uppdateringar inaktiverade obegränsad Kerberos-delegering (möjligheten att delegera en Kerberos-token från ett program till en serverdelstjänst) över skogsgränser för alla nya och befintliga förtroenden. Mer information finns i Uppdateringar till TGT-delegering över inkommande förtroenden i Windows Server.

Internet Explorer-funktionsnycklar

Dessa nycklar är registernycklar som aktiverar eller inaktiverar vissa funktioner i webbläsaren. Nycklarna finns på följande registerplatser:

  • HKEY_USERS\<UserSID>\Software\Microsoft\Internet Explorer\Main\FeatureControl – om det definieras på användarnivå
  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\ – om det definieras på datornivå

Funktionsnycklar bör skapas på någon av dessa platser, beroende på om du vill aktivera eller inaktivera funktionen:

  • för alla användare på datorn
  • endast för ett specifikt konto

Dessa nycklar ska skapas under respektive sökväg. Inuti nyckeln ska ett DWORD-värde med namnet iexplorer.exe deklareras. Standardvärdet för varje nyckel ska vara antingen sant eller falskt, beroende på den önskade inställningen för funktionen. Som standard är värdet för båda funktionsnycklarna FEATURE_INCLUDE_PORT_IN_SPN_KB908209 och FEATURE_USE_CNAME_FOR_SPN_KB911149, falskt. Här är ett exempel på en export av registret genom att ändra funktionsnyckeln till att inkludera portnummer i Kerberos-biljetten till sant:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_INCLUDE_PORT_IN_SPN_KB908209]
"iexplore.exe"=dword:00000001

Mer information

Felsökning av diagnostiksidor för Windows-integrerad autentisering