Fundamentação Teórica: Configure self-service password reset (SSPR)

---

1. Intuição Inicial

Em qualquer empresa com centenas ou milhares de funcionários, uma das tarefas mais frequentes do helpdesk é resetar senhas. Um funcionário esqueceu a senha na segunda-feira de manhã, liga para o suporte, aguarda na fila, um técnico verifica a identidade dele e redefine a senha. Esse ciclo custa tempo, dinheiro e paciência.

O Self-Service Password Reset (SSPR) é a solução do Microsoft Entra ID para esse problema: permite que o próprio usuário redefina sua senha ou desbloqueie sua conta sem precisar ligar para o helpdesk, desde que ele tenha previamente registrado métodos de verificação de identidade (como um celular ou e-mail alternativo).

A analogia perfeita é o "Esqueceu sua senha?" dos sites de banco. Você clica, o site verifica sua identidade por um código SMS ou e-mail, e você define uma nova senha. O SSPR é exatamente isso, mas integrado ao Entra ID, funcionando tanto para acesso ao portal do Azure quanto para login no Windows e em aplicações corporativas.

---

2. Contexto

O SSPR faz parte do conjunto de funcionalidades de segurança e produtividade do Microsoft Entra ID. Ele se posiciona na intersecção entre segurança de identidade e experiência do usuário:

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Um ponto importante: o registro de métodos de autenticação para SSPR e para MFA usa a mesma infraestrutura no portal Combined Security Info Registration (aka.ms/mysecurityinfo). Um usuário que registra seu celular para MFA pode usar o mesmo celular para SSPR, e vice-versa. Isso elimina a necessidade de registros separados.

O Password Writeback (indicado em amarelo) é a funcionalidade que conecta o SSPR a ambientes híbridos. Sem ele, uma redefinição feita no Entra ID não se propaga para o Active Directory on-premises, e o usuário continuaria com a senha antiga no ambiente local.

Requisitos de Licença

Funcionalidade	Licença necessária
SSPR para usuários na nuvem	Microsoft Entra ID Free (com P1/P2 para recursos avançados)
SSPR com Password Writeback	Microsoft Entra ID P1 ou P2
SSPR + Identity Protection integration	Microsoft Entra ID P2

Ponto de atenção: o SSPR básico (apenas cloud) está disponível no plano gratuito. O Password Writeback requer P1 ou P2. Para o AZ-104, é importante saber essa distinção.

---

3. Construção dos Conceitos

3.1 Escopo de Habilitação do SSPR

O primeiro conceito a entender é que o SSPR não precisa ser habilitado para todos ao mesmo tempo. Existem três opções de escopo:

Opção	Quem pode usar SSPR	Quando usar
None	Ninguém	SSPR desabilitado no tenant
Selected	Apenas usuários de um grupo específico	Piloto, rollout gradual, grupos específicos
All	Todos os usuários do tenant	Implantação completa

A opção Selected é fundamental para fazer um piloto controlado antes de habilitar para todos. Você cria um grupo de segurança chamado, por exemplo, SG-SSPR-Piloto, adiciona 50 usuários voluntários, habilita o SSPR para esse grupo, coleta feedback e então expande para All.

3.2 Métodos de Autenticação do SSPR

Para que o usuário possa redefinir a senha por conta própria, o sistema precisa verificar que é realmente ele. Isso é feito através de métodos de autenticação. O Entra ID suporta os seguintes métodos para SSPR:

Método	Como funciona	Observações
Mobile app notification	Notificação push no Microsoft Authenticator	Mais seguro e conveniente
Mobile app code	Código TOTP gerado pelo Authenticator	Funciona sem internet no celular
Email	Código enviado para e-mail alternativo (não o corporativo)	E-mail alternativo, não o que o usuário está tentando acessar
Mobile phone	Código SMS ou chamada de voz para celular	Amplamente suportado
Office phone	Chamada de voz para ramal comercial	Menos comum para SSPR
Security questions	Perguntas e respostas pré-cadastradas	Menos seguro, ver nota abaixo

