Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Cet article utilise un déploiement hypothétique de client et de serveur pour illustrer les approches de résolution des problèmes d’authentification Kerberos.
Environnement et configuration
L’utilisateur « John » appartient au
contoso.comdomaine.Tous les serveurs DNS (Domain Name System) du domaine sont des contrôleurs de domaine.
John est connecté à un ordinateur client configuré comme suit :
Nom et domaine :
Client1.contoso.comSystème d’exploitation : Windows 11
Navigateur : Microsoft Edge
Application de supervision : Moniteur réseau (installé à partir de Microsoft Network Monitor)
Configuration des options Internet : tous les
contoso.comsites appartiennent à la zone intranet locale
Sur l’ordinateur client, John se connecte à un serveur cible configuré comme suit :
Nom et domaine :
IISServer.contoso.comSystème d’exploitation : Windows Server 2019
Service cible : site web qui s’exécute sur Internet Information Services (IIS)
Compte de service cible : le compte d’ordinateur (le service s’exécute dans le contexte de
IISServer.contoso.com)Port de service cible : port TCP 80
Configuration de l’authentification (configurée dans internet Information Services Manager) :
L’authentification Windows est activée.
La liste des fournisseurs d’authentification activés inclut Negotiate, comme illustré dans la capture d’écran suivante :
Configuration de l’audit d’ouverture de session : l’audit d’ouverture de session et l’audit d’échec d’ouverture de session sont tous les deux activés.
Remarque
Par défaut, tous les systèmes d’exploitation Windows Server ont activé l’audit d’ouverture de session réussite et échec. Pour vérifier ce paramètre, ouvrez une fenêtre d’invite de commandes en tant qu'administrateur, puis exécutez la commande suivante :
auditpol /get /Subcategory:"logon"Si le paramètre est activé, cette commande génère la sortie suivante :
System audit policy Category/Subcategory Setting Logon/Logoff Logon Success and FailureSi vous ne voyez pas ce résultat, exécutez la commande suivante pour activer la journalisation de l’audit réussite et échec :
auditpol /set /subcategory:"Logon" /Success:enable /Failure:enable
Flux d’authentification attendu
Le diagramme suivant montre la séquence de messages de requête et de réponse Kerberos et les chemins d’accès de ces messages dans l’environnement décrit dans la section précédente.
Le processus démarre lorsque l’utilisateur John, connecté à l’ordinateur Client1.contoso.comclient, ouvre un navigateur Microsoft Edge et se connecte à IISServer.contoso.com.
L’étape 1 se produit sur l’ordinateur client et inclut les étapes suivantes :
- Le service de résolution DNS met en cache
IISServer.contoso.compour vérifier si cette information est déjà mise en cache. - Le service de résolution DNS vérifie le fichier HOSTS (C :\Windows\System32\drivers\etc\Hosts) pour tout mappage de
IISServer.contoso.com. - Le service client DNS envoie une requête DNS au serveur DNS préféré (tel que configuré sur les paramètres de configuration IP).
L’étape 2 se produit sur le serveur DNS (contrôleur de domaine) et inclut les étapes suivantes :
- Le service serveur DNS vérifie ses zones configurées, localise l'enregistrement « A » de l'hôte et résout
IISServer.contoso.comen l'adresse IP192.168.2.104. - Le serveur DNS retourne l’adresse IP à l’ordinateur client.
L’étape 3 se produit sur l’ordinateur client et inclut les étapes suivantes :
- L’ordinateur client effectue une négociation TCP à trois voies en utilisant le port TCP 80.
- L’ordinateur client envoie une requête HTTP anonyme à
IISServer.contoso.com.
L’étape 4 se produit sur le serveur cible et inclut les étapes suivantes :
- Le service web (en cours d’exécution en tant que
IISServer.contoso.com) reçoit la demande deClient1.contoso.com. - Le service web envoie à
Client1.contoso.comun message de réponse qui contient une réponse de défi « HTTP 401 ». le message spécifie Negotiate comme fournisseur d’authentification préféré et NTLM comme fournisseur d’authentification secondaire.
L’étape 5 se produit sur l’ordinateur client et inclut les étapes suivantes :
- L’ordinateur client reçoit le message de réponse du défi de
IISServer.contoso.com. - Le processus Microsoft Edge vérifie que
IISServer.contoso.comappartient à la zone intranet locale. Par conséquent, le processus d’authentification doit utiliser Kerberos au lieu de NTLM. - Le processus Microsoft Edge appelle LSASS.exe afin de rechercher un ticket de service pour
IISServer.contoso.com. - Dans ce cas, l’ordinateur client n’a pas de ticket de service approprié. Le processus Microsoft Edge envoie une demande au Centre de distribution Kerberos (KDC) pour un ticket.
L’étape 6 se produit sur le contrôleur de domaine et inclut les étapes suivantes :
- Le contrôleur de domaine (service KDC) reçoit la demande de
Client1.contoso.comet recherche le service qui utilise le SPNHTTP\IISServer.contoso.com(ouHOST\IISServer.contoso.com). - Le contrôleur de domaine identifie le service demandé comme service web qui s’exécute sous le contexte de
IISServer.contoso.com. - Le contrôleur de domaine envoie une réponse à l’ordinateur client qui inclut un ticket de service pour le
IISServer.contoso.comservice web.
L’étape 7 se produit sur le contrôleur de domaine et inclut les étapes suivantes :
- Le processus Microsoft Edge crée un message AP (Kerberos Application Protocol) qui inclut le ticket de service.
- Le processus Microsoft Edge envoie le message AP à
IISServer.contoso.comen réponse au message de réponse au défi « HTTP 401 ».
L’étape 8 se produit sur le serveur web et inclut les étapes suivantes :
- Le processus IIS interroge le processus local LSASS.exe.
- Le processus LSASS.exe déchiffre le ticket, puis crée un jeton pour l’utilisateur qui inclut un ID de session et les appartenances aux groupes de John.
- Le processus LSASS.exe retourne un handle pour le jeton au processus IIS.
- Le processus IIS vérifie les informations de groupe dans le jeton pour s'assurer que John a la permission d'accéder à la page demandée.
- Le processus IIS envoie la page demandée au navigateur.
Utiliser Network Monitor pour enregistrer un test d’authentification
Utilisez les étapes suivantes pour collecter des données de trace sur un environnement qui ressemble à celui décrit dans la section Environnement et configuration . Pendant ce test, les composants système doivent interagir de la manière décrite dans la section Flux d’authentification attendu .
Remarque
Pour utiliser les procédures de cette section, vous devez appartenir au groupe Administrateurs local :
- Sur l’ordinateur client, ouvrez une fenêtre de console d'administration, puis exécutez
ipconfig /flushdns. - Ouvrez Network Monitor et démarrez l’enregistrement.
- Ouvrez Microsoft Edge. Dans la barre d’adresse, entrez
http://iisserver.contoso.com. - Une fois l’opération Microsoft Edge terminée, arrêtez l’enregistrement dans Le moniteur réseau.
Passez en revue les données générées par le test d’authentification
Le test d’authentification génère les informations suivantes :
- Données de trace du Moniteur réseau
- Données de ticket
- Audit des données d'événements d'authentification réussis et échoués
Le reste de cette section fournit plus de détails sur les données produites par le flux d’authentification.
Passer en revue les données de trace pour les événements significatifs
Dans les données de trace, recherchez des informations qui ressemblent aux extraits de trace suivants :
Requête DNS vers le contrôleur de domaine pour l'enregistrement hôte « A » de
IISServer.contoso.com:3005 00:59:30.0738430 Client1.contoso.com DCA.contoso.com DNS DNS:QueryId = 0x666A, QUERY (Standard query), Query for iisserver.contoso.com of type Host Addr on class InternetRéponse DNS du service DNS sur le contrôleur de domaine :
3006 00:59:30.0743438 DCA.contoso.com Client1.contoso.com DNS DNS:QueryId = 0x666A, QUERY (Standard query), Response - Success, 192.168.2.104Demande anonyme du processus Microsoft Edge sur
Client1.contoso.comvers le serveur web IISIISServer.contoso.com.3027 00:59:30.1609409 Client1.contoso.com iisserver.contoso.com HTTP HTTP:Request, GET / Host: iisserver.contoso.comMessage de réponse de la demande HTTP 401 de
IISServer.contoso.comversClient1.contoso.com:3028 00:59:30.1633647 iisserver.contoso.com Client1.contoso.com HTTP HTTP:Response, HTTP/1.1, Status: Unauthorized, URL: /favicon.ico Using Multiple Authetication Methods, see frame details WWWAuthenticate: Negotiate WWWAuthenticate: NTLMDemande de ticket de service depuis
Client1.contoso.comau contrôleur de domaineDCA.contoso.compour le service qui utiliseHTTP/iisserver.contoso.comcomme son SPN (également appelé message de requête TGS) :3034 00:59:30.1834048 Client1.contoso.com DCA.contoso.com KerberosV5 KerberosV5:TGS Request Realm: CONTOSO.COM Sname: HTTP/iisserver.contoso.comRéponse de ticket de service de
DCA.contoso.comqui inclut le ticket de service pourIISServer.contoso.com(aussi appelé message de réponse TGS) :3036 00:59:30.1848687 DCA.contoso.com Client1.contoso.com KerberosV5 KerberosV5:TGS Response Cname: John Ticket: Realm: CONTOSO.COM, Sname: HTTP/iisserver.contoso.com Sname: HTTP/iisserver.contoso.comDeuxième demande du processus Microsoft Edge sur
Client1.contoso.comversIISServer.contoso.com. Ce message inclut le ticket de service :3040 00:59:30.1853262 Client1.contoso.com iisserver.contoso.com HTTP HTTP:Request, GET /favicon.ico , Using GSS-API Authorization Authorization: Negotiate Authorization: Negotiate YIIHGwYGKwYBBQUCoIIHDzCCBwugMDAuBgkqhkiC9xIBAgIGCSqGSIb3EgECAgYKKwYBBAGCNwICHgYKKwYBBAGCNwICCqKCBtUEggbRYIIGzQYJKoZIhvcSAQICAQBugga8MIIGuKADAgEFoQMCAQ6iBwMFACAAAACjggTvYYIE6zCCBOegAwIBBaENGwtDT05UT1NPLkNPTaIoMCagAwIBAqEfMB0bBEhUVFAbF SpnegoToken: 0x1 NegTokenInit: ApReq: KRB_AP_REQ (14) Ticket: Realm: CONTOSO.COM, Sname: HTTP/iisserver.contoso.comMessage du serveur IIS vers
Client1.contoso.com. Ce message indique que l’utilisateur est authentifié et autorisé :3044 00:59:30.1875763 iisserver.contoso.com Client1.contoso.com HTTP HTTP:Response, HTTP/1.1, Status: Not found, URL: / , Using GSS-API Authentication WWWAuthenticate: Negotiate oYG2MIGzoAMKAQChCwYJKoZIgvcSAQICooGeBIGbYIGYBgkqhkiG9xIBAgICAG+BiDCBhaADAgEFoQMCAQ+ieTB3oAMCARKicARuIF62dHj2/qKDRV5XjGKmyFl2/z6b9OHTCTKigAatXS1vZTVC1dMvtNniSN8GpXJspqNvEfbETSinF0ee7KLaprxNgTYwTrMVMnd95SoqBkm/FuY7WbTAuPvyRmUuBY3EKZEy NegotiateAuthorization: GssAPI: 0x1 NegTokenResp: ApRep: KRB_AP_REP (15)
Passer en revue les informations de ticket sur l’ordinateur client
Exécutez klist tickets à l'invite de commande de l'ordinateur client. La sortie doit ressembler à l’extrait suivant :
Client: John @ CONTOSO.COM
Server: HTTP/iisserver.contoso.com @ CONTOSO.COM
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x40a10000 -> forwardable renewable pre_authent name_canonicalize
Start Time: 11/28/2022 0:59:30 (local)
End Time: 11/28/2022 10:58:56 (local)
Renew Time: 12/5/2022 0:58:56 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
Cache Flags: 0
Kdc Called: DCA.contoso.com
Passer en revue les événements d’audit sur le serveur cible
Dans l’Observateur d’événements sur IISServer.contoso.com, accédez au journal des événements Windows>Sécurité pour passer en revue les événements de connexion (logon). Recherchez les instances de l’ID d’événement 4624 ou 4625, puis vérifiez les champs suivants :
- Mots clés : Échec d’audit ou de réussitede l’audit
- Type d’ouverture de session : 3 (ouverture de session réseau)
- ID de sécurité dans le nouveau champ Ouverture de session : Contoso\John
- Adresse réseau source : adresse IP de l’ordinateur client
- Processusd’ouverture de session et package d’authentification : Kerberos
Le texte intégral de l’enregistrement d’événements ressemble à l’extrait suivant :
Log Name: Security
Source: Microsoft-Windows-Security-Auditing
Date: 11/28/2022 12:59:30 AM
Event ID: 4624
Task Category: Logon
Level: Information
Keywords: Audit Success
User: N/A
Computer: IISServer.contoso.com
Description:
An account was successfully logged on.
Subject:
Security ID: NULL SID
Account Name: -
Account Domain: -
Logon ID: 0x0
Logon Information:
Logon Type: 3
Restricted Admin Mode: -
Virtual Account: No
Elevated Token: No
Impersonation Level: Impersonation
New Logon:
Security ID: CONTOSO\John
Account Name: John
Account Domain: CONTOSO.COM
Logon ID: 0x1B64449
Linked Logon ID: 0x0
Network Account Name: -
Network Account Domain: -
Logon GUID: {<GUID>}
Process Information:
Process ID: 0x0
Process Name: -
Network Information:
Workstation Name: -
Source Network Address: 192.168.2.101
Source Port: 52655
Detailed Authentication Information:
Logon Process: Kerberos
Authentication Package: Kerberos
Résoudre les problèmes liés au flux de travail d’authentification
Passez en revue les traces réseau pour observer quelle étape échoue afin que vous puissiez affiner l’emplacement dans le processus où le problème se produit. Utilisez ces informations pour déterminer quelles méthodes de dépannage peuvent vous aider à résoudre le problème.
Vérifier la connectivité réseau
S’il semble y avoir un problème dans les communications DNS ou TCP, vérifiez les interactions suivantes :
Vérifiez que vous pouvez résoudre le nom du serveur cible (
IISServer.contoso.com) à partir de l’ordinateur client (Client1.contoso.com).Vérifiez que le serveur DNS résout correctement l’adresse IP du serveur cible. Pour ce faire, ouvrez une fenêtre PowerShell, puis exécutez l’applet de commande suivante :
Resolve-DnsName -Name IISServer.contoso.comLa sortie de cette applet de commande doit ressembler à l’extrait suivant :
Name Type TTL Section IPAddress ---- ---- --- ------- --------- IISServer.contoso.com A 1200 Answer 192.168.2.104Vérifiez que les ports réseau requis sont ouverts entre l’ordinateur client et le serveur cible. Pour ce faire, exécutez l’applet de commande suivante :
Test-NetConnection -Port 80 IISServer.contoso.comLa sortie de cette applet de commande doit ressembler à l’extrait suivant :
ComputerName : IISServer.contoso.com RemoteAddress : 192.168.2.104 RemotePort : 80 InterfaceAlias : Ethernet 2 SourceAddress : 192.168.2.101 TcpTestSucceeded : True
Vérifier les informations de ticket sur l’ordinateur client
Ouvrez une fenêtre d’invite de commandes standard (au lieu d’une fenêtre d’invite de commandes administrative) dans le contexte de l’utilisateur qui tente d’accéder au site web.
Exécutez les commandes suivantes, dans l’ordre donné :
klist purge klist get http/iisserver.contoso.comLa sortie de ces commandes doit ressembler à l’extrait suivant :
Current LogonId is 0:0xa8a98b A ticket to http/iisserver.contoso.com has been retrieved successfully. Cached Tickets: (2) #0> Client: John @ CONTOSO.COM Server: krbtgt/CONTOSO.COM @ CONTOSO.COM KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96 Ticket Flags 0x40e10000 -> forwardable renewable initial pre_authent name_canonicalize Start Time: 11/28/2022 1:28:11 (local) End Time: 11/28/2022 11:28:11 (local) Renew Time: 12/5/2022 1:28:11 (local) Session Key Type: AES-256-CTS-HMAC-SHA1-96 Cache Flags: 0x1 -> PRIMARY Kdc Called: DCA.contoso.com #1> Client: John @ CONTOSO.COM Server: http/iisserver.contoso.com @ CONTOSO.COM KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96 Ticket Flags 0x40a10000 -> forwardable renewable pre_authent name_canonicalize Start Time: 11/28/2022 1:28:11 (local) End Time: 11/28/2022 11:28:11 (local) Renew Time: 12/5/2022 1:28:11 (local) Session Key Type: AES-256-CTS-HMAC-SHA1-96 Cache Flags: 0 Kdc Called: DCA.contoso.comCet extrait indique que le ticket a été récupéré avec succès. Les détails du ticket sont étiquetés « #1> » dans la section Tickets mis en cache .
Vérifiez que le service web IIS s’exécute sur le serveur IIS à l’aide des informations d’identification par défaut
Ouvrez une fenêtre d’invite PowerShell standard (au lieu d’une fenêtre d’invite PowerShell administrative) dans le contexte de l’utilisateur qui tente d’accéder au site web :
invoke-webrequest -Uri http://IIsserver.contoso.com -UseDefaultCredentials
La sortie de ces commandes doit ressembler à l’extrait suivant :
StatusCode : 200
StatusDescription : OK
Content : <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" cont...
RawContent : HTTP/1.1 200 OK
Persistent-Auth: true
Accept-Ranges: bytes
Content-Length: 703
Content-Type: text/html
Date: Mon, 28 Nov 2022 09:31:40 GMT
ETag: "3275ea8a1d91:0"
Last-Modified: Fri, 25 Nov 2022...
Passez en revue le journal des événements de sécurité sur le serveur cible
Dans l’Observateur d’événements sur le serveur cible, accédez au journalde sécurité des journaux> Windows. Recherchez les instances de l’ID d’événement 4624 (Réussite de l’audit) ou 4625 (Échec d’audit).
Vérifier que d’autres services fonctionnent correctement
Pour vérifier que d’autres services sur le serveur cible peuvent traiter l’authentification Kerberos, procédez comme suit :
Sur le serveur cible, créez un partage de fichiers ou identifiez un partage de fichiers existant à utiliser pour les tests. Assurez-vous que vous (dans le rôle de « John ») avez l’autorisation Lecture sur le dossier.
Sur l’ordinateur client, connectez-vous (en tant qu’utilisateur « John »), puis ouvrez l’Explorateur Windows.
Dans la barre d’adresses, entrez \\IISServer.contoso.com \Software$.
Sur le serveur cible, ouvrez l’Observateur d’événements, puis passez en revue les événements de sécurité. Vérifiez qu’il existe de nouveaux événements ID 4624 ou 4625.
Sur l’ordinateur client, exécutez la commande
klist ticketsà l’invite de commande. La sortie de commande doit inclure un ticket de service pourCIFS/IISServer.contoso.com, comme indiqué dans l’extrait suivant :#1> Client: John @ CONTOSO.COM Server: cifs/iisserver.contoso.com @ CONTOSO.COM KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96 Ticket Flags 0x40a10000 -> forwardable renewable pre_authent name_canonicalize Start Time: 11/28/2022 1:40:22 (local) End Time: 11/28/2022 11:28:11 (local) Renew Time: 12/5/2022 1:28:11 (local) Session Key Type: AES-256-CTS-HMAC-SHA1-96 Cache Flags: 0 Kdc Called: DCA.contoso.com