Soy un profesor que enseña Active Directory y hace tiempo que me pregunto lo siguiente: Al planificar una nueva estructura de AD, ¿tiene sentido crear las ubicaciones en el DIT (árbol de información de directorio) como unidades organizativas? ¿O no es una buena idea porque las ubicaciones se pueden configurar como objetos de todos modos? ¿Cuál es un buen enfoque aquí?
¿Cuáles son los argumentos a favor de los sitios como unidades organizativas? ¿Cuáles son los argumentos en contra de Sites as OUst?
Respuesta1
Es una práctica normal que la configuración de sus sitios y subredes describa la red física lo más fielmente posible, con vínculos a sitios que describan cómo están conectados los sitios individuales. Si se hace correctamente, esto permite a AD tomar algunas decisiones bastante inteligentes con respecto a qué controladores de dominio usar para dar servicio a sus autenticaciones, etc. (como cuál debería hacerse cargo de un sitio determinado si uno deja de funcionar durante un período). En una gran empresa esto puede ser de importancia crítica. Un punto importante es asegurarse de tener también objetos de subred definidos para todas sus subredes, ya que lo primero que hace un dispositivo al iniciar Windows es intentar determinar dónde está. Si no puede hacerlo, entonces cualquier DC en su red es un juego limpio para usar para la autenticación, lo que puede resultar en un rendimiento muy lento si tiene un DC infrautilizado en el extremo más alejado de un trozo de cuerda empapada.
Respuesta2
No existe una respuesta correcta o incorrecta para la creación de unidades organizativas basadas en una ubicación frente a un organigrama. Incluso una combinación de ambos puede funcionar. La respuesta es 100% basada en las necesidades de la organización. Créame cuando digo que cualquier diseño que elija no hará felices a todos. En mi opinión, las unidades organizativas deberían crearse principalmente para delegar privilegios administrativos. Las unidades organizativas pueden dividir la responsabilidad de los objetos AD cuando también crea un grupo de seguridad y delega el control de la unidad organizativa a ese grupo. Esto soluciona el mayor dolor de cabeza de saber quién gestiona qué.
Otras razones típicas para la creación de unidades organizativas, como la aplicación de GPO o la identificación de la ubicación geográfica de objetos, se pueden lograr de manera más sencilla. Los GPO se pueden aplicar mediante filtros WMI, filtrado de grupos de seguridad o vincularse a sitios de AD. No cree una unidad organizativa solo para aplicar un GPO, a menos que ese GPO sea para completar grupos de administradores locales a través de grupos restringidos (pista). La ubicación física de los objetos debe almacenarse en atributos de cada objeto. Consulta esos atributos cuando quieras saber en qué ciudad o edificio se encuentra ese usuario o computadora. Tienes poco control sobre las personas que se mueven de un lugar a otro, y es por eso que las estructuras de unidades organizativas basadas en la ubicación no hacen un buen trabajo al decirte dónde está algo. fisicamente lo es. Claro, los atributos también pueden eventualmente ser incorrectos, pero actualizar un atributo tiene menos implicaciones que cambiar las unidades organizativas.
Respuesta3
Active Directory le ofrece una manera de dividir la topología lógica de la topología física.
Puede definir varios sitios, con controladores de dominio en cada uno de ellos. Los sitios se asignan a subredes IP y cada computadora del dominio puede buscar el controlador de dominio "más cercano" según su subred IP. También puede administrar la replicación de información de AD entre sitios.
Definitivamente deberías aprovechar esto, porque AD está estructurado para ser multisitio y resistente a sitios.
TL;DR: DeberíasnoAsigne sus sitios físicos a unidades organizativas y no utilice múltiples dominios. AD es más que capaz de ocuparse de múltiples sitios; Definitivamente no se necesitan varios dominios o unidades organizativas específicas del sitio para manejar esto.
Más información aquí:https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/understanding-active-directory-site-topology