Sobre perguntas de segurança: são o método mais fraco porque as respostas podem ser descobertas por engenharia social ou pesquisa em redes sociais. A Microsoft recomenda não usar perguntas de segurança como único método, e o SSPR não permite que seja o único método quando apenas um método é requerido para reset.

3.3 Número de Métodos Requeridos

Uma das configurações mais importantes é quantos métodos o usuário precisa apresentar para conseguir redefinir a senha:

Configuração	Comportamento	Segurança
1 método requerido	Usuário apresenta apenas 1 método cadastrado	Menor atrito, menor segurança
2 métodos requeridos	Usuário deve apresentar 2 métodos diferentes	Maior segurança, mais atrito

A escolha depende do perfil de risco da organização. Para a maioria das empresas, 1 método é suficiente quando o método é o Microsoft Authenticator ou SMS. Para ambientes de alta segurança ou para contas com acesso privilegiado, 2 métodos é mais adequado.

3.4 Registro dos Métodos

Antes de poder usar o SSPR, o usuário precisa registrar seus métodos de autenticação. Existem três cenários de registro:

Registro forçado no próximo login: o administrador habilita a opção de exigir que o usuário registre os métodos quando fizer login pela próxima vez. O usuário é redirecionado para aka.ms/mysecurityinfo e não pode pular o registro.

Registro voluntário: o usuário acessa aka.ms/mysecurityinfo por conta própria e registra seus métodos. Depende de comunicação e adoção.

Período de carência (grace period): se o registro forçado está habilitado, você pode configurar um período de dias (padrão: 14 dias) durante o qual o usuário pode adiar o registro. Após esse período, o registro se torna obrigatório.

3.5 Password Writeback: O Elo Híbrido

Em ambientes onde existe um Active Directory on-premises sincronizado com o Entra ID via Entra Connect, existe um desafio: as senhas dos usuários sincronizados são gerenciadas no AD local. Se um usuário redefine a senha pelo SSPR (no Entra ID), essa mudança precisa ser propagada de volta para o AD on-premises. Isso é o Password Writeback.

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Sem o Password Writeback habilitado, um usuário que redefiniu a senha no SSPR consegue acessar serviços cloud (Microsoft 365, portal do Azure), mas não consegue logar no Windows de um computador ingressado no domínio local, pois o AD ainda tem a senha antiga.

---

4. Visão Estrutural

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

---

5. Funcionamento na Prática

Fluxo do Usuário: Reset de Senha

O usuário que esqueceu a senha acessa https://aka.ms/sspr (ou clica em "Forgot my password" na tela de login do Microsoft 365 ou Windows). O fluxo é:

1. Insere o UPN (seu endereço de e-mail corporativo)
2. Resolve um CAPTCHA para evitar automação maliciosa
3. Escolhe o método de verificação (dos que registrou)
4. Completa a verificação (insere o código SMS, aprova a notificação do app, etc.)
5. Se configurado para 2 métodos, repete com um segundo método diferente
6. Define a nova senha (respeitando a política de complexidade do tenant)
7. Recebe confirmação e é redirecionado ao login

Comportamentos Importantes e Não Óbvios

Administradores sempre precisam de 2 métodos: independentemente da configuração do tenant para usuários comuns, contas com papéis administrativos no Entra ID sempre precisam de 2 métodos para resetar a senha via SSPR. Isso é uma proteção adicional que não pode ser desabilitada.

Administradores não podem usar perguntas de segurança: por razões de segurança, contas com papéis administrativos não podem usar perguntas de segurança como método de verificação no SSPR.

Notificações de reset: quando uma senha é redefinida via SSPR, o Entra ID pode enviar uma notificação por e-mail ao usuário e/ou ao administrador. Isso serve como alerta de segurança: se alguém tentou usar o SSPR sem ser o usuário legítimo, o usuário real é notificado e pode acionar o helpdesk.

