¡Por supuesto usted puede asignar sí políticas del grupo a los grupos de la seguridad!
Tengo que blog esto enseguida - será parte de un “GP más grande que procesa” el artículo en un cierto punto sin embargo… Pero ésta es la materia importante del IMHO que las necesidades de salir allí aprisa 
He oído la oración siguiente demasiadas veces (en una forma o la otra): “Usted puede asignar solamente objetos de la política del grupo al sitio, al nivel del dominio o a OU”…
- pero ése está solamente en parte ¡verdad! Normalmente en los newsgroup, los foros etc. esto sale de los lectores (eg. alguien que hicieron una pregunta del GP o lo que) con la impresión que usted no puede “golpeó” a miembros de un seguro Grupo de la seguridad solamente (con que le deja “Filtración del sitio/Domain/OU” y/o “Filtración de WMI” como único posible opciones disponibles). ¡Pero eso no es simplemente justo a la política asombrosa del grupo que procesa el motor!
Aun cuando “WMI que se filtra” es bastante bien sabido actualmente (después de que llegó WS2003), mucha gente tiende para olvidarse del poco - pero extremadamente eficaz y flexible - cosa llamada “Filtración de la seguridad” (aun cuando es algo más “básico” comparado a WMI)…
Hablemos de él para un minuto o dos si usted está interesado…
Usted puede fijar esta clase de filtrar dentro de la consola de la gerencia de la política del grupo (GPMC) en cualquier la lengüeta del alcance:
- o la lengüeta de la delegación (un pedacito avanzado):
Como usted puede ver, cerca DEFECTO todos los objetos de la política del grupo (GPO) incluyen “Usuarios authenticados” con ambos Permita: “Leído” y Permita: “Aplique la política del grupo” permisos fijados. Ambos permisos son necesarios para usuarios y computadoras para tomar en (o proceso) un GPO dado:
La cosa sobre el grupo muy importante de los “usuarios authenticados” es que incluye TODAS LAS cuentas del usuario Y de la computadora/objetos dentro del dominio del ANUNCIO (Reguladores del dominio también, a la derecha). Así pues, cerca omita un GPO se aplica a ambas computadoras y usuarios (no vamos a hablar de las piezas etc. de GPO que inhabilitan. ahora).
Ésa es la explicación “técnica” porqué las políticas puestas encendido
a) el sitio se aplica a TODOS LOS usuarios y computadoras dentro del sitio (el sitio de los usuarios sigue el sitio de computadora, sitio sigue IP address)
b) el nivel del dominio se aplica a TODOS LOS usuarios y computadoras dentro del dominio
c) cualquier OU dado se aplica a TODOS LOS usuarios y computadoras dentro de eso OU (y secundario-OUs particulares para esa materia)
=> porque el grupo de la seguridad de los “usuarios authenticados” está allí cerca defecto. Éstos omiten permisos en GPOs nuevo son dirigidos por algo llamado “Descriptores de la seguridad”, solamente más en eso en un cierto otro blog o artículo.
So, we have Security permission on all of our GPOs (unfortunately not the GPO links, but that’s another talk) - leaving us with GREAT power to control to whom he particular GPO should be assigned (or ‘applied’). All we need to do is to change the default permissions and <Zaboooka!> we are in complete control.
First step is generally to remove the "Authenticated Users" group from the GPO in question. Click Remove (below Security Filtering section) on the Scope tab and click OK:
Click Add… and select the domain security group you want to "hit" - click OK when done:
And <poof>, this GPO will only apply to members of "The Sales Group" - or whatever group (or user, or computer object…) you selected:
Now all you need to do is to link the GPO to the Domain Level (or Site or OU if that’s better in your case) - but the Domain Level should be fine for most environments.
Now, you could turn this around and Exclude certain groups, users or computers - by setting Deny:"Apply Group Policy" instead. In some cases that might be the best choice - but as always with "deny" you have to watch out (manly because deny overwrites allow)!
Also note, that Security groups can include both user and computer accounts - we are maybe used to thinking that groups are for users only (in my experience most admins know the "Domain Users" group - but the "Domain Computers" group is not that well known)… But, with this in mind, you could make a group of computers instead of applying a WMI filter for instance (which is generally slower).
You could use other methods for setting permissions than the GPMC (like scripts) - but the GPMC is a wonderful tool for doing this easily - no sweat!
One way of automatically creating Security Groups from members of an OU is described in my article "Configuring Granular Password Settings in Windows Server 2008, Part 2" - these groups are referred to as Shadow Groups (cool, right). In some "filtering situations" that is nice to know…
Wow - that was nice getting it off my shoulders, and now I can refer to this blog entry whenever I get the question again - and so can you of course
.
Popularity: unranked
Popularity: unranked
Written by Jakob H. Heidelberg. Read more great feeds at is source WEBSITE
no comments.
Read more articles on otherSoftware and Group Policy and GPO.
- [+] Digg: Feature this article
- [+] Del.icio.us: Bookmark this article
- [+] Furl: Bookmark this article
