Azure-docs: Mensagem: AADSTS50020: A conta de usuário do provedor de identidade 'live.com' não existe no locatário 'Microsoft Services' e não pode acessar o aplicativo '2793995e-0a7d-40d7-bd35-6968ba142197' (Meus Aplicativos) nesse locatário.

@ansred , vincule o documento que você está seguindo para que possamos ajudá-lo melhor.

Estou tendo o mesmo problema. Isso ocorre apenas com usuários convidados. Quando o usuário convidado tenta acessar o portal myapps, você vê a IU antiga aparecer por um segundo e, em seguida, o usuário convidado recebe a tela "Escolha uma conta" novamente. Ao escolher a conta, eles recebem: "A conta de usuário selecionada não existe no locatário 'Microsoft Services' e não pode acessar o aplicativo '2793995e-0a7d-40d7-bd35-6968ba142197' naquele locatário. A conta precisa ser adicionada como um usuário externo no locatário primeiro. Use uma conta diferente. "

Se eles escolherem "Usuário de outra conta", o erro "AADSTS50020: Conta de usuário ''do provedor de identidade' live.com 'não existe no locatário' Microsoft Services 'e não pode acessar o aplicativo' 2793995e-0a7d-40d7-bd35-6968ba142197 '(Meus aplicativos) nesse locatário. A conta precisa ser adicionada como um usuário externo no locatário primeiro "aparece".

Oi @jacksiergiej

Isso soa exatamente como estou enfrentando. Você descobriu as etapas / KB a serem usadas para que esse usuário seja adicionado como externo no locatário?

@MarileeTurscak-MSFT Estou procurando uma KB ainda para corrigir esse problema, conforme solicitado acima, compartilhe uma.

Obrigado

@ansred Ainda não descobri a solução, mas estou com o tíquete aberto com o suporte. Para mim, parece um problema de back-end da Microsoft que está fora de nosso controle. Posso acessar a IU clássica sem problemas, bem como meus aplicativos proxy de aplicativo tanto da IU quanto da URL externa direta.

Isso me diz que meu usuário convidado está bem. Assim que clico no botão "experimentar", sou solicitado a escolher meu usuário novamente e recebo o erro.

O que é realmente ruim é que todos os usuários convidados parecem ser levados automaticamente para a nova IU de experiência durante o processo de convite. Isso obviamente causa o erro e os interrompe.

@jacksiergiej Concordo totalmente com você e este é um grande problema.

@ MarileeTurscak-MSFT Por favor, avise

@ansred Acabei de receber uma mensagem de um contato da MS que esse é um bug e agora deve ser resolvido. No entanto, surgiu um novo problema em que você recebe um MFA cada vez que acessa a nova experiência. Por exemplo, apenas se logando no portal, você será MFA duas vezes (uma para o clássico e depois quando mudar para a nova experiência, você será expulso no MFA novamente.) Se você sair da nova experiência e volte para a IU clássica e, em seguida, clique em "Experimentar" para retornar à nova experiência. Você será liberado novamente e terá uma MFA. Isso não devia estar acontecendo.

"Tivemos um bug introduzido no final da semana passada que fez com que algumas contas de convidado / B2B não funcionassem corretamente no novo My Apps. Corrigimos esse bug na segunda-feira (15/6), então os usuários com contas de convidado agora devem ser capazes de clicar" Experimente! "E acesse a nova experiência My Apps corretamente."

@ansred Recebi uma resposta da equipe de produto MyApps e o problema do prompt duplo do MFA agora é o bug # 2. De acordo com a equipe, "Eles fizeram uma solicitação de correção de bug para isso e esperam ter o problema do prompt duplo resolvido até o final da próxima semana."

@jacksiergiej isso faz sentido agora, dois bugs em um acerto.
Isso está correto, o usuário está configurado com MFA.
Você pode compartilhar o jira / bug #s para referência, por favor.

Obrigado

Olá @jacksiergiej , você pode compartilhar o bug? Tenho tentado encontrar o time certo para isso.

Eu relatei isso aos meus contatos também! Farei o acompanhamento quando eu tiver uma resposta.

@MarileeTurscak-MSFT Parece um plano. Obrigado por sua ajuda também.

Por enquanto, estou usando apenas a experiência clássica - https://account.activedirectory.windowsazure.com/

e não o novo / moderno https://myapplications.microsoft.com/

Para evitar reclamações dos usuários.

Ansioso por ouvir de você em breve.

@ansred como você impede que a IU clássica mude automaticamente para a nova experiência? Tentei usar https://account.activedirectory.windowsazure.com/ , mas assim que faço o login, o portal muda automaticamente para a nova experiência e o URL muda para https://myapplications.microsoft.com/.

@ansred como você impede que a IU clássica mude automaticamente para a nova experiência? Tentei usar https://account.activedirectory.windowsazure.com/ , mas assim que faço o login, o portal muda automaticamente para a nova experiência e o URL muda para https://myapplications.microsoft.com/.

Ele simplesmente funciona indo diretamente para qualquer um dos links mencionados. Não tenho certeza se existe uma opção que talvez esteja forçando os usuários a usar a IU moderna.

Eu relatei isso aos meus contatos também! Farei o acompanhamento quando eu tiver uma resposta.

Alguma atualização do seu lado? Posso confirmar que o problema ainda persiste.

Como solução alternativa por enquanto, estou usando apenas a experiência clássica - https://account.activedirectory.windowsazure.com

e não o novo / moderno https://myapplications.microsoft.com

cc @ MarileeTurscak-MSFT

Como os usuários do MSA não têm um locatário residencial, eles precisarão usar a versão locada do url para fazer login no locatário convidado correto. O url alugado é https://myapplications.microsoft.com/?tenant=