Protezione password Entra ID: elenchi e scadenza

Che cos’è la protezione password Entra ID?

La protezione password Entra ID valuta le nuove password rispetto ai termini vietati nell’elenco globale di Microsoft e, quando configurato, nell’elenco personalizzato dell’organizzazione. La verifica operativa pone tre domande distinte: i termini specifici dell’organizzazione sono coperti, le modifiche locali vengono effettivamente bloccate e la scadenza delle password impone ancora cambiamenti periodici?

Microsoft documenta che l’elenco globale cloud è automatico e non può essere disabilitato. L’assenza di un elenco personalizzato non significa quindi che il tenant non abbia alcuna protezione password. Significa che l’organizzazione non ha aggiunto il proprio vocabolario alla base di protezione. La convalida avviene durante le modifiche e le reimpostazioni delle password. Microsoft Learn: concetti della protezione password.

Considera questa verifica del controllo insieme al più ampio audit di sicurezza Microsoft Entra ID, che spiega come verificare i controlli di accesso applicabili, i ruoli privilegiati, l’attendibilità delle applicazioni e le identità esterne. Un criterio password da solo non risponde a queste domande più ampie.

Come funziona: perché l’elenco globale non basta

Microsoft costruisce il proprio elenco globale dalla telemetria di sicurezza Entra. L’elenco personalizzato aggiunge termini locali, come marchi, prodotti, sedi centrali e abbreviazioni interne. I due elenchi lavorano insieme; l’elenco personalizzato non sostituisce la base globale. Microsoft Learn: password vietate personalizzate.

Non presumere che ogni password contenente un termine nell’elenco debba essere rifiutata. L’algoritmo di valutazione normalizza l’input, verifica le varianti e assegna un punteggio alla password risultante; una password sufficientemente robusta può contenere un termine vietato ed essere comunque accettata. Leggi l’algoritmo di valutazione documentato prima di progettare i test di convalida.

Questa distinzione cambia il modo di costruire un elenco personalizzato utile. Esamina il vocabolario dell’organizzazione invece di importare un’enorme raccolta di password complete. Verifica se sono rappresentati i marchi attuali, i nomi delle aziende acquisite, le famiglie di prodotti e le abbreviazioni significative a livello locale. Collega i casi di test ai termini configurati, in modo da poter indagare un rifiuto invece di darlo semplicemente per scontato.

L’articolo sul password spraying spiega l’attacco: un piccolo insieme di tentativi distribuiti su molti account. Questa guida esamina la configurazione che riduce le scelte di password prevedibili prima che arrivino quei tentativi. Non considera un rilievo sul criterio password come prova che si sia verificato un password spraying.

La trappola della scadenza

Le raccomandazioni Microsoft sui criteri password sconsigliano la scadenza periodica per gli account esclusivamente cloud e raccomandano password che non scadono. Le stesse indicazioni sottolineano l’unicità delle password, la registrazione MFA e la protezione delle identità. La rimozione della scadenza programmata va accompagnata da questi controlli; non è un motivo per ignorare una sospetta compromissione.

Il rilievo controintuitivo è la scadenza abilitata, anziché la scadenza disabilitata. Esamina perché esiste un obbligo di modifica basato sull’età, a quale popolazione di identità si applica e se un requisito vincolante ne impedisce la rimozione. Mantieni ogni eccezione di questo tipo separata dalla base cloud raccomandata. Non dichiarare risolto un vincolo aziendale documentato solo perché la raccomandazione predefinita è diversa.

I valori predefiniti non dimostrano lo stato del tenant

La pagina sui criteri password Entra documenta l’assenza di scadenza come età massima predefinita attuale, ma indica un valore predefinito di 90 giorni per i tenant creati prima del 2021. Descrive inoltre separatamente l’impostazione del singolo utente per non far scadere la password. L’età del tenant e un flag utente non sostituiscono quindi la lettura del criterio effettivo.

La procedura di scadenza Microsoft 365 si applica agli utenti esclusivamente cloud. Esclude esplicitamente gli utenti ibridi che usano la sincronizzazione dell’hash delle password, l’autenticazione pass-through o la federazione locale. In una verifica ibrida, identifica l’autorità responsabile delle password prima di scegliere la procedura di modifica.

Misurare la configurazione prima di modificarla

1. Registrare le impostazioni del portale Password Protection

Apri Entra ID > Authentication methods > Password protection. Registra Enforce custom list, le voci dell’elenco, Enable password protection on Windows Server Active Directory e il Mode locale. Si tratta di osservazioni separate. Un’opzione Windows Server abilitata non indica se gli agenti abbiano ricevuto un criterio né se tutti i controller previsti siano coperti.

La pagina Microsoft sulle operazioni locali indica che Audit accetta le password che verrebbero rifiutate e registra l’esito; Enforced rifiuta le password non sicure. Impostare l’opzione Windows Server su No interrompe la convalida negli agenti DC distribuiti. Queste impostazioni riguardano AD DS, non un interruttore che disabilita l’elenco globale cloud automatico.

2. Leggere l’eccezione di scadenza dell’utente cloud

Con Microsoft Graph PowerShell installato e connesso al tenant previsto con almeno il ruolo User Administrator, come richiesto dalla procedura citata, usa il comando seguente, riportato senza modifiche dalla procedura Microsoft di verifica della scadenza:

Get-MgUser -All -Property UserPrincipalName, PasswordPolicies | Select-Object UserPrincipalName, @{N="PasswordNeverExpires";E={$_.PasswordPolicies -contains "DisablePasswordExpiration"}}

