Error AADSTS50020: la cuenta de usuario del proveedor de identidades no existe en el inquilino

  • Artículo

Este artículo le ayuda a solucionar el código AADSTS50020 de error que se devuelve si un usuario invitado de un proveedor de identidades (IdP) no puede iniciar sesión en un inquilino de recursos en Microsoft Entra ID.

Síntomas

Cuando un usuario invitado intenta acceder a una aplicación o recurso en el inquilino de recursos, se produce un error en el inicio de sesión y se muestra el siguiente mensaje de error:

AADSTS50020: La cuenta de usuario 'user@domain.com' del proveedor de identidades {IdentityProviderURL} no existe en el inquilino {ResourceTenantName}.

Cuando un administrador revisa los registros de inicio de sesión en el inquilino principal, una entrada de código de error "90072" indica un error de inicio de sesión. El mensaje de error indica:

La cuenta de usuario {email} del proveedor de identidades {idp} no existe en el inquilino {tenant} y no puede acceder a la aplicación {appId}({appName}) en ese inquilino. La cuenta debe agregarse primero como usuario externo en el inquilino. Cierre la sesión y vuelva a iniciar sesión con una cuenta de usuario Microsoft Entra diferente.

Causa 1: Los usuarios inician sesión en Centro de administración Microsoft Entra mediante cuentas personales de Microsoft

Cuando intenta iniciar sesión en Centro de administración Microsoft Entra con sus cuentas personales de Microsoft (Outlook, Hotmail o OneDrive), está conectado al inquilino de Servicios de Microsoft de forma predeterminada. Dentro del inquilino predeterminado, no hay ningún directorio vinculado para realizar ninguna acción. Este comportamiento es normal.

En la experiencia anterior, se crea y vincula un directorio (por ejemplo, UserNamehotmail735.onmicrosoft.com) a la cuenta personal, y puede realizar acciones como la creación de cuentas de usuario en el directorio. Ahora se ha cambiado el comportamiento.

Solución: Creación de una cuenta de Azure con un nuevo inquilino

Si tiene como objetivo tener un directorio, debe crear una cuenta de Azure y un nuevo inquilino:

  1. Vaya a y, a https://azure.microsoft.com/en-us/free/continuación, seleccione Iniciar gratis .
  2. Siga las instrucciones para crear una cuenta de Azure.
  3. Se generará un inquilino junto con la cuenta de Azure y se le designará automáticamente como administrador global. Esto le concede acceso total a todas las opciones dentro de este inquilino.

Causa 2: Se ha usado un tipo de cuenta no compatible (cuentas multiinquilino y personales)

Si el registro de la aplicación está establecido en un tipo de cuenta de inquilino único, los usuarios de otros directorios o proveedores de identidades no pueden iniciar sesión en esa aplicación.

Solución: cambiar la configuración de audiencia de inicio de sesión en el manifiesto de registro de la aplicación

Para asegurarse de que el registro de la aplicación no es un tipo de cuenta de inquilino único, siga estos pasos:

  1. En el Azure Portal, busque y seleccione Registros de aplicaciones.

  2. Seleccione el nombre del registro de la aplicación.

  3. En la barra lateral, seleccione Manifiesto.

  4. En el código JSON, busque la configuración signInAudience .

  5. Compruebe si la configuración contiene uno de los siguientes valores:

    • AzureADandPersonalMicrosoftAccount
    • AzureADMultipleOrgs
    • PersonalMicrosoftAccount

    Si la configuración signInAudience no contiene uno de estos valores, vuelva a crear el registro de la aplicación con el tipo de cuenta correcto seleccionado. Actualmente no puede cambiar signInAudience en el manifiesto.

Para obtener más información sobre cómo registrar aplicaciones, consulte Inicio rápido: Registro de una aplicación con el Plataforma de identidad de Microsoft.

Causa 3: Se ha usado el punto de conexión incorrecto (cuentas personales y de la organización)

La llamada de autenticación debe tener como destino una dirección URL que coincida con la selección si el tipo de cuenta compatible del registro de la aplicación se estableció en uno de los siguientes valores:

  • Cuentas en cualquier directorio organizativo (cualquier directorio Microsoft Entra multiinquilino)

  • Cuentas en cualquier directorio organizativo (cualquier directorio Microsoft Entra multiinquilino) y cuentas personales de Microsoft (por ejemplo, Skype, Xbox)

  • Solo cuentas personales de Microsoft

Si usa https://login.microsoftonline.com/<YourTenantNameOrID>, los usuarios de otras organizaciones no podrán acceder a la aplicación. Debe agregar estos usuarios como invitados en el inquilino especificado en la solicitud. En ese caso, se espera que la autenticación solo se ejecute en el inquilino. Este escenario provoca el error de inicio de sesión si espera que los usuarios inicien sesión mediante la federación con otro inquilino o proveedor de identidades.

