Partager via


Utiliser un scénario de test d’analyse des journaux pour dépanner l’authentification Kerberos

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.com domaine.

  • 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.com

    • Systè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.com sites appartiennent à la zone intranet locale

      Capture d’écran des propriétés Internet montrant que tous les sites web « contoso.com » se trouvent dans la zone intranet locale.

  • Sur l’ordinateur client, John se connecte à un serveur cible configuré comme suit :

    • Nom et domaine : IISServer.contoso.com

    • Systè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.

        Capture d’écran de la fenêtre Gestionnaire des services Internet montrant que l’authentification Windows est activée.

      • La liste des fournisseurs d’authentification activés inclut Negotiate, comme illustré dans la capture d’écran suivante :

        Capture d’écran de la fenêtre Fournisseurs montrant les fournisseurs activés inclut Negotiate.

    • 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 Failure
      

      Si 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.

Capture d’écran d’un flux d’authentification.

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 :

  1. Le service de résolution DNS met en cache IISServer.contoso.com pour vérifier si cette information est déjà mise en cache.
  2. Le service de résolution DNS vérifie le fichier HOSTS (C :\Windows\System32\drivers\etc\Hosts) pour tout mappage de IISServer.contoso.com.
  3. 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 :

  1. Le service serveur DNS vérifie ses zones configurées, localise l'enregistrement « A » de l'hôte et résout IISServer.contoso.com en l'adresse IP 192.168.2.104.
  2. Le serveur DNS retourne l’adresse IP à l’ordinateur client.

L’étape 3 se produit sur l’ordinateur client et inclut les étapes suivantes :

  1. L’ordinateur client effectue une négociation TCP à trois voies en utilisant le port TCP 80.
  2. 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 :

  1. Le service web (en cours d’exécution en tant que IISServer.contoso.com) reçoit la demande de Client1.contoso.com.
  2. Le service web envoie à Client1.contoso.com un 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 :

  1. L’ordinateur client reçoit le message de réponse du défi de IISServer.contoso.com.
  2. Le processus Microsoft Edge vérifie que IISServer.contoso.com appartient à la zone intranet locale. Par conséquent, le processus d’authentification doit utiliser Kerberos au lieu de NTLM.
  3. Le processus Microsoft Edge appelle LSASS.exe afin de rechercher un ticket de service pour IISServer.contoso.com.
  4. 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 :

  1. Le contrôleur de domaine (service KDC) reçoit la demande de Client1.contoso.com et recherche le service qui utilise le SPN HTTP\IISServer.contoso.com (ou HOST\IISServer.contoso.com).
  2. Le contrôleur de domaine identifie le service demandé comme service web qui s’exécute sous le contexte de IISServer.contoso.com.
  3. Le contrôleur de domaine envoie une réponse à l’ordinateur client qui inclut un ticket de service pour le IISServer.contoso.com service web.

L’étape 7 se produit sur le contrôleur de domaine et inclut les étapes suivantes :

  1. Le processus Microsoft Edge crée un message AP (Kerberos Application Protocol) qui inclut le ticket de service.
  2. Le processus Microsoft Edge envoie le message AP à IISServer.contoso.com en 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 :

  1. Le processus IIS interroge le processus local LSASS.exe.
  2. 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.
  3. Le processus LSASS.exe retourne un handle pour le jeton au processus IIS.
  4. 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.
  5. 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 :

  1. Sur l’ordinateur client, ouvrez une fenêtre de console d'administration, puis exécutez ipconfig /flushdns.
  2. Ouvrez Network Monitor et démarrez l’enregistrement.
  3. Ouvrez Microsoft Edge. Dans la barre d’adresse, entrez http://iisserver.contoso.com.
  4. 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 » deIISServer.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 Internet
    
  • Ré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.104
    
  • Demande anonyme du processus Microsoft Edge sur Client1.contoso.com vers le serveur web IIS IISServer.contoso.com.

    3027    00:59:30.1609409    Client1.contoso.com    iisserver.contoso.com    HTTP    HTTP:Request, GET /
    Host:  iisserver.contoso.com
    
  • Message de réponse de la demande HTTP 401 de IISServer.contoso.com vers Client1.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: NTLM
    
  • Demande de ticket de service depuis Client1.contoso.com au contrôleur de domaine DCA.contoso.com pour le service qui utilise HTTP/iisserver.contoso.com comme 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.com
    
  • Réponse de ticket de service de DCA.contoso.com qui inclut le ticket de service pour IISServer.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.com
    
  • Deuxième demande du processus Microsoft Edge sur Client1.contoso.com vers IISServer.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.com
    
  • Message 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.com
    

    La 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.104
    
  • Vé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.com 
    

    La 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

  1. 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.

  2. Exécutez les commandes suivantes, dans l’ordre donné :

    klist purge
    klist get http/iisserver.contoso.com
    

    La 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.com
    

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

  1. 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.

  2. Sur l’ordinateur client, connectez-vous (en tant qu’utilisateur « John »), puis ouvrez l’Explorateur Windows.

  3. Dans la barre d’adresses, entrez \\IISServer.contoso.com \Software$.

  4. 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.

  5. Sur l’ordinateur client, exécutez la commande klist tickets à l’invite de commande. La sortie de commande doit inclure un ticket de service pour CIFS/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