Bloqueio após tentativas falhas: o SSPR tem proteção contra força bruta. Após um número de tentativas de verificação falhas, a conta é bloqueada temporariamente para SSPR. O usuário precisa aguardar ou entrar em contato com o helpdesk.

Portal de registro e SSPR são diferentes do portal de uso: o registro é feito em aka.ms/mysecurityinfo. O uso do SSPR é em aka.ms/sspr. A maioria dos usuários chega ao SSPR pelo link "Forgot my password" na tela de login, não acessando o portal diretamente.

---

6. Formas de Implementação

6.1 Portal do Azure

Quando usar: configuração inicial, ajustes pontuais, verificação de estado.

Caminho: Microsoft Entra ID > Password reset

A seção "Password reset" no portal do Azure tem as seguintes abas:

Aba	O que configura
Properties	Escopo: None / Selected / All
Authentication methods	Quais métodos são permitidos, quantos são requeridos
Registration	Registro obrigatório no login, período de carência, frequência de reconfirmação
Notifications	Notificação ao usuário e ao admin quando senha é redefinida
Customization	Link para helpdesk personalizado exibido quando SSPR não está disponível
On-premises integration	Password Writeback

Vantagens: visualização completa de todas as configurações em um lugar, feedback imediato.

Limitações: não escala para automação ou deployment em múltiplos tenants.

6.2 PowerShell (Microsoft Graph PowerShell SDK)

Quando usar: automação, deployment consistente entre tenants, scripts de auditoria.

Verificar a configuração atual do SSPR:

# Requer permissão Policy.Read.All
Get-MgPolicyAuthenticationMethodPolicy

Verificar métodos de autenticação registrados por um usuário:

$userId = "joao.silva@contoso.com"
Get-MgUserAuthenticationMethod -UserId $userId

Isso retorna todos os métodos registrados pelo usuário, incluindo telefones, o app Authenticator e senhas (como método de autenticação primário).

Remover um método de autenticação de um usuário (útil quando um funcionário perde o celular):

$userId = "joao.silva@contoso.com"
$methods = Get-MgUserAuthenticationPhoneMethod -UserId $userId
foreach ($method in $methods) {
    Remove-MgUserAuthenticationPhoneMethod -UserId $userId -PhoneAuthenticationMethodId $method.Id
}

6.3 Microsoft Graph API

Verificar métodos de autenticação registrados:

GET https://graph.microsoft.com/v1.0/users/joao.silva@contoso.com/authentication/methods

Adicionar um número de telefone para um usuário (pré-populando o registro):

POST https://graph.microsoft.com/v1.0/users/joao.silva@contoso.com/authentication/phoneMethods
Content-Type: application/json

{
  "phoneNumber": "+55 11 99999-0000",
  "phoneType": "mobile"
}

Isso é particularmente útil para pré-registrar métodos durante o onboarding: o sistema de RH pode enviar o número de celular do novo funcionário, e um script popula automaticamente o método de autenticação antes do primeiro login, eliminando a necessidade de o usuário registrar por conta própria.

6.4 Configuração via Microsoft Entra Admin Center

O Microsoft Entra Admin Center (entra.microsoft.com) oferece a mesma interface que o portal do Azure para configuração de SSPR, com uma experiência ligeiramente mais moderna. Para o AZ-104, ambos os caminhos levam ao mesmo resultado.

---

7. Controle e Segurança

Políticas de Senha

O SSPR respeita e está integrado às políticas de senha do Entra ID:

Política	Comportamento padrão	Configurável?
Comprimento mínimo	8 caracteres	Sim (até 256)
Complexidade	Requer maiúsculas, minúsculas, números ou símbolos	Não (sempre requerido)
Histórico de senhas	Não pode reutilizar as 3 últimas	Não configurável pelo portal
Expiração	90 dias (padrão), mas muitos tenants desabilitam	Sim
Senhas banidas	Lista global de senhas comuns (Azure AD Password Protection)	Pode adicionar lista customizada

