Cómo Funcionan las Directivas de Grupo (GPOs)

El uso y aplicación de las Directivas de Grupo, en adelante GPOs, en ambiente de dominio de Directorio Activo (Active Directory) es uno de los temas que provoca más dudas e inconvenientes entre los administradores de redes, así que en esta nota vamos a tratar de aclarar las bases de su funcionamiento, y que permitirán aclarar su aplicación correcta.

Vamos a hacer primero un poco de historia sobre el tema. Aunque se han popularizado a partir de Windows 2000, en realidad ya estaban en Windows 95 y NTs. La idea atrás de estas directivas era poner restricciones a ciertos usuarios y/o máquinas.

Pocos las vieron en ese momento pues el ejecutable POLEDIT.EXE no tenía un acceso directo en la interfaz gráfica, y por lo tanto había que descubrirlo. Los pocos que se dieron cuenta de su existencia y uso, en general no tuvieron una buena experiencia además.

POLEDIT.EXE permitía poner restricciones por usuario, por grupo o por máquina, en forma local o en dominio, y contenía sólo unas 50 o 60 configuraciones dependiendo de las plantillas cargadas. Permitía guardar la directiva configurada con un nombre a elección y en la carpeta que el creador deseara; y así no funcionaba. Había que guardarla con un nombre determinado (CONFIG.POL para los Windows 95/98, NTCONFIG.POL para los NTs) y en un lugar específico (NETLOGON de los Controladores de Dominio). Como si fuera poco lo anterior no funcionaba como muchos administradores esperaban; ellos pensaban que si querían sacar las restricciones sólo debían borrar el archivo .POL pero no era así ya que las directivas ya habían hecho los cambios en el Registro (Registry) por lo cual para volver a cualquier configuración anterior había que aplicar una directiva que revirtiera los cambios. Resumiendo: tuvieron una muy reducida aplicación.

El cambio fundamental se produjo con Windows 2000, y sigue hasta nuestros días de Windows 7 / Windows Server 2008 R2 con muchos más agregados, pero conceptualmente funcionando de la misma forma. Todo lo que hablemos de acá en más en esta nota estará basado en conceptos que se desarrollaron en Windows 2000 pero que siguen siendo válidos actualmente.

Para diferenciar las “nuevas directivas” de las “viejas directivas” se decidió cambiarles el nombre. Las primeras fueron llamadas “Directivas de Sistema” (System Policies), y las nuevas “Objeto Directivas de Grupo” (Group Policy Objects = GPOs).

Estas nuevas GPOs ya no eran sólo un archivo, sino un grupo de carpetas y archivos que además están relacionados con un objeto creado en el Directorio Activo (Active Directory).
Lo anterior da una explicación coherente al porqué cuando queremos operar con una GPO no alcanza con copiar la carpeta correspondiente; no hay que olvidar que se corresponde y relaciona con un objeto propio (dentro de) el Directorio Activo.

Estas GPOs tienen existencia propia, lo cual implica que pueden estar creadas y presentes, pero sin embargo no afectar a ningún objeto. Para que afecten, o mejor dicho para que se apliquen a objetos del Directorio Activo deben enlazarse (link) a un objeto de tipo contenedor del directorio.
Una GPO puede enlazarse a un Sitio (Site), Dominio (Domain) o Unidad Organizativa (Organizational Unit). Y cuando se enlaza a un contenedor de este tipo se aplicará a todos los objetos contenidos en el mismo. Nota importante: un Subdominio no está contenido en el Dominio padre; una Unidad Organizativa sí está contenida en un dominio; y un Sitio puede contener máquinas de varios Dominios del Bosque.

Una GPO puede contener mucho más que las 50 ó 60 configuraciones iniciales. Cada versión de Sistema Operativo y Service Pack fueron agregando posibles configuraciones. Cuando salió Windows 2000 originalmente había aproximadamente 550 configuraciones, con Windows 7 estamos en aproximadamente un poco mas de 3300 configuraciones.
La última versión de una planilla Excel con las configuraciones posibles puede descargarse de:
Group Policy Settings Reference for Windows and Windows Server: http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=18c90c80-8b0a-4906-a4f5-ff24cc2030fb
Además estas configuraciones no son sólo valores en el Registro (Registry) sino configuraciones del propio sistema.
Las configuraciones de registro son sólo las que están bajo “Plantillas administrativas” (Administrative Templates). Y además ya no son resilientes, esto es, se revierten en la mayoría de los casos cuando se deja de aplicar la GPO. Para comprender esto: se guardan las configuraciones en un par de claves del Registro, y en el momento del arranque se produce en memoria la combinación de valores.

