Considerazioni e problemi noti quando si usa Credential Guard

È consigliabile che, oltre a distribuire Credential Guard, le organizzazioni passino dalle password ad altri metodi di autenticazione, ad esempio Windows Hello for Business, chiavi di sicurezza FIDO 2 o smart card.

Considerazioni su Wi-Fi e VPN

Quando si abilita Credential Guard, non è più possibile usare l'autenticazione classica NTLM per l'accesso Single Sign-On. Sarà necessario immettere le credenziali per usare questi protocolli e non è possibile salvare le credenziali per un uso futuro.

Se si usano endpoint WiFi e VPN basati su MS-CHAPv2, sono soggetti ad attacchi simili a quelli di NTLMv1.

Per le connessioni Wi-Fi e VPN, è consigliabile passare da connessioni basate su MSCHAPv2 (ad esempio PEAP-MSCHAPv2 e EAP-MSCHAPv2) all'autenticazione basata su certificato (ad esempio PEAP-TLS o EAP-TLS).

Considerazioni su Kerberos

Quando abiliti Credential Guard, non puoi più usare la delega senza vincoli Kerberos né la crittografia DES. La delega senza vincoli potrebbe consentire a utenti malintenzionati di estrarre le chiavi Kerberos dal processo LSA isolato.
Usa la delega Kerberos con vincoli o basata su risorse.

Considerazioni relative ai provider di supporto per la sicurezza non Microsoft

Alcuni provider di supporto per la sicurezza non Microsoft potrebbero non essere compatibili con Credential Guard perché non consentono ai provider di servizi di sicurezza non Microsoft di richiedere hash delle password da LSA. Tuttavia, gli SSP e I punti di accesso continuano a ricevere notifiche relative alla password quando un utente effettua l'accesso e/o cambia la propria password. Non è supportato l'uso di API non documentate all'interno di provider di servizi app e indirizzi di accesso personalizzati.
È consigliabile testare le implementazioni personalizzate di provider di servizi di sicurezza/indirizzi IP con Credential Guard. Gli SSP e i punti di accesso che dipendono da eventuali comportamenti non documentati o non supportati non riescono. Ad esempio, l'uso dell'API KerbQuerySupplementalCredentialsMessage non è supportato. Sostituire gli SSP NTLM o Kerberos con SSP e punti di accesso personalizzati.

Per altre informazioni, vedere Restrizioni relative alla registrazione e all'installazione di un pacchetto di sicurezza.

Considerazioni sull'aggiornamento

Con l'aumento della profondità e dell'ampiezza delle protezioni fornite da Credential Guard, le nuove versioni di Windows con Credential Guard in esecuzione potrebbero influire sugli scenari che funzionavano in passato. Ad esempio, Credential Guard può bloccare l'uso di un particolare tipo di credenziali o di un componente specifico per impedire che il malware sfrutti le vulnerabilità.

Scenari di test necessari per le operazioni in un'organizzazione prima di aggiornare un dispositivo usando Credential Guard.

Considerazioni relative alle credenziali di Windows salvate

Gestione credenziali consente di archiviare tre tipi di credenziali:

  • Credenziali di Windows
  • Credenziali basate su certificato
  • Credenziali generiche

Le credenziali di dominio archiviate in Credential Manager sono protette con Credential Guard.

Le credenziali generiche, ad esempio i nomi utente e le password usate per accedere ai siti Web, non sono protette perché le applicazioni richiedono la password non crittografate. Se l'applicazione non necessita di una copia della password, può salvare le credenziali di dominio come credenziali di Windows protette. Le credenziali di Windows vengono utilizzate per connettersi ad altri computer in una rete.

