Considerações e problemas conhecidos ao usar o Credential Guard

É recomendável que, além de implantar o Credential Guard, as organizações se afastem de senhas para outros métodos de autenticação, como Windows Hello para Empresas, chaves de segurança FIDO 2 ou cartões inteligentes.

Considerações de Wi-fi e VPN

Ao habilitar o Credential Guard, você não pode mais usar a autenticação clássica do NTLM para logon único. Você será forçado a inserir suas credenciais para usar esses protocolos e não poderá salvar as credenciais para uso futuro.

Se você estiver usando pontos de extremidade WiFi e VPN baseados em MS-CHAPv2, eles estarão sujeitos a ataques semelhantes aos do NTLMv1.

Para conexões WiFi e VPN, é recomendável migrar de conexões baseadas em MSCHAPv2 (como PEAP-MSCHAPv2 e EAP-MSCHAPv2), para autenticação baseada em certificado (como PEAP-TLS ou EAP-TLS).

Considerações kerberos

Ao habilitar o Credential Guard, você não poderá mais usar a delegação Kerberos irrestrita nem a criptografia DES. A delegação irrestrita pode permitir que os invasores extraiam chaves Kerberos do processo isolado da LSA.
Em vez disso, use a delegação Kerberos restrita ou com base em recursos.

Considerações de provedores de suporte à segurança não microsoft

Alguns SSPs (SSPs e APs) que não são da Microsoft Security Support podem não ser compatíveis com o Credential Guard porque não permite que SSPs não microsoft peçam hashes de senha da LSA. No entanto, SSPs e PAs ainda são notificados sobre a senha quando um usuário faz logon e/ou altera sua senha. Não há suporte para qualquer uso de APIs não documentadas em SSPs e APs personalizados.
É recomendável que implementações personalizadas de SSPs/APs sejam testadas com o Credential Guard. SSPs e PAS que dependem de qualquer falha de comportamento não documentado ou sem suporte. Por exemplo, não há suporte para usar a API KerbQuerySupplementalCredentialsMessage. Substituir os SSPs NTLM ou Kerberos por SSPs e PAs personalizados.

Para obter mais informações, confira Restrições ao registrar e instalar um pacote de segurança.

Considerações de atualização

À medida que a profundidade e a amplitude das proteções fornecidas pelo Credential Guard são aumentadas, novas versões do Windows com o Credential Guard em execução podem afetar cenários que estavam funcionando no passado. Por exemplo, o Credential Guard pode bloquear o uso de um determinado tipo de credencial ou um componente específico para impedir que o malware aproveite as vulnerabilidades.

Cenários de teste necessários para operações em uma organização antes de atualizar um dispositivo usando o Credential Guard.

Considerações de credenciais salvas do Windows

O Gerenciador de Credenciais permite que você armazene três tipos de credenciais:

  • Credenciais do Windows
  • Credenciais baseadas em certificado
  • Credenciais genéricas

As credenciais de domínio armazenadas no Credential Manager são protegidas com o Credential Guard.

Credenciais genéricas, como nomes de usuário e senhas que você usa para entrar em sites, não estão protegidas, pois os aplicativos exigem sua senha de texto livre. Se o aplicativo não precisar de uma cópia da senha, ele poderá salvar credenciais de domínio como credenciais do Windows protegidas. Credenciais do Windows são usadas para se conectar a outros computadores em uma rede.

As considerações a seguir se aplicam às proteções do Credential Guard para o Gerenciador de Credenciais:

  • As credenciais do Windows salvas pelo cliente da Área de Trabalho Remota não podem ser enviadas para um host remoto. Tentativas de usar credenciais salvas do Windows falham, exibindo falha na tentativa de logon da mensagem de erro
  • Falha nos aplicativos que extraem credenciais do Windows
  • Quando as credenciais são apoiadas de um computador que tem o Credential Guard habilitado, as credenciais do Windows não podem ser restauradas. Se você precisar fazer backup de suas credenciais, você deve fazê-lo antes de habilitar o Credential Guard

Considerações de compensação do TPM

A Segurança baseada em virtualização (VBS) usa o TPM para proteger sua chave. Quando o TPM é limpo, a chave protegida do TPM usada para criptografar segredos VBS é perdida.

Aviso

A limpeza dos resultados de TPM resulta em perda de dados protegidos de todos os recursos que usam a VBS para proteger dados.

Quando um TPM é desmarcado, todos os recursos que usam o VBS para proteger os dados não podem mais descriptografar seus dados protegidos.

Como resultado, o Credential Guard não pode mais descriptografar dados protegidos. O VBS cria uma nova chave TPM protegida para o Credential Guard. O Credential Guard usa a nova chave para proteger dados novos. No entanto, os dados protegidos anteriormente serão perdidos para sempre.

