Compartir a través de

Consideraciones para las conexiones de Escritorio remoto en una implementación de autenticación sin contraseñas resistente al phishing en Microsoft Entra ID

Normalmente, las organizaciones que implementan sistemas sin contraseña resistentes al phishing necesitan que algunos de sus usuarios usen tecnología de escritorio remoto para facilitar la productividad, la seguridad o la administración. Los dos casos de uso básicos son:

  • Inicialización y autenticación de una sesión de conexión de Escritorio remoto desde un cliente local a una máquina remota mediante credenciales sin contraseña resistentes a la suplantación de identidad (phishing)
  • Uso de credenciales sin contraseña resistentes a la suplantación de identidad dentro de una sesión de conexión de Escritorio remoto establecida

Revise las consideraciones específicas para cada caso de uso.

Componentes de conexión de Escritorio Remoto

El protocolo de escritorio remoto de Windows implica tres componentes principales, todos los cuales necesitan admitir correctamente credenciales sin contraseña resistentes a la suplantación de identidad para iniciar una sesión de conexión de Escritorio remoto mediante estas credenciales. Si alguno de estos componentes no puede funcionar correctamente o carece de compatibilidad con determinadas credenciales sin contraseña, uno o ambos escenarios descritos no funcionarán. Esta guía se centra en la compatibilidad con la clave de acceso/FIDO2 y el soporte de autenticación Cert-Based (CBA).

GIF que muestra la experiencia del usuario al usar Windows Hello para empresas para establecer una sesión de conexión a Escritorio remoto.

Diagrama de carriles que muestra cómo se usan las credenciales sin contraseña resistentes a la suplantación de identidad al conectarse mediante una conexión a Escritorio remoto

Recorra las secciones siguientes para determinar si se espera soporte para la autenticación sin contraseñas resistente al phishing en los tres componentes que está utilizando. Repita este proceso si tiene varios escenarios que requieren evaluación.

Plataforma cliente

Hay varios sistemas operativos usados habitualmente para los clientes locales que se utilizan para iniciar sesiones de escritorio remoto. Entre las opciones más usadas se incluyen:

  • Windows 10+
  • Windows Server
  • macOS
  • Ios
  • Androide
  • Linux

La compatibilidad con la conexión sin contraseña y el escritorio remoto resistente al phishing depende de que la plataforma cliente tenga compatibilidad con protocolos de claves de paso, en particular el protocolo Client To Authenticator (CTAP) y WebAuthn. CTAP es una capa de comunicación entre autenticadores móviles, como claves de seguridad FIDO2 o claves de acceso en un dispositivo móvil y una plataforma cliente. La mayoría de las plataformas cliente admiten estos protocolos, pero hay determinadas plataformas que no. En algunos casos, como con dispositivos de cliente ligero dedicados que ejecutan sistemas operativos especializados, debe ponerse en contacto con el proveedor para confirmar el soporte técnico.

La autenticación basada en certificados (CBA) de Microsoft Entra requiere la configuración en el identificador de Microsoft Entra para que los usuarios puedan usar certificados de la infraestructura de clave pública (PKI) para la autenticación. En este artículo no se abordan solo las implementaciones de autenticación basada en certificados locales.

Plataforma cliente Compatibilidad con FIDO Microsoft Entra CBA Notas
Windows 10+ Sí Sí
Windows Server Parcial Sí Windows Server no se recomienda para dispositivos informáticos de cliente.

Los servidores de salto de Windows Server pueden dificultar los sistemas sin contraseña resistentes al phishing basados en FIDO. Si usa servidores de salto, se recomienda CBA en lugar de FIDO.
macOS Sí Sí No todos los marcos web de Apple admiten FIDO
Ios Sí Sí No todos los marcos web de Apple admiten FIDO
Androide Sí Sí
Linux Es posible Sí Confirmación de la compatibilidad con FIDO con el proveedor de distribución de Linux

Plataforma de destino

La plataforma objetivo es fundamental para determinar si se admite la autenticación sin contraseña resistente al phishing para establecer la sesión de conexión de escritorio remoto.

Plataforma de destino Inicialización de la sesión de conexión a Escritorio remoto con soporte FIDO Inicialización de sesión de conexión a Escritorio remoto Microsoft Entra CBA
Windows 10+ Microsoft Entra unido Sí Sí
Windows Server unido a Microsoft Entra Sí1 Sí
Windows 10+ unido de forma híbrida a Microsoft Entra Sí Sí
Windows Server unido de forma híbrida a Microsoft Entra Sí1 Sí
Windows 10+ registrado en Microsoft Entra No No
Solo unido a un dominio local de Windows 10+ No No
Solo unido a un dominio local de Windows Server No No
Grupo de trabajo de Windows 10+ No No
Windows Server independiente o de grupo de trabajo administrado por Azure Arc Sí Sí

1. Solo se aplica a los servidores unidos a Microsoft Entra o unidos híbridos que ejecutan Windows Server 2022 o posterior
2. Solo se aplica a los servidores unidos a Microsoft Entra que ejecutan Windows Server 2025 o posterior

Cliente de conexión a Escritorio remoto

La compatibilidad de la plataforma del cliente para la autenticación resistente al phishing no es suficiente para admitir este tipo de autenticación en las sesiones de conexión a Escritorio remoto. El cliente de conexión a Escritorio remoto usado también debe admitir los componentes necesarios para que estas credenciales funcionen correctamente. Revise muchos de los clientes de conexión a Escritorio remoto usados habitualmente y sus distintas opciones admitidas:

Cliente de conexión a Escritorio remoto Inicialización de la sesión de conexión a Escritorio remoto con soporte FIDO Inicialización de sesión de conexión a Escritorio remoto Microsoft Entra CBA
MSTSC.exe para el cliente de Windows Sí Sí
MSTSC.exe para Windows Server 2022+ Sí Sí
MSTSC.exe para Windows Server 2019 o versiones anteriores No No
Aplicación de Windows para Windows Sí Sí
Aplicación de Windows para macOS Sí Sí
Aplicación de Windows para iOS Sí Sí
Aplicación de Windows para Android Sí Sí
Aplicación web de Windows 365 No No
Cliente de terceros para conexión a Escritorio remoto Es posible Es posible

Importante

Los dispositivos cliente y de destino deben estar unidos a Microsoft Entra, unidos a Microsoft Entra híbrido o registrados en Microsoft Entra en el mismo tenant. La autenticación entre arrendatarios no funcionará, el dispositivo cliente no podrá autenticarse en el dispositivo de destino si pertenecen a diferentes arrendatarios.

Evaluación de la compatibilidad con los escenarios

Si alguno de los tres componentes descritos en este documento no admite su escenario, no se espera que el escenario funcione. Para evaluarlo, considere cada componente de la autenticación de la sesión de conexión a escritorio remoto y el uso de credenciales en la sesión. Repita este proceso para cada escenario del entorno para comprender qué escenarios se espera que funcionen y cuáles no.

Ejemplo 1

Por ejemplo, este es el modo en que podría evaluar si su escenario es "mis trabajadores de la información deben usar sus dispositivos Windows para acceder a Azure Virtual Desktop, deben autenticar la sesión de conexión de Escritorio remoto mediante una clave de acceso microsoft Authenticator y usar la clave de acceso dentro de la sesión de conexión de Escritorio remoto en el explorador Microsoft Edge":

Escenario Plataforma cliente Plataforma de destino Cliente de conexión a Escritorio remoto ¿Está soportado?
Inicialización de sesión de conexión a Escritorio remoto mediante la clave de paso de la aplicación de autenticación Windows 11 Microsoft Entra unido/Unión híbrida/Aislado Azure Virtual Desktop se ha unido a Microsoft Entra Aplicación de Windows Sí+Sí+Sí = Sí
Conexión a Escritorio remoto In-Session autenticación mediante la clave de acceso de la aplicación de autenticación Windows 11 Microsoft Entra unido/Unión híbrida/Aislado Azure Virtual Desktop se ha unido a Microsoft Entra Aplicación de Windows Sí+Sí+Sí = Sí

En este ejemplo, tanto la propia sesión de conexión de Escritorio remoto como las aplicaciones en sesión pueden aprovechar la clave de acceso del usuario. La tecnología sin contraseña resistente a suplantaciones de identidad (phishing) debería funcionar de forma generalizada.

Ejemplo 2

Aquí se muestra cómo puede evaluar si su escenario es "mis trabajadores de la información necesitan usar sus dispositivos macOS para acceder a Azure Virtual Desktop, deben autenticar la sesión de conexión de escritorio remoto usando una clave de paso de Microsoft Authenticator y usar la clave de paso dentro de la sesión de conexión de escritorio remoto":

Escenario Plataforma cliente Plataforma de destino Cliente de conexión a Escritorio remoto ¿Está soportado?
Inicialización de sesión de conexión a Escritorio remoto mediante la clave de paso de la aplicación de autenticación macOS 15 Azure Virtual Desktop se ha unido a Microsoft Entra Aplicación de Windows Sí+Sí+Sí = Sí
Conexión a Escritorio remoto In-Session autenticación mediante la clave de acceso de la aplicación de autenticación macOS 15 Azure Virtual Desktop se ha unido a Microsoft Entra Aplicación de Windows Sí+Sí+No = No

En este ejemplo, los usuarios pueden usar su clave de acceso para establecer la sesión de conexión a Escritorio remoto, pero no pueden usarla dentro de la sesión de conexión a Escritorio remoto porque la aplicación de Windows en macOS aún no admite esta funcionalidad. Puede esperar un mejor soporte para las claves de paso en el cliente de conexión a Escritorio remoto o puede cambiar a otra credencial, como los certificados con CBA.

Ejemplo 3

Aquí se muestra cómo puede evaluar si el escenario es "mis administradores deben usar sus dispositivos Windows para acceder a servidores de Windows locales, tener que autenticar la sesión de conexión de Escritorio remoto mediante un certificado y usar el certificado dentro de la sesión de conexión a Escritorio remoto":

Escenario Plataforma cliente Plataforma de destino Cliente de conexión a Escritorio remoto ¿Está soportado?
Inicialización de sesión de conexión a Escritorio remoto mediante certificado Windows 11 Domain-Joined Windows Server MSTSC.exe Sí+Sí+Sí = Sí
Conexión a Escritorio remoto In-Session autenticación mediante certificado Windows 11 Domain-Joined Windows Server MSTSC.exe Sí+Sí+Sí = Sí

En este ejemplo, los usuarios pueden usar su certificado para establecer la sesión de conexión a Escritorio remoto y también usar el certificado dentro de la sesión de conexión a Escritorio remoto. Sin embargo, este escenario no funcionará con una clave de acceso, ya que el servidor windows unido al dominio no puede usar una clave de acceso para configurar una sesión de conexión de Escritorio remoto o dentro de la sesión.

Ejemplo 4

Este es el modo en que podría evaluar si el escenario es "mis trabajadores de primera línea deben usar un cliente ligero basado en Linux para acceder a los clientes de infraestructura de escritorio virtual (VDI) de Windows, unidos a un dominio local que no están en unión híbrida de Microsoft Entra, necesitan autenticar la sesión de conexión a Escritorio Remoto mediante una clave de seguridad FIDO2 y usar la clave de seguridad FIDO2 dentro de la sesión de Conexión a Escritorio Remoto":

Escenario Plataforma cliente Plataforma de destino Cliente de conexión a Escritorio remoto ¿Está soportado?
Inicialización de sesión de conexión a Escritorio remoto mediante la clave de seguridad FIDO2 Distribución embebida de Linux Domain-Joined Windows 11 Cliente proporcionado por el proveedor No+Tal vez+No = No
Conexión a Escritorio remoto In-Session autenticación mediante la clave de seguridad FIDO2 Distribución embebida de Linux Domain-Joined Windows 11 Cliente proporcionado por el proveedor Tal vez+Sí+Tal vez = Tal vez

En este ejemplo, es probable que los usuarios no puedan usar sus claves de seguridad FIDO2 para la conexión a Escritorio remoto, ya que el sistema operativo de cliente fino y el cliente de conexión a Escritorio remoto no admiten claves FIDO2 o passkeys en todos los escenarios necesarios. Trabaje con su proveedor de cliente ligero para comprender su hoja de ruta de soporte técnico. Además, planee unir o integrar Microsoft Entra híbridamente a las máquinas virtuales de la plataforma de destino para mejorar el soporte de las claves de acceso.

Pasos siguientes

Implementación de la autenticación sin contraseña y resistente a la suplantación de identidad en Microsoft Entra ID