Atualmente estou trabalhando na implementação de uma Autoridade de Certificação Corporativa para um cliente cuja rede não está totalmente conectada; ele abrange vários sites geográficos e alguns deles não têm roteamento para o site onde a autoridade de certificação está localizada.
Para contornar isso, usei o Certificate Enrollment Web Service , que permite a inscrição de certificados via HTTPS; o serviço é exposto por meio de um nome público e endereço IP, e os computadores nos sites remotos podem acessá-lo dessa maneira.
A solução funciona muito bem para todos os tipos de certificados; no entanto, os controladores de domínio nos sites remotos não conseguem obter um certificado usando o modelo "Autenticação Kerberos" (que os DCs recentes tentam usar quando o registro automático está habilitado); o erro é um genérico "o servidor RPC está indisponível", mas acontece na própria CA , ficando logado nas requisições com falha.
Isso me intrigou por um tempo, até que decidi examinar o tráfego da rede; e eis que, parece que quando uma solicitação de certificado é feita usando o modelo "Autenticação Kerberos", a CA tenta se conectar novamente ao controlador de domínio que fez a solicitação . Isso não é possível na rede do cliente e parece ser a razão pela qual a solicitação falha.
Acho que a CA está tentando validar que o computador que está solicitando o certificado é na verdade um controlador de domínio; no entanto, não consegui encontrar nenhuma documentação para isso, e esse "retorno de chamada" parece contrário à lógica cliente/servidor das solicitações de certificado.
Esse comportamento está documentado em algum lugar?
Pode ser desligado?
O sistema operacional na CA é o Windows Server 2019.
Editar
Há quatro domínios na floresta do AD; a CA está no domínio raiz da floresta.
O comportamento é o mesmo para todos os DCs em todos os domínios: sempre que é feita uma solicitação de certificado "Autenticação Kerberos", seja manualmente ou via autoinscrição, a CA tenta entrar em contato com o DC solicitante nas portas 445 e 139 (estranhamente, há nenhum tráfego real de LDAP, Kerberos ou RPC); quando isso falha, a solicitação é negada com o erro "negado pelo módulo de política" e o código de status "o servidor RPC não está disponível".
Isso só acontece para certificados de "Autenticação Kerberos"; todos os outros certificados podem ser registrados com sucesso via CES, incluindo "Autenticação de controlador de domínio" e "Replicação de e-mail de diretório".
Eu também testei isso para DCs que podem realmente conversar com o CA: se o tráfego for bloqueado do DC para o CA, forçando a solicitação a usar o CES, mas não o contrário, as solicitações serão bem-sucedidas; se o tráfego for bloqueado da CA para o DC, a solicitação falhará.
De acordo com a documentação, o comportamento que você está enfrentando é esperado, por design e não pode ser desativado.
Kerberos Authenticationrequer uma conexão RPC de CA para DC. Quais são as opções para você:Domain Contoller Authenticationo modelo de certificado em vez doKerberos Authenticationmodelo.Domain Contoller Authenticationmodelo não requer conexão RPC de volta ao DC.Na verdade, eu não me lembrava de todos os detalhes e elogios para você, que você fez uma boa investigação e apontou sobre uma falha de retorno de chamada RPC, isso realmente reduziu a quantidade de motivos possíveis. Detalhes completos sobre por que isso acontece estão abaixo.
TL;DR
Parte 1
Em primeiro lugar, sobre os modelos de certificado: ambos
Domain Controller AuthenticationeKerberos Authenticationos modelos são usados para fornecer suporte para LDAP S (LDAP sobre TLS) e autenticação mútua durante o logon do certificado/smar card.A diferença entre dois é como o sujeito é construído, ou o que está incluído nele.
Domain Controller Authenticationinclui o FQDN do controlador de domínio somente na extensão SAN.Kerberos Authenticationadiciona mais dois nomes: nomes de domínio FDQN e NetBIOS. Além disso,Kerberos Authenticationadiciona umKDC AuthenticationEKU. A configuração do modelo padrão é definida em [MS-CRTD], Apêndice A . Para ser mais claro:Domain Controller Authenticationnome do assunto tem 134217728 (0x8000000) combinação de sinalizador, que se traduz em apenas sinalizador:CT_FLAG_SUBJECT_ALT_REQUIRE_DNSKerberos Authenticationnome do assunto tem 138412032 (0x8400000) combinação de sinalizadores, que se traduz em dois sinalizadores:CT_FLAG_SUBJECT_ALT_REQUIRE_DNSeCT_FLAG_SUBJECT_ALT_REQUIRE_DOMAIN_DNS.Os sinalizadores de nome do assunto são armazenados no
msPKI-Certificate-Name-Flagatributo ( [MS-CRTD] §2.28 ).O problema em sua pergunta é causado pelo requisito na SAN de incluir nomes de FQDN e NetBIOS de domínio.
Kerberos Authenticationtemplate é o único template padrão que usaCT_FLAG_SUBJECT_ALT_REQUIRE_DOMAIN_DNSflag.Parte 2
A CA do Windows usa a especificação do protocolo [MS-WCCE] para processar solicitações e emitir certificados. Este protocolo especifica completamente o comportamento do cliente e uma pequena parte da interação e comportamento do Windows CA. [MS-WCCE] §3.2.2.1.3 define um comportamento especial para clientes que são controladores de domínio e preparam seus nomes para estarem prontos para conexão RPC, acrescentando "\\".
Parte 3
A CA do Windows processa o
CT_FLAG_SUBJECT_ALT_REQUIRE_DOMAIN_DNSconforme especificado em [MS-WCCE] §3.2.2.6.2.1.4.5.9 .Como você pode ver,
LsarOpenPolicycall é de fato a chamada RPC e retorna um identificador para a conexão RPC em caso de sucesso. No seu caso, essa chamada falha e a CA não pode chamarLsarQueryInformationPolicy(que é chamada RPC novamente!) para obter os nomes necessários para inserir no certificado.Resultado final
Pode haver um desejo de desativar o FQDN do domínio e o nome NetBIOS do domínio no
Kerberos Authenticationmodelo, mas eu não recomendaria isso. Nem tentar adicionarKDC AuthenticationEKU aDomain Controller Authentication, porque primeiro depende estritamente da presença do domínio FQDN e NetBIOs que causam problemas em seu ambiente.Para contornar a chamada RPC de volta ao seu DC, você pode duplicar o modelo Kerberos e adicionar as SANs manualmente. Em seguida, ative a renovação automática.
Aqui estão os passos -
Configurar modelo:
duplicar o modelo kerberos
configure o nome do assunto dos novos modelos para 'fornecer na solicitação'
No seu WES:
iisreset para atualizar a lista de modelos
Inscreva o certificado:
Em seu DC isolado, registre um certificado e adicione os nomes de domínio na extensão SAN (isso não fará a chamada RPC de volta da CA para o DC).
(Se você não conseguir ver o modelo, limpe o cache WES local em C:\ProgramData\Microsoft\Windows\X509Enrollment)
Habilite a renovação automática (via GPO):
Configurações do Windows > Configurações de segurança > Políticas de chave pública > Cliente de serviços de certificados - Registro automático. Basta marcar apenas 'Renovar certificados expirados, atualizar certificados pendentes e remover certificados revogados'
Testando a renovação automática:
No novo modelo - clique com o botão direito e escolha 'Reinscrever todos os titulares de certificados'. Isso aumentará a versão principal do modelo e forçará a renovação do certificado no próximo ciclo de inscrição automática (uma vez em 8 horas).
Se você não quiser esperar - então reinicie o WES, exclua a pasta local x509enrollment e execute 'certutil -pulse'
Boa sorte