Le considerazioni seguenti si applicano alle protezioni di Credential Guard per Gestione credenziali:

  • Le credenziali di Windows salvate dal client Desktop remoto non possono essere inviate a un host remoto. I tentativi di usare le credenziali di Windows salvate hanno esito negativo, visualizzando il messaggio di errore Tentativo di accesso non riuscito
  • Le applicazioni che estraggono le credenziali di Windows hanno esito negativo
  • Quando viene eseguito il backup delle credenziali da un PC in cui è abilitato Credential Guard, le credenziali di Windows non possono essere ripristinate. Se è necessario eseguire il backup delle credenziali, è necessario farlo prima di abilitare Credential Guard

Considerazioni sulla cancellazione di TPM

La sicurezza basata su virtualizzazione (VBS) usa il TPM per proteggere la chiave. Quando il TPM viene cancellato, la chiave protetta TPM usata per crittografare i segreti VBS viene persa.

Warning

La cancellazione di TPM comporta la perdita dei dati protetti per tutte le funzionalità che utilizzano VBS per proteggere i dati.

Quando un TPM viene cancellato, tutte le funzionalità che usano VBS per proteggere i dati non possono più decrittografare i dati protetti.

Di conseguenza, Credential Guard non può più decrittografare i dati protetti. VBS crea una nuova chiave TPM protetta per Credential Guard. Credential Guard usa la nuova chiave per proteggere i nuovi dati. Tuttavia, i dati precedentemente protetti sono persi per sempre.

Nota

Credential Guard ottiene la chiave durante l'inizializzazione. La perdita di dati influirà solo sui dati persistenti e si verificherà dopo il successivo avvio del sistema.

Credenziali di Windows salvate in Gestione credenziali

Poiché Credential Manager non può decrittografare le credenziali di Windows salvate, vengono eliminate. Le applicazioni devono richiedere le credenziali che sono state salvate in precedenza. Se salvate nuovamente, le credenziali di Windows sono protette da Credential Guard.

Chiave pubblica con provisioning automatico del dispositivo aggiunto a un dominio

Per altre informazioni sul provisioning automatico della chiave pubblica, vedere Autenticazione a chiave pubblica del dispositivo aggiunta al dominio.

Poiché Credential Guard non può decrittografare la chiave privata protetta, Windows usa la password del computer aggiunto al dominio per l'autenticazione al dominio. A meno che non vengano distribuiti altri criteri, non dovrebbe verificarsi una perdita di funzionalità. Se un dispositivo è configurato per usare solo la chiave pubblica, non può eseguire l'autenticazione con la password finché tale criterio non viene disabilitato. Per ulteriori informazioni sulla configurazione dei dispositivi per utilizzare solo la chiave pubblica, vedi Autenticazione della chiave pubblica del dispositivo aggiunto a un dominio.

Inoltre, se eventuali controlli di controllo di accesso, inclusi i criteri di autenticazione, richiedono che i dispositivi abbiano i KEY TRUST IDENTITY (S-1-18-4) SID o FRESH PUBLIC KEY IDENTITY (S-1-18-3) noti, tali controlli di accesso hanno esito negativo. Per ulteriori informazioni sui criteri di autenticazione, vedi Criteri di autenticazione e silo di criteri di autenticazione. Per ulteriori informazioni sui SID noti, vedi [MS-DTYP] sezione 2.4.2.4 Strutture SID note.

Interruzione di DPAPI nei dispositivi aggiunti a un dominio

Nei dispositivi aggiunti a un dominio, DPAPI può ripristinare le chiavi utente utilizzando un controller di dominio dal dominio dell'utente. Se un dispositivo aggiunto a un dominio non ha connettività a un controller di dominio, il ripristino non è possibile.

Importante

Durante la cancellazione di un TPM in un dispositivo aggiunto al dominio si consiglia di usare una rete con connettività ai controller di dominio. In questo modo le funzioni DPAPI e l'utente non si confronteranno con comportamenti anomali.

