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 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. Primero se debe agregar la cuenta como usuario externo en el inquilino. 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), 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 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 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 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:

   • AzureADandPersonalMicrosoftAccount
   • 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 el 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 inquilino 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:

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 Plataforma de identidad de Microsoft opciones de configuración de aplicaciones.

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 https://myapps.microsoft.comde . 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 User account valores y Identity provider en el mensaje de error. ¿Coinciden esos valores con la combinación esperada o no? Por ejemplo, ¿un usuario inicia sesión con su cuenta de organización en el inquilino en lugar de su inquilino principal? O bien, ¿un usuario ha iniciado sesión en el live.com proveedor de identidades mediante una cuenta personal diferente a la que ya se ha invitado?

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 fue invitado al 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:

• Para asignar individualmente el acceso de usuario a la aplicación, consulte Asignación de una cuenta de usuario a una aplicación empresarial.

• Para asignar usuarios si son miembros de un grupo asignado o de un grupo dinámico, consulte Administración del acceso a una aplicación.

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 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 invitan a un inquilino de Microsoft Entra no pueden usar ROPC. Para más información, consulte Plataforma de identidad de Microsoft y credenciales de contraseña de propietario de recursos de OAuth 2.0.

Causa 8: el administrador de inquilinos de inicio volvió 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 verificació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 verificació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 MSOnline PowerShell.

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

PowerShell de MSOnline

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 de recursos en 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.

Opción de verificación 2: compruebe si el identificador de seguridad alternativo de invitado del inquilino de recursos difiere del identificador de red de usuario del inquilino principal

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 en el 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 de recursos, 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 del paso 1 y el paso 3 para comprobar que son diferentes. De NetID la cuenta de usuario del inquilino principal cambió cuando se eliminó y se volvió a crear la cuenta.

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 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 o busque consejo en la comunidad de Azure. También puede enviar comentarios sobre el producto con los comentarios de la comunidad de Azure.