jump to navigation

Diseño eficaz de unidades organizativas noviembre 1, 2008

Posted by admin in WServer 2008.
trackback

Que tal amigos, navegando en internet e investigando mas sobre el tema que me permitira tener una correcta estructura en mi diseño de las unidades organizativas en mi AD, encontre este artículo sumamente interesante en http://technet.microsoft.com, lo comparto con ustedes. Espero que les sea útil.

No subestime la importancia, y la complejidad, del diseño de una buena estructura de unidad organizativa (OU). Mi experiencia me dice que los departamentos de TI, con frecuencia, adoptan una u otra dirección: bien

ponen demasiado énfasis en la estructura de la unidad organizativa, o bien se olvidan de la misma. Cualquiera que sea la dirección adoptada, ambas pueden provocar problemas con el modelo de Active Directory®.

Poner demasiado énfasis en la estructura de la unidad organizativa resta importancia a otras áreas de diseño de Active Directory, como la planeación de la topología del sitio o la consideración del tamaño del controlador de dominio. Por otro lado, al reducir la prioridad de planeación de la unidad organizativa, la directiva de grupo y la delegación se ven afectadas.

Una de las excusas que he oído en alguna ocasión es que la estructura de la unidad organizativa es flexible y puede cambiarse posteriormente si no es la adecuada. Es verdad que la estructura de la unidad organizativa es flexible. No obstante, los administradores descubren, con frecuencia, que ese cambio posterior de estructura de la unidad organizativa es más complicado de lo que habían pensado en un principio. Es también verdad que se pueden agregar nuevas unidades organizativas, pero las anteriores no son fáciles de eliminar.

Una estructura de unidad organizativa mal planeada tiende a cobrar vida propia. Si se crea un objeto nuevo en el directorio y el administrador no sabe en qué lugar de la unidad organizativa colocar el objeto, creará una nueva unidad organizativa, o bien colocará el objeto en un lugar al que no pertenezca. Ambos escenarios presentan sus propios peligros inherentes. La creación de una nueva unidad organizativa es sencilla, pero realizar un seguimiento de la misma es bastante complicado a la larga. La creación desorganizada de una unidad organizativa contribuye a una estructura de unidad organizativa caótica y es fácil permitir la acumulación de valores no documentados en el directorio. Por otro lado, si agrega un objeto a una unidad organizativa existente a la que no pertenezca realmente, el objeto nuevo puede recibir directivas que no debería recibir o los permisos del objeto podrían delegarse en usuarios imprevistos.

Al diseñar estructuras de unidad organizativa, debe tener en mente una ecuación básica: sencillez + adaptabilidad = sostenibilidad. Si el diseño es demasiado sencillo, puede que no sea adaptable y, por lo tanto, tendrá que cambiarse con demasiada frecuencia. Si el diseño es demasiado adaptable, todo quedará dividido en secciones, lo cual aportará demasiada complejidad.

Hay tres principios clave referidos a la directiva de grupo, la delegación y la administración de objetos que pueden ayudarle a adoptar una correcta decisión de diseño. Estos principios pueden resumirse en tres preguntas que debe realizarse a sí mismo y que le ayudarán a garantizar que la estructura de la unidad organizativa que está creando superará el paso del tiempo y los cambios de la organización:

¿Es necesaria la creación de esta unidad organizativa de manera que se pueda aplicar a la misma un objeto de directiva de grupo (GPO, Group Policy Object) exclusivo?

¿Es necesario que un grupo particular de administradores tenga permisos para los objetos de esta unidad organizativa?

¿Facilitará esta nueva unidad organizativa la administración de los objetos existentes dentro de la misma?

Si la respuesta a cualquiera de estas preguntas es “sí”, con toda probabilidad debería crear la unidad organizativa. Si la respuesta a estas tres preguntas es “no”, debe volver a plantearse el diseño y determinar si un diseño distinto podría generar una opción más apropiada. Pero antes de entrar en detalles y mostrarle cómo aplicar estos principios, debo explicar en primer lugar por qué estos principios son importantes.

Principio 1: directiva de grupo