La configurazione automatica VPN è protetta dalla DPAPI dell'utente. Utente potrebbe non essere in grado di usare la VPN per connettersi al controller di dominio poiché le configurazioni VPN vengono perse. Se è necessario cancellare il TPM in un dispositivo aggiunto a un dominio senza connettività ai controller di dominio, è opportuno considerare quanto segue.

Accesso utente di dominio in un dispositivo aggiunto a un dominio dopo aver cancellato un TPM finché non è presente alcuna connettività a un controller di dominio:

Tipo di credenziale Comportamento
Certificato (smart card o Windows Hello for Business) Tutti i dati protetti con DPAPI dell'utente sono inutilizzabili e il DPAPI dell'utente non funziona affatto.
Password Se l'utente ha eseguito l'accesso con un certificato o una password prima di cancellare il TPM, può accedere con la password e L'utente DPAPI non è interessato.

Una volta che il dispositivo dispone della connettività ai controller di dominio, la DPAPI ripristina la chiave dell'utente e i dati protetti prima della cancellazione del TMP possono essere decrittografati.

Impatto degli errori DPAPI su Windows Information Protection

Quando i dati protetti con la DPAPI dell'utente sono inutilizzabili, l'utente perde l'accesso a tutti i dati di lavoro protetti da Windows Information Protection. L'impatto include: Outlook non è in grado di iniziare e non è possibile aprire documenti protetti da lavoro. Se la DPAPI funziona, i dati di lavoro appena creati sono protetti e accessibili.

Soluzione temporanea: gli utenti possono risolvere il problema collegando il dispositivo al dominio e riavviando oppure usando il certificato Agente recupero dati di Encrypting File System. Per ulteriori informazioni sul certificato Agente recupero dati di Encrypting File System, vedi Creare e verificare un certificato dell'agente di recupero dati per EFS (Encrypting File System).

Problemi noti

Credential Guard blocca alcune funzionalità di autenticazione. Le applicazioni che richiedono tali funzionalità non funzioneranno quando Credential Guard è abilitato.

Questo articolo descrive i problemi noti quando Credential Guard è abilitato.

L'accesso Single Sign-On per i servizi di rete si interrompe dopo l'aggiornamento a Windows 11 versione 22H2

I dispositivi che usano connessioni wireless o cablate, RDP o VPN 802.1x che si basano su protocolli non sicuri con autenticazione basata su password non sono in grado di usare l'accesso SSO e sono costretti a ripetere manualmente l'autenticazione in ogni nuova sessione di Windows quando Credential Guard è in esecuzione.

Dispositivi interessati

Qualsiasi dispositivo con Credential Guard abilitato potrebbe riscontrare il problema. Come parte dell'aggiornamento di Windows 11 versione 22H2, i dispositivi idonei che non hanno disabilitato Credential Guard lo hanno abilitato per impostazione predefinita. Ciò ha interessato tutti i dispositivi nelle licenze Enterprise (E3 ed E5) ed Education, nonché alcune licenze Pro, purché soddisfino i requisiti hardware minimi.

Tutti i dispositivi Windows Pro che in precedenza hanno eseguito Credential Guard su una licenza idonea e successivamente declassati a Pro e che soddisfano ancora i requisiti hardware minimi, riceveranno l'abilitazione predefinita.

Suggerimento

Per determinare se un dispositivo Windows Pro riceve l'abilitazione predefinita quando viene aggiornato a Windows 11 versione 22H2, controllare se la chiave IsolatedCredentialsRootSecret del Registro di sistema è presente in Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0. Se è presente, il dispositivo abilita Credential Guard dopo l'aggiornamento.

È possibile disabilitare Credential Guard dopo l'aggiornamento seguendo le istruzioni di disabilitazione.

Causa del problema

