Laboratório de Troubleshooting: Configure self-service password reset (SSPR)
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
A equipe de suporte de uma empresa relata que usuários de um departamento específico estão sendo redirecionados para a página de registro do SSPR toda vez que tentam fazer login no portal do Microsoft Entra ID. Os usuários afirmam que já realizaram o registro anteriormente e que suas informações de contato estão atualizadas no perfil do Entra ID.
O administrador verifica o portal e confirma que o SSPR está habilitado para o grupo que contém esses usuários. Ele também confirma que a licença Microsoft Entra ID P1 está atribuída a todos os afetados. Ao revisar os logs de auditoria, encontra entradas recentes de registro bem-sucedido para esses usuários.
Informações adicionais coletadas pelo administrador:
Política de SSPR:
- Escopo: Grupo "Departamento_Financeiro"
- Métodos necessários para redefinição: 1
- Métodos habilitados: Aplicativo autenticador, E-mail alternativo
Configuração de registro:
- Exigir que os usuários se registrem ao entrar: Habilitado
- Número de dias antes que os usuários sejam solicitados a
reconfirmar suas informações de autenticação: 30
Os usuários confirmam que o último registro foi realizado há 32 dias.
Qual é a causa raiz do comportamento observado?
A) As licenças Microsoft Entra ID P1 foram atribuídas após o registro inicial, invalidando os métodos cadastrados.
B) O intervalo de reconfirmação de 30 dias foi atingido, e o sistema está solicitando que os usuários reconfirmem seus métodos de autenticação.
C) O grupo "Departamento_Financeiro" foi recriado recentemente, removendo a associação dos usuários com os registros de SSPR anteriores.
D) O método de aplicativo autenticador exige revalidação periódica independente das configurações de SSPR, causando o redirecionamento.
Cenário 2 — Decisão de Ação
O administrador de identidade de uma organização identificou que o write-back de senha está falhando silenciosamente. Usuários sincronizados do Active Directory local conseguem redefinir a senha pelo portal do SSPR sem erros, mas a nova senha não é propagada ao ambiente local. O acesso à rede local continua exigindo a senha antiga.
A causa foi confirmada: o write-back de senha está desabilitado nas configurações do Microsoft Entra Connect. O serviço do Entra Connect está em execução e a sincronização de diretório está funcionando normalmente.
O contexto operacional no momento da análise é o seguinte:
- São 14h30 de uma sexta-feira
- A janela de manutenção aprovada pela organização é entre 22h e 02h
- O ambiente é de produção com aproximadamente 800 usuários ativos
- O administrador possui permissões de Administrador Global no Entra ID e acesso administrativo ao servidor onde o Entra Connect está instalado
- Três usuários já abriram chamado relatando o problema nesta tarde
Qual é a ação correta a tomar neste momento?
A) Habilitar o write-back de senha imediatamente nas configurações do Entra Connect, pois a alteração não requer reinicialização de serviços e o impacto ao ambiente é mínimo.
B) Aguardar a janela de manutenção para habilitar o write-back de senha, e orientar os usuários afetados a solicitarem redefinição de senha ao administrador local até lá.
C) Desabilitar temporariamente o SSPR para todos os usuários sincronizados para evitar que mais usuários sejam afetados pelo comportamento inconsistente.
D) Reinstalar o agente do Microsoft Entra Connect no servidor local para forçar a restauração das configurações padrão, incluindo o write-back.
Cenário 3 — Causa Raiz
Um usuário entra em contato com o suporte relatando que não consegue completar a redefinição de senha pelo SSPR. Ele informa que escolheu o método de perguntas de segurança, respondeu corretamente todas as perguntas solicitadas, mas recebeu a seguinte mensagem ao tentar prosseguir:
Erro: Você não tem permissão para redefinir sua senha usando este método.
Entre em contato com o administrador.
O administrador verifica as configurações e encontra o seguinte:
Política de SSPR:
- Escopo: Todos os usuários
- Métodos necessários para redefinição: 1
- Métodos habilitados: Perguntas de segurança, E-mail alternativo
Conta do usuário:
- UPN: marcos.silva@contoso.com
- Funções atribuídas no Entra ID: Administrador de Helpdesk
- Licença: Microsoft Entra ID P2
- Métodos registrados: Perguntas de segurança (5 de 5 respondidas)
- Último login bem-sucedido: há 2 dias
O administrador também confirma que outros usuários sem funções administrativas conseguem usar perguntas de segurança normalmente.
Qual é a causa raiz do erro recebido por Marcos?
A) O usuário possui a licença Microsoft Entra ID P2, que impõe restrições adicionais aos métodos de autenticação disponíveis no SSPR.
B) A política de SSPR com escopo "Todos os usuários" não se aplica a contas com funções administrativas, exigindo um grupo dedicado.
C) Perguntas de segurança não são permitidas como método de redefinição de senha para contas que possuem funções administrativas no Microsoft Entra ID.
D) O registro de cinco perguntas de segurança excede o limite suportado para contas com funções no diretório, causando conflito interno.
Cenário 4 — Sequência de Diagnóstico
Um administrador recebe um alerta de que usuários de um ambiente híbrido estão conseguindo redefinir a senha pelo SSPR, mas a senha antiga continua funcionando no Active Directory local mesmo após a redefinição bem-sucedida no portal.
Os passos de investigação disponíveis são:
[P1] Verificar nos logs do Entra Connect se há erros de write-back
nas últimas sincronizações
[P2] Confirmar se o write-back de senha está habilitado nas
configurações do Microsoft Entra Connect
[P3] Verificar se o SSPR está configurado para o escopo correto
de usuários no portal do Entra ID
[P4] Confirmar se o agente do Entra Connect possui conectividade
com o Azure Service Bus (porta 443 de saída)
[P5] Verificar se a conta de serviço do Entra Connect possui
permissão de redefinição de senha no Active Directory local
Qual é a sequência correta de investigação para esse sintoma?
A) P3 → P1 → P2 → P4 → P5
B) P2 → P4 → P1 → P5 → P3
C) P2 → P1 → P4 → P5 → P3
D) P1 → P3 → P5 → P2 → P4
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A configuração exibe explicitamente que o intervalo de reconfirmação está definido como 30 dias, e os usuários realizaram o registro há 32 dias. Esse comportamento é exatamente o esperado: o Microsoft Entra ID solicita que o usuário reconfirme os métodos cadastrados quando o intervalo configurado é atingido. As entradas de registro bem-sucedido nos logs de auditoria confirmam registros anteriores válidos, não indicam falha, o que elimina hipóteses de invalidação.
A informação irrelevante neste cenário é a atribuição de licença Microsoft Entra ID P1. Ela é mencionada para induzir o leitor a investigar um caminho de licenciamento, mas licenças não afetam o comportamento de reconfirmação periódica.
O distrator A é o mais perigoso porque representa um equívoco real: licenças não invalidam registros de SSPR já realizados. Agir com base nesse diagnóstico levaria o administrador a revisar atribuições de licença sem resolver o problema, enquanto os usuários continuariam sendo redirecionados.
Gabarito — Cenário 2
Resposta: B
A causa já está identificada e a correção técnica é simples, mas o contexto operacional é determinante. Habilitar o write-back de senha no Entra Connect é uma alteração de configuração que, embora de baixo risco técnico, ocorre em ambiente de produção com 800 usuários ativos, fora da janela de manutenção aprovada. A política de manutenção existe para proteger o ambiente e deve ser respeitada, especialmente quando há uma alternativa de mitigação imediata: orientar os usuários afetados a solicitar redefinição manual até a janela disponível.
A alternativa A seria tecnicamente correta em um contexto sem restrições operacionais, mas ignora completamente a janela de manutenção, que é a restrição crítica do cenário. A alternativa C introduz impacto desnecessário para todos os usuários sincronizados em vez de mitigar apenas o problema relatado. A alternativa D descreve uma ação destrutiva e desproporcional para uma falha de configuração simples.
Gabarito — Cenário 3
Resposta: C
A Microsoft impõe explicitamente que perguntas de segurança não podem ser usadas como método de redefinição de senha por contas que possuem funções administrativas no Microsoft Entra ID, independentemente da política de SSPR configurada. Essa é uma restrição de plataforma, não de configuração. O fato de outros usuários sem funções conseguirem usar o mesmo método confirma que a política e o registro estão corretos; o problema é específico à conta com função atribuída.
A informação irrelevante é a licença Microsoft Entra ID P2. Ela foi incluída para desviar o raciocínio para uma investigação de licenciamento. O tipo de licença Entra ID não determina quais métodos de SSPR estão disponíveis para contas administrativas.
O distrator B representa um erro de raciocínio comum: confundir o escopo da política com a restrição de método. O escopo "Todos os usuários" está correto e se aplica normalmente; a restrição é sobre o método específico para funções administrativas, não sobre o escopo. Agir com base no distrator B levaria o administrador a criar grupos desnecessários sem resolver o problema.
Gabarito — Cenário 4
Resposta: C
A sequência correta segue a lógica de eliminação progressiva do geral para o específico, partindo da configuração mais básica e avançando para dependências de infraestrutura.
P2 deve ser o primeiro passo porque é a verificação mais direta: se o write-back está desabilitado, todos os outros passos são irrelevantes. P1 vem em seguida para confirmar se há erros registrados nas sincronizações, o que pode revelar se o write-back estava habilitado mas falhando. P4 investiga conectividade de rede com o Azure Service Bus, que é a dependência de infraestrutura do write-back. P5 verifica permissões da conta de serviço, que é uma causa comum de falha silenciosa no write-back mesmo quando tudo está habilitado. P3 é o último porque o sintoma já confirma que o SSPR funciona no portal; verificar o escopo seria retroceder para uma hipótese já descartada pelo próprio enunciado.
A sequência D é o erro mais perigoso: começar pelos logs (P1) antes de verificar se o write-back está habilitado (P2) é investigar sintomas antes de checar a configuração fundamental, o que pode gerar conclusões falsas a partir de logs que simplesmente não existem quando o write-back está desabilitado.
Árvore de Troubleshooting: Configure self-service password reset (SSPR)
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | Pergunta diagnóstica |
| Vermelho | Causa identificada ou ação corretiva necessária |
| Verde | Resolução confirmada |
| Laranja | Validação intermediária ou estado de atenção |
Para usar esta árvore diante de um problema real, comece sempre pelo nó raiz que descreve o sintoma observado e siga as ramificações respondendo cada pergunta diagnóstica com o que você pode verificar diretamente no portal ou no servidor. Cada resposta elimina um conjunto de hipóteses e direciona para a próxima verificação. Quando você chega a um nó vermelho, a causa está identificada e a ação está indicada. Quando chega a um nó verde, o fluxo está funcionando conforme esperado e o problema pode estar fora do escopo do SSPR.