Kerberos-fouten in Internet Explorer oplossen

Dit artikel helpt u bij het isoleren en oplossen van de oorzaken van verschillende fouten bij het openen van websites die zijn geconfigureerd voor het gebruik van Kerberos-verificatie in Internet Explorer. Het aantal potentiële problemen is bijna net zo groot als het aantal hulpprogramma's dat beschikbaar is om deze op te lossen.

Veelvoorkomend symptoom wanneer Kerberos mislukt

U probeert toegang te krijgen tot een website waarop Windows Integrated Authenticated is geconfigureerd en u verwacht het Kerberos-verificatieprotocol te gebruiken. In dit geval vraagt uw browser u onmiddellijk om referenties, als volgt:

Hoewel u een geldige gebruikersnaam en wachtwoord invoert, wordt u opnieuw gevraagd (in totaal drie prompts). Vervolgens ziet u een scherm dat aangeeft dat u geen toegang hebt tot de gewenste resource. In het scherm wordt een HTTP 401-statuscode weergegeven die lijkt op de volgende fout:

Niet geautoriseerd
HTTP-fout 401. Voor de aangevraagde resource is gebruikersverificatie vereist.

Op de Microsoft Internet Information Services (IIS)-server bevatten de websitelogboeken aanvragen die eindigen op een 401.2-statuscode, zoals het volgende logboek:

#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

Of het scherm geeft een 401.1-statuscode weer, zoals het volgende logboek:

#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

Bepalen of Kerberos wordt gebruikt

Wanneer u kerberos-verificatiefouten oplost, wordt u aangeraden de configuratie tot het minimum te vereenvoudigen. Dat wil gezegd, één client, één server en één IIS-site die wordt uitgevoerd op de standaardpoort. Daarnaast kunt u enkele eenvoudige stappen voor probleemoplossing volgen. Gebruik bijvoorbeeld een testpagina om de gebruikte verificatiemethode te controleren. Als u ASP.NET gebruikt, kunt u deze ASP.NET verificatietestpagina maken.

Als u klassieke ASP gebruikt, kunt u de volgende Testkerb.asp pagina gebruiken:

<%
    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"
%>

U kunt ook de volgende hulpprogramma's gebruiken om te bepalen of Kerberos wordt gebruikt:

• Fiddler
• HttpWatch
• Netwerkmonitor
• De ontwikkelhulpprogramma's in uw browser

Zie tracering aan de clientzijde voor meer informatie over hoe dergelijke traceringen kunnen worden gegenereerd.

Wanneer Kerberos wordt gebruikt, is de aanvraag die door de client wordt verzonden groot (meer dan 2000 bytes), omdat de HTTP_AUTHORIZATION header het Kerberos-ticket bevat. De volgende aanvraag is voor een pagina die gebruikmaakt van Op Kerberos gebaseerde Windows-verificatie om binnenkomende gebruikers te verifiëren. De grootte van de GET-aanvraag is meer dan 4000 bytes.

Als de NTLM-handshake wordt gebruikt, is de aanvraag veel kleiner. De volgende opname aan de clientzijde toont een NTLM-verificatieaanvraag. De GET-aanvraag is veel kleiner (minder dan 1400 bytes).

Nadat u hebt vastgesteld dat Kerberos-verificatie mislukt, controleert u elk van de volgende items in de opgegeven volgorde.

Dingen om te controleren of Kerberos-verificatie mislukt

In de volgende secties worden de dingen beschreven die u kunt gebruiken om te controleren of Kerberos-verificatie mislukt.

Bevinden de client en server zich in hetzelfde domein?

Voor het gebruik van Kerberos is een domein vereist, omdat een Kerberos-ticket wordt geleverd door de domeincontroller (DC). Geavanceerde scenario's zijn ook mogelijk wanneer:

• De client en server bevinden zich niet in hetzelfde domein, maar in twee domeinen van hetzelfde forest.
• De client en server bevinden zich in twee verschillende forests.

