Te damos la respuesta a este dilema, al menos eso esperamos. Si tienes dudas puedes escribirlo en el apartado de preguntas, que sin dudarlo te ayudaremos
Solución:
Solución 1:
Tu plan luce bien. Ish.
-
10 controladores de dominio para menos de 100 usuarios es una proporción muy alta de controladores de dominio por usuarios. Estrictamente hablando, no necesita un controlador de dominio en cada oficina.
- No tener un controlador de dominio en un sitio resultará en un mayor tráfico a través del enlace del sitio, como resultado de la autenticación y otro tráfico del servicio de dominio que atraviesa el enlace.
- Los servicios de dominio no estarán disponibles si el enlace del sitio se cae (lo que puede ser un problema para usted o no)
-
Un solo dominio sin subdominios suena bien. Microsoft ya no recomienda el uso de subdominios, excepto en algunos casos de uso poco comunes.
- Aquí hay una buena respuesta para sus preguntas sobre dominios secundarios y unidades organizativas y, para el caso, probablemente valga la pena ver todo el hilo, ya que no parece tener ninguna experiencia con Active Directory.
-
No puede replicar OU selectivamente entre controladores de dominio. Tú tampoco quieres.
-
Es una convención común no usar el integrado
UsersoComputerscontenedores. (Y tenga en cuenta que son contenedores, no unidades organizativas). Estas son las ubicaciones a las que los nuevos usuarios y computadoras van de forma predeterminada, por lo que hace la vida más fácil si no se utilizan para nada más. Usarlos como contenedor raíz para su jerarquía generalmente no es una buena idea.
Solucion 2:
Lo siento, de antemano, por la naturaleza laberíntica de mi comentario.
Quiero usar un dominio para todos los usuarios sin subdominios. Estoy en lo cierto? En realidad, no veo la ventaja de utilizar más dominios, ni siquiera subdominios.
El dominio único es casi siempre el camino a seguir para organizaciones de casi cualquier tamaño, grandes o pequeñas (especialmente desde que Microsoft agregó una política de contraseñas detallada). El dominio único es la configuración más fácil de administrar, con diferencia.
Computadoras controladoras de dominio
Si hay recursos locales a los que los usuarios de cada oficina física pueden acceder para seguir trabajando en caso de falla de la WAN, entonces colocar un controlador de dominio (DC) en cada oficina física es ciertamente agradable. Si todos los recursos a los que acceden son remotos de todos modos, es posible que no tenga sentido implementar tantos DC.
Si su plan es usar el DC en cada oficina como servidor de archivos, también, le recomiendo encarecidamente usar Hyper-V para alojar el DC como un invitado de VM independiente. Debe intentar aislar a los controladores de dominio para que brinden servicios relacionados con el dominio y nada más, si es posible. Disminuye su superficie de ataque.
Piense en lo que sucede si alguien roba un CD de una de las oficinas y planifique eso. Debe leer sobre controladores de dominio de solo lectura (RoDC) para ver si se ajusta a sus necesidades. Si un RoDC es robado, las contraseñas de ese RoDC se ven comprometidas. Si un DC de lectura / escritura tradicional es robado todas las contraseñas (y el krbtgt hash) están comprometidos y deberá restablecer todas las contraseñas (y restablecer el krbtgt hash y reinicie todos los equipos miembros del dominio).
Sitios, subredes, replicación
Querrá configurar sitios y subredes para permitir que AD administre correctamente la topología de replicación.
¿Puedo replicar solo subárboles entre países en desarrollo? ¿Como “OU = country1, OU = Internal, CN = Users”?
No se preocupe por la replicación selectiva de AD. Tiene tan pocos datos que cualquier intento de replicar selectivamente (que es de lo que se tratan los dominios secundarios, principalmente) solo causará mucho más dolor que beneficio.
Tenga en cuenta que la latencia de replicación entre sitios (15 minutos entre sitios, de forma predeterminada) hará que desee adquirir el hábito de conectar sus herramientas de administración remota directamente al DC en una oficina cuando desee realizar cambios que sean inmediatamente “visibles” para usuarios en ese sitio. (Existe una opción para habilitar un protocolo de notificación de cambios para la replicación entre sitios que acelerará la replicación drásticamente, pero ese no es el comportamiento predeterminado del producto).
Estructura OU
La delegación de control administrativo es la primera restricción de diseño que debe utilizar para determinar la estructura de una unidad organizativa. Por ejemplo, si habrá usuarios en cada oficina remota que puedan actuar como “mesa de ayuda” y restablecer las contraseñas de los usuarios locales, entonces querrá una estructura de unidad organizativa orientada geográficamente (como ha propuesto). En algunas empresas, la estructura de la unidad organizativa se desglosa primero por líneas departamentales / de unidad de negocio porque la administración delegada se maneja a nivel de departamento / unidad de negocio. Incluso si no está planeando una delegación de control, ahora piense en cómo podría crecer la empresa en el futuro y trate de planificar eso. (Geográfica es generalmente la forma en que la gente va). Delegación de cantidades de control de listas de control de acceso (ACL) aplicadas a objetos en el directorio. Dado que un objeto solo puede tener una única ACL aplicada, y dado que hereda su ACL del contenedor (OU, en la mayoría de los casos), se coloca en, de forma predeterminada, obtener la ubicación del objeto es bastante importante.
La segunda restricción de diseño debería ser la aplicación de la directiva de grupo. Como es nuevo en AD, debería tomarse un tiempo para leer la Política de grupo. A diferencia de la delegación de control, la política de grupo es más flexible en cuanto a la aplicación a objetos que están “dispersos” en contenedores subordinados (a través de una función llamada “filtrado de seguridad”), por lo que es menos crítico que la estructura de la unidad organizativa refleje la estrategia de aplicación de la política de grupo planificada ( Sin embargo, cuando puede vincular GPO a OU sin ningún filtrado de seguridad, las cosas son mucho más simple).
Vi en alguna parte un AD donde no usaban CN = Users para los usuarios “normales”, sino un nuevo CN = “Company Users” en la raíz. ¿Es una convención común? No veo ninguna buena razón para no usar el subárbol CN = Users original.
La razón práctica es que el objeto “CN = Usuarios” es un objeto “Contenedor” (no una OU; compare la diferencia en los iconos de “Usuarios y equipos de Active Directory” con “Usuarios” frente a “Controladores de dominio”) y no puede se le aplica una directiva de grupo, ni se pueden crear unidades organizativas debajo de ella. Lo mismo vale true para el contenedor “CN = Computadoras”. En términos prácticos, nadie que use la Política de grupo usa estos contenedores para otra cosa que no sean las cuentas de usuario y los grupos predeterminados colocados en “CN = Usuarios” (que, en general, ¡no debería mover!).
No puede crear la estructura de OU que está buscando debajo de “CN = Users” porque no puede crear OU allí. La convención típica es crear una unidad organizativa a nivel de dominio y colocar todas sus unidades organizativas, usuarios, equipos, grupos, etc., bajo esa unidad organizativa.
Parece que ha tenido un comienzo sólido, pero pasaría algún tiempo jugando con esto en un laboratorio y pensando en escenarios de administración comunes. Dedique un poco de dinero y tiempo a leer sobre AD en general y la Política de grupo, en particular, y creo que tendrá un tiempo razonable.
Si te gusta este mundo, tienes la habilidad dejar un ensayo acerca de qué le añadirías a esta sección.