Monosign MFA: diseño, despliegue y resolución de problemas
Qué ha cambiado
Cada actualización del contenido se versiona. Seleccione una versión para compararla con la anterior.
Versión 9 → 10
ActualizaciónNuevo módulo sobre decisiones de acceso y recuperación: restricciones de acceso y definiciones de políticas, passkeys e inicio de sesión sin contraseña en operación, Kerberos y MFA, recuperación de contraseña, desbloqueo de cuenta, los mosaicos de inicio de sesión de Windows y verificación de identidad.
3 lecciones actualizadas
Actualización de contenido. Se notificó a los estudiantes inscritos.
Monosign tiene dos herramientas que deciden si un inicio de sesión puede continuar. Se parecen y se comportan de forma muy distinta.
| Herramienta | Qué hace | Uso típico |
| --- | --- | --- |
| Restricción de acceso | Permite o deniega un objeto, como un usuario, en una aplicación | Bloquear una sola cuenta o impedirle el acceso a ciertas horas |
| Política de autenticación | Decide qué factores y pasos necesita un inicio de sesión, por ámbito y prioridad | MFA fuera de la oficina, una passkey para administradores |
Una restricción nunca pide MFA. Solo deja pasar el inicio de sesión o lo rechaza.
### Restricciones de acceso
Management → Security → `Restrictions`, o la pestaña `Access Restrictions` del usuario. Una fila tiene un `Object`, `Access Types` (`Allow` o `Deny`), un `Scope Object` (la aplicación), `Start Date`, `End Date` y un `Cron` opcional.
Tres reglas explican la mayoría de las incidencias de soporte:
- **Solo se comprueba al iniciar sesión.** Un nuevo `Deny` no termina una sesión que ya está abierta. Durante un incidente, añada la restricción y cierre además las sesiones del usuario en Management → `Sessions`.
- **Gana el primer `Allow` que coincide.** La evaluación se detiene ahí, y una fila `Deny` posterior se ignora. Antes de añadir un `Deny`, revise las filas que el usuario ya tiene.
- **El ámbito debe ser la aplicación en la que el usuario inicia sesión.** Una fila con ámbito en otra aplicación no afecta a ese inicio de sesión.
::diagram mfa-restriction-evaluation
`Cron` limita un `Deny` a una franja horaria del día. Sus horas son **UTC**, no la hora local del servidor ni la del usuario. Una oficina en Estambul (UTC+3) que quiera bloquear de 18:00 a 08:00 hora local escribe `0 15-23,0-4 * * *`. Desde v2026.10 la franja se aplica tal como está escrita. En versiones anteriores, un `Deny` con `Cron` y una vigencia de más de un día bloqueaba las 24 horas, así que vuelva a probar esas filas después de una actualización.
`Remove` termina una fila fijando su fecha de fin. La fila se conserva como historial.
### Definiciones de políticas
Management → Security → `Policies` contiene las definiciones. El lab de acceso condicional construye un conjunto completo de políticas; estas son las reglas del propio editor:
- **`Type` se elige una sola vez.** Solo puede seleccionarse mientras se crea la definición. `Generic` sirve únicamente para filtrar; un flujo de inicio de sesión necesita `Authentication`. Una definición no se puede clonar ni cambiar de tipo, por lo que una guardada con el tipo equivocado se sustituye por una nueva.
- **Una definición `Authentication` necesita al menos un elemento `Scope` y un elemento `Flow`.** Los elementos de flujo están en la pestaña `Actions`.
- `Priority` va de 1 a 10, y cada definición necesita un nombre único.
- Una definición que usa un paquete de acceso no puede deshabilitarse ni eliminarse. Desvincúlela primero del paquete.
Las passkeys son el factor más fuerte del catálogo y traen sus propias reglas de operación. Planifíquelas antes del despliegue, no después de la primera incidencia.
### El registro pertenece al usuario
Una passkey se registra en la aplicación Account, dentro de la propia sesión del usuario. Un administrador no puede registrarla en nombre de un usuario desde Management, y el servicio de asistencia no puede preparar passkeys para un equipo por adelantado. Planifique que las personas se registren por sí mismas: una guía breve, un periodo de tiempo y una segunda passkey u otro factor como vía de regreso.
### Eliminar la última passkey
Cuando un usuario elimina su última passkey, el método `Passkeys` se desactiva para él. Si era su único factor, se queda sin factor de MFA hasta que vuelva a registrarse. No hay ningún recurso automático. Añádalo al proceso de retirada de dispositivos: primero se registra en el dispositivo nuevo y después se elimina el antiguo.
### Cada dirección de inicio de sesión debe ser un host del tenant
Una passkey está vinculada a la dirección web en la que se registró, y Monosign obtiene esa dirección de los hosts del tenant de Account. Si los usuarios llegan a las páginas de inicio de sesión mediante un nombre de host que no está registrado como host del tenant de Account, el navegador rechaza el paso de passkey, mientras que el inicio de sesión con contraseña en el mismo host sigue funcionando. El registro de la API muestra entonces `Tenant host not found for host`.
Por tanto, cuando el cliente añada un nuevo nombre de host, compruebe primero que está registrado como host del tenant de Account. Tenga en cuenta además que una passkey registrada en un host no se acepta en otro.
### `Passwordless Login` y lo que sustituye
Con `Passwordless Login` activado, un usuario puede iniciar sesión solo con una passkey. Ese inicio de sesión cuenta como MFA para el ajuste de dos factores **del propio usuario**. No satisface una **política de autenticación** que pide un segundo factor: en una aplicación cubierta por una política así, al usuario se le sigue pidiendo MFA después de la passkey. También se sigue exigiendo un cambio de contraseña pendiente. Explíqueselo al cliente; de lo contrario, los primeros usuarios de passkeys lo notificarán como un fallo.
### Kerberos vuelve a ser distinto
El inicio de sesión con Kerberos en dispositivos unidos al dominio elimina la petición de contraseña, pero, a diferencia de los demás inicios de sesión sin contraseña, la sesión no se considera verificada con MFA. Un usuario con MFA habilitada, o una aplicación cuyo nivel de autenticación exige MFA, sigue recibiendo el desafío de MFA después del ticket. Es el comportamiento esperado. Si un cliente no quiere ninguna petición en una aplicación concreta, eso es una decisión sobre el ajuste de MFA de la aplicación, no un fallo de Kerberos.
::diagram mfa-passwordless-and-mfa
> Consejo: `Passkeys` es el método que debe usarse tanto para passkeys de plataforma como para llaves de seguridad FIDO2. Deje deshabilitada la fila heredada `Security Key`.
Los usuarios que no pueden iniciar sesión representan la mayor parte de las llamadas al servicio de asistencia. Monosign les ofrece vías de autoservicio, y cada una tiene límites que el servicio de asistencia debe conocer.
### Recuperación de contraseña
Un usuario que ha olvidado su contraseña empieza en la página de boarding con `I don't remember my password`, se identifica y demuestra quién es con un factor de MFA, con preguntas de seguridad o con ambos. Los interruptores están en System → `Configurations` → pestaña `Boarding`.
Dos comportamientos generan incidencias:
- **El SMS se oculta cuando existe otro factor.** Si el usuario tiene más de un factor verificado, el factor SMS no se ofrece en la página de recuperación. Un usuario cuya aplicación se restableció o cuyo teléfono se sustituyó no puede recurrir allí al SMS, y el servicio de asistencia tiene que ayudarle. Téngalo en cuenta al decidir qué factores deben registrar los usuarios.
- **Puede que ya haya un código en camino.** La recuperación comparte el tiempo de espera de reenvío con el inicio de sesión, como explica la lección sobre el envío de códigos.
### Desbloqueo de cuenta
Un usuario bloqueado puede desbloquear la cuenta desde la misma página con un código de un solo uso enviado por SMS o push móvil. Los límites:
- El desbloqueo **solo quita el bloqueo**. No restablece la contraseña y no vuelve a habilitar una cuenta deshabilitada por otro motivo, por ejemplo por RR. HH. o por un administrador. Ese usuario completa el desbloqueo y sigue sin poder iniciar sesión.
- El código es válido durante una hora. Desde v2026.09, los códigos erróneos están limitados a cinco por solicitud.
- Solo se ofrecen SMS y push, y solo a los usuarios que ya los han registrado y verificado.
### En la pantalla de inicio de sesión de Windows
Un usuario que no puede entrar en Windows no tiene navegador para llegar a estas páginas. Monofor Identity Client añade mosaicos independientes a la pantalla de inicio de sesión, y cada uno tiene una sola función:
| Mosaico | Finalidad |
| --- | --- |
| `Monosign MFA Credential Provider` | Contraseña de Windows y después MFA de Monosign |
| `Monosign QR Login`, `Monosign Push Login` | Inicio de sesión sin contraseña con la aplicación Monofor Identity |
| `Self Service Portal` | Restablecimiento de contraseña y desbloqueo de cuenta desde la pantalla de bloqueo |
Para el personal de campo sin un segundo dispositivo, `Self Service Portal` es la función que debe seleccionarse en el instalador. Los demás mosaicos no restablecen una contraseña olvidada.
::diagram mfa-self-service-paths
### Verificación de identidad
Algunos accesos necesitan algo más que un factor: la prueba de que la persona es quien dice ser. En Identity → `Verification` se conecta como origen un proveedor de verificación de identidad. El usuario completa la verificación de documento y selfie en el flujo alojado del proveedor desde la aplicación Account y vuelve con un nivel de garantía de `IAL1` a `IAL3`, que se guarda en el usuario.
Hay dos formas de exigirla:
- **Para un usuario, ahora**: el panel `Identity Assurance` del usuario → `Request identity verification`.
- **Para todos los que coinciden con una política**: la acción de política `Require Identity Verification` en una política de autenticación. Al iniciar sesión genera una solicitud cuando el nivel del usuario está por debajo del requerido.
Monosign no comprueba los documentos por sí mismo; lo hace el proveedor. Las preguntas de seguridad, los magic links y las restricciones de acceso no sustituyen a la verificación de identidad.