Observação

O Credential Guard obtém a chave durante a inicialização. A perda de dados só afetará os dados persistentes e ocorrerá após a próxima inicialização do sistema.

Credenciais do Windows salvas no Gerenciador de Credenciais

Como o Credential Manager não pode descriptografar credenciais salvas do Windows, elas são excluídas. Os aplicativos devem solicitar credenciais salvas anteriormente. Quando são salvas novamente, as credenciais do Windows são protegidas pelo Credential Guard.

A chave pública do dispositivo ingressado no domínio é provisionada automaticamente

Os dispositivos ingressados no domínio do Active Directory provisionam automaticamente uma chave pública vinculada, para obter mais informações sobre o provisionamento automático de chaves públicas, consulte Autenticação de chave pública de dispositivo ingressada no domínio.

Como o Credential Guard não pode descriptografar a chave privada protegida, o Windows usa a senha do computador ingressado no domínio para autenticação no domínio. A menos que outras políticas sejam implantadas, não deve haver perda de funcionalidade. Se um dispositivo estiver configurado para usar apenas a chave pública, ele não poderá se autenticar com senha até que essa política seja desabilitada. Para obter mais informações sobre como Configurar dispositivos para usar somente a chave pública, consulte Autenticação de chave pública de dispositivo ingressado em domínio.

Além disso, se quaisquer verificações de controle de acesso, incluindo políticas de autenticação, exigirem que os dispositivos tenham os KEY TRUST IDENTITY (S-1-18-4) SIDs ou FRESH PUBLIC KEY IDENTITY (S-1-18-3) conhecidos, essas verificações de acesso falharão. Para saber mais sobre as políticas de autenticação, consulte Políticas de autenticação e silos da política de autenticação. Para saber mais sobre SIDs conhecidos, consulte [MS-DTYP] Seção 2.4.2.4 Estruturas de SID conhecidas.

Quebra de DPAPI em dispositivos ingressados em domínio

Em dispositivos ingressados em domínio, o DPAPI pode recuperar chaves do usuário usando um controlador de domínio do domínio do usuário. Se um dispositivo ingressado no domínio não tiver conectividade com um controlador de domínio, a recuperação não será possível.

Importante

A prática recomendada ao limpar um TPM em um dispositivo ingressado no domínio é estar em uma rede conectada aos controladores de domínio. Isso garante que as funções de DPAPI e do usuário não apresentem comportamento estranho.

Configuração de VPN automática protegida com o usuário DPAPI. O usuário não poderá usar a VPN para se conectar a controladores de domínio já que as configurações de VPN foram perdidas. Se você deve apagar o TPM em um dispositivo ingressado no domínio sem conectividade com controladores de domínio, você deve considerar o seguinte.

Logon do usuário de domínio em um dispositivo ingressado no domínio depois de limpar um TPM enquanto não houver conectividade com um controlador de domínio:

Tipo de credencial Comportamento
Certificado (cartão inteligente ou Windows Hello para Empresas) Todos os dados protegidos com DPAPI de usuário são inutilizáveis e o DPAPI do usuário não funciona.
Senha Se o usuário entrou com um certificado ou senha antes de limpar o TPM, ele poderá entrar com senha e o DPAPI do usuário não será afetado.

Depois que o dispositivo estiver conectado aos controladores de domínio, o DPAPI recupera a chave do usuário e os dados protegidos antes de limpar o TPM podem ser descriptografados.

Impacto de falhas de DPAPI na Proteção de Informações do Windows

Quando os dados protegidos com o DPAPI do usuário são inutilizáveis, o usuário perde o acesso a todos os dados de trabalho protegida pela Proteção de Informações do Windows. O impacto inclui: o Outlook não pode iniciar e os documentos protegidos pelo trabalho não podem ser abertos. Se o DPAPI estiver funcionando, os dados de trabalho recém criados são protegidos e podem ser acessados.

Solução: os usuários podem resolver o problema conectando seus dispositivos ao domínio e reinicializando ou usando o certificado do Agente de recuperação dados do sistema de arquivos de criptografia. Para obter mais informações sobre o certificado de Criptografia do agente de recuperação dados do sistema de arquivos, consulte Criar e verificar um certificado de Agente de recuperação de dados (DRA) do Sistema de arquivos de criptografia (EFS).

Problemas conhecidos

O Credential Guard bloqueia determinadas funcionalidades de autenticação. Aplicativos que exigem esses recursos não funcionarão quando o Credential Guard estiver habilitado.

Este artigo descreve problemas conhecidos quando o Credential Guard está habilitado.

Logon único para quebras de serviços de rede após a atualização para Windows 11, versão 22H2