Una GPO puede contener una o más configuraciones; un contenedor puede tener enlazadas ninguna o varias GPOs; y una GPO puede estar enlazada a más de un contenedor sin importar su clase. Lo anterior es la consecuencia de la existencia como objeto independiente que tienen las GPO.

También es conveniente recordar que cada GPO tiene dos partes principales Configuración de Equipo y Configuración de Usuario.

En la siguiente figura podemos ver un diagrama genérico de Directorio Activo. Específicamente aclaramos que cada contenedor tiene solamente otros dos abajo por simplicidad de dibujo, pero podría tener más. Así mismo es de notar que hemos puesto GPOs enlazadas en todos los contenedores y que las cuentas de usuario y de máquina se encuentran en Unidades Organizativas separadas, ya que la idea es hacer una explicación general del funcionamiento.

Supongamos también que como es lógico si hemos enlazado una GPO a un contenedor es porque ésta contiene alguna configuración o configuraciones.

También por simplicidad hemos puesto tanto la cuenta de máquina como la de usuario en el mismo Dominio, aunque esto no es necesario.

Cuando se inicia una máquina con sistema Windows 2000 o posterior, al igual que todos los NTs anteriores (no es el caso de los Windows 9x) la máquina debe autenticarse en el dominio. Luego que el Controlador de Dominio hace esta autenticación le pasa a la máquina la lista de GPOs que debe aplicar de acuerdo a la Unidad Organizativa donde ésta se encuentra. En nuestro caso le dirá que debe aplicar: GPO1, GPO2, GPO3, GPO4 y GPO7. De todas esas GPOs la máquina aplicará la parte Configuración de Equipo, se ejecutarán los Scripts de Inicio, y recién aparecerá el cuadro para que el usuario ingrese sus credenciales para iniciar sesión.
Cuando el usuario ingresa sus credenciales y es autenticado, el Controlador de Dominio informa al equipo cuáles son las GPOs que debe aplicar de acuerdo a dónde esté la cuenta de usuario. En nuestro caso: GPO1, GPO2, GPO3, GPO4 y GPO8. De estas GPOs se aplicará la parte Configuración de Usuario, se ejecutarán los scripts de inicio de sesión y finalmente se mostrará el escritorio del usuario.

Debemos aclarar, que lo anterior es rigurosamente cierto, si el equipo y usuario es la primera vez que se ingresa al dominio, ya que de otra forma el sistema, para acelerar el proceso, usará copias de las GPOs “cacheadas” localmente, permitiendo que el usuario llegue al escritorio aún antes que el equipo tenga conectividad de red. Posteriormente verificará si hay cambios en las GPOs y las aplicará posteriormente.

Volviendo al tema específico de las configuraciones ¿Qué configuraciones de GPO estarán aplicadas? Bien, el resultado es todas. Tanto la máquina como el equipo recibirán algunas configuraciones de una GPO y otras de otra GPO. Recibirá la “unión” de todas las GPOs.

Si todo fuera tan simple sería muy fácil, pero qué sucede si hay configuraciones opuestas, por ejemplo que una GPO oculta el Ejecutar y otra tiene que hay que mostrar el Ejecutar.
El valor por omisión es que prevalece la última en ejecutarse, la más cercana al objeto.
Esto es así para permitir que las configuraciones más generales se hagan “más alto” y la estructura de Unidades Organizativas permitan poner las configuraciones más específicas. Un poco más adelante veremos cómo podemos alterar este comportamiento.

Permítanme una observación personal que creo que ha llevado al poco entendimiento general sobre cómo trabajan las GPOs. En inglés GPO = “Group Policy Object”, y está localizado en español como “Objeto Directiva de Grupo”. Eso ha llevado a multitud de confusiones porque muchos administradores con buena lógica asociaron su uso a Grupos de seguridad de Directorio Activo. En realidad esto no es así, hubiera sido mucho más lógico usar algo como “Objeto Conjunto de Directivas” porque en realidad con “grupo” se está refiriendo a que en una GPO pueden agruparse (en conjunto) varias configuraciones.

Cuando se planifica un Directorio Activo es fundamental decidir sobre qué estructura de Unidades Organizativas se va a utilizar, ya que ésta debe facilitar la administración de los recursos. Se deben tener en cuenta dos factores: Delegación de Tareas, y Aplicación de GPOs.

