Preguntas frecuentes sobre la autenticación multifactor de Microsoft Entra

Con Servidor Multi-Factor Authentication, los datos del usuario se almacenan solo en los servidores locales. Los datos de usuario persistentes no se almacenan en la nube. Cuando el usuario realiza la verificación en dos pasos, el Servidor Multi-Factor Authentication envía datos al servicio en la nube de autenticación multifactor de Microsoft Entra para la autenticación. Para establecer la comunicación entre Servidor Multi-Factor Authentication y el servicio en la nube de autenticación multifactor se utilizan los protocolos Capa de sockets seguros (SSL) o Seguridad de la capa de transporte (TLS) en el puerto 443 de salida.

Cuando se envían solicitudes de autenticación al servicio en la nube, se recopilan datos para los informes de uso y autenticación. Los campos de datos siguientes se incluyen en los registros de comprobación en dos pasos:

• Id. único (cualquier nombre de usuario o id. de Servidor Multi-Factor Authentication local)
• Nombre y apellidos (opcional)
• Dirección de correo electrónico (opcional)
• Número de teléfono (cuando se utiliza una llamada de voz o autenticación por mensaje de texto)
• Token de dispositivo (al realizar la autenticación de una aplicación móvil)
• Modo de autenticación
• Resultado de la autenticación
• Nombre de Servidor Multi-Factor Authentication
• IP de Servidor Multi-Factor Authentication
• IP de cliente (si está disponible)

Los campos opcionales pueden configurarse en Servidor Multi-Factor Authentication.

El resultado de la comprobación (aceptación o denegación) y el motivo de la denegación se almacenan con los datos de autenticación. Los datos están disponibles en los informes de autenticación y uso.

Para obtener más información, vea Residencia de datos y datos de clientes en la autenticación multifactor de Microsoft Entra.

En Estados Unidos, utilizamos los siguientes códigos cortos:

• 97671
• 69829
• 51789
• 99399

En Canadá, utilizamos los siguientes códigos cortos:

• 759731
• 673801

No hay garantía de que los mensajes de texto o las solicitudes de autenticación multifactor basadas en la voz se envíen por el mismo número. En interés de nuestros usuarios, podemos agregar o eliminar códigos cortos en cualquier momento a medida que realizamos ajustes de ruta para mejorar la capacidad de entrega de los mensajes de texto.

No admitimos códigos cortos para países o regiones que no sean Estados Unidos y Canadá.

Sí, en determinados casos que suelen implicar solicitudes de autenticación repetidas en un breve espacio de tiempo, la autenticación multifactor de Microsoft Entra limitará los intentos de inicio de sesión de los usuarios para proteger las redes de telecomunicaciones, mitigar los ataques del estilo de fatiga de MFA y proteger sus propios sistemas en beneficio de todos los clientes.

Aunque no compartimos límites específicos, se basan en un uso razonable.

No, no se le cobrará nada por las llamadas de teléfono individuales que se realicen o los mensajes de texto que se envíen a los usuarios cuando se use la autenticación multifactor de Microsoft Entra. Si usa un proveedor de MFA por autenticación, se le facturará por cada autenticación pero no por el método que se use.

Podrían cobrarse a los usuarios las llamadas de teléfono o los mensajes de texto que reciban, dependiendo de su servicio telefónico personal.

La facturación se basa en la cantidad de usuarios que están configurados para usar la autenticación multifactor, sin tener en cuenta si realizaron o no una verificación en dos pasos el mes en cuestión.

Cuando se crea un proveedor de MFA por usuario o por autenticación, se factura mensualmente a la suscripción de Azure de su organización según el uso. Este modelo de facturación es similar a la forma en que Azure factura el uso de máquinas virtuales y Web Apps.

Al adquirir una suscripción para la Autenticación multifactor de Microsoft Entra, su organización solo paga la cuota de licencia anual para cada usuario. Las licencias MFA y Microsoft 365, Microsoft Entra ID P1 p P2, o Enterprise Mobility + Security se facturan de esta manera.

Para obtener más información, consulte Cómo obtener la autenticación multifactor de Microsoft Entra.