-All richiede tutti gli utenti; -Property recupera esplicitamente le proprietà usate dall’espressione. Interpreta il risultato nella direzione corretta: PasswordNeverExpires=True significa che il flag di disabilitazione è presente. False significa che quel flag non è stato trovato; da solo non dimostra un’età massima finita del dominio.

Abbina questo inventario a Microsoft 365 admin center > Settings > Org Settings > Security and Privacy > Password expiration policy per la popolazione cloud applicabile. Registra l’ambito dei domini e le eventuali eccezioni individuali. La procedura avverte che i nuovi domini gestiti, o quelli convertiti dalla federazione, richiedono di riapplicare il criterio dell’organizzazione per aggiornare tutti i domini. Microsoft Learn: criterio di scadenza.

Qui non viene mostrato alcun risultato di un tenant: il comando è una misurazione documentata, non l’affermazione che un ambiente specifico abbia superato il controllo.

Rilevamento: verificare l’applicazione locale

Usa il canale Admin dell’agente DC in Applications and Services Logs > Microsoft > AzureADPasswordProtection > DCAgent > Admin. Il riferimento Microsoft per il monitoraggio distingue questi esiti:

L’evento 30019 è una notifica dello stato del criterio, non un esito emesso per ogni modifica o reimpostazione della password. Segnala che il criterio ricevuto ha disabilitato l’elaborazione: le password successive sono considerate conformi senza convalida e non vengono registrati ulteriori eventi finché il criterio non cambia.

Le coppie di eventi associati condividono un CorrelationId. Esamina l’evento che spiega il motivo insieme all’esito e conserva l’identità del controller e il timestamp. Non contare la coppia come due richieste rifiutate indipendenti.

Per un riepilogo specifico di un controller, Microsoft fornisce questo comando su un server proxy Password Protection:

Get-AzureADPasswordProtectionSummaryReport -DomainController bplrootdc2

Questo è il nome del controller dell’esempio Microsoft, non un ambiente osservato qui. Sostituiscilo con il controller in esame. Il rapporto legge i log Admin dell’agente tramite PowerShell remoto; la mancanza di accesso o di agenti limita le prove. Non interpretare un rapporto vuoto come un test riuscito dell’applicazione.

Questi eventi descrivono la convalida delle password, non attacchi di accesso. Correla separatamente un incidente tramite la telemetria di accesso; un rifiuto dell’elenco personalizzato da solo non identifica la persona che tenta un password spraying.

Correzione: termini personalizzati, applicazione AD DS e scadenza (Remediation)

1. Abilitare e convalidare l’elenco personalizzato

Segui il tutorial dell’elenco personalizzato con almeno il ruolo Authentication Policy Administrator e licenze Entra ID P1 o P2. Imposta Enforce custom list su Yes, inserisci un termine per riga e salva. I termini devono avere 4–16 caratteri; l’elenco supporta fino a 1.000 termini. Gli aggiornamenti possono richiedere diverse ore.

Usa un account di test non amministratore e i prerequisiti SSPR documentati. Prova una variante debole di un termine configurato dopo la propagazione. Registra l’accettazione o il rifiuto senza conservare la password. Se un test viene accettato inaspettatamente, esamina l’applicazione, la propagazione e l’algoritmo di valutazione prima di dichiarare inefficace l’elenco.

2. Completare la distribuzione locale

Segui la guida di distribuzione Microsoft: installa e registra il servizio proxy e la foresta, distribuisci gli agenti DC e considera il riavvio necessario per caricare il filtro delle password. I controller scrivibili sono i punti di convalida; i RODC inoltrano le operazioni sulle password e non necessitano di un agente DC.

Audit è la modalità iniziale documentata. Usa quel periodo per provare i flussi di modifica delle password e la promozione/retrocessione dei controller di dominio, quindi passa a Enforced dopo aver risolto i problemi operativi. Conferma che l’opzione Windows Server sia Yes e salva la modifica usando la procedura operativa. Ripeti un test controllato con una password debole e verifica i relativi eventi di rifiuto correlati.

La guida di distribuzione spiega anche il funzionamento con criteri memorizzati nella cache quando i proxy non sono disponibili. Verifica l’aggiornamento del criterio oltre alla presenza degli agenti: un servizio in esecuzione e una schermata del portale sono prove diverse.

3. Rimuovere la scadenza cloud periodica ove applicabile

Per gli utenti esclusivamente cloud, esamina l’opzione raccomandata di non scadenza nel riquadro di scadenza Microsoft 365. Per l’eccezione di un singolo utente, Microsoft documenta questo comando in Impostare una password affinché non scada mai:

Update-MgUser -UserId <user ID> -PasswordPolicies DisablePasswordExpiration

Il segnaposto è copiato dalla documentazione; sostituiscilo con l’ID dell’utente previsto. Esamina i valori esistenti del criterio password prima di un aggiornamento mirato. Evita di trasformare l’esempio in una modifica dell’intero tenant senza verifica e ripeti successivamente l’inventario in sola lettura.

Per le identità ibride, risolvi separatamente il criterio sul lato AD e il modello di sincronizzazione. La procedura cloud non certifica una modifica dell’età massima locale. Mantieni i cambiamenti delle password attivati da una compromissione e i controlli MFA e di rischio delle identità raccomandati da Microsoft.

Come EtcSec rileva questo problema

Le implementazioni dei rilevatori etc-collector esaminate per questo articolo valutano tre segnali di configurazione:

Usa questi rilievi per avviare le verifiche manuali corrispondenti. L’assenza di un rilievo non sostituisce le misurazioni del portale, l’inventario Graph e la convalida controllata AD DS descritti sopra. Chiudi ogni correzione con prove dal percorso effettivo di modifica della password che si sta proteggendo.