Come impostare la scadenza della password su Microsoft e Windows

La scadenza della password non si imposta “su Windows” in modo unico: cambia in base al tipo di account, al dominio e al servizio Microsoft coinvolto. Se stai lavorando con un PC standalone, con un computer in Active Directory, oppure con utenti Microsoft 365/Azure AD, la logica è diversa e conviene scegliere il punto di controllo corretto subito. Forzare una policy nel posto sbagliato porta solo a confusione: l’utente continua a non vedere la scadenza, oppure la password viene trattata come non scadibile anche se pensavi il contrario.

La regola pratica è semplice: account locali si gestiscono sul singolo sistema o via policy locali; account di dominio si governano da Active Directory o da una Group Policy; account cloud dipendono dalle impostazioni di sicurezza del tenant Microsoft 365 e dalle eventuali regole di autenticazione moderne. Prima di toccare qualsiasi impostazione, chiarisci quale identità stai controllando. È il punto che evita il 90% dei falsi allarmi in assistenza.

Account locali Windows: scadenza password sul singolo PC

Su un computer Windows non collegato a dominio, la scadenza password vale per gli utenti locali. In questo caso puoi intervenire dalla gestione utenti locali o da criteri di sicurezza locali. Il comportamento dipende anche dall’edizione di Windows: alcune funzioni amministrative sono più complete su Pro ed Enterprise rispetto a Home.

Il controllo più diretto è verificare se la password dell’utente locale è soggetta a scadenza. In molti scenari l’impostazione viene ereditata dal criterio “maximum password age”, cioè il numero massimo di giorni prima della scadenza. Se il valore è a zero o disabilitato, la password non scade. Se invece vuoi imporre una rotazione, devi definire un intervallo coerente con la policy aziendale.

Per controllare rapidamente lo stato da riga di comando puoi usare questo comando:

net accounts

Tra i dati restituiti cerca Maximum password age. Se vedi Unlimited o un valore non coerente con la tua policy, il problema è lì. Questo controllo è utile perché ti dice subito se la macchina sta applicando una scadenza o no, senza aprire più console del necessario.

Per modificare la policy locale in ambiente Pro o Enterprise puoi passare da Local Security Policy oppure usare la gestione avanzata. Il percorso classico è: secpol.msc → Account Policies → Password Policy → Maximum password age. Da lì imposti il numero di giorni desiderato. È la strada più pulita se il PC non è gestito centralmente.

Se vuoi verificare che la policy sia stata recepita, un secondo controllo utile è:

gpupdate /force

Dopo l’aggiornamento, riesegui net accounts e confronta il valore. Se non cambia, è probabile che la policy locale venga sovrascritta da criteri di dominio o da una gestione MDM, nel qual caso il PC non è davvero “standalone” come sembrava.

Active Directory: la scadenza va definita a livello di dominio

Se l’utente è in dominio, la scadenza password si imposta quasi sempre in Active Directory, non sul singolo client. Qui la differenza importante è tra la policy del dominio e le eccezioni per singoli utenti. La policy base stabilisce la durata massima della password, mentre eventuali eccezioni si gestiscono con attributi specifici dell’account o con policy granulari.

Il controllo iniziale è capire quale policy sta effettivamente governando l’utente. In ambiente AD, il comando più utile è questo:

net accounts /domain

Il risultato mostra i parametri di password del dominio, inclusa la durata massima. Se il valore non coincide con quello atteso, la correzione non va fatta sul PC dell’utente: va fatta sul controller di dominio o nella Group Policy che applica il criterio.

Per un controllo più preciso su un utente specifico puoi verificare se l’account ha l’attributo che esclude la scadenza. In Active Directory Users and Computers, apri le proprietà dell’utente e controlla la scheda Account: l’opzione Password never expires è il classico punto che blocca la scadenza. Se è attiva, la password non andrà mai in scadenza anche se il dominio ha una policy aggressiva.

Se vuoi operare in modo più strutturato, usa PowerShell sul controller o da workstation con RSAT. Un controllo utile è:

Get-ADDefaultDomainPasswordPolicy

Il comando ti restituisce i parametri del dominio: durata massima, complessità, lunghezza minima e altri dettagli. È il modo migliore per capire se la policy è davvero quella desiderata o se esiste un override da cercare altrove.

Per gli ambienti più maturi, conviene usare Fine-Grained Password Policies quando servono eccezioni per gruppi diversi di utenti. È una soluzione più ordinata rispetto a escludere manualmente i singoli account. Un gruppo amministrativo può avere una durata diversa rispetto agli utenti standard senza dover aprire eccezioni individuali difficili da auditare.

Attenzione a un errore comune: cambiare la policy e aspettarsi un effetto immediato su tutti gli account. In realtà la scadenza si calcola in base all’età della password già impostata. Se la password è stata cambiata ieri, non scadrà domani solo perché hai abbassato il limite a 30 giorni. Per verificare quando un utente è entrato nel ciclo di scadenza, controlla la data dell’ultimo cambio password, non solo il criterio in vigore.

Microsoft 365 e Entra ID: quando la scadenza è nel cloud

Nel mondo Microsoft 365, la scadenza password non si gestisce come su un dominio classico. Dipende da Entra ID e da eventuali impostazioni legacy del tenant. In molti tenant moderni la scadenza password viene volutamente disattivata, perché Microsoft spinge verso MFA, password forte e protezioni contro il rischio reale, non verso il cambio forzato periodico come misura universale.

