Microsoft 365 Admin Center: opzione “cambia password al primo accesso” bloccata — cause, stato e workaround operativi MO897396

Nel Microsoft 365 Admin Center alcuni amministratori vedono la casella “Richiedi che l’utente cambi la password al primo accesso” già selezionata e non modificabile. Non è una nuova policy: è un bug del portale (incidente MO897396). Qui trovi cause, stato, impatto e workaround operativi.

Indice

Quadro generale e sintomi

All’atto di creare un nuovo utente dal portale di amministrazione Microsoft 365, la casella relativa al cambio password obbligatorio al primo accesso risulta:

preselezionata in modo forzato;
disattivata e non deselezionabile;
identica per amministratori globali e amministratori utenti;
presente tanto in tenant solo cloud quanto in ambienti ibridi con sincronizzazione directory.

Il comportamento non dipende da permessi locali, connector o criteri personalizzati: il portale sovrascrive l’impostazione impedendone la modifica dall’interfaccia.

Ambiti interessati

Il problema interessa gli amministratori che creano o modificano utenti dal portale. Non impatta direttamente le API o i cmdlet PowerShell, che continuano a rispettare i parametri inviati lato codice.

Causa tecnica dell’anomalia

La causa è stata attribuita a un aggiornamento del codice dell’interfaccia del portale, che ha introdotto una forzatura della proprietà “cambia password al primo accesso” e ne ha bloccato il toggle. Di seguito il riepilogo strutturato.

Elemento	Dettagli
ID incidente	MO897396
Servizi interessati	Microsoft 365 suite
Tipo di evento	Service degradation (Advisory)
Origine del guasto	Un aggiornamento recente al codice del portale ha forzato l’impostazione “cambia password al primo accesso” e ne ha inibito la disattivazione.
Inizio impatto	19 settembre 2024 – 13:00 UTC
Ambito	Qualsiasi amministratore che tenti di deselezionare l’opzione dal portale

Cronologia e stato dell’incidente

24 settembre 2024: conferma ufficiale del problema e avvio del rollback del codice difettoso.
Finestra di ripristino: prevista tra il 26 e il 27 settembre, con propagazione che può variare per fuso orario e regione.
Dove seguire gli aggiornamenti: all’interno del tenant, sezione Health ► Service Health, voce associata all’ID MO897396.

Una volta contrassegnato come “Service restored”, il portale tornerà a consentire la deselezione della casella.

Impatto operativo e rischi reali

L’impostazione forzata obbliga gli utenti al cambio password al primo accesso. In molte realtà questa prassi è allineata alle policy, ma esistono eccezioni operative in cui non è desiderabile o non è possibile:

account di servizio o integrazioni applicative che non supportano flussi interattivi;
utenze temporanee per test o demo con credenziali precondivise tra più persone in finestre ristrette;
scenari di automazione in cui la prima autenticazione avviene “headless”.

Per questi casi è fondamentale poter impostare Force change password at next sign-in a false in fase di creazione o subito dopo.

Soluzioni e workaround disponibili

Qui sotto trovi la matrice decisionale con i pro e quando preferire ogni opzione.

Approccio	Descrizione	Quando usarlo
Attendere il rollback	Il revert del portale ripristina il comportamento normale senza attività lato tenant.	Scenario standard: non urge creare account con eccezioni alla prima login.
Creare o gestire utenti via PowerShell	Uso dei cmdlet Microsoft Graph o, se presenti, dei moduli legacy per impostare la proprietà desiderata.	Urgenze o run-book che richiedono di disabilitare il cambio password al primo accesso.
Reset manuale post‑creazione	Alcuni amministratori segnalano che il reset della password seguito da un primo accesso può aggirare l’obbligo successivo.	Workaround tampone se non è possibile usare PowerShell; esito da verificare caso per caso.

Procedura con Microsoft Graph PowerShell

Questa è la via consigliata perché moderna, supportata e coerente con Microsoft Entra ID. Richiede permessi adeguati e l’installazione del modulo.

Prerequisiti

Account con privilegi per creare o aggiornare utenti;
Modulo Microsoft.Graph aggiornato;
Consenso per lo scope User.ReadWrite.All o equivalente.

Installazione e connessione

# Esegui in una console PowerShell con privilegi da amministratore del dispositivo
Install-Module Microsoft.Graph -Scope CurrentUser

Avvia la sessione Graph con gli scope minimi necessari

Connect-MgGraph -Scopes "User.ReadWrite.All"

Verifica le informazioni del profilo e del tenant

Get-MgContext

Creazione di un nuovo utente senza cambio password al primo accesso

# Dati di esempio
$upn          = "d.garcia@contoso.com"
$displayName  = "Diego Garcia"
$mailNick     = "dgarcia"
$usageLoc     = "IT"     # Due lettere ISO, es. IT, US, DE...
$tempPwd      = "P@ssw0rd!A123456"  # Usa una password temporanea forte

