Diseño de OU de Active Directory para <500 usuarios, 4 ubicaciones

Estamos buscando agregar alguna estructura lógica a nuestra jerarquía AD (Win 2003). Tenemos un solo dominio y alrededor de 500 usuarios. Todos los usuarios y computadoras están actualmente organizados en una unidad organizativa. Todos los grupos de seguridad y distribución están en una segunda unidad organizativa. La pertenencia a grupos se basa esencialmente en usuarios individuales sin anidamiento de grupos.

Mis preguntas:

1. Para una organización de este tamaño, ¿vale la pena diseñar una jerarquía de unidades organizativas basadas en el departamento, la geografía y / o la clase de objeto (es decir, computadoras, usuarios, grupos) y trasladar a los usuarios, computadoras y grupos a las unidades organizativas relevantes?
2. Si es así, ¿cómo estructuraría la jerarquía, por ejemplo, departamento-> ubicación-> clase de objeto?
3. ¿Deberíamos anidar grupos, cuando corresponda, para una mejor asignación de roles de aplicaciones empresariales y entradas de direcciones de Exchange?

Estos son los principios básicos de la recomendación de Microsoft para el diseño lógico de AD:

• Diseñe primero para la delegación de control, porque se basa en permisos de AD y es el eje más inflexible para modificar. Si no está delegando el control, no se preocupe por esto (pero lo planearía de todos modos, incluso en una organización tan pequeña que pueda necesitar para usuarios designados en sucursales para poder restablecer contraseñas, etc)

• Diseño segundo para la aplicación de la política de grupo. El filtrado de la aplicación de la política de grupo por pertenencia al grupo de seguridad permite que un GPO se aplique solo a un subconjunto de objetos de usuario u ordenador debajo del punto en el que está vinculado en el directorio, por lo que este eje tiene más flexibilidad que los permisos de AD.

• Diseñe por último para la organización y facilidad de uso. Facilite encontrar cosas para usted y otros administradores.

Piense en cada una de estas consideraciones a medida que diseña, priorizándolas según lo recomendado. Es fácil cambiar las cosas más tarde (comparativamente), y nunca "lo hará bien" en el primer intento. Antes incluso de utilizar DCPROMO, mi primer controlador de dominio, normalmente dibujo la estructura propuesta en papel o en una pizarra y analizo posibles escenarios de uso para ver si mi diseño "se mantiene". Es una excelente manera de eliminar los problemas en un diseño.

(Tampoco se olvide de la aplicación de directiva de grupo en los objetos del sitio. Debe tener cuidado con la aplicación de GPO entre dominios cuando vincule los GPO en los sitios, pero si es un entorno de dominio único, puede obtener muchas funcionalidad al vincular los GPO a los sitios. Trabaje en algunos escenarios de muestra con él: encuentro que es excelente para cargar software que tiene configuraciones "específicas del sitio" o para proporcionar scripts de inicio de sesión específicos a los usuarios cuando inician sesión en ciertas computadoras ubicaciones físicas, mediante el procesamiento de la política de grupo de bucle invertido).

Siempre había dividido a los usuarios, las computadoras y los grupos en unidades organizativas separadas, por la sencilla razón de que facilita la administración.

Si no tiene una razón convincente para una estructura AD específica, diseñe su AD desde un punto de vista administrativo. Piense dónde va a aplicar las políticas.

Si está aplicando la mayoría de sus políticas a nivel de departamento, use Departamento \ Ubicación \ Objeto

Si está aplicando la mayoría de sus políticas a nivel de ubicación, use Ubicación \ Departamento \ Objeto

Si lo hiciera de la otra manera, significaría que tendría que vincular sus políticas en varias unidades organizativas, lo que implica un trabajo innecesario.

Los grupos de anidamiento están perfectamente bien y, de nuevo, hacen que la administración de AD sea mucho más fácil.

Tiendo a diseñar estructuras de AD teniendo en cuenta 'facilitar la administración', en lugar de reflejar la estructura física de la empresa, sin embargo, ambas son a menudo iguales.

Creo que si tuviera que rediseñar mi AD nuevamente, hay algunas cosas que haría de manera diferente, pero he descubierto que:

Usuarios: divida las tesis en departamentos, pero también con un área / s para el personal temporal o de la agencia. La ubicación de estos no será tan importante como sin duda la gente se moverá.

Computadoras: divídalas en ubicaciones y sub ubicaciones. Es decir, OfficeComputers / LondonOffice / Room103 (Finanzas). Esto significa que puede aplicar la configuración a una ubicación u oficina, por ejemplo, a un servidor proxy diferente o a una configuración antivirus diferente (por supuesto, solo si el programa de administración de AV usa AD), sin reorganizar, y con suerte no tendrá que abrir el lata de gusanos que es el procesamiento de bucle invertido.

También me ha parecido útil no utilizar los usuarios integrados o grupos de computadoras, no ningún problema técnico, sino solo para que pueda ver fácilmente dónde no deberían estar las cosas.

Finalmente, divida sus servidores también, he elegido una ubicación / función que parece haber funcionado bastante bien.

Como ya se respondió, aquí está mi opinión para un pequeño ejemplo, tenga en cuenta que no hay nada correcto o incorrecto, todo depende de las necesidades, es decir, ¿organización o ubicación primero? Prefiero el rol organizacional primero incluso para los roles de computadora / servidor También me gusta la capacidad de señalar una única unidad organizativa para obtener todos los empleados y no basura para llenar las listas de empleados de la intranet. ¡Siéntase libre de editar!

• Personas (usuarios / tipo = persona)
  • Interno
    • Departamento A
      • Ubicación X
      • Ubicación Y
    • Departamento B
    • Departamento C
  • Externo
    • Empresa 1
    • Empresa 2
• Máquina (usuarios / tipo = cualquier computadora incluida)
  • Cliente
    • Laptops
    • Escritorios
  • Servidor
    • Solicitud
      • Ubicación T
      • Ubicación V
    • Infraestructura
    • Base de datos
  • Servicio
  • Cuentas administrativas (si se usan)
• Listas (grupos y contactos)
  • Contacto
  • Distribución
  • Seguridad

Simplemente los dividiría por ubicación en este caso. La estructura OU resultante se vería así:

Location1
-Computers
-Groups
-Users

Location2
-Computers
-Groups
-Users

etc.

Realmente no veo ninguna necesidad de más divisiones aquí, por ejemplo, por departamento, ya que generaría una sobrecarga administrativa adicional sin realmente dar mucho a cambio. Sin embargo, dividir por ubicación le permitiría implementar la delegación en cada sitio.

Una línea guía que uso es: Usuarios; organizar de acuerdo con los grupos de diagrama de recursos humanos; organizar de acuerdo con el flujo de trabajo Computadoras; organizar de acuerdo a la ubicación geográfica

Sin embargo, las otras respuestas en este hilo también son muy buenas.