Implemente 2FA / MFA para RDP sin perder el acceso
Lira incorpora un segundo factor al inicio de sesión de Windows. La activación modifica el control de acceso: prepare una vía de recuperación, registre un usuario piloto, pruebe una conexión RDP nueva desde otro equipo y amplíe la política por etapas.
No active MFA para todas las cuentas en el primer paso.
Si los usuarios aún no están registrados, el portal no está disponible o Credential Provider falla, una activación general puede interrumpir el acceso remoto. Mantenga una vía de recuperación comprobada fuera del flujo RDP protegido.
Por qué RDP necesita autenticación de dos factores (2FA/MFA)
Una contraseña puede ser obtenida mediante phishing, reutilizada, interceptada por software malicioso o adivinada. MFA exige una prueba independiente antes de crear la sesión RDP y reduce el riesgo de que una contraseña robada permita acceso administrativo.
MFA complementa, pero no sustituye, Network Level Authentication, la exposición limitada de RDP, el bloqueo de intentos, las cuentas nominativas, el registro de eventos, las actualizaciones y un procedimiento de recuperación probado.
¿Se puede restaurar el acceso desde la consola Lira?
Sí, mientras quede disponible al menos un canal de administración independiente.
Dirección del administrador bloqueada: abra el portal desde la misma red externa, use Obtener mi IP pública en la lista permitida, añada la dirección detectada y espere la sincronización de Windows Firewall en los agentes.
Política MFA para RDP incorrecta: active una omisión temporal o seleccione Desactivado. El agente en línea retira la aplicación obligatoria en el siguiente intercambio de políticas.
Certificado TLS de RDP incorrecto: seleccione Restaurar listener. El agente elimina la asociación forzada, activa Negotiate y reinicia los servicios RDP.
Si el servicio del agente está detenido, un superadministrador puede reiniciarlo mediante WinRM configurado previamente. Si no están disponibles el agente ni WinRM, se requiere una consola local, de hipervisor, iLO/iDRAC/KVM/VNC o acceso físico.
Qué cambia al iniciar sesión
Lira Credential Provider participa en la pantalla de inicio de Windows antes de crear el escritorio. Tras aceptar la contraseña, el usuario protegido debe completar el segundo factor configurado.
Los clientes RDP habituales siguen siendo válidos; el cambio se concentra en el límite de autenticación y por ello debe implantarse por etapas.
1. Prepare el acceso de recuperación
Confirme el acceso directo a la consola o al hipervisor.
Prepare una cuenta administrativa de emergencia y proteja sus credenciales según la política de acceso privilegiado.
Pruebe esa cuenta antes de cambiar MFA.
Defina quién puede usarla y cómo se auditará.
La cuenta de emergencia no sustituye MFA; es un mecanismo controlado para recuperar el servicio.
2. Registre y pruebe un usuario piloto
Elija una cuenta nominativa con credenciales Windows conocidas.
Cree el registro en Lira y añada el secreto TOTP a la aplicación autenticadora.
Verifique un código vigente en el portal.
Active MFA solo para ese usuario y un servidor.
Abra una conexión nueva desde otro cliente y complete contraseña y MFA.
Cierre sesión y repita la prueba para descartar una sesión almacenada.
3. Elija conscientemente la política de disponibilidad
Fail open conserva la disponibilidad durante una interrupción temporal, pero debilita transitoriamente el segundo factor.
Fail closed conserva la exigencia estricta, pero puede impedir el acceso si el servicio de verificación no responde.
Documente el modo, las excepciones, el responsable de recuperación y la interrupción máxima aceptable.
4. Amplíe la política por grupos
Comience con un servidor y un usuario.
Continúe con administradores capaces de informar de incidencias.
Incorpore después usuarios por departamento o grupo de servidores.
No retire las excepciones temporales hasta completar la validación.
Validación y recuperación
Compruebe un inicio RDP nuevo y el rechazo de un TOTP no válido.
Confirme que el portal registra la decisión y que el agente sigue en línea.
Verifique la hora y la vía de emergencia.
Si falla, no repita contraseñas: use la consola, desactive la exigencia afectada, confirme la entrega de la política y analice hora, registro, conectividad y Credential Provider antes de reactivarla.
Preguntas frecuentes
¿Por qué puede rechazarse un código válido?
TOTP depende de la hora. Compruebe Windows, el controlador de dominio y el teléfono, y verifique que el código corresponde al registro actual y no ha caducado.