Active Directory – Resumen (Relacionando Notas)

Hace tiempo que vengo publicando notas sobre Windows Server y específciamente sobre Active Directory, y lo que me estoy dando cuenta es que falta relacionarlas.

En cada una de las notas se trata sólo una parte, lo cual es lógico por un tema de extensión, de otra forma terminaría escribiendo un libro

En esta nota voy a hacer una recopilación, lo más ordenada posible, que permita comprender en forma resumida desde el “por qué”, diferentes componentes, y cómo se relacionan entre sí. Además por supuesto agregaré información que no está en ninguna de las notas hasta ahora

Debemos tener en cuenta, que algunas de las primeras notas seguramente fueron hechas sobre Windows Server 2003, luego con Windows Server 2008, luego Windows Server 2008-R2 (que no es lo mismo), y las últimas sobre Windows Server 2012. Lo importante es que conceptualmente no ha cambiado mayormente, todos los conceptos, inclusive desde Windows 2000, son válidos en Windows 2012, lo que se ha agregado es nueva funcionalidad en cada versión

Comencemos por lo más básico ¿Por qué usar Active Directory? La respuesta no siempre es sencilla; tenemos dos alternativas en ambiente Microsoft: Grupo de Trabajo o Dominio, y cada uno tiene sus ventajas e inconvenientes

Básicamente un Grupo de Trabajo, tiene ventajas importantes en cuanto a costo, ya que no es requerida la instalación de un servidor, cuyo costo ya sea tanto por hardware como por software es mucho mayor a un sistema de escritorio

La limitación importante del ambiente de Grupo de Trabajo radica principalmente en que se debe administrar cada máquina en forma individual. Esto último como es fácil de ver se incrementa directamente con la cantidad de máquinas

En general se dice que un Grupo de Trabajo no debería incluir más de 10 o 12 máquinas, pero he visto estructuras de más de 100, no se pueden imaginar el trabajo que llevaba y el descontrol de esa empresa

Para no extenderme más sobre el tema, vean la siguiente nota:

Dominios y Grupos de Trabajo – Autenticación y Autorización

Una vez decididos a montar nuestro ambiente de Dominio Active Directory hay una parte muy, pero muy, importante que muchos pasan de largo, y que luego les puede traer problemas que dificulten la administración, inclusive algunas configuraciones iniciales son de bastante trabajo y riesgo si las queremos cambiar luego.

El ambiente Microsoft tiene algo muy bueno, pero que se puede convertir en un inconveniente: la facilidad de uso

Esta facilidad de uso permite que cualquiera sin prácticamente ningún conocimiento instale y configure un Dominio, pero la pregunta fundamental es ¿le servirá para su organización? Esta instalación con todos los valores por omisión ¿es la adecuada a sus necesidades?

A diario se ven ejemplos en los foros de Technet de Active Directory que hay muchos que instalaron, sin tener los conocimientos mínimos y básicos como para crear la infraestructura adecuada

Lo anterior, y en determinada medida, se vuelve contra Microsoft, porque en cuanto tiene dificultados o problemas lo primero que piensa es “Active Directory no sirve, tiene problemas, no hace ‘lo que yo quiero’ y un largo número de etcéteras”
En la mayoría de los casos esto no es así. O no lo configuraron adecuadamente, o le están pidiendo cosas que no son del sistema, o inclusive muchas veces no toman medidas mínimas de seguridad”

Entonces antes de crear nuestro Dominio o Dominios, hay que pasar mínimo por tres fases:

  • Diseño: donde debemos definir “los grandes rasgos”, por ejemplo y fundamental definir los objetivos concretamente, cuánto abarcará de nuestra organización, planes a futuro, decisiones empresariales, etc.
  • Planificación: debemos definir cómo alcanzaremos lo requerido en el punto anterior. Habrá decisiones sobre cantidad de Dominios, Sites, planificación de tiempos y recursos disponibles, priorización de objetivos, etc.
    En esta etapa se deberían hacer pruebas de laboratorio simulando el ambiente a implementar.
    Y siendo estructurados, en esta etapa deberían documentarse los procedimientos de instalación de cada uno de los equipos, procedimientos, etc.
  • Implementación: esta es la etapa más sencilla si se ejecutaron adecuadamente las dos anteriores ya que es sólo la instalación y configuración de acuerdo a la documentación proveniente de la planificación.
    Puede involucrar implementaciones piloto antes de la general

