Verifica AD dei PC in OU server: criteri prima dello spostamento

In cosa consiste una verifica AD dei PC in OU server?

Una verifica AD dei PC in OU server controlla se la posizione di un computer nella directory corrisponde al suo scopo reale e ai criteri che dovrebbe ricevere. Un computer abilitato che sembra una workstation all'interno di un'OU il cui nome richiama i server merita una revisione. La sola posizione non dimostra un errore nei criteri, un incidente di sicurezza o una violazione della conformità.

La domanda utile è precisa: spostare questo computer cambierebbe il risultato dei criteri previsto, e il responsabile può dimostrare che il cambiamento è appropriato? Partite dal ruolo effettivo del dispositivo e dalla convenzione delle OU dell'organizzazione. Conservate poi il risultato attuale dei criteri del computer, esaminate la destinazione proposta e testate un pilota approvato prima di estendere il cambiamento.

Questa guida affronta un segnale di classificazione di WORKSTATION_IN_SERVER_OU. Non introduce una struttura universale delle OU. Una gerarchia condivisa, un nome ereditato o un endpoint con uno scopo particolare documentato possono spiegare un riscontro. La revisione deve produrre una decisione sulla posizione con un responsabile identificato e prove dei criteri a supporto, compresa la decisione di mantenere la posizione attuale quando è giustificata.

Relazione tra posizione e ambito dei criteri

La documentazione Microsoft sull'elaborazione dei criteri di gruppo descrive l'elaborazione a livello locale, di sito, di dominio e di OU, comprese le OU superiori. L'ordine dei collegamenti, l'applicazione forzata, il blocco dell'ereditarietà, le sezioni disabilitate, il filtro di sicurezza e il filtro WMI influenzano il risultato. La grafia del nome di un'OU non è un'impostazione dei criteri.

Preparate un confronto tra origine e destinazione in GPMC. Registrate i collegamenti e l'ereditarietà pertinenti per ogni posizione, poi identificate quali impostazioni il responsabile del dispositivo prevede di mantenere, acquisire o perdere. Usate le identità dei criteri oltre ai nomi visualizzati, così da non confondere GPO con nomi simili nel registro della modifica. Risolvete le differenze prive di spiegazione prima di pianificare il pilota.

Per il livello delle autorizzazioni, leggete la nostra guida su Read per i computer, Apply mirato e filtro di sicurezza GPO. Read e Apply Group Policy sono distinti; il recupero da parte del computer e i destinatari previsti per l'applicazione richiedono controlli separati. Quella guida supporta la revisione dell'ambito qui descritta. Non dimostra che il nome di un'OU abbia causato un errore.

Quando l'esperienza utente dipende dal computer, esaminate anche il loopback. La documentazione Microsoft sull'elaborazione distingue Merge, che aggiunge l'elenco dei criteri utente basato sul computer, da Replace, che usa quell'elenco al posto di quello precedente. Registrate la modalità configurata e includete test utente rappresentativi quando è pertinente. Un risultato relativo al solo computer non può rispondere a ogni domanda sulle sessioni utente.

Esiste anche un problema distinto relativo ai contenitori predefiniti. La nostra guida su CN=Computers, reindirizzamento e risultati dei criteri client spiega che il contenitore predefinito non può avere un collegamento GPO diretto come un'OU. Reindirizzare le creazioni future, ricollocare gli oggetti esistenti e validare i risultati dei client sono attività distinte. Un oggetto già all'interno di un'OU chiamata Servers non richiede automaticamente quella procedura di reindirizzamento.

Rilevamento: identificare il dispositivo e conservarne il risultato

1. Confermare gli input del riscontro

Per ogni candidato, conservate il nome distinto, sAMAccountName, l'attributo di directory operatingSystem, lo stato abilitato, l'ora di raccolta e l'ambito di raccolta. Identificate quale parte del DN corrispondeva al modello di nome server. Una corrispondenza in un antenato ha una spiegazione amministrativa diversa da una corrispondenza nel genitore immediato, anche se il rilevatore accetta entrambe.

Chiedete al responsabile del dispositivo di verificarne il ruolo attuale e il sistema operativo tramite l'inventario attendibile degli endpoint dell'organizzazione o un controllo autorizzato del dispositivo. Riconciliate le discrepanze con gli attributi della directory. Un prefisso del nome è una pista di indagine; non è una prova indipendente che l'host sia attualmente un desktop o che debba essere spostato.

Usate questa matrice di revisione per tenere separate le prove:

2. Acquisire il RSoP del computer prima di cambiarne la posizione

Microsoft documenta Get-GPResultantSetOfPolicy come un cmdlet che scrive le informazioni RSoP in un file. La sua sintassi accetta Computer, ReportType e Path. Il seguente esempio per il lettore adatta quei parametri documentati a una workstation fittizia e a un nome di file per la baseline:

Get-GPResultantSetOfPolicy -Computer 'pc01.contoso.com' -ReportType Xml -Path 'C:\Reports\pc01-before.xml'

Usate il nome verificato del dispositivo, una directory disponibile per i report e un account autorizzato nel vostro ambiente. La guida Microsoft sui risultati dei criteri di gruppo documenta l'accesso remoto tramite l'autorizzazione delegata Remotely access Group Policy Results data sul dominio o sull'OU che contiene l'oggetto, oppure tramite l'appartenenza al gruppo Administrators locale del computer di destinazione. Verificate anche la connettività di rete verso la destinazione. Conservate il report con l'identità dell'oggetto, il DN originale, l'ora di acquisizione e il registro della revisione. Esaminate il contesto di registrazione restituito e la sezione computer del report per confermare che le prove riguardino il dispositivo previsto. Una query non riuscita lascia il risultato sconosciuto; non è una baseline vuota acquisita correttamente.

Il cmdlet restituisce risultati di registrazione. Microsoft indirizza gli amministratori a GPMC per la modellazione RSoP. Di conseguenza, questo report registra l'elaborazione osservata anziché prevedere il risultato nella destinazione. Confrontatelo con la baseline approvata ed elencate le differenze irrisolte prima di valutare uno spostamento. Quando un'impostazione governa un servizio o una protezione, pianificate anche un controllo operativo corrispondente.

Correzione: validare un pilota prima di spostare altri host (Remediation)

1. Scegliere una decisione documentata

Classificate il candidato esaminato come un'eccezione approvata, una discrepanza di classificazione o una modifica di posizione che richiede validazione. Registrate il responsabile, la spiegazione e le prove. Mantenere un oggetto può essere il risultato corretto se il suo ruolo e i criteri previsti sono già soddisfatti. Rinominare un dispositivo o un'OU soltanto per eliminare la corrispondenza con l'euristica non dimostra alcun miglioramento del risultato dei criteri.

Per uno spostamento proposto, documentate il DN di origine, la destinazione approvata, la differenza attesa nei criteri, il dispositivo pilota, i criteri di accettazione e il responsabile del ripristino. Confermate che la modifica riguardi lo stesso dominio e il computer selezionato. Una migrazione tra domini richiede una propria procedura sottoposta a revisione; esula dall'esempio di posizione di un singolo computer qui descritto.

2. Esaminare la singola operazione sulla directory

La documentazione Microsoft di Move-ADObject descrive Identity, TargetPath, WhatIf e Confirm. Il seguente esempio inserisce in quella sintassi un DN di computer fittizio e un'OU approvata fittizia:

Move-ADObject -Identity 'CN=PC01,OU=Servers,DC=contoso,DC=com' -TargetPath 'OU=Workstations,DC=contoso,DC=com' -WhatIf

-WhatIf mostra un'anteprima dell'operazione. Non sposta l'oggetto e non simula l'elaborazione delle GPO. Esaminate l'origine e la destinazione risolte prima di continuare. Non inviate mai tutti i riscontri tramite pipeline a un'operazione di spostamento: il predicato non conosce la decisione del responsabile, l'idoneità della destinazione o il piano di manutenzione approvato.

Dopo la validazione e l'autorizzazione, la singola operazione pilota può usare gli stessi parametri documentati con conferma:

Move-ADObject -Identity 'CN=PC01,OU=Servers,DC=contoso,DC=com' -TargetPath 'OU=Workstations,DC=contoso,DC=com' -Confirm

Sostituite ogni identificatore di esempio con i valori esaminati. La conferma è una richiesta di esecuzione; non sostituisce l'approvazione dell'organizzazione e non valida la progettazione dei criteri. Questi sono esempi documentati per il lettore, non comandi eseguiti contro un dominio AD per questo articolo.

3. Confrontare il risultato dopo il pilota

Verificate la nuova posizione nella directory e completate l'elaborazione dei criteri richiesta dal piano di test approvato. La documentazione Microsoft sull'elaborazione distingue l'avvio, l'accesso e l'aggiornamento in background; quest'ultimo non elabora tutte le estensioni. Registrate il contesto di elaborazione prima di interpretare un report raccolto dopo lo spostamento.

Acquisite un risultato separato per lo stesso computer usando i parametri RSoP documentati:

Get-GPResultantSetOfPolicy -Computer 'pc01.contoso.com' -ReportType Xml -Path 'C:\Reports\pc01-after.xml'

Confrontate i due report conservati con le modifiche attese, poi controllate le impostazioni pertinenti e i criteri di accettazione operativi. Quando il loopback è rilevante, includete i confronti approvati delle sessioni utente. Indagate su aggiunte, omissioni o errori inattesi prima di estendere il pilota. Usate la procedura di ripristino registrata se i criteri di accettazione non sono soddisfatti e verificatene l'esito, anziché presumere che ripristinare il DN ripristini ogni impostazione.

Chiudete la revisione con la decisione, le prove e le eccezioni ancora aperte. Un riscontro eliminato può confermare che la directory non corrisponde più a questa euristica. I report dei criteri e i controlli operativi stabiliscono se il risultato previsto è stato raggiunto. Non unite questi criteri di completamento in un unico stato verde.

Come EtcSec rileva questo caso

Questa sezione descrive soltanto WORKSTATION_IN_SERVER_OU, esaminato nel commit di etc-collector 20268a321609c193b79c5da6764f3f56950449cb, in public/internal/audit/detectors/ad/computers/organization/workstation-in-server-ou.go:37.

Il rilevatore ignora i computer contrassegnati come Disabled. Per i restanti computer forniti, cerca nell'intero DN i modelli non ancorati e senza distinzione tra maiuscole e minuscole ou=server e ou=datacenter. Questi modelli possono corrispondere a un antenato e a prefissi come OU=Serverless; non analizzano un nome esatto di OU genitore immediata.

Un oggetto selezionato viene classificato come workstation se il suo sAMAccountName inizia, senza distinzione tra maiuscole e minuscole, con ws, pc, laptop, desktop o nb, oppure se la sua stringa del sistema operativo contiene Windows 10, Windows 11, Windows 7 o Windows 8. È sufficiente una delle due condizioni. Ad esempio, un prefisso corrispondente può selezionare un oggetto senza una stringa del sistema operativo di workstation corrispondente. Sono test su stringhe, non un controllo in tempo reale del ruolo del dispositivo.

Il provider LDAP in public/internal/providers/ldap/client.go:515 fornisce gli oggetti computer, e parser.go:220–278 legge DN, nome account, sistema operativo e controllo account utente nel modello del computer. Lo stato disabilitato deriva dal controllo account utente. I valori configurati BaseDN e MaxComputers limitano l'inventario; un conteggio pari a zero va interpretato nell'ambito effettivo della raccolta.

Il riscontro è informativo. Il commento del codice identifica esplicitamente un'euristica del prodotto senza uno standard di denominazione del fornitore o normativo, e non registra un'attivazione confermata in laboratorio né una validazione mediante introduzione e annullamento. La descrizione del riscontro afferma un effetto GPO errato, ma il predicato esaminato non legge il ruolo effettivo o un report dei criteri risultanti e non può supportare tale affermazione causale.

Usate il riscontro per selezionare una revisione documentata. Confermate il ruolo e la convenzione locale, valutate il percorso dei criteri e conservate le prove prima/dopo per ogni spostamento approvato. Qui non si affermano un pilota AD riuscito, una correzione dei criteri o un risultato di laboratorio.