Comprendere i rischi delle impostazioni di accesso compatibili con i sistemi precedenti a Windows 2000

[Aggiornato il 14 febbraio 2024; pubblicato originariamente il 29 novembre 2021] Il numero e la portata delle impostazioni di sicurezza confuse e rischiose di Active Directory diventano sempre più noti a ogni nuovo attacco informatico. Molte di queste vulnerabilità possono essere attribuite a configurazioni rischiose che si sono accumulate negli ambienti legacy nel corso del tempo. Tuttavia, i team IT devono ancora prestare attenzione alle impostazioni problematiche che vengono fornite in Windows Server 2022. Purtroppo, lo stesso vale per l'imminente Windows Server 2025. Un'impostazione di Active Directory che ogni team IT dovrebbe immediatamente affrontare è il gruppo Pre-Windows 2000 Compatible Access precompilato con il principio di sicurezza Authenticated Users. Questa impostazione può lasciare una porta aperta agli intrusi, come dimostrerò.

Per capire perché l'impostazione Accesso compatibile pre-Windows 2000 è così problematica, analizziamo la storia della delega dei permessi e dell'assegnazione dei criteri in Active Directory. In questo modo potrete prendere una decisione informata su come gestire questa impostazione nella vostra organizzazione.

Lettura correlata: Cos'è la sicurezza di Active Directory?

Essere o non essere... compatibile con Windows NT?

C'è una buona ragione per cui non si parla molto di Windows NT in questi giorni. È storia. È una tecnologia del secolo scorso.

Windows NT è stato un grande passo avanti per Microsoft e ha segnato l'ingresso dell'azienda nel mercato delle imprese nel 1993. Ma il sistema operativo è stato sostituito da versioni più recenti e sicure dal rilascio di Windows 2000 all'inizio di questo secolo. Per quanto riguarda i server, Microsoft ha mantenuto lo standard di denominazione di aggiungere l'anno più vicino alla data di rilascio.

Mentre scrivo questo aggiornamento, Windows Server 2022 è l'ultimo sistema operativo Microsoft. Ma nel gennaio 2024, il nome della prossima release "vNext" è stato (senza sorpresa) confermato come Windows Server 2025. Ci aspettiamo che la nuova versione del sistema operativo venga rilasciata prima della fine del 2024.

Cosa è cambiato in Windows 2000?

Un cambiamento fondamentale di Windows 2000 è stata la sostituzione del concetto di dominio di Windows NT, che era una directory piatta per l'autenticazione di utenti e macchine nella rete aziendale, con Active Directory, molto più scalabile e sicuro. Oltre al concetto di dominio, Active Directory ha introdotto gli alberi e le foreste di dominio. Il servizio permetteva anche di creare una struttura gerarchica di unità organizzative (OU) per gli oggetti all'interno di un dominio. Questa struttura era utile per delegare le autorizzazioni e assegnare criteri specifici.

Un'altra differenza fondamentale è stata altrettanto importante. Active Directory ha introdotto la possibilità di impostare le autorizzazioni non solo a livello di oggetto (ad esempio, utenti, gruppi, computer), ma anche a livello di attributo (ad esempio, reparto, numero di telefono, appartenenza a gruppi) di ciascun oggetto. Gli amministratori possono ora distinguere tra la possibilità di "leggere" o "scrivere" tutti gli attributi di un determinato oggetto di Active Directory o solo quelli rilevanti per una determinata attività.

La chiave del principio del minor privilegio

Questa funzionalità è stata fondamentale per consentire alle aziende di seguire il mantra del minimo privilegio di ogni buon piano di sicurezza: concedere agli utenti solo il numero di autorizzazioni necessario per svolgere il proprio lavoro. Non concedete agli utenti più permessi di accesso ai dati di cui non hanno bisogno. In caso contrario, un utente, soprattutto se compromesso, potrebbe abusare di tali permessi e danneggiare l'azienda.

In qualsiasi file server o struttura SharePoint che condivida documenti per gli utenti di tutta l'azienda, l'approccio più naturale sarebbe quello di seguire la regola del minor privilegio. Ad esempio, gli utenti devono essere membri di un gruppo di sicurezza appropriato per poter visualizzare i documenti che contengono dati finanziari o comunque sensibili dell'azienda, o anche solo per elencare l'esistenza del file.

Si può comunque scegliere di rendere disponibili a tutti gli utenti dati specifici e non sensibili tramite una condivisione di documenti pubblici a cui tutti gli utenti hanno accesso, senza bisogno di essere aggiunti a un gruppo speciale. L'accesso viene in genere concesso al gruppo Utenti di dominio o anche ai principi di sicurezza Utenti autenticati o Tutti .

