Gruppo Pre-Windows 2000 Compatible Access Active Directory

Che cos’è il gruppo Pre-Windows 2000 Compatible Access?

Il gruppo Pre-Windows 2000 Compatible Access in Active Directory può concedere un ampio accesso in lettura alla directory, ma gli attributi leggibili dal chiamante dipendono dalle ACE dell’oggetto. «Lettura dell’intera directory» non significa che ogni segreto sia leggibile, e l’appartenenza non garantisce l’enumerazione LDAP anonima. Microsoft documenta sia i controlli di accesso agli oggetti sia una restrizione LDAP separata. Requisiti di accesso delle funzioni di gestione della rete, restrizioni LDAP anonime.

Pre-Windows 2000 Compatible Access è il gruppo di sicurezza incorporato identificato da S-1-5-32-554, situato sotto CN=Builtin nel dominio. Microsoft lo descrive come un meccanismo di compatibilità per client Windows NT 4.0 e precedenti, con accesso in lettura alle informazioni su utenti e gruppi. Non è protetto da AdminSDHolder, e la tabella dei gruppi di Microsoft indica che non può essere spostato fuori dal contenitore predefinito. Esaminatene i membri anziché eliminare o spostare il gruppo. Gruppi di sicurezza di Active Directory.

Un’indagine utile pone quattro domande: quali entità di sicurezza sono membri, quali autorizzazioni ricevono, quale interfaccia accetta le loro richieste e quali applicazioni hanno ancora bisogno di queste letture. Tenete separate le risposte nel registro della modifica. Il numero di membri fornisce il primo indizio; non risolve le altre tre domande.

Definite i criteri di successo della revisione prima di modificare l’accesso. Per un percorso anonimo non necessario, il risultato desiderato è una riduzione documentata di quel percorso mentre le funzioni autenticate necessarie continuano a funzionare. Per un account di servizio, può trattarsi di sostituire autorizzazioni di compatibilità ampie con un accesso verificato agli attributi che richiede effettivamente. Per una dipendenza irrisolta, il risultato può essere un’eccezione con un responsabile e un piano di test. Questi sono risultati operativi proposti, non osservazioni sul vostro dominio né un’affermazione secondo cui ogni appartenenza sarebbe sfruttabile.

L’appartenenza iniziale dipende dalla creazione del dominio

La specifica del protocollo collega l’appartenenza iniziale al sistema operativo del primo controller di dominio e alla modalità di autorizzazione scelta dall’amministratore. Documenta questi casi. MS-ADTS 6.1.1.4.12.14.

Dire «Everyone è sempre il membro predefinito» perde questa distinzione. Le indicazioni di Microsoft sull’accesso delle applicazioni spiegano inoltre che aggiungere un DC Windows Server 2003 a un dominio Windows 2000 esistente non modifica la precedente scelta di compatibilità. Un dominio aggiornato può quindi conservare una scelta più vecchia. KB331951: applicazioni e informazioni di autorizzazione.

Usate questa cronologia per interpretare uno stato di riferimento, non per approvare ogni membro attuale. Un’impostazione predefinita storica potrebbe non soddisfare più un’esigenza aziendale, mentre un’aggiunta successiva potrebbe supportare un’applicazione. L’elenco attuale non può dirvi chi abbia aggiunto una voce né perché. Registrate «origine sconosciuta» quando i registri di distribuzione e i registri delle modifiche conservati non rispondono alla domanda.

Funzionamento: appartenenza, ACE e controlli di protocollo

Everyone da solo non è Anonymous

I requisiti NetAPI di Microsoft richiedono esplicitamente l’appartenenza di Anonymous per l’accesso anonimo alle informazioni sui gruppi: il normale token anonimo non include il SID di Everyone. Il comportamento di Windows 2000 e l’override EveryoneIncludesAnonymous=1 sono eccezioni documentate nella stessa pagina. Su un sistema moderno con il normale comportamento dei token, Everyone da solo non equivale ad Anonymous Logon. L’appartenenza esplicita di Anonymous fornisce un percorso di autorizzazione, soggetto alle altre restrizioni dell’interfaccia. Requisiti di accesso delle funzioni di gestione della rete.

L’accesso in lettura e l’enumerazione hanno condizioni proprie. NetQueryDisplayInformation restituisce informazioni che il chiamante può leggere; richiede List Contents sull’oggetto Domain ed Enumerate Entire SAM Domain sull’oggetto SAM Server nel contenitore System. È un percorso concreto di autorizzazione da indagare, non una promessa che qualsiasi client di rete possa elencare ogni oggetto. NetQueryDisplayInformation.

LDAP ha un controllo separato

Windows Server 2003 ha introdotto un blocco predefinito delle operazioni LDAP anonime oltre ai bind e alle ricerche rootDSE. Il settimo carattere di dsHeuristics, impostato a 2, rimuove questo blocco; le operazioni richiedono comunque le autorizzazioni ACL. Aggiungere Anonymous a questo gruppo non modifica tale attributo. Viceversa, controllare il blocco LDAP non dimostra la sicurezza di un’altra interfaccia di enumerazione. KB326690: operazioni LDAP anonime.

Per questo meccanismo separato, leggete l’accesso LDAP anonimo e il controllo dsHeuristics. L’articolo tratta l’impostazione LDAP e la verifica di bind e ricerche. Qui il tema è il percorso di autorizzazione del gruppo di compatibilità. Usate l’articolo collegato per indagare quel controllo, verificando le decisioni tecniche sulla documentazione Microsoft.

Da dove provengono le autorizzazioni di lettura ereditate

Il descrittore di sicurezza predefinito di Domain-DNS pubblicato contiene autorizzazioni per RU. Il riferimento Microsoft alle stringhe SID definisce RU come alias di Pre-Windows 2000 Compatible Access. Questo estratto proviene dalla sezione Windows 2000 Server della pagina. Mostra autorizzazioni a livello radice ed ereditabili; confrontate la versione appropriata e la DACL effettiva del vostro dominio prima di basarvi su di esso. Classe Domain-DNS, stringhe SID.

(A;CI;LC;;;RU)
(A;;RC;;;RU)
(OA;CIIO;RPLCLORC;;bf967aba-0de6-11d0-a285-00aa003049e2;RU)
(OA;CIIO;RPLCLORC;;bf967a9c-0de6-11d0-a285-00aa003049e2;RU)

In SDDL, A e OA sono forme di ACE di autorizzazione; CI indica l’ereditarietà dei contenitori e IO la sola ereditarietà. RP significa Read Property, LC List Children, LO List Object e RC Read Control. La maschera dei diritti e i flag di ereditarietà sono campi separati, quindi una voce ereditata specifica per oggetto non va interpretata come un’autorizzazione senza restrizioni sulla radice stessa. Stringhe ACE.

I due GUID delle classi ereditate identificano User e Group. Computer è una sottoclasse di User: includete i computer nella revisione, senza inventare una ACE separata diretta a Computer in questo estratto. I riferimenti delle classi pubblicano descrittori predefiniti versionati; la vecchia voce User non dimostra che ogni utente attuale abbia una DACL identica. Classe User, classe Group, classe Computer.

Il descrittore completo di Domain-DNS include anche ACE di lettura dei set di proprietà User. Il riferimento Sam-Server mostra separatamente una voce RU con RPLCLORC. Questi valori predefiniti spiegano percorsi da misurare; non sostituiscono l’ispezione dell’ereditarietà, delle voci esplicite e degli oggetti protetti di un dominio reale. Descrittore Domain-DNS, classe Sam-Server.

Misurare il gruppo effettivo e le autorizzazioni di lettura

Gli esempi seguenti adattano parametri documentati delle cmdlet e la sintassi di dsacls. Non sono stati eseguiti su un dominio. Sostituite il server e i nomi distinti fittizi con valori risolti nel vostro ambiente. Eseguiteli da una postazione amministrativa appropriata con gli strumenti e le autorizzazioni di lettura necessari. Conservate separatamente l’output e gli errori di ogni comando, affinché una ricerca non riuscita non possa essere scambiata per un risultato senza problemi.

Passaggio 1: acquisire i membri diretti

Iniziate dal nome inglese noto, quando esiste. Questo esempio adatta i parametri Identity e Server documentati della cmdlet di appartenenza. Get-ADGroupMember.

Get-ADGroupMember -Identity "Pre-Windows 2000 Compatible Access" -Server "dc01.contoso.com"

Identificate poi il gruppo incorporato tramite il SID stabile e richiedete la proprietà grezza member. L’esempio Microsoft di Get-ADGroup usa questo schema con un altro SID incorporato; questa variante lo sostituisce con il SID 554. Get-ADGroup.

Get-ADGroup -Identity "S-1-5-32-554" -Properties member -Server "dc01.contoso.com"

Usate questa identità anche per la vista dell’appartenenza diretta. La cmdlet accetta un SID come Identity. Opzioni di identità di Get-ADGroupMember.

Get-ADGroupMember -Identity "S-1-5-32-554" -Server "dc01.contoso.com"

Confrontate i membri risolti con i riferimenti grezzi, soprattutto quando fallisce la risoluzione di identità speciali o di entità di sicurezza esterne. Registrate il DN e il SID del gruppo, il DC contattato e l’identità di ogni membro. Un errore di risoluzione non equivale a un gruppo vuoto. Indagate l’oggetto referenziato prima di trarre una conclusione o preparare una rimozione.

Conservate questa vista diretta per confrontarla con il conteggio dei membri del collector. -Recursive risponde a una domanda diversa: la cmdlet percorre la gerarchia del gruppo per restituire membri senza oggetti figlio. Una revisione ricorsiva registrata separatamente può aiutare a indagare le entità di sicurezza annidate, ma non deve sostituire silenziosamente lo stato di riferimento diretto. Comportamento ricorsivo di Get-ADGroupMember.

Nel registro delle evidenze proposto, indicate esplicitamente la ricerca riuscita, la ricerca fallita e il riferimento irrisolto. Conservate i valori grezzi originali accanto alle annotazioni. Ciò rende verificabile il confronto successivo: un nome visualizzato che scompare potrebbe essere una differenza di risoluzione, mentre un valore grezzo di appartenenza modificato merita un’indagine. Evitate di conservare come unica evidenza un comodo rapporto formattato, soprattutto quando un altro revisore dovrà riprodurre la decisione.

Passaggio 2: ispezionare la radice e discendenti rappresentativi

Con il DN di un oggetto e senza opzioni di modifica, dsacls mostra le ACE dell’oggetto. Lo strumento può anche modificare le autorizzazioni, quindi conservate la forma di sola lettura mostrata qui. Il riferimento Microsoft richiede un prompt dei comandi con privilegi elevati e l’autorizzazione Read sull’oggetto di destinazione. Questi quattro comandi sono adattamenti che usano oggetti fittizi. Riferimento Dsacls.

dsacls "DC=contoso,DC=com"

dsacls "CN=Alice,OU=Users,DC=contoso,DC=com"

dsacls "CN=AppReaders,OU=Groups,DC=contoso,DC=com"

dsacls "CN=PC01,OU=Computers,DC=contoso,DC=com"

Per ogni campione, registrate il destinatario delle autorizzazioni, il tipo di autorizzazione o negazione, i diritti, l’ereditarietà, l’ambito della classe e quello dei set di proprietà. Identificate le voci per il SID 554 anche quando il nome visualizzato è localizzato. Includete oggetti usati dalle applicazioni in esame ed esempi con impostazioni di ereditarietà diverse. Un singolo oggetto utente ordinario è un campione, non un risultato di accesso effettivo per tutto il dominio.

La distinzione è rilevante per il writeback delle password: Microsoft documenta le autorizzazioni necessarie sulla radice e quelle ereditate dai discendenti, poi chiede agli amministratori di ispezionare le autorizzazioni effettive dell’account connettore. Leggere una DACL e provare l’operazione di un chiamante risponde a domande diverse. Usate entrambi i metodi per convalidare una dipendenza. Autorizzazioni per il writeback delle password.

Passaggio 3: costruire un registro delle dipendenze

Per ogni entità di sicurezza mantenuta, proponete un registro contenente il responsabile, l’applicazione e la versione, l’identità chiamante, gli attributi richiesti, il protocollo, gli oggetti di destinazione e il test funzionale. Includete l’errore che giustificherebbe un ripristino. Un nome account simile a quello di un prodotto è un indizio per l’indagine, non la prova di un’azione del programma di installazione.

Questa revisione è diversa anche da quella su Everyone e Authenticated Users nei gruppi AD privilegiati. Quell’articolo esamina identità ampie inserite direttamente in gruppi privilegiati e l’appartenenza privilegiata permanente. Qui il ruolo documentato del gruppo è l’autorizzazione di lettura per compatibilità; non trasformate il conteggio dei membri in un’affermazione di appartenenza amministrativa diretta.