El primer principio de diseño de unidades organizativas consiste en tener en cuenta los objetos de directiva de grupo que se aplicarán a una unidad organizativa. Un GPO le permite configurar opciones para los usuarios y equipos de una manera aplicable. Puede definir varios GPO en Active Directory y aplicarlos a un dominio completo, a varias unidades organizativas o, incluso, a los sitios del dominio. Los GPO se dividen en dos categorías: uno para los usuarios y otro para los equipos.

Tanto las directivas de equipo como las de usuario pueden definirse en el mismo GPO. La sección Configuración de usuario del GPO define, en su mayor parte, la experiencia que tendrá el usuario una vez haya iniciado sesión. Estos tipos de configuración existen también en la sección Configuración del equipo, pero esta sección contiene, asimismo, más configuraciones relacionadas con la seguridad del equipo, por ejemplo, quién puede iniciar sesión en él de forma local o cómo se cifran los datos.

Estos son algunos de los aspectos básicos que hay que tener en cuenta a la hora de definir unidades organizativas para que sean compatibles con los GPO. En primer lugar, sólo porque las directivas de usuario y de equipo puedan definirse en el mismo GPO, no significa que sea buena idea colocar los objetos de usuario y equipo en la misma unidad organizativa. Combinar ambos objetos en el mismo GPO dificulta la solución de problemas en la aplicación de GPO. Esto se hace muy evidente si tiene habilitada una directiva de bucle invertido.

En segundo lugar, muchas personas olvidan que puede aplicar los GPO a nivel de sitio y, por lo tanto, diseñar sus estructuras de unidad organizativa para modelar la estructura del sitio según los objetivos de la aplicación de GPO. Éste es un modelo común de diseño de unidad organizativa, conocido como modelo geográfico. En un instante hablaré sobre el mismo. Sería negligente por mi parte no reconocer que el modelo geográfico tiene su lugar en el diseño de unidades organizativas, pero como verá más adelante, no creo que esa aplicación de GPO deba ser la razón principal para implementar este modelo.

Además, al pensar en la estructura de unidad organizativa en términos de GPO, el objetivo debe ser eliminar la complejidad. Asegúrese de que la unidad organizativa se agrega al flujo de herencia de GPO. Si su unidad organizativa contiene servidores que requieran la misma directiva que otros servidores, considere la colocación de estos objetos de equipo bajo una unidad organizativa Servidores más amplia, así como la creación de varias unidades organizativas para diferentes tipos de servidor bajo la unidad organizativa Servidores (consulte la Figura 1). Esto puede simplificar la aplicación de directivas, puesto que cada objeto de equipo en las unidades organizativas inferiores obtendrá la directiva de la unidad organizativa Servidores así como cualquier otra directiva que sea específica para ese tipo específico de servidor.

Mantenimiento de dos unidades organizativas paralelas independientes 

La segunda opción consiste en crear una unidad organizativa anidada y en configurar una denegación explícita de permiso en la unidad organizativa que contenga usuarios especiales. Cualquier experto en delegación le dirá que denegar de forma explícita no es lo más adecuado, pero en este caso, necesita seleccionar, de los dos males, el mejor (consulte la Figura 3). Puede, por una parte, duplicar o mantener la configuración en dos unidades organizativas independientes o bien puede configurar una denegación explícita en una de las unidades organizativas. El hecho de denegar de forma explícita es, a largo plazo, la mejor decisión.

El modelo superficial cuenta con unas pocas unidades organizativas de alto nivel que contienen la mayoría de los objetos

Si el encargado de recursos humanos es también el encargado de las nóminas, no tiene entonces sentido crear dos unidades organizativas independientes para ambos departamentos. En el modelo superficial, todos los objetos de usuario pueden agruparse en una unidad organizativa de gran tamaño para Cuentas o pueden mantenerse en el contenedor predeterminado Usuarios. Como mínimo, sus objetos de usuario deben separarse de sus objetos de equipo.

Para este modelo, recomiendo también que vaya un paso más allá y separe sus estaciones de trabajo de los servidores. A continuación, puede aplicar directivas de grupo diferentes sin tener que definir un GPO que use una consulta del Instrumental de administración de Windows® (WMI, Windows Management Instrumentation) para filtrar estaciones de trabajo o servidores.

