Microsoft Windows Server 2008 R2: Los certificados impulsan la seguridad de RDS

Certificados desempeñan un papel enorme en proteger las conexiones entre clientes y hosts de servicios de escritorio remoto.

Kristin Griffin

Pedir certificados de uso de roles que trata de truco. La respuesta real es "todos ellos". Es importante comprender donde deben utilizar certificados en implementaciones de servicios de escritorio remoto (RDS), y por qué los utilice con cada servicio de rol particular de RDS.

Roles más que necesitará configurar, pero algunos de ellos que no (como el servidor de licencias de escritorio remoto). De forma predeterminada, usted necesitará certificados SSL (x.509) en cada etapa de conectarse a una sesión o alojada la máquina virtual (VM). Utilizará estos tres fines principales: para proteger las comunicaciones entre cliente y servidor, para confirmar la identidad del servidor o del sitio Web para que el cliente se conecta y firmar archivos de protocolo de escritorio remoto (RDP) para que los usuarios sepan el archivo RDP proviene de una fuente confiable y no ha sido alterado.

Éstos son algunos ejemplos de cómo RDS utiliza certificados:

• Los servidores Host de sesión de escritorio remoto utilizan certificados para probar su identidad. Esto se denomina autenticación de servidor.
• Los servidores Host de sesión de escritorio remoto y Host de virtualización de escritorio remoto utilizar certificados para establecer un vínculo seguro entre cliente y servidor con TLS 1.0.
• Servidores de Host de sesión de escritorio remoto utiliza certificados para la autenticación de cliente necesaria para la autenticación de nivel de red (NLA), inicio de sesión único (SSO) y aplicación Web SSO.
• Los servidores Host de sesión de escritorio remoto y agente de conexión a Escritorio remoto utilizan un certificado SSL para firmar archivos RemoteApps y VM RDP, asegurando a los usuarios que están lanzando un archivo de confianza.
• Servidores Gateway RD utilizan certificados para cifrar las comunicaciones con los clientes utilizando TLS 1.0.
• Puede proteger el sitio de RD Web Access con un certificado SSL para asegurar que la gente va a un sitio de confianza (HTTPS).

Habilitar la funcionalidad RDS se basa en tecnologías específicas para apoyar el uso de certificados (consulte figura 1).

Figura 1 funcionalidad de RDS que permite lleva a desempeñan determinadas tecnologías de seguridad.

El canal seguro

TLS es el estándar de Internet Engineering Task Force (IETF) basado en SSL versión 3, publicada por Netscape. Algunas de las mejoras a TLS incluyan nuevos mensajes de alerta, la capacidad de certificados en cadena a un intermediario certificado de autoridad de certificación (CA) en lugar del certificado de entidad emisora raíz y ligeramente distintos algoritmos de codificación de SSL.

Aunque TLS está basado en SSL, los dos son incompatibles. TLS puede, sin embargo, implementar un mecanismo por el cual puede retroceder a la versión 3 de SSL si es necesario. Para establecer un canal de comunicación seguro entre un cliente y un servidor utilizando TLS, el cliente y el servidor van a través de un proceso de mensajería, la respuesta y el cifrado (véase figura 2).

Figura 2 el proceso de cifrado bidireccional para establecer un canal seguro.

Existen dos requisitos para que este proceso funcione correctamente.

• El cliente debe confiar en la entidad emisora que firma el certificado del servidor SSL.
• La conexión entre el servidor y el cliente debe utilizar alto nivel (por defecto) o cifrado Federal Information Processing Standard (FIPS). Cifrado de bajo nivel sólo cifra el tráfico del cliente al servidor, no el servidor al cliente, por lo que no es una manera segura para enviar las funcionalidades de seguridad o los secretos compartidos.

Si el nivel de conexión y cifrado cumple los dos requisitos, el cliente y el servidor para establecer comunicación de lo siguiente:

1. El cliente envía un mensaje Hola junto con un valor aleatorio de longitud fija. El servidor responde con un valor aleatorio de longitud fija. Durante este intercambio, el cliente indica al servidor los métodos de compresión, cifrados y hashes soporta. También envía su versión de protocolo y un identificador de sesión en el servidor. El ID de sesión identifica el Desarr­canal catiónico: este no es el ID de sesión en un servidor Host de sesión de escritorio remoto.
2. El servidor selecciona el método de cifrado más alto ambos apoyan y la función de cifrado y hash de la lista del cliente. A continuación, indica al cliente que uno tiene cho­sen. Si hay un nivel mínimo establecido para el servidor y el cliente no puede cumplir este mínimo, se producirá un error en la conexión.
3. El servidor envía su certificado digital para el cliente. Este certificado contiene el nombre del servidor, el CA de confianza que firmó el certificado y la clave pública del servidor.
4. El cliente comprueba que el certificado es válido y de confianza. El certificado utilizado para firmar el certificado de servidor será en el almacén de entidades emisoras raíz de confianza del cliente. A continuación, crea un secreto premasterizado, cifra con la clave pública del servidor y envía al servidor.
5. El servidor recibe y descifra el secreto premasterizado con su clave privada. Este servidor es el único que puede hacer esto porque es el único servidor con la clave privada correspondiente.
6. El servidor y el cliente tienen el secreto premasterizada y números aleatorios intercambiados al comienzo del proceso. Utilizan estos valores para generar el secreto principal de 48 bytes (también conocido como el secreto compartido). Después de generar el secreto principal, elimine el secreto premasterizado.
7. Cliente y servidor, a continuación, hash el secreto principal de 48 bytes y utilizan para generar el secreto de MAC (la clave de sesión utilizada para hash) y la clave de escritura (la clave de sesión utilizada para el cifrado). Estas claves cifrar y descifrar la comunicación para este período de sesiones. Una vez terminada la sesión, se descartan las claves.

Si cualquier paso de esta secuencia no funciona, la conexión no ha sido plenamente garantizada. Lo que sucede luego depende de la configuración de la ficha Opciones avanzadas en la Connec de escritorio remoto­cliente tion (RDC). En el caso de fallo de autenticación, un usuario puede elegir hacer alguna de las siguientes acciones:

• De todas formas conectar sin notificar al cliente hubo un problema al autenticar el servidor.
• Avisar al cliente, pero todavía permitir la conexión (el valor predeterminado).
• Denegar la conexión si no se puede comprobar.

La excepción es si el servidor requiere un nivel mínimo de seguridad. Si ese es el caso y el cliente no puede alcanzar el nivel mínimo, se producirá un error en la conexión. De forma predeterminada, el cliente y el servidor serán negociar y utilizar la configuración de conexión más segura que ambos apoyan.

Credenciales caché con CredSSP

El almacenamiento en caché de credenciales se introdujo con Windows Vista y Windows Server 2008. Esto permite dos características: uno que ayuda a uno que ayuda a proteger el servidor y el usuario.

El almacenamiento en caché de credenciales ayuda a los usuarios por almacenar las credenciales para una conexión en particular por lo que no necesitan darles cada vez que se conectan al servidor (esto es SSO). Esto acelera la conexión. De lo contrario debe comprobarse una conexión abierta en cada paso.

En el lado del servidor, el almacenamiento en caché de credenciales proporciona credenciales en el servidor antes de que establece una sesión. Esto evita la sobrecarga de una sesión si el usuario no está autorizado (esto es NLA).

La pieza que hace trabajo de caché de credenciales es el proveedor de servicios de seguridad de credenciales (CredSSP). Esto es compatible con Windows 7, Windows Vista, Windows Server 2008 y Windows XP SP3. No está vinculado a la versión de la RDC se utiliza porque CredSSP es parte del sistema operativo. CredSSP realiza las siguientes funciones:

• Para NLA, CredSSP proporciona el marco que autentica a un usuario a un servidor Host de sesión de escritorio remoto antes de establecer plenamente la conexión.
• Para conectarse a una sesión dentro de una granja, CredSSP acelera el proceso de pasar de la conexión al servidor correcto por dejar que el servidor Host de sesión de escritorio remoto a ver quien es iniciar sesión sin tener que crear una sesión completa. NLA se utiliza en un escenario ligeramente diferente.
• SSO, CredSSP almacena las credenciales del usuario y pasa al servidor Host de sesión de escritorio remoto para automatizar el inicio de sesión.

CredSSP permite la autenticación mutua de servidor y cliente (véase figura 3).

Figura 3 autenticar el servidor y el cliente requiere un canal seguro.

Este proceso de autenticación lleva los siguientes pasos.

1. El cliente inicia un canal seguro con el servidor utilizando TLS. El servidor pasa atrás el certificado con su nombre, CA y su clave pública. Sólo el servidor es identificado. El cliente permanece anónimo en este punto.
2. Cuando se establece la sesión y una clave de sesión creada, CredSSP utiliza el Protocolo Simple y negociación de GSS-API protegida (SPNEGO) mutuamente auten­cate el servidor y el cliente. Básicamente, este mecanismo permite que el cliente y el servidor de acuerdo sobre un mecanismo de autenticación que tanto apoyan, tales como Kerberos o Windows NT LAN Manager (NTLM).
3. Una vez finalizada la autenticación mutua, CredSSP del lado cliente encripta el certificado del servidor con la clave de sesión creada durante el paso 2 y envía al servidor. El servidor recibe el certificado de cifrado, descifra con su clave privada y, a continuación, agrega una el bit más significativo del número de certificado. A continuación, se cifra el resultado y se envía al cliente. Asegura que la operación de este última que nadie puede interceptar el intercambio entre cliente y servidor y suplantar el servidor.
4. El cliente revisa el certificado de cifrado recibido desde el servidor y com­pares para su propio certificado.
5. Suponiendo que coinciden con los resultados, CredSSP en el lado del cliente envía las credenciales de usuario al servidor.

Autenticar la identidad del servidor

Un peligro de comunicarse con un equipo remoto que requiere credenciales de suministro es que el servidor puede no ser lo que crees. Si es un servidor de rogue suplantar una confianza, inadvertidamente podría escribir sus credenciales en el servidor equivocado. Esto le daría los atacantes todo que lo necesario para conectarse a su servidor o dominio.

RDP incluye cifrado, pero el Protocolo no tiene ningún medio para autenticar el servidor. Es donde TLS y CredSSP. Autenticación de servidor comprueba el nombre que introduzca en la RDC cliente (o archivo RDP) contra el nombre que se emitió el certificado especificado en la herramienta de configuración de escritorio remoto en el servidor Host de sesión de escritorio remoto al que está conectado.

Firmar archivos RDP

Puede utilizar certificados para firmar digitalmente los archivos de RemoteApp, así como archivos RDP que utiliza para conectarse a un personal o agrupado VM (VDI). Firma estos archivos asegura al usuario que fueron creados por una fuente de confianza. También protege el archivo RDP de manipulación.

Firma RemoteApp archivos también es necesaria para la aplicación Web SSO. Esto permite a los usuarios iniciar sesión una vez para el sitio Web de RD Web Access. A continuación, pueden lanzar RemoteApps de cualquier explotación sin tener que dar nuevamente sus credenciales.

CredSSP no puede pasar credenciales RD Web Access. El usuario primero debe iniciar sesión el sitio Web para almacenar sus credenciales. Entonces no necesita autenticar nuevamente para iniciar programas RemoteApp. Para que funcione, debe ser firmado el RemoteApps y el usuario debe confiar en el certificado utilizado para firmar el RemoteApp.

Archivos RDP creados cuando un usuario inicia una conexión RDP desde la ficha de ordenadores de sobremesa de RD Web Access se crean sobre la marcha. Los archivos no están firmados. Por lo tanto, SSO Web no funciona cuando se conecta a ordenadores de sobremesa. El usuario tendrá que iniciar una sesión el extremo una vez establecida la conexión. SSO Web también funcionará para conexiones a VMs personales o agrupadas.

Proteger las conexiones

RD Gateway utiliza TLS 1.0 para comunicaciones seguras entre Gateway RD y clientes de escritorio remotos, normalmente situados fuera de la red corporativa (por Internet). TLS, como se describió anteriormente, requiere un certificado SSL. También puede comunicaciones seguras entre los clientes y el servidor de RD Web Access mediante un certificado digital para cifrar las sesiones de sitio Web (HTTPS).

Los certificados son una pieza esencial de una implementación de RDS. RDS utiliza certificados para proteger las comunicaciones y las características que permiten. El próximo mes, podrá cubrir configurar servicios de rol RDS para utilizar dichos certificados.

Kristin Griffin es un MVP de servicios de escritorio remoto. Ella modera un foro de Microsoft dedicado a ayudar a la comunidad informática basada en servidor (servicios de escritorio remoto) y mantiene un blog RDS en blog.kristinlgriffin.com. Ella es colaborador "Mastering Windows Server 2008" de Mark Minasi (Sybex, 2008) y "Mastering Windows Server 2008 R2" (Sybex, 2010). También fue coautora "Microsoft Windows Server 2008 Terminal Services Resource Kit" (Microsoft Press, 2008) y "Microsoft Windows Server 2008 R2 Remote Desktop Services Resource Kit" (Microsoft Press, 2010) con Christa Anderson.

Contenido relacionado

• Agregue Hyper-V a RDS para escritorios virtuales económicos
• Firmar digitalmente los programas RemoteApp
• Aplicación Web SSO