Resumo
As proteções para o CVE-2022-21920 estão incluídas nas atualizações de Windows de 11 de janeiro de 2022 e Windows posteriores. Essas atualizações contêm lógica aprimorada para detectar ataques de downgrade para nomes de entidades de serviço de 3 partes ao usar o protocolo de autenticação do Microsoft Negotiate.
Este artigo fornece orientações quando a autenticação Kerberos não é bem-sucedida.
Mais informações
A instalação das atualizações de Windows de 11 de janeiro de 2022 e posteriores Windows pode causar falha na autenticação para SPNs de 3 partes em que a autenticação Kerberos não é bem-sucedida. Para esses ambientes, é provável que a autenticação Kerberos para SPNs de 3 partes não tenha funcionado há algum tempo. Você pode ver o seguinte evento em sistemas Windows Cliente para ajudar a triagem.
|
Captura de tela do evento LSA 40970 identificando um fallback NTLM para um SPN específico de um ambiente de teste da Microsoft. |
Versão texto do evento LSA 40970 |
|
|
O Sistema de Segurança detectou uma tentativa de downgrade ao entrar em contato com o SPN de 3 partes <nome SPN> com código de erro "O banco de dados SAM no servidor Windows não tem uma conta de computador para a relação de confiança da estação de trabalho (0x0000018b)" A autenticação foi negada. |
Ação
A Microsoft recomenda que você triagem por que a autenticação Kerberos para o SPN de 3 partes falhou. Alguns motivos comuns para a falha de autenticação Kerberos incluem:
-
O SPN que está sendo usado como destino para autenticação está malformado. Para obter mais informações, consulte Name Formats for Unique SPNs.
Observação: Aplicativos e APIs podem ter definições mais estritas ou diferentes para o que constitui um SPN legítimo para seu serviço.
Exemplos de um SPN legítimo
http/webserver
Host/machine2.contoso.com
Ldap/machine1.contoso.com/contoso.com
Serviço/máquina1:10100
Exemplos de SPNs possivelmente malformadosSPN
Motivo
Host/host/machine1
Host/host é provavelmente um erro, já que "host" geralmente é uma classe de serviço e não um nome de máquina. É possível que o SPN legítimo seja host/machine1.
Ldap/machine/contoso.com:10100
As portas podem ser especificadas no nome do host ("máquina") e não no nome da instância de serviço. É possível que o SPN legítimo seja "ldap/machine:10100/contoso.com"
Ldap/dc-a/DC=CONTOSO,DC=COM
Determinadas APIs esperam um nome DNS em vez de um FQDN. Por exemplo, a função DsBindA (ntdsapi.h) espera ser passada em um nome DNS. Se um FQDN for passado, ele poderá resultar no SPN malformado.
O SPN legítimo pode ser "ldap/dc-a/contoso.com"Para resolver esses problemas, considere usar o SPN correto ou registrar o SPN malformado na conta de serviço correta.
-
O SPN que está sendo usado como o destino da autenticação não existe. Para resolver esse problema, considere registrar o SPN na conta de serviço correta.
-
A Windows cliente não tem Linha de Visão para um controlador de domínio (como os DCs estão offline, não podem ser descobertos no DNS ou o acesso à porta KDC está bloqueado).
-
Você pode estar usando nomes NetBIOS em um cenário em que os nomes NetBIOS não funcionam. Um exemplo é acessar recursos de domínio de uma máquina não ingressada no domínio e a resolução de nome do NetBIOS está desabilitada ou não está funcionando.
A Microsoft recomenda o uso de um UPN (Nome de Entidade de Usuário) ou um Dns (Sistema de Nomes de Domínio) name em vez do nome NetBIOS.
Registrando SPNs
Dependendo da configuração do aplicativo e do seu ambiente, os SPNs podem ser configurados no atributo Service Principal Name da conta de serviço ou na conta do computador localizada no domínio do Active Directory com o qual o cliente Kerberos está tentando estabelecer a conexão Kerberos. Para que a autenticação Kerberos funcione corretamente, o SPN de destino deve ser válido.
Consulte a documentação de implantação ou o provedor de suporte para cada aplicativo específico para obter orientações sobre como habilitar a autenticação Kerberos. Alguns instaladores de aplicativos ou aplicativos registram SPNs automaticamente. Há opções diferentes para desenvolvedores e administradores registrarem um SPN:
-
Para registrar manualmente SPNs para uma instância de serviço, consulte Setspn.
-
Para registrar programaticamente SPNs para uma instância de serviço, consulte How a Service Registers its SPNs descrevendo como:
-
Chame a função DsGetSpn para criar um ou mais SPNs exclusivos para a instância do serviço. Para obter mais informações, consulte Name Formats for Unique SPNs.
-
Chame a função DsWriteAccountSpn para registrar os nomes na conta de logon do serviço.
-
Problemas conhecidos
Atualmente, não há problemas conhecidos com essa atualização.