Los valores predeterminados de seguridad se pueden habilitar en el nivel Gratis de Microsoft Entra ID. Con los valores predeterminados de seguridad, todos los usuarios están habilitados para la autenticación multifactor mediante la aplicación Microsoft Authenticator. No se puede usar el mensaje de texto ni la comprobación del teléfono con los valores predeterminados de seguridad, solo la aplicación Microsoft Authenticator.

Para obtener más información, vea ¿Cuáles son los valores de seguridad predeterminados?

Si la organización adquiere MFA como servicio independiente con facturación basada en el consumo, se elige un modelo de facturación cuando se crea un proveedor de MFA. No se puede cambiar el modelo de facturación después de que se crea un proveedor de MFA.

Si el proveedor de MFA no está vinculado a un inquilino de Microsoft Entra o si vincula el nuevo proveedor de MFA a un inquilino de Microsoft Entra diferente, los valores de usuario y las opciones de configuración no se transferirán. Además, los servidores MFA se tendrán que reactivar mediante las credenciales de activación generadas a través del nuevo proveedor de MFA. Reactivar los servidores MFA para vincularlos al nuevo proveedor de MFA no afecta a la autenticación por llamada telefónica y mensaje de texto, sino que las notificaciones de aplicación móvil dejarán de funcionar para todos los usuarios hasta que se reactive la aplicación móvil.

Obtenga más información sobre los proveedores de MFA en Introducción a un proveedor de autenticación multifactor de Azure.

En algunos casos, sí.

Si el directorio tiene un proveedor de autenticación multifactor de Microsoft Entra por usuario, puede agregar licencias de MFA. Los usuarios con licencia no se cuentan en la facturación basada en consumo por usuario. Los usuarios sin licencias podrán seguir habilitados para MFA a través del proveedor de MFA. Si compra y asigna licencias para todos los usuarios configurados para usar la autenticación multifactor, puede eliminar el proveedor de autenticación multifactor de Microsoft Entra. Siempre puede crear otro proveedor de MFA por usuario si en el futuro tiene más usuarios que licencias.

Si el directorio tiene un proveedor de autenticación multifactor de Microsoft Entra por autenticación, siempre se le factura por cada autenticación, mientras el proveedor de MFA esté vinculado a su suscripción. Puede asignar licencias de MFA a los usuarios, pero se le seguirá facturando por cada solicitud de verificación en dos pasos, independientemente de si viene de alguien que tiene asignada una licencia de MFA o no.

Si la organización usa un modelo de facturación basado en el consumo, Microsoft Entra ID es opcional, no obligatorio. Si el proveedor de MFA no está vinculado a un inquilino de Microsoft Entra, solo puede implementar Servidor Microsoft Azure Multi-Factor Authentication de manera local.

El modelo de licencia requiere Microsoft Entra ID porque las licencias se agregan al inquilino de Microsoft Entra cuando las compra y asigna a los usuarios en el directorio.

Haga que sus usuarios intenten hasta cinco veces en 5 minutos recibir una llamada telefónica o un mensaje de texto para autenticarse. Microsoft utiliza varios proveedores para realizar llamadas y enviar mensajes de texto. Si este enfoque no funciona, abra una incidencia de soporte técnico para solucionar el problema.

Las aplicaciones de seguridad de terceros también pueden bloquear el mensaje de texto del código de verificación o la llamada telefónica. Si usa una aplicación de seguridad de terceros, pruebe a deshabilitar la protección y, a continuación, solicitar que se envíe otro código de verificación de MFA.

Si los pasos anteriores no funcionan, compruebe si los usuarios están configurados para más de un método de comprobación. Intente volver a iniciar sesión, pero seleccione un método de comprobación distinto en la página de inicio de sesión.

Para obtener más información, consulte la guía de solución de problemas del usuario final.

Puede restablecer la cuenta del usuario; para ello, pídale que vuelva a realizar el proceso de registro. Obtener más información sobre administración de la configuración de usuarios y dispositivos con la autenticación multifactor Microsoft Entra en la nube.

Para evitar el acceso no autorizado, elimine todas las contraseñas de aplicación del usuario. Una vez que el usuario tenga un dispositivo de reemplazo, pueden volver a crearlas. Obtener más información sobre administración de la configuración de usuarios y dispositivos con la autenticación multifactor Microsoft Entra en la nube.

