Compartir a través de

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

Este artículo le ayuda a solucionar problemas de 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 arrendatario {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 añadirse primero como usuario externo en el arrendatario. Cierre la sesión y vuelva a iniciarla con otra cuenta de usuario de Microsoft Entra.

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

Al intentar iniciar sesión en el Centro de Administración de Microsoft Entra con sus cuentas Microsoft personales (Outlook, Hotmail o OneDrive), se conecta al locatario de servicios de Microsoft automáticamente. 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 un directorio (por ejemplo: UserNamehotmail735.onmicrosoft.com) y se vincula 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 https://azure.microsoft.com/en-us/free/, y luego 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 de este inquilino.

Causa 2: Tipo de cuenta no admitido usado (cuentas multiinquilino y personales)

Si el registro de la aplicación se establece 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 sea un tipo de cuenta de inquilino único, siga estos pasos:

  1. En 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:

    • AzureAD y Cuenta personal de Microsoft
    • AzureADMultipleOrgs
    • PersonalMicrosoftAccount

    Si la configuración signInAudience no contiene uno de estos valores, vuelva a crear el registro de la aplicación teniendo seleccionado el tipo de cuenta correcto. Actualmente no se 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 la plataforma de identidad de Microsoft.

Causa 3: Se ha usado el punto de conexión incorrecto (cuentas personales y de 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 admitido del registro de la aplicación se estableció en uno de los siguientes valores:

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

  • Cuentas en cualquier directorio organizativo (cualquier directorio de 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 pueden acceder a la aplicación. Debe agregar estos usuarios como invitados en el inquilinato especificado en la solicitud. En ese caso, solo se espera que la autenticación 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: Usar 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 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, consulte Opciones de configuración de aplicaciones de la plataforma de identidad de Microsoft.

Causa 4: Iniciar sesión en el cliente incorrecto

Cuando los usuarios intentan acceder a su 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, los usuarios se redirigen para iniciar 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 está pensada para usarse. 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 valores de User account y Identity provider en el mensaje de error. ¿Coinciden esos valores con la combinación esperada o no? Por ejemplo, ¿inició un usuario sesión con su cuenta de organización en tu arrendatario en lugar de su arrendatario principal? ¿Ha iniciado sesión un usuario en el live.com proveedor de identidad usando una cuenta personal distinta de la que ya fue invitada?

Solución: cierre sesión y vuelva a iniciar sesión desde un explorador diferente o una sesión privada del explorador.

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

Causa 5: El usuario invitado no fue invitado

El usuario invitado que intentó iniciar sesión no estaba autorizado para el inquilino.

Solución: Invitar al usuario invitado

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

Causa 6: La aplicación requiere la asignación de usuarios

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

  1. En 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 requerida está establecida en Sí.

Solución: Asignar acceso a 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 un 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 solo admite ROPC en inquilinos de Microsoft Entra, no en cuentas personales.

Solución: use un punto de conexión específico para el inquilino o la 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 se inviten a una entidad de Microsoft Entra no pueden utilizar ROPC. Para obtener más información, consulte Plataforma de identidad de Microsoft y Credenciales de contraseña del propietario de recursos de OAuth 2.0.

Causa 8: el administrador del arrendatario de origen recreó un nombre de usuario eliminado anteriormente.

Puede producirse un error AADSTS50020 si se vuelve a crear, por parte del administrador del inquilino de origen, el nombre de un usuario invitado que se eliminó en un inquilino de recursos compartidos. 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:

Comprobación: compruebe si el usuario invitado del inquilino de recursos es más antiguo que la cuenta de usuario del inquilino principal.

Para comprobar la fecha de creación de la cuenta de usuario invitado, puede usar Microsoft Graph, Microsoft Entra PowerShell o el SDK de PowerShell de Microsoft Graph.

Microsoft Graph

Emita una solicitud a MS Graph API 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, compare la fecha de creación del usuario invitado en el inquilino de recursos con 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.

Microsoft Entra PowerShell

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

Get-EntraUser -UserId {id | userPrincipalName} | Select-Object id, userPrincipalName, createdDateTime

A continuación, compare la fecha de creación del usuario invitado en el inquilino de recursos con 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.

SDK de Microsoft Graph para PowerShell

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

$p = @('Id', 'UserPrincipalName', 'CreatedDateTime')
Get-MgUser -UserId {id | userPrincipalName} -Property $p| Select-Object $p

A continuación, compare la fecha de creación del usuario invitado en el inquilino de recursos con 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.

Solución: Restablecer el estado de redención de la cuenta de invitado del usuario

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

Ponte en contacto con nosotros para obtener ayuda

Si tiene preguntas o necesita ayuda, cree una solicitud de soporte técnico o solicite soporte técnico a la comunidad de Azure. También puede enviar comentarios sobre el producto a la comunidad de comentarios de Azure.