Deze mogelijke scenario's worden besproken in de sectie Waarom mislukt kerberos-delegering tussen mijn twee forests, hoewel het vroeger werkte in dit artikel.

Is IIS geconfigureerd voor het gebruik van geïntegreerde verificatie

Is geïntegreerde verificatie ingeschakeld in Internet Explorer

Wordt de gebruikte URL omgezet in een beveiligingszone waarvoor referenties kunnen worden verzonden?

Voer deze controle altijd uit voor de volgende sites:

• Sites die zijn gekoppeld aan de zone Lokaal intranet van de browser.
• Sites in de zone Vertrouwde sites.

U kunt controleren in welke zone uw browser besluit de site op te nemen. Open hiervoor het menu Bestand van Internet Explorer en selecteer vervolgens Eigenschappen. In het venster Eigenschappen wordt de zone weergegeven waarin de browser heeft besloten de site op te nemen waarnaar u bladert.

U kunt controleren of automatische aanmelding is toegestaan in de zone waarin de site is opgenomen. Open hiervoor het menu Internetopties van Internet Explorer en selecteer het tabblad Beveiliging . Nadat u de gewenste zone hebt geselecteerd, selecteert u de knop Aangepast niveau om de instellingen weer te geven en controleert u of Automatisch aanmelden is geselecteerd. (Normaal gesproken is deze functie standaard ingeschakeld voor de zones Intranet en Vertrouwde sites).

Is de IIS-server geconfigureerd voor het verzenden van de header WWW-Authenticate: Negotiate

Als IIS deze header niet verzendt, gebruikt u de IIS Manager-console om de header Negotiate via de configuratie-eigenschap NTAuthenticationProviders in te stellen. Zie Providers van Windows-verificatieproviders> voor <meer informatie. U hebt toegang tot de console via de instelling Providers van de Details van Windows-verificatie in IIS-beheer.

Zijn de client en server op dezelfde computer geïnstalleerd

Kerberos is standaard niet ingeschakeld in deze configuratie. Als u dit gedrag wilt wijzigen, moet u de DisableLoopBackCheck registersleutel instellen. Zie KB 926642 voor meer informatie.

Kan de client een Kerberos-ticket krijgen

U kunt het hulpprogramma Kerberos List (KLIST) gebruiken om te controleren of de clientcomputer een Kerberos-ticket kan verkrijgen voor een bepaalde service-principalnaam. In dit voorbeeld is de service-principal name (SPN) http/web-server.

Wanneer de Kerberos-ticketaanvraag mislukt, wordt Kerberos-verificatie niet gebruikt. NTLM-terugval kan optreden, omdat de SPN die is aangevraagd onbekend is bij de DC. Als de DC onbereikbaar is, treedt er geen NTLM-terugval op.

Zie het volgende artikel om een SPN te declareren:

SPN's gebruiken bij het configureren van webtoepassingen die worden gehost op Internet Information Services.

Gebruikt de webserver een andere poort dan de standaardpoort (80)

Internet Explorer bevat standaard niet de poortnummergegevens in de SPN die wordt gebruikt om een Kerberos-ticket aan te vragen. Dit kan een probleem zijn als u IIS gebruikt om meerdere sites onder verschillende poorten en identiteiten te hosten. In deze configuratie werkt Kerberos-verificatie mogelijk alleen voor specifieke sites, zelfs als alle SPN's correct zijn gedeclareerd in Active Directory. U kunt dit probleem oplossen door de FEATURE_INCLUDE_PORT_IN_SPN_KB908209 registerwaarde in te stellen. (Zie de sectie Internet Explorer-functiesleutels voor informatie over het declareren van de sleutel.) Deze instelling dwingt Internet Explorer om het poortnummer op te nemen in de SPN die wordt gebruikt om het Kerberos-ticket aan te vragen.

Gebruikt Internet Explorer de verwachte SPN?

