redircmp redirusr contenitori predefiniti GPO: guida AD

Che cosa sono i contenitori predefiniti in Active Directory?

La domanda pratica alla base di redircmp redirusr contenitori predefiniti GPO riguarda dove vengono collocate le nuove identità e se tale posizione appartiene alla struttura di criteri prevista. Active Directory fornisce CN=Computers e CN=Users quando viene installato il dominio. Sono contenitori, anziché unità organizzative. La guida Microsoft alla redirezione dei contenitori ne spiega il ruolo predefinito, mentre la panoramica dei Criteri di gruppo identifica l'OU come il livello più basso di AD a cui è possibile assegnare Criteri di gruppo.

Non è possibile collegare direttamente un GPO a questi contenitori predefiniti. Questo non significa che i loro computer e utenti non ricevano alcun Criterio di gruppo: i GPO collegati al sito e al dominio possono comunque applicarsi e i criteri locali restano pertinenti. La lacuna è più specifica. Un oggetto in CN=Computers si trova fuori dal sottoalbero di un criterio collegato soltanto all'OU delle workstation o dei server. La documentazione di Redircmp di Microsoft conferma l'assenza di un collegamento diretto dei Criteri di gruppo al contenitore predefinito. Le regole di ambito di sito, dominio e OU sono documentate nella panoramica dei Criteri di gruppo citata sopra.

Questa guida distingue quattro domande: dove risiedono attualmente gli oggetti, dove li collocherà la futura creazione predefinita, quali criteri raggiungono realmente il client e quali account computer richiedono una revisione del provisioning. Un rilievo sul contenitore predefinito risponde alla prima domanda. La redirezione affronta la seconda. Nessuno dei due stabilisce lo stato LAPS del client o la sicurezza di un account macchina predisposto.

Funzionamento: destinazione e ambito dei criteri sono separati

La creazione predefinita segue un riferimento della directory

Microsoft documenta le destinazioni predefinite nell'attributo wellKnownObjects del dominio. Le API di creazione meno recenti consultano questi riferimenti per utenti, gruppi e computer. Le utilità di redirezione modificano i riferimenti verso OU selezionate dall'amministratore; non trasformano i contenitori originali in OU. I nuovi oggetti creati tramite i percorsi predefiniti interessati utilizzano poi la nuova destinazione. KB324949 descrive sia i riferimenti sia le operazioni che ne dipendono.

Un flusso di aggiunta al dominio può anche fornire esplicitamente una destinazione. La documentazione di netdom join descrive /ou e indica che la creazione dell'account usa la destinazione computer predefinita del dominio quando l'opzione viene omessa. In un'installazione standard senza redirezione è CN=Computers; dopo la redirezione può essere l'OU designata. Un account esistente riutilizzato per l'aggiunta al dominio costituisce un altro caso. Evitare quindi di presumere che ogni aggiunta crei necessariamente un nuovo oggetto nel contenitore predefinito.

Per gli utenti, redirusr modifica la posizione di creazione predefinita di utenti, gruppi e account utente di trust creati tramite le API documentate. La posizione di un gruppo non significa che il gruppo stesso elabori la configurazione utente come un utente connesso. Tenere distinti l'inventario degli account e l'elaborazione dei criteri e conservare gli account predefiniti, salvo che una modifica esaminata separatamente richieda diversamente. S1 descrive l'insieme più ampio di oggetti interessati dalla destinazione Users.

La collocazione in un'OU crea un percorso idoneo, non un controllo completato

L'ambito dei Criteri di gruppo segue i collegamenti a siti, domini e OU, inclusa la gerarchia pertinente delle OU superiori. Spostare un computer nell'OU prevista può inserirlo in quella gerarchia, ma resta necessario verificare l'elaborazione e le impostazioni previste. La panoramica Microsoft descrive l'ambito basato sulla posizione e l'elaborazione lato client.

La nostra guida al filtro di sicurezza dei GPO affronta il livello successivo: ambito dei collegamenti, autorizzazione Read del computer, autorizzazione Apply dell'utente e distinzione tra consentire il recupero e ampliare i destinatari. Spiega che la posizione corretta e un criterio collegato non bastano senza le autorizzazioni e le condizioni di elaborazione richieste. Eseguire questa revisione dopo aver corretto la collocazione.

