Guido Grillenmeier

Proteggere adeguatamente la vostra Active Directory (AD) non è mai stato facile. Lo stesso vale per la concessione dei diritti di modifica dell'AD. Dopo tutto, non si vuole che gli account di amministrazione più privilegiati (ad esempio, gli amministratori di dominio) eseguano le operazioni quotidiane della directory, ma la concessione di troppi privilegi minaccia la sicurezza dell'AD. È qui che entra in gioco la delega dei permessi agli oggetti AD.

La granularità delle autorizzazioni in Active Directory è potente ma può essere eccessiva. Nel corso degli anni, Microsoft ha aggiunto alcune opzioni e diritti per consentire agli amministratori di concedere funzionalità a un livello più granulare. Tuttavia, gli sforzi per garantire la retrocompatibilità con le autorizzazioni delegate esistenti hanno reso ancora più difficile la protezione dell'AD. Ho scritto in precedenza di alcune potenziali conseguenze per la sicurezza dell'AD. Purtroppo, questi problemi permangono anche nella versione più recente del sistema operativo, Windows Server 2025.

Ecco come utilizzare le opzioni di password di Windows con la gestione delle deleghe per supportare la struttura di gestione degli utenti senza sacrificare la sicurezza di Active Directory.

Delega della gestione degli utenti e principio del minor privilegio

Quando si progetta un modello di delega AD, gli amministratori devono distinguere attentamente chi può vedere o fare cosa in quale parte della directory. Agli amministratori delegati devono essere concessi solo i privilegi minimi necessari per svolgere le loro attività amministrative, né più né meno.

Ad esempio, il ruolo di un operatore di helpdesk consiste nel reimpostare le password degli utenti. Gli operatori non hanno bisogno del Controllo completo dell'unità organizzativa (OU) che contiene tutti gli account utente. Ciò consentirebbe agli operatori dell'helpdesk di eseguire molte altre modifiche agli account utente e ad altri oggetti in quella OU. Anche se si desidera concedere agli operatori regionali le autorizzazioni fino al controllo completo, o addirittura il controllo completo, pergestire un maggior numero di aspetti degli utenti, è necessario che seguano le regole di sicurezza generali, in particolare per quanto riguarda le diverse opzioni di password per gli utenti che gestiscono.

Gestione delle opzioni di password e politica delle password