O Azure AD Password Protection é um componente que bloqueia senhas fracas ou previsíveis (como "Contoso2024!" para uma empresa chamada Contoso). Ele opera tanto na nuvem quanto pode ser estendido ao AD on-premises com um agente instalado nos controladores de domínio.

Auditoria do SSPR

Toda atividade do SSPR gera registros nos Audit Logs e nos Self-service password reset activity reports do Entra ID:

Caminho: Microsoft Entra ID > Password reset > Audit logs

Os eventos registrados incluem:

• Self-service password reset flow activity started: usuário iniciou o processo
• User wrote back password to on-premises directory: writeback executado
• User reset password (self-service): reset concluído com sucesso
• User registered for self-service password reset: registro de método concluído
• Blocked from self-service password reset: tentativas bloqueadas por suspeita de abuso

Customization: Helpdesk Link

Quando o SSPR não está disponível para o usuário (não está no escopo habilitado, não registrou métodos), a tela de "Esqueceu a senha" pode exibir um link personalizado para o helpdesk interno. Isso é configurado na aba Customization:

• Helpdesk email or URL: pode ser um endereço de e-mail ou URL de um portal de suporte interno
• Custom helpdesk text: texto exibido ao lado do link

Essa customização melhora a experiência do usuário ao direcionar claramente para onde pedir ajuda quando o self-service não funciona.

---

8. Tomada de Decisão

Quantos métodos exigir para reset?

Situação	Configuração recomendada	Motivo
Usuários comuns, baixo risco	1 método (Authenticator ou SMS)	Menor atrito, suficiente para a maioria
Contas de acesso a dados sensíveis	2 métodos	Maior garantia de que é o usuário real
Contas administrativas	2 métodos (obrigatório pelo Azure)	Proteção adicional não configurável
Ambiente com alta rotatividade	1 método + registro forçado	Garante registro sem onboarding manual

Qual método de autenticação priorizar?

Método	Segurança	Usabilidade	Recomendação
Microsoft Authenticator (notificação)	Alta	Alta	Primeira escolha
Microsoft Authenticator (código TOTP)	Alta	Alta	Segunda escolha
SMS	Média	Alta	Boa para usuários sem smartphone
E-mail alternativo	Média	Alta	Útil como fallback
Chamada de voz	Média	Média	Para usuários sem acesso a SMS
Perguntas de segurança	Baixa	Alta	Evitar como método único

Quando habilitar Password Writeback?

Situação	Decisão	Motivo
Ambiente 100% na nuvem	Não necessário	Não há AD on-premises para sincronizar
Ambiente híbrido com usuários que usam VPN/Intune	Obrigatório	Sem writeback, reset não funciona para login local
Ambiente híbrido onde usuários só acessam cloud	Opcional	Se não há login local, writeback não é crítico
Usuários com dispositivos Windows ingressados no domínio local	Obrigatório	Login no Windows usa a senha do AD local

---

9. Boas Práticas

Faça rollout gradual com o escopo "Selected": antes de habilitar SSPR para todos, crie um grupo piloto com usuários representativos de diferentes perfis (técnicos, não técnicos, móveis, fixos). Monitore o uso, colete feedback e ajuste as configurações antes de expandir.

Force o registro mas dê um período de carência razoável: o período de 14 dias padrão é adequado para a maioria dos ambientes. Períodos muito curtos causam fricção desnecessária. Períodos muito longos resultam em usuários que nunca registram.

Comunique antes de habilitar: usuários que não sabem o que é SSPR vão ligar para o helpdesk confusos quando forem redirecionados para registrar métodos. Uma comunicação prévia com instruções claras reduz chamados e resistência.

Pré-popule o número de celular via Graph API durante o onboarding: em vez de depender que o usuário registre o método por conta própria, injete o número de celular (fornecido pelo RH) automaticamente no momento da criação da conta. O usuário já chega com um método registrado.

Configure a reconfirmação periódica de métodos: o Entra ID pode solicitar que os usuários confirmem/atualizem seus métodos de autenticação periodicamente (padrão: 180 dias). Isso garante que números de telefone desatualizados não fiquem como único método registrado.

Habilite notificações de reset para o usuário: a notificação por e-mail quando uma senha é redefinida funciona como alerta de segurança. Se o usuário real não iniciou o reset, ele é notificado e pode agir rapidamente.

---

10. Erros Comuns

Habilitar SSPR sem comunicar os usuários sobre o registro

O SSPR fica habilitado, mas como os usuários nunca registraram métodos, quando tentam redefinir a senha recebem a mensagem de que não têm métodos configurados. Continuam ligando para o helpdesk. O SSPR existe mas não é usado. A solução é habilitar o registro forçado junto com o SSPR.

Não habilitar Password Writeback em ambiente híbrido

O usuário redefine a senha pelo portal, recebe confirmação de sucesso, mas não consegue logar no computador do escritório. O helpdesk recebe o chamado confuso pois a "redefinição funcionou". A causa é a ausência do writeback. Sempre verifique se o ambiente é híbrido antes de concluir a configuração.

Confiar apenas em perguntas de segurança

Perguntas como "Qual o nome do seu primeiro animal de estimação?" são frequentemente descobertas por pesquisa em redes sociais ou por pessoas próximas. Se as perguntas de segurança forem habilitadas, use-as apenas como segundo método complementar, nunca como único método.

Não testar o fluxo completo após configuração

Administradores configuram o SSPR no portal, marcam como "concluído" e nunca testam o fluxo real do usuário. Problemas como URLs de redirecionamento incorretas, métodos que não funcionam no país do usuário ou configurações de writeback mal feitas só aparecem quando um usuário real tenta usar. Sempre teste com uma conta de teste antes do rollout.

Bloquear acesso ao aka.ms/mysecurityinfo por proxy ou firewall

Algumas organizações filtram URLs externas agressivamente. Se aka.ms/mysecurityinfo ou aka.ms/sspr estiverem bloqueados pelo proxy corporativo, os usuários não conseguem registrar métodos nem usar o SSPR. Verifique que essas URLs estão na lista de permissões.

Esquecer que administradores têm regras diferentes

Um administrador que testa o SSPR com sua própria conta percebe que precisa de 2 métodos mesmo com o tenant configurado para 1. Isso não é um bug nem uma configuração errada: é o comportamento esperado para contas com papéis administrativos. O teste deve ser feito com uma conta de usuário comum.

---

11. Operação e Manutenção

Relatórios de Uso do SSPR

O Entra ID oferece relatórios específicos para o SSPR em Microsoft Entra ID > Password reset > Audit logs e Usage & insights:

Registration report: mostra quantos usuários registraram métodos, quais métodos foram registrados e quais usuários ainda não registraram nada.

Usage report: mostra quantos resets foram feitos, quais métodos foram usados, quantos falharam e por quê (método inválido, usuário bloqueado, etc.).

Esses relatórios são essenciais para:

• Identificar usuários que ainda não registraram métodos
• Medir o impacto do SSPR na redução de chamados ao helpdesk
• Identificar métodos com alta taxa de falha

Verificar usuários sem métodos registrados

# Listar usuários habilitados sem nenhum método de autenticação registrado
$users = Get-MgUser -All -Filter "accountEnabled eq true" `
  -Property "id,displayName,userPrincipalName"

foreach ($user in $users) {
    $methods = Get-MgUserAuthenticationMethod -UserId $user.Id
    # Filtra apenas método "password" (todos têm); procura por métodos adicionais
    $additionalMethods = $methods | Where-Object { 
        $_.AdditionalProperties["@odata.type"] -ne "#microsoft.graph.passwordAuthenticationMethod"
    }
    if ($additionalMethods.Count -eq 0) {
        Write-Output "$($user.DisplayName) - $($user.UserPrincipalName) - SEM MÉTODOS"
    }
}

Limites Importantes

Item	Valor
Tentativas de reset antes do bloqueio	Configurável, padrão: sem limite por design (proteção por throttling inteligente)
Validade do código SMS	5 minutos
Validade do código de e-mail	5 minutos
Período de reconfirmação de métodos	0 a 730 dias (padrão: 180)
Perguntas de segurança mínimas para registro	3 a 5 (configurável)
Perguntas de segurança requeridas para reset	3 a 5 (configurável, não pode exceder o número de registro)

---

12. Integração e Automação

Integração com Entra Connect e Password Writeback

O Password Writeback é configurado em dois lugares:

No Entra Connect (servidor on-premises): ao configurar o Entra Connect, habilite a funcionalidade "Password writeback" na seção de features opcionais do wizard de configuração.

No portal do Entra ID: em Password reset > On-premises integration, habilite "Write back passwords to your on-premises directory" e opcionalmente "Allow users to unlock accounts without resetting their password" (permite desbloquear a conta AD sem precisar mudar a senha).

Pré-registro via Automação no Onboarding

A melhor estratégia de automação para SSPR é integrar o pré-registro ao fluxo de onboarding de novos funcionários:

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Esse fluxo garante que 100% dos usuários cheguem com pelo menos um método registrado, eliminando a dependência de adoção voluntária.

Monitoramento com Azure Monitor

Os logs de SSPR podem ser exportados para um Log Analytics Workspace para monitoramento centralizado e alertas:

# Exportar audit logs do Entra ID para Log Analytics
# Configurado em: Microsoft Entra ID > Monitoring > Diagnostic settings

Com os logs no Log Analytics, é possível criar alertas para:

• Picos no número de resets (pode indicar campanha de phishing)
• Alta taxa de falhas em verificações (pode indicar ataque de força bruta)
• Usuários que tentaram SSPR mas não tinham métodos registrados

---

13. Resumo Final

Pontos essenciais:

• O SSPR permite que usuários redefinam senhas e desbloqueiem contas sem helpdesk, usando métodos de autenticação pré-registrados.
• O escopo pode ser None, Selected (grupo específico) ou All. Comece com Selected para piloto controlado.
• Métodos suportados: Microsoft Authenticator (notificação e TOTP), SMS, chamada de voz, e-mail alternativo, perguntas de segurança. O Authenticator é a primeira escolha.
• O número de métodos requeridos para reset pode ser 1 ou 2. Administradores sempre precisam de 2, independente da configuração.
• O Password Writeback é necessário em ambientes híbridos e requer licença P1 ou P2. Sem ele, o reset atualiza apenas a nuvem.
• O registro combinado (aka.ms/mysecurityinfo) compartilha métodos entre SSPR e MFA.

Diferenças críticas:

• SSPR para usuários comuns (licença Free): funciona para identidades cloud. Password Writeback não incluso.
• SSPR com Password Writeback (licença P1/P2): funciona para ambientes híbridos, propaga a mudança para o AD local.
• Administradores vs. usuários comuns: admins sempre precisam de 2 métodos para SSPR, não podem usar perguntas de segurança, e suas redefinições passam por um processo mais rigoroso.
• Registro (aka.ms/mysecurityinfo) vs. uso (aka.ms/sspr): são portais diferentes para fins distintos.

O que precisa ser lembrado:

• Habilite o registro forçado no próximo login ao implantar o SSPR para garantir adoção.
• Pré-popule números de telefone via Graph API durante o onboarding para garantir que usuários chegam com métodos registrados.
• Evite perguntas de segurança como único método. Prefira Authenticator ou SMS.
• Teste o fluxo completo com uma conta de usuário comum antes do rollout, não com conta de administrador.
• Configure notificações de reset para que usuários sejam alertados quando uma redefinição ocorre, funcionando como detecção de abuso.
• Em ambientes híbridos, verifique que o Entra Connect tem o Password Writeback habilitado E que o portal do Entra ID também tem o writeback ativado. São duas configurações independentes que precisam estar ambas ativas.