Si la organización todavía usa clientes heredados y se permite el uso de contraseñas de aplicación, los usuarios no podrán iniciar sesión en estos clientes heredados con su nombre de usuario y contraseña. En lugar de eso, deberán configurar contraseñas de aplicación. Los usuarios deben borrar (eliminar) su información de inicio de sesión, reiniciar la aplicación y, luego, iniciar sesión con su nombre de usuario y la contraseña de aplicación en lugar de la contraseña habitual.

Si la organización no tiene clientes heredados, no debe permitir que los usuarios creen contraseñas de aplicación.

La entrega de mensajes de texto no está garantizada porque hay factores incontrolables que pueden afectar a la fiabilidad del servicio. Estos factores incluyen el país o la región de destino, el operador del teléfono móvil y la intensidad de la señal.

Las aplicaciones de seguridad de terceros también pueden bloquear el mensaje de texto del código de verificación o la llamada telefónica. Si usa una aplicación de seguridad de terceros, pruebe a deshabilitar la protección y, a continuación, solicitar que se envíe otro código de verificación de MFA.

Si sus usuarios tienen problemas con frecuencia para recibir mensajes de texto de manera confiable, indíqueles que usen en su lugar la aplicación Microsoft Authenticator o el método de llamada de teléfono. Microsoft Authenticator puede recibir notificaciones con conexiones de telefonía móvil y Wi-Fi. Además, la aplicación móvil puede generar códigos de comprobación aunque el dispositivo no tenga señal. La aplicación Microsoft Authenticator está disponible para Android, iOS y Windows Phone.

En algunos casos, sí es posible.

Para SMS unidireccionales con el servidor MFA v7.0 o superior, puede configurar el ajuste de tiempo de espera estableciendo una clave del registro. Una vez que el servicio de nube MFA envía el mensaje de texto, se devuelve el código de verificación (o código de acceso de un solo uso) al servidor MFA. El servidor MFA almacena el código en la memoria durante 300 segundos de forma predeterminada. Si el usuario no escribe el código antes de que transcurran los 300 segundos, se denegará la autenticación. Siga estos pasos para cambiar la configuración de tiempo de espera predeterminada:

1. Ir a HKLM\Software\Wow6432Node\Positive Networks\PhoneFactor.
2. Cree una clave del Registro DWORD llamada pfsvc_pendingSmsTimeoutSeconds y establezca el tiempo (en segundos) durante el cual desea que el Servidor MFA almacene los códigos de acceso de un solo uso.

Si los usuarios no responden al SMS dentro del período de tiempo de espera definido, se deniega la autenticación.

Para SMS unidireccionales con la autenticación multifactor de Microsoft Entra en la nube (incluido el adaptador de AD FS o la extensión del Servidor de directivas de red), no puede configurar el ajuste de tiempo de espera. Microsoft Entra ID almacena el código de verificación durante 180 segundos.

Si usa Servidor Microsoft Multi-Factor Authentication, puede importar los tokens de contraseña de un solo uso de duración definida (TOTP) y los de autenticación abierta (OATH) de terceros y, después, utilizarlos para realizar la comprobación en dos pasos.

Puede usar tokens de ActiveIdentity del tipo OATH TOTP si coloca la clave secreta en un archivo CSV y lo importa a Servidor Multi-Factor Authentication. Puede usar tokens de OATH con Active Directory Federation Services (ADFS), autenticación basada en formularios de Internet Information Services (IIS) y Servicio de autenticación remota telefónica de usuario (RADIUS) siempre que el sistema cliente pueda aceptar las entradas de usuario.

Puede importar tokens de OATH TOTP de terceros con los siguientes formatos:

• Contenedor de claves simétricas portátil (PSKC)
• CSV si el archivo contiene un número de serie, una clave secreta en formato Base 32 y un intervalo de tiempo

Sí, pero si usa Windows Server 2012 R2 o versiones posteriores, solo puede proteger Terminal Services con Puerta de enlace de Escritorio remoto (Puerta de enlace de RD).