Una de las ventajas de mantener la amplitud de su estructura de unidad organizativa, y no la profundidad, es que las búsquedas de Active Directory se ejecutarán más rápido. Normalmente recomiendo no sobrepasar las 10 subunidades organizativas. El control sobre los objetos no es muy preciso en este modelo, pero si va a administrar objetos en una pequeña empresa no necesitará ese control tan preciso. Además, este modelo sería difícil de usar correctamente en una empresa de gran tamaño, pero funciona muy bien en pequeñas empresas.

El modelo geográfico

En el modelo geográfico, debe crear unidades organizativas independientes para las distintas regiones geográficas. Este modelo es mucho mejor para las empresas que cuentan con departamentos de TI descentralizados pero que no desean incurrir en costos asociados con la administración de varios dominios.

El modelo basado en tipos agrupa los objetos según sus funciones 

En la mayoría de los casos, debe distinguir entre distintas clasificaciones de objetos de usuario para las directivas. Sus directivas se diferenciarán en su mayoría según el tipo de cuenta de usuario. Por ejemplo, el permitir a las personas iniciar sesión en un equipo con una cuenta de servicio es generalmente una práctica de negocio incorrecta. Las contraseñas de la cuenta de servicio se comparten, generalmente, entre muchos usuarios, por lo que si alguien inicia sesión con una cuenta de servicio, su identidad permanece anónima. En el caso de que ocurriera algo, tendría problemas para realizar un seguimiento del usuario que había iniciado sesión cuando se produjo el evento. En este ejemplo, debería establecer una directiva en las cuentas de servicio que evitara el inicio de sesión interactivo. Esto se adapta muy bien al modelo jerárquico mostrado en la Figura 3.

Podría usar la herencia de GPO para obtener ventajas en este caso. Por ejemplo, podría tener una directiva Todos los usuarios referida a directivas implementadas para todos los objetos de usuario. Además, podría tener una directiva distinta e independiente para las cuentas de servicio, que dependa de la directiva Todos los usuarios. Este enfoque garantiza que sus cuentas de servicio tienen el mismo conjunto base de directivas que cualquier otra cuenta, así como las restricciones de inicio de sesión específicas.

Este enfoque es adecuado también para la delegación, en la que usa la herencia de permisos en lugar de la herencia de GPO. Suponga que sus administradores del nivel 2 tienen la capacidad de restablecer las contraseñas para todas las cuentas excepto para las cuentas de los administradores del nivel 3. Con una estructura de unidad organizativa plana, tendría que delegar los permisos a cada unidad organizativa que contenga cuentas de usuario. Sin embargo, en un modelo basado en tipos con una estructura jerárquica, puede dar al grupo del nivel 2 permisos para “restablecer la contraseña” en la unidad organizativa Cuentas y, a continuación, en la unidad organizativa del nivel 3, podría simplemente no heredar los permisos o incluso configurar una denegación explícita para evitar que el nivel 2 restablezca la contraseña.

Esto funciona también correctamente para los objetos de equipo. Los servidores y las estaciones de trabajo pueden separarse permitiendo la aplicación de distintas directivas a los mismos. Entonces, los servidores pueden subdividirse en funciones (consulte la Figura 1). En este diseño, es posible configurar una directiva de alto nivel en la unidad organizativa Servidores que afecte a todos los servidores y también configurar directivas individuales en cada unidad organizativa de nivel inferior.

Por ejemplo, digamos que tiene una cuenta de servicio de Microsoft Operations Manager (MOM). Con este modelo por niveles, puede crear un GPO de MOM y aplicarlo a la unidad organizativa Servidores de MOM. Y, a continuación, dentro de ese GPO, puede otorgar derechos a la cuenta de servicio de MOM para iniciar sesión como un servicio. Esto sólo se aplicaría a los servidores MOM de esa unidad organizativa. Los servidores MOM obtendrán, no obstante, el GPO de Servidores de la unidad organizativa Servidores de nivel superior, pero también obtendrán el GPO de MOM especializado, que está vinculado en la unidad organizativa de MOM.

Documentación del diseño