Il modello di autorizzazioni originale rilasciato da Microsoft con Windows Server 2000 era incredibilmente completo e consentiva agli amministratori di concedere funzionalità fino agli attributi di un oggetto (anziché solo all'oggetto stesso). Tuttavia, le limitazioni relative all'impostazione di specifiche opzioni di password potevano potenzialmente entrare in conflitto con i criteri aziendali in materia di password.

Il problema della versione originale di AD è che non poteva distinguere tra le seguenti opzioni di gestione delle password sensibili alla sicurezza(Figura 1):

  • Memorizzare la password utilizzando la crittografia reversibile
  • La password non scade mai
  • Password non richiesta Bit
Figura 1: Opzioni dell'account con password critica nella scheda Account

Il bit Password non richiesta non è disponibile nelle interfacce utente native di Windows. Tuttavia, il bit può essere impostato in modo programmatico, ad esempio tramite PowerShell:

Get-ADUser -Identity Bob | Set-ADUser -PasswordNotRequired $true

Queste opzioni, se utilizzate, possono facilmente compromettere i criteri aziendali sulle password, mettendo a rischio l'azienda. Le opzioni non hanno un proprio attributo in cui sono memorizzate, ma fanno parte dell'attributouserAccountControl di un utente in AD. Questo attributo è una raccolta di varie impostazioni che controllano molti aspetti di un account utente, attivando un interruttore binario nella posizione corretta.

Sfortunatamente, qualsiasi autorizzazione delegata che conceda a un operatore il Controllo completo sugli utenti di un'UO o anche solo il diritto di scrivere le Restrizioni account su tali oggetti utente, consente all'operatore di impostare queste opzioni di password sensibili su qualsiasi account sotto il suo controllo.

Consentire agli amministratori delegati di scegliere queste opzioni di password per gli account che gestiscono porta spesso a risultati spiacevoli. Ad esempio, gli amministratori delegati che non sono consapevoli della sicurezza potrebbero configurare un'alta percentuale di utenti con l'opzione Password senza scadenza, semplicemente per evitare problemi quando gli utenti cambiano la password. Naturalmente, questa pratica compromette qualsiasi politica di invecchiamento delle password impostata a livello di dominio... anche quelle impostate per i gruppi attraverso criteri di password a grana fine.

Il problema degli utenti autenticati

Microsoft non ci ha messo molto a combattere questo problema. Con il rilascio di Windows Server 2003, Microsoft ha introdotto tre nuovi diritti di accesso di controllo, detti anche diritti estesi:

  • Abilita la password crittografata reversibile per utente
  • Password non scaduta (che abilita l'impostazione del flag Password non scaduta )
  • Aggiornamento password non richiesto Bit

A differenza dei diritti estesi come Reset-Password, che devono essere impostati direttamente per gli oggetti utente, questi tre diritti estesi sono stati implementati per essere applicati a livello di dominio. Con questi diritti, solo gli operatori a cui è stato concesso il Controllo completo o la Scrittura di AccountRestrictions a un insieme di utenti (ad esempio, in una OU) in combinazione con una delle autorizzazioni speciali per le password sulla radice del dominio possono effettivamente impostare queste opzioni di password sensibili sugli account che controllano.

Tuttavia, essendo Microsoft, la necessità di garantire la retrocompatibilità con le autorizzazioni delegate esistenti e l'esigenza di "far funzionare le cose come prima" hanno avuto la priorità sull'incoraggiamento ai clienti a migliorare la sicurezza AD nei loro modelli di delega.

Per risolvere questo dilemma, Microsoft ha scelto di concedere al gruppo Utenti Autenticati questi diritti alla radice del dominio durante l'aggiornamento di Windows Server 2003 dei domini e delle foreste AD esistenti. Sfortunatamente, ha anche impostato queste autorizzazioni su ogni nuovo dominio AD implementato.

Vi suona familiare? Sì, gli Utenti autenticati appaiono ovunque... e non sempre a vostro favore(Figura 2).

Figura 2: Autorizzazioni predefinite per gli utenti autenticati alla radice del dominio AD

Questo è lo status quo dall'aggiornamento di Windows Server 2003... e continua a verificarsi nelle nuove implementazioni AD basate su Windows Server 2022 e persino Windows Server 2025. Ciò significa che quasi certamente troverete queste autorizzazioni predefinite ancora attive nella vostra implementazione AD e probabilmente vi impediranno di rafforzare la sicurezza delle password in Active Directory.

Come migliorare la sicurezza delle password AD

Quindi, come si può migliorare la sicurezza delle password AD? Innanzitutto, è necessario rimuovere l'autorizzazione predefinita per gli utenti autenticati per questi tre diritti estesi dalla radice dei domini. Poi, dovrete scegliere dei sostituti adeguati, nel caso in cui decidiate di delegare queste autorizzazioni. Ricordate: Questi tre diritti estesi devono essere impostati a livello di dominio. La concessione a livello di UO non ha alcun effetto.

La mia raccomandazione:

  1. Creare un gruppo separato per ciascuno di questi diritti estesi sensibili.
  2. Concedere a ciascun gruppo la rispettiva autorizzazione alla radice del dominio. Questi gruppi appartengono alla UO di livello 0, dove solo gli amministratori di dominio possono apportare modifiche.
  3. In una foresta multidominio, creare i gruppi come gruppi universali nel dominio principale. In questo modo, è possibile aggiungere ai gruppi utenti selezionati di ogni dominio, che saranno poi in grado di concedere le rispettive autorizzazioni in qualsiasi dominio.

Ad esempio, si possono creare i seguenti tre gruppi:

  • SVC-ADconfig-PerUserReversiblyEncryptedPwd
  • SVC-ADconfig-UnexpirePassword
  • SVC-ADconfig-PwdNotRequiredBit

Quindi, sostituite i diritti estesi concessi agli Utenti autenticati con ogni gruppo corrispondente(Figura 3).

Figura 3: Sostituzione delle autorizzazioni con gruppi speciali per autorizzazione alla radice del dominio AD

Supponiamo ora che un operatore, Fred, abbia le autorizzazioni per gestire un utente. È ancora possibile concedere a Fred il Controllo completo o la Scrittura delle restrizioni dell'account per tutti gli utenti dell'OU di cui è responsabile. Tuttavia, Fred non potrà impostare nessuna delle tre opzioni di password sensibili su tali account utente.

Ora, se si aggiunge Fred al gruppo SVC-ADconfig-UnexpirePassword, potrà impostare l'opzione Password senza scadenza per gli utenti che gestisce. Probabilmente è meglio non dare a Fred questa opzione, ma si potrebbe fare se ci fosse una necessità valida.

Si spera che siano già disponibili piani di test e un elenco di persone responsabili della convalida delle applicazioni, degli strumenti e dei processi di gestione degli utenti e dei clienti più critici, nonché un processo di raccolta dei feedback dopo aver apportato queste modifiche alle autorizzazioni. Naturalmente, prima di eseguire tali modifiche nell'ambiente AD di produzione, è necessario registrare le autorizzazioni correnti e testare le nuove impostazioni prima di distribuire le modifiche.

L'ideale sarebbe disporre di una soluzione che registri tutte le modifiche in Active Directory, compreso l'attributo nTsecurityDescriptor, che memorizza essenzialmente l'autorizzazione del rispettivo oggetto. Ancora meglio sarebbe una soluzione in grado di annullare tali modifiche in AD.

Sì, per completezza: Semperis Directory Service Protector (DSP) può fare entrambe le cose. Esistono anche script disponibili pubblicamente che potete utilizzare con le vostre schermate per documentare il vostro lavoro.

Principali indicazioni per le opzioni di password sensibili in Windows Server 2025 e precedenti

Active Directory è piena di sorprese in termini di sicurezza. Per identificare le potenziali lacune di sicurezza nel vostro ambiente, scaricate Purple Knightuno strumento gratuito di valutazione della sicurezza di AD che identifica oltre 150 indicatori di esposizione e di compromissione e fornisce indicazioni su come affrontarli.

Tenete presente che l'adozione di Windows Server 2025 non implica necessariamente l'abbandono delle problematiche impostazioni precedenti. Se non altro, considerate la possibilità di modificare le impostazioni di configurazione relative alla delega delle opzioni di password sensibili.

  1. Se avete delegato l'amministrazione degli oggetti utente a persone che non sono amministratori di dominio, stabilite se queste persone devono avere la possibilità di impostare opzioni sensibili come Password mai scaduta sugli account utente che gestiscono.
  2. Sostituite le autorizzazioni predefinite per gli Utenti autenticati nella radice del dominio per i tre diritti estesi discussi in questo articolo con gruppi che solo gli Amministratori di dominio possono gestire.
  3. Aggiungete selettivamente gli amministratori delegati ai gruppi appena creati, ma solo se c'è una reale necessità aziendale di gestire una qualsiasi di queste opzioni di password sensibili.

Apportare queste modifiche comporta pochi rischi e grandi vantaggi per la sicurezza di Active Directory e per una gestione efficace delle deleghe.

Avete bisogno di assistenza con AD Security?

Sfruttate l'esperienza di Semperis. Richiedete una Security Configuration Review e il nostro team utilizzerà strumenti automatici e metodi manuali per individuare le configurazioni errate e i percorsi di attacco che un aggressore potrebbe sfruttare per compromettere il vostro ambiente.

Ulteriori letture