LAPS aggiunge propri requisiti di distribuzione. La procedura Windows LAPS con archiviazione in AD di Microsoft distingue l'autorizzazione di scrittura del dispositivo, l'autorizzazione di recupero della password, i criteri del dispositivo e la verifica degli aggiornamenti della directory. Un computer fuori da un'OU che costituisce l'unica fonte dei suoi criteri LAPS può quindi avere un problema di copertura; un computer che riceve criteri equivalenti attraverso un altro percorso supportato potrebbe non averlo.

La guida correlata alle lacune di copertura LAPS esamina distribuzione parziale, archiviazione legacy, diritti di recupero eccessivi e prove necessarie per verificare la rotazione. Fornisce la revisione successiva quando la collocazione rivela una possibile lacuna. Contare i computer in CN=Computers non misura i computer privi di LAPS.

Misurare la collocazione prima di cambiare le destinazioni predefinite

1. Inventariare i computer nel contenitore predefinito

Usare un dominio definito e registrare base di ricerca, momento della raccolta, stato di abilitazione e identificatori degli oggetti. Il seguente esempio per il lettore adatta i parametri documentati Filter, SearchBase, SearchScope e Properties di Get-ADComputer. I nomi di dominio e di oggetto usati in questa guida sono segnaposto fittizi.

Get-ADComputer -Filter * -SearchBase 'CN=Computers,DC=contoso,DC=com' -SearchScope OneLevel -Properties Enabled,userAccountControl

L'obiettivo è enumerare i figli diretti per una revisione della collocazione. Questa query include gli account disabilitati, mentre il rilevatore di collocazione EtcSec esaminato li esclude. Mantenere separate queste popolazioni nel confrontare i risultati. Un inventario amministrativo e il conteggio di un rilevatore non devono necessariamente coincidere, perché i loro predicati differiscono.

Il conteggio di un contenitore misura la collocazione nella directory, non la copertura di protezione. Decidere quali oggetti appartengono alla produzione, quali sono account di preparazione approvati e quali richiedono indagine. Per ogni oggetto, registrare la destinazione proposta e il responsabile. Sono decisioni di revisione; il comando fornisce dati della directory, non una valutazione della protezione degli endpoint.

2. Inventariare gli utenti senza considerare il contenitore un'unica classe di account

L'esempio seguente sostituisce il contenitore Users predefinito nel modello documentato di ricerca in un contenitore e richiede lo stato di abilitazione tramite Properties. Get-ADUser documenta entrambi i parametri:

Get-ADUser -Filter * -SearchBase 'CN=Users,DC=contoso,DC=com' -Properties Enabled

Questo recupera utenti, anziché un inventario completo di tutti i gruppi e degli oggetti speciali nel contenitore. La guida alla redirezione di Microsoft tratta specificamente i gruppi predefiniti e gli account utente di trust. Prima della migrazione, distinguere gli utenti ordinari dagli account predefiniti o dipendenti da applicazioni e stabilire quali oggetti devono restare nella posizione attuale.

Esaminare insieme origine e destinazione. Un utente spostato in un'altra OU può entrare in una gerarchia diversa di criteri utente, proprio come un computer può entrare in una gerarchia diversa di criteri computer. Usare il modello di ambito dei Criteri di gruppo per identificare il cambiamento atteso prima di spostare l'oggetto, anziché considerare una vista della directory più ordinata come criterio di completamento.

3. Esaminare separatamente il segnale di provisioning degli account macchina

Un computer può essere predisposto in un'OU appropriata e richiedere comunque una revisione. Viceversa, un computer attivo nel contenitore predefinito non deve necessariamente corrispondere al segnale di preparazione. Per ottenere l'attributo sottostante, questo esempio usa il parametro Properties documentato di Get-ADComputer:

Get-ADComputer -Filter * -Properties userAccountControl