Gracias a los cambios de seguridad realizados en Windows Server 2012 R2, se ha modificado la forma en que Servidor Microsoft Multi-Factor Authentication se conecta al paquete de seguridad de autoridad de seguridad local (LSA) en Windows Server 2012 y versiones anteriores. Para las versiones de Terminal Services en Windows 2012 o versiones anteriores, puede proteger una aplicación con la autenticación de Windows. Sin embargo, si va a utilizar Windows Server 2012 R2, necesita el servicio Puerta de enlace de Escritorio remoto.

A veces, cuando las llamadas de autenticación multifactor se realizan a través de la red telefónica pública, se enrutan a través de un operador que no admite la característica de identificación de llamadas. Debido a este comportamiento del operador, los identificadores de llamada no están garantizados, aunque el sistema de autenticación multifactor los envíe siempre.

Hay varios motivos por los cuales se les pueden pedir a los usuarios que registren su información de seguridad:

• El administrador habilitó al usuario para MFA en Microsoft Entra ID, pero todavía no tiene registrada la información de seguridad de su cuenta.
• El usuario se ha habilitado para el autoservicio de restablecimiento de contraseña en Microsoft Entra ID. La información de seguridad le ayudará a restablecer su contraseña en el futuro si llegara a olvidarla.
• El usuario tuvo acceso a una aplicación con una directiva de acceso condicional para requerir MFA y no se registró anteriormente para MFA.
• El usuario registra un dispositivo con Microsoft Entra ID (incluida la unión a Microsoft Entra) y la organización requiere MFA para el registro de dispositivos, pero el usuario no se registró anteriormente para MFA.
• El usuario genera Windows Hello para empresas en Windows 10 (que requiere MFA) y no se registró anteriormente para MFA.
• La organización creó y habilitó una directiva de registro de MFA que se aplicó al usuario.
• El usuario se registró anteriormente para MFA, pero eligió un método de comprobación que un administrador deshabilitó desde entonces. Por lo tanto, el usuario debe volver a registrarse para MFA para poder seleccionar un método de comprobación predeterminado nuevo.

Pida al usuario que complete el siguiente procedimiento para quitar su cuenta de Microsoft Authenticator y, a continuación, agréguela de nuevo:

1. Vaya a su perfil de cuenta e inicie sesión con la cuenta de la organización.
2. Seleccione Comprobación de seguridad adicional.
3. Quite la cuenta existente de la aplicación Microsoft Authenticator.
4. Haga clic en Configurar y siga las instrucciones para volver a configurar Microsoft Authenticator.

El error 0x800434D4L se genera cuando intenta iniciar sesión en una aplicación sin explorador, instalada en un equipo local, que no funciona con las cuentas que requieren la verificación en dos pasos.

Una forma de solucionar este error es tener una cuenta de usuario independiente para las operaciones relacionadas con la administración y otra para las no administrativas. Más adelante, puede vincular los buzones entre la cuenta de administrador y una sin derechos administrativos; de este modo, podrá iniciar sesión en Outlook con la cuenta sin derechos administrativos. Para más información, consulte Dar a un administrador la capacidad de abrir y ver el contenido del buzón de correo de un usuario.

Error 1073741715 = Error de inicio de sesión de estado -> El intento de inicio de sesión no es válido. Esto se debe a un nombre de usuario o una autenticación no válidos.

Un motivo plausible de este error: si las credenciales principales especificadas son correctas, podría haber una discrepancia entre la versión de NTLM admitida en el servidor de MFA y el controlador de dominio. El servidor de MFA solo admite NTLMv1 (LmCompatabilityLevel=1 hasta 4) y no NTLMv2 (LmCompatabilityLevel=5).

Pasos siguientes

Si su pregunta no tiene aquí una respuesta, están disponibles las siguientes opciones de soporte técnico:

• Busque soluciones a problemas técnicos comunes en Microsoft Support Knowledge Base.
• Busque y examine cuestiones técnicas y sus respuestas en la comunidad, o bien realice su propia pregunta en Microsoft Entra Q&A.
• Póngase en contacto con un profesional de Microsoft a través del soporte técnico de Servidor Multi-Factor Authentication. Al ponerse en contacto con nosotros, nos resultará de gran utilidad que incluya tanta información sobre su problema como sea posible. Entre la información que puede aportar se incluyen la página donde vio el error, el código de error específico, el identificador de sesión específico y el identificador del usuario que vio el error.