Windows Server 2008 R2: ¿Para qué sirve la autenticación a nivel de red?
Utilizando la autenticación de nivel de red (NLA), al método anterior de servicios de Terminal Server, es más rápido y más seguro.
Kristin Griffin
Pasar de servicios de Terminal Server de Windows Server 2003 a Windows Server 2008 R2 Remote Desktop Services se ha convertido en una ruta de actualización bastante común. Como la gente hace esta actualización, a menudo oirá les preguntan por qué es tan diferente la experiencia de conexión de usuario entre las dos versiones.
Cuando se conecta a un servidor de Terminal Server 2003, un usuario inicia una sesión y tipos en sus credenciales. Cuando se utiliza un servidor Host de sesión de escritorio remoto, un usuario entra normalmente credenciales en un cuadro de diálogo del lado del cliente. De forma predeterminada, no se pueden conectar a los clientes que no admiten una tecnología llamada autenticación a nivel de red (NLA). ¿Por qué la diferencia? Hay razones por qué Microsoft introdujo la autenticación a nivel de red y por qué es de hecho algo bueno.
¿Qué es NLA?
NLA fuerza el equipo cliente presente credenciales de usuario para la autenticación antes de que el servidor creará una sesión para ese usuario. Debido a ese proceso, a veces se llama "frontal autenticación". Servidores que ejecutan Windows Server 2008/Vista o posterior, y clientes que ejecutan Windows XP SP3 o posterior, soporte NLA. Porque NLA se basa en una tecnología llamada protocolo Credential Security Support Provider (CredSSP), si está utilizando a un cliente de protocolo de escritorio remoto (RDP) para otro sistema operativo, necesitará pedir su desarrollador si es compatible con NLA.
Así que ¿por qué presenta credenciales antes de la creación de sesión algo bueno? Hay dos ventajas principales para no crear una sesión hasta que esté seguro de que la persona intentando conectar está autorizada a hacerlo: ofrece un nivel de defensa contra ataques de denegación de servicio (DoS) y acelera el proceso de intermediación.
Iniciar una sesión — incluso presentar una pantalla de inicio de sesión: requiere que el servidor crear muchos de los procesos requeridos para soportar una sesión, como Csrss.exe y Winlogon.exe. Debido a esto, creación de sesión es relativamente lento y costoso. Si se trató de un número de usuarios no autorizados a conectarse a una sesión al mismo tiempo, que podrían potencialmente bloquear otros de utilizar ese servidor porque creó sesiones a aceptar esas credenciales falsas de inicio de sesión.
El problema de rendimiento es más crítico. En Windows Server 2003, las granjas fueron relativamente raras. A partir de Windows Server 2008, las granjas se hicieron más comunes. Recuerde que cada servidor en una granja de Host de sesión de escritorio remoto es potencialmente un redirector. Si el servidor host debe crear una sesión completa antes de redirigir una solicitud de conexión para el agente de conexión RD, esto reduce el tiempo de conexión.
NLA utiliza CredSSP para presentar las credenciales de usuario para el servidor de autenticación antes de crear una sesión. Este proceso evita esas cuestiones. CredSSP tiene también otros beneficios. CredSSP puede reducir el número de inicios de sesión de que un usuario debe hacer mediante el almacenamiento de credenciales para una conexión determinada.
La primera vez que un usuario se conecta a un servidor nuevo, máquina virtual (VM) o incluso otro PC, deberás proporcionar sus credenciales. Sin embargo, también tendrá la opción de guardarlos. Si lo hacen, no necesitan proporcionar credenciales nuevo para esa conexión hasta que cambian su contraseña.
¿Cómo CredSSP soporta NLA
El protocolo CredSSP ayuda a aplicaciones con seguridad delegar credenciales de usuario desde un cliente a un servidor de destino. Este Protocolo establece primero un canal cifrado entre el cliente y el servidor de destino utilizando Transport Layer Security (TLS) (como se especifica en [RFC2246]).
Cuando se conecta a un servidor Host de sesión de escritorio remoto con una RDC 6.x o posterior del cliente, tal vez han notado que no se conecta directamente a la pantalla de inicio de sesión del servidor Host de sesión de escritorio remoto para proporcionar las credenciales. En cambio, un cuadro de diálogo local aparece para tomar sus credenciales en el cliente. Este cuadro de diálogo es el front-end de CredSSP.
Cuando escriba sus credenciales en este cuadro de diálogo, incluso si no desea guardarlos, van a CredSSP. Este entonces pasa las credenciales en el servidor Host de sesión de escritorio remoto a través de un canal seguro. El servidor Host de sesión de escritorio remoto sólo comenzará una sesión de usuario una vez que acepta las credenciales de la construcción.
Los clientes que admiten CredSSP y RDP 6.x y más tarde serán siempre utilizan NLA si está disponible. Porque CredSSP (la tecnología que soporta NLA) es parte del sistema operativo y no de RDP, el sistema operativo del cliente debe ser compatible con CredSSP para NLA trabajar.
Por lo tanto, aunque hay un cliente RDC 6.0 para Windows XP SP2, esto no deja Windows XP SP2 utilizar NLA. Clientes que ejecutan Windows XP SP3, Windows Vista y Windows 7 admiten CredSSP. También, RDC contare si es compatible con NLA en la pantalla acerca de. Para ver esto, haga clic en el icono de equipo en la esquina superior izquierda de la RDC y seleccione acerca de. Esto indica si admite NLA.
Windows XP SP3 admite CredSSP, pero no lo tiene activado por defecto. Para habilitarla, Microsoft publicó un artículo de knowledge base con un repararlo para mí enlace. El artículo también explica cómo habilitar CredSSP manualmente. Una vez que habilitar CredSSP, reinicie el equipo.
Si el equipo cliente no está configurado para correctamente apoyo NLA obtendrá un mensaje diciendo que por lo que cuando se intenta una conexión remota a una máquina que requiere NLA. Por ejemplo, si su cliente de Windows XP SP3 no tiene CredSSP habilitado, obtendrá este error cuando se intenta una conexión remota a un servidor Host de sesión de escritorio remoto que requerían NLA: "El equipo remoto requiere autenticación a nivel de red, que no es compatible con el equipo".
Cómo forzar el uso de NLA
Servidores Host de sesión de escritorio remoto no requieren NLA por defecto. Se puede configurar para permitir conexiones de equipos compatibles con NLA, mediante Directiva de grupo o en una base por servidor de configuración de Host de sesión de RD.
Para requerir NLA para conectar con el servidor Host de sesión de escritorio remoto por servidor, abra configuración de Host de sesión de RD. Haga doble clic en RDP-Tcp (en la sección conexiones) y en la ficha General, active la casilla de verificación Permitir conexiones sólo desde equipos que ejecutan escritorio remoto con autenticación a nivel de red. Esto evitará que los clientes que no admiten NLA (es decir, cualquier cliente que ejecuta RDC anteriores a la versión 6.x y cualquier sistema operativo no compatible con CredSSP) de conexión al servidor.
Para habilitar NLA mediante Directiva de grupo, habilitar las siguientes directivas y aplicarla al servidor Host de sesión de escritorio remoto OU: Configuración del equipo | Directivas | Plantillas administrativas | Componentes de Windows | Servicios de escritorio remotos | Host de sesión de escritorio remoto | Seguridad | Requieren autenticación de usuario para conexiones remotas mediante la autenticación de nivel de red.
Deshabilitar o no configurar esta política significa que NLA no es necesario.
Solicitudes VDI
Las implementaciones de infraestructura de escritorio virtual (VDI), también puede restringir el Windows Vista y Windows 7 para aceptar solicitudes de conexión únicamente desde clientes que admiten NLA. Vaya al Panel de Control | Sistema | Configuración remota. En la ficha remoto del cuadro de diálogo Propiedades del sistema, seleccione la opción de permitir conexiones sólo de equipos ejecutando Desktop con red nivel de autenticación remota (más segura).
Esto debería explicar por qué NLA propicio en los servidores Host de sesión de escritorio remoto y VMs VDI son una buena idea. Debe comprender cómo requieren NLA en sus servidores y VMs de VDI y cómo configurar los equipos cliente para apoyar NLA.
Certificados, mientras que menciona sólo brevemente, son una pieza esencial de cualquier implementación de RDS. Y eso no es sólo para NLA, pero también la autenticación de servidor, con Gateway de RD, RD Web Access e incluso agente de conexión de escritorio remoto. Próxima vez voy ahondar más en los requisitos de certificado para implementaciones de RDS.
.jpg)
Kristin Griffines 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.
NLA q & a
P. Estoy ejecutando Windows XP SP3. He permitido CredSSP, pero aún obtengo el siguiente error al conectarse a un servidor Host de sesión de escritorio remoto que requiere NLA: "Se ha producido un error de autenticación".
R. Hay una revisión que resuelve este problema de mi blog.
Este error se producirá también en esta circunstancia específica con estos factores presentes:
- El cliente ejecuta Windows XP SP3 con CredSSP habilitado.
- Ha configurado el servidor para utilizar un certificado SSL real para identificarse a sí mismo (no está utilizando el certificado generado automáticamente que se encuentra en el lugar por defecto).
- El cliente no confía en el certificado de CA que se utiliza para firmar el certificado SSL para el servidor.
Porque NLA requiere un canal seguro que recibe credenciales, y no puede crear este túnel si no confía en el certificado, NLA no funcionará. Para solucionar este problema, asegúrese de que la máquina del cliente XP tiene el certificado utilizado para firmar el certificado SSL del servidor Host de sesión de escritorio remoto instalado en sus certificados de entidades emisoras raíz de confianza de equipo almacenar la carpeta.
Nota: Este error específico puede variar ligeramente de RDC 6.x a RDC 7.0. Si instala RDC 7.0, puede ver este mensaje de error: "La conexión ha terminado porque el equipo remoto se recibió un certificado de autenticación de servidor inesperado."