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 Alguns campos, como Emissor, Assunto e Número de Série, são comunicados num formato "forward". Tem de inverter este formato quando adicionar a cadeia de carateres de mapeamento ao atributo altSecurityIdentities . Por exemplo, para adicionar o mapeamento X509IssuerSerialNumber a um utilizador, pesquise os campos "Emissor" e "Número de série" do certificado que pretende mapear para o utilizador. Veja o resultado de exemplo abaixo.

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

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>1200000000AC1100000002B"

Para atualizar esse atributo usando o PowerShell, você pode usar o comando abaixo. Lembre-se de que, por padrão, apenas 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>120000000AC11000000002B"}

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

Assim que tiver instalado 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 só puder ser mapeado de forma fraca para um usuário, a autenticação ocorrerá conforme o esperado. No entanto, será registada uma mensagem de aviso, a menos que o certificado seja mais antigo do que o utilizador. Se o certificado for mais antigo do que o utilizador e a chave de registo de Datação de Certificado não estiver presente ou o intervalo estiver fora da compensação de retrodatação, a autenticação falhará e será registada uma mensagem de erro.  Se a chave do Registro Certificate Backdating estiver configurada, ela registrará uma mensagem de aviso no log de eventos se as datas se enquadrarem na compensação de retrocesso.

Depois de instalar as atualizações do Windows de 10 de maio de 2022, esteja atento a qualquer mensagem de aviso que possa aparecer após um mês ou mais. Se não existirem mensagens de aviso, recomendamos vivamente que ative o modo de Imposição Total em todos os controladores de domínio utilizando autenticação baseada em certificados. Pode utilizar a chave do registo KDC para ativar o modo de Imposição Completa.

A menos que sejam atualizados para o modo de Auditoria ou o modo de Imposição através da chave de registo 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 não for possível mapear fortemente um certificado. A opção para voltar ao Modo de compatibilidade permanecerá até que a atualização de segurança do Windows de 9 de setembro de 2025 seja instalada. Após esta data, a chave de registo StrongCertificateBindingEnforcement deixará de ser suportada

Se a autenticação baseada em certificado depender de um mapeamento fraco que você não pode mover do ambiente, poderá colocar os controladores de domínio no modo Desativado usando uma configuração de chave do Registro. A Microsoft não recomenda isto e vamos remover o modo Desativado a 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 suportar os clientes com a funcionalidade opcional RSAT instalada, o mapeamento de certificados em Utilizadores & Computadores do Active Directory irá selecionar por predefinição o mapeamento forte com o X509IssuerSerialNumber em vez do mapeamento fraco com o 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 Política de Grupo não tenham sido alterados" sob o objeto Política de Grupo "Computer Configuration>Administrative Templates>System>Política de Grupo>Configure o processamento da diretiva do Registro" pode interferir intermitentemente com os mapeamentos baseados em nome em controladores de domínio.

Solução

Para contornar esse problema, desative a configuração "Processar mesmo que os objetos Política de Grupo não tenham sido alterados" nos controladores de domínio. Só efetue este procedimento se forem necessários mapeamentos baseados no nome, conforme definido no Política de Grupo "Computer Configuration>Administrative Templates>System>KDC>Allow name-based strong mappings for certificates". Para obter mais informações, consulte Habilitar mapeamento baseado em nome forte em cenários governamentais.

Próximo passo

Estamos a investigar estas denúncias e iremos fornecer mais informações assim que estiverem disponíveis.

• Use o log operacional Kerberos no computador relevante para determinar qual controlador de domínio está falhando no login. Aceda a Visualizador de Eventos>Registos de Aplicações e Serviços Segurança\do Microsoft \Windows-Kerberos\\Operacional.
• Procure eventos relevantes no Registo de Eventos de Sistema no controlador de domínio contra o qual a conta está a tentar autenticar.
• Se o certificado for mais antigo que a conta, reemita 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 possa ser adicionado um.

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 , estes cenários utilizam o protocolo Kerberos Certificate Service For User (S4U) para mapeamento e autenticação de certificados por predefinição.
• No protocolo Kerberos Certificate S4U, 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á ao usar métodos de mapeamento de certificado fracos.

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. Inicie sessão num servidor de Autoridade de Certificação ou num cliente Windows 10 associado a um domínio com as credenciais de administrador da empresa ou equivalente.
2. Abra uma linha de comandos e selecione Executar como administrador.
3. Run certutil -dstemplate user msPKI-Enrollment-Flag +0x00080000.

A desativação da adição desta extensão removerá a proteção fornecida pela nova extensão. Considere efetuar este procedimento apenas depois de uma das seguintes opções:

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

Os ambientes com implementações de AC que não sejam da Microsoft não serão protegidos com 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 suporte e recursos adicionais, consulte a secção "Recursos adicionais".

Não, não é necessária a renovação. A autoridade de certificação será enviada 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 se encontrem em Imposição (o valor de registo StrongCertificateBindingEnforcement está definido como 2) serão movidos para a Aplicação. Se a autenticação for negada, verá o ID de Evento 39 (ou ID de Evento 41 para Windows Server 2008 R2 SP1 e Windows Server 2008 SP2). Nesta fase, terá a opção de voltar a definir o valor da chave de registo como 1 (Modo de compatibilidade).

Na atualização do Windows de 9 de setembro de 2025, o valor de registo StrongCertificateBindingEnforcement deixará de ser suportado.