Bit - loader

Introducción al diseño e implementación de Directorio Activo. Parte 1

   Artículo | Windows Server 2016 Bit - Introducción al diseño e implementación de Directorio Activo. Parte 1
Joan Carles Roca | 13/04/18

Con este empezaremos una serie de artículos sobre el diseño e implementación del directorio activo tomando como referencia Windows Server 2016.

 

 

El despliegue del directorio activo abarca típicamente tres fases: la de diseño, la de despliegue y la de operaciones. En esta serie de artículos nos ocuparemos de un despliegue estándar, pero considerando situaciones a veces no tan habituales de despliegue como por ejemplo Read-Only Domain Controllers, Microsoft Exchange o situaciones un poco más complejas, como múltiples forests.

 

En una primera fase de diseño, deberemos identificar perfectamente nuestro entorno actual, esto es, si ya tenemos una estructura de directorio activo o no, y en caso de que la tengamos, documentarla meticulosamente.

En diseño una de las cosas que deberemos tener muy claras es hacia donde queremos ir, es decir, que estructura final deseamos tener y como la vamos a administrar. Esto dictará los pasos para migrar nuestro entorno. Por ejemplo, si podemos actualizar, o deberemos migrar, si deberemos consolidar dominios en una nueva estructura, etc…

 

Por lo que respecta a los requisitos de diseño, el primer paso deberá ser diseñar la infraestructura lógica del directorio activo. La infraestructura lógica responde a como vamos a organizar el directorio activo, sus objetos y como los vamos a administrar.

  1. Primeramente deberemos decidir cuantos Forests necesitaremos
  2. En segundo lugar diseñar una estructura de dominios para cada Forest
  3. En tercer lugar diseñar la correspondiente infraestructura de DNS para cada Forest.
  4. En cuarto lugar crear un diseño para las unidades organizativas para el propósito de la aplicación de políticas de grupo y delegación del control.

 

Antes de comenzar con el diseño, es importante comprender los elementos de la estructura lógica del directorio activo.

 

AD Forest

El bosque o Forest es una colección de uno o más dominios estructurados jerárquicamente, en una relación Parent-Child. Estos dominios comparten la misma definición de clases de objetos y atributos, configuración de replicación de directorio y catálogo global. Los dominios en un mismo Forest están conectados a través de relaciones de confianza entre dominio o Trust, los cuales son bidireccionales y transitivos.

 

Todos estos conceptos los iremos desarrollando en esta colección de artículos.

 

Por lo que respecta a los objetos y atributos, tomemos como ejemplo a un objeto de la clase usuario y a sus propiedades como atributos. En un Forest, la clase de objeto usuario y sus atributos son comunes a todos los dominios, es decir cualquier usuario tiene las mismas propiedades indistintamente del dominio donde se cree.

 

 

AD Domain

Los Dominios, son el esqueleto fundamental de los Forests. Por una parte son límites de seguridad en si mismos, dado que los objetos, sean cuales sean, como un usuario, equipo etc… se crean y pertenecen a un dominio concreto, quedando administrados por las políticas o directivas de dicho dominio. El hecho de que los dominios estén organizados jerárquicamente  y den así forma a un Forest, responde a criterios de conectividad y acceso a recursos como iremos viendo.

 

De hecho los dominios se crearon en su momento, como respuesta al defectuoso crecimiento de los grupos de trabajo. En un grupo de trabajo, si queremos acceder a recursos de por ejemplo diez equipos de forma segura, necesitamos diez cuentas de usuario, una creada en cada equipo. Si los usuarios que necesitan acceder a recursos de diez equipos son siete, cada uno de ellos necesitará diez cuentas de usuario, una en cada uno de los equipos a los que tiene que acceder, esto resulta en setenta cuentas de usuario, que no se pueden sincronizar de ninguna forma y que hay que mantener (cambios de contraseña… etc).

 

En un dominio, hay unos equipos especiales, los controladores de dominio que albergan una base de datos que entre otras cosas mantiene las cuentas de usario de forma centralizada, de forma que un empleado únicamente necesita una cuenta de usuario creada en un controlador dominio para acceder a cualquier recurso en cualquier equipo del dominio. Es el conocido single sign-on. Una única cuenta para acceder a múltiples recursos en múltples equipos, obviamente si tiene acceso.

 

 

AD Organizational Units

Las unidades organizativas sirven como contenedores de objetos, se pueden anidar y son un punto de aplicación de las políticas de grupo.  Además sirven para transferir o delegar control sobre parte del directorio activo.

Los criterios para crear una estructura normalmente responde a agrupar objetos con las mismas necesidades de administración. Cabe recordar que esta estructura es visible solamente para administradores y que no es necesario que represente por ejemplo el organigrama de la empresa u otra estructura similar. La estructura de OUs, debe responder a criterios de facilidad de administración.

 

En el siguiente artículo continuaremos con los componentes y el diseño: que son las relaciones de confianza, la estructura física, replicación etc.

 

 


Entradas relacionadas
Nuestro sitio utiliza cookies para análisis. Si no estás seguro de ello, echa un vistazo a nuestra política de privacidad.