Als een website wordt geopend met behulp van een aliasnaam (CNAME), gebruikt Internet Explorer eerst DNS-resolutie om de aliasnaam om te zetten in een computernaam (ANAME). De computernaam wordt vervolgens gebruikt om de SPN te bouwen en een Kerberos-ticket aan te vragen. Zelfs als de URL die wordt ingevoerd in de adresbalk van Internet Explorer is http://MYWEBSITE, vraagt Internet Explorer een SPN voor HTTP/MYSERVER aan als MYWEBSITE een alias (CNAME) van MYSERVER (ANAME) is. U kunt dit gedrag wijzigen met behulp van de FEATURE_USE_CNAME_FOR_SPN_KB911149 registersleutel. (Zie de functiesleutels van Internet Explorer voor informatie over het declareren van de sleutel.)

Een netwerkmonitortracering is een goede methode om de SPN te controleren die is gekoppeld aan het Kerberos-ticket, zoals in het volgende voorbeeld:

- 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:

Komt de identiteit van de groep van toepassingen overeen met het account dat is gekoppeld aan SPN

Wanneer een Kerberos-ticket vanuit Internet Explorer naar een IIS-server wordt verzonden, wordt het ticket versleuteld met behulp van een persoonlijke sleutel. De persoonlijke sleutel is een hash van het wachtwoord dat wordt gebruikt voor het gebruikersaccount dat is gekoppeld aan de SPN. Dus alleen een toepassing die wordt uitgevoerd onder dit account kan het ticket decoderen.

De volgende procedure is een samenvatting van het Kerberos-verificatiealgoritme:

1. Internet Explorer bepaalt een SPN met behulp van de URL die is ingevoerd in de adresbalk.

