No subestime la importancia, y la complejidad, del diseño de una buena estructura de unidad organizativa (OU).
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 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.
Figura 1 Creación de varias unidades organizativas para distintos tipos de servidor (Hacer clic en la imagen para ampliarla)
Otro aspecto básico consiste en asegurarse de que no se crean o vinculan de forma innecesaria varios GPO. Con un GPO, puede crear una directiva y aplicarla a varias unidades organizativas. En ocasiones esto es útil, pero también puede causar daños. Si tiene que cambiar una configuración de GPO y dispone de un sistema extremadamente complejo de GPO vinculados, podría aplicar por accidente un cambio a los objetos equivocados. Cuantos más vínculos cree, más complicado será definir el ámbito de una directiva. Igualmente, debe evitar la creación de directivas adicionales con la misma configuración que otras directivas. Si tiene que hacer esto con frecuencia, considere la modificación de su estructura de unidad organizativa para aplicar un nuevo modelo de herencia de GPO.
Y, por último, debe crear casi siempre una nueva unidad organizativa para los objetos de usuario y los de equipo. De forma predeterminada, los objetos de usuario y de equipo se colocan en contenedores, lo cual no le permite vincular los GPO directamente a los mismos. Los GPO se pueden aplicar a los contenedores para usuarios y equipos desde el dominio, pero a menos que bloquee la herencia en otro sitio, estas directivas se aplicarán a cada usuario y equipo del dominio. En Windows Server® 2003, puede usar las herramientas rediruser.exe y redircomp.exe para cambiar la ubicación predeterminada de los objetos de usuario y de los objetos de equipo a la unidad organizativa que creó para los mismos.
Principio 2: delegación
Es importante que cree la estructura de la unidad organizativa de una manera que sea coherente con la forma de delegar permisos en el dominio. Tenga presente que al delegar permisos en Active Directory, los cambios de permiso se llevan a cabo sólo en el objeto. Así pues, si ofreciera a un usuario control total sobre un objeto de equipo particular, esa persona podría modificar los atributos del objeto, pero carecería de privilegios de administrador en el propio equipo.
Estos son algunos de los procedimientos recomendados referentes a la delegación a la hora de diseñar una estructura de unidad organizativa:
Diseño con herencia de permisos Por ejemplo, digamos que desea que los administradores del nivel 1 puedan cambiar la contraseña de la mayoría de las cuentas. Los administradores no deben tener la capacidad de restablecer las contraseñas de un grupo especial de usuarios, sin embargo, los primeros deben tener la capacidad de cambiar los nombres para mostrar de dichas cuentas.
Aquí cuenta con dos opciones. La primera, podría crear dos unidades organizativas paralelas independientes y separar los usuarios especiales de los usuarios normales. Esto significa, sin embargo, que si desea cambiar las opciones de delegación de todos los usuarios, tiene que cambiar estos permisos en dos sitios independientes. Por otra parte, esto contradice la práctica de no vincular innecesariamente varias directivas (consulte la Figura 2)
Figura 2
Mantenimiento de dos unidades organizativas paralelas independientes (Hacer clic en la imagen para ampliarla)
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.
Figura 3
Uso de la denegación explícita (Hacer clic en la imagen para ampliarla)
Preste atención a AdminSDHolder.
Este ejemplo funciona bastante bien a menos que los usuarios especiales pertenezcan todos a uno de los grupos de administradores (Administradores de dominio, Administradores de esquema, Administradores de empresa o Administradores) puesto que los permisos para las cuentas en estos grupos se administran de manera distinta. Básicamente lo que no desea es proporcionar a alguien de forma accidental permisos a una cuenta de administrador.
Si crea una unidad organizativa independiente para administradores, observará que los permisos que les delega siguen desapareciendo. Esto se debe a AdminSDHolder, que es un contenedor especial que aplica su lista de control de acceso a cada cuenta de administrador en un intervalo especificado. Como consecuencia, cualquier cambio de delegación que realice en una cuenta de administrador no será válido si los cambios no se aplican también al contenedor AdminSDHolder. Por lo tanto, no debería separar las cuentas de administrador de otras cuentas con el objeto de llevar a cabo una delegación. Es preferible, no obstante, separar las cuentas de administrador a efectos de la directiva de grupo. Esto es especialmente cierto en Windows Server 2008, donde puede tener varias directivas de contraseña.
Principio 3: administración de objetos
La unidad organizativa debe facilitar la administración de los objetos. Agrupar los objetos en la misma unidad organizativa puede, a menudo, facilitar la realización de cambios globales. El complemento Usuarios y equipos de Active Directory le permite editar ciertos atributos en una selección de varios objetos. Así pues, si tiene que cambiar un atributo con regularidad en un grupo de objetos, es más fácil hacerlo si todos se encuentran en la misma unidad organizativa.
Esto es también especialmente útil si va a llevar a cabo actualizaciones con un script. Los lenguajes de scripting facilitan en gran medida la enumeración de todos los objetos de una unidad organizativa y la administración de los mismos de uno en uno. La otra opción consiste en buscar y modificar cada objeto individualmente. Simplemente el hecho de colocar los objetos en la misma unidad organizativa para la administración puede, en ocasiones, ahorrarle horas de trabajo innecesario cada semana.
Otra manera de ayudar en la administración de objetos consiste en separar los objetos en diferentes unidades organizativas según su tipo. La creación de una unidad organizativa independiente para objetos de impresora o recursos compartidos publicados garantiza que esos objetos no tengan que ser eliminados cuando lleve a cabo la administración en otros objetos de la unidad organizativa. Esta práctica es equivalente a la de no agrupar cuentas de usuario y de equipo en la misma unidad organizativa.
ELECCIÓN DE UN MODELO
Ahora que he tratado los principios del diseño de las unidades organizativas, puedo centrarme en algunos modelos de diseño comunes. Tenga en cuenta que hay muchos más modelos de los que puedo tratar aquí y que no está limitado a trabajar con las restricciones de un solo modelo. Puede tomar fragmentos de cada uno y crear su propio modelo híbrido dirigido a sus necesidades particulares.
Prácticamente cualquier modelo puede ser satisfactorio a pequeña escala, pero cuando la empresa crece, su capacidad para mantener la administración del entorno decrece. Por tanto, asegúrese de que, en primer lugar, prueba su modelo en un entorno de laboratorio adecuado. Y recuerde que aunque las estructuras de las unidades organizativas pueden, en un principio, cambiarse fácilmente, son más difíciles de cambiar cuanto más tiempo lleven funcionando.
El modelo superficial
El modelo superficial toma su nombre del hecho de que se mantiene prácticamente plano. En este modelo, unas pocas unidades organizativas de alto nivel contienen la mayoría de los objetos (consulte la Figura 4). Este modelo se ejercita en su mayor parte en empresas más pequeñas en las que hay una pequeña tienda de TI, no hay muchas divisiones diferentes ni los empleados tienden a ejercer funciones distintas. Recomiendo, normalmente, no subir por encima de las 10 subunidades organizativas, aunque Microsoft sugiere un límite de 15 subunidades organizativas antes de que se materialicen problemas de rendimiento.
Figura 4
El modelo superficial cuenta con unas pocas unidades organizativas de alto nivel que contienen la mayoría de los objetos (Hacer clic en la imagen para ampliarla)
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 (consulte la Figura 5).
Figura 5
El modelo geográfico separa las unidades organizativas por región geográfica (Hacer clic en la imagen para ampliarla)
Pongamos como ejemplo que tiene oficinas en Atlanta, Baltimore y Seattle. En el caso de que cada sitio administre sus propios usuarios y equipos, podría tratarse de una buena opción en términos de delegación. Pero, ¿qué ocurre si un usuario de Seattle vuela a Baltimore para realizar un curso y bloquea su cuenta? Los encargados de TI en Baltimore no podrán ayudar a este usuario si no se les han delegado permisos para obtener acceso a la cuenta del usuario. Si son las 8 de la mañana en Baltimore, son las 5 de la mañana en Seattle, lo que significa que el usuario puede tener que esperar horas antes de poder ponerse en contacto con alguien de la oficina de Seattle para obtener ayuda.
Algunas compañías globales usan un modelo denominado "Follow the sun" ("Siga el sol"), en el cual las llamadas al departamento de soporte técnico se enrutan a un sitio ubicado en una zona horaria en la que aún sea horario de oficina. Esto significa que la compañía no tiene por qué tener abierto el departamento de soporte técnico las 24 horas en cada una de las sucursales. Aún así puede proporcionar ayuda a los empleados, por ejemplo, desbloquear sus cuentas, en cualquier momento del día o de la noche.
Si éste es su modelo, la creación de unidades organizativas independientes basadas en la ubicación geográfica no es probablemente la mejor opción para sus necesidades operativas. Tendría que delegar los permisos independientes a cada departamento de soporte técnico regional para cada unidad organizativa de usuarios. Sin embargo, si sus ubicaciones cuentan con sus propios departamentos de TI, el modelo geográfico puede constituir un buen modelo para su organización.
El modelo geográfico es también difícil de eliminar en un solo dominio debido a su naturaleza de funcionamiento. Un dominio tiende a tener un modelo de seguridad diferente de otros dominios. Esto es más evidente si observa una aplicación a nivel de empresa, como Microsoft® Exchange.
El servidor Exchange Server de Atlanta puede tener distintas directivas de mensajes definidas, pero todos los Exchange Server de la empresa tienen, probablemente, los mismos GPO aplicados. Si éste fuera el caso, al poner Exchange Server en unidades organizativas independientes basadas en regiones provocaría el tener que vincular de manera innecesaria el mismo GPO a varias unidades organizativas. En términos de delegación, tiene que preguntar si los administradores de Exchange necesitan realmente permisos únicos a los objetos de equipo para los servidores Exchange Server. En la mayoría de los casos, la división de los objetos de equipo en unidades organizativas geográficas se lleva a cabo por la directiva de grupo, no por la delegación.
El modelo basado en tipos
El modelo basado en tipos clasifica los objetos según sus funciones (consulte la Figura 6). Al crear su último objeto de usuario, ¿lo hizo para una cuenta de usuario normal, una cuenta administrativa o una cuenta de servicio? En un modelo basado en tipos, cada uno de estos objetos se trata de manera diferente.
Figura 6
El modelo basado en tipos agrupa los objetos según sus funciones (Hacer clic en la imagen para ampliarla)
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.
FUENTE: http://technet.microsoft.com
Ahora si abrimos la carpeta perfiles y le damos al usuario Menganito vemos que nos abre todo su árbol de carpetas de perfil Móvil, pero el propio usuario no tendrá permiso para entrar en la carpeta como consecuencia de haber tomado posesión sobre ella los administradores (Dominio\Administradores). Tendremos que darle ahora permisos al propio usuario.
Ahora pulsamos Agregar y le damos posesión también al propio Usuario y al SYSTEM, con control total sobre la carpeta, y solo queda pulsar Aceptar ......
.gif)
.gif)
.gif)
.gif)
.gif)
.gif)
