Entra ID + AD ibrido: scadenza password a 180 giorni solo per un gruppo (popup M365, AAD Connect, FGPP)

Vuoi imporre la scadenza password a 180 giorni solo a un gruppo selezionato di utenti in un tenant ibrido (Microsoft Entra ID + AD on‑prem), lasciando tutti gli altri invariati? In questo articolo trovi il perché tecnico, tre approcci pratici (con passaggi passo‑passo), script pronti all’uso e una checklist di verifica.

Indice

Scenario

Ambiente

Tenant Microsoft Entra sincronizzato con AAD Connect in modalità Password Hash Sync (PHS).
Dispositivi Entra‑joined e gestiti da Intune; Active Directory locale esiste solo per motivi storici.
Obiettivo: visualizzare il pop‑up di Microsoft 365 che richiede il cambio password ogni 180 giorni, ma solo per un sotto‑insieme di utenti; per tutti gli altri niente cambia.

Perché succede: i meccanismi dietro la scadenza

In un ambiente ibrido con PHS, le password degli utenti “sincronizzati” vengono salvate in Entra ID come hash; per impostazione predefinita, il flag cloud PasswordPolicies = DisablePasswordExpiration rimane attivo sui synced‑users, quindi anche se in AD locale la password è scaduta, in molti casi l’utente continua ad autenticarsi nel cloud. Questo spiega perché il classico prompt di Microsoft 365 non compare per loro.

Esiste la funzionalità EnforceCloudPasswordPolicyForPasswordSyncedUsers che, se abilitata a livello di tenant, rimuove quel flag e fa sì che sia Entra ID a gestire direttamente la scadenza per tutti gli utenti sincronizzati. Il punto è proprio questo: l’opzione è globale, non filtrabile per gruppo.

Al contrario, in Active Directory on‑prem puoi applicare Fine‑Grained Password Policies (FGPP) con MaxPasswordAge differenziato per utente o gruppo. Tuttavia, il prompt “da cloud” non è garantito: l’utente vedrà l’avviso solo se la sua sessione passa da risorse che interrogano il DC (VPN, RDP, file server, ecc.). Su device Entra‑joined l’esperienza può risultare disomogenea.

Cosa si può e non si può fare in Entra ID

Si può imporre la scadenza password dal cloud per utenti sincronizzati, ma solo in blocco (tenant‑wide) abilitando EnforceCloudPasswordPolicyForPasswordSyncedUsers.
Non si può applicare una “cloud password expiry” per gruppo direttamente in Entra ID.
Per gli utenti cloud‑only puoi giocare sia con la policy di dominio cloud sia con il flag per‑utente PasswordPolicies (es. DisablePasswordExpiration).
Le FGPP on‑prem sono l’unico modo nativo per avere una scadenza davvero granulare per singolo utente o gruppo.

Tre strategie reali (confronto rapido)

Approccio	Come si configura	Vantaggi	Limiti
A. Delegare ad AD on‑prem con FGPP	Creare un gruppo AD Pwd‑180d. In Active Directory Administrative Center → System > Password Settings Container → New > Password Settings: impostare `MaxPasswordAge = 180` giorni e associare il gruppo/utenti in Directly Associated. Mantenere EnforceCloudPasswordPolicyForPasswordSyncedUsers = `False` così il cloud non forza l’expiry per i synced‑users.	Granularità perfetta per utente/gruppo; nessun impatto sugli altri.	Il prompt di Microsoft 365 non è generato dal cloud; esperienza disomogenea su device Entra‑joined e servizi solo‑cloud.
B. Usare il cloud e separare i domini	Spostare o creare il sotto‑insieme su un managed domain dedicato (es. contoso‑180d.com). Impostare per quel dominio la validità password a 180 giorni. Abilitare EnforceCloudPasswordPolicyForPasswordSyncedUsers = `True` per far valere l’expiry cloud anche sui synced‑users.	Prompt cloud di Microsoft 365/Entra dopo 180 giorni, indipendente dal DC locale.	Serve un dominio aggiuntivo o conversione del dominio esistente; la policy resta per‑dominio, non per singolo utente.
C. Cloud‑only per il gruppo mirato	Escludere gli utenti target dalla sincronizzazione (filtering in AAD Connect per OU/attributi/regole). Impostare scadenza a 180 giorni sul tenant o sul dominio cloud. Per gli altri utenti sincronizzati, mantenere PasswordNeverExpires = `True` (`PasswordPolicies = DisablePasswordExpiration`).	Esperienza uniforme (solo popup cloud). Nessun legame con AD locale per il gruppo target.	Richiede ristrutturare la sincronizzazione o creare nuovi account; attenzione a risorse legacy dipendenti dal SID on‑prem.

