☰

Todos os serviços do ADCS devem ser executados na mesma conta de serviço no mesmo servidor?

tag-icon • tag-icon ad-certificate-services service-accounts
Todos os serviços do ADCS devem ser executados na mesma conta de serviço no mesmo servidor?

Ao implantar o ADCS, na documentação a Microsoft recomenda o uso de contas de serviço para os serviços que compõem o ADCS. O problema é que não aborda se estes devem ser gerenciados individualmente, se podem compartilhar um host, nem se aborda a perda de acesso de um Gerenciador de Servidor remoto porque a delegação Kerberos está envolvida.

Aprendi como consertar isso há algum tempo porque é o mesmo problema quandoADFS*é implantado: o controle do computador é roubado pela conta de serviço, mas,como você deve saber,ele pode ser recuperado simplesmente adicionando aliases do Active Directory (CNAMEs) à conta da máquina. por exemplo;

        …se o CA se chamasse LOCKSMITH…

netdom computername locksmith /add:ceslocksmith.domain.tld
netdom computername locksmith /add:ceplocksmith.domain.tld
netdom computername locksmith /add:nedeslocksmith.domain.tld

        …ou talvez até subdomínios; (Eu nunca tentei esse pensamento)

netdom computername locksmith /add:ces.locksmith.domain.tld
…

Então eu estava me perguntando isso,seEu adiciono aliases para cada uma das contas de serviço que o ADCS pode usar (CES, CEP, NDES). Eu poderia executar cada uma conforme recomendação, mas na mesma máquina -provavelmente contra as melhores práticas, mas você sabe- exceto que encontrei essa coisa em algum tipo de fórum onde dizia issomúltiplas instâncias do CES(presumo que em uma fazenda) todos deveriam funcionar com omesma conta de serviço. Nenhuma menção aos outros serviços foi feita. Mas eles também deveriam compartilhar a mesma conta de serviço ou é aceitável para serviços individuaisamarrado a umsolteiroCA corporativacada um executado em sua própria conta de serviço?

Obrigado.

*: na verdade é pior para o ADFS porque há vários anos a documentação indica erroneamente o uso do Kerberos errado service/PRINCIPAL. Indica host, em vez do httpserviço. Dando controle dehttppara uma conta, no máximo, bloqueia você do administrador remoto/remoting do PowerShell, mas conceder o controle do host fora da conta da máquina o deixa órfão do domínio. O pior é que isso é repetido literalmente porMVPse outros em seus próprios blogs.

Responder1

Isso provavelmente é irrelevante agora, dado o atraso e não é uma resposta completa, mas vamos lá:

O conector NDES (para SCEP) não deve ser instalado em um servidor CA emissor, o que significa que isso está fora da equação. Ele deve ser executado como sua própria conta de serviço com os direitos apropriados de "Emitir certificado" delegados na CA, além de outros requisitos, pora documentação.

Para CES/CEP, você só os instalaria conforme necessário - por exemplo, para inscrições de certificados de usuários externos/máquinas não ingressadas em domínios ou entre domínios. Pessoalmente, fico mais feliz se eles não estiverem no servidor CA, mas vocêpodeimplantá-los lá. Por padrão, eles usam a identidade do pool de aplicativos para o serviço web, mas você pode (e deve) alterá-la para uma conta de usuário de domínio. Observe também que você pode usar um (g)MSA para executar os serviços.Esta documentaçãoé bastante antigo, mas ainda é o mais completo.

A documentação observa que se você instalar o CES/CEP na CA, poderá encontrar o seguinte problema. É por isso que eu pessoalmente executaria esses serviços em outro lugar,seeles são obrigatórios.

Se outros serviços http/https autenticados Kerberos estiverem em execução no mesmo host que um serviço Web de política de registro de certificado ou serviço Web de registro de certificado configurado para autenticação Kerberos, poderão ocorrer falhas de registro devido a uma colisão de SPN. A resolução é configurar todos os serviços para serem executados como a mesma conta de usuário

Por fim, não está claro qual documentação você pode estar seguindo ou qual versão do ADCS você está implantando, mas lembre-se de proteger os servidores CA contra ataques de retransmissão NTLM, porKB5005413. Idealmente, isso significa desabilitar a autenticação NTLM nos controladores de domínio (muito difícil na maioria dos ambientes corporativos) ou, alternativamente, em cada servidor CS (ou seja, servidores CA ou CES). As soluções alternativas mínimas exigem https e configuram a Proteção Estendida para Autenticação (EPA) nos serviços web de registro.

informação relacionada