Rilevamento: stabilire lo stato e monitorare le modifiche di appartenenza

Combinate l’inventario basato sui SID con una traccia delle modifiche. La documentazione Microsoft degli eventi di sicurezza colloca 4732 e 4733 in Audit Security Group Management, con un evento per ogni membro aggiunto o rimosso. Possono essere generati su controller di dominio, server membri e postazioni di lavoro; selezionate i registri dei DC rilevanti per il gruppo del dominio. Evento 4732, evento 4733.

Una regola di monitoraggio proposta dovrebbe confrontare TargetSid con S-1-5-32-554, conservare MemberSid e i campi del soggetto, e confrontare le modifiche con le attività approvate. Confrontare i SID evita di dipendere da un nome gruppo tradotto. Provate la mappatura dei campi nella vostra pipeline di raccolta prima di considerare la regola una copertura effettiva. I nomi dei campi provengono dagli esempi XML degli eventi; questa regola è una proposta operativa, non un rilevamento SIEM distribuito. Campi dell’evento 4732.

Questi eventi registrano modifiche di appartenenza. Non mostrano quali attributi siano stati letti, non scoprono tutte le dipendenze applicative e non confermano un’enumerazione anonima riuscita. L’assenza di eventi non è conclusiva senza criteri di audit, raccolta e conservazione funzionanti. Affiancate ai log lo stato salvato e i test funzionali autorizzati, invece di considerare uno di questi elementi una valutazione completa dell’accesso.

Correzione: rimuovere gli accessi non necessari per fasi (Remediation)

Questo è un processo di modifica proposto in base ai meccanismi documentati, non un’istruzione universale di Microsoft di svuotare il gruppo. Conservate lo stato precedente, provate le dipendenze e modificate membri selezionati. L’appartenenza è una modifica di un gruppo del dominio: chiamarla «progetto pilota su una OU» non limita a una OU l’effetto della rimozione di un membro.

Passaggio 1: distinguere le impostazioni storiche predefinite dalle deviazioni successive

Usate l’inventario dei SID e i valori grezzi di member riportati sopra. Confrontateli con i registri disponibili di creazione e aggiornamento, poi classificate le voci come impostazioni predefinite spiegate, aggiunte applicative documentate o appartenenze senza spiegazione. Sottoponete ogni categoria alla stessa revisione dell’esigenza attuale. La tabella di appartenenza iniziale spiega l’origine; non è un’esenzione dalla revisione. Specifica MS-ADTS dell’appartenenza.

Passaggio 2: risolvere le dipendenze documentate prima della rimozione

Le fonti seguenti forniscono dipendenze specifiche e alternative da indagare. Rispettatene i limiti anziché estenderle a ogni distribuzione di accesso remoto o sincronizzazione.

Fonti: risoluzione dei problemi VPN NT4, registrare un NPS, accesso TGGAU, autorizzazioni per il writeback delle password.

La registrazione NPS non dimostra un requisito di Anonymous. Per TGGAU, l’alternativa Windows Authorization Access richiede una verifica propria delle autorizzazioni: le indicazioni di Microsoft distinguono i domini nuovi da quelli in modalità mista e aggiornati in cui al gruppo non è stato concesso automaticamente l’accesso necessario. Non sostituitelo con un gruppo privilegiato solo per far scomparire un errore di accesso negato. TGGAU e WAA.

Le indicazioni Entra Connect avvertono esplicitamente di problemi di writeback quando manca Authenticated Users, soprattutto con versioni meno recenti. La sezione SAM-server distingue inoltre le autorizzazioni dirette di Authenticated Users dall’accesso tramite questo gruppo. Questa dipendenza documentata impedisce una raccomandazione indiscriminata di rimuovere tutte le identità ampie. Risoluzione dei problemi di writeback.

Exchange rimane non dimostrato come origine automatica dell’appartenenza in questo contesto. L’appendice B indica che l’installazione di Exchange può creare account e gruppi aggiuntivi in Builtin e Users; non dimostra aggiunte automatiche al SID 554 né le versioni interessate. Trattate le voci con nomi Exchange e le appliance come questioni che richiedono evidenze specifiche del prodotto e test funzionali. Appendice B.

Passaggio 3: simulare una rimozione selezionata

Date priorità all’indagine su Anonymous, poi su Everyone con il comportamento effettivo dei token, e sugli account senza un’esigenza confermata. Conservate Authenticated Users finché le sue dipendenze non saranno comprese. Scegliete l’esatto membro risolto e provate in un dominio di test rappresentativo prima di programmare la modifica al dominio di produzione.

L’adattamento seguente usa identificatori SID documentati e -WhatIf. Simula la rimozione di Anonymous; non è un comando eseguito per questo articolo. Convalidate prima l’entità di sicurezza risolta. Remove-ADGroupMember.

Remove-ADGroupMember -Identity "S-1-5-32-554" -Members "S-1-5-7" -Server "dc01.contoso.com" -WhatIf

Dopo i test e la decisione di modifica dell’amministratore, eseguite solo la rimozione selezionata con la normale conferma. La cmdlet documenta il comportamento di conferma; evitate un ciclo che svuoti il gruppo o elimini la revisione di ogni membro. Un’anteprima -WhatIf non esegue la rimozione né dimostra che riuscirebbe; non può prevedere il comportamento applicativo dopo una modifica reale. Parametri di rimozione e conferma.

Passaggio 4: verificare il funzionamento, le autorizzazioni e la traccia della modifica

Proponete una finestra di modifica del dominio, un membro alla volta, con un responsabile del ripristino designato. Rileggete l’appartenenza sui DC usati dai servizi interessati dopo la replica, quindi ripetete le operazioni autorizzate dell’applicazione nel contesto di sicurezza pertinente. Le indicazioni Microsoft sul writeback trattano specificamente i ritardi di replica e l’uso di un DC preferito durante la correzione delle autorizzazioni. Considerazioni sulla replica.

Esaminate gli errori di accesso applicativo e l’evento 4733 per la rimozione prevista; monitorate 4732 per le aggiunte, compreso un ripristino controllato. Se il funzionamento peggiora, ripristinate soltanto l’appartenenza modificata tramite il processo di recupero approvato e indagate la dipendenza. Non prescrivete una durata arbitraria di monitoraggio né un riavvio universale dei DC: l’istruzione di riavvio del documento VPN NT4 appartiene al suo specifico scenario storico. 4733, 4732, scenario NT4.

Come EtcSec rileva questa configurazione

Il controllo di etc-collector PRE_WINDOWS_2000_ACCESS è implementato in ad/groups/membership/pre-windows-2000-access.go:24. Il Detect() esaminato converte in minuscolo il CN e il SAMAccountName di ogni gruppo, poi seleziona il primo gruppo il cui nome contiene pre-windows 2000 compatible access. Il suo Count è len(targetGroup.Members): vengono conteggiati tutti i membri raccolti, inclusi Authenticated Users e gli account applicativi. Il catalogo esaminato lo classifica come Medium con peso 1.

La funzione restituisce un risultato anche quando non trova alcun gruppo corrispondente o il conteggio è zero. I dettagli e il gruppo interessato sono inclusi solo quando IncludeDetails è abilitato, è stato trovato un gruppo e il conteggio è positivo. Queste affermazioni descrivono l’implementazione esaminata, non un audit eseguito sul vostro dominio.

Il controllo non verifica i SID del gruppo o dei membri, non ispeziona le ACE, non legge dsHeuristics, non espande le appartenenze annidate in questa funzione né prova l’accesso di un’applicazione. La corrispondenza per sottostringa inglese può non rilevare nomi localizzati e selezionare un nome corrispondente indesiderato; anche dati di input mancanti possono produrre zero. Usate le misurazioni basate sui SID per qualificare il segnale. Un conteggio positivo non dimostra l’appartenenza di Anonymous, e zero non dimostra che ogni percorso di lettura sia limitato.

COMPUTER_PRE_WINDOWS_2000 è esplicitamente fuori dall’ambito e dai tag di questo articolo. Il suo Detect(), esaminato separatamente in ad/computers/other/pre-windows-2000.go:43, confronta i valori non vuoti di OperatingSystem con Windows 95|Windows 98, senza distinguere maiuscole e minuscole. Non ispeziona i membri o le autorizzazioni di questo gruppo.

Concludete la revisione con i fatti accertati: identità risolte, percorsi ACL ispezionati, restrizioni di protocollo verificate, dipendenze provate e modifiche selezionate monitorate. Il rilevatore di appartenenza aiuta a dare priorità a questo lavoro; le evidenze determinano quali accessi possano essere rimossi senza compromettere il funzionamento.