Le applicazioni e i servizi sono interessati dal problema quando si basano su protocolli non sicuri che usano l'autenticazione basata su password. Tali protocolli sono considerati non sicuri perché possono portare alla divulgazione delle password nel client o nel server e Credential Guard li blocca. I protocolli interessati includono:

  • Delega non vincolata Kerberos (le credenziali SSO e specificate sono bloccate)
  • Kerberos quando PKINIT usa la crittografia RSA anziché Diffie-Hellman (sono bloccate sia le credenziali SSO che le credenziali fornite)
  • MS-CHAP (solo l'accesso SSO è bloccato)
  • WDigest (solo l'accesso SSO è bloccato)
  • NTLM v1 (solo l'accesso SSO è bloccato)

Nota

Poiché solo l'accesso SSO è bloccato per MS-CHAP, WDigest e NTLM v1, questi protocolli possono comunque essere usati richiedendo all'utente di fornire le credenziali.

Come confermare il problema

MS-CHAP e NTLMv1 sono rilevanti per la rottura dell'accesso SSO dopo l'aggiornamento di Windows 11 versione 22H2. Per verificare se Credential Guard blocca MS-CHAP o NTLMv1, aprire il Visualizzatore eventi (eventvwr.exe) e passare a Application and Services Logs\Microsoft\Windows\NTLM\Operational. Controllare i log seguenti:

ID evento (tipo)

Descrizione

4013 (Avviso)

<string
id="NTLMv1BlockedByCredGuard"
value="Attempt to use NTLMv1 failed.
Target server: %1%nSupplied user: %2%nSupplied domain: %3%nPID
of client process: %4%nName
of client process: %5%nLUID
of client process: %6%nUser identity
of client process: %7%nDomain name
of user identity of client process: %8%nMechanism OID: 9%n%n
This device doesn't support NTLMv1.
/>

4014 (Errore)

<string
id="NTLMGetCredentialKeyBlockedByCredGuard"
value="Attempt to get credential key by call package blocked by Credential Guard.%n%n
Calling Process Name: %1%nService Host Tag: %2"
/>

Come risolvere il problema

È consigliabile passare dalle connessioni basate su MSCHAPv2, ad esempio PEAP-MSCHAPv2 e EAP-MSCHAPv2, all'autenticazione basata su certificato, ad esempio PEAP-TLS o EAP-TLS. Credential Guard non blocca l'autenticazione basata su certificati.

Per una correzione più immediata ma meno sicura, disabilitare Credential Guard. Credential Guard non ha criteri per protocollo o per applicazione e può essere attivato o disattivato. Se disabiliti Credential Guard, lasci le credenziali di dominio archiviate vulnerabili al furto.

Suggerimento

Per impedire l'abilitazione predefinita, configurare i dispositivi per disabilitare Credential Guard prima di eseguire l'aggiornamento a Windows 11 versione 22H2. Se l'impostazione non è configurata (ovvero lo stato predefinito) e se il dispositivo è idoneo, il dispositivo abilita automaticamente Credential Guard dopo l'aggiornamento.

Se Credential Guard è disabilitato in modo esplicito, il dispositivo non abiliterà automaticamente Credential Guard dopo l'aggiornamento.

Problemi con applicazioni non Microsoft

Il problema seguente riguarda MSCHAPv2:

Il seguente problema riguarda l'API GSS Java. Vedi l'articolo sul database bug di Oracle seguente:

Quando Credential Guard è abilitato in Windows, l'API GSS Java non viene autenticata. Credential Guard blocca specifiche funzionalità di autenticazione dell'applicazione e non fornisce la chiave di sessione TGT alle applicazioni, indipendentemente dalle impostazioni della chiave del Registro di sistema. Per altre informazioni, vedere Requisiti dell'applicazione.

Supporto del fornitore

I prodotti e i servizi seguenti non supportano Credential Guard:

Importante

Questo elenco non è completo. Verificare se il fornitore del prodotto, la versione del prodotto o il sistema computer supporta Credential Guard nei sistemi che eseguono una versione specifica di Windows. Modelli di sistema computer specifici potrebbero non essere compatibili con Credential Guard.