Condividi tramite

Usare uno scenario di test di analisi dei log per risolvere i problemi di autenticazione Kerberos

Questo articolo usa una distribuzione ipotetica di client e server per illustrare gli approcci di risoluzione dei problemi di autenticazione Kerberos.

Ambiente e configurazione

  • L'utente "John" appartiene al contoso.com dominio.

  • Tutti i server DNS (Domain Name System) del dominio sono controller di dominio.

  • John è connesso a un computer client configurato come segue:

    • Nome e dominio: Client1.contoso.com

    • Sistema operativo: Windows 11

    • Browser: Microsoft Edge

    • Applicazione di monitoraggio: Monitoraggio di rete (installato da Microsoft Network Monitor)

    • Configurazione delle opzioni Internet: tutti i contoso.com siti appartengono all'area Intranet locale

      Screenshot di Proprietà Internet che mostra che tutti i siti Web

  • Nel computer client John si connette a un server di destinazione configurato come segue:

    • Nome e dominio: IISServer.contoso.com

    • Sistema operativo: Windows Server 2019

    • Servizio di destinazione: sito Web eseguito in Internet Information Services (IIS)

    • Account del servizio di destinazione: l'account del computer (il servizio viene eseguito nel contesto dell'account IISServer.contoso.com)

    • Porta del servizio di destinazione: porta TCP 80

    • Configurazione dell'autenticazione (configurata in Gestione Internet Information Services):

      • L'autenticazione di Windows è abilitata.

        Screenshot della finestra Gestione Internet Information Services che mostra che l'autenticazione di Windows è abilitata.

      • L'elenco dei provider di autenticazione abilitati include Negotiate, come illustrato nello screenshot seguente:

        Screenshot della finestra Provider che mostra che i provider abilitati includono Negotiate.

    • Configurazione di controllo dell'accesso: il controllo accesso riuscito e il controllo degli errori di accesso sono entrambi abilitati.

      Annotazioni

      Per impostazione predefinita, per tutti i sistemi operativi Windows Server è abilitato il controllo accesso riuscito e non riuscito. Per verificare questa impostazione, aprire una finestra del prompt dei comandi amministrativa e quindi eseguire il comando seguente:

      auditpol /get /Subcategory:"logon"

      Se l'impostazione è abilitata, questo comando genera l'output seguente:

      System audit policy
Category/Subcategory                    Setting
Logon/Logoff
  Logon                                 Success and Failure

      Se questo risultato non viene visualizzato, eseguire il comando seguente per abilitare il log di audit delle operazioni riuscite e non riuscite:

      auditpol /set /subcategory:"Logon" /Success:enable /Failure:enable

Flusso di autenticazione previsto

Il diagramma seguente illustra la sequenza di messaggi di richiesta e risposta Kerberos e i percorsi di tali messaggi nell'ambiente descritto nella sezione precedente.

Screenshot di un flusso di autenticazione.

Il processo viene avviato quando l'utente John, che ha eseguito l'accesso al computer Client1.contoso.comclient, apre un browser Microsoft Edge e si connette a IISServer.contoso.com.

Il passaggio 1 si verifica nel computer client e include i passaggi seguenti:

  1. Il servizio resolver DNS memorizza nella cache IISServer.contoso.com per verificare se queste informazioni sono già presenti.
  2. Il servizio resolver DNS controlla il file HOSTS (C:\Windows\System32\drivers\etc\Hosts) per qualsiasi mapping di IISServer.contoso.com.
  3. Il servizio client DNS invia una query DNS al server DNS preferito (come configurato nelle impostazioni di configurazione IP).

Il passaggio 2 si verifica nel server DNS (controller di dominio) e include i passaggi seguenti:

  1. Il servizio server DNS controlla le zone configurate, individua il record Host "A" e risolve IISServer.contoso.com nell'indirizzo IP 192.168.2.104.
  2. Il server DNS restituisce l'indirizzo IP al computer client.

Il passaggio 3 si verifica nel computer client e include i passaggi seguenti:

  1. Il computer client esegue un handshake a tre vie TCP con IISServer.contoso.com sulla porta TCP 80.
  2. Il computer client invia una richiesta HTTP anonima a IISServer.contoso.com.

Il passaggio 4 si verifica nel server di destinazione e include i passaggi seguenti:

  1. Il servizio Web (in esecuzione come IISServer.contoso.com) riceve la richiesta da Client1.contoso.com.
  2. Il servizio Web invia un messaggio di risposta a Client1.contoso.com che contiene una risposta di richiesta "HTTP 401". il messaggio specifica Negotiate come provider di autenticazione preferito e NTLM come provider di autenticazione secondario.

Il passaggio 5 si verifica nel computer client e include i passaggi seguenti:

  1. Il computer client riceve il messaggio di risposta della richiesta di verifica da IISServer.contoso.com.
  2. Il processo di Microsoft Edge verifica che IISServer.contoso.com appartiene all'area Intranet locale. Pertanto, il processo di autenticazione deve usare Kerberos anziché NTLM.
  3. Il processo di Microsoft Edge chiama LSASS.exe per cercare un ticket di servizio per IISServer.contoso.com.
  4. In questo caso, il computer client non dispone di un ticket di servizio appropriato. Il processo di Microsoft Edge invia una richiesta al Centro di distribuzione Kerberos (KDC) per ottenere un ticket.

Il passaggio 6 si verifica nel controller di dominio e include i passaggi seguenti:

  1. Il controller di dominio (servizio KDC) riceve la richiesta da Client1.contoso.com e cerca il servizio che usa il nome SPN HTTP\IISServer.contoso.com (o HOST\IISServer.contoso.com).
  2. Il controller di dominio identifica il servizio richiesto come servizio Web eseguito nel contesto di IISServer.contoso.com.
  3. Il controller di dominio invia una risposta al computer client che include un ticket di servizio per il IISServer.contoso.com servizio Web.

Il passaggio 7 si verifica nel controller di dominio e include i passaggi seguenti:

  1. Il processo di Microsoft Edge crea un messaggio AP (Kerberos Application Protocol) che include il ticket di servizio.
  2. Il processo di Microsoft Edge invia il messaggio AP a IISServer.contoso.com in risposta al messaggio di risposta di richiesta "HTTP 401".

Il passaggio 8 si verifica nel server Web e include i passaggi seguenti:

  1. Il processo IIS interroga il processo locale LSASS.exe.
  2. Il processoLSASS.exe decrittografa il ticket e quindi crea un token per l'utente che include un SessionID e le appartenenze ai gruppi di John.
  3. Il processo LSASS.exe restituisce un handle per il token al processo IIS.
  4. Il processo IIS controlla le informazioni sul gruppo nel token per assicurarsi che John disponga dell'autorizzazione per accedere alla pagina richiesta.
  5. Il processo IIS invia la pagina richiesta al browser.

Usare Monitoraggio di rete per registrare un test di autenticazione

Usare la procedura seguente per raccogliere dati di traccia in un ambiente simile a quello descritto nella sezione Ambiente e configurazione . Durante questo test, i componenti di sistema devono interagire nel modo descritto nella sezione Flusso di autenticazione previsto .

Annotazioni

Per usare le procedure descritte in questa sezione, è necessario appartenere al gruppo Administrators locale:

  1. Sul computer client, aprire una finestra del prompt dei comandi come amministratore e quindi eseguire ipconfig /flushdns.
  2. Aprire Monitoraggio rete e avviare la registrazione.
  3. Aprire Microsoft Edge. Nella barra degli indirizzi, immettere http://iisserver.contoso.com.
  4. Al termine dell'operazione di Microsoft Edge, arrestare la registrazione in Monitoraggio di rete.

Esaminare i dati generati dal test di autenticazione

Il test di autenticazione genera le informazioni seguenti:

  • Dati di traccia del monitoraggio della rete
  • Dati dei ticket
  • Controlla i dati degli eventi di successo di verifica e degli errori di verifica per gli eventi di autenticazione

Nella parte restante di questa sezione vengono fornite informazioni più dettagliate sui dati generati dal flusso di autenticazione.

Esaminare i dati di traccia per eventi significativi

Nei dati di traccia cercare informazioni simili agli estratti di traccia seguenti:

  • Query DNS al controller di dominio per il record "A" host perIISServer.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

  • Risposta DNS dal servizio DNS nel controller di dominio:

    3006    00:59:30.0743438    DCA.contoso.com    Client1.contoso.com    DNS    DNS:QueryId = 0x666A, QUERY (Standard query), Response - Success, 192.168.2.104

  • Richiesta anonima dal processo Client1.contoso.com di Microsoft Edge al IISServer.contoso.com server Web IIS:

    3027    00:59:30.1609409    Client1.contoso.com    iisserver.contoso.com    HTTP    HTTP:Request, GET /
Host:  iisserver.contoso.com

  • Messaggio di risposta della richiesta di verifica HTTP 401 da IISServer.contoso.com a 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

  • Richiesta di ticket di servizio da Client1.contoso.com al controller DCA.contoso.com di dominio per il servizio che usa HTTP/iisserver.contoso.com come nome SPN (noto anche come messaggio di richiesta TGS):

    3034    00:59:30.1834048    Client1.contoso.com    DCA.contoso.com    KerberosV5    KerberosV5:TGS Request Realm: CONTOSO.COM Sname: HTTP/iisserver.contoso.com

  • Risposta del ticket di servizio da DCA.contoso.com, che comprende il ticket di servizio per IISServer.contoso.com (conosciuto anche come messaggio di risposta 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

  • Seconda richiesta dal processo di Microsoft Edge su Client1.contoso.com a IISServer.contoso.com. Questo messaggio include il ticket di servizio:

    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

  • Messaggio dal server IIS a Client1.contoso.com. Questo messaggio indica che l'utente è autenticato e autorizzato:

    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)