2. De SPN wordt via een SSPI-API (Security Support Provider Interface) (InitializeSecurityContext) doorgegeven aan het systeemonderdeel dat verantwoordelijk is voor Windows-beveiliging (het LSASS-proces (Local Security Authority Subsystem Service). In deze fase ziet u dat de Code van Internet Explorer geen code implementeert om het Kerberos-ticket samen te stellen. Internet Explorer roept alleen SSPI-API's aan.

3. LSASS gebruikt de SPN die is doorgegeven om een Kerberos-ticket aan te vragen bij een DC. Als de DC de aanvraag kan verwerken (bekende SPN), wordt er een Kerberos-ticket gemaakt. Vervolgens wordt het ticket versleuteld met behulp van een sleutel die is samengesteld op basis van de hash van het wachtwoord van het gebruikersaccount voor het account dat is gekoppeld aan de SPN. LSASS verzendt vervolgens het ticket naar de client. Wat Internet Explorer betreft, is het ticket een ondoorzichtige blob.

4. Internet Explorer bevat het Kerberos-ticket dat wordt geleverd door LSASS in de Authorization: Negotiate header en verzendt vervolgens het ticket naar de IIS-server.

5. IIS verwerkt de aanvraag en stuurt deze door naar de juiste groep van toepassingen met behulp van de hostheader die is opgegeven.

6. De groep van toepassingen probeert het ticket te ontsleutelen met behulp van SSPI/LSASS-API's en door deze voorwaarden te volgen:

   • Als het ticket kan worden ontsleuteld, slaagt Kerberos-verificatie. Alle services die zijn gekoppeld aan het ticket (imitatie, delegatie als het ticket dit toestaat, enzovoort) zijn beschikbaar.

   • Als het ticket niet kan worden ontsleuteld, wordt er een Kerberos-fout (KRB_AP_ERR_MODIFIED) geretourneerd. Deze fout is een algemene fout die aangeeft dat het ticket op een of andere manier is gewijzigd tijdens het transport. Het ticket kan dus niet worden ontsleuteld. Deze fout wordt ook vastgelegd in de Windows-gebeurtenislogboeken.

Als u een SPN niet expliciet declareert, werkt Kerberos-verificatie alleen onder een van de volgende toepassingsgroepidentiteiten:

• Netwerkservice
• ApplicationPoolIdentity
• Een ander systeemaccount, zoals LOCALSYSTEM of LOCALSERVICE

Maar deze identiteiten worden niet aanbevolen, omdat ze een beveiligingsrisico vormen. In dit geval wordt het Kerberos-ticket gebouwd met behulp van een standaard-SPN die is gemaakt in Active Directory wanneer een computer (in dit geval de server waarop IIS wordt uitgevoerd) wordt toegevoegd aan het domein. Deze standaard-SPN is gekoppeld aan het computeraccount. Onder IIS wordt het computeraccount toegewezen aan Network Service of ApplicationPoolIdentity.

Als uw groep van toepassingen een andere identiteit moet gebruiken dan de vermelde identiteiten, declareert u een SPN (met behulp van SETSPN). Koppel deze vervolgens aan het account dat wordt gebruikt voor de identiteit van uw toepassingsgroep. Een veelvoorkomende fout is het maken van vergelijkbare SPN's met verschillende accounts. Bijvoorbeeld:

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

Deze configuratie werkt niet, omdat er geen deterministische manier is om te weten of het Kerberos-ticket voor de SPN http/mywebsite wordt versleuteld met het wachtwoord UserAppPool1 of UserAppPool2. Deze configuratie genereert doorgaans KRB_AP_ERR_MODIFIED fouten. Gebruik de hulpprogramma's die in het volgende artikel worden beschreven om te bepalen of u zich in dit scenario met dubbele SPN's bevindt:

Waarom u nog steeds dubbele SPN's kunt hebben in AD 2012 R2 en AD 2016

Vanaf Windows Server 2008 kunt u ook een bijgewerkte versie van SETSPN voor Windows gebruiken waarmee dubbele SPN's kunnen worden gedetecteerd met behulp van de setspn –X opdracht wanneer u een nieuwe SPN voor uw doelaccount declareert. Zie Setspn voor meer informatie.

We raden u ook aan de volgende artikelen te lezen:

• Problemen met Kerberos-verificatie : problemen met SPN (Service Principal Name) - deel 1

• Problemen met Kerberos-verificatie : problemen met SPN (Service Principal Name) - deel 2

• Problemen met Kerberos-verificatie : problemen met SPN (Service Principal Name) - deel 3

Mislukt Kerberos-verificatie in IIS 7 en latere versies, ook al werkt dit in IIS 6?

Verificatie in de kernelmodus is een functie die is geïntroduceerd in IIS 7. Het biedt de volgende voordelen:

• De prestaties zijn verbeterd, omdat overgangen tussen kernelmodus en gebruikersmodus niet meer worden gemaakt.
• Kerberos-ticketdecodering wordt uitgevoerd met behulp van het computeraccount en niet met de identiteit van de groep van toepassingen. Met deze wijziging kunt u meerdere toepassingsgroepen uitvoeren onder verschillende identiteiten zonder DAT u SPN's hoeft te declareren.

Waarom mislukt delegering, hoewel Kerberos-verificatie werkt?

Controleer in dit scenario de volgende items:

• De Internet Explorer-zone die wordt gebruikt voor de URL. Kerberos-delegering is alleen toegestaan voor de zones Intranet en Vertrouwde sites. (Met andere woorden, Internet Explorer stelt de ISC_REQ_DELEGATE vlag alleen in wanneer InitializeSecurityContext wordt aangeroepen als de zone die wordt bepaald intranet of vertrouwde sites is.)

• Voor het gebruikersaccount voor de IIS-toepassingsgroep die als host fungeert voor uw site moet de vlag Vertrouwd voor delegatie zijn ingesteld in Active Directory.

Als delegering nog steeds mislukt, kunt u overwegen de Kerberos-Configuration Manager voor IIS te gebruiken. Met dit hulpprogramma kunt u IIS-configuraties diagnosticeren en oplossen voor Kerberos-verificatie en voor de bijbehorende SPN's op de doelaccounts. Zie de README.md voor meer informatie. U kunt het hulpprogramma hier downloaden.

Waarom krijg ik slechte prestaties wanneer ik Kerberos-verificatie gebruik?

Kerberos is een verificatieprotocol op basis van aanvragen in oudere versies van Windows Server, zoals Windows Server 2008 SP2 en Windows Server 2008 R2. Dit betekent dat de client het Kerberos-ticket (dat een vrij grote blob kan zijn) moet verzenden bij elke aanvraag die naar de server wordt gedaan. Dit is in strijd met verificatiemethoden die afhankelijk zijn van NTLM. NTLM is standaard sessiegebaseerd. Dit betekent dat de browser slechts één aanvraag verifieert wanneer de TCP-verbinding met de server wordt geopend. Voor elke volgende aanvraag op dezelfde TCP-verbinding is geen verificatie meer vereist om de aanvraag te accepteren. In nieuwere versies van IIS, vanaf Windows 2012 R2, is Kerberos ook gebaseerd op sessies. Alleen de eerste aanvraag voor een nieuwe TCP-verbinding moet worden geverifieerd door de server. Volgende aanvragen hoeven geen Kerberos-ticket te bevatten.

U kunt dit gedrag wijzigen met behulp van de eigenschap authPersistNonNTLM als u werkt onder IIS 7 en latere versies. Als de eigenschap is ingesteld op true, wordt Kerberos gebaseerd op sessie. Anders wordt het op aanvraag gebaseerd. Dit levert slechtere prestaties op omdat we elke keer een grotere hoeveelheid gegevens moeten opnemen die naar de server moeten worden verzonden. Zie Kerberos-verificatie op basis van aanvraag versus sessie (of de parameter AuthPersistNonNTLM) voor meer informatie.

Waarom mislukt kerberos-delegatie tussen mijn twee forests, hoewel het vroeger werkte

Neem het volgende scenario:

• De gebruikers van uw toepassing bevinden zich in een domein in forest A.
• Uw toepassing bevindt zich in een domein in forest B.
• U hebt een vertrouwensrelatie tussen de forests.

In dit scenario werkt de Kerberos-delegatie mogelijk niet meer, hoewel deze voorheen werkte en u geen wijzigingen hebt aangebracht in forests of domeinen. Kerberos-verificatie werkt nog steeds in dit scenario. Alleen de delegatie mislukt.

Dit probleem kan optreden vanwege beveiligingsupdates voor Windows Server die door Microsoft zijn uitgebracht in maart 2019 en juli 2019. Met deze updates is onbeperkte Kerberos-delegering (de mogelijkheid om een Kerberos-token van een toepassing naar een back-endservice te delegeren) over forestgrenzen uitgeschakeld voor alle nieuwe en bestaande vertrouwensrelaties. Zie Updates TGT-delegering tussen binnenkomende vertrouwensrelaties in Windows Server voor meer informatie.

Internet Explorer-functiesleutels

Deze sleutels zijn registersleutels die bepaalde functies van de browser in- of uitschakelen. De sleutels bevinden zich op de volgende registerlocaties:

• HKEY_USERS\<UserSID>\Software\Microsoft\Internet Explorer\Main\FeatureControl – indien gedefinieerd op gebruikersniveau
• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\ - indien gedefinieerd op machineniveau

Functiesleutels moeten op een van deze locaties worden gemaakt, afhankelijk van of u de functie wilt in- of uitschakelen:

• voor alle gebruikers op de computer
• alleen voor een specifiek account

Deze sleutels moeten worden gemaakt onder het respectieve pad. In de sleutel moet een DWORD-waarde met de naam iexplorer.exe worden gedeclareerd. De standaardwaarde van elke sleutel moet true of false zijn, afhankelijk van de gewenste instelling van de functie. De waarde van beide functiesleutels en FEATURE_INCLUDE_PORT_IN_SPN_KB908209FEATURE_USE_CNAME_FOR_SPN_KB911149, is standaard onwaar. Voor de volledigheid volgt hier een voorbeeld van export van het register door de functiesleutel voor het opnemen van poortnummers in het Kerberos-ticket in te stellen op true:

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

Meer informatie

Diagnostische pagina's voor het oplossen van problemen met geïntegreerde Windows-verificatie