Compartilhar via

Erro AADSTS50020 – A conta de usuário do provedor de identidade não existe no locatário

Este artigo ajuda você a solucionar problemas do código de erro AADSTS50020 retornado se um usuário convidado de um provedor de identidade (IdP) não puder entrar em um locatário de recurso no Microsoft Entra ID.

Sintomas

Quando um usuário convidado tenta acessar um aplicativo ou recurso no locatário do recurso, a entrada falha e a seguinte mensagem de erro é exibida:

AADSTS50020: A conta de usuário 'user@domain.com' do provedor de identidade {IdentityProviderURL} não existe no locatário {ResourceTenantName}.

Quando um administrador examina os registros de login no locatário principal, uma entrada de código de erro "90072" indica uma falha de login. A mensagem de erro afirma:

A conta de usuário {email} do provedor de identidade {idp} não existe no locatário {locatário} e não pode acessar o aplicativo {appId}({appName}) nesse locatário. A conta precisa ser adicionada primeiro como um usuário externo no tenant. Saia e entre novamente com uma conta de usuário diferente do Microsoft Entra.

Causa 1:Os usuários fazem logon no Centro de administração do Microsoft Entra usando contas pessoais da Microsoft

Ao tentar fazer logon no centro de administração do Microsoft Entra usando suas contas pessoais da Microsoft (Outlook, Hotmail ou OneDrive), você está conectado ao locatário de Serviços da Microsoft por padrão. Dentro do locatário padrão, não há diretório vinculado para executar ações. O comportamento é esperado.

Na experiência anterior, um diretório (por exemplo: UserNamehotmail735.onmicrosoft.com) é criado e vinculado à conta pessoal, e você pode executar ações como criar contas de usuário no diretório. O comportamento agora foi alterado.

Solução: criar uma conta do Azure com um novo locatário

Se você pretende ter um diretório, deve criar uma conta do Azure e um novo locatário:

  1. Navegue até https://azure.microsoft.com/en-us/free/e selecione Iniciar gratuitamente .
  2. Siga as instruções para criar uma conta do Azure.
  3. Um locatário será gerado junto com a conta do Azure e você será designado automaticamente como o Administrador Global. Isso concede a você acesso total a todas as opções dentro desse locatário.

Causa 2: uso de tipo de conta sem suporte (contas multiempresariais e pessoais)

Se o registro do aplicativo estiver definido como um tipo de conta de locatário único, os usuários de outros diretórios ou provedores de identidade não poderão entrar nesse aplicativo.

Solução: alterar a configuração de público-alvo de entrada no manifesto de registro do aplicativo

Para garantir que o registro do aplicativo não seja um tipo de conta de locatário único, execute as seguintes etapas:

  1. No portal do Azure, pesquise e selecione Registros de aplicativo.

  2. Selecione o nome do registro do aplicativo.

  3. Na barra lateral, selecione Manifesto.

  4. No código JSON, localize a configuração signInAudience.

  5. Verifique se a configuração contém um dos seguintes valores:

    • Azure AD e Conta Pessoal da Microsoft
    • AzureADMultipleOrgs
    • Conta PessoalMicrosoft

    Se a configuração signInAudience não contiver um desses valores, recrie o registro do aplicativo selecionando o tipo de conta correto. No momento, não é possível alterar signInAudience no manifesto.

Para obter mais informações sobre como registrar aplicativos, consulte Guia de início rápido: registrar um aplicativo com a plataforma de identidade da Microsoft.

Causa 3: usou o endpoint errado (contas pessoais e de organização)

Sua chamada de autenticação deve ser direcionada a uma URL que corresponda à sua seleção se o tipo de conta com suporte do registro do aplicativo tiver sido definido como um dos seguintes valores:

  • Contas em qualquer diretório organizacional (qualquer diretório do Microsoft Entra - Multilocatário)

  • Contas em qualquer diretório organizacional (qualquer diretório do Microsoft Entra - Multilocatário) e contas pessoais da Microsoft (por exemplo, Skype, Xbox)

  • Somente contas pessoais da Microsoft

Se você usar https://login.microsoftonline.com/<YourTenantNameOrID>, os usuários de outras organizações não poderão acessar o aplicativo. Você precisa adicionar esses usuários como convidados no locatário especificado na solicitação. Nesse caso, espera-se que a autenticação seja executada somente em seu locatário. Esse cenário causará o erro de entrada se você espera que os usuários entrem usando a federação com outro locatário ou provedor de identidade.

Solução: use a URL de login correta

Use a URL de entrada correspondente para o tipo de aplicativo específico, conforme listado na tabela a seguir:

Tipo de aplicativo URL de login
Aplicativos multilocatários https://login.microsoftonline.com/organizations
Contas multiusuário e pessoais https://login.microsoftonline.com/common
Somente contas pessoais https://login.microsoftonline.com/consumers

No código do aplicativo, aplique esse valor de URL na configuração de Authority. Para obter mais informações sobre Authority, consulte as Opções de configuração do aplicativo da plataforma de identidade da Microsoft.

Causa 4: conectado ao tenant errado

Quando os usuários tentam acessar seu aplicativo, eles recebem um link direto para o aplicativo ou tentam obter acesso por meio do https://myapps.microsoft.com. Em qualquer situação, os usuários são redirecionados para entrar no aplicativo. Em alguns casos, o usuário pode já ter uma sessão ativa que usa uma conta pessoal diferente daquela que deve ser usada. Ou eles têm uma sessão que usa a conta da organização, embora pretendam usar uma conta de convidado pessoal (ou vice-versa).

