Hola a todos,
En la entrada de hoy no es que vaya a reinventar la rueda ni mucho menos, pero desde hace años veo cierta confusión a la hora de identificar los distintos grupos de AD, sus funcionalidades, y su alcance.
Existen muchas referencias en la Web, y en el sitio de Microsoft, sobre los grupos, pero casi nunca queda muy claro, además hay que leer bastante para tener perfectamente clara la manera de trabajar con los grupos de seguridad, las buenas prácticas a la hora de anidarlos, y sobre todo como utilizarlos en entornos de múltiples dominios, y o con relaciones de confianza.
Hoy me quiero centrar sobre todo en la parte relativa a los entornos con relación de confianza, en distintos dominios o Forests.
Casi todas las semanas recibo alguna consulta ya sea a través del Blog, Twitter, o de algún compañero o amigo, relacionada con que tipo de grupos usar para dar acceso a Dominio A en Dominio B, o en periodos de Coexistencia en migraciones de usuarios complejas, donde queremos que un usuario acceda a los recursos de un dominio distinto.
La información que podemos encontrar por la web se resume en este cuadro:
Lo más importante es entender la funcionalidad de los grupos, en la tabla de arriba que la he sacado de Microsoft, y es la típica tabla donde nos explican que es, que hace, y los posibles miembros de cada grupo, no queda muy claro en muchas ocasiones si un grupo admite miembros de otro Forest, o solo de otros usuarios de Dominios distintos al suyo, pero dentro de su mismo Forest. A parte de los nombres que con el nombre de los grupos casi nadie sabe su finalidad.
Domain Local: La finalidad de este grupo es acceder a recursos de su propio Dominio, por eso es Dominio Local. Por lo tanto ya tenemos claro que un grupo de dominio local solo puede dar acceso a objetos de su propio dominio.
Global Group: Por el contrario los grupos de dominio Global se conciben para dar acceso a recursos dentro de cualquier dominio de su Forest, o incluso en dominios o forest con relación de confianza.
Universal Groups: Para dar acceso a cualquier recurso dentro del mismo Forest, o Forest de confianza.
Una vez aclarada la finalidad, ahora hay que entender cuales son los posibles miembros … porque claro, ojala todo fuera tan sencillo como entender la finalidad de cada grupo, además debemos conocer que usuarios, y grupos admite cada uno de ellos.
Entornos de Coexistencia, relaciones de confianza, y acceso entre forests, y Bosques de recursos.
Centrándome ya en el origen de esta entrada, me gustaría analizar detalladamente las situaciones que vivimos, y las necesidades que se nos presentan en entornos con relación de confianza, periodos de Coexistencia mientras vivimos una migración de AD entre entornos, o simplemente cuando instalamos un Forest de recursos, y debemos implementar un modelo de delegación, o de acceso a los recursos.
Voy a dar por hecho que ya hemos llegado a esta situación, que ya hemos establecido conectividad entre los distintos Dominios, relación de confianza, etc., y que por necesidades del proyecto, del servicio, o porque se ha definido así en la arquitectura o diseño del entorno, debemos dar acceso a recursos de nuestro dominio, a identidades (usuarios) de dominios externos.
Pongamos que tenemos como dominio destino donde residen los recursos a acceder contoso.com, y como dominios de origen bank.com y datum.es. Desde los dominios origen nos solicitan tener acceso a una granja de servidores llamada SW1.
Este tipo de situaciones se suelen solventar de dos posibles vías, la primera a mi modo de entender no es correcta, y la segunda si:
- Dando acceso directamente en el recurso de contoso.com a usuario origen, Grupo Universal, o Grupo Global origen. Desgraciadamente en muchas ocasiones, y motivado por las prisas se da acceso directamente a los objetos de origen en SW1, sin crear en contoso ningún tipo de grupo que controle esta delegación de permisos. Esto a la larga es un gran error, ya que no controlamos quien tiene acceso, y con el tiempo se olvida que alguien dio acceso de manera local a SW1.
- Creando en contoso.com un grupo Domain Local, con los permisos necesarios sobre la granja SW1 (la forma de dar los permisos, o accesos es indiferente), el grupo podría llamarse DL_SW1_DATUM. Ahora faltaría hacer miembros de ese grupo domain local a los usuarios o grupos de datum. En teoría habrá cierta comunicación entre datum y contoso, y se habrá definido que se genere un grupo nuevo en Datum con los usuarios que deben tener acceso a SW1, ese grupo puede ser Global o Universal. Este es el método correcto ya que nosotros controlamos a través de grupos de seguridad los accesos a nuestra granja SW1, además la nomenclatura lo deja claro haciendo mención al dominio de origen, luego se podría incluir en la nomenclatura alguna mención al tipo de acceso, pero eso ya entra en la forma de trabajar, y en los modelos de administración de cada organización, a mi me gusta crear grupos en base a roles, y tipos de permisos.
Resumiendo un poco, los únicos grupos que admiten miembros de otros Forests (bosques) son los Domain Local Groups. En esta imagen he intentado resumir que el único grupo que admite miembros de otros bosques es Domain local, y los que se pueden usar para anidar en Domain Local de otros forests son Universales y Globales.
Un saludo
Daniel Graciá
