Editar

Compartir a través de


Preguntas frecuentes sobre la autenticación multifactor de Microsoft Entra

En estas preguntas más frecuentes se responden preguntas comunes sobre la autenticación multifactor de Microsoft Entra y el uso del servicio de autenticación multifactor. Se divide en preguntas sobre el servicio en general, los modelos de facturación, las experiencias del usuario y la solución de problemas.

Importante

En septiembre de 2022, Microsoft anunció el desuso del servidor de autenticación multifactor. A partir del 30 de septiembre de 2024, las implementaciones del servidor de autenticación multifactor ya no atenderán las solicitudes de autenticación multifactor, lo que podría provocar un error en las autenticaciones de su organización. Para garantizar que los servicios de autenticación funcionen sin interrupciones y sigan siendo compatibles, las organizaciones deben migrar los datos de autenticación de los usuarios al servicio de autenticación multifactor de Microsoft Entra basado en la nube mediante la utilidad de migración más reciente incluida en la última actualización del servidor de MFA. Para obtener más información, vea Migración del servidor MFA.

General

¿Cómo controla Azure Multifactor Authentication Server los datos de usuario?

Con el servidor de autenticación multifactor, los datos de usuario solo se almacenan 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 de autenticación multifactor envía datos al servicio en la nube de autenticación multifactor de Microsoft Entra para la autenticación. La comunicación entre el servidor de autenticación multifactor y el servicio en la nube de autenticación multifactor usa capa de sockets seguros (SSL) o seguridad de la capa de transporte (TLS) a través del puerto 443 saliente.

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:

  • identificador único (nombre de usuario o id. de servidor de autenticación multifactor 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 del servidor de autenticación multifactor
  • ip del servidor de autenticación multifactor
  • IP de cliente (si está disponible)

Los campos opcionales se pueden configurar en el servidor de autenticación multifactor.

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.

¿Qué códigos cortos se utilizan para enviar mensajes de texto a mis usuarios?

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á.

¿La autenticación multifactor de Microsoft Entra limita los inicios de sesión de usuario?

Sí, en determinados casos que normalmente implican solicitudes de autenticación repetidas en un breve período de tiempo, la autenticación multifactor de Microsoft Entra limita los intentos de inicio de sesión de usuario para proteger las redes de telecomunicaciones, mitigar los ataques de estilo de fatiga de MFA y proteger sus propios sistemas para beneficiarse de todos los clientes.

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

¿Se le aplican cargos a mi organización por el envío de llamadas telefónicas y mensajes de texto que se usan para la autenticación?

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.

En el modelo de facturación por usuario, ¿los cargos se aplican por todos los usuarios habilitados o solo por los que realizaron la verificación en dos pasos?

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.

¿Cómo funciona la facturación de la autenticación multifactor?

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.

¿Hay una versión gratuita de 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?

¿Puede mi organización cambiar entre los modelos de facturación de consumo por usuario y por autenticación en cualquier momento?

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. La reactivación de los servidores MFA para vincularlos al nuevo proveedor de MFA no afecta a la autenticación de mensajes de texto y llamadas telefónicas, pero las notificaciones de aplicaciones móviles dejan de funcionar para todos los usuarios hasta que reactivan 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.

¿Mi organización puede cambiar entre la facturación basada en el consumo y las suscripciones (un modelo basado en licencias) en cualquier momento?

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.

¿Mi organización tiene que usar y sincronizar las identidades para usar la autenticación multifactor de Microsoft Entra?

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 el servidor de autenticación multifactor de Azure 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.

Administración y soporte técnico de las cuentas de usuario

¿Qué debo decir a los usuarios que hagan si no reciben respuesta en el teléfono?

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.

¿Qué debo hacer si uno de los usuarios no puede acceder a su cuenta?

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.

¿Qué debo hacer si a uno de los usuarios se le pierde el teléfono en el que usa las contraseñas de aplicación?

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.

¿Qué ocurre si un usuario no puede iniciar sesión en aplicaciones que no sean derowser?

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.

Nota:

Autenticación moderna para clientes de Office 2013

Las contraseñas de aplicación solo son necesarias para las aplicaciones que no admiten la autenticación moderna. Los clientes de Office 2013 admiten protocolos de autenticación moderna, pero se deben configurar. La autenticación moderna está disponible para cualquier cliente con la actualización de marzo de 2015 o posterior de Office 2013. Para obtener más información, vea la entrada de blog Autenticación moderna actualizada de Office 365.

Mis usuarios dicen que hay ocasiones en que no reciben el mensaje de texto, pero se agota el tiempo de espera de la comprobació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.

¿Puedo cambiar la cantidad de tiempo que los usuarios tienen para escribir el código de verificación de un mensaje de texto antes de que se agote el tiempo de espera del sistema?

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.

Sugerencia

Si tiene varios servidores MFA, solo el que procesó la solicitud de autenticación original conoce el código de verificación que se envió al usuario. Cuando el usuario escribe el código, la solicitud de autenticación para validarlo tiene que enviarse al mismo servidor. Si la validación del código se envía a un servidor diferente, se deniega la autenticación.

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.

¿Puedo usar tokens de hardware con el servidor de autenticación multifactor?

Si usa el servidor de autenticación multifactor, puede importar tokens basados en tiempo de autenticación abierta (OATH) de terceros, contraseña única (TOTP) y, a continuación, usarlos para la verificación en dos pasos.

Puede usar tokens activeIdentity que son tokens OATH TOTP si coloca la clave secreta en un archivo CSV e importa al servidor de autenticación multifactor. 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

¿Puedo usar el servidor de autenticación multifactor para proteger Terminal Services?

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).

Los cambios de seguridad en Windows Server 2012 R2 cambiaron cómo el servidor de autenticación multifactor se conecta al paquete de seguridad de la 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.

Configuré el identificador de llamada en el Servidor de MFA, pero mis usuarios siguen recibiendo llamadas de autenticación multifactor provenientes de un autor de llamada anónimo.

Cuando se realizan llamadas de autenticación multifactor a través de la red telefónica pública, a veces se enrutan a través de un operador que no admite el identificador de llamada. 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.

¿Por qué se les pide a mis usuarios que registren su información de seguridad?

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.

Errors

¿Qué deben hacer los usuarios si ven un mensaje de error "La solicitud de autenticación no es para una cuenta activada" al usar notificaciones de aplicaciones móviles?

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. Seleccione Configurary siga las instrucciones para volver a configurar Microsoft Authenticator.

¿Qué deben hacer los usuarios si ven un mensaje de error 0x800434D4L al iniciar sesión en una aplicación que no sea derowser?

El error de 0x800434D4L se produce cuando intenta iniciar sesión en una aplicación que no sea derowser, instalada en un equipo local, que no funciona con cuentas que requieren verificación en dos pasos.

Una solución alternativa para este error es tener cuentas de usuario independientes para las operaciones relacionadas con el administrador y noadmin. Más adelante, puede vincular buzones entre la cuenta de administrador y la cuenta que no sea de administrador para que pueda iniciar sesión en Outlook mediante su cuenta que no sea de administrador. 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.

¿Cuáles son las posibles razones por las que se produce un error en un usuario con el código de error "Error en LsaLogonUser con NTSTATUS -1073741715 para el servidor de MFA"?

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 MFA solo admite NTLMv1 (LmCompatabilityLevel=1 a 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 el profesional de Microsoft a través de compatibilidad con el servidor de autenticación multifactor. 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.