De entre todo lo estándar que pueden ser las PKIs y los certificados, al final siempre llega un momento en que al mezclar cosas de distintas plataformas, la liamos. Y no es un liarla de liarla “parda”, no, no, es simplemente un liarla porque nos encontramos con las diferencias que al final existen, pese a estándares y otras declaraciones de intenciones.
¿Y a que me refiero yo exactamente con esta introducción?
Me refiero a que mientras todo nuestro proceso se desarrolle dentro de una misma plataforma, e.j. OpenSSL o Windows Server ADCS, lo normal es que todo sea maravilloso, el problema empieza con las mezclas. Como siempre, las mezclas acaban en problemas… Bueno, volviendo al tema que nos atañe, que se me va.
Mezclas, es decir, cosas como procesar solicitudes de una plataforma en la otra, por ejemplo. La situación que os describo hoy puede ser muy útil en escenarios del día a día, donde tenemos que generar certificados para multitud de equipos que no tienen plataforma Windows, ni saben de dominios de AD ni nada de esas cosas.
En mi caso concreto, lo hago a menudo para impresoras, switches de red y equipos con plataforma Linux. En estos casos, lo que ocurre es que acabamos con un fichero de texto (.csr), conteniendo la solicitud de certificado generada por el equipo, o por la suite OpenSSL si se trata de una maquina Linux.
Ooops!.. (El Error)
Si intentamos entregar esta solicitud directamente a una CA (entidad certificadora) Windows Server ADCS, a través de la consola de dicha CA (pulsando botón derecho sobre la CA y luego Todas las tareas -> Enviar solicitud nueva…), lo más probable es que acabemos con un mensaje similar a este que vemos abajo:
Error al procesar una solicitud de OpenSSL
¿Qué ha pasado?
Bueno, que nadie entre en pánico, es sencillo. Lo que ocurre es que, las CAs en Windows Server requieren que en la solicitud se les indique la plantilla de certificado a usar para emitir dicho certificado, peeeero, estos equipos al ser completamente independientes al dominio, plataforma y todo lo que le rodea, no disponen de ninguna información acera de dichas plantillas. Por este motivo no queda otra que generar la solicitud sin dicha información, esperando que eso se indique durante el proceso de emisión.
La salvación…
Afortunadamente, existe un comando fantástico en todas las CAs Windows Server, que nos permite hacer el truco, os hablo de certreq. Si no lo conocíais os lo presento:
– certreq.. Estos son nuestros carísimos IT Pros
– IT Pros.. Nuestro queridísimo certreq
certreq es el comando que gestiona las operaciones relacionadas con las solicitudes y emisión de certificados en las CAs Windows Server, y que nos permite especificar que plantilla queremos usar para procesar una determinada solicitud. Así que, nuestra salvación está en este comandito que os indico a continuación:
certreq -submit -attrib "CertificateTemplate:WebServer" SolicitudCert.csr
Esta es la forma de especificar la plantilla que queremos usar para emitir el certificado solicitado mediante el fichero SolicitudCert.csr, a través del atributo CertificateTemplate incluido en la línea de comando.
Y si… me dan miedo las consolas
No pasa nada, afortunadamente tenemos una alternativa a través del portal de la CA, para ello solo tenemos que conectarnos a la URL: https://<ServidorCA>/certsrv, donde <ServidorCA> es el nombre de nuestro servidor que ejecuta el rol de Windows Server ADCS, y el responsable por emitir los certificados en nuestro entorno.
Envío de solicitud a través del portal web de la CA
Navegando por las opciones: Solicitar un certificado -> Solicitud avanzada de certificado -> Enviar una solicitud de certificado con un archivo codificado en base64 CMC o PKCS#10 o una solicitud de renovación con un archivo codificado en base64 PKCS#7, podemos copiar y pegar la solicitud de certificado directamente en la caja de texto, y recoger el resultado, bien instalando dicho certificado en la máquina local, o bien mediante el fichero descargado.
La guinda…
Para terminar solo una pequeña notita. Si acaso no os aparece en el desplegable la plantilla que necesitáis usar para emitir el certificado, debéis aseguraros que esa plantilla tiene permisos de Leer e Inscribirse para la cuenta que estáis usando. Además, se debe realizar la publicación de dicha plantilla después de hacer el cambio, y reiniciar la entidad certificadora.
En el caso de que la plantilla ya tenga asignados esos permisos, para una cuenta o grupo administrativo, y se esté usando esa cuenta, debemos lanzar Internet Explorer dentro de un contexto de seguridad de administración, usando la opción “Ejecutar como Administrador”.
Dicho esto… ¡A mezclar todo el mundo!
A lo largo de nuestras vidas con la tecnología, todos vamos incorporando ciertos truquillos/comportamientos en nuestro día a día con las máquinas, que nos hacen la vida mucho más fácil. Hoy os voy a hablar de uno de esos truquillos, que para mí es fundamental, y que con la incorporación de la nueva interface de Windows 8 y 8.1 me estaba dando algo de guerra, pero primero veamos el escenario…
Si tenéis que dedicar algo de tiempo a las labores de gestión, a bien de la seguridad del entorno de vuestras empresas, lo más normal es que vuestras cuentas de usuario no tengan directamente privilegios de administración de dominio y esas cosas. En mi caso, cada uno de nosotros tiene su usuario de dominio con los permisos necesarios para trabajar y luego una segunda cuenta, “especial”, para las labores que requieren ensuciarse las manos, meter la cabeza en las consolas de los servicios, etc.
Ya veis por donde voy, mí día a día está lleno de ejecuciones “Run As”, o “Ejecutar como”, para seguir la misma nomenclatura que la interface de Windows en castellano.
“Run As”, “Ejecutar como” o “El otro Yo”…
Cuando recurrimos a esta metodología de cuentas de usuario, lo normal es que en los escritorios de los administradores de sistemas veamos una mezcla de aplicaciones y ventanas, ejecutándose tanto con la cuenta normal del usuario como con la cuenta de administrador que le está asignada (consolas y demás herramientas dedicadas al trabajo “duro”).
Esto es algo que se lleva muy bien, en un entorno puramente de escritorio de Windows (como los que teníamos hasta Windows 7, e incluso en el escritorio de Windows 8), pero si incorporamos la nueva interface de Windows 8, con el nuevo menú de Inicio, a nuestra forma de trabajar, necesitamos algunos pequeños retoques para conseguir que todo siga siendo igual de ágil.
En el escritorio, ejecutar una aplicación con una cuenta de usuario distinta (ya sea una cuenta de administración o cualquier otra) es muy sencillo, pulsando la tecla Shift y luego el botón derecho del ratón sobre la aplicación deseada hacemos que esta opción aparezca en el menú contextual.
Opción “Ejecutar como” en el entorno de escritorio
Donde las cosas se complican es cuando tenemos que hacer la misma operación lanzando las aplicaciones desde el menú de Inicio de Windows 8 o 8.1, al pulsar el botón derecho esta opción no está disponible.
Está claro que esta opción no es necesaria en la gran mayoría de escenarios de uso de Windows cliente, me atrevería incluso a decir que más de un 80% de usuarios jamás la necesitará, por lo que el hecho de que esté oculta hace que la interface sea más sencilla y limpia.
Sin embargo, para perfiles como los administradores de sistemas y desarrolladores de aplicaciones, esta funcionalidad es muy útil y en definitiva algo a tener en cuenta. Solo un pequeño paréntesis antes de seguir, me refiero en todo momento a Windows cliente (8 y 8.1) porque en Windows Server (2012 y 2012 R2) esta opción sí que está habilitada por defecto, aunque me imagino que, en general y siguiendo unas buenas prácticas, realizáis las labores de administración desde una estación de trabajo en lugar de hacer RDPs a diestro y siniestro.
En el escenario de administración que os comentaba anteriormente, cuento con mi grupo de iconos en el menú de Inicio de Windows 8 con todas las consolas que necesito. Para conseguir habilitar esta opción y desde ahí poder lanzar estas aplicaciones con el contexto del usuario correspondiente, tenemos que habilitar esta funcionalidad mediante una GPO de Windows.
Estos son los pasos para habilitar la opción con la consola de directivas de equipo local, para realizar la operación a nivel de dominio sería algo similar pero gestionándolo desde la consola de directivas de dominio:
- Abrir la consola de directivas de equipo local, ejecutando gpedit.msc.
- Buscar la directiva en la ruta: Directiva Equipo Local -> Configuración de usuario -> Plantillas administrativas -> Menú Inicio y barra de tareas (Si tenéis la interface en inglés sería: Local Computer Policy -> User configuration -> Administrative Templates -> Start Menu and Taskbar).
Consola de directivas de equipo local
- La directiva que deseamos habilitar es: Mostrar el comando “Ejecutar como otro usuario” en Inicio.
- Seleccionamos Habilitada, aplicamos los cambios, y esto nos activa la opción en el menú de Inicio como se puede ver a continuación.
Directiva: Mostrar "Ejecutar como otro usuario"
Ahora nuestro menú de Inicio, al hacer “botón derecho” o su equivalente en equipos con pantalla táctil, nos presenta la opción deseada, como podemos ver en la imagen de abajo (izquierda – versión táctil; derecha – versión tradicional con ratón).
"Ejecutar como otro usuario" en el menú de Inicio
Para terminar me gustaría dejaros una pequeña nota acerca de la activación de esta opción, al hacer el cambio a la política la activación es inmediata, sin embargo, en equipos miembros de dominio (que será la inmensa mayoría de los casos para el escenario de administración descrito), la opción solo se activará cuando el equipo esté conectado a la red corporativa con acceso a sus controladores de dominio.
Yuhu! A administrar sin parar…