New-MgUser `  -AccountEnabled:$true`
-DisplayName $displayName `  -MailNickname $mailNick`
-UserPrincipalName $upn `  -UsageLocation $usageLoc`
-PasswordProfile @{ Password = $tempPwd; ForceChangePasswordNextSignIn = $false }

La proprietà chiave è PasswordProfile.ForceChangePasswordNextSignIn = $false, che disattiva l’obbligo al primo accesso indipendentemente dallo stato del portale.

Modifica di un utente esistente

# Disattiva l'obbligo al prossimo accesso per un utente già creato
$upn = "d.garcia@contoso.com"
Update-MgUser -UserId $upn -PasswordProfile @{ ForceChangePasswordNextSignIn = $false }

Se il portale dovesse continuare a segnalare l’obbligo, esegui un reset guidato impostando una nuova password temporanea e nel medesimo comando specifica la proprietà a $false:

$newTempPwd = "N0vaP@ss!2024"
Update-MgUser -UserId $upn -PasswordProfile @{ Password = $newTempPwd; ForceChangePasswordNextSignIn = $false }

Alternative con moduli legacy

Qualora il tuo ambiente utilizzi ancora i moduli storici, puoi ricorrere a questi comandi. Verifica però gli standard interni: molte organizzazioni hanno già migrato al Graph SDK.

Modulo AzureAD

# Connessione
Connect-AzureAD

Creazione utente

$pwd = "P@ssTemp0ra!e"
New-AzureADUser `  -DisplayName "Diego Garcia"`
-MailNickName "dgarcia" `  -UserPrincipalName "d.garcia@contoso.com"`
-AccountEnabled $true `
-PasswordProfile @{ Password = $pwd; ForceChangePasswordNextSignIn = $false }

Aggiornamento utente esistente con reset opzionale

Set-AzureADUserPassword `  -ObjectId (Get-AzureADUser -SearchString "d.garcia@contoso.com").ObjectId`
-Password "N0vaP@ss!2024" `
-ForceChangePasswordNextLogin $false

Modulo MSOnline

# Connessione
Connect-MsolService

Creazione utente

New-MsolUser `  -UserPrincipalName "d.garcia@contoso.com"`
-DisplayName "Diego Garcia" `  -FirstName "Diego"`
-LastName "Garcia" `  -UsageLocation "IT"`
-Password "P@ssw0rd!A123456" `
-ForceChangePassword $false

Reset per un utente esistente

Set-MsolUserPassword `  -UserPrincipalName "d.garcia@contoso.com"`
-NewPassword "N0vaP@ss!2024" `
-ForceChangePassword $false

Queste operazioni bypassano la limitazione del portale perché agiscono direttamente sulle API sottostanti.

Reset manuale post‑creazione

Se non puoi usare PowerShell in tempi rapidi, alcuni amministratori hanno riportato che questa sequenza può evitare l’obbligo di cambio al logon successivo:

crea l’utente dal portale, accettando temporaneamente l’obbligo al primo accesso;
subito dopo esegui un reset password dall’area utenti, impostando la nuova password desiderata;
effettua un primo accesso controllato (tu o l’utente) per validare le credenziali;
verifica che ai successivi accessi non sia più richiesto il cambio.

Trattandosi di un workaround non garantito, testalo su un account pilota prima di applicarlo in produzione.

Consigli operativi

Monitorare lo stato: segui la voce MO897396 in Health ► Service Health fino a “Service restored”.
Documentare le eccezioni: per account di servizio o casi speciali annota il razionale, i comandi usati e l’owner.
Verificare dopo il ripristino: crea un account di test per accertare che la casella del portale sia di nuovo modificabile.
Allineare la comunicazione: informa gli utenti se il cambio password al primo accesso non sarà più richiesto, per evitare ticket inutili.

Checklist di controllo qualità

la creazione via portale mostra il toggle attivo e cliccabile;
la creazione via cmdlet imposta correttamente ForceChangePasswordNextSignIn secondo policy;
gli account di servizio non subiscono blocchi inattesi in job o connettori;
gli audit delle attività includono chi ha eseguito modifiche e su quali oggetti;
la documentazione interna è stata aggiornata per riflettere la finestra di incidente e i workaround usati.

Buone pratiche di sicurezza durante i workaround

usa sempre password temporanee robuste e un canale sicuro per condividerle;
pretendi la protezione con autenticazione a più fattori per gli account interattivi;
per gli account non interattivi preferisci credenziali applicative o certificati dove possibile;
revoca le credenziali temporanee appena terminato il collaudo;
evita di salvare password in chiaro in script e repository; quando indispensabile, ricorri a segreti protetti o vault.

Domande frequenti

È una nuova policy di sicurezza obbligatoria

No. È un bug del portale, non un cambiamento di policy a livello di piattaforma. L’incidente è tracciato con l’ID MO897396 e il ripristino è stato pianificato a breve distanza dalla conferma.

Riguarda anche ambienti ibridi

Sì. Il comportamento è stato osservato sia in tenant cloud‑only sia in scenari ibridi. Non è legato ad Azure AD Connect né a permessi di Active Directory locali.

Da dove verifico lo stato

Direttamente nel tenant, sezione Health ► Service Health, filtrando gli advisory attivi. Quando lo stato passa a “Service restored”, il portale torna al comportamento atteso.

Posso creare utenti senza obbligo di cambio password durante l’incidente

Sì, via PowerShell con Microsoft Graph o moduli compatibili, impostando la proprietà ForceChangePasswordNextSignIn a $false come mostrato negli esempi.

Il portale continua a mostrare la casella grigia anche dopo l’annuncio di ripristino

Effettua un hard refresh del browser, svuota la cache delle applicazioni web e prova da una finestra in incognito o da un altro profilo amministrativo. Se persiste, crea un account di test via PowerShell per confermare che il back‑end sia sano e che si tratti solo di un artefatto di interfaccia.

Come gestisco gli account di servizio

Pianifica una revisione: ove non sia possibile usare identità applicative, imposta esplicitamente $false per il flag di cambio password al primo accesso e registra l’eccezione nei controlli di sicurezza.

Esempi pronti da riutilizzare

Creazione in blocco con Microsoft Graph

# CSV con colonne: UserPrincipalName,DisplayName,MailNickname,UsageLocation,TempPassword
Esempio: d.garcia@contoso.com,Diego Garcia,dgarcia,IT,P@ssw0rd!A123456

$path = "C:\temp\new-users.csv"
$users = Import-Csv $path
Connect-MgGraph -Scopes "User.ReadWrite.All"

foreach ($u in $users) {
try {
New-MgUser `      -AccountEnabled:$true`
-DisplayName $u.DisplayName `      -MailNickname $u.MailNickname`
-UserPrincipalName $u.UserPrincipalName `      -UsageLocation $u.UsageLocation`
-PasswordProfile @{ Password = $u.TempPassword; ForceChangePasswordNextSignIn = $false }
```
Write-Host "Creato: $($u.UserPrincipalName)"
```
}
catch {
Write-Warning "Errore su $($u.UserPrincipalName): $($_.Exception.Message)"
}
}

Validazione tecnica dopo il rollback

# Crea un utente di prova dal portale verificando che il toggle sia nuovamente modificabile.
In parallelo, crea un utente via Graph e verifica l'accesso senza prompt di cambio password.

$upnTest = "[test.toggle@contoso.com](mailto:test.toggle@contoso.com)"

Se necessario, disabilita il flag per essere certo del comportamento:

Update-MgUser -UserId $upnTest -PasswordProfile @{ ForceChangePasswordNextSignIn = $false }

Effettua un accesso di prova e registra l'esito in un file di controllo

"$(Get-Date -Format s) - Verifica completata per $upnTest" | Out-File C:\temp\m365-admincenter-verify.log -Append

Note per audit e compliance

conserva i log dei comandi eseguiti e gli artefatti di approvazione;
aggiorna i run‑book del team per includere sia il caso standard sia la gestione in incidente;
archivia uno post‑mortem con l’ID dell’incidente, le date chiave e i controlli eseguiti;
se sono state sospese temporaneamente policy o controlli, documenta motivazione e tempi di ripristino.

Messaggio suggerito da inoltrare agli utenti

Stiamo effettuando un’attività di manutenzione legata alla gestione delle password. In caso di richiesta inaspettata di cambio password al primo accesso, seguite le istruzioni a schermo. Se non vi viene più richiesto, è tutto regolare. Per dubbi, contattate il supporto interno.

Conclusioni

L’impostazione bloccata del cambio password al primo accesso nel Microsoft 365 Admin Center è l’effetto di un malfunzionamento dell’interfaccia, non di una variazione delle policy di sicurezza. Con l’avanzare del rollback l’esperienza nel portale torna al comportamento atteso. Nel frattempo, l’approccio più solido è utilizzare Microsoft Graph PowerShell per creare e gestire gli utenti impostando esplicitamente la proprietà ForceChangePasswordNextSignIn. Mantieni la visibilità sullo stato dall’area di salute del tenant, documenta eventuali eccezioni e, una volta chiuso l’incidente, esegui una verifica end‑to‑end su un account di test per convalidare il ripristino completo.

Riepilogo pratico

il flag grigio è un bug di portale tracciato con l’ID MO897396;
il rollback è stato avviato e non richiede azioni strutturali lato tenant;
per urgenze, crea o modifica gli utenti via PowerShell con Microsoft Graph impostando ForceChangePasswordNextSignIn = $false;
eventualmente prova il reset manuale come soluzione tampone;
verifica lo stato in Health ► Service Health e aggiorna i run‑book.