Volvamos ahora al tema que dejamos pendiente sobre qué podemos hacer para alterar la resolución de conflictos de configuraciones cuando se aplican varias GPOs.
Habíamos dicho que el valor por omisión es que en caso de configuraciones opuestas prevalecía la última en aplicar, pero esto no siempre es deseable o posible para alcanzar objetivos propuestos.
Por eso tenemos otras opciones para alterar esa forma de aplicación:
Bloquear la Herencia de Directivas (Block Policy Inheritance): esta opción está a nivel del contenedor y nos permite bloquear en forma total todas las GPOs heredadas que vienen de contenedores superiores. No se puede hacer selectivamente, se bloquean todas o ninguna.
No Reemplazar (Enforce / No Override): esta opción a nivel de enlace (link) permite forzar la aplicación. Las configuraciones de esta GPO se aplicarán aunque esté bloqueada la herencia, e inclusive prevalecerán en caso de conflicto.
Permisos sobre la GPO: como todo objeto del Directorio Activo, una GPO tiene permisos. Por omisión el grupo Usuarios Autentificados (Authenticated Users) tiene los permisos Permitir Lectura y Permitir Aplicar GPO. Como todas las máquinas y usuarios pertenecen a este grupo, la GPO no hará excepciones. Pero aprovechando nuestros conocimientos de administración de permisos y sabiendo que los permisos de Denegar prevalecen por sobre los de Permitir, podemos influenciar el comportamiento utilizándolos adecuadamente.
Por ejemplo si queremos exceptuar a un grupo de usuarios podríamos incluirlos en un grupo y específicamente a este grupo denegarle los permisos mencionados, con lo cual lo exceptuaríamos.
Otra posibilidad para que aplique a un grupo específico, sería editar los permisos, sacando a Usuarios Autentificados y otorgándoselos específicamente al grupo que queramos.

Algunos comentarios sobre estas posibilidades antes nombradas. La mejor solución es siempre la más simple. Una buena planificación de la estructura de Unidades Organizativas nos puede ahorrar mucho tiempo y trabajo. Por lo tanto tratemos de evitar en lo posible cualquiera de las tres alternativas anteriores, no porque no funcionen adecuadamente, sino porque en caso de problemas éstos son de más difícil resolución.
Si tenemos que usar mucho el bloqueo de herencia y forzar la aplicación es para pensar si un rediseño de la estructura de Unidades Organizativas nos podría ayudar. El uso de los permisos a través de grupos únicamente debería usarse en casos excepcionales.

Post a comment or leave a trackback: Trackback URL.