Esaminare le informazioni sul ticket sul computer del client

Al prompt dei comandi nel computer client eseguire klist tickets. L'output dovrebbe essere simile al seguente estratto:

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

Esaminare gli eventi di controllo nel server di destinazione

Nel Visualizzatore eventi su IISServer.contoso.com, vai ai Registri di Windows>Sicurezza per esaminare gli eventi di accesso. Cercare le istanze dell'ID evento 4624 o 4625 e controllare i campi seguenti:

  • Parole chiave: Controlloesito positivo o errore di controllo
  • Tipo di accesso: 3 (accesso di rete)
  • ID di sicurezza nel campo Nuovo accesso: Contoso\John
  • Indirizzo di rete di origine: indirizzo IP del computer client
  • Processo di accesso e pacchetto di autenticazione: Kerberos

Il testo completo del record dell'evento è simile al seguente estratto:

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

Risolvere i problemi relativi al flusso di lavoro di autenticazione

Esaminare le tracce di rete per osservare quale passaggio ha esito negativo in modo da limitare la posizione nel processo in cui si verifica il problema. Usare queste informazioni per determinare quali metodi di risoluzione dei problemi consentono di risolvere il problema.

Verificare la connettività di rete

Se sembra esserci un problema nelle comunicazioni DNS o TCP, controllare le interazioni seguenti:

  • Verificare che sia possibile risolvere il nome del server di destinazione (IISServer.contoso.com) dal computer client (Client1.contoso.com).

  • Verificare che il server DNS risolva correttamente l'indirizzo IP del server di destinazione. A tale scopo, aprire una finestra di PowerShell e quindi eseguire il cmdlet seguente:

    Resolve-DnsName -Name IISServer.contoso.com

    L'output di questo cmdlet dovrebbe essere simile al seguente estratto:

    Name                                       Type   TTL   Section    IPAddress
----                                       ----   ---   -------    ---------
IISServer.contoso.com                      A      1200  Answer     192.168.2.104

  • Verificare che le porte di rete necessarie siano aperte tra il computer client e il server di destinazione. A tale scopo, eseguire il cmdlet seguente:

    Test-NetConnection -Port 80 IISServer.contoso.com

    L'output di questo cmdlet dovrebbe essere simile al seguente estratto:

    ComputerName     : IISServer.contoso.com
RemoteAddress    : 192.168.2.104
RemotePort       : 80
InterfaceAlias   : Ethernet 2
SourceAddress    : 192.168.2.101
TcpTestSucceeded : True

Verificare le informazioni sul ticket nel computer client

  1. Aprire una finestra del prompt dei comandi standard (anziché una finestra del prompt dei comandi amministrativo) nel contesto dell'utente che sta tentando di accedere al sito web.

  2. Eseguire i comandi seguenti, nell'ordine specificato:

    klist purge
klist get http/iisserver.contoso.com

    L'output di questi comandi dovrebbe essere simile al seguente estratto:

    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

    Questo estratto indica che il ticket è stato recuperato correttamente. I dettagli del ticket sono etichettati "#1>" nella sezione Ticket memorizzati nella cache .

Verificare che il servizio Web IIS sia in esecuzione nel server IIS usando le credenziali predefinite

Aprire una finestra del prompt di PowerShell standard (anziché una finestra di prompt di PowerShell amministrativa) nel contesto dell'utente che sta tentando di accedere al sito Web:

invoke-webrequest -Uri http://IIsserver.contoso.com -UseDefaultCredentials

L'output di questi comandi dovrebbe essere simile al seguente estratto:

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

Esaminare il registro eventi di sicurezza nel server di destinazione

Nel Visualizzatore eventi sul server di destinazione, vai al log Registri di Windows>Sicurezza. Cercare istanze dell'ID evento 4624 (esito positivo del controllo) o 4625 (errore di controllo).

Verificare che altri servizi funzionino correttamente

Per verificare che altri servizi nel server di destinazione possano elaborare l'autenticazione Kerberos, seguire questa procedura:

  1. Nel server di destinazione creare una condivisione file o identificare una condivisione file esistente da usare per il test. Assicurati che tu, nel ruolo di "John", abbia il permesso di lettura sulla cartella.

  2. Sul computer client, accedi (come utente "John") e quindi apri Esplora File.

  3. Nella barra degli indirizzi immettere \\IISServer.contoso.com \Software$.

  4. Nel server di destinazione aprire Visualizzatore eventi e quindi esaminare gli eventi di sicurezza. Verificare che siano presenti nuovi eventi con ID evento 4624 o ID evento 4625.

  5. Sul computer client, eseguire il comando klist tickets al prompt dei comandi. L'output del comando deve includere un ticket di servizio per CIFS/IISServer.contoso.com, come illustrato nell'estratto seguente:

    #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
  • Last updated on