La documentazione UserAccountControl di Microsoft assegna a PASSWD_NOTREQD il valore 0x20 e a WORKSTATION_TRUST_ACCOUNT il valore 0x1000. Il collector li combina in 0x1020, decimale 4128, e verifica la presenza di entrambi i bit. Il predicato esatto è illustrato più avanti; non sostituirlo con un test di uguaglianza sull'intero attributo.

Per gli account corrispondenti, chiedere chi ha creato l'oggetto, quale richiesta di provisioning supporta, se la macchina prevista è stata aggiunta al dominio e quali prove indipendenti di attività esistono. Stabilire un periodo locale di revisione con il proprietario dell'account. Il rilevatore non fornisce una soglia di anzianità né una cronologia verificata delle aggiunte al dominio, quindi nessuna delle due deve apparire in un presunto risultato del rilevatore.

Rilevamento: correlare i segnali della directory con i risultati del client

Un oggetto collocato male richiede una revisione dell'ambito

Trattare la collocazione come un segnale per indagare la relazione prevista con i criteri. Registrare i GPO di riferimento attesi per il computer, le posizioni dei relativi collegamenti e i risultati effettivi del client. La documentazione gpresult definisce i report del set di criteri risultante e le opzioni di ambito computer e riepilogo usate qui:

gpresult /scope computer /r

Eseguire il controllo documentato per il lettore sul computer interessato con l'accesso appropriato. Confrontare i GPO applicati con la configurazione di riferimento prevista, quindi verificare le impostazioni rilevanti. Un report che mostra l'applicazione di criteri è una prova diversa da un backup LAPS riuscito o dallo stato effettivo di un'impostazione di auditing. Questo articolo non dichiara risultati ottenuti da un dominio reale.

Per Windows LAPS nativo con archiviazione in AD, la procedura di distribuzione di Microsoft identifica l'evento 10018 come prova che una nuova password è stata aggiornata correttamente in AD. Usarlo come controllo di risultato separato dove quella distribuzione si applica. Un evento assente richiede indagini su tempi e log disponibili; non è una prova ricavata dal DN dell'oggetto.

Le password predefinite storiche richiedono il contesto della versione

La creazione preventiva può essere un flusso legittimo. La guida Microsoft alle autorizzazioni di aggiunta al dominio descrive un amministratore che crea un account computer e un'altra identità autorizzata che lo riutilizza. Un account predisposto richiede gestione del ciclo di vita, ma la sola preparazione non dimostra una compromissione.

Esiste un rischio storico distinto. La documentazione NetProvisionComputerAccount descrive un'opzione esplicita che usa il nome della macchina in minuscolo come password iniziale e raccomanda di evitarla quando possibile. Questo descrive una specifica modalità di provisioning. La maschera UAC non legge il segreto e non può stabilire che l'opzione sia stata usata, che una password sia vuota o prevedibile o che l'autenticazione sia riuscita.

La versione è rilevante. Le novità di Windows Server 2025 documentate da Microsoft descrivono password iniziali degli account computer generate casualmente, controlli che rifiutano valori predefiniti derivati dal nome e l'impossibilità in ADUC/ADAC di creare account precedenti a Windows 2000. Il criterio documentato è Domain controller: Refuse setting default machine account password. Verificare le versioni dei controller di dominio, gli strumenti di creazione e questo criterio prima di applicare il modello storico agli account attuali. Un'identità abbandonata richiede comunque un proprietario e una decisione sul ciclo di vita anche se il suo segreto iniziale era casuale.

Correzione: reindirizzare le creazioni future e migrare gli oggetti esistenti (Remediation)

1. Progettare le OU di destinazione e le relative responsabilità

Scegliere le OU di destinazione secondo i requisiti di amministrazione e dei criteri. Decidere se la creazione predefinita debba arrivare in un'OU di preparazione o nella gerarchia finale di produzione e documentare chi completa la transizione. Un'OU chiamata «Staging» è utile soltanto quando i criteri previsti e il team responsabile sono chiari. La panoramica dei Criteri di gruppo tratta il bilanciamento tra delega e requisiti dei criteri.

I seguenti comandi adattano l'esempio 1 di New-ADOrganizationalUnit, sostituendo due nomi di destinazione e il dominio fittizio. L'esempio documentato crea un'OU con la protezione dall'eliminazione accidentale implicitamente abilitata. Ogni operazione è mostrata separatamente:

New-ADOrganizationalUnit -Name 'MyComputers' -Path 'DC=contoso,DC=com'

New-ADOrganizationalUnit -Name 'MyUsers' -Path 'DC=contoso,DC=com'

Preparare i criteri e la delega previsti prima di usare queste OU come destinazioni predefinite. Creare l'OU è un'operazione di gestione di oggetti; non collega un GPO, non autorizza il provisioning e non stabilisce che un dispositivo abbia elaborato una configurazione di riferimento.

2. Verificare i prerequisiti della redirezione

KB324949 richiede un livello funzionale di dominio Windows Server 2003 o superiore, un'OU di destinazione esistente, credenziali di amministratore del dominio e un PDC accessibile. Verificare la configurazione effettiva del dominio anziché dedurre il livello funzionale dal sistema operativo di un singolo server.

La precedente pagina Redircmp elenca versioni storiche dei livelli funzionali. Per questa procedura, usare il requisito «2003 o superiore» della KB attuale. La documentazione Redircmp richiede anche un prompt dei comandi con privilegi elevati. L'innalzamento del livello funzionale del dominio, se necessario, è una decisione di compatibilità separata; non va presentato come passaggio accessorio in un articolo sulla collocazione degli oggetti.

3. Modificare indipendentemente le destinazioni predefinite di computer e utenti

I due comandi seguenti riproducono gli esempi Microsoft di S1, omettendo il prefisso del prompt dei comandi. Ogni comando modifica una destinazione predefinita distinta:

redircmp ou=mycomputers,DC=contoso,dc=com

redirusr ou=myusers,DC=contoso,dc=com

La sintassi generica documentata è redircmp container-dn e c:\windows\system32\redirusr container-dn. L'argomento è il nome distinto dell'OU di destinazione. Sostituire la destinazione approvata; un comando riuscito riguarda la creazione futura tramite i percorsi predefiniti interessati.

Nessuna delle due utilità sposta gli oggetti esistenti. Gestire la collocazione futura e quella esistente come attività separate. Anche il provisioning con OU esplicita e il riutilizzo degli account richiedono una verifica propria, anziché essere dedotti dal nuovo valore predefinito.

4. Migrare gli oggetti esistenti selezionati con una revisione dei criteri

Valutare dipendenze applicative, scopo dell'account e cambiamento atteso dei criteri prima di selezionare ogni oggetto. Il comando seguente adatta la sintassi documentata Identity e TargetPath di Move-ADObject a un computer esistente fittizio:

Move-ADObject -Identity 'CN=PC01,CN=Computers,DC=contoso,DC=com' -TargetPath 'OU=MyComputers,DC=contoso,DC=com'

Selezionare gli oggetti reali tramite un inventario esaminato. Non usare uno spostamento indiscriminato in massa di tutto ciò che si trova in CN=Users o CN=Computers. La KB sulla redirezione tratta la compatibilità con le versioni precedenti e gli account predefiniti; la panoramica dei Criteri di gruppo spiega l'ereditarietà che rende operativamente significativo un cambiamento di destinazione.

Dopo lo spostamento, confermare la nuova posizione dell'oggetto e ripetere la revisione dei criteri del client. Chiudere l'attività di collocazione con prove della directory e ogni lacuna di protezione con prove relative a quella protezione. Sono controlli correlati con criteri di completamento diversi.

5. Delegare deliberatamente creazione, riutilizzo e gestione dei criteri

La guida alla delega del controllo di Microsoft distingue attività come aggiungere computer al dominio, gestire utenti e gestire collegamenti GPO. Delegare le attività necessarie nell'ambito appropriato. Cambiare una destinazione predefinita non concede all'identità che aggiunge il computer al dominio l'autorizzazione a creare o riutilizzare account in quella posizione.

Per gli account computer riutilizzati, verificare il proprietario e le autorizzazioni richieste rispetto alla procedura delle autorizzazioni di aggiunta al dominio. Diagnosticare un'aggiunta fallita entro questi requisiti. Non ampliare le appartenenze amministrative né aggirare i controlli di proprietà soltanto per far funzionare un flusso appena reindirizzato.