Para ter certeza de que esse cenário é o que está causando o problema, procure os valores User account e Identity provider na mensagem de erro. Esses valores correspondem à combinação esperada ou não? Por exemplo, um usuário entrou usando a conta da sua organização no seu locatário em vez de seu locatário principal? Ou um usuário entrou no live.com provedor de identidade usando uma conta pessoal diferente daquela que já havia sido convidada?

Solução: saia e entre novamente em um navegador diferente ou em uma sessão privada do navegador

Instrua o usuário a abrir uma nova sessão de navegador privada ou fazer com que o usuário tente acessar de um navegador diferente. Nesse caso, os usuários devem sair da sessão ativa e tentar entrar novamente.

Causa 5: o usuário convidado não foi convidado

O usuário visitante que tentou entrar não foi convidado para o locatário.

Solução: convidar o usuário convidado

Siga as etapas em Início Rápido: Adicionar usuários convidados ao seu diretório no portal do Azure para convidar o usuário convidado.

Causa 6: o aplicativo requer atribuição de usuário

Se o aplicativo for um aplicativo empresarial que requer atribuição de usuário, ocorrerá um erro AADSTS50020 se o usuário não estiver na lista de usuários permitidos que recebem acesso ao aplicativo. Para verificar se seu aplicativo empresarial requer atribuição de usuário:

  1. No portal do Azure, pesquise e selecione Aplicativos empresariais.

  2. Selecione seu aplicativo empresarial.

  3. Na barra lateral, selecione Propriedades.

  4. Verifique se a opção Atribuição necessária está definida como Sim.

Solução: Atribuir acesso aos usuários individualmente ou como parte de um grupo

Use uma das seguintes opções para atribuir acesso aos usuários:

Causa 7: Tentativa de usar um fluxo de credenciais de senha do titular de recursos para contas pessoais

Se um usuário tentar usar o fluxo de credenciais de senha do proprietário do recurso (ROPC) para contas pessoais, ocorrerá um erro AADSTS50020 . A plataforma de identidade da Microsoft dá suporte ao ROPC somente em locatários do Microsoft Entra, não em contas pessoais.

Solução: usar um endpoint específico para o locatário ou organização

Use um endpoint específico do locatário (https://login.microsoftonline.com/<TenantIDOrName>) ou um endpoint da organização. Contas pessoais que são convidadas para um locatário do Microsoft Entra não podem usar ROPC. Para mais informações, confira Plataforma de identidade da Microsoft e credenciais de Senha de Proprietário do Recurso do OAuth 2.0.

Causa 8: Um nome de usuário excluído anteriormente foi criado novamente pelo administrador do locatário principal.

O erro AADSTS50020 pode ocorrer se o nome de um usuário convidado que foi excluído em um inquilino de recursos for recriado pelo administrador do inquilino principal. Para verificar se a conta de usuário convidado no locatário do recurso não está associada a uma conta de usuário no locatário inicial, use uma das seguintes opções:

Verificação: cheque se o usuário convidado do inquilino do recurso é mais antigo do que a conta de usuário do inquilino principal.

Para verificar a data de criação da conta de usuário convidado, você pode usar o Microsoft Graph, o Microsoft Entra PowerShell ou o SDK do Microsoft Graph PowerShell.

Gráfico da Microsoft

Emita uma solicitação para a API do MS Graph para revisar a data de criação do usuário, da seguinte maneira:

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

Em seguida, verifique a data de criação do usuário convidado no locatário do recurso em relação à data de criação da conta de usuário no locatário inicial. O cenário é confirmado se o usuário convidado tiver sido criado antes da criação da conta de usuário do locatário principal.

Microsoft Entra PowerShell

Execute o cmdlet Get-EntraUser PowerShell para examinar a data de criação do usuário, da seguinte maneira:

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

Em seguida, verifique a data de criação do usuário convidado no locatário do recurso em relação à data de criação da conta de usuário no locatário inicial. O cenário é confirmado se o usuário convidado tiver sido criado antes da criação da conta de usuário do locatário principal.

SDK do PowerShell do Microsoft Graph

Execute o cmdlet Get-MgUser PowerShell para examinar a data de criação do usuário, da seguinte maneira:

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

Em seguida, verifique a data de criação do usuário convidado no locatário do recurso em relação à data de criação da conta de usuário no locatário inicial. O cenário é confirmado se o usuário convidado tiver sido criado antes da criação da conta de usuário do locatário principal.

Solução: redefinir o status de resgate da conta de usuário convidado

Restaure o status de resgate da conta de usuário convidado no tenant de recurso. Em seguida, você pode manter o objeto de usuário convidado sem precisar excluir e recriar a conta de convidado. Você pode redefinir o status de resgate usando o portal do Azure, o Azure PowerShell ou a API do Microsoft Graph. Para obter instruções, consulte Redefinir o status de resgate para um usuário convidado.

Entre em contato conosco para obter ajuda

Se você tiver dúvidas ou precisar de ajuda, crie uma solicitação de suporte ou peça ajuda à comunidade de suporte do Azure. Você também pode enviar comentários sobre o produto para a comunidade de comentários do Azure.