Se però la tua organizzazione vuole ancora imporre una scadenza, devi verificare la configurazione del tenant. In alcuni casi la gestione passa da Microsoft Entra admin center, in altri da impostazioni legacy di Azure AD o da policy ibride sincronizzate con Active Directory locale. Il punto non è “dove cliccare”, ma capire quale autorità sta imponendo la regola.

In un tenant cloud puro, il comportamento tipico si controlla nelle impostazioni di autenticazione e password. Se hai sincronizzazione ibrida con AD Connect, la password potrebbe essere ancora governata dal dominio locale, quindi la scadenza impostata in cloud non avrà effetto sull’utente sincronizzato. Questo è uno dei casi in cui il supporto riceve ticket apparentemente contraddittori: in portale la policy sembra corretta, ma l’utente continua a vedere una scadenza diversa perché l’origine dell’identità è altrove.

Per evitare ambiguità, verifica sempre il tipo di account: cloud-only o synced. Se l’utente è sincronizzato da AD locale, la correzione quasi sempre va fatta nel dominio on-premises. Se invece è cloud-only, puoi agire direttamente sul tenant. Un controllo pratico è cercare l’utente nel portale Entra e osservare il campo relativo alla sorgente dell’identità.

Se stai usando il portale Microsoft 365, la verifica più utile non è solo la policy password, ma anche lo stato di Security defaults, MFA e eventuali Conditional Access. In certe organizzazioni la scadenza password è stata abbandonata proprio perché MFA e risk-based sign-in rendono più sensato lavorare sulla qualità dell’autenticazione invece che sul reset periodico. Non è una scorciatoia: è una scelta di modello.

Quando l’utente dice “mi chiede di cambiare password” ma la policy sembra giusta

Qui bisogna distinguere tra scadenza vera e richiesta di cambio password per altri motivi. Windows e Microsoft possono chiedere il cambio per password temporanea, primo accesso, reset amministrativo, compromissione sospetta, policy di compliance o semplice scadenza. Il messaggio a schermo non basta: serve il contesto dell’account.

Se l’utente riceve una richiesta inattesa, controlla prima gli eventi di autenticazione o i log del servizio di identità. In ambiente locale puoi partire dall’Event Viewer; in dominio, dai log di sicurezza del controller; in cloud, dai sign-in logs del tenant. L’obiettivo è vedere se il trigger è una scadenza programmata oppure un evento di sicurezza diverso.

Un caso frequente è la password impostata come non scadibile per un account tecnico, ma poi forzata a cambiare dopo un reset manuale. L’attributo “never expires” non impedisce il cambio se un amministratore ha fatto un reset e l’account è stato marcato per cambio al primo login. Anche qui la distinzione è importante: reset non è la stessa cosa di expiration.

Scelta operativa: dove intervenire davvero

La scelta corretta dipende da tre domande. Primo: l’account è locale, di dominio o cloud? Secondo: esiste una policy superiore che sovrascrive quella che vuoi cambiare? Terzo: vuoi imporre scadenza a tutti o solo a un gruppo? Se non rispondi a queste tre domande prima di modificare qualcosa, rischi di cambiare il punto sbagliato e perdere tempo nel troubleshooting.

Per un ambiente piccolo, un PC standalone e pochi utenti locali, la gestione dal sistema è sufficiente. Per un ufficio con dominio, la policy va centralizzata in AD e documentata. Per Microsoft 365, la scadenza password va trattata come una decisione di identità e sicurezza del tenant, non come una proprietà del singolo PC. Questa distinzione evita configurazioni incoerenti tra endpoint e identità.

Se devi fare una modifica, applica sempre questo schema: verifica lo stato attuale, cambia una sola variabile, conferma l’effetto, poi estendi il cambiamento. Per esempio, prima controlla net accounts o la policy del dominio, poi modifica il valore massimo, quindi verifica con un utente di test. È un approccio più solido rispetto al classico “provo a cambiare tutto e vedo cosa succede”.

Verifica finale e punti di attenzione

Dopo aver impostato la scadenza, verifica almeno tre cose: il valore di policy, l’applicazione sull’account giusto e il comportamento al login successivo. Su Windows locale puoi ricontrollare con net accounts; in dominio con net accounts /domain e con le proprietà dell’utente; in cloud con il portale Entra e i log di accesso. Se uno di questi tre passaggi non torna, la configurazione non è ancora affidabile.

Metti anche in conto l’impatto operativo. Una scadenza troppo breve produce ticket, reset e interruzioni evitabili. Una scadenza assente su account esposti aumenta il rischio se non hai MFA e controlli di accesso adeguati. La scelta giusta non è “attivarla sempre” o “disattivarla sempre”: è allinearla al modello di sicurezza e alla maturità operativa dell’ambiente.

Se ti serve un criterio pratico, questo funziona bene nella maggior parte dei casi: account utente standard con MFA attiva e protezioni moderne possono anche non avere una scadenza rigida; account amministrativi, tecnici o in ambienti legacy vanno invece trattati con più attenzione e con una policy esplicita, documentata e verificabile. In ogni caso, la regola non deve vivere nella memoria di chi ha configurato il sistema anni fa: deve stare in una policy che puoi controllare oggi.