A KB5124008, atualização de segurança de setembro de 2026 para o Windows 11 24H2 e 25H2, está associada a relatos de computadores corporativos que perdem a relação de confiança com o domínio Active Directory depois da instalação e reinicialização. O problema pode impedir o login de usuários com credenciais válidas e transformar uma atualização de segurança em uma ocorrência de suporte bastante complexa.
Os relatos analisados pela Microsoft e por administradores indicam uma possível relação com o recurso Machine Identity Isolation, utilizado junto ao Credential Guard para proteger as credenciais da conta de máquina. A Microsoft confirmou que está investigando os relatos, mas, até o momento, não confirmou oficialmente que esse mecanismo seja a causa raiz nem publicou uma correção específica para esse problema.
Neste artigo, você verá o que acontece após a instalação da KB5124008, por que o canal seguro entre a estação e o controlador de domínio pode ser afetado e como administradores estão utilizando uma solução temporária baseada no Registro e no PowerShell para recuperar os computadores atingidos.
O que está acontecendo com a atualização KB5124008 no Windows 11
A KB5124008 foi disponibilizada pela Microsoft em 8 de setembro de 2026 para o Windows 11 24H2 e 25H2, com atualizações de segurança e outras melhorias. O problema de autenticação não aparece necessariamente em todos os computadores, mas os relatos concentram-se principalmente em ambientes corporativos com máquinas ingressadas em domínios do Active Directory.
O comportamento descrito por administradores é particularmente problemático porque o computador pode funcionar normalmente antes da atualização e apresentar a falha somente depois da reinicialização pós-instalação.
Na prática, o usuário tenta entrar no Windows usando uma conta de domínio e recebe mensagens que podem indicar falha na relação de confiança, credenciais incorretas ou impossibilidade de autenticação no domínio. Isso não significa necessariamente que a senha do usuário esteja errada.
O problema pode estar no canal seguro entre o computador e o controlador de domínio. Esse canal é utilizado pelo serviço Netlogon para manter a comunicação confiável entre uma máquina ingressada no Active Directory e os controladores de domínio.
Relatos em ambientes com Windows 11 25H2 também mencionam falhas de Kerberos, seguidas por tentativas de fallback para NTLM e problemas relacionados ao Netlogon. Em alguns casos, credenciais armazenadas em cache continuam permitindo o acesso quando a máquina está desconectada da rede, reforçando a indicação de que o problema está relacionado à autenticação contra o domínio, e não necessariamente à senha do usuário.
Um caso relatado no Microsoft Q&A descreve máquinas que perdiam repetidamente o canal seguro após a instalação da atualização. Outros administradores observaram comportamento semelhante em estações Windows 11 25H2 de seus ambientes.
Entendendo a causa raiz: o isolamento de identidade da máquina
A investigação aponta para o Machine Identity Isolation, recurso de segurança relacionado ao Virtualization-Based Security (VBS) e ao Credential Guard.
O objetivo do mecanismo é aumentar a proteção das credenciais utilizadas pela conta de máquina do Active Directory. Em vez de manter essas informações apenas no armazenamento tradicional do sistema, o recurso pode transferir a proteção das credenciais para o ambiente isolado fornecido pelo Credential Guard.
Essa arquitetura aumenta a resistência contra técnicas que tentam acessar ou roubar credenciais de máquinas ingressadas no domínio.
O problema aparece quando há uma incompatibilidade entre o comportamento esperado desse mecanismo e o estado da máquina após a instalação da KB5124008.
Segundo os relatos técnicos publicados por administradores, o valor de configuração MachineIdentityIsolation pode aparecer como 1 ou 2, correspondendo respectivamente a modos de auditoria ou imposição. Em determinadas máquinas afetadas, a mudança faz com que o segredo da conta de máquina armazenado pelo LSA seja tratado de maneira diferente, comprometendo a capacidade de estabelecer ou manter o canal seguro com o domínio.
O ponto importante é que a Microsoft ainda não confirmou oficialmente essa relação como causa raiz definitiva. Portanto, administradores devem tratar essa explicação como uma hipótese fortemente sustentada pelos testes reproduzidos em ambientes reais, e não como uma conclusão oficial da Microsoft.
Como reparar a relação de confiança afetada pela KB5124008
Antes de alterar o Registro, é importante verificar se o problema realmente está relacionado ao canal seguro do computador.
Abra o PowerShell como administrador e execute:
Test-ComputerSecureChannelSe o resultado for:
Falsehá indicação de que o canal seguro entre a estação e o domínio não está funcionando corretamente. O cmdlet oficial da Microsoft foi desenvolvido justamente para testar e reparar esse relacionamento.
Em uma máquina afetada, administradores relataram como solução temporária a desativação do Machine Identity Isolation, seguida da reconstrução do canal seguro.
1. Faça backup da configuração antes da alteração
Abra o Editor do Registro (regedit.exe) com privilégios administrativos.
Navegue até:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LsaLocalize o valor:
MachineIdentityIsolationAntes de alterar qualquer coisa, faça uma exportação da chave Lsa ou registre o valor original para permitir a reversão posteriormente.
2. Altere temporariamente o MachineIdentityIsolation
Em ambientes nos quais o problema foi reproduzido, administradores relataram a alteração do valor para:
0O comando equivalente no PowerShell, executado como administrador, é:
Set-ItemProperty `
-Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" `
-Name "MachineIdentityIsolation" `
-Type DWord `
-Value 0Depois, reinicie o computador.
Essa alteração deve ser tratada como uma mitigação temporária, não como uma recomendação permanente para desabilitar uma camada de segurança do Windows em toda a organização.
3. Repare o canal seguro
Depois da reinicialização e com a estação conectada novamente à rede corporativa, abra o PowerShell como administrador.
Execute:
Test-ComputerSecureChannel -Repair -Credential (Get-Credential)Será solicitada uma conta com permissões adequadas para executar o reparo.
Também é possível especificar um controlador de domínio:
Test-ComputerSecureChannel `
-Server "DC01.seudominio.local" `
-Repair `
-Credential (Get-Credential)A documentação da Microsoft confirma que o parâmetro -Repair remove e reconstrói o canal utilizado pelo Netlogon. O cmdlet deve ser executado em computadores membros do domínio, e não em controladores de domínio.
Depois do procedimento, valide novamente:
Test-ComputerSecureChannelO resultado esperado é:
TrueEm ambientes maiores, o administrador também pode utilizar ferramentas como Netdom ou Nltest, especialmente quando precisa diagnosticar ou reparar relacionamentos envolvendo controladores de domínio.
Cuidado antes de desativar o isolamento de identidade
Existe um detalhe importante que impede tratar a alteração do Registro como uma solução universal.
O Machine Identity Isolation existe justamente para aumentar a proteção das credenciais da conta de máquina. A documentação da Microsoft alerta que alterações nesse mecanismo podem afetar a autenticação de domínio. Quando o isolamento estava configurado em modo de imposição, simplesmente desativá-lo pode exigir procedimentos adicionais, incluindo remover e ingressar novamente o dispositivo no domínio em determinados cenários.
Por isso, não é recomendável aplicar:
MachineIdentityIsolation = 0em toda a infraestrutura sem antes identificar quais máquinas estão realmente afetadas.
Também é importante verificar GPOs, políticas de Credential Guard e configurações de Virtualization-Based Security. Uma política de domínio pode restaurar automaticamente o valor anterior durante uma atualização de política, fazendo com que o problema reapareça.
O ideal é testar a mitigação primeiro em um pequeno grupo de máquinas, registrar o comportamento e somente depois decidir como tratar o restante do parque.
KB5124008 exige atenção dos administradores
A situação é especialmente delicada porque a KB5124008 é uma atualização de segurança, portanto simplesmente removê-la de maneira generalizada também representa uma decisão com impacto na segurança do ambiente.
Além disso, a Microsoft já publicou uma atualização fora de banda, KB5129195, em 14 de setembro de 2026, para Windows 11 24H2 e 25H2. Entretanto, as notas oficiais disponíveis dessa atualização descrevem correções relacionadas principalmente a RDS e USB Audio Class 1.0, e não apresentam uma correção específica para a falha de confiança de domínio discutida aqui.
Isso significa que administradores devem acompanhar as atualizações oficiais da Microsoft antes de assumir que uma atualização posterior eliminou o problema.
Conclusão
A KB5124008 colocou administradores de Windows 11 diante de um problema particularmente sensível: uma atualização de segurança pode, em determinadas configurações corporativas, resultar na perda do canal seguro entre computadores e o Active Directory.
Os relatos disponíveis apontam para uma possível interação problemática com o Machine Identity Isolation, principalmente quando o mecanismo está em modo de auditoria ou imposição. Entretanto, essa relação ainda está sob investigação da Microsoft e não deve ser confundida com uma confirmação oficial da causa raiz.
Para equipes de suporte, o caminho temporário relatado envolve identificar a falha do canal seguro, ajustar cuidadosamente o MachineIdentityIsolation, reiniciar a estação e executar Test-ComputerSecureChannel -Repair com credenciais administrativas apropriadas.
A recomendação mais importante é evitar mudanças indiscriminadas em toda a infraestrutura. Registre a configuração original, teste a mitigação em poucas máquinas, valide as GPOs e acompanhe a orientação oficial da Microsoft antes de transformar uma correção emergencial em configuração permanente.
Se a sua empresa foi afetada pela KB5124008, deixe um comentário relatando qual versão do Windows 11 está sendo utilizada, se o MachineIdentityIsolation estava configurado como 1 ou 2 e qual procedimento conseguiu restaurar o acesso ao domínio.
