Admins relataram que a opção “O usuário deve alterar a senha quando entrar pela primeira vez” apareceu marcada e esmaecida no Microsoft 365 Admin Center. Este guia explica a causa, impacto e soluções práticas, inclusive PowerShell e Entra ID.
Visão geral do problema
Ao criar contas no Microsoft 365 Admin Center, a caixa “O usuário deve alterar a senha quando entrar pela primeira vez” passou a aparecer marcada e cinzenta (bloqueada), impedindo a desmarcação no fluxo de criação. O efeito foi observado de forma ampla em locatários (tenants) exclusivamente em nuvem e também em cenários híbridos com sincronização de diretório. Como a opção fica desabilitada para edição, o administrador não consegue sinalizar no assistente que o usuário não deve trocar a senha no primeiro login/início de sessão.
Importante: diversos relatos indicaram que, apesar de visualmente “travada”, a exigência nem sempre era aplicada no momento do primeiro logon — caracterizando um problema mais visual/operacional do que funcional em muitos casos.
Causa raiz confirmada
O comportamento foi rastreado ao incidente de serviço MO897396, divulgado no Service Health / Message Center. Um update recente no código do Admin Center habilitou a exigência por padrão e, inadvertidamente, bloqueou sua edição no assistente de criação de usuários. A Microsoft reconheceu o erro e iniciou a reversão do ajuste.
Segundo a comunicação do incidente, a reversão foi programada para concluir entre 26 e 27 de setembro de 2024 (de acordo com o fuso). Após a reversão, a caixa volta a ficar editável no fluxo de criação do usuário.
Escopo e impacto
- Quem é afetado: qualquer administrador que tente desabilitar a exigência de troca de senha diretamente no wizard do Microsoft 365 Admin Center.
- Serviços envolvidos: criação de contas no Microsoft 365; propriedades do usuário no Entra ID (antigo Azure AD).
- Impacto prático: atrito operacional na criação de usuário e possível necessidade de ajustes pós-criação. Em muitos tenants, a exigência não se materializou no primeiro logon apesar do “check” visual estar travado; portanto, o impacto foi frequentemente cosmético.
- Ambientes híbridos: apesar de ambientes híbridos poderem ter problemas semelhantes por permissões de OU no AD local, neste caso específico a causa principal foi o incidente global no Admin Center.
Como reconhecer o sintoma
- Abra o Microsoft 365 Admin Center e inicie a criação de um novo usuário.
- Na etapa de senha, observe a opção “O usuário deve alterar a senha quando entrar pela primeira vez”.
- Se estiver marcada e esmaecida, sem permitir clique para desmarcar, você está diante do comportamento associado ao MO897396.
Matriz rápida de decisão
| Cenário | O que fazer agora | Por que escolher esta abordagem |
|---|---|---|
| Exigência não é aplicada no teste de login | Ignorar temporariamente e seguir com o onboarding | Evita retrabalho; impacto é apenas visual |
| Você precisa garantir que não haja troca no primeiro logon | Ajustar via PowerShell (Graph) após a criação | Controle preciso da flag forceChangePasswordNextSignIn |
| Você prefere não usar PowerShell | Criar/editar usuário direto no Entra ID (portal) | A opção permanece editável fora do wizard afetado |
| Criação em massa | Script em lote com Microsoft Graph | Automação consistente, auditável e reversível |
Soluções e workarounds
Enquanto o incidente não era totalmente revertido (ou em casos de recorrência de comportamento similar), utilize uma das abordagens abaixo.
| Abordagem | Como fazer | Observações |
|---|---|---|
| PowerShell (Microsoft Graph) | Após criar o usuário no Admin Center, ajuste a flag via Graph: # Instalar e conectar Install-Module Microsoft.Graph -Scope CurrentUser Import-Module Microsoft.Graph.Users Connect-MgGraph -Scopes "User.ReadWrite.All" Desabilitar a troca de senha no primeiro logon Update-MgUser -UserId [usuario@dominio.com](mailto:usuario@dominio.com) \` -PasswordProfile @{ forceChangePasswordNextSignIn = \$false } | Requer permissões adequadas (User.ReadWrite.All). Comando atua diretamente em passwordProfile.forceChangePasswordNextSignIn. |
| PowerShell (MSOnline) | Se ainda usa o módulo MSOnline, a forma mais direta é ajustar apenas a flag: # Conectar Connect-MsolService Apenas alternar a exigência sem trocar a senha Set-MsolUserPassword -UserPrincipalName [usuario@dominio.com](mailto:usuario@dominio.com) \` -ForceChangePasswordOnly \$true -ForceChangePassword \$false | O módulo MSOnline está em modo de manutenção; prefira Microsoft Graph em projetos novos. Evite comandos que apenas mexem em PasswordPolicies (como DisablePasswordExpiration): isso é outra configuração e não controla a troca no primeiro logon. |
| Azure Portal (Entra ID) | Crie ou edite o usuário diretamente no Entra ID: Acesse o portal do Entra ID e vá a Usuários. Crie o usuário ou abra o perfil recém-criado. Na seção de senha/perfil, ajuste a exigência de troca no primeiro logon (opção permanece editável). | Evita o wizard do Admin Center que foi impactado pelo bug. |
| Ignorar temporariamente | Faça um teste de login em janela privada. Se o sistema não solicitar troca de senha, continue o onboarding sem ações adicionais. | Útil para cenários de baixa criticidade e quando há pressão por agilidade. |
Automatizando em lote com Microsoft Graph
Para muitos usuários, automatize em PowerShell com Graph, lendo uma lista de UPNs de um CSV.
# Arquivo: usuarios.csv com uma coluna UPN
UPN
joana@contoso.com
paulo@contoso.com
Import-Module Microsoft.Graph.Users
Connect-MgGraph -Scopes "User.ReadWrite.All"
\$usuarios = Import-Csv -Path ".\usuarios.csv"
foreach (\$u in \$usuarios) {
try {
Update-MgUser -UserId \$u.UPN -PasswordProfile @{ forceChangePasswordNextSignIn = \$false }
Write-Host "OK - \$(\$u.UPN)"
} catch {
Write-Warning "ERRO - \$(\$u.UPN): \$($\_.Exception.Message)"
}
} Como verificar o resultado de forma segura
- Teste controlado: peça ao usuário para entrar uma vez em janela privada de navegador (ou use uma máquina de teste) e observar se a troca é exigida.
- Repetibilidade: após definir
forceChangePasswordNextSignIn = $false, a exigência não deve aparecer; se persistir, reforce o ajuste e aguarde a replicação. - Auditoria: registre o ticket interno ou mudança (Change) com data/hora e comando utilizado.
Status oficial e acompanhamento
O incidente MO897396 foi reconhecido como regressão no Microsoft 365 Admin Center. A Microsoft iniciou e conduziu a reversão com previsão de conclusão entre 26 e 27 de setembro de 2024. Para verificar o histórico ou confirmar resoluções de incidentes similares, utilize o painel Health → Service Health do portal e pesquise por esse identificador. Em cenários futuros, sempre que algum controle “grudar” ou ficar inesperadamente cinzento, checar o Message Center antes de alterar políticas pode poupar tempo e evitar configurações desnecessárias.
Diagnóstico diferencial em ambientes híbridos
Ambientes com sincronização de diretório (Entra Connect) podem exibir sintomas parecidos por permissões insuficientes na OU ou por atributos protegidos no Active Directory local, que prevalecem durante a sincronização. Dicas:
- Valide se a conta é cloud-only ou sincronizada (on-premises sync enabled).
- Para objetos sincronizados, ajustes de senha e bandeiras de troca geralmente devem respeitar a origem (on-premises). Revise GPOs e delegações nas OUs envolvidas.
- Se o comportamento somente aparece no Assistente do Admin Center e não no portal do Entra ID, isso reforça o diagnóstico de incidente no Admin Center.
Boas práticas de segurança e operação
- Princípio do mínimo privilégio: use contas administrativas apenas para as ações necessárias e prefira perfis de função em vez de Global Admin para tarefas operacionais.
- Troca de senha no primeiro logon: é uma prática recomendada em muitos cenários. Desative-a apenas quando houver processo de identidade que garanta o sigilo da senha inicial (envio seguro, Just-In-Time, credenciais temporárias, autenticação multifator obrigatória, etc.).
- Padronize seu onboarding: scripts ou runbooks que criam usuários e aplicam propriedades de forma consistente reduzem a chance de incidentes visuais criarem ruído.
- Use MFA e SSPR: combine MFA e Redefinição de Senha Autossuficiente (SSPR) para equilibrar segurança e experiência do usuário, sobretudo quando a troca de senha no primeiro logon é desativada por razões operacionais.
Erros comuns que vale evitar
- Confundir
PasswordPolicies DisablePasswordExpirationcom a exigência de troca de senha no primeiro logon — são configurações diferentes. - Alterar políticas globais de senha por causa de um bug cosmético no assistente; prefira validar o Service Health e fazer workaround pontual.
- Deixar de testar com janela privada ou outro navegador — o cache pode induzir conclusões incorretas.
Perguntas frequentes
Essa exigência travada significa que todos os usuários serão obrigados a trocar a senha?
Não necessariamente. Em muitos relatos, a exigência não se concretizou no logon. Ainda assim, se você precisa garantir um comportamento específico, ajuste via PowerShell ou Entra ID.
Posso resolver sem PowerShell?
Sim. Criar ou editar diretamente no Entra ID mantém a opção editável. Porém, para maior controle em massa, o Microsoft Graph via PowerShell é a opção mais robusta.
O que mudou após a reversão?
A caixa volta a ficar editável no Microsoft 365 Admin Center, permitindo marcar ou desmarcar a exigência durante a criação do usuário.
E se o meu ambiente for híbrido?
Verifique se políticas ou permissões on‑premises estão influenciando a conta. Se o problema só aparece no Assistente do Admin Center e não no Entra ID, isso indica mais fortemente o incidente do portal, não uma restrição local.
Checklist operacional
- Confirmar se o cenário corresponde ao MO897396 (comportamento travado no assistente).
- Definir a estratégia: ignorar temporariamente, ajustar via PowerShell ou usar o Entra ID.
- Se usar PowerShell, preferir Microsoft Graph e registrar os comandos executados.
- Executar teste de login controlado e documentar resultado.
- Monitorar o Service Health para o encerramento oficial do incidente e para possíveis recorrências.
Comandos úteis e equivalências
| Objetivo | Microsoft Graph (PowerShell) | MSOnline (PowerShell) | Interface |
|---|---|---|---|
| Desabilitar “trocar senha no primeiro logon” | Update-MgUser -UserId UPN -PasswordProfile @{ forceChangePasswordNextSignIn = $false } | Set-MsolUserPassword -UserPrincipalName UPN -ForceChangePasswordOnly $true -ForceChangePassword $false | Entra ID → Usuário → Senha → Ajustar exigência |
| Desabilitar expiração de senha | Update-MgUser -UserId UPN -PasswordPolicies DisablePasswordExpiration | Set-MsolUser -UserPrincipalName UPN -PasswordNeverExpires $true | Política de senha / Configurações de segurança |
Dica: desabilitar expiração de senha não substitui a configuração de troca no primeiro logon; são finalidades distintas.
Conclusão
O bloqueio da opção “O usuário deve alterar a senha quando entrar pela primeira vez” no Microsoft 365 Admin Center foi fruto de uma alteração regressiva reconhecida pela Microsoft sob o incidente MO897396. A reversão foi planejada para os dias 26/27 de setembro de 2024 e, uma vez concluída, devolveu a editabilidade do controle no wizard de criação. Enquanto o problema esteve ativo (ou em caso de recorrências semelhantes), os administradores puderam contornar de forma segura e eficaz usando PowerShell com Microsoft Graph, realizando a criação/edição diretamente no Entra ID, ou, quando comprovado que o efeito era apenas visual, ignorando temporariamente.
Para reduzir impactos de incidentes visuais futuros, mantenha runbooks padronizados, monitore o Service Health, e priorize automação com Graph. Assim, sua operação permanece segura, rastreável e resiliente — mesmo quando o portal passa por ajustes nos bastidores.