Como corrigir o erro AADSTS50034: usuário não existe no Microsoft Azure AD

By Mirko Peters · 2026-04-21

O erro AADSTS50034 no Microsoft Azure AD significa, simplesmente, “usuário não existe”. Quando alguém tenta entrar no Microsoft 365, no Azure ou em serviços de nuvem relacionados e recebe esse código, o Azure Active Directory não consegue encontrar uma conta que corresponda ao nome de usuário informado. Essa mensagem aparece com frequência, especialmente depois que um usuário deixa a empresa, é ex

Automatically translated with AI from the original post. Read the English original

Cover: Fix Azure Governance Before Your Next Cloud Audit

Corrigir esse erro não se resume a eliminar uma mensagem incômoda. Ele é essencial para um acesso contínuo à nuvem, para a produtividade dos usuários e para uma segurança sólida. O AADSTS50034 pode impedir que usuários legítimos façam o trabalho deles e sinaliza problemas mais profundos no ciclo de vida das contas, na configuração do diretório ou no acesso ao locatário. Este guia detalha exatamente por que esse erro aparece, como ele se relaciona com problemas semelhantes e quais etapas seguir para corrigi-lo ou, melhor ainda, para evitar futuros problemas com os códigos AADSTS em ambientes Microsoft.

Entendendo o AADSTS50034 e outros erros de autenticação do Azure AD

O AADSTS50034 está no centro do processo de busca de usuários do Azure Active Directory. Quando aparece a mensagem “usuário não existe”, o que realmente acontece é que o Azure AD tentou localizar o nome de usuário ou as credenciais no diretório e não encontrou nada. Isso pode significar que o usuário nunca existiu, foi excluído ou nunca foi sincronizado ou provisionado.

Mas a autenticação na nuvem da Microsoft raramente é simples, e vários códigos de erro podem se acumular, gerando mais confusão do que clareza. Além do AADSTS50034, os administradores costumam encontrar outros erros de login, como AADSTS50020 e AADSTS50126. Todos giram em torno da existência e da identidade do usuário, mas cada um tem um significado próprio e sutil. Por isso, a solução de problemas vira um quebra-cabeça, em que cada erro aponta para uma causa diferente, seja uma incompatibilidade de locatário, problemas de senha ou objetos de usuário ausentes.

Entender esses códigos é essencial para quem dá suporte ao Microsoft 365 ou ao Azure. A linha que separa um usuário ausente, uma senha inválida e um locatário errado é tênue, e conhecer as diferenças ajuda a resolver os problemas mais rapidamente e com mais segurança. Antes de partir para as correções técnicas, é importante ter a visão geral: como o Azure AD verifica identidades, interpreta os erros e relaciona esses códigos no contexto de um acesso seguro e confiável. Vamos detalhar o que causa o AADSTS50034 e como ele se compara a outros erros comuns de login de usuário.

O que causa o erro AADSTS50034 e como corrigir o código AADSTS50034 no Microsoft Azure

O erro AADSTS50034 aparece quando o Azure AD não consegue encontrar um objeto de usuário correspondente durante o login. É tão direto quanto parece: se o usuário não existe no diretório, o acesso é negado. Os motivos, porém, podem variar de algo simples, como um erro de digitação em um endereço de e-mail, a problemas mais ocultos, como exclusões, falhas de sincronização ou incompatibilidades de locatário.

As causas mais comuns incluem nomes de usuário digitados incorretamente, usuários excluídos recentemente que ainda tentam entrar ou contas que nunca foram sincronizadas do Active Directory local. Outro vilão é o usuário tentar acessar o locatário errado, seja porque tem acesso a várias organizações, seja porque o convite de convidado não terminou o provisionamento. Mais confuso ainda: se houver atraso na criação de usuários B2B ou uma divergência entre e-mail e UPN durante a federação, o AADSTS50034 vai aparecer.

Para corrigir esse erro, comece verificando se o nome de usuário foi digitado corretamente. No portal do Azure, confirme se o usuário existe em Usuários no locatário pretendido. Se o usuário foi excluído, talvez seja necessário restaurá-lo ou, no caso de acesso de convidado, enviar um novo convite. Em ambientes híbridos, verifique se a conta local está ativa e sincronizando com o Azure AD. Por fim, confirme sempre que o login está sendo feito no locatário correto e que o tipo de usuário ("Membro" ou "Convidado") corresponde à função da conta. Resolver essas causas de base elimina o AADSTS50034 e melhora a confiabilidade da identidade no seu ambiente.