Puede ser muy gratificante diseñar una estructura de unidad organizativa que resista los numerosos cambios que se producen en un entorno de Active Directory. Pero necesita algún método para realizar el seguimiento de las características dinámicas de las unidades organizativas. Si no dispone de ningún método, podría perder rápidamente el control de su entorno. Cuando sea necesario un cambio y deba agregarse o eliminarse una unidad organizativa, debe saber exactamente qué hacer para garantizar que su modelo seguirá ciñéndose a su modelo de diseño, adhiriéndose a los tres principios fundamentales. Por esta razón debe contar con un diseño bien documentado.

Microsoft ofrece guías de documentación en el Kit de recursos de Windows Server. Estas guías son estupendas si su estructura es un marco sólido que no va a cambiar mucho en el futuro. Pero la mayoría de las organizaciones cuentan con una estructura muy dinámica que cambia con frecuencia. Así pues, les presento algunas sugerencias importantes para garantizar que su estructura de unidad organizativa esté bien documentada y pueda ser compatible con un entorno dinámico.

Asegúrese de que toda la información es relevante Creo firmemente en la documentación que persigue un objetivo. Demasiados documentos operativos cuentan con tanta información superflua que es difícil encontrar lo que realmente se busca. No se quede estancado en el proceso de documentación porque sí. ¿Necesita realmente incluir el número de objetos en cada unidad organizativa o cada Entrada de control de acceso (ACE, Access Control Entry) en la lista de control de acceso de la unidad organizativa? Para la documentación de la unidad organizativa, la información siguiente será generalmente suficiente:

·         Nombre de la unidad organizativa

·         Descripción breve

·         Quién la creó, o con quién hay que ponerse en contacto para obtener más información o cambios

·         Cuándo se creó

No dificulte las actualizaciones Si, desafortunadamente, tiene que actualizar algún documento complejo de Microsoft Word, es más que probable que postergue la implementación de actualizaciones. No es un problema que se desvincule de implementar pequeños cambios si sabe que pronto contará con una gran cantidad de actualizaciones que llevar a cabo a la vez. Desafortunadamente, las personas a menudo se olvidan de estos pequeños cambios o simplemente siguen postergándolos, por lo que el trabajo nunca se termina. Por lo tanto, la actualización del documento debe ser muy sencilla para no desalentarse. En la mayoría de los casos, una sencilla hoja de cálculo de Microsoft Excel® con unas pocas columnas funcionará bien.

Realice comentarios sobre el propio objeto Los objetos de la unidad organizativa tienen un atributo de descripción donde puede escribir sus comentarios. En lugar de escribir los comentarios en el documento de diseño, considere l escribirlos en el atributo de descripción, de manera que otros usuarios puedan deducir directamente para qué sirve la unidad organizativa. Si necesita incluir más detalles, escriba una breve descripción en el atributo de descripción e incluya más detalles en el documento de la unidad organizativa.

Automatice la documentación Un script se puede escribir para volcar los contenidos de la estructura de la unidad organizativa en un archivo de texto, una hoja de cálculo de Excel o incluso un archivo HTML. Este script puede ejecutarse cada noche en una tarea programada. Esto puede ser muy útil si incluye comentarios en el campo de descripción de la unidad organizativa. A continuación, es sólo cuestión de volcar el atributo de descripción al archivo y obtendrá automáticamente una estructura de unidad organizativa completamente documentada que estará siempre actualizada. Si crea un archivo nuevo cada vez que se ejecuta el script, en vez de sobrescribir el documento existente, puede mantener un historial de los cambios a los que se ha sometido la unidad organizativa a lo largo del tiempo.

Desafortunadamente, la mayoría de los administradores no entienden la importancia de una buena documentación de estructura de unidad organizativa hasta que realmente la necesitan. Y para entonces, a las 3 de la mañana, es casi imposible resolver lo que otras unidades organizativas eliminaron por accidente sin llevar a cabo una restauración.

No espere hasta que le ocurra esto. Le recomiendo encarecidamente que sea previsor en este área y que comience de inmediato un documento de unidad organizativa y designe una persona responsable de actualizarlo. Por último, si sigue la regla de facilitar la actualización de la documentación, la tarea no supondrá ninguna complicación.

 

 

A %d blogueros les gusta esto: