lunes, 24 de abril de 2023

Uso Recomendado de Grupos en Dominios Windows Server



Lo primero a tener en cuenta es que existen dos clases de grupos:
  • Grupos Locales: estos grupos son los que podemos crear en cualquier instalación, salvo que sea Controlador de Dominio
    Se pueden usar para asignar privilegios únicamente en la máquina local
    Si la máquina está en grupo de trabajo, es la única posibilidad
  • Grupos de Dominio: estos grupos los creamos y administramos en los Controladores de Dominio del Dominio, normalmente a través de la consola de administración del Dominio
Hay dos temas importantes a tener en cuenta:
  • ¿Cuándo usamos cada uno? más adelante veremos las características de cada uno, y de ahí veremos el uso recomendado
  • Convención de nombres para los grupos: veamos esto primero
Como todos sabemos los grupos se usan principalmente para la asignación de privilegios (permisos y derechos). Siempre es conveniente asignarlos a grupos y no a cuentas individuales. Podemos ahorrarnos mucho trabajo a futuro en la eventualidad de un cambio, o crecimiento de la estructura
Es muy común que los administradores, en el momento de la creación decidan el nombre, sin seguir ninguna regla en especial (“¿cómo me voy a olvidar para qué lo creé?”)
Pero sin embargo pasado un tiempo, o ante cambio o asingación de nuevos administradores, el tema comienza a complicarse
Un caso típico se da cuando un administrador va a crear un grupo, y no recuerda si ya existe otro, con la membresía que necesita. Ante la duda crea uno nuevo
Y el resultado es: grupos que están duplicados, triplicados, y más :-)
A partir de lo anterior, algún administrador quiere comenzar a poner orden, pero ¿cómo identificar los repetidos? ¿lo podré borrar sin consecuencias? ¿cómo sé quién y para qué lo creó?
Y salta inmediatamente las preguntas “¿Cómo puedo saber si determinado grupo se está usando o no?” o “¿Como puedo saber qué permisos tiene el grupo en la red?”
Ninguna de las dos tiene una respuesta fácil, porque generalmente se usa el anidamiento de grupos (grupos dentro de grupos). Luego cualquier búsqueda debe tener en cuenta este anidamiento que puede tener varios niveles
Así que lo primero a tener en cuenta es que es necesario adoptar una buena convención de nombres para los grupos que creemos, que con sólo ver el nombre sepamos qué tipo de grupo es, para qué se creó, qué cuentas contiene, y qué y dónde tiene permisos ¿estamos de acuerdo supongo?
Volviendo al primer punto, debemos ver cuándo usar cada uno. Nombramos antes los Grupos Locales, pero también tenemos los Grupos de Dominio, y éstos tienen muchas más variantes.
Lo primero a tener en cuenta es el tipo, ya que pueden ser de dos diferentes:
  • Grupos de Distribución: no se pueden usar para asignar privilegios. Simplemente si tenemos una aplicación de correo integrada a Active Directory (Exchange) y habilitamos al grupo, podremos enviarle un correo al grupo y lo recibirán todos los miembros
  • Grupos de Seguridad: tienen la misma característica que el anterior con respecto al envío de correos, pero además estos sí los podemos usar para asignar privilegios
Los grupos de Dominio, además del tipo, tienen algo que se llama “Alcance” (Scope) y de acuerdo a éste tienen diferentes características tanto de membresía como del visibilidad (dónde los voy a poder usar para asignarle permisos)
Pongamos una tabla resumen porque escribir uno por uno sería muy largo, y además es interesante verlos comparativamente
Grupos
Hay dos puntos importantes a tener en cuenta:
  • Qué puede contener: ya que esto me dice qué cuentas puedo poner en el grupo (Ver las tres primeras columnas de datos)
  • Dónde lo puedo ver: es decir, dónde lo puedo usar para asignar privilegios
La asignación de privilegios en ambiente Microsoft, tiene algo muy bueno, es sumamente flexible e intuitiva, per esto mismo se puede volver en contra, porque permite hacer casi cualquier cosa sin ninguna planificación
Supongamos situaciones, si alguien no usa grupos y asigna todos los privilegios cuenta por cuenta ¿funcionará? si, por supuesto que lo hará.
Y si sólo agrupo cuentas en Grupos Globales ¿funcionará? si, también lo hará. No voy a seguir repitiendo pero funciona con cualquiera de los ámbitos de grupo, sólo limitará la membresía y el alcance
Pero por supuesto hay ventajas importantes usándolos de una forma planificada, y también teniendo en cuenta el tamaño de la organización y su crecimiento futuro. Es fácil ver que no es lo mismo un ambiente de por ejemplo 20 usuarios, que uno de 500, que de 5000, o de 50000
En un ambiente “chico” seguramente no utilizaremos anidamiento de grupos, a diferencia de el uso en organizacione más grandes. Y análogamente los requerimientos de una organización con varios miles de usuarios repartidos entre varios Dominios en diferentes sitios geográficos  no serán los mismos que los de una pequeña empresa
Voy a centrarme en una empresa mediana, o chica pero que se puede esperar crecimiento a futuro. Cuidado que lo que hoy es una pequeña empresa en un tiempo puede comenzar a ser una mediana empresa, y si nuestra base no está bien hecha comenzarán los problemas de re-organizar todo, que da bastante trabajo.
Sin entrar en una gran disquisición de los motivos, pero créanme que tiene su fundamento, Microsoft recomienda el uso para cada uno de los alcances de grupos
Grupos Locales: única alternativa en ambiente de grupo de trabajo. En ambiente de Dominio, sólo en casos que se necesiten asignar privilegios específicos locales. Ejemplos: que un grupo del Dominio sea administrador local de la máquina, o que un grupo de Dominio pueda ejecutar copias de seguridad o recuperación en un equipo en particular
Grupos Globales: se recomienda utilizarlos para agrupar cuentas con función similar. Por ejemplo, un sector, un cargo, etc.
Grupos Locales de Dominio: se recomienda utilizarlos para asignar privilegios (permisos y derechos)
Grupos Universales: se recomienda la utilización cuando se requiere agrupar Grupos Globales de diferentes Dominios
Resumiendo, para una empresa mediana, la preferencia es:
  • Agrupar por función: cuentas –> Globales (Accounts –> Global Groups)
  • Agrupar por permisos: Grupos Locales de Dominio <– Permisos (DL <– Permissiones
Más resumido: Cuentas –> Grupos Globales –> Grupos Locales de Dominio <– Permisos
O aún más: A–>GG–>DLG<–P
Respecto al uso de Grupos Universales, son muy flexibles pero hay que usarlos con cuidado, ya que bajo determinadas circunstancias pueden aumentar considerablemente el tráfico de red. Básicamente el motivo es porque no sólo el nombre, sino además la membresía será replicada a todos los Catálogos Globales del Bosque.
Y ahora sí, finalmente, si usamos lo anterior podemos pensar en una buena convención de nombres que nos sea útil a nuestras necesidades
Por ejemplo pongo una que he utilizado más de una vez y expongo algunos motivos:
  • En un ambiente multidominio, como la visibilidad puede abarcar a todos ellos sería bueno poner un prefijo que indique en qué dominio se ha creado
  • Como a primera vista no se diferencia si un grupo es Local de Dominio, o Global o Universal, sería bueno que el nombre lo indique
  • Los grupos Globales deberían indicar claramente quiénes son los miembros
  • Los grupos Locales de Dominio deberían indicar claramente sobre qué recurso y qué permisos se le han otorgado
Entonces suponiendo que tuviéramos el Dominio que típicamente usa Microsoft para su demostraciones y cursos que se llama Contoso, una posibilidad de definir nombres de grupos podría ser:
CON-GG-HR_Central
Creo que es fácil deducir que está creado en el Dominio “Contoso” (CON), que es de tipo Global (GG), y que contiene al personal de recursos humanos (HR) del sitio central (Central)
Fácilmente podría distinguir el anterior de uno que se llame SUB-GG-Mkt_Pers
Y como los Locales de Dominio se utilizarán para dar permisos entonces se podría hacer algo así:
CON-DL-Prod_DB-R
Le agrego la sigla de dominio (CON) sólo para ser consistente ya que estos grupos no podrán ser vistos en otros Dominios, DL me indica que es un grupo Local de Dominio (Domain Local), que tiene permisos sobre la base de producción (Prod_DB) y el permiso es de lectura (R=Read)
Para crear un grupo que necesite permiso de cambios sobre el recurso, utilizaría por ejemplo: CON-DL-Prod_DB-CH (CH=Change)
Y todavía podemos agregar un par más de consideraciones. Primero, recordemos que aunque podemos extendernos, serán visibles los primeros 20 caracters de los nombres de un grupo.
Y segundo, recordemos que en las propiedades de cada grupo tenemos dos campos disponibles que podemos usar a nuestra conveniencia: Descripción y Notas

Práctica de estrategia de grupos AGDLP
Descarga aquí

Resolución