Entra ID SAML com IdP externo

Esta resposta foi traduzida automaticamente. Como resultado, pode haver erros gramaticais ou expressões estranhas.

Hi @VirginiaBordin,

Bem-vindo ao Microsoft Q&A e obrigado por entrar em contato.

De acordo com sua descrição, você configurou com sucesso a federação SAML entre seu Provedor de Identidade (IdP) externo e o Microsoft Entra ID em um ambiente somente em nuvem (sem Azure AD Connect ou AD local). O domínio foi verificado e federado, e os usuários existem no Entra ID com licenças atribuídas e status habilitado.

No entanto, quando os usuários tentam entrar nos serviços da Microsoft (por exemplo, Outlook, Teams, Office 365), eles são redirecionados para a página de login da Microsoft com o erro:

AADSTS51004: The user account [ObjectId] does not exist in the [tenant] directory.

Você confirmou que:

• A configuração da federação foi concluída e os certificados correspondem.
• O usuário existe no Entra ID e está devidamente licenciado.
• Você testou diversas configurações, incluindo:
  • Diferentes formatos e valores de NameID (ObjectId, e-mail, formato persistente).
  • Diferentes valores de público-alvo (urn:federation:MicrosoftOnline, https://sts.windows.net/{tenant-id}/, https://login.microsoftonline.com/{tenant-id}/).
  • Mapeamento por ImmutableID, definido manualmente via Graph API e usado no token SAML.

Apesar desses esforços, o erro persiste.

Observe que, como moderador do Microsoft Q&A, não tenho acesso à configuração do seu locatário, mas farei o possível para ajudá-lo usando a documentação e as orientações disponíveis.

Em resposta à sua pergunta, com base na minha pesquisa e nas informações que você forneceu, aqui estão algumas possíveis soluções que podem ajudar a resolver o problema:

1. Requisitos para Federação SAML Somente em Nuvem:

• Não há requisitos ausentes em sua configuração, mas há pontos críticos a serem observados:
• O ID do Objeto não é compatível com o mapeamento de usuários na federação SAML.
• Você deve usar:
  • ImmutableID (GUID codificado em Base64 definido manualmente via Graph API ou PowerShell)
  • Nome Principal do Usuário (UPN) (por exemplo, usuário@domínio.com) na declaração NameID

Formatos corretos para cada identificador:

• UPN:

Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"

Observe que o SAML 1.1 é necessário para este formato porque o UPN se assemelha a um endereço de e-mail e é interpretado adequadamente pelo Entra ID. O SAML 2.0 é destinado a identificadores opacos (por exemplo, ImmutableID) ou identificadores específicos de sessão (por exemplo, valores transitórios).

• ImmutableID:

    Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
  

2.Mapeamento de Reivindicações para Ambientes Somente em Nuvem:

Seu mapeamento de reivindicação atual:

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier

é padrão e válido. Não há necessidade de alterar o nome da reivindicação. O que importa é o valor usado na reivindicação:

Use UPN ou ImmutableID.

Evite usar ID de Objeto, que o Entra ID não consegue resolver durante a autenticação SAML.

3.Licenças e Permissões:

Nenhuma licença especial é necessária para a federação SAML externa básica no Entra ID somente na nuvem.

No entanto, para configurar e gerenciar a federação, as seguintes funções normalmente são necessárias:

Administrador Global ou Administrador de Aplicativos

Administrador de Usuários (para gerenciar atributos e licenças de usuários)

Leitores de Diretório (se estiver usando entidades de serviço ou federação M2M)

Recursos avançados, como Acesso Condicional ou Governança de Identidade, podem exigir o Microsoft Entra ID P1 ou P2, mas estes não são necessários para a federação básica.

Para obter mais informações sobre a configuração SAML, consulte este artigo da Microsoft aqui.

Além disso, encontrei um tópico da comunidade onde outro usuário compartilhou uma solução alternativa que o ajudou a resolver um problema semelhante. Sinta-se à vontade para revisar e verificar se elas se aplicam ao seu ambiente, caso tenha achado as sugestões úteis.

Observe que o comando Set-MsolUser está obsoleto e não é mais suportado. Para definir o ImmutableID para um usuário, você precisará usar a API do Microsoft Graph. Por exemplo, você pode usar o comando Update-MgUser do Graph PowerShell SDK para atribuir o valor manualmente.

Observação: o tópico e o artigo referenciados estão disponíveis apenas em inglês. Conforme verifiquei, não há alternativas no seu idioma de preferência no momento. Se necessário, considere usar uma ferramenta de tradução para ajudar a interpretar o conteúdo.

Se tiver alguma dúvida ou precisar de mais esclarecimentos, deixe um comentário abaixo. Terei prazer em ajudar.

Observação: siga as etapas em nossa documentação para habilitar notificações por e-mail se desejar receber notificações por e-mail relacionadas a este tópico.

Hi @VirginiaBordin,

Thank you very much for your response, and I’m glad to hear that the issue has been successfully resolved.

Regarding your question about why changing the User Principal Name (UPN) to the onmicrosoft.com domain and then switching it back to the federated domain appears to resolve the AADSTS51004 error:

While I can't confirm this with absolute certainty, a strong possibility is that this process helps re-establish a clean federation link. The AADSTS51004 error typically occurs when Microsoft Entra ID cannot match the incoming SAML token to an existing user object. If the UPN attribute does not correspond to a verified domain in Microsoft Entra ID, synchronization will replace the suffix with .onmicrosoft.com.

Therefore, by temporarily changing the UPN to the default onmicrosoft.com domain, federation constraints might be bypassed, allowing manual correction of the ImmutableID. Once corrected, reverting the UPN to the federated domain could restore proper federation behavior and resolve the identity mapping issue.

Warm thanks.