Comparando erros de usuário do Azure AD: AADSTS50020 x AADSTS50126

Os erros AADSTS50020 e AADSTS50126 costumam ser confundidos com o AADSTS50034, mas indicam problemas de entrada um pouco diferentes. O AADSTS50020 significa que o usuário existe em algum lugar do Azure AD, mas não no locatário que ele está tentando acessar. Isso acontece com frequência quando alguém entra com as credenciais certas na organização ou no locatário errado.

Por outro lado, o AADSTS50126 aponta para credenciais incorretas, como um nome de usuário válido com a senha errada. Enquanto o AADSTS50034 pergunta "Quem é você?", esses outros códigos dizem "Não está aqui!" (50020) ou "Essa não é a sua senha!" (50126). Diagnosticar essas nuances rapidamente ajuda os administradores a identificar se o problema está nos dados de login, no locatário ou na própria configuração do diretório.

Solução de problemas de locatário e diretório para corrigir problemas de acesso ao Azure AD

Muitos problemas de acesso ao Azure AD se resumem à seleção de locatário, à configuração do diretório ou à aplicação de políticas. Ambientes corporativos, especialmente aqueles com vários locatários do Azure ou configurações de colaboração entre empresas (B2B), fazem com que os usuários caiam em erros simplesmente por estarem no lugar errado na hora errada. Não é raro que um usuário entre sem querer em outro locatário, ou que uma política bloqueie um login que, de outra forma, seria válido.

A estrutura de locatário e diretório do Azure AD funciona como um limite de segurança. O acesso dos usuários, o registro de aplicativos e as permissões de recursos estão todos vinculados ao contexto do locatário atual. Se um usuário ou convidado tentar entrar a partir do contexto errado, o sistema não está sendo apenas preciosista: ele realmente não tem como encontrar nem autorizar esse usuário, o que leva a erros como AADSTS50034, AADSTS50105 ou AADSTS53003.

Solucionar problemas nesses casos significa prestar muita atenção em como os usuários são direcionados entre locatários, se são membros ou convidados e se há alguma inconsistência no diretório. Em organizações com acesso condicional complexo ou locatários muito restritos, as políticas de administração também podem atrapalhar, negando acesso mesmo quando tudo parece estar configurado corretamente. Para saber mais sobre como governança e políticas podem determinar o acesso, confira este conteúdo sobre governança corporativa no Azure. Entender os limites de diretório e de locatário é essencial antes de se aprofundar em erros do tipo "por que este usuário não é encontrado?", que não param de se acumular.

Como corrigir: confirme o acesso ao locatário correto no Azure AD

Verifique o contexto do locatário: sempre confirme o locatário exibido no portal do Azure ou do Microsoft 365. O nome de exibição no canto superior direito indica a organização ativa.
Alterne entre diretórios: se você pertencer a mais de um locatário, use o seletor de diretórios do portal para trocar de organização antes de tentar entrar novamente.
Valide o status de membro ou convidado: confirme se você está listado como membro ou convidado na organização que está acessando. Funções incorretas costumam bloquear o acesso.
Revise os convites: para usuários convidados, certifique-se de que o convite foi aceito e de que a conta de convidado foi provisionada no diretório correto do Azure AD.

Resolvendo o erro AADSTS50105 e o AADSTS53003: acesso ao diretório bloqueado ou negado

Política ou acesso bloqueado (AADSTS50105): os administradores podem ter definido políticas de acesso, grupos ou restrições que impedem determinados usuários de acessar recursos. Confirme as atribuições de grupo e a elegibilidade de funções no centro de administração.
Acesso condicional ou restrições para usuários externos (AADSTS53003): o login pode ser bloqueado se houver políticas de conformidade do dispositivo, localização ou risco aplicadas. Revise todas as políticas de acesso condicional no Microsoft Entra ID e garanta que os requisitos de inscrição e segurança do dispositivo sejam atendidos.
Expiração de convidado ou revisão de acesso: convidados ou usuários externos podem perder o acesso após revisões de acesso ou expiração automática. Realize auditorias regulares das contas de convidado e revisões do ciclo de vida para gerenciar e minimizar negações inesperadas.
Intervenção do administrador: se você suspeitar de um bloqueio mais amplo, entre em contato com o administrador para remover as restrições ou reprovisionar o acesso, seguindo as boas práticas descritas no guia de governança do ciclo de vida de convidados.

Sincronizando o AD local e verificando os tipos de conta para evitar o AADSTS50034

Organizações que usam identidade híbrida muitas vezes caem em armadilhas do AADSTS50034 por causa de problemas de sincronização e de classificação de contas. Quando o seu Active Directory local está vinculado ao Azure AD, qualquer falha na sincronização de contas de usuário pode deixar pessoas bloqueadas, mesmo que a conta pareça existir localmente.

Uma causa importante é a falta de sincronização adequada dos usuários entre o AD local e o Azure AD. Talvez o processo de sincronização tenha falhado, o objeto do usuário tenha sido desativado ou as alterações ainda não tenham sido replicadas para a nuvem. Esses problemas costumam não aparecer até que o usuário tente entrar e veja a mensagem "user does not exist" (o usuário não existe).

A situação fica mais complicada quando os usuários são classificados de forma errada, como "Convidado" quando deveriam ser "Membro", ou o contrário. O Microsoft Entra ID (antigo Azure AD) verifica esse status durante a autenticação. Se um convidado externo estiver mal configurado ou se um usuário membro sincronizado for marcado como convidado, o Azure AD não saberá onde procurar, e você vai encontrar o AADSTS50034. Esses detalhes são essenciais para administradores que gerenciam ambientes híbridos, multinuvem ou com muitos convidados. A seguir, vamos ver formas práticas de garantir a sincronização correta e os tipos de conta adequados no diretório em nuvem da Microsoft.

Corrigir a sincronização do AD local com o Azure AD para evitar problemas de sincronização de diretório

Verificar o status da sincronização: no painel do Azure AD Connect, revise a hora da última sincronização e quaisquer relatórios de erro. Se houver falhas, resolva-as antes de continuar.
Verificar o usuário na nuvem: use o portal do Azure AD para confirmar que o usuário está presente e que corresponde aos detalhes do diretório local.
Resolver erros de sincronização: trate problemas comuns, como proxies duplicados, conflitos em objetos de usuário ou atributos mal configurados que bloqueiam a sincronização do diretório.
Forçar uma sincronização manual: se um usuário acabou de ser criado ou modificado, execute uma sincronização manual para forçar a atualização entre os diretórios local e na nuvem.

Verificar o tipo de conta e corrigir o AADSTS50034 para membros e convidados da Microsoft

Revisar o tipo de usuário: no Microsoft Entra ID, verifique se o usuário está marcado como "Membro" ou "Convidado". Um tipo incorreto bloqueia o login nos recursos do locatário.
Corrigir classificações incorretas: converta convidados registrados incorretamente em membros (ou o contrário) usando as ferramentas de gerenciamento de usuários do Azure AD.
Validar UPNs e e-mails: garanta que o User Principal Name corresponda à conta pretendida e que não existam aliases de e-mail divergentes causando conflitos.
Auditar identidades externas: para usuários B2B e híbridos, confirme que os convites e as relações organizacionais estão corretamente configurados e ativos.

Quando a autenticação de serviços e aplicativos gera erros AADSTS no Microsoft 365

Os erros AADSTS não ocorrem apenas em logins de usuários comuns. Eles também aparecem quando aplicativos e serviços se conectam ao Microsoft 365. Às vezes, o problema está no próprio serviço: registros de aplicativo apresentam falhas, segredos de cliente expiram ou o registro foi excluído. O Exchange Online, o SharePoint e centenas de integrações de terceiros dependem de uma configuração correta no Azure AD, então até uma pequena mudança pode bloquear tudo.

O registro do aplicativo precisa corresponder às configurações de autenticação do cliente, e qualquer desvio, como um segredo ausente ou revogado, um ID de aplicativo incorreto, um aplicativo desativado ou um URI de redirecionamento divergente, pode gerar erros como AADSTS700016 ("application not found", ou seja, aplicativo não encontrado) ou AADSTS7000218 ("invalid client secret", ou seja, segredo de cliente inválido). Esses problemas afetam administradores de TI, especialmente durante migrações de locatário, automações em PowerShell ou quando novos aplicativos são criados rapidamente.

Além disso, políticas de acesso condicional rigorosas e restrições de locatário muito estritas podem bloquear aplicativos mesmo quando os detalhes de autenticação parecem corretos. Saber interpretar esses erros e rastrear o problema, seja uma configuração do aplicativo, uma concessão de consentimento ou uma brecha no OAuth, é fundamental para evitar interrupções nos negócios. Se você está preocupado com consentimento OAuth ou lacunas de segurança em aplicativos, veja como prevenir ataques de consentimento no Entra ID OAuth consent.

Corrigir os erros AADSTS700016 e AADSTS7000218: aplicativo não encontrado ou cliente inválido

Verificar o registro do aplicativo: garanta que o aplicativo esteja registrado no locatário do Azure AD. Compare os IDs de cliente/aplicativo nas solicitações de autenticação com os valores registrados.
Revisar o segredo ou certificado do cliente: para clientes confidenciais, verifique se o segredo ou certificado é válido, está ativo e corresponde às configurações do registro do aplicativo.
Validar os URIs de redirecionamento: a resposta deve usar um URI de redirecionamento listado no registro do aplicativo. Qualquer divergência causa falha no login.
Confirme o locatário e as permissões: os aplicativos precisam estar habilitados no locatário correto, com permissões delegadas ou somente de aplicativo compatíveis com o caso de uso.

Resolvendo AADSTS90002 e AADSTS900144 nos serviços do Microsoft 365

Locatário não encontrado (AADSTS90002): Geralmente, isso significa que o locatário de destino não existe ou foi excluído. Verifique novamente o nome do domínio no seu login ou na cadeia de conexão do aplicativo e confirme se o locatário está ativo.
Violação de política ou de diretório (AADSTS900144): O acesso condicional ou as políticas em todo o locatário podem estar aplicando controles mais rígidos. Revise e ajuste as políticas, priorizando uma cobertura abrangente e reduzindo ao máximo as exceções pontuais para garantir confiabilidade. Saiba mais sobre a estrutura ideal de políticas neste guia de melhores práticas de acesso condicional.
Problemas de acesso delegado: Consentimentos OAuth expirados ou permissões ausentes nos registros de aplicativo podem interromper o fluxo de entrada. Por isso, revise regularmente as concessões de consentimento e suas datas de expiração.
Exclusão de serviço ou de usuário: Certifique-se de que a entidade de serviço e o usuário necessários existem no locatário correto. Se tiverem sido excluídos recentemente, restaure-os ou registre-os novamente, conforme necessário.

Requisitos de autenticação multifator e políticas de acesso condicional

Mesmo quando os usuários têm a conta e as credenciais corretas, o Azure AD pode continuar bloqueando o acesso se as políticas de segurança não forem atendidas. A autenticação multifator (MFA) e os requisitos de conformidade do dispositivo têm um papel importante nisso. As organizações usam esses recursos para reduzir riscos, exigindo verificação extra ou verificações da postura do dispositivo antes de concluir uma entrada.

Erros como AADSTS50076 e AADSTS50079 aparecem quando o usuário ignora a MFA ou tenta entrar a partir de um dispositivo não gerenciado ou não conforme. Esses erros podem surpreender os usuários, especialmente se as políticas tiverem sido alteradas recentemente ou se eles estiverem usando um dispositivo novo pela primeira vez. Muitas vezes, não fica claro de antemão que uma nova condição está sendo aplicada, até que o Azure AD recuse a conexão de imediato.

Para os administradores, configurar e manter um acesso condicional eficaz é um ciclo contínuo, não uma tarefa de configurar e esquecer. O desvio acontece: usuários encontram atalhos, políticas são ajustadas e dispositivos são substituídos. Se você precisa de uma análise aprofundada sobre segurança de identidade escalável e aplicável, este podcast sobre governança de acesso condicional explica como manter os controles fortes com o mínimo de atrito. A seguir, estão as etapas práticas de solução de problemas para resolver bloqueios de entrada comuns, causados pela MFA e pela conformidade do dispositivo.

Corrigindo AADSTS50076 e AADSTS50079: MFA e conformidade do dispositivo exigidas

Configure a MFA: se for solicitado, certifique-se de que a MFA esteja habilitada e configurada. Use o aplicativo móvel, uma chamada telefônica ou SMS, de acordo com a configuração da sua organização.
Registre os dispositivos: para a conformidade do dispositivo, certifique-se de que ele esteja inscrito na solução de gerenciamento de dispositivos da sua organização, como o Intune ou o Endpoint Manager.
Revise as políticas: verifique a atribuição e o escopo das políticas de acesso condicional. Ajuste-as caso usuários legítimos estejam sendo bloqueados por regras excessivamente restritivas.
Fale com o administrador: se a configuração estiver correta, mas os erros persistirem, peça ao administrador que verifique a conformidade do dispositivo ou da sessão e revise os logs de políticas em busca de alterações recentes.