Per Windows LAPS nativo con archiviazione in AD, la procedura di distribuzione documenta l'autorizzazione del dispositivo ad aggiornare se stesso. Questo esempio sostituisce l'OU computer approvata in quel comando:

Set-LapsADComputerSelfPermission -Identity 'OU=MyComputers,DC=contoso,DC=com'

Questo non configura i criteri LAPS né stabilisce i diritti di recupero delle password. Verificare separatamente i criteri previsti e un aggiornamento riuscito del client. Esaminare anche la popolazione autorizzata al recupero; portare un computer nell'ambito dei criteri non risolve accessi di recupero eccessivi.

6. Esaminare gli account predisposti e provare i flussi futuri

Per ogni candidato alla preparazione, conservare scopo aziendale, proprietario, strumento di provisioning e prove a sostegno del suo uso continuato. Stabilire se l'account debba completare il provisioning, restare in un processo di preparazione approvato o entrare nella procedura di dismissione dell'organizzazione. Dalla maschera UAC non si deducono soglie universali di anzianità né regole automatiche di eliminazione.

Dopo la correzione, provare un flusso autorizzato di creazione di un nuovo account tramite il percorso predefinito e un flusso che riutilizza un account creato preventivamente. Verificare destinazione risultante, autorizzazioni, applicazione prevista dei GPO e risultati dei servizi applicabili. Le autorizzazioni di aggiunta al dominio e le regole di destinazione netdom di Microsoft spiegano perché questi flussi vadano considerati separatamente.

Tutti i comandi di questa guida sono esempi documentati per il lettore o adattamenti identificati esplicitamente. Non sono stati eseguiti su un dominio AD per questo articolo e non costituiscono prove di redirezione, migrazione o rotazione riuscite.

Come EtcSec rileva questo problema

Le descrizioni seguenti riflettono le implementazioni Detect() esaminate nel commit etc-collector b767fc1ef7ea4cf52d797d5aea1dd4c2d3d07d7c. I percorsi seguenti sono relativi a public/internal/audit/detectors/.

COMPUTER_WRONG_OU, in ad/computers/organization/wrong-ou.go:35, ignora i computer disabilitati, converte il DN in minuscolo e cerca ,cn=computers,dc= alle righe 39–49. Riporta una gravità Low. È un test di sottostringa, anziché un confronto analizzato del genitore dell'oggetto con un'OU di destinazione configurata. Non inventaria l'applicazione effettiva dei GPO né stabilisce l'assenza di LAPS, hardening o auditing.

COMPUTER_PRE_CREATED, in ad/computers/status/pre-created.go:35, verifica UserAccountControl & 0x1020 == 0x1020 alle righe 38–41. Sono consentiti bit aggiuntivi, incluso lo stato disabilitato. Il suo rilievo Medium non contiene condizioni sul DN, soglie di anzianità, test della cronologia di accesso o ispezioni del valore segreto. Il nome del rilievo identifica un segnale di revisione della preparazione; il predicato non dimostra che il computer non sia mai stato aggiunto al dominio.

Un controllo adiacente, SERVER_NO_ADMIN_GROUP, è stato esaminato ma non è associato a questo articolo. In ad/computers/organization/server-no-admin-group.go:43, seleziona i computer abilitati classificati euristicamente come server e verifica la copertura tramite collegamenti abilitati a dati analizzati di Restricted Groups contenenti un elenco non vuoto di membri di Administrators. Le funzioni ausiliarie si trovano alle righe 102–186. Non rileva specificamente la residenza in CN=Computers, non calcola il filtraggio effettivo né ispeziona i membri locali effettivi del server. Senza dati di criteri GPO forniti, il conteggio zero non dimostra conformità.

Usare questi rilievi per scegliere il passaggio di verifica successivo. Correggere la collocazione, verificare il provisioning futuro, accertare la protezione effettiva del client e risolvere separatamente la proprietà degli account predisposti. Un predicato di directory che non corrisponde più è una prova utile per quel predicato; una correzione operativa riuscita richiede le corrispondenti prove di risultato.