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 recursos 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 revisa os logs de entrada no locatário da casa, 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 {tenant} e não pode acessar o aplicativo {appId}({appName}) nesse locatário. A conta precisa ser adicionada como um usuário externo no locatário primeiro. Saia e entre novamente com uma conta de usuário Microsoft Entra diferente.

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

Quando você tenta 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 dos Serviços microsoft por padrão. Dentro do locatário padrão, não há nenhum diretório vinculado para executar ações. Esse comportamento é esperado.

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

Solução: Create 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 Administrador Global. Isso concede 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 for 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 audiência 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, crie novamente o registro do aplicativo tendo o tipo de conta correto selecionado. Atualmente, você não pode alterar signInAudience no manifesto.

Para obter mais informações sobre como registrar aplicativos, consulte Início Rápido: Registre um aplicativo com o plataforma de identidade da Microsoft.

Causa 3: usado o ponto de extremidade errado (contas pessoais e de organização)

Sua chamada de autenticação deve direcionar uma URL que corresponda à sua seleção se o tipo de conta compatível do seu registro de aplicativo foi definido como um dos seguintes valores:

  • Contas em qualquer diretório organizacional (Qualquer diretório Microsoft Entra – Multilocatário)

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

  • 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 causa 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: usar a URL de entrada 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 configuração Authority . Para obter mais informações sobre Authority, consulte plataforma de identidade da Microsoft opções de configuração do aplicativo.

Causa 4: entrou no locatário errado

Quando os usuários tentam acessar seu aplicativo, eles são enviados um link direto para o aplicativo ou tentam obter acesso por meio https://myapps.microsoft.comde . 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 da que pretende ser usada. Ou eles têm uma sessão que usa sua conta de organização, embora pretendam usar uma conta de convidado pessoal (ou vice-versa).

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

Solução: sair e entrar novamente de um navegador diferente ou de uma sessão de navegador privado

Instrua o usuário a abrir uma nova sessão de navegador privado 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

Verifique se você segue as etapas no Início Rápido: adicione usuários convidados ao diretório no portal do Azure para convidar o usuário convidado.

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

Se o aplicativo for um aplicativo empresarial que requer atribuição do usuário, ocorrerá um erro AADSTS50020 se o usuário não estiver na lista de usuários permitidos que têm acesso atribuído ao aplicativo. Para marcar se seu aplicativo empresarial requer atribuição de usuário:

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

  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: tentou usar um fluxo de credenciais de senha do proprietário do recurso para contas pessoais

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

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

Use um ponto de extremidade específico do locatário (https://login.microsoftonline.com/<TenantIDOrName>) ou o ponto de extremidade da organização. Contas pessoais que são convidadas para um locatário Microsoft Entra não podem usar ROPC. Para obter mais informações, consulte plataforma de identidade da Microsoft e credenciais de senha do proprietário do recurso OAuth 2.0.

Causa 8: Um nome de usuário excluído anteriormente foi recriado pelo administrador do locatário da casa

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 da casa. 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 da casa, use uma das seguintes opções:

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

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

Microsoft Graph

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

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

Em seguida, marcar 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 da casa. O cenário será confirmado se o usuário convidado foi criado antes da criação da conta de usuário do locatário doméstico.

MSOnline PowerShell

Observação

O módulo do MSOnline 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 que você possa executar os comandos a seguir.

Execute o cmdlet Get-MsolUser 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, marcar 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 da casa. O cenário será confirmado se o usuário convidado foi criado antes da criação da conta de usuário do locatário doméstico.

Observação

Os módulos Azure AD e MSOnline PowerShell foram preteridos a partir de 30 de março de 2024. Para saber mais, leia a atualização sobre substituição. Após essa data, o suporte para esses módulos é limitado à assistência de migração para o SDK do Microsoft Graph PowerShell e 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 (anteriormente Azure AD). Para obter respostas para perguntas de migração comuns, consulte as perguntas frequentes sobre migração. Observação: as versões 1.0.x do MSOnline podem sofrer interrupções após 30 de junho de 2024.

Opção de verificação 2: verifique se a ID de segurança alternativa do locatário de recurso é diferente da ID líquida do locatário da casa

Observação

O módulo do MSOnline 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 que você possa 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 AlternativeSecurityIdskey atributo. Como a conta de usuário foi excluída e criada no locatário da casa, o NetID valor da conta terá sido alterado para o usuário no locatário da casa. Compare o NetID valor da conta de usuário no locatário da casa com o valor de chave armazenado dentro AlternativeSecurityIds da conta de convidado no locatário do recurso da seguinte maneira:

  1. No locatário da casa, 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 valor do key atributo dentro AlternativeSecurityIds de uma cadeia de caracteres codificada com base64:

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

  3. Converta a cadeia de caracteres codificada 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. O NetID da conta de usuário no locatário da casa foi alterado quando a conta foi excluída e recriada.

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

Redefinir 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, Azure PowerShell ou o microsoft API do Graph. Para obter instruções, consulte Redefinir 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.