Dicas de especialista: evite erros de "usuário não existe" em cenários B2B do Microsoft Entra

Corrigir "usuário não existe" é uma coisa; evitar que isso aconteça é outro desafio, especialmente em cenários B2B do Microsoft Entra e entre locatários. À medida que as organizações colaboram mais entre empresas, aumentam as chances de encontrar o AADSTS50034 devido a atrasos no provisionamento de usuários, contas de convidados fantasmas e propriedades de usuário desalinhadas. O processo de criação de usuários convidados, remoção de contas e sincronização de identidade híbrida nem sempre é instantâneo ou perfeitamente confiável.

Assumir o controle do gerenciamento do ciclo de vida é essencial. Convites atrasados, sincronizações externas com falha e divergências em aliases de e-mail podem disparar o AADSTS50034 para usuários convidados, mesmo quando o processo de integração parece concluído. Contas excluídas por inatividade, conformidade ou limpeza manual feita pelo administrador podem permanecer em estado de exclusão temporária, causando comportamentos estranhos durante a entrada ou em migrações de locatário. Se você quer evitar essas armadilhas, revisões regulares de acesso e regras estruturadas de ciclo de vida, como descrito neste detalhado guia de gerenciamento de convidados, são extremamente valiosas.

Administradores que movem aplicativos ou serviços com autenticação de entidade de serviço enfrentam seus próprios problemas, em que a ausência de contexto de usuário ou permissões mal configuradas fazem surgir o erro AADSTS50034. Na prática, a causa raiz raramente é um usuário ausente. Ser proativo com o provisionamento B2B, a correspondência entre e-mail e UPN e as configurações de migração de aplicativos dá ao seu diretório a estabilidade necessária para projetos entre locatários e fluxos de automação complexos. Vamos ver os detalhes de como monitorar, diagnosticar e prevenir esses cenários persistentes de AADSTS50034.

Provisionamento de usuários convidados, exclusão de contas e incompatibilidades de UPN que levam ao AADSTS50034

Atrasos no provisionamento: depois que um convidado aceita um convite, pode haver um atraso até que a conta apareça completamente no Azure AD. Monitore os logs de entrada e confirme o cronograma de criação antes de continuar a solução de problemas.
Exclusão automática ou manual: convidados e usuários externos podem ser excluídos automaticamente por inatividade ou removidos manualmente pelos administradores. Contas excluídas temporariamente não conseguem se autenticar e disparam o AADSTS50034. Revise com frequência as políticas de ciclo de vida, conforme descrito neste guia de gerenciamento do ciclo de vida.
Incompatibilidade entre e-mail e UPN: usuários que entram com aliases de e-mail ou com User Principal Names divergentes podem não ser encontrados pelo Azure AD. Para resolver, garanta que o UPN e o e-mail principal correspondam ao que está registrado no diretório.
Conflitos de correspondência SMTP: endereços de e-mail duplicados entre locatários geram falhas na resolução de identidade. Use convites explícitos e garanta que os e-mails sejam exclusivos dentro de cada locatário para evitar erros de pesquisa.

Entidade de serviço e autenticação somente de aplicativo: evitando erros AADSTS50034 enganosos em migrações

Contexto de autenticação somente de aplicativo: ferramentas de migração ou scripts de automação que usam entidades de serviço podem receber AADSTS50034 se as permissões do aplicativo estiverem mal configuradas ou se o script fizer referência a um objeto de usuário inexistente, mesmo sem nenhum usuário envolvido na autenticação. Sempre valide as funções e os escopos do aplicativo no portal antes de executar migrações.
Escopos delegados e consentimento expirado: se permissões delegadas forem necessárias, mas o consentimento estiver expirado ou ausente, as ferramentas podem reportar AADSTS50034 de forma incorreta. Conceda novamente ou revise o consentimento, especialmente após migrações de locatário ou ciclos de reaprovação de aplicativos.
Precisão de UPN e ID de objeto: ao criar scripts, use o UPN e o ID de objeto corretos e atualizados, que correspondam ao usuário ou à entidade de serviço ativa no locatário, para evitar falhas de referência.
Diagnosticando erros: não procure apenas um usuário ausente. Verifique os logs da API do Graph ou do PowerShell em busca de erros de permissão e de referência de objeto para descobrir a verdadeira causa das falhas de autenticação.