☰

¿Todos los servicios de ADCS deben ejecutarse con la misma cuenta de servicio en el mismo servidor?

tag-icon • tag-icon ad-certificate-services service-accounts
¿Todos los servicios de ADCS deben ejecutarse con la misma cuenta de servicio en el mismo servidor?

Al implementar ADCS, en la documentación, Microsoft recomienda usar cuentas de servicio para los servicios que componen ADCS. El problema es que no aborda si estos deben administrarse individualmente, si podrían compartir un host, ni aborda la pérdida de acceso desde un Administrador de servidor remoto porque está involucrada la delegación de Kerberos.

Aprendí cómo solucionar este problema hace un tiempo porque es el mismo problema cuandoADFS*se implementa: la cuenta de servicio roba el control de la computadora pero,como probablemente sabes,se puede recuperar simplemente agregando alias de Active Directory (CNAME) a ​​la cuenta de la máquina. p.ej;

        …si el CA se llamara CERRAJERO…

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

        …o tal vez incluso subdominios; (Nunca he probado este pensamiento)

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

Entonces me preguntaba eso,siAgrego alias para cada una de las cuentas de servicio que ADCS podría usar (CES, CEP, NDES). Podría ejecutar cada una según la recomendación, pero en la misma máquina.probablemente en contra de las mejores prácticas, pero ya sabes- excepto que encontré esto en algún lugar tipo foro donde decía quemúltiples instancias de CES(Supongo que en una granja) todos deberían ejecutarse con elmisma cuenta de servicio. No se hizo mención de los otros servicios. Pero, ¿deberían ellos también compartir la misma cuenta de servicio o está bien para servicios individuales?atado a unsolteroCA empresarial¿Para que cada uno ejecute su propia cuenta de servicio?

Gracias.

*: en realidad, es peor para ADFS porque durante varios años la documentación ha indicado erróneamente que se debe utilizar el Kerberos incorrecto service/PRINCIPAL. Indica host, en lugar del httpservicio. Dar control dehttpa una cuenta como máximo le impide acceder a la comunicación remota de administración remota/PowerShell, pero otorgar el control del host fuera de la cuenta de la máquina lo deja huérfano del dominio. Lo peor es que esto lo repiten palabra por palabraMVPs y otros en sus propios blogs.

Respuesta1

Probablemente esto sea irrelevante a estas alturas, dado el retraso de tiempo y no una respuesta completa, pero allá vamos:

El conector NDES (para SCEP) no debe instalarse en un servidor CA emisor, por lo que significa que está fuera de la ecuación. Debe ejecutarse como su propia cuenta de servicio con los derechos apropiados de "Emitir certificado" delegados en la CA más los demás requisitos, segúnla documentación.

Para CES/CEP, solo los instalará según sea necesario, por ejemplo, para máquinas entre dominios o no unidas a dominios/inscripciones de certificados de usuarios externos. Personalmente, estoy más feliz si no están en el servidor de CA, pero túpoderdesplegarlos allí. De forma predeterminada, utilizan la identidad del grupo de aplicaciones para el servicio web, pero usted puede (y debe) cambiarla a una cuenta de usuario de dominio. También tenga en cuenta que puede utilizar un (g)MSA para ejecutar los servicios.Esta documentaciónEs bastante antiguo, pero sigue siendo el más completo.

La documentación señala que si instala CES/CEP en la CA, puede encontrar el siguiente problema. Es por eso que yo personalmente ejecutaría estos servicios en otro lugar,sison requeridos.

Si otros servicios http/https autenticados por Kerberos se ejecutan en el mismo host que un servicio web de política de inscripción de certificados o un servicio web de inscripción de certificados configurado para la autenticación Kerberos, pueden producirse errores de inscripción debido a una colisión de SPN. La resolución es configurar todos los servicios para que se ejecuten como la misma cuenta de usuario.

Finalmente, no está claro qué documentación podría estar siguiendo o qué versión de ADCS está implementando, pero recuerde proteger los servidores de CA contra ataques de retransmisión NTLM, segúnKB5005413. Idealmente, esto significa deshabilitar la autenticación NTLM en los controladores de dominio (bastante difícil en la mayoría de los entornos empresariales) o, alternativamente, en cada servidor CS (es decir, servidores CA o CES). Las soluciones mínimas son requerir https y configurar la Protección extendida para la autenticación (EPA) en los servicios web de inscripción.

información relacionada