Los problemas más graves comienza cuando se comienza “por atrás”: implementando, sin tener definidos ni objetivos, ni recurso, ni cómo se va hacer o inclusive si se puede hacer

Lo problemático de este sistema de tres etapas, es que aunque la tercera es sencilla (seguimos el asistente … next … next …) las dos primeras requieren conocimientos más o menos profundos, y que son lo que les falta a muchos

Y lamentablemente este tema no lo podemos cubrir en una nota, lleva mucho tiempo de lectura, experiencia, muchos conocimientos de cómo funciona internamente, la arquitectura del sistema, etc. Hace tiempo Microsoft tenía un curso de Diseño de Active Directory que lamentablemente ha discontinuado. Era muy útil para gente que teniendo experiencia quería dedicarse al diseño y planificación, que es lo fundamental de una implementación

Algo aunque muy básico lo pueden encontrar en:

Consideraciones Básicas de Diseño de Dominios de Directorio Activo

Suponiendo que nos hemos decidido a crear un ambiente de Dominio veamos algunos requisitos en:

Comprender Active Directory

El paso siguiente será seguir asistentes, y es variable de acuerdo al sistema operativo. Hasta Windows Server 2008-R2 con DCPROMO.EXE y partir de Windows Server 2012 instalando los binarios y siguiendo el asistente

Algo importante a tener en cuenta: dependiendo del sistema operativo de los Controladores de Dominio, existen diferentes niveles de funcionalidad, tanto a nivel de Dominio como de Bosque (Forest)
Un artículo con los detalles lo pueden encontrar en:

Understanding Active Directory Domain Services (AD DS) Functional Levels

Si desean ver los procedimientos paso a paso para crear una estructura de dos Dominios en relación Padre-Hijo, dentro del mismo Bosque, en Sitios separados, e inclusive con la implementación de un RODC (Read Only Domain Controller), en el siguiente enlace tienen el procedimiento sobre Windows Server 2008-R2

Instalación del Primer Controlador de Dominio del Dominio Raíz

Instalación del Segundo Controlador de Dominio del Dominio Raíz – Controlador Adicional – Controlador de Dominio Réplica

Creación de un Subdominio (Child Domain) en un Sitio (Site) Diferente – Primer Controlador de Dominio

Creación de un Subdominio (Child Domain) en un Sitio (Site) Diferente – Segundo Controlador de Dominio (Core Server)

Si nos enfocamos a nivel de los archivos que consitituyen un Dominio, tenemos dos partes fundamentales: la base propiamente dicha donde se guarda gran parte de la información (el archivo NTDS.DIT), y las Directivas de Grupo o GPOs (la carpeta Sysvol)

La información contenida en estos dos componentes será replicada, de acuerdo a necesidad, a todos los Controladores de Dominio del Dominio, o aún a todos los Controladores de Dominio del Bosque

Aclaremos un poco esto último

La carpeta Sysvol contiene una porción de las Directivas de Grupo (GPOs), luego es replicada solamente a los Controladores de Domino del propio Dominio. Esto es así porque las GPOs se definen a nivel de Dominio. El protocolo de replicación es dependiendo de la versión del sistema operativo FRS (File Replication Service) o DFS-R (Distributed File System Replication). Esta forma de replicación es totalmente independiente de la que usa la base (NTDS.DIT) que es diferente

Respecto a la base (NTDS.DIT) es básicamente una base con el motor de Exchange, y aunque es un único archivo en realidad tiene tres o más particiones internas (normal y actualmente 5) y cada una con diferente alcance de replicación

Las particiones son:

  • Schema (Esquema)
    Que es la definición de atributos y clases de Active Directory
  • Configuration (Configuración)
    Que contiene la configuración de nuestro Bosque, puede contener la configuración propia de Exchange, la definición de Sites, etc.)
  • Domain (Dominio)
    Esta es la que contiene todos los objetos de nuestro Dominio ya sean usuarios, grupos, cuentas de máquina, etc.

Las particiones Schema y Configuration se replican en todos los Controladores de Dominio del Bosque

La partición Domain se replica en todos los Controladores de Dominio del Dominio. Y para ser detallistas, un parcial se replica como sólo lectura a los Catálogo Global

En un sistema operativo igual o superior a Windows Server 2003, y si configuramos, o mejor si dejamos que el asistente de promoción instalara y configurara el servicio DNS, además tendremos dos particiones más

  • Forest DNS Zones
    Que contiene la zona _msdcs.<dominio.raiz>
    Se replica en todos los Controladores de Dominio con el servicio DNS en el Bosque
  • Domain DNS Zones
    Que contiene la zona <dominio.sufijo>
    Se replica en todos los Controladores de Dominio con el servicio DNS en el Dominio

Información más detallada pueden encontrar en esta nota:

Active Directory Replication – A Fondo – Parte 1

Y si alguien desea profundizar aún más en el tema replicación vea esta otra nota:

Active Directory Replication – A Fondo – Parte 2

 

Un punto muy importante a tener en cuenta es la resolución de nombres de máquina, que en general es poco comprendido

La dificultad es que en realidad una máquina tiene dos nombres: el Nombre NetBIOS y el Hostname, que aunque por omisión son iguales, los métodos de resolución de uno y otro son diferentes, aunque Microsoft tiene una implementación que ayuda

Para comprender el tema vean la siguiente nota:

Resolución de Nombres de Máquina (DNS, WINS, etc.)

Y como la resolución de nombres en ambiente de Dominio es por DNS, es importantísimo entender cómo funciona DNS

Así que acá van tres notas para no perderse:

Cómo Funciona DNS – Parte 1

Cómo Funciona DNS – Parte 2

Cómo Funciona DNS – Parte 3 – Integración con Active Directory

 

Volviendo al tema central del funcionamiento de Active Directory veremos y trataremos de demistificar algo poco comprendido: los FSMO Roles o Maestros de Operaciones

Hay dos notas que tratan el tema:

Maestros de Operaciones (FSMO Roles) – Parte 1

Maestros de Operaciones (FSMO Roles) – Parte 2

 

Y no dejemos sin comentar, otra funcionalidad que no es un FSMO Rol, y cuya utilidad es poco comprendida: el Catálogo Global

Funciones del Catálogo Global (Global Catalog)

 

Otro tema muy muy importante y que todos los días se escuchan pedidos de auxilio: la tolerancia a fallas del Dominio

Primero que nada una recomendación básica y fundamental tener por lo menos dos Controladores de Dominio en cada Dominio. Esto nos permitirá que ante la falla de uno de ellos “todo siga funcionando” hasta que podamos resolver el problema

Es importante conocer cuál es la configuración de estos Controladores de Dominio para tener tolerancia a fallas, lo pueden ver en la siguiente nota:

Controladores de Dominio: Tolerancia a Fallas

Y de todas formas “nada, nada, nada, reemplaza a un Backup (Copia de Seguridad) probada :-)

El tema de Backup (Copia de Seguridad) de los Controladores de Dominio es también algo sobre lo que hay mucho desconocimiento

Me ha llevado cinco notas, para demostrar la funcionalidad de cada una de las opciones, así como algunas consideraciones muy importantes

Controladores de Dominio: Copia de Seguridad y Recuperar (Domain Controllers Backup – Restore) – Parte 1 de …

