Gruppi con restrizioni amministratori locali: verificare prima del rilascio

Cosa controllano realmente i criteri di gruppi con restrizioni amministratori locali

La revisione dei criteri di gruppi con restrizioni amministratori locali parte da una domanda pratica: quali identità devono mantenere l'accesso amministrativo su ogni workstation o server membro? Una voce in una GPO è soltanto un elemento di prova. Prima di distribuire una configurazione di riferimento dei membri, confrontate la popolazione prevista con il gruppo effettivo, esaminate le due proprietà di appartenenza del criterio e dimostrate quali computer lo ricevono.

Questa guida descrive una procedura di verifica e distribuzione, confrontata con la documentazione Microsoft e l'implementazione di etc-collector il 4 ottobre 2026. I comandi sono esempi di consultazione destinati a un amministratore Windows autorizzato; nessuno è stato eseguito su un dominio per questo articolo. Non si dichiara alcuna modifica delle appartenenze né alcun risultato di distribuzione.

Microsoft documenta due operazioni diverse in Restricted Groups:

Microsoft supporta questo meccanismo per i gruppi locali, non per gestire i membri dei gruppi di dominio. Aggiungere un gruppo di sicurezza del dominio al gruppo Administrators locale di un computer è un'operazione diversa dalla modifica dei membri di quel gruppo di dominio. Questa procedura riguarda workstation e server membri; i controller di dominio richiedono un progetto di amministrazione separato.

Il gruppo locale è anche distinto dall'assegnazione dei diritti utente. Esaminate i privilegi GPO come SeDebug e SeTcb separatamente dai membri di Administrators locale. Una revisione dei membri non può certificare tali assegnazioni di privilegi.

Funzionamento: leggere il criterio prima di interpretare il rilievo

Nei file SYSVOL della GPO, esaminate Machine\Microsoft\Windows NT\SecEdit\GptTmpl.inf, inclusa l'intera sezione [Group Membership]. Registrate il GUID della GPO, il nome visualizzato, il controller di dominio di origine, l'ora della raccolta e l'esito della lettura del file. Conservate le righe originali insieme alla vista dell'editor dei criteri.

Il seguente è un modello illustrativo, che riflette il formato della chiave letto dal collector. I valori tra parentesi angolari sono segnaposto, non SID validi né una configurazione di riferimento distribuibile:

[Group Membership]
*S-1-5-32-544__Members = *<approved-domain-group-SID>,*<approved-local-account-SID>

Identificate l'entità di sicurezza prima di __, quindi controllate se il file effettivo contiene __Members, __Memberof, entrambi o nessuno dei due per quell'entità. Registrate separatamente un valore __Members esplicitamente vuoto e una chiave assente. Queste distinzioni non possono essere ricostruite dal solo array vuoto dei membri analizzati.

La procedura Microsoft per i modelli di sicurezza mostra le due aree di modifica: Members of this group e This group is a member of. L'articolo descrive il flusso storico dello snap-in di Windows Server 2003; usatelo per comprendere le proprietà, senza considerare la vecchia interfaccia o l'elenco delle piattaforme come indicazioni di distribuzione attuali.

Preferite una revisione basata sui SID quando i nomi visualizzati differiscono tra le lingue. La documentazione Microsoft sugli identificatori di sicurezza identifica S-1-5-32-544 come il gruppo Administrators predefinito. Conservate sia il SID sia il nome risolto nelle prove. Un nome localizzato valido in Windows non implica che il confronto di stringhe di un collector lo riconosca.

Non modificate manualmente un file SYSVOL di produzione per far scomparire un rilievo di audit. Esaminate e create la GPO prevista tramite il processo di gestione approvato, quindi ispezionate il file risultante e il comportamento degli endpoint.

Rilevamento: accertare i membri, l'ambito e le prove delle modifiche

Passaggio 1 — Acquisire lo stato iniziale dell'endpoint

Su ogni workstation o server membro selezionato, ottenete i membri diretti attuali prima di modificare il criterio. Microsoft fornisce questo esempio Get-LocalGroupMember esatto per un nome di gruppo inglese:

Get-LocalGroupMember -Group "Administrators"

Per selezionare il gruppo indipendentemente dalla lingua, la stessa documentazione definisce il parametro -SID. Questo esempio di consultazione usa quel parametro documentato con il SID del gruppo predefinito:

Get-LocalGroupMember -SID 'S-1-5-32-544'

Usate un contesto Windows PowerShell supportato; Microsoft precisa che il modulo LocalAccounts non è disponibile in PowerShell a 32 bit su un sistema a 64 bit. Salvate il risultato con l'identità del computer e la data e ora. Se il comando fallisce, conservate l'errore e contrassegnate quel dispositivo come non risolto, invece di registrare un gruppo vuoto.

