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.