Purtroppo, la maggior parte delle aziende non tratta Active Directory in questo modo. Il motivo è in parte dovuto alle autorizzazioni predefinite con cui Microsoft ha distribuito - e distribuisce tuttora - i nuovi domini Active Directory.

Che cos'è il gruppo Accesso compatibile pre-Windows 2000?

Prendiamo il gruppo Accesso compatibile pre-Windows 2000. Microsoft ha deciso di introdurre questo gruppo, che sarebbe più appropriato chiamare gruppo Autorizzazioni meno sicure di Windows NT, quando ha rilasciato Windows 2000. Il problema: anche in una nuova implementazione di una foresta Active Directory sui server Windows Server 2022 e sì, sui server Windows Server 2025, Microsoft pre-popola il gruppo Accesso compatibile pre-Windows 2000 con il principio di sicurezza Utenti autenticati.

Allora, perché è importante e perché dovrebbe interessarvi?

Come dice il nome, il gruppo Accesso compatibile pre-Windows 2000 è stato creato per essere compatibile con Windows NT. In altre parole, il gruppo consente di concedere autorizzazioni a livello di oggetto sugli oggetti di Active Directory che sono compatibili con il meno sicuro Windows NT, invece di utilizzare autorizzazioni più granulari a livello di attributo. Microsoft non nasconde le implicazioni potenzialmente rischiose nella descrizione del gruppo: "Un gruppo di compatibilità all'indietro che consente l'accesso in lettura a tutti gli utenti e gruppi del dominio".

E poiché Microsoft vuole "aiutarvi" il più possibile con la retrocompatibilità, concede le autorizzazioni complete di lettura per i rispettivi oggetti (utenti e gruppi) proprio in cima a ogni dominio della foresta, consentendo di ereditare l'intera gerarchia di OU.

Queste autorizzazioni predefinite sono impostate, anche se Microsoft non chiede più se si desidera distribuire la nuova foresta AD in modo compatibile con le versioni di Windows precedenti al 2000 (ad esempio, Windows NT). Questa opzione era disponibile nei sistemi operativi precedenti quando si promuoveva una nuova foresta AD. Se aveste scelto questa opzione qualche anno fa, avreste persino aggiunto Utenti anonimi e Tutti al gruppo Accesso compatibile pre-Windows 2000, garantendo così a questi principi di sicurezza un potente accesso in lettura ad Active Directory. Gli utenti non avrebbero nemmeno bisogno di autenticarsi per leggere l'AD! Spero proprio che abbiate già ripulito questi permessi legacy, di cui ogni controllo di sicurezza vi avrebbe già avvertito.

È possibile lasciare gli utenti autenticati nel gruppo Accesso compatibile pre-Windows 2000?

Sì, è necessario rimuovere Utenti autenticati dai gruppi Accesso compatibile pre-Windows 2000 in ogni dominio della foresta AD, anche se Microsoft continua ad aggiungerlo come impostazione predefinita per le nuove implementazioni AD. Lasciare Utenti Autenticati nel gruppo garantisce le autorizzazioni complete di LETTURA, consentendo a qualsiasi utente e computer collegato al dominio di leggere i rispettivi dati su qualsiasi oggetto.

Si noti che ogni computer collegato al dominio è anche un utente autenticato nella foresta di Active Directory. Anche se nessun utente è connesso a questi computer, un processo, forse un trojan, che gira nel contesto di sistema di un computer collegato al dominio ha lo stesso accesso ad Active Directory dei vostri utenti.

Per comprendere meglio l'impatto, è necessario scavare un po' più a fondo e verificare quali autorizzazioni vengono concesse di default a Utenti Autenticati su tutti gli oggetti utente e gruppo del dominio. Ogni volta che si crea un oggetto, Active Directory aggiunge al nuovo oggetto il descrittore di sicurezza predefinito per l'oggetto in questione. Queste autorizzazioni sono concesse esplicitamente all'oggetto (cioè non sono ereditate). In quanto tali, hanno la massima priorità nella determinazione dei permessi complessivi dell'oggetto. Si noti che questa configurazione concede anche a questi permessi predefiniti una priorità più alta rispetto a un permesso di negazione ereditato, cosa che spesso confonde gli amministratori.

Autorizzazioni sugli oggetti del gruppo

Per gli oggetti del gruppo, le autorizzazioni di Accesso compatibile pre-Windows 2000 non fanno differenza. Agli utenti autenticati viene concessa la lettura completa di ogni oggetto del gruppo.

