Mi problema es que la Política de grupo no se aplica cuando un cliente se inicia recientemente. Inmediatamente después del arranque, el cliente publica un mensaje de error en el registro de eventos con la fuente "GroupPolicy (Microsoft-Windows-GroupPolicy)" y el ID de evento 1058: "Error en el procesamiento de la política de grupo. [...]". En la pestaña Detalles, el código de error es 50, que significa ERROR_NOT_SUPPORTED. No es sólo una cuestión cosmética: las políticas realmente no se aplican correctamente: las unidades de red asignadas no están ahí, por ejemplo. Después de esperar un rato, la ejecución de "gpupdate" funciona y las políticas se aplican con normalidad: aparecen las unidades de red asignadas.
El escenario más simple en el que pude reproducir el problema: dominio recién creado en Windows Server 2012R2 recién instalado, el cliente es una máquina con Windows 10 de 64 bits recién instalada. El dominio consta de un solo controlador de dominio y no tiene ninguna relación con otros dominios.
Dado que el mensaje de error indica que Windows no puede leer un archivo .GPT del recurso compartido Sysvol del dominio, intenté acceder al mismo archivo desde el símbolo del sistema. Y, de hecho, cuando abro el símbolo del sistema inmediatamente después del arranque, aparece esto:
C:\Users\username>dir \\domain.example.com\sysvol
The request is not supported.
Después de esperar uno o dos minutos, ejecutar el mismo comando le dará una lista del directorio. Ejecutar gpupdate en este punto funcionará bien.
Configuré la configuración de Política de grupo "Esperar siempre a que la red se inicie e inicie sesión en la computadora" en "Habilitado", y sé que esta política se aplica: en el mismo objeto de política se especifica una configuración de Registro, y cuando verifico el Registro en el cliente la configuración especificada está ahí.
Otros factores que podrían ser relevantes:
- NTLM está restringido en el dominio, pero esto no parece importar: incluso después de habilitarlo, actualizar las políticas y reiniciar todas las máquinas, los síntomas siguen siendo los mismos.
- No importa si el servidor está configurado mediante DHCP o con una configuración estática.
- El servidor DNS del dominio no admite actualizaciones dinámicas. Los registros necesarios se agregaron manualmente (desde C:\Windows\System32\config\netlogon.dns)
- La hibernación está deshabilitada en el cliente (usando
powercfg /h off), por lo que cada inicio es un inicio completo, no un inicio rápido. - El tiempo de espera de procesamiento de la política de inicio está establecido en 120 segundos.
- La conectividad al DC funciona bien. Los pings funcionarán. Apagar el cliente, deshabilitar mi cuenta en AD, encender el cliente hará que el cliente no inicie sesión: inmediatamente se da cuenta de que la cuenta está deshabilitada.
- Aparte de este tema, no noto nada fuera de lo normal.
Esto parece ser más un problema de SMB que un problema de política de grupo. Olfatear la conexión en el lado del servidor muestra algo interesante: la primera vez que ejecuto el comando dir \\domain.example.com\sysvol, se muestra lo siguiente en Microsoft Message Analyzer en el DC:
- El cliente configura una conexión TCP al puerto 445 del DC y se realiza con éxito una ComNegotiation (DialectRevision: 0x02FF).
- Inmediatamente después, se realiza con éxito una negociación. La revisión del dialecto es 0x0302.
- Inmediatamente después de eso, el cliente cierra la conexión TCP con un TCP RST (??)
Cada vez que emito el comando y aparece el error, se producen los pasos 2 y 3.
Cuando el comando comienza a funcionar, ocurren los pasos 1 y 2, pero en lugar de que el cliente envíe un TCP RST, se realiza un SessionSetup, luego un TreeConnect y luego se produce una gran cantidad de conversaciones SMB (aparentemente normales).
Entonces, parece que de alguna manera el cliente no comunicará correctamente SMB con el DC hasta uno o dos minutos después del arranque, y esto hace que falle el procesamiento de la Política de grupo.
¿Alguien sabe cómo puedo depurar y resolver este problema?
Respuesta1
A partir de Windows 8, Microsoft introdujo esta noción de "arranque rápido", donde, cuando se apaga el sistema operativo, se hiberna la huella de memoria del sistema operativo tal como funciona Hibernate en escenarios de hibernación normales. Esto hace que el sistema operativo funcione más rápido, pero también tiene el efecto secundario de deshabilitar el procesamiento de GP por computadora al inicio. Probablemente eso es lo que está viendo y se puede desactivar deshabilitando la política en Configuración del equipo\Políticas\Plantillas administrativas\Sistema\Apagado\Requerir el uso de inicio rápido.
Si eso no resuelve el problema, lo más probable es que se trate de un problema de sincronización de la pila de red, donde el procesamiento de GP para la computadora se inicia antes de que la pila de red se inicialice por completo. Esto ha existido desde XP y, a partir de Windows 7, Microsoft agregó una política en Configuración del equipo\Políticas\Plantillas administrativas\Sistema\Política de grupo\Tiempo de espera de procesamiento de políticas de inicio donde puede aumentar el tiempo que espera GP antes de iniciar. Intente configurarlo en 60 segundos y vea si eso ayuda.
Darren
Respuesta2
Logré resolver este problema yo mismo. Parareferenciaesto es lo que resolvió mi problema:
En primer lugar, me equivoqué al afirmar que deshabilitar todos los bloqueos de NTLM provocaba los mismos síntomas. Resultó en undiferentesíntoma, que resultó tener el mismo efecto. Sin ninguna política de bloqueo NTLM vigente, el dircomando ahora generó un error de acceso denegado. La Política de grupo aún no se aplicaría, lo cual tiene sentido: todavía no se podía acceder a SYSVOL.
Un poco de búsqueda en la web me dijo que sé que tenía un problema más común. aunque. Aparentemente, los clientes de Windows 10 pueden tener problemas para acceder al recurso compartido SYSVOL de controladores de dominio (y quizás también al recurso compartido NETLOGON). Supuestamente Windows 10 cambió algo en la forma en que accede a esos recursos compartidos, lo que puede generar problemas. La solución es deshabilitar el endurecimiento de rutas UNC en el cliente para estos recursos compartidos, estableciendo la Política de grupo "Rutas UNC reforzadas" para los clientes de Windows 10 de esta manera:
\\*\SYSVOL RequireMutualAuthentication=0,RequireIntegrity=0,RequirePrivacy=0
\\*\NETLOGON RequireMutualAuthentication=1,RequireIntegrity=1
(Si tiene problemas para acceder al recurso compartido Netlogon desde clientes de Windows 10, también podría ser útil establecer los tres parámetros en cero para ese recurso compartido).
Ver elartículo de Microsoft sobre MS15-011para más información. Contiene una buena descripción de las implicaciones de seguridad de cambiar esta configuración, así como pasos detallados sobre cómo cambiar la política.
Advertencia: Tenga en cuenta que los ajustes anterioresdesactivar¡Algunas o todas las protecciones contra el problema de seguridad para el que se creó MS15-011!Nosimplemente cópielos y péguelos a ciegas, pero tome una decisión informada basada en los riesgos involucrados. Además, es probable que este problema se resuelva en el futuro. Cuando eso suceda, no olvide establecer esta política en los valores recomendados como se describe en MS15-011.
Respuesta3
Solo para su información, para cualquiera que encuentre este hilo, desactivar el refuerzo UNC estableciendo la autenticación mutua en 0 deshabilita parte de su seguridad. Estamos teniendo el mismo problema con los clientes win7 y estaba intentando trabajar con Microsoft en ello. Me dijeron que es un error, pero hasta ahora no me han dado una forma de saber cuándo se solucionará el error.
Mira este otro hilo para más información. https://social.technet.microsoft.com/Forums/en-US/6a20e3f6-728a-4aa9-831a-6133f446ea08/gpos-do-not-apply-on-windows-10-enterprise-x64
Respuesta4
Probé varias sugerencias, incluidos cambios en el registro y cambios en la política del grupo local, ninguno de los cuales resolvió el problema: las unidades asignadas todavía estaban X en el arranque. Un gpupdate lo solucionaría siempre, pero ese era un paso adicional para el usuario.
Lo que terminó solucionándolo fue mapear manualmente las unidades de red, reemplazando las entradas de GPO en cada una de ellas. No es necesario desconectarlos y reemplazarlos, los mapeé de la misma manera que fueron mapeados, solo que manualmente.