Come scegliere

AD on‑prem ancora raggiungibile dai client (VPN sempre‑on, applicazioni legacy): Approccio A è il più rapido; crei una FGPP da 180 giorni per il gruppo target e non tocchi il resto.
Dispositivi quasi sempre internet‑only e servizi cloud‑first: passa al controllo cloud con Approccio B (se accetti di usare un dominio separato) oppure Approccio C (se preferisci rendere quel gruppo cloud‑only).
Valutazione di sicurezza: Microsoft sconsiglia la scadenza periodica “a tempo” a favore di MFA e passwordless (FIDO2/WHfB). Se proprio devi applicarla per compliance, automatizza e notifica bene agli utenti.

Guida passo‑passo – Approccio A (FGPP on‑prem)

Prerequisiti

AD DS funzionante; diritti per creare Password Settings Objects (PSO) nel Password Settings Container.
Client che talvolta interrogano il DC (es. VPN, risorse interne) se desideri che vedano il prompt on‑prem.

Creazione FGPP

# Creare la policy fine-grained a 180 giorni
New-ADFineGrainedPasswordPolicy `
  -Name "FGPP-180d" `
  -Precedence 100 `
  -MinPasswordLength 14 `
  -ComplexityEnabled $true `
  -LockoutDuration (New-TimeSpan -Minutes 15) `
  -LockoutObservationWindow (New-TimeSpan -Minutes 15) `
  -LockoutThreshold 10 `
  -MinPasswordAge (New-TimeSpan -Days 1) `
  -MaxPasswordAge (New-TimeSpan -Days 180)

Associare il gruppo di sicurezza "Pwd-180d"

Add-ADFineGrainedPasswordPolicySubject `  -Identity "FGPP-180d"`
-Subjects "CN=Pwd-180d,OU=SecurityGroups,DC=contoso,DC=com"

Nota: nelle FGPP, il numero di precedenza più basso vince. Assicurati che non ci siano altri PSO con precedenza minore che sovrascrivano la tua impostazione.

Verifica sul DC

# Verificare l'effettiva policy risultante per un utente
$u = Get-ADUser -Identity mario.rossi
Get-ADUserResultantPasswordPolicy -Identity $u

Controllo rapido della scadenza in giorni

(net user mario.rossi /domain) | findstr /I "Password expires"

Cosa vedrà l’utente

Quando la password supera i 180 giorni, l’utente riceve le notifiche di scadenza tipiche del mondo AD (logon on‑prem, accesso a risorse interne, ecc.). Non è garantito che compaia il pop‑up cloud di Microsoft 365 sui dispositivi Entra‑joined se non vi è interazione con AD locale.

Best practice

Comunica in anticipo la nuova finestra di scadenza per il gruppo target.
Monitora pwdLastSet e imposta avvisi (es. script schedulato che invia e‑mail quando mancano N giorni).
Valuta di abilitare Self‑Service Password Reset (SSPR) con Password writeback per offrire un’esperienza di cambio password coerente anche da remoto.

Guida passo‑passo – Approccio B (cloud con domini separati)

Prerequisiti

Possibilità di aggiungere e verificare un dominio gestito aggiuntivo nel tenant Microsoft 365.
Allineamento su impatti UPN/mailbox: cambiare dominio UPN può avere effetti su accessi SSO/applicazioni.
Disponibilità ad abilitare EnforceCloudPasswordPolicyForPasswordSyncedUsers a livello tenant.

Passi operativi

Creazione del dominio “dedicato” (es. contoso‑180d.com) e verifica nel tenant.
Spostamento o creazione degli account target usando quel suffisso UPN (sincronizzati o cloud‑only a seconda del caso).
Impostare la policy di scadenza a 180 giorni per il dominio.
Abilitare la funzionalità tenant‑wide che fa valere le policy cloud anche per gli utenti sincronizzati.

Comandi utili

# ATTENZIONE: impatta tutti i synced-users (tenant-wide)
Abilita l'applicazione della policy cloud di scadenza password
Set-MsolDirSyncFeature `
  -Feature EnforceCloudPasswordPolicyForPasswordSyncedUsers `
  -Enable $true

Impostare per-dominio la validità (modulo MSOnline - legacy)

Esempio: 180 giorni per contoso-180d.com

Set-MsolPasswordPolicy `  -DomainName "contoso-180d.com"`
-ValidityPeriod 180 `
-NotificationDays 14

Nota operativa: con questa strategia, tutti i synced‑users diventano soggetti all’expiry cloud; la granulosità la ottieni isolandoli su un dominio dedicato. Per gli altri domini potresti impostare ValidityPeriod differente o mantenere PasswordPolicies = DisablePasswordExpiration sui relativi utenti (se cloud‑only).

Esperienza utente

Il pop‑up cloud di Microsoft 365/Entra verrà mostrato quando l’utente supera i 180 giorni. Se utilizzi SSPR con Password writeback, anche gli utenti sincronizzati potranno cambiare la password direttamente dal prompt cloud e l’aggiornamento verrà scritto in AD on‑prem.

Pitfall da evitare

Non abilitare EnforceCloudPasswordPolicyForPasswordSyncedUsers senza aver prima comunicato e pianificato l’impatto su tutti i synced‑users.
Verifica che applicazioni e automazioni non dipendano dal vecchio UPN.
Separa chiaramente gli account di servizio e imposta per loro PasswordPolicies = DisablePasswordExpiration (o esenzioni concordate) per evitare outage.

Guida passo‑passo – Approccio C (cloud‑only per il gruppo mirato)

Quando ha senso

Hai utenti che vivono solo nel cloud e non dipendono da SID on‑prem, risorse legacy o Kerberos/NTLM? Rendili cloud‑only, imposta la scadenza password a 180 giorni e mantieni invariate le identità sincronizzate.

Passi operativi

Esclusione dalla sincronizzazione in AAD Connect
- OU filtering: sposta gli utenti in un’OU esclusa dal scope.
- Attribute filtering: usa un attributo (es. extensionAttribute10=CloudOnly) e crea una regola di esclusione.
- Group‑based filtering (se applicabile): limiti la sync agli utenti in un gruppo specifico.
Confermare in Entra ID che gli utenti risultino cloud‑only (non più sincronizzati).
Impostare scadenza a 180 giorni sul tenant o sul dominio cloud usato dagli utenti target.
Per gli altri (sincronizzati), lascia PasswordPolicies = DisablePasswordExpiration (comportamento predefinito) e non abilitare EnforceCloudPasswordPolicyForPasswordSyncedUsers.

Comandi utili (Microsoft Graph PowerShell)

# Installare e connettersi (se necessario)
Install-Module Microsoft.Graph -Scope CurrentUser
Connect-MgGraph -Scopes "User.ReadWrite.All","Directory.ReadWrite.All"

Verificare quali utenti hanno la password "never expires" abilitata

Get-MgUser -All `  | Where-Object { $_.PasswordPolicies -match "DisablePasswordExpiration" }`
| Select-Object Id, UserPrincipalName, PasswordPolicies

Abilitare/Disabilitare l'expiry per un utente cloud-only (per-utente)

Update-MgUser -UserId "[mario.rossi@contoso-180d.com](mailto:mario.rossi@contoso-180d.com)" `
-PasswordPolicies "None"   # None = soggetto alla policy di dominio/tenant

oppure

Update-MgUser -UserId "[svcapp@contoso.com](mailto:svcapp@contoso.com)" `
-PasswordPolicies "DisablePasswordExpiration"  # esenzione per account di servizio

Tip: se intendi applicare l’expiry a tutti i cloud‑only di un dominio specifico, imposta la validità a 180 giorni a livello di dominio e poi esenta solo i pochi che non devono scadere (per‑utente).

Requisiti critici per un’esperienza fluida

SSPR + Password writeback abilitati (se vuoi che i synced‑users cambino la password dal prompt cloud e la modifica venga scritta in AD on‑prem).
Licensing adeguato per SSPR (incluso in Microsoft Entra ID P1 o in piani equivalenti).
Canali di notifica agli utenti: comunicalo in anticipo, specifica la finestra (180 giorni), fornisci guida “come cambiare password”.
Break‑glass accounts (almeno due, cloud‑only) con Password never expires, MFA forte e monitoraggio.

Piano di roll‑out sicuro

