• Cloud, Guide, Sicurezza
• 25 Febbraio 2022

In Azure Active Directory (Azure AD) è presente una password policy che definisce impostazioni come complessità, lunghezza o età delle password. È anche disponibile un criterio che definisce i caratteri accettabili e la lunghezza per i nomi utente.

Le impostazioni predefinite per la password policy di Azure AD sono:

• Minimo 8 caratteri e massimo 256 caratteri
• Password complessa con almeno 3 dei quattro requisiti seguenti:
  • Caratteri minuscoli.
  • Caratteri maiuscoli.
  • Numeri (da 0 a 9).
  • Simboli (@ # $ % ^ & * – _ ! + = [ ] { } | \ : ‘ , . ? / ` ~ ” ( ) ; <>) . Si può usare anche lo spazio vuoto
• Durata scadenza password predefinita di 90 giorni (modificabile con la cmdlet Set-MsolPasswordPolicy)
• Notifica di scadenza della password predefinita di 14 giorni (modificabile con la cmdlet Set-MsolPasswordPolicy)
• L’utente NON può riutilizzare l’ultima password al momento del cambio password (1 password ricordata)
• L’utente può usare di nuovo la password più recente se sta reimpostando una password dimenticata

In più:

• L’account viene bloccato per 1 minuto dopo 10 inserimenti di password errate. Successivi inserimenti di password sbagliate bloccheranno l’utente per più tempo (l’algoritmo non è reso noto da Microsoft per motivi di sicurezza).

NOTA: queste configurazioni non possono essere cambiate.

Per impostazione predefinita, gli account amministratore sono abilitati per la reimpostazione della password self-service e vengono applicati criteri di reimpostazione della password predefiniti a due gate. Questo criterio può essere diverso da quello definito per gli utenti e non può essere modificato. Il criterio a due gate richiede tre tipi di dati di autenticazione, ad esempio un indirizzo di posta elettronica, un’app di autenticazione o un numero di telefono.

NOTA: Azure AD supporta criteri di scadenza delle password separati per ogni dominio registrato.

Figura 1: Verifica e configurazione della password policy

Figura 2: La verifica e la configurazione della password policy può essere effettuata anche dal Microsoft 365 Admin Center

Modifica dei criteri delle password

Un amministratore globale o un amministratore utenti può usare il modulo Microsoft Azure AD per Windows PowerShell per impostare le password utente in modo che non scadano mai.

È anche possibile usare le cmdlet di PowerShell per rimuovere la configurazione senza scadenza o per vedere quali password utente sono impostate per non scadere mai.

Queste indicazioni si applicano ad altri provider, ad esempio Intune e Microsoft 365, che si basano anche sul Azure AD per i servizi di identità e directory.

Per recuperare informazioni sulle password policy applicate ai diversi utenti del vostro tenant di Azure AD potete utilizzare la cmdlet Get-AzureADUser

Figura 3: Verifica della password policy per utenti solo cloud

Per impostare la password di un utente in modo che non scada mai potete eseguire il comando:

Per impostare le password di tutti gli utenti di un’organizzazione in modo che non scadano mai potete eseguire il comando:

Per impostare la password di un utente in modo che scada potete eseguire il comando:

Per impostare le password di tutti gli utenti di un’organizzazione in modo che scadano potete eseguire il comando:

Identità ibride di Azure AD

Nel caso di un dominio ibrido (identità ibrida), cioè sincronizzato con Azure AD Connect, la password policy per tutti gli utenti sarà impostata su DisablePasswordExpiration. La password policy che verrà applicata sarà quella che è stata assegnata a livello di dominio Active Directory locale. Quando la sincronizzazione dell’hash delle password è abilitata, i criteri di complessità delle password presenti nell’istanza di Active Directory locale sostituiscono i criteri di complessità definiti nel cloud per gli utenti sincronizzati.

Qui di seguito il comando che ho lanciato per verificare la password policy di alcuni utenti che sono sincronizzati tramite Azure AD Connect e che hanno la Password Hash Synchronization abilitata.

Figura 4: Verifica della password di dominio per utenti ibridi sincronizzati con Azure AD Connect

Quando infatti viene utilizzato Azure AD Connect per sincronizzare gli utenti e le password, il servizio di sincronizzazione Azure AD Connect estrae l’hash della password dall’istanza di Active Directory locale. All’hash della password viene applicata un’elaborazione di sicurezza aggiuntiva prima della sincronizzazione con il servizio di autenticazione di Azure Active Directory. Le password vengono sincronizzate per ogni singolo utente e in ordine cronologico.

NOTA: Il servizio di dominio Active Directory archivia le password come rappresentazioni con valore hash delle password utente reali. Un valore hash è il risultato di una funzione matematica unidirezionale ( algoritmo hash). Non esiste un metodo per ripristinare la versione in testo normale di una password dal risultato di una funzione unidirezionale.

Il flusso di dati del processo di sincronizzazione hash delle password è simile alla sincronizzazione dei dati utente. Le password vengono tuttavia sincronizzate con una frequenza maggiore rispetto alla finestra di sincronizzazione standard della directory per altri attributi (che di default è ogni 30 minuti e non può essere diminuita ma soltanto aumentata).
Il processo di sincronizzazione dell’hash delle password viene eseguito ogni 2 minuti. Non è possibile modificare la frequenza del processo. Se si sincronizza una password, la password sincronizzata sovrascrive quella esistente nel cloud. Quando si modifica una password locale, la password aggiornata viene sincronizzata.

NOTA: La sincronizzazione di una password non influisce sull’utente che ha già eseguito l’accesso. Se si modifica una password sincronizzata dopo aver eseguito l’accesso a un servizio cloud, la sessione corrente del servizio cloud non rileva immediatamente la modifica. Tuttavia, quando il servizio cloud richiede di nuovo l’autenticazione, è necessario specificare la nuova password.

Maggiori informazioni sono disponibili nella Implementare la sincronizzazione dell’hash delle password con il servizio di sincronizzazione Azure AD Connect | Microsoft Docs

Figura 5: Descrizione dettagliata del funzionamento della sincronizzazione dell’hash delle password

Da Febbraio 2020 è anche disponibile la funzionalità EnforceCloudPasswordPolicyForPasswordSyncedUsers. Quando EnforceCloudPasswordPolicyForPasswordSyncedUsers è disabilitata (impostazione predefinita), Azure AD Connect imposta l’attributo PasswordPolicies degli utenti sincronizzati su DisablePasswordExpiration. Questa operazione viene eseguita ogni volta che la password di un utente viene sincronizzata; Azure AD ignora i criteri di scadenza della password cloud per tale utente.

Nel momento in cui viene abilitata questa funzionalità invece che i criteri di scadenza password di Active Directory on-premises, verranno forzati i i criteri di scadenza della password di Azure AD.

Per abilitare la funzionalità EnforceCloudPasswordPolicyForPasswordSyncedUsers, è necessario eseguire il seguente comando PowerShell:

Il valore DisablePasswordExpiration viene rimosso immediatamente dalla proprietà PasswordPolicies di ogni utente ma solo durante la successiva sincronizzazione dell’hash delle password e solo alla successiva modifica della password in AD locale.

Dopo aver abilitato la funzionalità EnforceCloudPasswordPolicyForPasswordSyncedUsers i nuovi utenti avranno il valore PasswordPolicies vuoto.

È consigliabile abilitare EnforceCloudPasswordPolicyForPasswordSyncedUsers prima di abilitare la sincronizzazione dell’hash delle password, in modo che la sincronizzazione iniziale degli hash delle password non abiliti il valore all’attributo PasswordPolicies per gli utenti.

Migliorare l’efficacia della password policy

Abbiamo già visto prima che non è possibile cambiare la password policy di Azure AD. È possibile, tuttavia, sfruttare alcune funzionalità di sicurezza aggiuntive (disponibili in Azure AD Premium P1) utilizzando:

• Smart lockout La funzione di blocco intelligente blocca gli attori malintenzionati che tentano di indovinare le password degli utenti o usano metodi di forza bruta per ottenere l’accesso. Questa funzione è in grado di riconoscere i tentativi di accesso eseguiti da utenti validi e di gestirli in modo diverso da quelli di utenti malintenzionati e di altre origini sconosciute. Blocca gli utenti malintenzionati, consentendo al contempo a quelli validi di accedere ai propri account senza effetti negativi sulla produttività.
• Azure AD password protection Blocca password deboli note (prendendo da un elenco di 500 parole vietate) e le loro relative variazioni (ad esempio con la modalità Leet). È possibile aggiungere anche termini personalizzati, ad esempio nomi aziendali, nomi di prodotto, nomi di città, ecc. che possono essere facilmente riferiti all’azienda e aiutare i malintenzionati a fare ingegneria sociale.

Autenticazione senza password in Azure AD

Anche se fuori tema rispetto al titolo di questo articolo, vi invito a riflettere sull’Autenticazione senza password in Azure AD, o come viene più spesso chiamata Passwordless Authentication. Azure AD consente di autenticare gli utenti in modo nativo, attraverso metodi senza password che semplificano l’esperienza di accesso e riducono il rischio di subire attacchi. Windows Hello for Business, App Microsoft Authenticator, Chiavi di sicurezza FIDO2 sono tutti metodi efficaci che risolvono a monte il problema della debolezza della password come metodo di autenticazione.

Decisamente illuminante sarà la lettura dell’articolo Your Pa$$word doesn’t matter – Microsoft Tech Community e la visione del video How Easy It Is To Crack Your Password, With Kevin Mitnick – YouTube

Conclusioni

Spero di aver fatto un po’ di chiarezza su come funzionino le password policy in Azure AD e soprattutto perché dal portale non ci sono funzionalità che permettano di modificarle, generando spesso negli utenti dubbi drammatici perché ovviamente fanno il paragone con il funzionamento delle policy negli ambient di dominio on-premises. A proposito, avete già letto la mia guida Active Directory Password Policies: facciamo un po’ di chiarezza – ICT Power?