Dispositivos que usam conexões 802.1x sem fio ou com fio, RDP ou VPN que dependem de protocolos inseguros com autenticação baseada em senha não podem usar o SSO para entrar e são forçados a se autenticar manualmente em todas as novas sessões do Windows quando o Credential Guard estiver em execução.

Dispositivos afetados

Qualquer dispositivo com o Credential Guard habilitado pode encontrar o problema. Como parte do Windows 11, a atualização versão 22H2, dispositivos qualificados que não desabilitaram o Credential Guard, o habilitaram por padrão. Isso afetou todos os dispositivos nas licenças Enterprise (E3 e E5) e Education, bem como algumas licenças Pro, desde que atendessem aos requisitos mínimos de hardware.

Todos os dispositivos Windows Pro que anteriormente executaram o Credential Guard em uma licença qualificada e posteriormente rebaixados para o Pro, e que ainda atendem aos requisitos mínimos de hardware, receberão habilitação padrão.

Dica

Para determinar se um dispositivo Windows Pro recebe habilitação padrão quando atualizado para Windows 11, versão 22H2, marcar se a chave IsolatedCredentialsRootSecret do registro estiver presente em Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0. Se ele estiver presente, o dispositivo habilita o Credential Guard após a atualização.

Você pode desabilitar o Credential Guard após a atualização seguindo as instruções de desabilitação.

Causa do problema

Aplicativos e serviços são afetados pelo problema quando dependem de protocolos inseguros que usam autenticação baseada em senha. Esses protocolos são considerados inseguros porque podem levar à divulgação de senha no cliente ou no servidor, e o Credential Guard os bloqueia. Os protocolos afetados incluem:

  • Delegação não treinada kerberos (credenciais fornecidas e SSO são bloqueadas)
  • Kerberos quando o PKINIT usa criptografia RSA em vez de Diffie-Hellman (as credenciais SSO e fornecidas são bloqueadas)
  • MS-CHAP (somente O SSO está bloqueado)
  • WDigest (somente O SSO está bloqueado)
  • NTLM v1 (apenas O SSO está bloqueado)

Observação

Como apenas o SSO está bloqueado para MS-CHAP, WDigest e NTLM v1, esses protocolos ainda podem ser usados solicitando que o usuário forneça credenciais.

Como confirmar o problema

MS-CHAP e NTLMv1 são relevantes para a interrupção do SSO após o Windows 11, versão 22H2 atualização. Para confirmar se o Credential Guard está bloqueando MS-CHAP ou NTLMv1, abra o Visualizador de Eventos (eventvwr.exe) e vá para Application and Services Logs\Microsoft\Windows\NTLM\Operational. Verifique os seguintes logs:

ID do evento (tipo)

Descrição

4013 (Aviso)

<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 (Erro)

<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"
/>

Como corrigir o problema

Recomendamos se afastar de conexões baseadas em MSCHAPv2, como PEAP-MSCHAPv2 e EAP-MSCHAPv2, para autenticação baseada em certificado, como PEAP-TLS ou EAP-TLS. O Credential Guard não bloqueia a autenticação baseada em certificado.

Para uma correção mais imediata, mas menos segura, desabilite o Credential Guard. O Credential Guard não tem políticas por protocolo ou por aplicativo e pode ser ativado ou desativado. Se você desabilitar o Credential Guard, deixará as credenciais de domínio armazenadas vulneráveis ao roubo.

Dica

Para evitar a habilitação padrão, configure seus dispositivos para desabilitar o Credential Guard antes de atualizar para Windows 11, versão 22H2. Se a configuração não estiver configurada (que é o estado padrão) e se o dispositivo for qualificado, o dispositivo habilitará automaticamente o Credential Guard após a atualização.

Se o Credential Guard estiver explicitamente desabilitado, o dispositivo não habilitará automaticamente o Credential Guard após a atualização.

Problemas com aplicativos que não são da Microsoft

O seguinte problema afeta MSCHAPv2:

Este problema a seguir afeta a API Java GSS. Veja o artigo do banco de dados de bugs da Oracle:

Quando o Credential Guard está habilitado no Windows, a API do Java GSS não se autentica. O Credential Guard bloqueia recursos específicos de autenticação de aplicativo e não fornece a chave de sessão TGT para aplicativos, independentemente das configurações de chave do registro. Para obter mais informações, confira Requisitos de aplicativo.

Suporte ao fornecedor

Os seguintes produtos e serviços não dão suporte ao Credential Guard:

Importante

Esta lista não é abrangente. Verifique se seu fornecedor de produtos, versão do produto ou sistema de computador dá suporte ao Credential Guard em sistemas que executam uma versão específica do Windows. Modelos específicos do sistema de computador podem ser incompatíveis com o Credential Guard.