Laboratório de Troubleshooting: Create users and groups
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Um administrador de TI relata que tentou criar um novo usuário membro no Microsoft Entra ID pelo portal do Azure. O processo foi concluído sem mensagem de erro e o usuário aparece na lista de usuários do diretório. No entanto, ao tentar fazer login com as credenciais criadas, o usuário recebe a seguinte mensagem:
AADSTS50126: Invalid username or password, or Invalid on-premise username or password.
O administrador confirma que:
- A senha foi definida como
Temp@2024!durante a criação - A opção "O usuário deve alterar a senha no próximo login" estava marcada
- O tenant utiliza um domínio verificado customizado
contoso.com - O UPN do usuário criado foi
joao.silva@contoso.com - O tenant possui Microsoft Entra Connect configurado, sincronizando usuários de um AD local
- O departamento do usuário foi preenchido como
TIno perfil
O administrador verifica que não existe nenhum usuário com o mesmo UPN no AD local.
Qual é a causa raiz da falha de autenticação?
A. A senha Temp@2024! não atende à política de complexidade mínima do Microsoft Entra ID.
B. O usuário foi criado como membro na nuvem, mas o Microsoft Entra Connect sobrescreveu ou bloqueou o objeto por conflito de identidade com o escopo de sincronização.
C. O domínio contoso.com não está verificado no tenant, impedindo a autenticação com esse sufixo de UPN.
D. A opção "alterar senha no próximo login" está em conflito com o fluxo de autenticação do Microsoft Entra Connect, que bloqueia logins com senha temporária.
Cenário 2 — Decisão de Ação
A equipe de identidade identificou que um grupo de segurança chamado GRP-Auditoria foi configurado incorretamente com tipo de associação Atribuída quando deveria ser Dinâmica, pois a regra baseada no atributo jobTitle -eq "Auditor" precisa ser aplicada automaticamente. O grupo já possui 15 membros adicionados manualmente e está associado a 3 políticas de Microsoft Entra Conditional Access ativas em produção.
A causa está confirmada. A equipe precisa agir agora, durante o horário comercial, sem janela de manutenção aprovada.
Qual é a ação correta a tomar neste momento?
A. Alterar o tipo de associação do grupo existente de Atribuída para Dinâmica diretamente pelo portal do Azure, mantendo os membros atuais.
B. Criar um novo grupo com tipo de associação Dinâmica e a regra correta, atualizar as 3 políticas de Conditional Access para referenciar o novo grupo, e remover o grupo antigo somente após validação.
C. Criar um novo grupo com tipo de associação Dinâmica, aguardar a propagação automática dos membros, e excluir imediatamente o grupo antigo para evitar duplicidade.
D. Adicionar a regra dinâmica como metadado ao grupo existente via Microsoft Graph API, sem necessidade de recriar o grupo.
Cenário 3 — Causa Raiz
Um administrador configurou um grupo dinâmico no Microsoft Entra ID com a seguinte regra de associação:
(user.department -eq "Vendas") and (user.accountEnabled -eq true)
O grupo foi criado há 48 horas. Ao verificar os membros, o administrador observa que apenas 12 dos 40 usuários esperados do departamento de Vendas estão no grupo. O administrador verifica os seguintes fatos:
- Todos os 40 usuários têm o campo
departmentpreenchido comoVendasno portal do Microsoft Entra ID - Todos os 40 usuários estão com
accountEnabled = trueno portal - O tenant possui licença Microsoft Entra ID P1 atribuída apenas para os 12 usuários que aparecem no grupo
- Os outros 28 usuários possuem apenas licença Microsoft 365 Business Basic
- A regra foi validada com sucesso pela ferramenta de validação do portal antes de ser salva
- O grupo foi criado por um Administrador Global
Qual é a causa raiz do problema?
A. A regra de associação contém um erro de sintaxe que afeta apenas usuários sem licença Entra ID P1, processando-os de forma parcial.
B. Grupos dinâmicos exigem que cada membro potencial possua uma licença Microsoft Entra ID P1 ou superior; usuários sem essa licença não são avaliados pela regra.
C. O período de 48 horas ainda não foi suficiente para o processamento completo; grupos dinâmicos com mais de 30 membros esperados podem levar até 72 horas na primeira avaliação.
D. O atributo accountEnabled não é suportado como critério de filtragem em regras de associação dinâmica e está sendo ignorado silenciosamente, causando avaliação incorreta.
Cenário 4 — Sequência de Diagnóstico
Um administrador recebe o seguinte relato: um usuário membro do grupo dinâmico GRP-RH-Dinamico perdeu acesso a um aplicativo integrado ao Microsoft Entra ID. O acesso era concedido exclusivamente pela associação a esse grupo.
Os passos de investigação disponíveis são:
- Verificar se a licença Microsoft Entra ID P1 ainda está atribuída ao tenant
- Confirmar se o usuário ainda aparece como membro do grupo
GRP-RH-Dinamicono portal - Verificar o valor atual do atributo usado na regra dinâmica no perfil do usuário
- Revisar o histórico de alterações do perfil do usuário nos logs de auditoria do Microsoft Entra ID
- Confirmar se o aplicativo ainda tem o grupo
GRP-RH-Dinamicocomo atribuição de acesso ativa
Qual é a sequência correta de investigação?
A. 1 → 2 → 3 → 5 → 4
B. 2 → 3 → 4 → 5 → 1
C. 5 → 2 → 3 → 4 → 1
D. 2 → 5 → 3 → 4 → 1
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista central do enunciado é a combinação de dois fatos: o tenant possui o Microsoft Entra Connect ativo sincronizando objetos do AD local, e o usuário foi criado diretamente na nuvem com um UPN que pertence ao domínio sincronizado contoso.com. Quando o Entra Connect está configurado para sincronizar um domínio, objetos criados diretamente na nuvem com UPNs desse domínio podem entrar em conflito com o escopo de sincronização. O Entra Connect pode tratar esse objeto como um conflito de identidade, converter o usuário para um estado inconsistente ou bloquear a autenticação por não reconhecer a credencial como gerenciada localmente.
A informação sobre o departamento TI é irrelevante e foi incluída propositalmente para simular o ruído de dados presente em cenários reais.
A alternativa A é incorreta: Temp@2024! atende aos critérios padrão de complexidade do Entra ID (maiúscula, minúscula, número, símbolo, 8+ caracteres).
A alternativa C é o distrator mais perigoso: se o domínio não estivesse verificado, o usuário sequer teria sido criado com esse UPN sem erro. A criação bem-sucedida confirma que o domínio está verificado.
Agir com base na alternativa C levaria o administrador a desperdiçar tempo redefinindo senhas ou recriando o usuário sem resolver o conflito real com o Entra Connect.
Gabarito — Cenário 2
Resposta: B
O contexto impõe duas restrições críticas: o grupo está vinculado a políticas de Conditional Access ativas em produção e não há janela de manutenção. A alternativa B é a única que respeita ambas as restrições, pois mantém o grupo original funcional enquanto o novo grupo é preparado e validado, só desfazendo a referência nas políticas após confirmação.
A alternativa A representa um equívoco conceitual grave: o Microsoft Entra ID não permite alterar o tipo de associação de um grupo existente. Essa operação simplesmente não está disponível, independentemente do método utilizado.
A alternativa C é tecnicamente possível como sequência, mas excluir o grupo antigo imediatamente antes de validar o novo grupo em produção representa um risco real de interrupção de acesso para os usuários cobertos pelas políticas de Conditional Access.
A alternativa D é falsa: a Microsoft Graph API também não expõe um endpoint que permita converter o tipo de associação de um grupo existente. A restrição é da plataforma, não da interface.
Gabarito — Cenário 3
Resposta: B
A causa raiz está na distribuição de licenças descrita no enunciado: exatamente os 12 usuários com licença Microsoft Entra ID P1 estão no grupo, e os 28 restantes não possuem essa licença. Grupos dinâmicos no Microsoft Entra ID são um recurso que exige licença P1 ou superior por usuário avaliado. Usuários sem essa licença não são elegíveis para associação dinâmica, independentemente de seus atributos de perfil.
A informação de que a regra foi validada com sucesso pela ferramenta do portal é irrelevante para este diagnóstico e foi incluída propositalmente. A validação sintática da regra não verifica a cobertura de licença dos usuários candidatos.
A alternativa C é o distrator mais plausível superficialmente, mas o enunciado informa que já se passaram 48 horas e o grupo está estável com 12 membros, sem crescimento. Um problema de latência se manifestaria como crescimento gradual, não como um plateau fixo que coincide exatamente com a quantidade de usuários licenciados.
A alternativa D está errada: accountEnabled é um atributo suportado e documentado em regras de associação dinâmica no Entra ID.
Gabarito — Cenário 4
Resposta: D
A sequência correta é: 2 → 5 → 3 → 4 → 1.
O raciocínio diagnóstico deve seguir a lógica do sintoma para a causa, do mais específico para o mais amplo:
- Passo 2: confirmar se o usuário ainda é membro do grupo é o primeiro verificável e o mais direto para o sintoma relatado.
- Passo 5: confirmar se o grupo ainda está atribuído ao aplicativo elimina a hipótese de que o problema está na configuração do aplicativo, não no usuário.
- Passo 3: verificar o valor atual do atributo no perfil do usuário responde por que ele saiu do grupo, se for o caso.
- Passo 4: os logs de auditoria confirmam quando e por quem o atributo foi alterado, fechando o diagnóstico.
- Passo 1: verificar a licença P1 do tenant é uma verificação de infraestrutura ampla, relevante apenas se os passos anteriores não identificarem a causa.
A alternativa B (2 → 3 → 4 → 5 → 1) é plausível, mas verifica o atributo e o histórico antes de confirmar se o grupo ainda tem acesso ao aplicativo, o que pode levar o administrador a corrigir o atributo do usuário sem perceber que o grupo foi desassociado do aplicativo, resolvendo apenas metade do problema.
Árvore de Troubleshooting: Create users and groups
Legenda:
| Cor | Significado |
|---|---|
| Azul escuro | Sintoma inicial (nó raiz) |
| Azul | Pergunta diagnóstica |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
| Laranja | Validação ou verificação intermediária |
Para usar esta árvore diante de um problema real, comece pelo nó raiz e responda cada pergunta diagnóstica com base no que é observável no portal ou nos logs do Microsoft Entra ID. Cada resposta elimina um ramo e conduz ao próximo nível de verificação. Ao chegar a um nó de causa (vermelho), a ação correspondente (verde) indica a correção indicada. Nunca pule diretamente para a ação sem percorrer o caminho de perguntas, pois sintomas idênticos podem ter causas distintas dependendo do contexto de licenciamento, tipo de grupo e configuração de sincronização.