Active Directory: Estructuras de Active Directory
Aunque frecuentemente se cumple que más sencillo es mejor, a veces podría pensar en aplicar un diseño más creativo en su infraestructura de Active Directory.
Brien M. Posey
Una cosa siempre me ha sorprendido al mirar las implementaciones de Active Directory del mundo real: Aunque ciertamente hay excepciones, en la mayoría de los casos, las organizaciones se pegan con la configuración más simple con la que realmente pueden salirse.
En cierto modo, esto no debería ser una sorpresa. Me recuerda de un profesor universitario que a menudo dice que debemos vivir la vida según el principio de beso — mantenga It Simple, Stupid. Tal vez en ninguna parte este principio aplicar más precisión que el mundo de la informática.
Cualquier profesional sabe mantener las cosas simples reduce las posibilidades de tener problemas. También hace mucho más fácil la solución de problemas cuando algo va mal. Mientras que seré el primero en admitir que hay algo que decir para mayor simplicidad, cuando se trata de su infraestructura de Active Directory, puede mejor servido por una estructura más creativa.
No hay absolutamente nada de malo con el uso de una topología de Active Directory estándar. Hay una razón que Microsoft hizo la topología estándar por defecto. Estos diseños un poco más detallados, sin embargo, sería más apropiados para grandes organizaciones que necesitan segregar responsabilidades de gestión.
Dominios de usuario
En configuración de Active Directory más reales, la estructura de dominio imita la estructura geográfica de la organización. Por ejemplo, si una organización tiene tres oficinas, es probable que tenga tres dominios. Ciertamente no quiere decir que cada organización utiliza este diseño, pero es el tipo más común de la estructura de Active Directory. Mientras geográficas topologías de Active Directory son comunes y realmente eficaz, también puede considerar algunas estructuras de dominio alternativo.
Como sin duda eres consciente, Active Directory es realmente nada más que una base de datos elaborada. Una base de datos de Active Directory está lleno de diferentes tipos de objetos. Cada objeto se le asigna uno o más atributos. Algunas organizaciones de basan de su estructura de dominio en tipos específicos de objetos de Active Directory. Un claro ejemplo de este tipo de clasificación es dominios de usuario.
Un dominio de usuario es un dominio de Active Directory que tiene el único propósito de administrar cuentas de usuario. Para dar una idea de por qué esto es útil, considere una de las empresas donde solía trabajar. Esta organización tenía unos mil usuarios. Siempre hubo una alta tasa de rotación de los empleados. En consecuencia, la organización emplea a dos personas cuyo trabajo es crear, provisión y eliminar cuentas de usuario.
En este tipo de situación, un dominio de usuario resultó útil. Este tipo de estructura de dominio da los usuarios encargados de control administrativo total de mantenimiento de cuentas sobre las cuentas de usuario. No, sin embargo, conceder acceso a otros objetos de Active Directory o funciones.
Hay otras maneras de lograr este tipo de aislamiento de derecho administrativo. Aún así, una estructura de dominio de usuario podría ayudar a una organización a organizarse mejor. Si nada más, ayuda a hacer los dominios individuales que menos abarrotado. También proporciona un sentido de aislamiento físico de administrativo. Algunas organizaciones esto podrían preferir el aislamiento lógico y administrativo que puede ocurrir cuando varios tipos de objeto residen en un dominio común.
Dominios de recursos
Dominios de recursos son similares a los dominios de usuario. Estos son usados para mejorar la seguridad o para hacer la estructura de Active Directory más lógico o más manejable y de único propósito en la naturaleza. Hay implementaciones reales de Active Directory en el que todos los ordenadores de sobremesa se agrupan en un dominio de recursos dedicados. También hay otros dominios de recurso utilizados para otros tipos de recursos. Por ejemplo, una organización coloca todos los servidores que ejecutan su principal aplicación de línea de negocio (LOB) en un dominio de recursos dedicados.
Dominios de recursos son probablemente los más útiles cuando se está tratado como dominios de gestión. Por ejemplo, he creado un bosque de Active Directory dedicado diseñado para actuar como un dominio de administración para mis servidores Hyper-V. Hay un par de razones por qué elegí hacerlo.
La primera es una razón de gestión. System Center Operations Manager 2012 (y un número de otros productos de administración) sólo pueden administrar servidores que son miembros de un dominio de Active Directory. No quería unirse a mis servidores Hyper-V para mi dominio principal porque todos mis controladores de dominio para mi dominio principal están virtualizados. No quería el riesgo de no poder iniciar sesión en un servidor de Hyper-V simplemente porque los controladores de dominio virtuales fuera de línea. Unirse a los servidores de Hyper-V para un bosque dedicado de administración de Active Directory solucionó este problema.
La otra razón que decidí crear un dominio de recursos dedicados para mis servidores Hyper-V tiene que ver con algunas de las novedades en Hyper-V versión 3.0. Una de las características de Hyper-V 3.0 que más me emociona es la capacidad de replicar una máquina virtual (VM) de un servidor a otro.
Este tipo de replicación no es necesariamente una solución clúster de conmutación por error, sino más bien una solución de recuperación ante desastres que puede ayudarle a mantener una copia actualizada de sus máquinas virtuales en un servidor de host alternativo. Si algo sucediera a un arreglo de discos o host primario de Hyper-V, hay otra copia de la VM se puede contar con. Para poder utilizar esta función, sin embargo, el servidor y el servidor de réplica deben ser autenticados.
La forma más fácil de proporcionar esta autenticación es unir ambos servidores a un dominio común y utilizar Kerberos. Como tal, la creación de un dominio de recursos dedicados para servidores Hyper-V tiene perfecto sentido. Esto es especialmente cierto cuando se considera que hay otras funciones de Hyper-V que también requieren la pertenencia a un dominio.
Usuario y los dominios de recursos no son mutuamente excluyentes, por cierto. Algunas organizaciones usan una combinación de recursos y los dominios de usuario dentro de un bosque de Active Directory común. Ambos tienen sus puntos fuertes, y se pueden aplicar tanto como sea necesario.
Topología geográfica
La mayoría de las implementaciones de Active Directory en el mundo real se basa en la estructura geográfica. Por ejemplo, una organización con cinco sucursales puede utilizar cinco dominios separados: uno para cada oficina que incluye todas las máquinas físicas dentro de esa oficina. Técnicamente, no hay nada malo con el uso de este tipo de topología de Active Directory, pero hay algunas cosas que usted debe considerar.
En primer lugar, es importante no confundir la estructura de dominio con la estructura del sitio. La estructura del sitio de Active Directory siempre debe imitar la topología geográfica de una organización. Cada enlace de wide area network (WAN) hay entre oficinas, debe haber un vínculo de sitio correspondiente en Active Directory. También, los equipos que se encuentran dentro de una oficina física deben colocarse dentro de un sitio común de Active Directory. Idealmente, cada ubicación debe usar una subred dedicada, porque no puede haber una única subred abarcar varios sitios de Active Directory.
La razón que es tan importante la estructura del sitio de Active Directory es porque la estructura del sitio tiene un impacto directo en el volumen de tráfico de replicación de Active Directory que puede fluir a través de los enlaces WAN. Por ejemplo, imagine una organización tiene varias sucursales, pero optó por configurar su Active Directory como un único dominio. Una vez más, técnicamente no hay nada malo en ello, pero puede ser ineficiente.
En una situación como la, se podían hacer actualizaciones en el directorio activo potencialmente a cualquier DC puede escribir en cualquier lugar dentro de la organización. Cuando se produce una actualización, es responsabilidad de la DC para hacer la actualización disponible para los otros controladores de dominio.
Porque esta organización no hace uso de la estructura de una sitio adecuado, una actualización común no podrá pasar de un enlace WAN varias veces. Por ejemplo, si hubo cinco DCs de una sucursal, una actualización de Active Directory podría potencialmente llevarse a través del enlace WAN cinco veces, una vez cada CC.
Un DC en cada sitio de Active Directory actúa como un servidor cabeza de puente. Es trabajo del servidor cabeza de puente recibir actualizaciones de Active Directory de a través del enlace WAN. Luego distribuye esas actualizaciones a los otros controladores de dominio dentro del sitio. Esto significa que las actualizaciones de directorio activo existiría sólo tendrá que ser enviado a cada sucursal una vez, independientemente de cuántos DCs dentro de esa sucursal.
¿Qué pasa con las organizaciones que utilizan un dominio independiente para cada sucursal? Si cada sucursal tiene un bosque de Active Directory dedicado, usted no necesita preocuparse acerca de la definición de sitios de Active Directory. Por otro lado, si cada dominio es miembro de un bosque común, entonces definitivamente debería implementar una estructura adecuada de sitio de Active Directory como una forma de mantener el tráfico de replicación de Active Directory de nivel de bosque en jaque.
Hay muchas maneras diferentes para configurar una topología de dominio de Active Directory. En última instancia, usted debe elegir la topología que hace más conveniente para la distribución física de su organización y la infraestructura de red. Esto podría ser un modelo de dominio único, o un modelo de múltiples dominios que se basa en la proximidad geográfica, los usuarios o incluso recursos.
.jpg)
Brien PoseyMVP, es un escritor técnico freelance con miles de artículos y decenas de libros en su haber. Usted puede visitar el sitio de Web de Posey en brienposey.com.