- Implementación de protocolos modernos como OAuth y OpenID para aplicaciones UWP.
- Configuración de segundo factor de autenticación (2FA) mediante agentes especializados y Directorio Activo.
- Despliegue de métodos resistentes al phishing como FIDO2 y Windows Hello para empresas.
- Gestión de seguridad avanzada en entornos Windows Server mediante NPS y puertas de enlace de escritorio remoto.
Cuando hablamos de seguridad en entornos informáticos, la validación de la identidad es el pilar fundamental. No se trata solo de pedir una contraseña, sino de asegurar que quien intenta acceder a los recursos de la empresa sea realmente quien dice ser, evitando así intrusiones que podrían dejar el sistema totalmente expuesto.
En el ecosistema de Microsoft, existen diversas maneras de montar este sistema, desde el uso de aplicaciones modernas hasta la gestión de servidores robustos. Vamos a analizar a fondo cómo configurar estos agentes de autenticación para que tu red sea un búnker y no una puerta abierta para cualquier hacker, siguiendo los principios de seguridad informática y buenas prácticas.
Integración de aplicaciones UWP con proveedores externos
Si estás desarrollando una aplicación de la Plataforma Universal de Windows (UWP), lo más habitual es que quieras conectarla a un proveedor de identidades online que maneje protocolos como OAuth o OpenID. Para lograr esto, el método clave es AuthenticateAsync, el cual se encarga de lanzar la solicitud al proveedor y recuperar el token de acceso necesario para gestionar los recursos.
Lo primero que tienes que hacer es registrar tu aplicación con el proveedor elegido. Este paso es vital, ya que el proveedor te entregará un identificador de cliente o una clave secreta que servirá como «documento de identidad» de tu app. Sin este registro, el servidor externo simplemente rechazará cualquier intento de conexión.
Para que todo funcione, debes montar correctamente la URI de solicitud. Esta dirección debe ser estrictamente segura (HTTPS) e incluir parámetros como el ID de la aplicación, el tipo de respuesta y la URI de redireccionamiento. Un ejemplo típico de construcción de URL incluiría el client_id y los scopes solicitados para definir los permisos del token.
Una vez tengas la URI, ejecutas AuthenticateAsync. Dependiendo de la respuesta, podrías obtener un resultado exitoso con el token de acceso o un error HTTP si algo ha fallado en la comunicación. Es fundamental envolver este proceso en un bloque try-catch para gestionar posibles caídas de red o problemas de certificados SSL/TLS.
El Inicio de Sesión Único (SSO) y la persistencia
Por defecto, el agente de autenticación web no guarda cookies, lo que obliga al usuario a identificarse una y otra vez. Para evitar este engorro y habilitar el inicio de sesión único (SSO), el proveedor de identidad debe permitir cookies persistentes y tu aplicación debe usar la versión de AuthenticateAsync que no requiere una URI de callback.
Para que el SSO sea efectivo, el proveedor debe aceptar una URI de redireccionamiento con el formato ms-app://<appSID>. Puedes obtener el SID de tu aplicación directamente desde la página de desarrolladores o mediante el método GetCurrentApplicationCallbackUri, permitiendo que el usuario se mantenga registrado hasta que el token caduque.
Depuración y resolución de errores en AuthHost
A veces las cosas no salen a la primera y hay que rascar un poco para encontrar el fallo. Para ello, Windows ofrece registros operativos específicos en el canal Microsoft-Windows-WebAuth\Operational. Al activar este log en el visor de eventos, puedes ver exactamente cuándo empieza la navegación, si hay errores de código HTTP o si se han detectado metaetiquetas correctamente.
Un detalle curioso es que el agente de usuario añade la cadena «MSAuthHost/1.0» para identificarse en el servidor, aunque no conviene programar basándose en la versión ya que podría cambiar en el futuro. Si necesitas ir más allá, puedes usar Fiddler, pero requiere ajustar el registro de Windows creando la clave EnablePrivateNetwork para que el proceso authhost.exe tenga acceso a la red privada.
Además, para capturar el tráfico en Fiddler, debes ejecutar comandos de CheckNetIsolation.exe LoopbackExempt para los contenedores de AuthHost y configurar reglas en el firewall de Windows Defender que permitan el tráfico entrante a través del puerto 8888 o directamente al ejecutable de Fiddler.
Despliegue de FortiAuthenticator en entornos de dominio
En escenarios donde tenemos equipos Windows vinculados a un Directorio Activo (AD), el agente de FortiAuthenticator es una herramienta brutal para añadir capas de seguridad. Este agente permite implementar un segundo factor de autenticación (2FA) muy robusto, aunque actualmente dependa principalmente de la existencia de un AD para funcionar correctamente.
La configuración empieza por crear el dominio de autenticación y definir las IPs públicas y de reenvío. Si no configuras bien la IP de reenvío, las notificaciones push no llegarán al móvil del usuario y este tendrá que introducir el código OTP a mano, lo cual es bastante más lento y tedioso.
Dentro del FortiAuthenticator, es necesario crear un realm de autenticación vinculado a un servidor LDAP y habilitar la REST API y la API de FortiToken Mobile en la interfaz de red. Para mayor seguridad, se recomienda crear un administrador de API dedicado, restringiendo el acceso mediante claves API generadas en el panel de control del usuario administrador.
Un punto crítico es la autenticación offline. Para que el usuario pueda entrar al PC sin conexión, debes habilitar el soporte offline, configurar una clave secreta y establecer códigos de emergencia con una validez temporal corta para evitar que queden activos indefinidamente y supongan un riesgo.
Al instalar el agente en el PC, debes asegurarte de que la cuenta utilizada tenga permisos de administrador. En la configuración del agente, es vital incluir el dominio; si se usa el símbolo «.», se hace referencia a los usuarios locales. Si no se configuran correctamente los usuarios locales, estos podrían saltarse el segundo factor, dejando un agujero de seguridad importante.
Métodos de autenticación en Microsoft Entra ID
Microsoft Entra ID ofrece un abanico amplio de opciones para validar la identidad. Podemos usar métodos para el primer factor, para MFA o para el restablecimiento de contraseñas (SSPR). Sin embargo, no todo es igual; existen métodos resistentes a la suplantación (phishing) que son infinitamente más seguros que el clásico SMS o el OTP por correo.
Entre las opciones más recomendadas destacan Windows Hello para empresas, las claves de acceso FIDO2 y la autenticación basada en certificados (CBA). Estos sistemas evitan que un atacante, mediante ingeniería social o IA, pueda robar un código temporal, ya que requieren una prueba física o biométrica del usuario.
Para aquellos casos donde el usuario ha perdido absolutamente todas sus credenciales, Entra ID dispone de la recuperación de cuentas de alta garantía. Este proceso utiliza la verificación de documentos oficiales (pasaportes o licencias) combinada con coincidencia biométrica facial mediante Azure AI, eliminando la necesidad de que un operador de soporte técnico valide la identidad manualmente.
Configuración de MFA en Windows Server 2019
Si tienes un servidor 2019 en dominio y quieres meterle MFA, la ruta más común es pasar por el Servidor de Directivas de Red (NPS). Primero debes elegir tu proveedor (ya sea Microsoft Authenticator, Duo o Google) y luego instalar el rol de NPS desde el Administrador del Servidor.
La magia ocurre al configurar los clientes RADIUS en la consola de NPS, donde vinculas el servidor de puerta de enlace de Escritorio remoto mediante un secreto compartido. Es fundamental ajustar las políticas de red para admitir métodos como EAP-MSCHAP v2 o el uso de tarjetas inteligentes y certificados.
Finalmente, debes entrar en el Administrador de la Puerta de Enlace de Escritorio Remoto y definir que el servidor central que ejecute el NPS sea el encargado de validar los accesos. Una vez que el host de sesión (RDSH) esté apuntando a esta puerta de enlace, cualquier usuario que intente conectar remotamente tendrá que superar la validación MFA antes de entrar al sistema.
