Cómo funcionan las Directivas de Grupo (Group Policy Objects – 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.
GPO restriccion, habilitar todas las funciones a unidad organizacional
Buenas
Les escribo nuevamente ya que tengo una duda, respecto a las GPO’s
Tengo un dominio hablitado en Enterprise 2003, con su respectivo DNS, el DC trabaja bien sin problema alguna, incluso ya agrege una maquina al dominio, el detalle es al momento de editar las GPO, o en tal caso la GPO que cree.
La topologia del DC que tengo es esta:
OU User
OU Directores
Tengo un grupo llamado en Builten User y otro Directores
En la OU de User cree un GPO llamada User. Esta GPO casi no le he modificado nada.
En la OU de Directores cree otra GPO llamada Direcotes. Pero a esta GPO le quiero dar todos los privilegios, si no le coloco GPO a esta OU la OU toma la GPO del DC.
Ojo en el DC tengo la GPO que viene por default alli no la he modificado.
Pero tengo tremendo lio con esto de las restrcciones y permisos.
Quisiera que me hecharan una mano con esto por favor.
A cada OU le aplique una, GPO, a la OU de user, le aplique una GPO a la de directores no le aplique ninguna GPO pensando que no se aplicaria ninguna restriccion pero lei por alli que se aplica la del dominio.
Entoces quiero es que todos las cuentas que esten en la OU de Directores, tengan persmiso de administrador en la maquina donde inicie sesion.
Y no consigo realmente habilitar ciertos parametros al momento de editar la GPO, eh alli el detalle.
Otra cosa como deshabilito e las directivas de contrasña que no sea neceseario colocar una contraseña compleja si no simple ejemplo 12345678, en la GPO de default policy coloque Enabled a la a la casilla de complejidad de contraseña. en todas las GPO pero nada al momento de crear la cuenta y colocar un contraseña simple no me deja colocar.ç
Si no quieres que a la OU Directores se aplique una GPO no basta con no «linkar» ninguna, sino que debesbloquear la herencia de las GPOs de orden superior, en este caso, la del dominio .
A parte, si encima quieres que los usuarios sean Administradores locales, deberás crear otra GPO y aplicar lo que te comentan Pep y Guillermo.
Hola,
empieza por el primer post de este mismo foro del compañero Guillermo delPrato
Cómo funcionan las Directivas de Grupo (Group Policy Objects – GPOs)
http://social.technet.microsoft.com/Forums/es-ES/wsades/thread/35d227cb-8d34-4ac1-9033-91b5645a027b
Ook ya lei el post y lo entiendo, pero quisiera una explicacinn de los permisos, en una OU osea que todos los usuarios que este en esa OU al momento de ingresar en su maquina local tengan persmiso de administrador!
Quisiera es sobre como es la restriccion que habilitar o deshabiltar para restringir o dar todos los permisos en una OU o GPO que cree.
Si USers te refieres a la carpeta por defecto que se crea debajo del dominio, no es una OU, es una carpeta, por lo que la única GP que se aplica a ella es la del dominio; es sólo a título informativo.
No entiendo bien la pregunta socio; tú tienes OUs, y sobre esas OUs, creas las GPO; si en una OU hay cuentas de usuario y máquina, y pones una GPO para configurar aspectos de ambos, se aplicará por defeto a todos los usuarios/máquinas de esa OU; que quieres que unos sí y a otros no, usas el filtering scope por ejemplo.
Si en la OU que dices de directores, pones una GPO que pr ejemplo configure el Internet Exporer para usar un proxy, y restringir el acceso a determinadas configuraciones del IE, la GPO se alpicará a todos los usuarios de esa OU, pero eso es lo que está explicado en el post de Guillermo.
Filtering the Scope of a GPO
http://msdn.microsoft.com/en-us/library/aa373513(VS.85).aspx
How to Implement Group Policy Security Filtering
http://www.windowsnetworking.com/articles_tutorials/Group-Policy-Security-Filtering.html
para hacer a un usuario Administrador, o del grupo que sea, mediante GPO debes utilizar los grupos restringidos de manera que puedes configurarlo de 2 maneras, detallando los «Miembros» de esos grupos o si el usuario es «Miembro de» especificando los grupos a los que pertenecera , revisa este articulo para profundizar un poco mas
Grupos restringidos
http://technet.microsoft.com/es-es/library/cc785631(WS.10).aspx
acá tienes el procedimiento para hacer que un grupo sea administrador de estaciones de trabajo, en forma automática a través de GPO
Cómo configurar un grupo global para ser un miembro del grupo Administradores en todas las estaciones de trabajo:
http://support.microsoft.com/kb/320065/es
Si USers te refieres a la carpeta por defecto que se crea debajo del dominio, no es una OU, es una carpeta, por lo que la única GP que se aplica a ella es la del dominio; es sólo a título informativo.
No entiendo bien la pregunta socio; tú tienes OUs, y sobre esas OUs, creas las GPO; si en una OU hay cuentas de usuario y máquina, y pones una GPO para configurar aspectos de ambos, se aplicará por defeto a todos los usuarios/máquinas de esa OU; que quieres que unos sí y a otros no, usas el filtering scope por ejemplo.
Si en la OU que dices de directores, pones una GPO que pr ejemplo configure el Internet Exporer para usar un proxy, y restringir el acceso a determinadas configuraciones del IE, la GPO se alpicará a todos los usuarios de esa OU, pero eso es lo que está explicado en el post de Guillermo.
Filtering the Scope of a GPO
How to Implement Group Policy Security Filtering
Que tal no Javier la estructira que tengo es que cree 2 OU’s una llamada User y la otra Directores
Igualmente les dejo las imagenes para quevena la estructura que tengo.
A cada OU le aplique una, GPO, a la OU de user, le aplique una GPO a la de directores no le aplique ninguna GPO pensando que no se aplicaria ninguna restriccion pero lei por alli que se aplica la del dominio.
Entoces quiero es que todos las cuentas que esten en la OU de Directores, tengan persmiso de administrador en la maquina donde inicie sesion.
Yno consigo realmente habilitar ciertos parametros al momento de editar la GPO, eh alli el detalle.
Otra cosa como deshabilito e las directivas de contrasña que no sea neceseario colocar una contraseña compleja si no simple ejemplo 12345678, en la GPO de default policy coloque Enabled a la a la casilla de complejidad de contraseña. en todas las GPO pero nada al momento de crear la cuenta y colocar un contraseña simple no me deja colocar.ç
A cada OU le aplique una, GPO, a la OU de user, le aplique una GPO a la de directores no le aplique ninguna GPO pensando que no se aplicaria ninguna restriccion pero lei por alli que se aplica la del dominio. Entoces quiero es que todos las cuentas que esten en la OU de Directores, tengan persmiso de administrador en la maquina donde inicie sesion.
Y no consigo realmente habilitar ciertos parametros al momento de editar la GPO, eh alli el detalle.
Otra cosa como deshabilito e las directivas de contrasña que no sea neceseario colocar una contraseña compleja si no simple ejemplo 12345678, en la GPO de default policy coloque Enabled a la a la casilla de complejidad de contraseña. en todas las GPO pero nada al momento de crear la cuenta y colocar un contraseña simple no me deja colocar.ç
Saludos
Si no quieres que a la OU Directores se aplique una GPO no basta con no «linkar» ninguna, sino que debesbloquear la herencia de las GPOs de orden superior, en este caso, la del dominio .
A parte, si encima quieres que los usuarios sean Administradores locales, deberás crear otra GPO y aplicar lo que te comentan Pep y Guillermo.
zodiac_, vamos por partes, primero porque lo que dices no es lo que se ve en las capturas, y segundo vamos a ver lo que necesitas.
Entonces por lo primero, según dices tienes la GPO en Users, que en realidad se llama «empresa user» y que no es lo mismo ya que en Users no se pueden poner GPOs directamente.
Además, de acuerdo a http://a.imageshack.us/img84/3434/dc3w.jpg esa GPO «empresa user» está enlazada a nivel de dominio, y por lo tanto afectará a todo el dominio.
Debe quedar enlazada solamente como muestra http://a.imageshack.us/img684/2999/dc2zd.jpg
Para el tema de contraseñas: todo lo que sea referido a directivas de cuentas (contraseña, bloqueo y Kerberos) es *únicamente a nivel de dominio* y se maneja con la Default Domain Policy.
Poniéndolas a nive de OU no tendrás el resulado que buscas
Hasta W2003 no tienes alternativa. Deberías migrar a W2008 por lo menos, para tener diferentes directivas de contraseña en el mismo dominio.
Si lo que quieres es que cada director sea administrdor local de su propia máquina (y nada más) creo que lo más fácil y rápido es que lo hagas individualmente en cada equipo, porque de otra manera deberías crear tantas OU y GPOs como directores tengas.
Ya entiendo mejor al estructura de las GPO, voy a dar la pregunta como resuelta, cualquier duda lo colocare por aca.
Ok. 🙂
A parte del link de explicación sobre las GPOs de Guillermo, en www.secondnug.com, en la parte de IT Pro, puedes encontrar un par de PPTs míos sobre las GPOs así como otros 2 webcasts, uno teórico y otro totalmente práctico con el «Demo effect» :-P, donde intento explicar cómo funcionan y cómo aplicarlas.
The most misleading thing about Group Policy is its name—Group Policy is simply not a way of applying policies to groups! Instead, Group Policy is applied to individual user accounts and computer accounts by linking Group Policy Objects (GPOs), which are collections of policy settings, to Active Directory containers (usually OUs but also domains and sites) where these user and computer accounts reside. So the newbie’s question concerning Group Policy is usually, “How can I get this GPO to apply to this group?” The answer to this question is: by implementing security filtering.
Understanding Security Filtering
Security filtering is based on the fact that GPOs have access control lists (ACLs) associated with them. These ACLs contain a series of ACEs for different security principals (user accounts, computer accounts, security groups and built-in special identities), and you can view the default ACL on a typical GPO as follows:
- Open the Group Policy Management Console (GPMC)
- Expand the console tree until you see the Group Policy Objects node.
- Select a particular GPO under the Group Policy Objects node.
- Select the Delegation tab in the right-hand pane (see Figure 1).
Figure 1: Viewing the ACL for the Vancouver GPO using the Delegation tab
For a more detailed view of the ACEs in this GPO ACL, click the Advanced button to display the familiar ACL Editor (Figure 2):
Figure 2: Viewing the ACL for the Vancouver GPO using the ACL Editor
An obvious difference between these two views is that the ACL Editor displays the Apply Group Policy permission while the Delegation tab doesn’t. This is because the Delegation tab only displays ACEs for security principles that actually process the GPO, and that implicitly means those security principals have the Apply Group Policy permission set to Allow. More specifically, if you want a GPO to be processed by a security principal in a container linked to the GPO, the security principal requires at a minimum the following permissions:
- Allow Read
- Allow Apply Group Policy
The actual details of the default ACEs for a newly created GPO are somewhat complex if you include advanced permissions, but here are the essentials as far as security filtering is concerned:
| Security Principal |
Read |
Apply Group Policy |
| Authenticated Users |
Allow |
Allow |
| CREATOR OWNER |
Allow (implicit) |
|
| Domain Admins |
Allow |
|
| Enterprise Admins |
Allow |
|
| ENTERPRISE DOMAIN CONTROLLERS |
Allow |
|
| SYSTEM |
Allow |
|
Note that Domain Admins, Enterprise Admins and the SYSTEM built-in identity have additional permissions (Write, Create, Delete) that let these users create and manage the GPO. But since these additional permissions are not relevant as far as security filtering is concerned, we’ll ignore them for now.
The fact that Authenticated Users have both Read and Apply Group Policy permission means that the settings in the GPO are applied to them when the GPO is processed, that is, if they reside in a container to which the GPO is linked. But who exactly are Authenticated Users? The membership of this special identity is all security principals that have been authenticated by Active Directory. In other words, Authenticated Users includes all domain user accounts and computer accounts that have been authenticated by a domain controller on the network. So what this means is that by default the settings in a GPO apply to all user and computer accounts residing in the container linked to the GPO.
Using Security Filtering
Let’s now look at a simple scenario where you might use security filtering to resolve an issue in Group Policy design. Figure 3 below shows an OU structure I developed in a previous article. Note that the Vancouver top-level OU has three departments under it defined as second-level OUs, with user and computer accounts stored below these departments in third-level OUs:
Figure 3: Sample OU structure for Vancouver office
Let’s say that of the fifteen users who work in the Sales and Marketing Department in Vancouver, three of them are senior people who have special requirements, for example access to certain software that other people in the department shouldn’t have access to. Such software could be provided to them by publishing it in Add or Remove Programs using a user policy-based software installation GPO. The trouble is, if you link this GPO to the Sales and Marketing Users OU then all fifteen users in the department will have access to it through Add or Remove Programs. But you only want this special group of three users to be able to access the software, so what do you do?
You could create another OU beneath the Sales and Marketing Users OU and call this new OU the Senior Sales and Marketing Users OU. Then you could move the user accounts for the three senior employees to this new OU and create your software installation GPO and link it to the new OU. While this approach will work, it has several disadvantages:
- It makes your OU structure deeper and more complicated, making it harder to understand.
- It disperses user accounts into more containers making them more difficult to manage.
A better solution is to leave your existing OU structure intact and all fifteen Sales and Marketing users in the Sales and Marketing Users OU, create your software installation GPO and link it to the Sales and Marketing Users OU (see Figure 4), and then use security filtering to configure the ACL on the software installation GPO to ensure that only the three senior users receive the policy.
Figure 4: Senior Sales and Marketing Users Software Installation GPO
To filter the software installation GPO so that only users Bob Smith, Mary Jones, and Tom Lee receive it during policy processing, let’s first use Active Directory Users and Computers to create a global group called Senior Sales and Marketing Users that has only these three users as members (see Figure 5):
Figure 5: Membership of the Senior Sales and Marketing Users global group
Note that you can store this security group in any container in the domain, but for simplicity you’ll probably want to store it in the Sales and Marketing Users GPO since that’s where its members reside.
Now go back to the GPMC with the software installation GPO selected in the left-hand pane, and on the Scope tab of the right-hand pane, remove the Authenticated Users special identity from the Security Filtering section and then add the Senior Sales and Marketing Users global group (Figure 6):
Figure 6: Filtering the GPO so it only targets the Senior Sales and Marketing Users group
That’s it, we’re done! Now when policy is processed for a user account residing in the Sales and Marketing Users OU, the Group Policy engine on the client will first determine which GPOs need to be applied to the user. If the user is a member of the Senior Sales and Marketing Users security group, the following GPOs will be applied in the following order (assuming we haven’t used blocking or enforcement anywhere):
- Default Domain Policy
- Vancouver GPO
- Sales and Marketing GPO
- Sales and Marketing Users GPO
- Senior Sales and Marketing Users GPO
If however the user is one of the other twelve (junior) members of the Sales and Marketing Department, then the last policy above (Senior Sales and Marketing Users GPO) will not be applied to them. In other words, the published software will only be made available to Bob, Mary and Tom as desired.
The Power of Security Filtering
The power of security filtering is that it allows us to simplify our OU structure while still ensuring that Group Policy is processed as designed. For example, in my original OU structure for Vancouver (see Figure 3 above) I created separate OUs for three departments in that location, namely the IT Department, Management, and Sales and Marketing. In Toronto however I could have taken a different approach and lump all my users and computers together like this (Figure 7):
Figure 7: Toronto has a simpler OU structure than Vancouver
Then I could group user and computer accounts in Toronto into global groups like this:
- IT Department Users
- IT Department Computers
- Management Users
- Management Computers
- Sales and Marketing Users
- Sales and Marketing Computers
I could then create GPOs for each group of users and computers in Toronto, link these GPOs to the appropriate container, and use security filtering to ensure they are applied only to the desired security principals (Figure 8):
Figure 8: Using Group Policy to manage users in Toronto
The main downside of this approach is that as you flatten your OU structure you can end up with lots of GPOs linked to each OU, which can make it harder at first glance to figure out which policies are processed by each user or computer unless you examine in detail the security filtering setup.
Espacio de Jorge Mario Aristizábal Correa 