Anche se si rimuove Utenti autenticati dal gruppo Accesso compatibile pre-Windows 2000, tutti gli utenti possono leggere i membri di tutti i gruppi della foresta Active Directory. A meno che non si rimuova questa autorizzazione dai gruppi selezionati, qualsiasi utente della foresta, compreso un potenziale intruso, può facilmente determinare chi è membro di qualsiasi gruppo del dominio. Per i gruppi AD più sensibili, come gli Amministratori di dominio o gli Amministratori aziendali, sono necessari alcuni passaggi aggiuntivi per rimuovere questa autorizzazione READ. (Questi gruppi sono controllati dalle autorizzazioni di un oggetto speciale chiamato AdminSDholder. Per ulteriori informazioni su AdminSDholder e sulla sicurezza di Active Directory, consultare questo white paper).

Permessi sugli oggetti utente

Tuttavia, la situazione è molto diversa per gli oggetti utente. Le autorizzazioni predefinite concesse agli Utenti autenticati sugli oggetti utente sono anch'esse piuttosto estese e comprendono la lettura di tutti gli attributi delle informazioni generali e personali. Tuttavia, i permessi sono meno pervasivi di quelli che consentono la lettura di tutti gli attributi degli utenti.

Ciò significa che vari attributi sensibili dell'utente NON possono essere accessibili agli utenti autenticati tramite i permessi predefiniti dell'oggetto. Tra questi, userAccountControl, memberOf e tutti gli attributi relativi all'accesso, come l'ultimo accesso o l'ultima modifica della password. Attenzione: quando viene concesso l'accesso in lettura all'attributo userAccountControl , è possibile scoprire quali utenti hanno il flag PasswordNotRequired impostato e altre informazioni che potrebbero consentire la scoperta di oggetti non sicuri nella foresta AD. Gli utenti configurati con il flag PasswordNotRequired potrebbero essere stati creati secoli fa per qualche applicazione e potrebbero davvero non avere una password, se l'amministratore di Active Directory ha scelto di impostarla in questo modo. In quanto tali, sono una facile esca per un intruso.

Quindi, se si sceglie di mantenere Utenti autenticati nel gruppo Accesso compatibile pre-Windows 2000, a ogni utente e computer del dominio vengono automaticamente assegnati i permessi di quel gruppo al momento dell'accesso. Con questa assegnazione, qualsiasi processo, compreso il codice dannoso che un intruso potrebbe eseguire su un client collegato al dominio senza alcun utente connesso, è autorizzato a enumerare gli attributi degli utenti nel dominio.

Sebbene gli intrusi utilizzino spesso strumenti e script specifici per scansionare Active Directory e trovare vulnerabilità, non pensate che i vostri normali utenti abbiano difficoltà a fare lo stesso. Anche senza diritti di amministrazione sul proprio client, possono semplicemente scaricare l'ultimo Sysinternals AD explorer da Microsoft(https://docs.microsoft.com/en-us/sysinternals/downloads/adexplorer) e curiosare allegramente nella vostra foresta Active Directory. Le immagini seguenti mostrano quanto sia facile.

Rimozione degli utenti autenticati dal gruppo Accesso compatibile pre-Windows 2000 gruppo

Questo passo è solo uno dei tanti per aumentare la sicurezza della vostra Active Directory. Oggi non è più necessario mantenere la compatibilità con il modello di sicurezza di Windows NT.

Gli utenti non hanno bisogno delle autorizzazioni concesse dal gruppo Accesso compatibile pre-Windows 2000. Possono comunque accedere. Anche i computer e i server collegati al dominio non hanno bisogno di queste autorizzazioni; continueranno a lavorare nel dominio senza problemi. Anche l'elaborazione dei Criteri di gruppo non è influenzata da questa modifica. Anche gli amministratori di Active Directory non hanno bisogno di queste autorizzazioni, in quanto a loro sono concessi gli stessi permessi e altri ancora.

Tuttavia, la rimozione degli Utenti autenticati dal gruppo Accesso compatibile pre-Windows 2000 non è una modifica che si può eseguire rapidamente in Active Directory il lunedì mattina. Innanzitutto, verificate il potenziale impatto della modifica nel vostro ambiente. Potreste utilizzare strumenti o soluzioni che si aspettano che le autorizzazioni pre-Windows 2000 siano configurate nell'AD e le utilizzano per motivi legittimi.