Per ogni entità di sicurezza restituita, registrate il SID, l'account o gruppo risolto, il responsabile operativo e il motivo dell'accesso. Quando è presente un gruppo di dominio, esaminate separatamente le persone e i gruppi annidati che ricevono diritti tramite esso. L'elenco dei membri locali diretti, da solo, non indica chi ottiene effettivamente accesso attraverso quel gruppo.

Passaggio 2 — Dimostrare che il computer riceve il criterio previsto

Esaminate i collegamenti delle GPO, lo stato della configurazione computer, il filtro di sicurezza, il filtro WMI e l'ereditarietà. Includete dispositivi rappresentativi dell'ambito previsto e dispositivi che devono restarne esclusi. Non deducete l'applicazione dal nome descrittivo di una GPO o dalla presenza del suo file in SYSVOL.

Microsoft documenta gpresult per ottenere informazioni sul set risultante di criteri. Questi esempi di sola lettura combinano le opzioni documentate per l'ambito computer e l'output:

gpresult /scope computer /r
gpresult /scope computer /h computer-policy.html

Il primo visualizza un riepilogo; il secondo salva un report HTML. Eseguiteli in un contesto autorizzato che possa ottenere i dati dei criteri computer. Conservate le prove delle GPO applicate e negate, la data e ora e gli eventuali errori del report. Su ARM64, la pagina Microsoft specifica l'eseguibile gpresult di SysWow64 per l'opzione HTML.

Usate RSoP per indagare applicazione e precedenza, quindi corroborate i membri effettivi sull'endpoint. Né un report né un modello leggibile sostituiscono questa osservazione finale.

Passaggio 3 — Identificare gli altri meccanismi che modificano i membri

Inventariate gli elementi Local Users and Groups delle preferenze di Criteri di gruppo, le loro azioni e le regole di destinazione. La documentazione Microsoft sulle preferenze di Criteri di gruppo elenca questa estensione come un meccanismo per modificare utenti e gruppi locali. Chiedete anche al responsabile della gestione dei dispositivi quali script e profili MDM agiscono sullo stesso gruppo.

Per i dispositivi gestiti tramite MDM, ispezionate il CSP dei criteri LocalUsersAndGroups. L'azione Update può aggiungere o rimuovere i membri specificati conservando quelli non specificati; Restrict sostituisce i membri. Per l'azione Restrict di questo CSP sul gruppo Administrators predefinito, includete l'account Administrator predefinito nell'elenco dei membri da aggiungere; Microsoft documenta un errore se una sostituzione tenta di rimuoverlo. La documentazione avverte che applicare entrambi i criteri CSP LocalUsersAndGroups e RestrictedGroups a un dispositivo non è supportato. Tale avviso riguarda i due criteri CSP indicati; non è una regola universale di precedenza per ogni combinazione GPO/MDM.

Documentate quale sistema è responsabile dei membri per ciascuna popolazione di dispositivi. Risolvete le istruzioni sovrapposte prima del pilota; non tirate a indovinare quale meccanismo lascerà lo stato finale desiderato.

Passaggio 4 — Monitorare aggiunte e rimozioni

Le pagine degli eventi Microsoft confermano queste registrazioni nel log Security sotto Audit Security Group Management:

Raccogliete gli eventi dagli endpoint interessati, non soltanto dai controller di dominio. Per questa procedura, selezionate gli eventi il cui TargetSid è S-1-5-32-544 e conservate il computer, l'ora, MemberSid, l'identità del soggetto e SubjectLogonId. Verificate il corretto funzionamento della raccolta e dell'inoltro dell'audit prima di fare affidamento sull'assenza di eventi.

Confrontate le modifiche con il registro della distribuzione e i test applicativi. Un'aggiunta inattesa dopo un aggiornamento dei criteri può giustificare un'indagine su un'altra fonte di gestione o una modifica manuale; da sola non identifica la GPO responsabile né dimostra un attacco. Questi eventi descrivono modifiche dei membri, non l'elenco completo dei membri attuali.

Distribuire una configurazione di riferimento approvata dei membri (Remediation)

Passaggio 1 — Approvare la popolazione autorizzata

Create configurazioni di riferimento separate quando workstation e ruoli server hanno esigenze diverse. Per ogni entità di sicurezza mantenuta, richiedete un responsabile, uno scopo e un ambito. Per ogni rimozione proposta, chiedete al responsabile dell'applicazione o del supporto interessato di convalidarne l'impatto. Registrate le eccezioni con la popolazione di dispositivi, la giustificazione e la data di revisione.

Usate il modello di amministrazione a tier per definire responsabili, popolazioni amministrative e confini di accesso. Una configurazione di riferimento dei membri locali appartiene a questa architettura; non sostituisce la decisione su dove tali identità possano accedere.

Passaggio 2 — Stabilire una via di recupero utilizzabile

Prima della sostituzione, testate il processo di recupero approvato sui dispositivi pilota. Confermate l'account amministrativo locale designato, le sue appartenenze necessarie e la capacità del team autorizzato di recuperare l'accesso se la normale amministrazione del dominio fallisce. Tenete le credenziali fuori dalle esportazioni della revisione dei criteri e dai file di prova condivisi.

Windows LAPS gestisce ed esegue il backup delle password degli account amministratori locali sui dispositivi aggiunti supportati. Per un account di recupero gestito da LAPS, verificate la gestione della password e il recupero autorizzato separatamente dall'appartenenza dell'account e dalla via di accesso utilizzabile. La sola presenza di un criterio LAPS non completa il test di recupero.

Passaggio 3 — Preparare il criterio e i criteri di avanzamento del pilota

Eseguite il backup della GPO esistente e conservate le precedenti osservazioni dei membri. Preparate l'elenco approvato nell'editor dei criteri, esaminate il modello risultante e definite i collegamenti e i filtri esatti del pilota. Concordate le responsabilità di rollback e una procedura di ripristino dei membri, non soltanto della configurazione della GPO.

Non presumete che rimuovere un collegamento GPO ricrei tutti i membri rimossi durante l'applicazione. Richiedete una procedura di recupero testata che ripristini l'accesso necessario e intervenga sul meccanismo che ha autorità sui membri. Sospendete la distribuzione se raccolta, responsabilità, risoluzione dei nomi o ambito rimangono incerti.

Passaggio 4 — Convalidare dopo l'applicazione

Distribuite alla popolazione pilota tramite il processo di modifica approvato. Dopo l'elaborazione del criterio, ripetete i comandi di consultazione dei membri e gpresult indicati sopra. Confrontate i SID prima e dopo con l'elenco approvato e il comportamento documentato dell'account predefinito. Esaminate aggiunte e rimozioni durante la finestra prevista.

Chiedete ai responsabili delle applicazioni e del supporto di testare le attività amministrative reali, i processi di manutenzione e l'accesso di recupero. Ripetete le osservazioni dopo successive elaborazioni dei criteri o attività di gestione dei dispositivi per evidenziare meccanismi in conflitto. Un dispositivo inaccessibile o un test applicativo fallito rimane un criterio di distribuzione non soddisfatto.

Passaggio 5 — Estendere soltanto sulla base di prove registrate

Procedete per ruolo del dispositivo o popolazione amministrativa dopo l'accettazione dei risultati da parte del responsabile del pilota. Conservate esplicitamente le eccezioni, invece di nasconderle in un gruppo più ampio. Programmate successive revisioni dei membri e avvisi per gli scostamenti dallo stato approvato. Mantenete visibili nel report i dispositivi esclusi e non osservati.

Come EtcSec rileva questa configurazione

Il controllo M29_LOCAL_ADMIN_NOT_RESTRICTED di EtcSec è un segnale di revisione della configurazione. Il codice sorgente di etc-collector è stato letto al commit 15fc6399c215eabc415c370b762303cfcd7a353a, inclusi m29_local_admin.go:38, gptmpl_parser.go:367 e le righe SMB client.go:154 e :214.

I rami effettivi di Detect() sono:

Count 1 è il segnale di questo rilevatore, non un conteggio dei computer interessati. Il confronto non accetta altri nomi localizzati. Non valuta MembersSIDs, MemberOfSIDs, la popolazione autorizzata approvata, i collegamenti o l'applicabilità delle GPO, né i membri effettivi degli endpoint.

Il parser aggrega Members e Memberof in un'unica specifica per entità di sicurezza e crea tale specifica prima di controllare il suffisso. Un valore Members vuoto e una proprietà Members assente sono indistinguibili nell'array dei membri risultante. Una specifica corrispondente contenente soltanto Memberof può quindi sopprimere il rilievo senza stabilire una configurazione di riferimento di sostituzione tramite Members.

Il provider SMB popola i valori dei criteri quando la lettura di GptTmpl.inf riesce. Inserisce comunque un oggetto criterio quando tale lettura fallisce. Per questo controllo, una lettura fallita può assomigliare a una configurazione mancante; il rilievo non espone una distinzione dedicata al successo della raccolta. Anche una voce corrispondente in una GPO fuori dall'ambito effettivo di un computer può sopprimere il segnale.

La decisione di distribuzione deve identificare il criterio esatto, le popolazioni approvate, le osservazioni del pilota, il test di recupero e i dispositivi non risolti. Un rilevatore senza rilievi, da solo, non è una prova sufficiente per chiudere tale decisione.