Comentarios

  • Ignacio Sabido  On 12/04/2013 at 11:50

    Muy buenas Guillermo, he abierto una nueva consulta en el foro, ya como podras ver el tema de Directaccess lo solucione.

    Te paso el enlace:
    http://social.technet.microsoft.com/Forums/es-ES/wsgpes/thread/1054e9ae-87af-4c90-8379-3d05b3e87be8

  • Gabriel Gonzalez  On 28/04/2015 at 23:42

    Guillermo tengo un problema con GPO, habilite una para hacer una prueba, para restingir una aplicacion, la cual me aplico al contrario, solo puedo abrir esa aplicacion. el problema es que no puedo eliminarla ya que la GPO aplico para todos los usuarios, no tengo acceso al administrador para eliminarla, probe reinciando el servidor a prueba de fallos y me levanta la GPO, existe alguna otra forma, borrando algun archivo del sistema o algo asi?

    • Guillermo Delprato  On 29/04/2015 at 07:29

      Hola Gabriel ¡la haz hecho eh! :)
      Bueno haz aprendido algo “nunca hay que aplicar una GPO a “todos” los usuarios” ya que tú tambien estás ahí :)
      Habría que ver si fue hecho por “Software Restriction Policies” o “Application Locker” ya que funcionan totalmente distinto
      Ideas que se me ocurren aunque no sé si funcionarán
      – Tratar de acceder con una máquina en grupo de trabajo o en otro dominio, usando una consola MMC creada, y eliminar la GPO
      – Si con lo anterior no fuera posible por accesos denegados, probaría desde otro Dominio previamente a haber hecho una relación de confianza, que si sabes la contraseña de administrador de ambos Dominios podrás hacerlo
      – Si usaste AppLocker, a una máquina fuera del Dominio le deshabilitas el servicio “Application Identity”, y luego la unes al Dominio, con eso no debería aplicarte una GPO con AppLocker
      – Si usaste “Software Restriction Policies” revisa este artículo que puede darte ideas https://support.microsoft.com/en-us/kb/324036
      Son ideas, habría que pensar más
      ¿No tienes copia de seguridad de, por lo menos un DC?

      • Gabriel  On 10/05/2015 at 04:27

        Guillermo, buen dia, ya intente con cada una de las opciones y no he podido.tendras alguna otra idea?

      • Guillermo Delprato  On 11/05/2015 at 06:32

        Gabriel, te respondo en el siguiente comentario

      • Gabriel Gonzalez  On 10/05/2015 at 07:03

        He realizado cada una de las cosas que me has dicho, sin exito. encontre esto te suena que pueda ser?

        I had the same issue by accidentally changing system settings in gpedit. Try this fix I got from Greylox…. It worked for me.

        Click start button, type run into the search field at the bottom of the popup press enter. In the new window enter %systemroot%\system32\GroupPolicy\User delete registry.pol

        Do the same in %systemroot%\system32\GroupPolicy\Machine delete registry.pol if you see it, my PC didn’t have it.

        Reboot your system.

        Log in under admin account, create a new user with admin privileges, reboot and log back in using the new admin account.

        Click start button, type run into the search field at the bottom of the popup press enter. Type gpedit.msc, press enter.

        Go to Local Computer Policy -> User Configuration -> Administrative Templates -> (double click) system -> (look in panel on the right and double click) run only specified windows applications. Click the radio button next to Disabled.

      • Guillermo Delprato  On 11/05/2015 at 06:47

        Hola Gabriel, primero que nada cuidado que en lo que pegaste habla de haber usado GPEDIT, por lo tanto se trata de una “local policiy”, y no de una GPO
        La idea no es mala, pero en tu caso vas a encontrar una carpeta con todas las GPOs identificadas por su GUID, y tendrás que encontrar, quizás por fecha y hora, cuál es el .POL a borrar. Yo no lo borraría, no vaya a ser que se ponga peor, sólo lo movería a otra carpeta para en caso de ser necesario volver a dejar todo como está y no empeorar
        De todas formas, el tema de restricción de software, dependiendo cómo lo hayas hecho no está en el Registro, y el archivo .POL es la parte que se configura en el Registro. Por eso te daba la idea de borrar la GPO directamente
        Para peor, hay configuraciones, especialmente las relativas a “Security” que son resilientes, o sea que el cambio quedará aunque deje de aplicar la GPO. Se eliminan sólo con otra GPO que revierta el cambio

      • Gabriel Gonzalez  On 12/05/2015 at 09:58

        Guillermo, he logrado entrar al command prompt y he hecho esto
        https://technet.microsoft.com/en-us/library/hh875588.aspx
        Pero continuo sin poder abrir ningun aplicacion. No se si lo unico que me falte es reiniciar el servidor.

      • Guillermo Delprato  On 12/05/2015 at 11:19

        Hola Gabriel, eso te puede salvar sólo si el cambio lo haz hecho sobre alguna de las dos GPOs por omisión que crea el Dominio. Yo descartaba que no habías hecho eso ¿o si?
        ¿Habías hecho eso??? Acá en Argentina hay un dicho: “Más peligroso que mono con navaja” ja ja ja

      • Gabriel  On 15/05/2015 at 04:40

        Estuve leyendo una ves mas la informacion que me enviaste, al principio y recordando un poco lo que se hizo, y basicamente se realizo Software Restriction Policies, existe alguna forma de revertirlo o modificar via cmd o powershell?

      • Guillermo Delprato  On 15/05/2015 at 06:55

        Hola Gabriel, lamentablemente no puedo hacer más desde acá ya que estos comentarios están reservados para las notas. Deberías recurrir, por ejemplo, a algún foro de soporte. Entre otros podrías preguntar en los foros de Technet en español

      • Gabriel  On 15/05/2015 at 07:47

        Crees que me puedas dar soporte o podriamos hacer una sesion de RD para que lo revieses aun cuanto tenga costo?

      • Guillermo Delprato  On 15/05/2015 at 08:02

        No Gabriel, no hago soporte, sólo ayudo u oriento cuando puedo. El objetivo de estos comentarios son aclaraciones sobre la nota, y no soporte

Trackbacks

Este espacio es para comentarios sobre la nota. No es un sitio de soporte

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: