Se volete leggere le altre parti in questa serie di articoli, si prega di andare a:

• 10 Motivi per cui i Criteri di Gruppo non Riesce ad Applicare (Parte 1)
• 10 Motivi per cui i Criteri di Gruppo non Riesce ad Applicare (Parte 2)

Introduzione

Nei nostri primi due episodi di questo argomento abbiamo guardato i 7 motivi per cui Criteri di Gruppo potrebbero non funzionare correttamente nel tuo ambiente. Guardando indietro a quei 7 motivi esposti alcuni fattori chiave sulla politica di gruppo. Innanzitutto, i criteri di gruppo si basano sulla corretta autenticazione tramite DNS ai controller di dominio, utilizzando Kerberos per il protocollo di autenticazione, l’ambito di gestione e utilizzando il tipo di oggetto corretto per ogni impostazione in un GPO. Quindi, abbiamo esaminato la precedenza GPO (LSDOU) e il filtraggio della sicurezza. In questa puntata, vedremo nessun override, ereditarietà dei blocchi e filtri WMI.

Enforced (No override) è impostato su GPO

Per impostazione predefinita, ogni GPO configurato non ha alcun filtro di sicurezza, Applicato (No override), ereditarietà dei blocchi, ecc. Tuttavia, potrebbe esserci un momento in cui qualcuno imposta una di queste funzionalità. Abbiamo esaminato il filtraggio della sicurezza, ma ora stiamo guardando forzato (nessuna override). Applicata (nessuna override) è un’impostazione imposta a un GPO, insieme a tutte le impostazioni nel GPO, in modo che qualsiasi GPO con precedenza maggiore non “vinca” se c’è un’impostazione in conflitto.

È importante capire che l’ereditarietà GPO funziona con LSDOU (Locale, sito, dominio, OU). Una volta impostato nessun override su un GPO, questo concetto di precedenza viene negato. Enforced (No override) imposta il GPO in questione per non essere sovrascritto da nessun altro GPO (per impostazione predefinita, ovviamente).

Un buon esempio qui è quello di impostare la politica di dominio predefinita per forzata (Nessuna override), in modo che le impostazioni della politica della password contenute al suo interno non siano inventate da un GPO nel dominio per gli utenti del dominio o in un OU per gli utenti SAM locali nei computer situati nell’OU. Si può vedere questo è impostato sul criterio di dominio predefinito in Figura 1.

Figura 1:
Applicato (nessuna override) è impostato per il criterio di dominio predefinito.

Ci sono alcune cose da considerare quando si imposta forzata (Nessuna override). Innanzitutto, il GPO verrà impostato sulla precedenza più alta dalla posizione in cui il GPO è collegato attraverso la struttura dell’ANNUNCIO. In secondo luogo, se un GPO di precedenza più alto (ad esempio, a livello di OU nel nostro esempio) è impostato anche su Applicato (senza override), non avrà una precedenza maggiore rispetto al GPO collegato più alto nella struttura AD. In questo modo un amministratore OU non può impostare un GPO per avere una precedenza maggiore di un amministratore di dominio.

Block Inheritance è impostato su Active Directory Node

Un’altra caratteristica, anche se non è suggerito di utilizzare regolarmente, è la possibilità di bloccare l’ereditarietà della politica di gruppo standard di elaborazione verso il basso attraverso Active Directory. Come è stato menzionato molte volte in questo set di articoli, la precedenza LSDOU è rispettata per l’applicazione di criteri di gruppo e la risoluzione dei conflitti.

La funzione di ereditarietà dei blocchi è impostata sul nodo del dominio o su un’unità organizzativa. Anche se i siti possono avere un GPO collegato, l’unico GPO che ha una precedenza più debole rispetto al GPO collegato al sito è locale e i GPO locali non possono essere bloccati con questa funzione.

Ciò che la funzione fa è bloccare tutti i GPO di precedenza più deboli associati al livello in cui viene stabilita l’impostazione di ereditarietà dei blocchi. Quindi, se l’ereditarietà del blocco è impostata su un OU di secondo livello, tutti i GPO impostati sul dominio e l’OU di primo livello verrebbero bloccati, senza influire sugli utenti e sui computer situati nell’OU di secondo livello. Solo i GPO collegati al secondo livello OU avrebbero alcun effetto. Naturalmente, se ci fossero più livelli di OU sotto il secondo livello, anche questi GPO sarebbero efficaci, non solo quelli che hanno una precedenza più debole. Si può vedere come questo influenza GPO guardando Figura 2 e 3. La figura 2 non ha un set di ereditarietà dei blocchi, mentre la Figura 3 ha l’impostazione stabilita al secondo livello OU.

Figura 2:
Precedenza e ereditarietà GPO standard al secondo livello OU.

Figura 3:
L’ereditarietà dei blocchi è impostata al secondo livello OU.

Il filtro WMI non è corretto

I filtri WMI sono un modo efficace per controllare quali oggetti (utenti o computer) ricevono le impostazioni in un GPO. Il filtro WMI è un file stand-alone che è collegato a uno o più GPO. Quando vengono valutate le impostazioni dei criteri di gruppo di ciascun GPO, il filtro WMI determina se le query incluse nel filtro WMI tornano come positive o negative. Se positivo, soddisfacendo i criteri nel filtro WMI, verranno applicate le impostazioni nel GPO a cui è collegato il filtro WMI.

Naturalmente, si può vedere dove ci potrebbero essere molte aree in questo processo che il filtro WMI farà il GPO sembrano fallire. Innanzitutto, se il file del filtro WMI viene modificato o eliminato, ma il collegamento del filtro WMI rimane intatto, il filtro WMI non verrà soddisfatto, pertanto le impostazioni nel GPO non verranno applicate. Successivamente, se il filtro WMI presenta errori sintattici, causando il fallimento della query, anche le impostazioni nel GPO non verranno applicate. Infine, se la query è progettata in modo errato o la logica per il successo della query WMI non è corretta, le impostazioni GPO non verranno applicate.

Usa i filtri WMI solo dove non ci sono altre opzioni, poiché i filtri WMI hanno molte aree in cui possono negare l’applicazione di tutte le impostazioni nel GPO, inoltre i filtri WMI sono molto lenti da valutare e applicare. Anche nel Targeting a livello di elemento (ILT) situato nelle preferenze dei criteri di gruppo, utilizzare i filtri WMI con parsimonia, poiché all’interno del ILT possono avere problemi.

Sommario

In questa serie di articoli abbiamo esaminato dieci diversi modi in cui i criteri di gruppo potrebbero fallire, o almeno sembrare come se non funzionasse. In realtà, la politica di gruppo stessa raramente fallisce. Ciò che in genere fallisce è la configurazione del GPO, dei collegamenti, della struttura dei criteri di gruppo, ecc. che non sono corretti, causando il GPO e le impostazioni non si applicano alle destinazioni desiderate. Suggerisco sempre che tornare alle basi e ai fondamenti della politica di gruppo aiuterà a rintracciare dove sono radicati i problemi principali. Inoltre, trovo che le configurazioni fondamentali e fondamentali causino la maggior parte dei problemi con i criteri di gruppo. Come regola generale, assicurarsi di utilizzare la struttura OU per distribuire le impostazioni dei criteri di gruppo, in modo che tutti gli oggetti nell’OU ricevano le impostazioni. Quando si tenta di modificare le autorizzazioni predefinite, l’applicazione e la precedenza dei criteri di gruppo, è qui che i problemi iniziano ad accumularsi. Si consiglia, solo in situazioni molto rare, di utilizzare funzionalità come il filtro di sicurezza, l’ereditarietà dei blocchi, l’applicazione e i filtri WMI. Stare lontano da queste opzioni e funzionalità ti aiuterà a mantenere il tuo ambiente di criteri di gruppo più semplice, stabile e più facile da risolvere quando si verificano problemi reali.

Se desideri leggere le altre parti di questa serie di articoli, vai a:

• I 10 motivi principali per cui i criteri di gruppo non vengono applicati (parte 1)
• I 10 motivi principali per cui i criteri di gruppo non vengono applicati (Parte 2)

segnala questo annuncio