Windows 10: i criteri di gruppo non si applicano direttamente dopo l'avvio, ma riescono in un secondo momento

Il mio problema è che i criteri di gruppo non vengono applicati all'avvio di un client. Subito dopo l'avvio, il client registra un messaggio di errore nel registro eventi con l'origine "GroupPolicy (Microsoft-Windows-GroupPolicy)" e ID evento 1058: "L'elaborazione dei criteri di gruppo non è riuscita. [...]". Nella scheda Dettagli, ErrorCode è 50, che sta per ERROR_NOT_SUPPORTED. Non è solo un problema estetico: i criteri non sono applicati correttamente: le unità di rete mappate non sono presenti, ad esempio. Dopo aver atteso un po ', l'esecuzione di "gpupdate" funziona e i criteri vengono applicati normalmente: vengono visualizzate le unità di rete mappate.

Lo scenario più semplice in cui sono stato in grado di riprodurre il problema: dominio appena creato su Windows Server 2012R2 appena installato, il client è un computer Windows 10 a 64 bit appena installato. Il dominio è costituito da un solo controller di dominio e non ha alcuna relazione con altri domini.

Poiché il messaggio di errore indica che Windows non è in grado di leggere un file .GPT dalla condivisione Sysvol del dominio, ho cercato di accedere allo stesso file da un prompt dei comandi. E infatti, quando apro un prompt dei comandi subito dopo l'avvio ottengo questo:

C:\Users\username>dir \\domain.example.com\sysvol
The request is not supported.

Dopo aver atteso un minuto o due, eseguendo lo stesso comando verrà visualizzato un elenco di directory. L'esecuzione di gpupdate a questo punto funzionerà perfettamente.

Ho impostato l'impostazione di Criteri di gruppo "Attendi sempre la rete all'avvio e all'accesso del computer" su "Abilitato" e so che questo criterio è applicato: nello stesso oggetto criterio viene specificato un registro e quando controllo il Registro sul client è presente l'impostazione specificata.

Altri fattori che potrebbero essere rilevanti:

• NTLM è limitato nel dominio, ma questo non sembra importare: anche dopo averlo abilitato, aggiornando le politiche e riavviando tutte le macchine, i sintomi rimangono gli stessi.
• Non importa se il server è configurato tramite DHCP o con una configurazione statica.
• Il server DNS per il dominio non supporta gli aggiornamenti dinamici. I record necessari sono stati aggiunti manualmente (da C: \ Windows \ System32 \ config \ netlogon.dns)
• L'ibernazione è disabilitata sul client (utilizzando powercfg /h off), quindi ogni avvio è un avvio completo, non un avvio rapido
• Il tempo di attesa per l'elaborazione della politica di avvio della politica è impostato su 120 secondi
• La connettività alla DC funziona bene. Ping funzionerà. La disattivazione del client, la disabilitazione del mio account in AD, l'attivazione del client comporteranno il mancato accesso del client da parte del cliente: si accorge immediatamente che l'account è disabilitato.
• A parte questo problema, non noto nulla di straordinario.

Questo sembra essere più un problema di PMI che un problema di criteri di gruppo. Annusare la connessione sul lato server mostra qualcosa di interessante: la prima volta che eseguo il comando dir \\domain.example.com\sysvol, il seguente mostra in Microsoft Message Analyzer sul controller di dominio:

1. Il client imposta una connessione TCP alla porta 445 del controller di dominio e una ComNegotiation viene eseguita correttamente (DialectRevision: 0x02FF).
2. Immediatamente dopo, un negoziato viene eseguito con successo. DialectRevision è 0x0302.
3. Subito dopo, il client chiude la connessione TCP con un TCP RST (??)

Ogni volta che eseguo il comando e ricevo l'errore, si verificano i passaggi 2 e 3.

Quando il comando inizia a funzionare, si verificano i passaggi 1 e 2, ma invece del client che invia un RST TCP viene eseguito un SessionSetup, quindi un TreeConnect e quindi un sacco di chiacchiere SMB (apparentemente normali).

Quindi, in qualche modo sembra che il client non parlerà correttamente SMB al controller di dominio fino a un minuto o due dopo l'avvio, e ciò causa il fallimento dell'elaborazione dei criteri di gruppo.

Qualcuno sa come posso eseguire il debug e risolvere questo problema?

A partire da Windows 8, Microsoft ha introdotto questa nozione di "avvio rapido", in cui, quando si arresta il sistema operativo, vanno in letargo il footprint di memoria del sistema operativo proprio come Hibernate funziona in normali scenari di ibernazione. Ciò si traduce in una maggiore velocità del sistema operativo, ma ha anche l'effetto collaterale di disabilitare l'elaborazione GP per computer all'avvio. Questo è probabilmente quello che stai vedendo e questo può essere disabilitato disabilitando il criterio in Configurazione computer \ Politiche \ Modelli amministrativi \ Sistema \ Arresto \ Richiedi l'uso di avvio rapido

Se ciò non risolve il problema, è molto probabile che si tratti di un problema di temporizzazione dello stack di rete, in cui l'elaborazione GP per il computer sta per iniziare prima che lo stack di rete sia completamente inizializzato. Questo è in circolazione da XP e, a partire da Windows 7, Microsoft ha aggiunto un criterio in Configurazione computer \ Criteri \ Modelli amministrativi \ Sistema \ Criteri di gruppo \ Tempo di attesa elaborazione criteri di avvio in cui è possibile aumentare il tempo di attesa di GP prima dell'avvio. Prova a impostarlo su 60 secondi e vedi se questo aiuta.

Darren

Sono riuscito a risolvere questo problema da solo. Per riferimento ecco cosa ha risolto il mio problema:

Innanzitutto, mi sbagliavo nel fatto che disabilitare tutti i blocchi di NTLM causava gli stessi sintomi. Ha provocato un sintomo diverso , che ha avuto lo stesso effetto. Senza alcun criterio di blocco NTLM attivo, il dircomando ora ha provocato un errore di accesso negato. I criteri di gruppo non sarebbero ancora applicabili, il che ha senso: SYSVOL non era ancora accessibile.

Un po 'di ricerca sul web mi ha detto che so che ha avuto un problema più comune. anche se. Apparentemente, i client Windows 10 possono avere problemi ad accedere alla condivisione SYSVOL dei controller di dominio (e forse anche alla condivisione NETLOGON). Presumibilmente Windows 10 ha cambiato qualcosa nel modo in cui accede a tali condivisioni, il che può causare problemi. La soluzione alternativa è disabilitare l'indurimento del percorso UNC sul client per queste condivisioni, impostando i Criteri di gruppo "Percorsi UNC induriti" per i client Windows 10 in questo modo:

\\*\SYSVOL RequireMutualAuthentication=0,RequireIntegrity=0,RequirePrivacy=0
\\*\NETLOGON RequireMutualAuthentication=1,RequireIntegrity=1

(Se riscontri problemi con l'accesso alla condivisione Netlogon dai client Windows 10, potrebbe essere utile impostare tutti e tre i parametri su zero anche per quella condivisione.)

Vedere l' articolo di Microsoft su MS15-011 per ulteriori informazioni. Contiene una buona descrizione delle implicazioni di sicurezza della modifica di questa impostazione, nonché passaggi dettagliati su come modificare la politica.

Avvertenza : le impostazioni sopra disabilitano alcune o tutte le protezioni contro il problema di sicurezza per cui è stato creato MS15-011! Non solo copiarli / incollarli alla cieca, ma prendere una decisione informata in base ai rischi. Inoltre, è probabile che questo problema venga risolto in futuro. Quando ciò accade, non dimenticare di impostare questo criterio sui valori consigliati come descritto nel bollettino MS15-011.

Ho provato diversi suggerimenti, tra cui le modifiche al registro e le modifiche ai criteri di gruppo locali, nessuna delle quali ha risolto il problema: le unità mappate erano ancora eliminate all'avvio. Un gpupdate lo aggiustava ogni volta, ma quello era un passaggio aggiunto per l'utente.

Ciò che ha finito per risolverlo è stata la mappatura manuale delle unità di rete, sostituendo le voci dell'oggetto Criteri di gruppo su ciascuna di esse. Non è necessario disconnettersi e sostituirli, li ho mappati allo stesso modo in cui erano mappati, solo manualmente.

Cordiali saluti per chiunque trovi questo thread, disattivare l'indurimento UNC impostando l'autenticazione reciproca su 0 sta disabilitando parte della tua sicurezza. Stiamo riscontrando lo stesso problema con i client Win7 e stavo cercando di lavorare con Microsoft su di esso. Mi hanno detto che è un bug, ma finora non mi hanno dato un modo per tracciare quando il bug verrà risolto.

Vedi questa altra discussione per maggiori informazioni https://social.technet.microsoft.com/Forums/en-US/6a20e3f6-728a-4aa9-831a-6133f446ea08/gpos-do-not-apply-on-windows-10-enterprise -x64