Condividi tramite

L'evento di controllo mostra il pacchetto di autenticazione come NTLMv1 anziché NTLMv2

Questo articolo illustra un problema a causa del quale l'autenticazione usa effettivamente NTLMv2, ma segnala NTLMv1 nel registro eventi.

Numero KB originale: 2701704

Riepilogo

Si usa lmcompatibilitylevel su 3 o versione successiva in tutti i computer del dominio per forzare i client a usare solo NTLMv2. Durante il test delle connessioni alle condivisioni di rete in base all'indirizzo IP per forzare NTLM, si scopre che il "pacchetto di autenticazione" è ancora elencato come NTLMv1 nell'evento di controllo di sicurezza (ID evento 4624) connesso al server.

Ad esempio, si esegue il test con un client Windows 7 che si connette a una condivisione file in Windows Server 2008 R2. La traccia di rete ha mostrato che l'autenticazione usava effettivamente NTLMv2, ma segnalava NTLMv1 nel registro eventi:

Nome log: Sicurezza
Origine: Microsoft-Windows-Security-Auditing
ID evento: 4624
Categoria attività: Accesso
Livello: Informazioni
Parole chiave: Controlla esito positivo
Descrizione:
È stato eseguito l'accesso a un account.
Nome account: utente
Dominio account: contoso
Informazioni dettagliate sull'autenticazione:
Processo di accesso: NtLmSsp
Pacchetto di autenticazione: NTLM
Servizi transitati: -
Nome pacchetto (solo NTLM): NTLM V1
Lunghezza chiave: 128

Ulteriori informazioni

Esistono due scenari noti che possono portare a questo risultato.

  • Scenario A: Controller di dominio di Windows Server 2003

    È stato rilevato che è possibile riprodurre questo comportamento quando il controller di dominio convalida le credenziali degli utenti è un server basato su 2003. Windows Server 2003 non aveva il campo "pacchetto di autenticazione" nella registrazione eventi, questa era una nuova funzionalità aggiunta in Windows Vista.

    Se il controller di dominio è Windows Server 2008 o versione successiva, il server visualizzerà il pacchetto di autenticazione elencato correttamente come NTLMv2. Se la segnalazione della versione del protocollo di autenticazione è importante, è consigliabile usare i controller di dominio Windows Server 2008 o versioni successive.

    Windows Server 2003 è in fase di supporto esteso, il supporto viene ritirato a luglio 2015. Vedere Ciclo di vita del prodotto di ricerca.

  • Scenario B: La negoziazione dei livelli di sicurezza usa metodi "legacy" che indicano il massimo sforzo

    Questo scenario riguarda i client di terze parti:

    1. Il cliente ha un client SMB di terze parti configurato per NTLMv1.

    2. Il file server è configurato per LmCompatiblityLevel=5 e la sicurezza minima sesion NTLMv2, il controller di dominio è configurato per LmCompatiblityLevel=4.

    3. Un utente nel client di terze parti si connette. In SMB il BLOB di sicurezza viene visualizzato nella negoziazione della sessione SMB con i campi del nome previsti e NegotiateFlags, il server rifiuta la negoziazione:

      NegotiateFlags: 0x60000215 (NTLM v1128-bit encryption, , Sign)
NegotiateNTLM:                    (......................1.........) Requests usage of the NTLM v1 session security protocol.
NegotiateNTLM2:                   (............0...................) Does NOT request usage of the NTLM v1 using the extended session security.

    4. Il client di terze parti ritenta quindi senza usare il BLOB di sicurezza (che indica la sicurezza estesa della sessione). In questo formato non viene visualizzato lo stesso elenco noto di campi dei nomi e forse anche noNegotiateFlags. Alcuni campi come "ClientChallenge" potrebbero indicare che il client tenta di eseguire l'elaborazione hash NTLMv2. Tuttavia, a causa della mancanza di NegotiateFlags, questo non arriva come richiesta di autenticazione NTLMv2 nel controller di dominio.

    5. Il server inoltra il pacchetto al controller di dominio che autentica la richiesta e, poiché il controller di dominio è OK per usare NTLMv1, autentica la richiesta.

    6. Il server riceve l'accesso riuscito e controlla che come NTLMv1 come specificato dal controller di dominio.

    Per gli accessi senza sicurezza della sessione estesa, il server non può bloccare la richiesta di accesso in base ai flag client. Deve inoltrare la richiesta con i flag migliori che ha ottenuto al controller di dominio. Al ritorno, deve anche accettare qualsiasi decisione presa dal controller di dominio sull'accesso. In questo caso, accetta l'accesso e lo registra come accesso NTLMv1, anche se il server di risorse è configurato per consentire solo NTLMv2.