Recientemente realizamos una implementación de nuestro producto Certificate Management System (CMS) versión 4.0 para un cliente y nos encontramos con un extraño problema con la implementación de Microsoft de SCEP -el servicio de rol de autoridad de certificados Microsoft Network Device Enrollment Service (NDES) bajo el rol Active Directory Certificate Services (AD CS)- en Windows Server 2012 R2 que nunca habíamos encontrado antes. He pensado en contároslo para que, en caso de que os encontréis con este problema, no tengáis que daros cabezazos contra la pared tanto tiempo como nosotros antes de encontrar una solución.
El NDES de Microsoft se utiliza junto con el CMS para permitir el registro de certificados desde dispositivos iOS. En esta implementación particular del cliente, CMS estaba siendo instalado en el mismo servidor en el cual el rol de Microsoft NDES estaba instalado. Este es un diseño de implementación común. Tanto CMS como NDES se ejecutan bajo IIS, pero CMS requiere más servicios de rol IIS que NDES. También requiere ASP.NET 4.5, que es tanto una característica como un servicio de rol bajo IIS Application Development en Windows Server 2012 R2.
Debido a que NDES puede ser un poco complicado de conseguir que funcione, normalmente lo instalamos primero y nos aseguramos de que está emitiendo con éxito retos SCEP antes de instalar CMS, y así lo hicimos en este caso. Pero, por mucho que lo intentamos, no conseguimos que el servicio NDES emitiera retos SCEP. Habíamos configurado correctamente NDES según la documentación de Microsoft utilizando la autenticación Kerberos y habíamos concedido a nuestro usuario los derechos para inscribirse en los certificados utilizando la plantilla configurada para su uso por NDES. Sin embargo, cada vez que solicitábamos un desafío SCEP, recibíamos un mensaje que indicaba que no teníamos permisos suficientes para solicitar un desafío SCEP. El mensaje exacto en el registro de eventos para cada fallo era:
El Servicio de inscripción de dispositivos de red no puede proporcionar su contraseña porque el usuario no tiene permisos de inscripción en la plantilla de certificado configurada o la autoridad de certificación no está habilitada para emitir certificados basados en la plantilla de certificado configurada.
El mensaje recibido por el usuario final era:
No tiene permiso suficiente para inscribirse en SCEP. Póngase en contacto con el administrador del sistema.
Mientras seguíamos dándonos cabezazos contra la pared en este caso, nos dimos cuenta de algunos comportamientos muy curiosos:
- Si concedíamos a nuestro usuario derechos administrativos locales en el servidor NDES, ese usuario era capaz de obtener un desafío SCEP remotamente (visitando la URL /certsrv/mscep_admin servida desde el servidor NDES desde un ordenador diferente) pero era incapaz de obtener un desafío SCEP localmente. Para que CMS funcione correctamente, esto tiene que funcionar localmente. Además, es un riesgo de seguridad conceder al usuario (para la funcionalidad de CMS sería la cuenta de servicio bajo la cual se ejecuta CMS) derechos administrativos locales en el servidor, y no debería ser necesario.
- El usuario administrativo de dominio "Administrador" (la cuenta incorporada) podía obtener un desafío SCEP localmente, pero ninguna otra cuenta de administrador de dominio o empresa podía obtener un desafío SCEP localmente. Tenga en cuenta que este comportamiento sólo aparecía en entornos en los que NDES estaba configurado para realizar autenticación Kerberos. Si funciona correctamente, NDES funcionará correctamente dentro de un único dominio utilizando la autenticación NTLM.
- El mensaje de permiso denegado al intentar obtener un desafío SCEP se producía incluso si concedíamos al grupo mágico "Todos" permisos para inscribirse en la plantilla de CA configurada para NDES.
Está claro que el mensaje de permiso denegado era falso y que algo más iba mal, pero ¿qué? ¿Listo para la gran revelación? Aquí está lo que resultó ser.
Cuando instalamos las funciones de NDES en el servidor (tanto el servicio de inscripción de dispositivos de red como las funciones de inscripción web de la autoridad de certificación), instalamos al mismo tiempo las funciones adicionales necesarias para CMS: autenticación básica para IIS y ASP.NET 4.5 (tanto la función como el servicio de funciones de IIS). NDES en Windows Server 2012 R2 no juega bien con esto. El murmullo que escuchamos de Microsoft sobre esto fue que el archivo web.config utilizado por NDES es pisoteado (también conocido como corrupto) por uno de estos otros roles, lo que lleva a una situación en la que no hay esperanza de que NDES funcione.
¿La solución a este problema? Desinstale NDES (todos los roles CA) y todos los roles IIS. Luego reinstale sólo los roles NDES y cualquier servicio de rol IIS que quiera instalar. No seleccione ninguna función o característica adicional en esta primera instalación. Una vez que tenga los desafíos SCEP funcionando tanto remota como localmente (sin solicitudes de contraseña), puede volver e instalar los roles y características adicionales requeridos para CMS y continuar con la implementación de CMS.
ADVERTENCIA: No desinstale .NET Framework 4.5 de Windows Server 2012 R2. Esto desinstala la interfaz gráfica de usuario del equipo, dejándole con algo que se parece a una instalación de Windows Server Core. Está bien desinstalar ASP.NET 4.5, pero no es necesario para solucionar el problema.
Mientras solucionábamos este problema de NDES, nos encontramos con otro problema extraño de NDES que producía el mismo mensaje de error falso que el anterior, pero con una causa diferente. En este caso alternativo, el problema era el resultado de un error de asignación de IIS Handler. Este error es específico de Windows Server 2012 R2 y NDES y parece estar relacionado con la instalación del rol ASP.NET 4.5 además de los roles NDES e inscripción web en el servidor NDES, aunque todavía estamos esperando noticias de Microsoft sobre la causa exacta de este problema. Si se encuentra con este problema y el método de reinstalación anterior no lo resuelve, pruebe esta solución:
- Inicie el Administrador de IIS utilizando la opción "Ejecutar como administrador".
- Desplácese hasta el directorio virtual mscep_admin en certsrv para el sitio web predeterminado.
- Haga doble clic en "Handler Mappings".
- Haga clic en "Ver lista ordenada..." en el panel derecho.
- Busque y seleccione "ExtensionlessURLHandler-ISAPI-4.0_64bit".
- En "Acciones", en el panel derecho, haga clic en "Desplazar hacia abajo" hasta que "ExtensionlessURLHandler-ISAPI-4.0_64bit" aparezca al final de la lista.
- Reinicie IIS en el Administrador de IIS o en un indicador administrativo command con "iisreset".
- Vuelva a intentar la recuperación del desafío SCEP como la cuenta de servicio NDES tanto local como remotamente.