Inventario degli utenti target e loro dipendenze (app legacy, job schedulati, mappe drive, ecc.).
Ambiente pilota con 5‑10 utenti rappresentativi; verifica:
- Prompt di scadenza come atteso (cloud vs on‑prem).
- Capacità di cambio password end‑to‑end (SSPR/writeback se coinvolge AD).
- Impatto su tokens (access/refresh) e su client M365 (Outlook, Teams, Office).
Automazioni:
- Script che impostano/validano PasswordPolicies per‑utente.
- Report giornaliero di pwdLastSet (on‑prem) o di sign‑in errors (cloud) per AADSTS50055 (“password expired”).
Comunicazione agli utenti con FAQ e orari di manutenzione.
Go‑live graduale a gruppi, partendo dai team meno critici.
Backout plan: come rimuovere la policy (FGPP o dominio), ripristinare PasswordPolicies, disabilitare EnforceCloudPasswordPolicyForPasswordSyncedUsers se necessario.

Domande frequenti

Possiamo impostare l’expiry in Entra ID per un singolo gruppo sincronizzato?

No. L’impostazione EnforceCloudPasswordPolicyForPasswordSyncedUsers è tenant‑wide. Per la granularità per‑gruppo devi usare FGPP on‑prem (Approccio A) oppure isolare gli utenti in un dominio dedicato (Approccio B) o renderli cloud‑only (Approccio C).

Il prompt di Microsoft 365 appare sempre?

Appare quando la scadenza è gestita dal cloud (Approccio B o C). Se la scadenza è gestita solo on‑prem (Approccio A), l’utente potrebbe non vedere alcun pop‑up “cloud” e continuare ad autenticarsi ai servizi Microsoft 365 fino a quando la sessione non richiede un nuovo token o non interagisce con sistemi che consultano il DC.

Serve SSPR per cambiare password quando scade?

Per gli utenti cloud‑only, no: la modifica avviene nel cloud. Per gli utenti sincronizzati, sì se vuoi permettere il cambio password dal prompt cloud e scrivere la modifica in AD on‑prem: abilita SSPR + Password writeback in AAD Connect.

Che impatto ha sui token e sulle app?

Quando la password scade nel cloud, i token in corso di validità possono rimanere validi fino alla naturale scadenza; al prossimo reauth l’utente dovrà cambiare la password. Alcune app (Outlook, Teams, Office) potrebbero richiedere accesso interattivo.

Possiamo combinare approcci?

Sì. Esempio comune: FGPP per qualche account legacy che usa risorse on‑prem, e dominio separato + expiry cloud per un gruppo pilota cloud‑first. L’importante è documentare bene chi ricade in quale meccanismo.

Checklist operativa

Definizione gruppo target (statico o dinamico) e relativa governance.
Scelta approccio (A/B/C) in base alla connettività dei client e ai vincoli applicativi.
SSPR + writeback abilitati se coinvolgi utenti sincronizzati con controllo cloud.
Implementazione (FGPP o dominio/tenant policy o esclusione da sync) con script versionati.
Verifiche:
- On‑prem: Resultant Password Policy e pwdLastSet.
- Cloud: PasswordPolicies per‑utente, dominio con ValidityPeriod=180, stato di EnforceCloudPasswordPolicyForPasswordSyncedUsers.
Report periodico utenti a rischio scadenza nei 14 giorni successivi.
Comunicazione e supporto con guida “cambio password” e canale rapido per sblocchi.

Script pronti all’uso (estratto)

Abilitare la feature tenant‑wide (usare con cautela)

# Richiede modulo MSOnline (legacy)
Set-MsolDirSyncFeature `
  -Feature EnforceCloudPasswordPolicyForPasswordSyncedUsers `
  -Enable $true

Creare una FGPP da AD PowerShell

New-ADFineGrainedPasswordPolicy `
  -Name "FGPP-180d" `
  -MaxPasswordAge (New-TimeSpan -Days 180) `
  -MinPasswordAge (New-TimeSpan -Days 1) `
  -MinPasswordLength 14 `
  -ComplexityEnabled $true `
  -Precedence 100

Add-ADFineGrainedPasswordPolicySubject `  -Identity "FGPP-180d"`
-Subjects "CN=Pwd-180d,OU=SecurityGroups,DC=contoso,DC=com"

Elencare utenti con password “never expires” in Entra ID

Connect-MgGraph -Scopes "User.Read.All","Directory.Read.All"
Get-MgUser -All `
  | Where-Object { $_.PasswordPolicies -match "DisablePasswordExpiration" } `
  | Select-Object UserPrincipalName, PasswordPolicies

Impostare/annullare l’esenzione per singoli utenti (cloud‑only)

# Sottoporre l'utente alla policy di dominio/tenant (quindi scadenza)
Update-MgUser -UserId "utente@contoso-180d.com" -PasswordPolicies "None"

Esentare un account di servizio dalla scadenza

Update-MgUser -UserId "[svcbackup@contoso.com](mailto:svcbackup@contoso.com)" -PasswordPolicies "DisablePasswordExpiration"

Esempio di report “password in scadenza” (on‑prem)

$thresholdDays = 15
$today = Get-Date
Get-ADUser -Filter * -Properties msDS-ResultantPSO, pwdLastSet, DisplayName |
  ForEach-Object {
    $pwdSet = [datetime]::FromFileTime($_.pwdLastSet)
    $pso = $_.'msDS-ResultantPSO'
    # Default: 42 giorni se nulla, ma qui assumiamo FGPP-180d
    $maxAge = if ($pso) { 180 } else { 42 }
    $expires = $pwdSet.AddDays($maxAge)
    if (($expires - $today).Days -le $thresholdDays) {
      [pscustomobject]@{
        User              = $_.DisplayName
        UPN               = $_.UserPrincipalName
        PasswordSet       = $pwdSet
        PasswordExpires   = $expires
        DaysToExpire      = ($expires - $today).Days
        ResultantPolicy   = $pso
      }
    }
  } | Sort-Object DaysToExpire | Format-Table -AutoSize

Confronto approfondito: impatti, rischi, mitigazioni

Area	Approccio A (FGPP)	Approccio B (Domini separati)	Approccio C (Cloud‑only)
Esperienza utente	Avvisi “on‑prem”; possibile assenza del pop‑up M365.	Prompt cloud coerente.	Prompt cloud coerente.
Granularità	Per utente/gruppo, altissima.	Per dominio; serve separare i target.	Per utente (via flag) o per dominio cloud.
Impatto su altri utenti	Nullo.	Potenziale se si abilita enforcement tenant‑wide senza isolamento adeguato.	Nullo sui synced‑users (se enforcement disabilitato).
Dipendenza da AD on‑prem	Necessaria.	Non necessaria per il prompt; consigliato writeback.	Assente per il gruppo target.
Complessità di progetto	Bassa‑media.	Media‑alta (gestione domini/UPN).	Media (ristrutturazione sync, revisione accessi legacy).
Rischi principali	Esperienza non uniforme su device cloud‑first.	Impatto globale sui synced‑users; cambio UPN.	Perdita accesso a risorse che richiedono SID on‑prem.

Consiglio pratico (in una riga)

Vuoi il pop‑up cloud per un sotto‑insieme di utenti su dispositivi Internet‑only? Scegli B (dominio dedicato) o C (cloud‑only). Hai ancora dipendenze on‑prem diffuse? Vai con A (FGPP) e lascia invariato il resto.

In sintesi

L’unico modo realmente granulare per impostare la scadenza a 180 giorni “per gruppo” in un ambiente ibrido resta la Fine‑Grained Password Policy in AD DS. Se però desideri che il promemoria sia generato dal cloud, devi spostare gli account su un dominio dedicato con la policy desiderata o renderli cloud‑only. Entra ID applica l’expiry in blocco ai synced‑users: non è filtrabile per gruppo.

Ultimo ma importante: valuta seriamente se la scadenza periodica sia ancora la scelta migliore. In molti casi MFA forte, protezioni del rischio e passwordless migliorano sicurezza ed esperienza più di una rotazione calendarizzata.

Modelli di comunicazione agli utenti (riutilizzabili)

Oggetto: Nuova policy aziendale: cambio password ogni 180 giorni

Ciao ,
dal  la tua password aziendale scadrà ogni 180 giorni.
Riceverai un promemoria quando mancano 14 giorni alla scadenza e potrai cambiarla direttamente dal prompt di accesso.
Se usi app legacy o hai dubbi, contatta il Service Desk.

Grazie,
IT

Playbook Service Desk

Errore “password scaduta” su utenti sincronizzati: verificare SSPR + writeback attivi.
App legacy che non accettano la nuova password: controllare policy di complessità.
Account bloccato dopo rotazione: sbloccare in AD (on‑prem) o da Entra (cloud‑only) secondo il modello adottato.

Con questo, hai tutto il necessario per disegnare, implementare e governare una scadenza password a 180 giorni mirata solo a chi ti serve, senza effetti collaterali sul resto dell’organizzazione.