Compartilhar via

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

  • Artigo

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

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 logs de entrada no locatário inicial, uma entrada de código de erro "90072" indica uma falha de entrada. 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 locatário. 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: tipo de conta sem suporte usado (contas multilocatários 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:

    • AzureADandPersonalMicrosoftAccount
    • AzureADMultipleOrgs
    • PersonalMicrosoftAccount

    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>o , 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 entrada
Aplicativos multilocatários https://login.microsoftonline.com/organizations
Contas multilocatários 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 Authority configuração. Para obter mais informações sobre Authorityo , consulte Opções de configuração do aplicativo da plataforma de identidade da Microsoft.

Causa 4: conectado ao locatário 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 problema, procure os User account valores e Identity provider na mensagem de erro. Esses valores correspondem à combinação esperada ou não? Por exemplo, um usuário entrou usando sua conta da organização para seu locatário em vez de seu locatário inicial? Ou um usuário entrou no live.com provedor de identidade usando uma conta pessoal diferente daquela que já foi 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 convidado 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 proprietário do recurso 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 ponto de extremidade específico para o locatário ou organização

Use um endpoint específico do locatário (https://login.microsoftonline.com/<TenantIDOrName>) ou o endpoint da organização. Contas pessoais são convidadas a um locatário do Microsoft Entra não é possível 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 recriado pelo administrador do locatário inicial

O erro AADSTS50020 poderá ocorrer se o nome de um usuário convidado que foi excluído em um locatário de recurso for recriado pelo administrador do locatário inicial. 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:

Opção de verificação 1: verificar se o usuário convidado do locatário do recurso é mais antigo que a conta de usuário do locatário inicial

A primeira opção de verificação envolve a comparação da idade do usuário convidado do locatário do recurso com a conta de usuário do locatário inicial. Você pode fazer essa verificação usando o Microsoft Graph ou o MSOnline PowerShell.

Microsoft Graph

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 será confirmado se o usuário convidado tiver sido criado antes da criação da conta de usuário do locatário inicial.

MSOnline PowerShell

Observação

O módulo MSOnline do PowerShell está definido para ser preterido. Como ele também é incompatível com o PowerShell Core, verifique se você está usando uma versão compatível do PowerShell para poder executar os comandos a seguir.

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

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

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 será confirmado se o usuário convidado tiver sido criado antes da criação da conta de usuário do locatário inicial.

Observação

Os módulos Azure AD e MSOnline PowerShell estão preteridos desde 30 de março de 2024. Para saber mais, leia a atualização de preterição. Após essa data, o suporte a esses módulos se limitará à assistência à migração para o SDK do Microsoft Graph PowerShell e às correções de segurança. Os módulos preteridos continuarão funcionando até 30 de março de 2025.

Recomendamos migrar para o Microsoft Graph PowerShell para interagir com o Microsoft Entra ID (antigo Azure AD). Para perguntas comuns sobre migração, consulte as Perguntas Frequentes sobre Migração. Observação: as versões 1.0.x do MSOnline poderão sofrer interrupções após 30 de junho de 2024.

Opção de verificação 2: verificar se a ID de segurança alternativa do convidado do locatário do recurso difere da ID de rede do usuário do locatário inicial

Observação

O módulo MSOnline do PowerShell está definido para ser preterido. Como ele também é incompatível com o PowerShell Core, verifique se você está usando uma versão compatível do PowerShell para poder executar os comandos a seguir.

Quando um usuário convidado aceita um convite, o atributo do LiveID usuário (a ID de entrada exclusiva do usuário) é armazenado no AlternativeSecurityIds key atributo. Como a conta de usuário foi excluída e criada no locatário inicial, o NetID valor da conta terá sido alterado para o usuário no locatário inicial. Compare o NetID valor da conta de usuário no locatário inicial com o valor da chave armazenado na AlternativeSecurityIds conta de convidado no locatário do recurso, da seguinte maneira:

  1. No locatário inicial, recupere o valor do LiveID atributo usando o cmdlet do Get-MsolUser PowerShell:

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

  2. No locatário do recurso, converta o key valor do atributo em AlternativeSecurityIds uma cadeia de caracteres codificada em base64:

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

  3. Converta a cadeia de caracteres codificada em base64 em um valor hexadecimal usando um conversor online (como base64.guru).

  4. Compare os valores da etapa 1 e da etapa 3 para verificar se eles são diferentes. A NetID conta de usuário no locatário inicial foi alterada quando a conta foi excluída e recriada.

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

Redefina o status de resgate da conta de usuário convidado no locatário do 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.