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.
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.
