KB5014754: Alterações de autenticação baseadas em certificados em controladores de domínio do Windows

Não foi possível encontrar mapeamentos de certificados sólidos e o certificado não tinha a extensão SID (New Security Identifier) que o KDC poderia validar.

O certificado foi emitido para o utilizador antes de este existir no Active Directory e não foi possível encontrar um mapeamento seguro. Este evento só é registado quando o KDC está no Modo de compatibilidade.

O SID contido na nova extensão do certificado do usuário não corresponde ao SID do usuário, implicando que o certificado foi emitido para outro usuário.

Observação Determinados campos, como Emissor, Assunto e Número de Série, são relatados em um formato "encaminhar". Você deve reverter esse formato ao adicionar a cadeia de caracteres de mapeamento ao atributo altSecurityIdentities . Por exemplo, para adicionar o mapeamento X509IssuerSerialNumber a um usuário, pesquise os campos "Emissor" e "Número de Série" do certificado que você deseja mapear para o usuário. Veja o exemplo de saída abaixo.

• Emissor: CN=CONTOSO-DC-CA, DC=contoso, DC=com
• Número de série: 2B0000000011AC0000000012

Em seguida, atualize o atributo altSecurityIdentities do usuário no Active Directory com a seguinte cadeia de caracteres:

• "X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>1200000000AC11000000002B"

Para atualizar esse atributo usando o Powershell, você pode usar o comando abaixo. Lembre-se de que, por padrão, somente os administradores de domínio têm permissão para atualizar esse atributo.

• set-aduser 'DomainUser' -replace @{altSecurityIdentities= "X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>1200000000AC11000000002B"}

Observe que, ao inverter o SerialNumber, você deve manter a ordem de bytes. Isso significa que a inversão do SerialNumber "A1B2C3" deve resultar na cadeia de caracteres "C3B2A1" e não em "3C2B1A". Para obter mais informações, consulte HowTo: Mapear um usuário para um certificado por meio de todos os métodos disponíveis no atributo altSecurityIdentities.

Depois de instalar as atualizações do Windows de 10 de maio de 2022, os dispositivos estarão no modo de compatibilidade. Se um certificado puder ser fortemente mapeado para um usuário, a autenticação ocorrerá conforme o esperado. Se um certificado puder ser mapeado apenas fracamente para um usuário, a autenticação ocorrerá conforme o esperado. No entanto, uma mensagem de aviso será registrada, a menos que o certificado seja mais antigo que o usuário. Se o certificado for mais antigo que o usuário e a chave do Registro com data retroativa de certificado não estiver presente ou o intervalo estiver fora da compensação de data retroativa, a autenticação falhará e uma mensagem de erro será registrada.  Se a chave do Registro com retrocesso de certificado estiver configurada, ela registrará uma mensagem de aviso no log de eventos se as datas estiverem dentro da compensação com retrocesso.

Depois de instalar as atualizações do Windows de 10 de maio de 2022, observe qualquer mensagem de aviso que possa aparecer após um mês ou mais. Se não houver mensagens de aviso, recomendamos expressamente que você habilite o modo de Imposição Total em todos os controladores de domínio usando autenticação baseada em certificado. Você pode usar a chave do Registro KDC para habilitar o modo de Imposição Total.

A menos que sejam atualizados para o modo de auditoria ou de imposição usando a chave do Registro StrongCertificateBindingEnforcement anteriormente, os controladores de domínio passarão para o modo de imposição total quando a atualização de segurança do Windows de fevereiro de 2025 for instalada. A autenticação será negada se um certificado não puder ser fortemente mapeado. A opção de voltar para o Modo de compatibilidade permanecerá até que a atualização de segurança do Windows de 9 de setembro de 2025 seja instalada. Após essa data, a chave do Registro StrongCertificateBindingEnforcement não terá mais suporte

Se a autenticação baseada em certificado depender de um mapeamento fraco que você não pode mover do ambiente, você poderá colocar controladores de domínio no modo Desabilitado usando uma configuração de chave do Registro. A Microsoft não recomenda isso e removeremos o modo Desabilitado em 11 de abril de 2023.

Depois de instalar as atualizações do Windows de 13 de fevereiro de 2024 ou posteriores no Server 2019 e superior e dar suporte aos clientes com o recurso opcional RSAT instalado, o mapeamento de certificado em Usuários & Computadores do Active Directory usará como padrão a seleção de mapeamento forte usando X509IssuerSerialNumber em vez de mapeamento fraco usando X509IssuerSubject. A configuração ainda pode ser alterada conforme desejado.

Sintomas

A Microsoft recebeu relatórios de que a configuração "Processar mesmo que os objetos da Política de Grupo não tenham sido alterados" no objeto da Política de Grupo "Configuração> do Grupo,Modelos> Administrativos,Sistema>, Política de GrupoConfigurar o processamento de política do Registro>" pode interferir intermitentemente nos mapeamentos baseados em nome em controladores de domínio.

Solução alternativa

Para contornar esse problema, desabilite a configuração "Processar mesmo se os objetos da Política de Grupo não tiverem sido alterados" nos controladores de domínio. Faça isso somente se forem necessários mapeamentos baseados em nome, conforme definido na Política de Grupo "Configuração> do Computador,Modelos> Administrativos,Sistema>KDC>:Permitir mapeamentos fortes baseados em nome para certificados". Para obter mais informações, consulte Habilitar mapeamento forte baseado em nomes em cenários governamentais.

Próxima etapa

Estamos investigando esses relatórios e forneceremos mais informações quando estiverem disponíveis.

• Use o log operacional Kerberos no computador relevante para determinar qual controlador de domínio está falhando ao entrar. Vá para o Visualizador de EventosLogs\ de >Aplicativos e ServiçosSegurança do Microsoft \Windows\- Kerberos\Operacional.
• Procure eventos relevantes no Log de Eventos do Sistema no controlador de domínio no qual a conta está tentando se autenticar.
• Se o certificado for mais antigo que a conta, emita novamente o certificado ou adicione um mapeamento altSecurityIdentities seguro à conta (consulte Mapeamentos de certificado).
• Se o certificado contiver uma extensão SID, verifique se o SID corresponde à conta.
• Se o certificado estiver sendo usado para autenticar várias contas diferentes, cada conta precisará de um mapeamento altSecurityIdentities separado.
• Se o certificado não tiver um mapeamento seguro para a conta, adicione um ou deixe o domínio no modo de Compatibilidade até que um possa ser adicionado.

Um exemplo de mapeamento de certificado TLS é usar um aplicativo Web da intranet do IIS.

• Depois de instalar as proteções CVE-2022-26391 e CVE-2022-26923 , esses cenários usam o protocolo S4U (Serviço de Certificado Kerberos para Usuário) para mapeamento e autenticação de certificado por padrão.
• No protocolo S4U do Certificado Kerberos, a solicitação de autenticação flui do servidor de aplicativos para o controlador de domínio, não do cliente para o controlador de domínio. Portanto, eventos relevantes estarão no servidor de aplicativos.

Esta chave de registo não será suportada após a instalação das atualizações do Windows lançadas em ou depois de setembro de 2025.

Quando um aplicativo de servidor requer autenticação de cliente, Schannel tenta mapear automaticamente o certificado que o cliente TLS fornece para uma conta de usuário. Você pode autenticar usuários que entram com um certificado de cliente criando mapeamentos que relacionam as informações do certificado a uma conta de usuário do Windows. Depois de criar e habilitar um mapeamento de certificado, cada vez que um cliente apresentar um certificado de cliente, seu aplicativo de servidor associará automaticamente esse usuário à conta de usuário apropriada do Windows.

O Schannel tentará mapear cada método de mapeamento de certificado habilitado até que um seja bem-sucedido. O Schannel tenta mapear os mapeamentos de Service For-User-To-Self (S4U2Self) primeiro. Os mapeamentos de certificado Assunto/Emissor, Emissor e UPN são agora considerados fracos e foram desativados por predefinição. A soma mascarada de bits das opções selecionadas determina a lista de métodos de mapeamento de certificados disponíveis.

O padrão da chave do Registro SChannel foi 0x1F e agora está 0x18. Se você tiver falhas de autenticação com aplicativos de servidor baseados em Schannel, sugerimos que você execute um teste. Adicione ou modifique o valor da chave do Registro CertificateMappingMethods no controlador de domínio e defina-o como 0x1F e veja se isso resolve o problema. Procure mais informações nos registos de eventos do sistema no controlador de domínio para ver se existem erros listados neste artigo. Tenha em mente que alterar o valor da chave do Registro SChannel de volta para o padrão anterior (0x1F) reverter usar métodos de mapeamento de certificado fraco.

Para obter suporte e recursos adicionais, consulte a secção "Recursos adicionais".

Depois de instalar as atualizações que abordam CVE-2022-26931 e CVE-2022-26923, a autenticação pode falhar se os certificados de utilizador forem mais antigos do que a hora de criação dos utilizadores. Essa chave do Registro permite a autenticação bem-sucedida quando você está usando mapeamentos de certificado fracos em seu ambiente e o tempo do certificado é antes do tempo de criação do usuário dentro de um intervalo definido. Esta chave de registo não afeta os utilizadores ou máquinas com mapeamentos de certificados fortes, uma vez que a hora do certificado e a hora de criação do utilizador não são verificadas com mapeamentos de certificados fortes. Esta chave do registo não tem qualquer efeito quando StrongCertificateBindingEnforcement está definido como 2.

A utilização desta chave de registo é uma solução temporária para ambientes que a exijam e tem de ser feita com cuidado. A utilização desta chave de registo significa o seguinte para o seu ambiente:

• Esta chave de registo só funciona no Modo de compatibilidade a partir das atualizações disponibilizadas a 10 de maio de 2022. A autenticação será permitida dentro do deslocamento de compensação de backdate, mas um aviso de log de eventos será registrado para a vinculação fraca.
• A ativação dessa chave do Registro permite a autenticação do usuário quando a hora do certificado é anterior à hora de criação do usuário dentro de um intervalo definido como um mapeamento fraco. Os mapeamentos fracos não serão suportados após a instalação das atualizações do Windows lançadas em ou após setembro de 2025.

Execute o seguinte comando certutil para excluir certificados do modelo de usuário de obter a nova extensão.

1. Entre em um servidor de Autoridade de Certificação ou em um cliente do Windows 10 ingressado no domínio com credenciais de administrador corporativo ou equivalentes.
2. Abra um prompt de comando e escolha Executar como administrador.
3. Execute certutil -dstemplate user msPKI-Enrollment-Flag +0x00080000.

Desabilitar a adição dessa extensão removerá a proteção fornecida pela nova extensão. Considere fazer isso somente após uma das seguintes opções:

1. Você confirma que os certificados correspondentes não são aceitáveis para PKINIT (Criptografia de Chave Pública para Autenticação Inicial) em autenticações de Protocolo Kerberos no KDC
2. Os certificados correspondentes têm outros mapeamentos de certificados fortes configurados

Ambientes com implantações de autoridades de certificação não pertencentes à Microsoft não serão protegidos usando a nova extensão SID após a instalação da atualização do Windows de 10 de maio de 2022. Os clientes afetados devem trabalhar com os fornecedores de CA correspondentes para resolver isso ou devem considerar a utilização de outros mapeamentos de certificados fortes descritos acima.

Para obter recursos e suporte adicionais, consulte a seção "Recursos adicionais".

Não, a renovação não é necessária. A CA será fornecida no modo de compatibilidade. Se você quiser um mapeamento forte usando a extensão ObjectSID, precisará de um novo certificado.

Na atualização do Windows de 11 de fevereiro de 2025, os dispositivos que ainda não estão em Aplicação (o valor do Registro StrongCertificateBindingEnforcement é definido como 2) serão movidos para a Imposição. Se a autenticação for negada, você verá a ID do Evento 39 (ou a ID do Evento 41 para o Windows Server 2008 R2 SP1 e o Windows Server 2008 SP2). Você terá a opção de definir o valor da chave do Registro de volta como 1 (Modo de compatibilidade) nesta fase.

Na atualização do Windows de 9 de setembro de 2025, o valor do Registro StrongCertificateBindingEnforcement não terá mais suporte.