Publicado por primera vez en TECHNET en enero 24, 2014
Buenos días, AskPerf. Kiran aquí con una pregunta para usted: ¿Por qué necesitamos certificados? Bueno, los certificados se usan para firmar la comunicación entre dos máquinas. Cuando un cliente se conecta a un servidor, la identidad del servidor que recibe la conexión y, a su vez, la información del cliente, se valida mediante certificados.
Esto se hace para evitar posibles ataques de intermediario. Cuando se configura un canal de comunicación entre el cliente y el servidor, la autoridad que emite / genera el certificado avala que el servidor es auténtico.
Por lo tanto, siempre y cuando el cliente confíe en el servidor con el que se está comunicando, los datos que se envían hacia y desde el servidor se consideran seguros. Esto me lleva a la siguiente pregunta:
¿Qué tipo de certificado se requiere para RDS?
El siguiente blog contiene información sobre el tipo de certificados y cómo puede crearlos utilizando la CA interna del dominio.
http://blogs.msdn.com/b/rds/archive/2010/04/09/configuring-remote-desktop-certificates.aspx
Requisitos básicos para certificados de escritorio remoto:
- El certificado se instala en el almacén de certificados «Personal» del equipo.
- El certificado tiene una clave privada correspondiente.
- La extensión » Uso de clave mejorada «tiene un valor de» Autenticación de servidor «o» Autenticación de Escritorio remoto » (1.3.6.1.4.1.311.54.1.2). También se pueden utilizar certificados sin extensión de «Uso de clave mejorada».
Como sugiere la función que realiza, necesitamos un certificado de ‘Autenticación de servidor’. Este certificado se puede generar utilizando la plantilla de autenticación de estación de trabajo (si es necesario).
Aquí está el proceso exacto:
- Abra CERTSRV.Certificados MSC y configure.
- Autoridad de Certificación Abierta.
- En el panel de detalles, expanda el nombre del equipo del instructor.
- Haga clic con el botón secundario en Plantillas de certificado y seleccione Administrar. Haga clic con el botón secundario en Autenticación de estación de trabajo y haga clic en Plantilla duplicada.
- En la ficha General, cambie el nombre para mostrar de la plantilla a Autenticación Cliente-Servidor y marque Publicar certificado en Active Directory.
- En la ficha Extensiones, haga clic en Directivas de aplicación y, a continuación, en Editar. Haga clic en Agregar y, a continuación, seleccione Autenticación de servidor. Haga clic en Aceptar hasta que vuelva al diálogo Propiedades de Nueva plantilla.
- Haga clic en la pestaña Seguridad. Para Equipos de Dominio, haga clic en la casilla de verificación para ‘Permitir inscripción automática’. Haga clic en Aceptar. Cierre la consola de Plantillas de certificado.
- En el complemento certsrv, haga clic con el botón secundario en Plantillas de certificado y seleccione Nueva y, a continuación, Plantilla de certificado para emitir.
- Seleccione Autenticación Cliente-servidor y, a continuación, haga clic en Aceptar.
Esto será visible al ver el certificado en el complemento MMC «Certificados», como se muestra a continuación:
Al abrir el certificado, la pestaña «General» también contendrá el propósito de este certificado de ser «Autenticación de servidor», como se muestra a continuación:
Otra forma de validar esto sería ir a la sección «Detalles» del certificado y mirar la propiedad «Uso de clave mejorado»:
La forma más sencilla de obtener un certificado, si controla las máquinas cliente que se conectarán, es usar los servicios de certificados de Active Directory. Puede solicitar e implementar sus propios certificados y todos los equipos del dominio confiarán en ellos.
Si va a permitir que los usuarios se conecten externamente y no formarán parte de su dominio, deberá implementar certificados desde una CA pública. Ejemplos que incluyen, entre otros: GoDaddy, Verisign, Entrust, Thawte, DigiCert
Ahora que sabe qué tipo de certificado necesita, hablemos del contenido del certificado.
En Windows 2008/2008 R2, se conecta al nombre de la granja, que según DNS round robin, se dirige primero al redirector, junto al agente de conexión y, finalmente, al servidor que alojará la sesión.
En Windows 2012, se conecta al Agente de conexión y éste lo dirige a la colección mediante el nombre de la colección.
Los certificados que implemente deben tener un nombre de sujeto o un nombre alternativo de sujeto que coincida con el nombre del servidor al que se conecta el usuario. Por ejemplo, para publicar, el certificado debe contener los nombres de todos los servidores RDSH de la colección. El certificado para RDWeb debe contener el FQDN de la URL, basado en el nombre al que se conectan los usuarios. Si tiene usuarios que se conectan externamente, este debe ser un nombre externo (debe coincidir con el nombre con el que se conectan). Si tiene usuarios que se conectan internamente a RDWeb, el nombre debe coincidir con el nombre interno. Para el inicio de sesión único, de nuevo el nombre del sujeto debe coincidir con los servidores de la colección.
Para nuestro ejemplo, consideremos mi implementación de RDS para contener las siguientes máquinas:
RDSH1.RENDER.COM Host de sesión con Aplicaciones remotas configuradas
RDSH2.RENDER.COM Host de sesión con Aplicaciones remotas configuradas
RDVH1.RENDER.Host de virtualización COM con máquinas virtuales VDI configuradas
RDVH2.RENDER.COM Host de virtualización con máquinas virtuales VDI configuradas
RDCB.RENDER.COM Agente de conexión
RDWEB.RENDER.COM Servidor RDWeb y Gateway
Cuando mi cliente se conecte internamente, ingresará el FQDN del servidor que aloja la página web, es decir: RDWEB.RENDER.COM.
El nombre del certificado debe ser este nombre, de la URL a la que el usuario iniciará la conexión. Pero debemos recordar que la conexión no acaba aquí. A continuación, la conexión fluye desde el servidor web a uno de los hosts de sesión o hosts de virtualización y también al agente de conexión.
El certificado puede ser común en todos estos servidores. Por este motivo, recomendamos que el Nombre Alternativo del sujeto del certificado contenga los nombres de todos los demás servidores que forman parte de la implementación.
En resumen, el certificado para mi entorno sería el siguiente:
Tipo: Autenticación de servidor
Nombre: RDWEB.RENDER.COM
SAN: RDSH1.RENDER.COM; RDSH2.RENDER.COM; RDVH1.RENDER.COM; RDVH2.RENDER.COM; RDCB.RENDER.COM
Esto es todo lo que necesita siempre y cuando tenga 5 servidores o menos en la implementación. Pero tenemos un problema cuando tenemos más servidores en la implementación. Esto se debe a que, por diseño, la SAN (Nombre Alternativo del sujeto) en un certificado solo puede contener 5 nombres de servidor. Si tiene más de ellos, tendrá que obtener un certificado comodín emitido para cubrir todos los servidores de la implementación. Aquí mi certificado cambia de la siguiente manera:
Tipo: Autenticación de servidor
Nombre: RDWEB.RENDER.COM
SAN: *.RENDER.COM
Todavía nos encontramos con algunos desafíos cuando se trata del siguiente escenario. Tenga en cuenta que esto es cierto solo cuando tiene usuarios externos que acceden a la implementación.
nombre Externo: RDWEB.RENDER.com
Nombre Interno: RDWEB.RENDER.local
Aquí, si obtiene un certificado con RDWEB.RENDER.COM en el nombre, los errores de certificado siguen apareciendo. Esto se debe a que el certificado debe validar un servidor con el FQDN: ‘RDWEB.RENDER.COM’. Sin embargo, su servidor es ‘RDWEB.RENDER.LOCAL ‘y el’. com ‘to’.la magia local solo ocurre en su firewall/enrutador público utilizando el reenvío de puertos (escenario más común).
En tales escenarios, previamente recomendamos que el nombre en el certificado contenga el nombre ‘.com’ y la SAN contenga el ‘.nombre local.
Recientemente, todos los proveedores de certificados públicos han dejado de emitir certificados con ‘.SON locales. A partir de Windows 8 y Windows Server 2012, ya no necesitamos que los nombres externos e internos estén contenidos en el certificado.
En escenarios en los que tiene clientes externos conectados y tiene un sufijo de dominio interno privado (DOMINIO.LOCAL), puede obtener un certificado de una CA pública con el sistema externo (RDWEB.DOMAIN.COM) asigne un nombre y enlácelo a los roles de Acceso Web de Escritorio remoto y Puerta de enlace de Escritorio remoto, ya que estos son los únicos roles que están expuestos a Internet. Para habilitar el inicio de sesión único en Agente de conexión a Escritorio remoto – Publicación y Agente de conexión a Escritorio remoto -, puede usar un certificado interno con el DOMINIO».Tiene un nombre local. Sin embargo, como se mencionó anteriormente, esto solo funcionará con clientes que se conecten a través de RDC 8.0 o superior.
La puerta de enlace de Escritorio remoto y el cliente de escritorio remoto versión 8.0 (y superior) proporcionan a los usuarios externos una conexión segura a la implementación. Una vez conectado a la implementación, el certificado interno con el ‘.el nombre local se encargará de la firma remota de aplicaciones (publicación) y el Inicio de sesión único.
Ahora, veamos dónde configuramos el certificado que tenemos:
Abra el Administrador del servidor en el servidor del Agente de conexión y haga clic en Servicios de escritorio remoto en el panel izquierdo.
Una vez aquí, verá su implementación mostrada como en la ilustración a continuación. Haga clic en Tareas y seleccione «Editar propiedades de implementación»
Esto mostrará la hoja de propiedades de la implementación. Seleccione la opción Certificados en el panel izquierdo:
Ahora, como se mencionó anteriormente, puede seleccionar el certificado que se creó utilizando el botón «Seleccionar certificado existente» en la parte inferior de la pantalla.
Solo apunte a la ‘.archivo pfx y permitir que importe el certificado para el rol.
Puede usar un solo certificado para todos los roles, si sus clientes son internos solo al dominio, generando un certificado comodín simple ( * .RENDER.LOCAL) y vinculándolo a todos los roles.
Tenga en cuenta que, incluso si tiene varios servidores que forman parte de esta implementación, el Administrador del servidor importará el certificado a todos los servidores de la implementación, los colocará en la raíz de confianza de las máquinas y los vinculará a los roles respectivos.
– Kiran Kadaba