Esempi di soluzioni o attività che per impostazione predefinita utilizzano le autorizzazioni concesse tramite Utenti autenticati nel gruppo Accesso compatibile pre-Windows 2000:

• Alcuni strumenti di scansione della sicurezza che non vengono eseguiti con un account privilegiato o che vengono eseguiti nel contesto di sicurezza di una macchina potrebbero non riuscire a leggere gli attributi utente sensibili alla sicurezza discussi in questo articolo. Di conseguenza, questi strumenti potrebbero non avvertire se un utente è configurato con il flag PasswordNotRequired . È possibile scegliere di aggiungere il rispettivo account di servizio utilizzato dallo strumento o l'account del computer al gruppo Accesso compatibile pre-Windows 2000, oppure concedere le autorizzazioni richieste separatamente.
• Attenzione alle applicazioni che si legano ad Active Directory tramite LDAP per enumerare le appartenenze ai gruppi per la sicurezza all'interno dell'applicazione.
• Se utilizzate AD Federation Services (ADFS), a seconda della vostra configurazione potreste avere un impatto sull'autenticazione di WebForms, che potrebbe dover essere affrontato con permessi di lettura dedicati per i vostri server ADFS o utilizzando il Gruppo di accesso all'autorizzazione di Windows (WAAG).
• Quando si utilizza la scheda Accesso effettivo nelle impostazioni di sicurezza avanzate del file server per verificare quali autorizzazioni può avere un determinato utente su una cartella, il server utilizza il proprio account computer per leggere le appartenenze ai gruppi dell'utente. Questo processo fallirà dopo che Utenti autenticati è stato rimosso dal gruppo Accesso compatibile pre-Windows 2000. Il valore reale della scheda Accesso effettivo è generalmente discutibile, poiché non considera correttamente i gruppi annidati. Tuttavia, se si desidera utilizzarla, è possibile aggiungere nuovamente gli account dei computer file-server al gruppo Accesso compatibile pre-Windows 2000 o concedere in altro modo le rispettive autorizzazioni di lettura sugli oggetti utente.
• Il client Ivanti File Director ha problemi nella lettura di homeDirectory e userAccountAttribute. Gli utenti non riusciranno ad accedere a questo software a meno che non si aggiunga l'account di servizio utilizzato al gruppo Accesso compatibile pre-Windows 2000 o non si concedano le autorizzazioni corrette direttamente agli oggetti utente.

Un ulteriore vantaggio dello svuotamento del gruppo Accesso compatibile pre-Windows 2000: In questo modo sareste stati protetti dalla vulnerabilità PrintNightmare prima di applicare ai vostri controller di dominio la patch critica CVE-2021-1675 dell'estate del 2021. Allo stesso modo, lo svuotamento del gruppo vi proteggerà da altre vulnerabilità Zero Day che utilizzano queste autorizzazioni predefinite in Active Directory.

In ogni caso, per un funzionamento normale e sicuro di Active Directory, non è necessario che gli Utenti autenticati siano membri del gruppo Accesso compatibile pre-Windows 2000. Non lo sono nemmeno Tutti o Utenti anonimi. Mantenere il gruppo vuoto, o almeno popolato solo con i pochi utenti e computer dedicati che potrebbero richiederlo, contribuirà sicuramente a ridurre la superficie di attacco della vostra Active Directory. Questa configurazione rende molto più difficile per gli intrusi enumerare gli account deboli ed estrarre altri dati sensibili alla sicurezza dall'AD.

Come risolvere questo problema in un ambiente di grandi dimensioni

Scrivere della necessità di migliorare la sicurezza è facile. Ma modificare effettivamente l'appartenenza a un gruppo predefinito che Microsoft ha deciso di lasciare in vigore, anche nella sua ultima versione del sistema operativo, può essere una sfida, soprattutto in ambienti di grandi dimensioni.

Come già detto, iniziate a proteggere i gruppi più critici (ad esempio, Domain Admin, Enterprise Admin) dalla lettura da parte di tutti. In fin dei conti, trascurare questa protezione rende estremamente facile per gli intrusi pianificare i percorsi di attacco contro gli oggetti utente più sensibili della foresta di Active Directory. Il modo migliore per risolvere questo problema è aggiornare il modello AdminSDholder, utilizzato per aggiornare le autorizzazioni su tutti questi oggetti sensibili.

In ambienti di piccole dimensioni, la "pulizia" del gruppo Access compatibile con i sistemi pre-Windows 2000 potrebbe essere possibile nell'arco di un fine settimana, con alcuni test iniziali dei sistemi aziendali principali per confermare che tutto funziona ancora come previsto. Ma questo approccio può essere un po' scoraggiante nelle grandi aziende. Dopo tutto, non si vuole causare un impatto aziendale maggiore solo perché si è deciso di rafforzare la sicurezza di Active Directory.

Come per qualsiasi compito di grandi dimensioni, consiglio di suddividere il lavoro. Anche se la scelta è in ultima analisi binaria - gli Utenti autenticati possono far parte del gruppo Accesso compatibile pre-Windows 2000 oppure no - le autorizzazioni per questo gruppo vengono ereditate a diversi oggetti nella foresta di Active Directory dalla radice di ogni dominio della foresta. Pertanto, avete la possibilità di bloccare le singole UO:

1. Disabilitazione dell'ereditarietà sulle UO
2. Copia di tutte le autorizzazioni esistenti
3. Rimuovendo solo il gruppo Accesso compatibile pre-Windows 2000 dall'insieme di autorizzazioni esplicite risultanti.

Per gli oggetti della rispettiva OU, l'effetto è lo stesso che si avrebbe se si rimuovesse Utenti Autenticati dal gruppo alla radice del dominio. In altre parole, il gruppo Accesso compatibile pre-Windows 2000 non ha più permessi sugli oggetti della rispettiva OU.

Naturalmente, prima di eseguire tali modifiche, è necessario verificare l'impatto delle autorizzazioni. Suggerisco di registrare le autorizzazioni correnti su ogni OU che si desidera modificare. È utile disporre di una soluzione che registri tutte le modifiche in Active Directory, compreso l'attributo nTsecurityDescriptor, che memorizza essenzialmente i permessi del rispettivo oggetto. Ancora meglio sarebbe una soluzione in grado di annullare tali modifiche! Semperis Directory Service Protector (DSP ) è uno strumento di questo tipo, ma potete anche utilizzare script disponibili pubblicamente e le vostre schermate per documentare il vostro lavoro.

Idealmente, avete piani di test e stakeholder pronti a convalidare le applicazioni, gli strumenti e i processi di gestione degli utenti e dei clienti più critici. Dovrete raccogliere feedback dopo aver apportato la modifica delle autorizzazioni. L'esecuzione dei test sugli oggetti della prima OU bloccata fornirà indicazioni sui potenziali problemi da risolvere prima di bloccare un'altra OU e così via.

Alla fine, sarete pronti a rimuovere completamente il gruppo Utenti autenticati dal gruppo Accesso compatibile pre-Windows 2000. A questo punto, assicuratevi di riattivare l'ereditarietà dei permessi sulle UO utilizzate per i test. Ripristinate le precedenti autorizzazioni esplicite concesse a quel livello. L'utilizzo di strumenti adeguati per rilevare tutte le modifiche nella foresta di Active Directory ridurrà gli sforzi anche in questa fase.

Principali indicazioni per le impostazioni di Accesso compatibile pre-Windows 2000 in Windows Server 2025 e precedenti

Active Directory è piena di campi minati di sicurezza che i cyberattaccanti possono sfruttare. (Per identificare le potenziali lacune di sicurezza nel vostro ambiente, scaricate Purple Knightuno strumento gratuito di valutazione della sicurezza di Active Directory che identifica oltre 100 indicatori di esposizione o compromissione con indicazioni su come affrontarli). Ma adottare Windows Server 2025 o Windows Server 2022 non significa necessariamente abbandonare tutte le impostazioni precedenti.

Se non altro, considerate di apportare queste modifiche alle impostazioni di configurazione relative alla compatibilità pre-Windows 2000:

• Non pensateci due volte a rimuovere Anonymous e Everyone dal gruppo di accesso compatibile con i sistemi pre-Windows 2000 in ogni dominio della vostra foresta AD.
• Fate lo stesso per gli Utenti autenticati, ma fate attenzione all'impatto potenziale e siate pronti a ripopolare il gruppo con sistemi o utenti che potrebbero fare affidamento sulle autorizzazioni concesse.
• Rimuovere le autorizzazioni di lettura predefinite per gli Utenti autenticati dai gruppi sensibili per limitare chi può enumerare i loro membri. Consultate il mio blog su come farlo per i gruppi di amministratori AD integrati.

Dovete decidere da soli se rimuovere il gruppo Utenti autenticati per aumentare la sicurezza di Active Directory. Potreste scegliere di accettare il rischio e continuare a vivere con le vecchie autorizzazioni di Windows NT nella vostra Active Directory. Ma seguite questa strada solo dopo aver compreso attentamente il potenziale pericolo.