Solución: use la dirección URL de inicio de sesión correcta.

Use la dirección URL de inicio de sesión correspondiente para el tipo de aplicación específico, como se muestra en la tabla siguiente:

Tipo de aplicación Dirección URL de inicio de sesión
Aplicaciones multiinquilino https://login.microsoftonline.com/organizations
Cuentas multiinquilino y personales https://login.microsoftonline.com/common
Solo cuentas personales https://login.microsoftonline.com/consumers

En el código de la aplicación, aplique este valor de dirección URL en la Authority configuración. Para obtener más información sobre Authority, vea Plataforma de identidad de Microsoft opciones de configuración de la aplicación.

Causa 4: Iniciar sesión en el inquilino incorrecto

Cuando los usuarios intentan acceder a la aplicación, se les envía un vínculo directo a la aplicación o intentan obtener acceso a través de https://myapps.microsoft.com. En cualquier situación, se redirige a los usuarios para que inicien sesión en la aplicación. En algunos casos, es posible que el usuario ya tenga una sesión activa que use una cuenta personal diferente a la que se va a usar. O bien, tienen una sesión que usa su cuenta de organización aunque pretenden usar una cuenta de invitado personal (o viceversa).

Para asegurarse de que este escenario es el problema, busque los User account valores y Identity provider en el mensaje de error. ¿Esos valores coinciden con la combinación esperada o no? Por ejemplo, ¿un usuario ha iniciado sesión con su cuenta de organización en el inquilino en lugar de en su inquilino principal? ¿O un usuario inició sesión en el live.com proveedor de identidades con una cuenta personal diferente a la que ya se invitó?

Solución: cierre la sesión y vuelva a iniciar sesión desde otro explorador o desde una sesión de explorador privado.

Indique al usuario que abra una nueva sesión del explorador en privado o que intente acceder a ella desde otro explorador. En este caso, los usuarios deben cerrar la sesión desde su sesión activa y, a continuación, intentar iniciar sesión de nuevo.

Causa 5: No se invitó al usuario invitado

El usuario invitado que intentó iniciar sesión no fue invitado al inquilino.

Solución: Invitar al usuario invitado

Asegúrese de seguir los pasos descritos en Inicio rápido: Agregar usuarios invitados al directorio en el Azure Portal para invitar al usuario invitado.

Causa 6: La aplicación requiere asignación de usuario

Si la aplicación es una aplicación empresarial que requiere asignación de usuarios, se produce un error AADSTS50020 si el usuario no está en la lista de usuarios permitidos a los que se asigna acceso a la aplicación. Para comprobar si la aplicación empresarial requiere asignación de usuario:

  1. En el Azure Portal, busque y seleccione Aplicaciones empresariales.

  2. Seleccione la aplicación empresarial.

  3. En la barra lateral, seleccione Propiedades.

  4. Compruebe si la opción Asignación necesaria está establecida en Sí.

Solución: Asignar acceso a los usuarios individualmente o como parte de un grupo

Use una de las siguientes opciones para asignar acceso a los usuarios:

Causa 7: Se intentó usar un flujo de credenciales de contraseña de propietario de recursos para cuentas personales

Si un usuario intenta usar el flujo de credenciales de contraseña del propietario del recurso (ROPC) para cuentas personales, se produce un error AADSTS50020 . El Plataforma de identidad de Microsoft admite ROPC solo en Microsoft Entra inquilinos, no en cuentas personales.

Solución: use un punto de conexión específico para el inquilino u organización.

Use un punto de conexión específico del inquilino (https://login.microsoftonline.com/<TenantIDOrName>) o el punto de conexión de la organización. Las cuentas personales que están invitadas a un inquilino de Microsoft Entra no pueden usar ROPC. Para obtener más información, vea Plataforma de identidad de Microsoft y credenciales de contraseña de propietario de recursos de OAuth 2.0.

Causa 8: El administrador del inquilino principal ha vuelto a crear un nombre de usuario eliminado anteriormente

Puede producirse un error AADSTS50020 si el administrador del inquilino principal vuelve a crear el nombre de un usuario invitado que se eliminó en un inquilino de recursos. Para comprobar que la cuenta de usuario invitado del inquilino de recursos no está asociada a una cuenta de usuario en el inquilino principal, use una de las siguientes opciones:

Opción de comprobación 1: Compruebe si el usuario invitado del inquilino del recurso es anterior a la cuenta de usuario del inquilino principal.

La primera opción de comprobación implica comparar la antigüedad del usuario invitado del inquilino del recurso con la cuenta de usuario del inquilino principal. Puede realizar esta comprobación mediante Microsoft Graph o PowerShell MSOnline.

Microsoft Graph

Emita una solicitud al Graph API MS para revisar la fecha de creación del usuario, como se indica a continuación:

GET https://graph.microsoft.com/v1.0/users/{id | userPrincipalName}/createdDateTime

A continuación, compruebe la fecha de creación del usuario invitado en el inquilino del recurso con respecto a la fecha de creación de la cuenta de usuario en el inquilino principal. El escenario se confirma si el usuario invitado se creó antes de crear la cuenta de usuario del inquilino principal.

MSOnline PowerShell

Nota:

El módulo de PowerShell MSOnline está establecido en desuso. Dado que también es incompatible con PowerShell Core, asegúrese de que usa una versión compatible de PowerShell para que pueda ejecutar los siguientes comandos.

Ejecute el cmdlet Get-MsolUser de PowerShell para revisar la fecha de creación del usuario, como se indica a continuación:

Get-MsolUser -SearchString user@contoso.com | Format-List whenCreated

A continuación, compruebe la fecha de creación del usuario invitado en el inquilino del recurso con respecto a la fecha de creación de la cuenta de usuario en el inquilino principal. El escenario se confirma si el usuario invitado se creó antes de crear la cuenta de usuario del inquilino principal.

Nota:

Los módulos de PowerShell de Azure AD y MSOnline están en desuso a partir del 30 de marzo de 2024. Para obtener más información, lea la actualización de desuso. Después de esta fecha, la compatibilidad con estos módulos se limita a la ayuda de migración al SDK de PowerShell de Microsoft Graph y a las correcciones de seguridad. Los módulos en desuso seguirán funcionando hasta el 30 de marzo de 2025.

Se recomienda migrar a Microsoft Graph PowerShell para interactuar con Microsoft Entra ID (anteriormente Azure AD). Para obtener preguntas comunes sobre la migración, consulte las Preguntas más frecuentes sobre la migración. Nota: Las versiones 1.0.x de MSOnline pueden experimentar interrupciones después del 30 de junio de 2024.

Opción de comprobación 2: Compruebe si el identificador de seguridad alternativo del inquilino del recurso difiere del identificador de red de usuario del inquilino principal.

Nota:

El módulo de PowerShell MSOnline está establecido en desuso. Dado que también es incompatible con PowerShell Core, asegúrese de que usa una versión compatible de PowerShell para que pueda ejecutar los siguientes comandos.

Cuando un usuario invitado acepta una invitación, el atributo del LiveID usuario (el identificador de inicio de sesión único del usuario) se almacena en AlternativeSecurityIds el key atributo . Dado que la cuenta de usuario se eliminó y creó en el inquilino principal, el NetID valor de la cuenta habrá cambiado para el usuario del inquilino principal. Compare el NetID valor de la cuenta de usuario en el inquilino principal con el valor de clave almacenado dentro AlternativeSecurityIds de la cuenta de invitado en el inquilino de recursos, como se indica a continuación:

  1. En el inquilino principal, recupere el valor del LiveID atributo mediante el Get-MsolUser cmdlet de PowerShell:

    Get-MsolUser -SearchString tuser1 | Select-Object -ExpandProperty LiveID

  2. En el inquilino del recurso, convierta el valor del key atributo dentro de AlternativeSecurityIds en una cadena codificada en base64:

    [convert]::ToBase64String((Get-MsolUser -ObjectId 01234567-89ab-cdef-0123-456789abcdef
       ).AlternativeSecurityIds.key)

  3. Convierta la cadena codificada en base64 en un valor hexadecimal mediante un convertidor en línea (como base64.guru).

  4. Compare los valores de los pasos 1 y 3 para comprobar que son diferentes. El NetID de la cuenta de usuario en el inquilino principal cambió cuando se eliminó la cuenta y se volvió a crear.

Solución: restablecer el estado de canje de la cuenta de usuario invitado

Restablezca el estado de canje de la cuenta de usuario invitado en el inquilino del recurso. A continuación, puede mantener el objeto de usuario invitado sin tener que eliminar y, a continuación, volver a crear la cuenta de invitado. Puede restablecer el estado de canje mediante el Azure Portal, Azure PowerShell o microsoft Graph API. Para obtener instrucciones, consulte Restablecer el estado de canje de un usuario invitado.

Ponte en contacto con nosotros para obtener ayuda

Si tiene preguntas o necesita ayuda, cree una solicitud de soporte o busque consejo en la comunidad de Azure. También puede enviar comentarios sobre el producto con los comentarios de la comunidad de Azure.