Controladores de Dominio: Copia de Seguridad y Recuperar (Domain Controllers Backup – Restore) – Backup – Parte 2 de …

Controladores de Dominio: Copia de Seguridad y Recuperar (Domain Controllers Backup – Restore) – Restore – Parte 3 de …

Controladores de Dominio: Copia de Seguridad y Recuperar (Domain Controllers Backup – Restore) – Restore – Parte 4 de …

Controladores de Dominio: Copia de Seguridad y Recuperar (Domain Controllers Backup – Restore) – Restore – Parte 5 de …

 

Daría para mucho más, pero por ahora dejaré esta nota como está, ya que pienso que con todos los enlaces a notas del sitio tienen un buen rato para leer

Anuncios
Post a comment or leave a trackback: Trackback URL.

Comentarios

  • Jorge  On 01/03/2013 at 21:01

    Hola . una ves mas , excelente material para compartir !!!!!

  • Jorge  On 01/03/2013 at 21:10

    Digno para un libro . Al menos en PDF

    • Delprato  On 02/03/2013 at 10:05

      Costó un poco relacionarlos porque las notas no fueron hechas “de un tirón”, y hasta hay algunos temas superpuestos
      Además faltan algunos temas, de a poco iré completando
      Gracias nuevamente

  • Fer  On 03/07/2016 at 15:23

    Guillermo, excelente resumen, fui encontrando los artículos de forma separada, y con este resumen me pude guiar mejor.

    Por lo que fui viendo, recomendas no poner muchos roles en un servidor y mi pregunta es: como podría repartir estos por cuestión de seguridad y carga de procesos ?

    Siendo que voy a instalar (Windows Server 2012 R2):
    AD DS – DHCP – DNS – IIS – y quizás Exchange.

    En :
    – Servidor físico (Hyper-V)
    — Servidor Virtual 1
    — Servidor Virtual 2
    — Servidor Virtual 3

    Gracias por compartir tus conocimientos.

    • Guillermo Delprato  On 04/07/2016 at 08:49

      Hola Fer, no combinar determinados roles en un único servidor, es por varios motivos, carga, seguridad, interferencia, recuperación, etc. etc.
      AD, DNS y DHCP por ejemplo, son roles que se pueden poner juntos sin problema, no se “molestan” entre sí, y son “livianos”. IIS depende la carga puede ser más “pesado” e implica además un tema de seguridad sobre AD. Echange es uno que definitivamente no debe estar en un Controlador de Dominio. Servidor de archivos/impresoras es otro que no debería estar en un Controlador de Dominio
      Además y muy importante, siempre es conveniente tener por los menos dos Controladores de Dominio por más chico que sea el ambiente
      El problema grave que veo en la infraestructura que pones es tener un único servidor que virtualizará todos los servidors ¿haz pensado qué sucedería si ese deja de funcionar?
      Cuando se va a pensar en ambiente virtualizado, un Controlador de Dominio virutal + un “failover cluster” donde está el resto de las virtuales, inclusive otro Controlador de Dominio. Y política de Backup que estés seguro que puedes recuperar toda la información que está en el “cluster”

      • Fer  On 04/07/2016 at 10:02

        Gracias Guillermo por responder, bueno, voy a comenzar con los roles principales AD, DNS, DHCP y luego voy a pensar en un segundo servidor.
        Es interesante un “failover cluster”, pero voy a tener que profundizar en el tema.
        Saludos y gracias.

      • Guillermo Delprato  On 04/07/2016 at 12:47

        Si pones todo en un único equipo, este debe proveer tolerancia a fallas, ese es el motivo
        Pon mucha atención a eso que algunas ya lo”aprendieron por las malas” :)
        Es un poco el dicho de “no poner todos los huevos en la misma canasta” :D

Trackbacks

Este espacio es para comentarios sobre la nota. No es un sitio de soporte

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: