Gonzalo MarsilliUn inicio de sesión de Microsoft Entra puede abrir una aplicación Windows en AWS sin pedir al usuario una segunda contraseña de Active Directory. El resultado parece sencillo. El recorrido que lo hace posible no lo es.
Claims de identidad, permisos IAM, confianza de certificados, datos de revocación, DNS, unión al dominio y capacidad de la flota deben coincidir. Una solución correcta valida el recorrido completo y documenta los errores que un simple arranque de la aplicación no detectaría.
La arquitectura permite iniciar desde el navegador una sesión Windows Server unida al dominio mediante certificate-based authentication (CBA). El modelo de validación comprueba la aplicación publicada, la identidad Windows resultante, el fallback con contraseña y la desactivación/reactivación de CBA.
¿Por qué usar autenticación con certificados?
Queríamos comprobar si una organización que usa Microsoft Entra ID y Active Directory puede ofrecer una ruta más directa hacia aplicaciones Windows publicadas. Entra sigue siendo el punto de autenticación principal, con MFA y políticas de acceso. CBA elimina la petición adicional de la contraseña AD durante el streaming.
El modelo resulta útil cuando una aplicación aún necesita una identidad de dominio Windows, pero el usuario no debería gestionar otro paso de acceso. Entre los posibles casos están las aplicaciones empresariales, el acceso controlado para colaboradores y las aplicaciones que conviene mantener cerca de los datos corporativos.
Passwordless no significa ausencia de autenticación. AWS describe CBA como un flujo respaldado por SAML en el que WorkSpaces Applications solicita un certificado de usuario y lo presenta mediante una tarjeta inteligente virtual. El proveedor de identidad autentica primero al usuario.
Para comparar plataformas, consulta nuestra comparativa de AWS WorkSpaces, Azure Virtual Desktop y Citrix.
¿Qué debe demostrar una solución completa?
Una implementación defendible debería superar 11 pruebas de aceptación antes de considerarse correcta. Una ventana de aplicación abierta no basta como evidencia.
Las comprobaciones cubrieron aislamiento de cuenta, autenticación Entra, mapeo SAML, unión al dominio, confianza de CA, dos rutas de revocación, inicio sin contraseña AD, fallback, reversibilidad de CBA y desmontaje controlado.
El resultado principal es la continuidad de identidad. UPN y SID parten de Active Directory, se sincronizan con Entra, atraviesan la aserción SAML y vuelven al mismo usuario de Windows. Esta coincidencia convierte una transmisión correcta en un resultado de identidad verificado.
¿Cómo funciona el recorrido de identidad y certificado?
El diseño une dos flujos: la federación establece quién puede entrar en el stack de AWS, mientras que la PKI permite que Windows autentique a esa persona en Active Directory sin mostrar la petición de contraseña.
- El usuario se autentica con Microsoft Entra ID.
- Entra envía una aserción SAML con NameID persistente, rol, UPN, ObjectSid y dominio AD.
- AWS STS crea la sesión federada. La política de confianza permite
sts:AssumeRoleWithSAMLysts:TagSession. - WorkSpaces Applications reserva capacidad en la flota unida al dominio.
- El servicio solicita un certificado de usuario de corta duración a AWS Private CA.
- Windows recibe el certificado mediante una tarjeta inteligente virtual y lo asigna a la identidad AD prevista.
El SID no es un detalle secundario. En los requisitos previos de CBA, AWS exige que ObjectSid coincida con el SID de AD del usuario indicado en el NameID SAML. La misma guía requiere sts:TagSession y un punto de distribución CRL accesible por la flota y el controlador de dominio.
Un enfoque de implementación en seis etapas
Un entorno de prueba seguro debería permanecer aislado y deliberadamente pequeño. Debería usar una cuenta AWS no productiva dedicada, sin rutas ni relaciones de confianza con redes de clientes o producción.
La implementación tuvo seis etapas:
- Base: VPC dedicada, subredes privadas, salida controlada, etiquetas, presupuestos y administración mediante Systems Manager.
- Directorio: un controlador de dominio Windows desechable proporcionó AD DS, DNS, AD CS y el agente Entra Cloud Sync.
- Identidad híbrida: sincronizar un usuario estándar con Entra y comprobar UPN y SID local en cada frontera.
- Federación: una aplicación empresarial Entra emitió los claims SAML necesarios. El rol IAM autorizó el streaming y las etiquetas de sesión.
- PKI: usar la raíz empresarial AD CS para firmar una subordinada AWS Private CA de corta duración y publicar la cadena en los almacenes empresariales Root y NTAuth.
- Entrega: una imagen Windows Server 2022 personalizada, una flota multisesión Always-On y un stack en vista de aplicación entregaron el programa de prueba.
Para la revocación, AWS Private CA escribió su CRL en un origen S3 privado. CloudFront expuso solo la ruta HTTP no autenticada que necesitan los clientes PKI y mantuvimos S3 Block Public Access activo. Es el patrón documentado en la guía CRL de AWS Private CA.
Evidencias desde la conexión hasta la revocación
La primera evidencia es la pantalla de conexión. Muestra explícitamente el flujo de autenticación con certificados. La URL de streaming y el marco del navegador se eliminan de la vista publicada.
La segunda prueba está dentro de Windows. La demostración saneada abre Notepad en vista de aplicación y comprueba el token actual. Usuario y dominio se sustituyen por <TEST-USER> y <LAB-DOMAIN>.
La tercera evidencia es la revocación. La dirección CRL incluida en el certificado devuelve HTTP 200. El recorte excluye host público, identificador PCA, IP, identificadores de petición, ETag y marcas de tiempo.
Una validación completa también selecciona el fallback, autentica la misma identidad AD, desactiva CBA y vuelve a activarla. En cada estado debe regresar el comportamiento esperado. Esta prueba reversible evita confundir un éxito aislado con un diseño operable.
Lecciones comunes de implementación
Los problemas más difíciles aparecen en las fronteras entre servicios. Cuatro lecciones son transferibles:
- Inspeccionar la aserción SAML emitida. El portal puede parecer correcto aunque el nombre, valor o formato de comillas del claim sea incorrecto.
- Probar la URL CRL real del certificado. Publicar la CRL no demuestra que el controlador de dominio y la flota puedan recuperarla.
- Comprobar capacidad antes que identidad. Una flota Always-On sin sesiones disponibles puede producir errores parecidos a un fallo CBA.
- Separar desactivación y reducción de costes. Desactivar CBA no elimina los costes recurrentes de Private CA o NAT.
Para demostraciones intermitentes o pilotos conservados, un modelo operativo pilot-light con controles puede detener el controlador y la flota, eliminar NAT y Private CA reemplazables, y conservar bosque, imagen, stack, anclas de identidad y distribución CRL. La promoción crea una nueva CA subordinada y repite las pruebas de aceptación.
¿En qué escenarios puede ser útil?
El patrón encaja en organizaciones que ya confían en Entra para autenticar usuarios, pero aún dependen de aplicaciones Windows e identidades AD. Puede publicar una aplicación controlada por navegador o cliente, manteniendo ejecución, acceso a datos y políticas Windows dentro del entorno AWS.
Computer On Site diseña esta ruta de identidad en torno al tenant Entra, Active Directory, aplicaciones, controles de red y modelo operativo de cada cliente.
No es la respuesta predeterminada para toda carga. Las aplicaciones nativas de la nube quizá no necesiten una sesión AD. Un escritorio completo puede servir mejor a quien requiere un espacio persistente. Periféricos, latencia, licencias y gráficos deben probarse con usuarios y datos reales.
Nuestros servicios de cloud workspace cubren esa evaluación más amplia: identidad, aplicaciones, red, almacenamiento, seguridad, experiencia, operaciones y costes.
¿Qué debe cambiar antes de producción?
La configuración mínima de referencia no es un diseño de producción. Un entorno operativo debería usar al menos dos controladores de dominio en distintas zonas, separar los roles PKI duraderos, monitorizar y duplicar la publicación de revocación, aprobar backup y recuperación, reforzar límites administrativos y probar concurrencia y escalado.
También debe definirse la propiedad operativa. Alguien debe responsabilizarse de la aplicación Entra, el rol IAM, la identidad AD, el ciclo de vida de CA, el fallback, la retención de evidencias y la respuesta a incidentes. El diseño se completa cuando esas responsabilidades son explícitas.
Preguntas frecuentes
¿CBA elimina todas las contraseñas?
Elimina la petición de contraseña AD dentro de la sesión de WorkSpaces Applications. El usuario sigue autenticándose con el proveedor SAML, como Microsoft Entra ID, bajo las políticas de acceso y MFA de la organización.
¿La aplicación Windows sigue recibiendo una identidad AD?
Sí. El certificado de corta duración se presenta mediante una tarjeta inteligente virtual y se asigna al usuario AD sincronizado. La validación debe comprobar el token de Windows, no solo el inicio de la aplicación.
¿Por qué el acceso a la CRL forma parte de las pruebas?
Windows debe poder comprobar la validez de la cadena. AWS exige que el punto de distribución CRL sea accesible desde el controlador de dominio y la flota. Un CDP bloqueado o incorrecto puede romper CBA aunque SAML sea correcto.
¿La arquitectura de referencia está lista para producción?
No tal cual. Una demostración mínima puede usar un controlador, un rol AD CS multifunción y capacidad limitada. Producción requiere redundancia, separación de funciones, monitorización, revisión de seguridad, pruebas de carga y un rollback ensayado.
Convierte una idea de identidad en un piloto verificado
El valor de la solución no es solo una ventana de aplicación sin contraseña AD. Es un método repetible para demostrar identidad, confianza de certificados, revocación, capacidad, fallback y recuperación en conjunto.
Computer On Site puede diseñar y validar un piloto AWS para aplicaciones o escritorios según tu identidad, software y requisitos operativos. Háblanos de una evaluación de AWS workspace.