Diseño de una estructura lógica para AD DS en Windows Server 2008

Diseño de una estructura lógica para AD DS en Windows Server 2008Actualizado: abril de 2008

Se aplica a: Windows Server 2008, Windows Server 2008 R2

Los Servicios de dominio de Active Directory® (AD DS) del sistema operativo de Windows Server® 2008 permiten a las organizaciones crear una infraestructura segura, escalable y administrable para la administración de recursos y usuarios, y admiten también aplicaciones habilitadas para directorio.

Una estructura lógica de Active Directory bien diseñada presenta las siguientes ventajas:

Administración simplificada de redes basadas en Microsoft® Windows® que contienen un gran

número de objetos

Una estructura de dominio consolidada y costos de administración reducidos

La capacidad de delegar el control administrativo sobre los recursos, según corresponda

Una repercusión reducida sobre el ancho de banda de la red

El uso compartido simplificado de los recursos

Óptimo rendimiento de búsqueda

Un bajo costo total de propiedad

Una estructura lógica de Active Directory bien diseñada facilita la integración eficaz en el sistema de características tales como directiva de grupo, bloqueo de escritorio, distribución de software y administración de usuarios, grupos, estaciones de trabajo y servidores. Además, una estructura lógica diseñada cuidadosamente facilta la integración de servicios y aplicaciones de Microsoft y que no son de Microsoft, como Microsoft Exchange Server, infraestructura de clave pública (PKI) y un sistema de archivos distribuido (DFS) basado en dominio.

Cuando se diseña una estructura lógica de Active Directory antes de implementar AD DS, es posible optimizar el proceso de implementación para aprovechar mejor las ventajas que ofrecen las características de Active Directory de Windows Server 2008. Para diseñar la estructura lógica de Active Directory, el equipo de diseño identifica en primer lugar los requisitos de la organización y, basándose en esa información, decide dónde colocar los límites del dominio y el bosque. A continuación, el equipo de diseño decide cómo configurar el entorno del Sistema de nombres de dominio (DNS) para satisfacer las necesidades del bosque. Por último, el equipo de diseño identifica la estructura de la unidad organizativa (OU) necesaria para delegar la administración de los recursos de la organización.

En esta guía

Descripción del modelo lógico de Active Directory

Identificación de los participantes en el proyecto de implementación

Creación del diseño de un bosque

Creación del diseño de un dominio

Creación del diseño de una infraestructura DNS

Creación del diseño de una unidad organizativa

Búsqueda de recursos adicionales para el diseño de la estructura lógica de Active Directory de

Windows Server 2008

Apéndice A: Inventario de DNS

Descripción del modelo lógico de Active DirectoryActualizado: abril de 2008


Diseñar la estructura lógica de los Servicios de dominio de Active Directory (AD DS) implica definir las relaciones entre los contenedores del directorio. Estas relaciones pueden basarse en requisitos administrativos, como la delegación de autoridad, o pueden venir definidas por requisitos operativos, como la necesidad de controlar la replicación.

Antes de diseñar la estructura lógica de Active Directory, es importante entender el modelo lógico de Active Directory. AD DS es una base de datos distribuida que almacena y administra información acerca de los recursos de red así como datos específicos de las aplicaciones con directorio habilitado. AD DS permite a los administradores organizar los elementos de una red (por ejemplo, los usuarios, los equipos y los dispositivos) en una estructura de contención jerárquica. El contenedor de nivel superior es el bosque. Dentro de los bosques están los dominios y dentro de los dominios, las unidades organizativas (OU). Se trata de un modelo lógico porque es independiente de los aspectos físicos de la implementación, como el número de controladores de dominio necesarios en cada dominio y topología de red.

Bosque de Active Directory

Un bosque es un conjunto de uno o varios dominios de Active Directory que comparten una estructura lógica, un esquema del directorio (definiciones de clase y atributo), una configuración de directorio (información de replicación y del sitio) y un catálogo global (capacidades de búsqueda en todo el bosque) comunes. Los dominios del mismo bosque se vinculan automáticamente con relaciones de confianza transitivas bidireccionales.

Dominio de Active Directory

Un dominio es una partición dentro de un bosque de Active Directory. La partición de datos permite a las organizaciones replicar los datos únicamente donde es necesario. De esta manera, el directorio se puede adaptar globalmente en una red que dispone de un ancho de banda limitado. Además, el dominio es compatible con otras funciones clave relacionadas con la administración, entre las que se incluyen:

Identidad de usuario en toda la red. El dominio permite crear identidades de usuario y hacer

referencia a ellas en cualquier equipo unido al bosque en el que se encuentra el dominio. Los

controladores de dominio que forman parte del mismo se usan para almacenar cuentas y

credenciales de usuario (como contraseñas o certificados) de forma segura.

Autenticación. Los controladores de dominio proporcionan servicios de autenticación a los usuarios y

datos de autorización adicionales, como pertenencia a grupos de usuarios, que se pueden usar para

controlar el acceso a los recursos de la red.

Relaciones de confianza. Los dominios pueden ampliar los servicios de autenticación a los usuarios

de dominios situados fuera de su propio bosque mediante relaciones de confianza.

Replicación. El dominio define una partición del directorio que contiene datos suficientes para

proporcionar servicios de dominio y, a continuación, la replica entre los controladores del dominio.

De esta manera, todos los controladores están en el mismo nivel dentro del dominio y se

administran como una unidad.

Unidades organizativas de Active Directory

Las OU se pueden usar para formar una jerarquía de contenedores dentro de un dominio. Las OU se usan para agrupar objetos con fines administrativos, como la aplicación de una directiva de grupo o la delegación de autoridad. El control (sobre una OU y los objetos de la misma) está determinado por las listas de control de acceso (ACL) de la OU y de los objetos de la OU. Para facilitar la administración de un gran número de objetos, AD DS es compatible con el concepto de delegación de autoridad. Mediante la delegación, los propietarios pueden transferir un control administrativo total o limitado sobre los objetos a otros usuarios o grupos. La delegación es importante porque ayuda a distribuir la administración de un gran número de objetos entre una serie de usuarios en quienes se confía para realizar tareas de administración.

Identificación de los participantes en el proyecto de implementación

Actualizado: abril de 2008


El primer paso a la hora de establecer un proyecto de implementación para los Servicios de dominio de Active Directory (AD DS) consiste en configurar los equipos del proyecto de diseño e implementación que serán responsables de administrar las fases de diseño e implementación del ciclo de proyectos de Active Directory. Además, deben identificarse las personas y grupos que serán los propietarios del directorio y los responsables de mantenerlo una vez completada la implementación.

Definición de las funciones específicas del proyecto

Determinación de los propietarios y administradores

Creación de los equipos del proyecto

Definición de las funciones específicas del proyecto

Un paso importante a la hora de definir los equipos del proyecto es identificar a las personas que desempeñarán las funciones específicas del mismo. Entre ellas se incluyen el patrocinador ejecutivo, el arquitecto del proyecto y el administrador del proyecto. Estas personas son responsables de ejecutar el proyecto de implementación de Active Directory.

Una vez designados el administrador y el arquitecto del proyecto, éstos establecerán los canales de comunicación en toda la organización, crearán las programaciones del proyecto e identificarán a las personas que formarán parte de los equipos del proyecto, empezando por los diversos propietarios.

Patrocinador ejecutivoImplementar una infraestructura como AD DS puede tener una amplia repercusión en la organización. Por este motivo, es importante contar con un patrocinador ejecutivo que entienda el valor comercial de la implementación, apoye el proyecto en el nivel ejecutivo y pueda ayudar a resolver conflictos en toda la organización.

Arquitecto del proyectoToda implementación de Active Directory requiere un arquitecto de proyectos que administre el diseño y el proceso de toma de decisiones de la implementación. El arquitecto aporta conocimientos técnicos que yudan durante el proceso de diseño e implementación de AD DS.

Las responsabilidades del arquitecto del proyecto de Active Directory incluyen:

http://technet.microsoft.com/es-mx/library/cc732532(WS.10).aspx#BKMK_3



Ser propietario del diseño de Active Directory

Entender y registrar las razones que sustentan las decisiones clave del diseño

Asegurarse de que el diseño satisface las necesidades empresariales de la organización

Alcanzar el consenso entre los equipos de diseño, implementación y operaciones

Entender las necesidades de las aplicaciones integradas en AD DS

El diseño final de Active Directory debe reflejar una combinación de objetivos empresariales y decisiones técnicas. Por lo tanto, el arquitecto del proyecto debe revisar las decisiones de diseño para asegurarse de que se alinean con los objetivos empresariales.

Administrador del proyectoAl administrador del proyecto facilita la cooperación entre las unidades empresariales y entre los grupos de administración de tecnología. Lo ideal es que el administrador del proyecto de implementación de Active Directory sea alguien de dentro de la organización que esté familiarizado tanto con las directivas operativas del grupo de TI como con los requisitos de diseño de los grupos que se están preparando para implementar AD DS. El administrador del proyecto supervisa todo el proyecto de implementación, empezando por el diseño y continuando por la implementación, y se asegura de que el proyecto se ajuste a la programación y se mantenga dentro del presupuesto. Entre las responsabilidades del administrador del proyecto se incluyen las siguientes:

Proporcionar la planificación básica del proyecto, como la programación y el presupuesto

Impulsar los progresos en el proyecto de diseño e implementación de Active Directory

Asegurarse de que las personas adecuadas participen en cada una de las fases del proceso de

diseño

Servir como punto de contacto único para el proyecto de implementación de Active Directory

Establecer la comunicación entre los equipos de diseño, implementación y operaciones

Establecer y mantener la comunicación con el patrocinador ejecutivo en todo el proyecto de

implementación

Determinación de los propietarios y administradores

Para los administradores, los propietarios en un proyecto de implementación de Active Directory son responsables de asegurarse de que las tareas de implementación se completan y de que las especificaciones de diseño de Active Directory satisfacen las necesidades de la organización. Los propietarios no necesariamente tendrán acceso directo a la infraestructura del directorio ni podrán manipularlo. Los administradores son las personas responsables de realizar las tareas de implementación necesarias. Los administradores tienen los permisos y el acceso de red necesarios para manipular el directorio y su infraestructura.

La función del propietario es estratégica y administrativa. Los propietarios son responsables de comunicar a los administradores las tareas necesarias para la implementación del diseño de Active Directory, como la creación de nuevos controladores de dominio dentro del bosque. Los administradores son responsables de implementar el diseño en la red conforme a las especificaciones de diseño.

En las organizaciones de gran tamaño, personas diferentes ocupan las funciones de propietario y administrador, mientras que en algunas organizaciones pequeñas, la misma persona actúa como propietaria y administradora al mismo tiempo.

Propietarios de datos y serviciosEn la administración diaria de AD DS intervienen dos tipos de propietarios:

Propietarios de servicios, que son responsables de la planificación y el mantenimiento a largo plazo

de la infraestructura de Active Directory y de garantizar que el directorio continúa funcionando y de

que se mantienen los objetivos establecidos en los acuerdos de nivel de servicios.

Los propietarios de datos, que son responsables del mantenimiento de la información almacenada

en el directorio. Ello incluye la administración de cuentas de equipo y usuario y la administración de

recursos locales, como estaciones de trabajo y servidores miembro.

Es importante identificar con antelación a los propietarios de datos y servicios de Active Directory para que puedan participar en la mayor parte del proceso de diseño que sea posible. Puesto que los propietarios de datos y servicios son responsables del mantenimiento a largo plazo del directorio una vez que ha finalizado el proyecto de implementación, es importante que estas personas proporcionen información relativa a las necesidades organizativas y estén familiarizadas con los motivos y la forma en que se toman determinadas decisiones de diseño. Entre los propietarios de servicios se incluyen el propietario del bosque, el propietario del Sistema de nombres de dominio (DNS) de Active Directory y el propietario de la topología del sitio. Entre los propietarios de datos se incluye a los propietarios de la unidad organizativa (OU).

Administradores de datos y serviciosDos tipos de administradores intervienen en el funcionamiento de AD DS: administradores de servicios y administradores de datos. Los administradores de servicios implementan las decisiones de la directiva tomadas por los propietarios de servicios y hacen cargo de las tareas diarias asociadas al mantenimiento de la infraestructura y el servicio del directorio. Ello incluye administrar los controladores de dominio que hospedan el servicio de directorio, administrar otros servicios de red como DNS necesarios para AD DS, controlar la configuración de las opciones de todo el bosque y garantizar que el directorio esté siempre disponible.

Los administradores de servicios son responsables también de completar las tareas continuas de implementación de Active Directory que son necesarias una vez que se ha completado el proceso inicial de implementación de Active Directory de Windows Server 2008. Por ejemplo, a medida que aumentan las demandas sobre el directorio, los administradores de servicios crean controladores de dominio adicionales y establecen o eliminan las relaciones de confianza entre los dominios, según sea necesario. Por este motivo, el equipo de implementación de Active Directory necesita incluir a administradores de servicios.

Hay que tener cuidado de asignar las funciones de administrador de servicios únicamente a personas de confianza dentro de la organización. Puesto que estas personas tienenla capacidad de modificar los archivos del sistema en los controladores de dominio, pueden modificar el comportamiento de AD DS. Es preciso asegurarse de que los administradores de servicios de la organización sean personas que estén familiarizadas con las directivas operativas y de seguridad vigentes en la red y que entiendan la necesidad de hacer que se cumplan.

Los administradores de datos son usuarios de un dominio responsables tanto de mantener los datos que se almacenan en AD DS, como cuentas de grupo y usuario, como de mantener los equipos miembros del dominio. Los administradores de datos controlan subconjuntos de objetos dentro del directorio y no tienen ningún control sobre la instalación o configuración del servicio de directorio.

De manera predeterminada no se proporcionan cuentas de administradores de datos. Una vez que el equipo de diseño determina cómo deben administrarse los recursos para la organización, los propietarios del dominio deben crear cuentas de administradores de datos y delegar en ellos los permisos correspondientes basándose en el conjunto de objetos de los que van a ser responsables los administradores.

Es mejor limitar el número de administradores de servicios de la organización al número mínimo necesario para garantizar que la infraestructura siga funcionando. La mayor parte del trabajo administrativo pueden

llevarla a cabo los administradores de datos. Los administradores de servicios requieren un conjunto de destrezas mucho más amplio, ya que son responsables de mantener el directorio y la infraestructura que lo sustenta. Los administradores de datos sólo requieren las habilidades necesarias para administrar su parte del directorio. Dividir las asignaciones de trabajo de esta manera tiene como resultado un ahorro de costos para la organización, ya que sólo es preciso impartir formación a un número reducido de administradores para que haga funcionar y mantenga todo el directorio y su infraestructura.

Por ejemplo, un administrador de servicios necesita entender cómo agregar un dominio a un bosque. Ello incluye saber cómo instalar el software para convertir un servidor en un controlador de dominio y cómo manipular el entorno DNS para que el controlador de domino pueda combinarse sin problemas con el entorno de Active Directory. Un administrador de datos sólo necesita saber cómo administrar los datos específicos de los que son responsables, como la creación de nuevas cuentas de usuario para los empleados nuevos del departamento.

Implementar AD DS requiere la coordinación y la comunicación entre los diversos grupos involucrados en el funcionamiento de la infraestructura de red. Estos grupos deben designar a los propietarios de datos y servicios responsables de representar a los distintos grupos durante el proceso de diseño e implementación.

Una vez que ha finalizado el proyecto de implementación, estos propietarios de datos y servicios siguen siendo responsables de la parte de la infraestructura administrada por su grupo. En un entorno de Active Directory, estos propietarios son el propietario del bosque, el propietario de DNS para AD DS, el propietario de la topología del sitio y el propietario de la unidad organizativa (OU). Las funciones de estos propietarios de datos y servicios se explican en las siguientes secciones.

Propietario del bosqueEl propietario del bosque suele ser un administrador jefe de tecnologías de la información (TI) de la organización que es responsable del proceso de implementación de Active Directory y de administrar, en última instancia, la prestación de los servicios dentro del bosque una vez finalizada la implementación. El propietario del bosque designa a las personas que desempeñarán las demás funciones de propietarios identificando al personal clave de la organización capaz de aportar la información necesaria sobre la infraestructura de la red y las necesidades administrativas. El propietario del bosque es responsable de lo siguiente:

Implementación del dominio raíz del bosque para crear el bosque

Implementación del primer controlador de dominio de cada dominio para crear los dominios

necesarios para el bosque

Pertenencias de los grupos de administradores de servicios de todos los dominios del bosque

Creación del diseño de la estructura de la unidad organizativa para cada dominio del bosque

Delegación de la autoridad administrativa a los propietarios de la OU

Cambios en el esquema

Cambios en las opciones de configuración de todo el bosque

Implementación de determinadas opciones de directiva de la directiva de grupo, incluidas las

directivas de cuenta de usuario de dominio como las directivas de bloqueo de cuenta y de

contraseñas específicas.

Opciones de directiva de negocio que se aplican a los controladores de dominio

Cualquier otra configuración de directiva de grupo que se aplica en el nivel de dominio

El propietario del bosque tiene autoridad sobre todo el bosque. Es responsabilidad del propietario del bosque establecer las directivas de negocio y la directiva de grupo para seleccionar a las personas que serán administradores de servicios. El propietario del bosque es un propietario de servicios.

Propietario de DNS para AD DSEl propietario de DNS para AD DS es una persona que tiene un conocimiento profundo de la infraestructura de DNS y del espacio de nombres existentes de la organización.

El propietario de DNS para AD DS es responsable de lo siguiente:

Servir como enlace entre el equipo de diseño y el grupo de TI que posee actualmente la

infraestructura de DNS

Proporcionar información sobre el espacio de nombres de DNS existente en la organización para

ayudar a crear el nuevo espacio de nombres de Active Directory.

Trabajar con el equipo de implementación para garantizar que la nueva infraestructura de DNS se

implemente conforme a las especificaciones del equipo de diseño y de que ésta está funcionando

adecuadamente.

Administrar la infraestructura de DNS para AD DS, incluido el servicio Servidor DNS y los datos DNS

El propietario de DNS para AD DS es un propietario de servicios.

Propietario de la topología del sitioEl propietario de la topología del sitio está familiarizado con la estructura física de la red de la organización, incluida la asignación de subredes individuales, enrutadores y áreas de red que están conectadas mediante vínculos lentos. El propietario de la topología del sitio es responsable de lo siguiente:

Entender la topología de la red física y cómo afecta a AD DS

Entender cómo repercutirá la implementación de Active Directory en la red

Determinar los sitios lógicos de Active Directory que necesitan crearse

Actualizar los objetos del sitio para los controladores de dominio cuando se agrega, modifica o

elimina una subred

Crear vínculos de sitio, puentes de vínculo a sitio y objetos de conexión manual

El propietario de la topología del sitio es un propietario de servicios.

Propietario de unidad organizativa (OU)El propietario de la unidad organizativa (OU) es responsable de administrar los datos almacenados en el directorio. Esta persona necesita estar familiarizado con las directivas operativas y de seguridad vigentes en la red. Los propietarios de la unidad organizativa (OU) sólo pueden realizar las tareas que han delegado en ellos los administradores de servicios, y sólo pueden realizar dichas tareas en las unidades organizativas a las que están asignados. Entre las tareas que podrían asignarse al propietario de la OU se incluyen las siguientes:

Realizar todas las tareas de administración de cuentas dentro de sus unidades organizativas (OU)

asignadas

Administrar estaciones de trabajo y servicios miembro que son miembros de sus unidades

organizativas asignadas

Delegar la autoridad en los administradores locales dentro de sus unidades organizativas (OU)

asignadas

El propietario de la unidad organizativa (OU) es un propietario de datos.

Creación de los equipos del proyecto

Los equipos de proyecto de Active Directory son grupos temporales responsables de completar las tareas de diseño e implementación de Active Directory. Cuando finaliza el proyecto de implementación de Active Directory, los propietarios asumen la responsabilidad del directorio y los equipos de proyecto pueden disolverse.

El tamaño de los equipos de proyecto varía dependiendo del tamaño de la organización. En las organizaciones pequeñas, una única persona puede abarcar varias áreas de responsabilidad en un equipo de proyecto y participar en diversas fases de la implementación. Las organizaciones de gran tamaño pueden requerir equipos más grandes con personas diferentes o incluso equipos distintos que abarquen las diversas áreas de responsabilidad. El tamaño de los equipos no es importante siempre que se asignen todas las áreas de responsabilidad y que los objetivos de diseño de la organización se satisfagan.

Identificación de los potenciales propietarios de bosqueIdentifique los grupos de la organización que poseen y tienen el control de los recursos necesarios para proporcionar los servicios de directorio a los usuarios de la red. Estos grupos se consideran propietarios del bosque en potencia.

La separación entre la administración de datos y la de servicios en AD DS permite al grupo (o grupos) de TI de la infraestructura de una organización administrar el servicio de directorio mientras los administradores de cada grupo administran los datos que pertenecen a sus propios grupos. Los propietarios potenciales del bosque tienen la autoridad necesaria sobre la infraestructura de la red para implementar y dar soporte técnico a AD DS.

Para las organizaciones que tienen un grupo de TI de infraestructura centralizado, dicho grupo es generalmente el propietario del bosque y, por tanto, el propietario en potencia del bosque para cualquier implementación futura. Las organizaciones que contienen una serie de grupos de TI de infraestructura independientes tienen un número de propietarios potenciales del bosque. Si la organización ya tiene una infraestructura de Active Directory, los propietarios del bosque actuales son también los propietarios potenciales del bosque para nuevas implementaciones.

Seleccione uno de los propietarios potenciales del bosque para que actúe como propietario de cualquier bosque que esté considerando implementar. Estos propietarios potenciales del bosque son responsables de trabajar con el equipo de diseño para determinar si se implementará realmente o no su bosque o si hay algún curso de acción alternativo (como unirse a un bosque existente) con el que se haga un mejor uso de los recursos disponibles al tiempo que se satisfacen sus necesidades. El propietario (o propietarios) del bosque de la organización es miembro del equipo de diseño de Active Directory.

Creación de un equipo de diseñoEl equipo de diseño de Active Directory es responsable de reunir toda la información necesaria para tomar decisiones acerca del diseño de la estructura lógica de Active Directory.

Entre las responsabilidades del equipo de diseño se incluyen las siguientes:

Determinar cuántos bosques y dominios se necesitan y qué relaciones habrá entre los bosques y los

dominios

Trabajar con los propietarios de los datos para garantizar que el diseño satisface sus requisitos

administrativos y de seguridad

Trabajar con los administradores de red actuales para garantizar que la infraestructura de red

existente es compatible con el diseño y que éste no tendrá efectos adversos sobre las aplicaciones

implementadas en la red.

Trabajar con los representantes del grupo de seguridad de la organización para garantizar que el

diseño satisface las directivas de seguridad establecidas.

Diseñar estructuras de unidad organizativa (OU) que permitan niveles de protección apropiados y

una adecuada delegación de autoridad a los propietarios de los datos.

Trabajar con el equipo de implementación para probar el diseño en un entorno de laboratorio a fin

de garantizar que funciona conforme a lo planeado, así como para modificarlo en caso de que sea

necesario solucionar cualquier problema que pudiera surgir.

Crear un diseño de topología de sitio que satisfaga los requisitos de replicación del bosque al tiempo

que evita la sobrecarga del ancho de banda disponible. Para obtener más información sobre el

diseño de la topología del sitio, consulte el tema que trata acerca del diseño de la topología del sitio

de los Servicios de dominio de Active Directory en http://go.microsoft.com/fwlink/?LinkId=89026

(puede estar en inglés).

Trabajar con el equipo de implementación para garantizar que el diseño se implementa

correctamente

Entre los miembros del equipo de diseño se incluyen:

Propietarios potenciales del bosque

Arquitecto del proyecto

Administrador del proyecto

Personas responsables de establecer y mantener las directivas de seguridad en la red

Durante el proceso de diseño de la estructura lógica, el equipo de diseño identifica a los demás propietarios. Estas personas deben empezar a participar en el proceso de diseño tan pronto como sean designadas. Una vez que el proyecto de implementación se entrega al equipo de implementación, el equipo de diseño es responsable de supervisar el proceso de implementación para garantizar que el diseño se implemente correctamente. El equipo de diseño también se encarga de realizar los cambios en el diseño conforme a los comentarios recibidos de las pruebas.

Creación de un equipo de implementaciónEl equipo de implementación de Active Directory es responsable de probar e implementar el diseño de la estructura lógica de Active Directory. Esto conlleva realizar las siguientes tareas:

Establecer un entorno de prueba que emule suficientemente el entorno de producción

Probar el diseño implementando la estructura de dominio y bosque propuesta en un entorno de

laboratorio a fin de verificar que satisface los objetivos de cada uno de los propietarios de las

funciones

Desarrollar y probar cualquiera de los escenarios de migración propuestos por el diseño en un

entorno de laboratorio

http://go.microsoft.com/fwlink/?LinkId=89026

Asegurarse de que los propietarios cierran la sesión en el proceso de comprobación para garantizar

que se están comprobando las características de diseño correctas

Probar la operación de implementación en un entorno piloto

Una vez completadas las tareas de diseño y prueba, el equipo de implementación realiza las siguientes tareas:

Crea los bosques y dominios conforme al diseño de la estructura lógica de Active Directory

Crea los sitios y objetos de vínculo a sitios basándose en el diseño de la topología del sitio

Garantiza que la infraestructura de DNS se configure para admitir AD DS y que todos los espacios de

nombres nuevos se integren en el espacio de nombres existente de la organización

Entre los miembros del equipo de implementación de Active Directory se incluyen:

Propietario del bosque

Propietario de DNS para AD DS

Propietario de la topología del sitio

Propietarios de unidad organizativa (OU)

El equipo de implementación trabaja con los administradores de datos y servicios durante la fase de implementación para garantizar que los miembros del equipo de operaciones están familiarizados con el nuevo diseño. Esto ayuda a garantizar que la transición de propiedad se realice con fluidez una vez completada la operación de implementación. Al término del proceso de implementación, la responsabilidad de mantener el nuevo entorno de Active Directory pasa al equipo de operaciones.

Documentar los equipos de diseño e implementaciónDocumente los nombres y la información de contacto de las personas que participarán en el diseño e implementación de AD DS. Identifique a las personas responsables de cada función dentro de los equipos de diseño e implementación. En principio, en esta lista se encuentran los propietarios potenciales del bosque, el administrador del proyecto y el arquitecto del proyecto. Cuando determine el número de bosques que desea implementar, puede que necesite crear nuevos equipos de diseño para bosques adicionales. Tenga en cuenta que tendrá que actualizar su documentación a medida que cambien los miembros del equipo y a medida que identifique a los distintos propietarios de Active Directory durante el proceso de diseño. Para ver una hoja de trabajo que le ayude a documentar los equipos de diseño e implementación para cada bosque, descargue Job_Aids_Designing_and_Deploying_Directory_and_Security_Services.zip de Job Aids del Kit de implementación de Windows Server 2003 en http://go.microsoft.com/fwlink/?LinkID=102558 (puede estar en inglés) y abra "Design and Deployment Team Information" (DSSLOGI_1.doc).

Creación del diseño de un bosqueActualizado: abril de 2008


La creación del diseño de un bosque conlleva identificar primero los grupos de la organización que disponen de recursos para alojar un bosque de Active Directory y, a continuación, definir los requisitos de diseño del bosque. Por último, es preciso determinar el número de bosques que se requieren para satisfacer las necesidades de la organización.

Una vez asignados todos los requisitos de diseño a modelos de bosque y seleccionado el modelo de bosque que satisface las necesidades de la organización, se debe documentar el diseño de bosque propuesto. En la documentación se incluirá el nombre del grupo para el que se diseña el bosque, la información de contacto

http://go.microsoft.com/fwlink/?LinkID=102558

del propietario del bosque, el tipo de cada uno de los bosques que incluya y los requisitos que cada bosque satisface. Esta documentación ayudará al equipo de diseño a garantizar que todas las personas adecuadas participen en el proceso de diseño y a aclarar el alcance del proyecto de implementación.

Para ver una hoja de trabajo que le ayude a documentar el diseño de bosque propuesto, descargue Job_Aids_Designing_and_Deploying_Directory_and_Security_Services.zip de Job Aids del Kit de implementación de Windows Server 2003 en http://go.microsoft.com/fwlink/?LinkID=102558 (puede estar en inglés) y abra "Forest Design" (DSSLOGI_3.doc).

En esta sección

Identificación de los requisitos de diseño del bosque

Identificación de los requisitos de diseño del bosqueActualizado: abril de 2008


A la hora de crear el diseño de un bosque para la organización es preciso identificar los requisitos comerciales a los que necesita ajustarse la estructura del directorio. Esto conlleva determinar el grado de autonomía que los grupos de la organización necesitan para administrar sus recursos de red y si cada grupo necesita o no aislar sus recursos en la red de los demás grupos.

Los Servicios de dominio de Active Directory (AD DS) permiten diseñar una infraestructura de directorios que dé cabida a varios grupos de una organización con requisitos de administración únicos y conseguir la independencia estructural y operativa que sea necesaria entre los grupos.

Los grupos de la organización podrían tener algunos de los siguientes tipos de requisitos:

Requisitos de estructura organizativa. Partes de una organización podrían participar en una

infraestructura compartida para ahorrar costos, pero requerir la capacidad de operar de forma

independiente del resto de la organización. Por ejemplo, un grupo de investigación de una

organización de gran tamaño podría necesitar mantener el control sobre la totalidad de sus datos de

investigación.

Requisitos operativos. Una parte de una organización podría imponer restricciones únicas sobre

la seguridad, disponibilidad o configuración del servicio de directorio, o usar aplicaciones que

impongan restricciones únicas en el directorio. Por ejemplo, unidades de negocio individuales dentro

de una organización podrían implementar aplicaciones habilitadas para el uso de directorios que

modifiquen el esquema del directorio y que no hayan implementado otras unidades de negocio.

Puesto que todos los dominios del bosque comparten el esquema del directorio, crear varios

bosques es una solución para casos como este. Se pueden encontrar otros ejemplos en los

siguientes casos y organizaciones:

Organizaciones militares

Escenarios de hospedaje

Organizaciones que mantienen un directorio disponible tanto interna como externamente (como

aquellos a los que los usuarios pueden obtener acceso públicamente en Internet).

Requisitos legales. Algunas organizaciones deben cumplir requisitos legales para operar de una

forma determinada, como por ejemplo limitar el acceso a ciertos datos especificados en un contrato

comercial. Algunas organizaciones deben cumplir requisitos de seguridad para operar en redes

internas aisladas. El incumplimiento de dichos requisitos puede dar lugar a la pérdida del contrato y

al inicio de posibles acciones legales.

Parte de la identificación de los requisitos de diseño del bosque consiste en identificar el grado de confianza que los grupos de la organización pueden tener en los potenciales propietarios del bosque y sus administradores de servicios y en identificar los requisitos de autonomía y aislamiento de cada grupo de la organización.

El equipo de diseño debe documentar los requisitos de autonomía y aislamiento en materia de administración de datos y servicios para cada grupo de la organización que desee usar AD DS. El equipo debe también tomar nota de las áreas de conectividad limitada que podrían repercutir en la implementación de AD DS.

El equipo de diseño debe documentar los requisitos de autonomía y aislamiento en materia de administración de datos y servicios para cada grupo de la organización que desee usar AD DS. El equipo debe también tomar nota de las áreas de conectividad limitada que podrían repercutir en la implementación de AD DS. Para ver una hoja de trabajo que le ayude a documentar las regiones identificadas, descargue Job_Aids_Designing_and_Deploying_Directory_and_Security_Services.zip de Job Aids del Kit de implementación de Windows Server 2003 en http://go.microsoft.com/fwlink/?LinkID=102558 (puede estar en inglés) y abra "Forest Design Requirements" (DSSLOGI_2.doc).

En esta sección

Ámbito de autoridad del administrador de servicios

Ámbito de autoridad del administrador de serviciosActualizado: abril de 2008


Si decide participar en un bosque de Active Directory, debe confiar en el propietario del bosque y en los administradores de servicios. Los propietarios del bosque son responsables de seleccionar y administrar a los administradores de servicios; por lo tanto, si confía en un propietario de bosque, también confiará en los administradores de servicios que éste administra. Los administradores de servicios tienen acceso a todos los recursos del bosque. Antes de tomar la decisión de participar en un bosque, es importante entender que el propietario del bosque y los administradores de servicios tendrán acceso total a los datos. Este acceso no puede impedirse.

Todos los administradores de servicios de un bosque tienen un control absoluto sobre todos los datos y servicios de todos los equipos del bosque. Los administradores de servicios tienen capacidad para hacer lo siguiente:

Corregir errores en listas de control de acceso (ACL) de objetos. Esto permite al administrador de

servicios leer, modificar o eliminar objetos con independencia de las ACL definidas en los mismos.

Modificar el software del sistema de un controlador de dominio para pasar por alto las

comprobaciones de seguridad normales. Esto permite al administrador de servicios ver o manipular

cualquier objeto del dominio, con independencia de la ACL del objeto.

Usar la directiva de seguridad de grupos restringidos para conceder acceso administrativo a

cualquier usuario o grupo a cualquier equipo unido al dominio. De esta manera, los administradores

de servicios pueden obtener el control de cualquier equipo unido al dominio con independencia de

las intenciones del propietario del equipo.

Restablecer contraseñas o cambiar la pertenencia a grupos de los usuarios.

Obtener acceso a otros dominios del bosque modificando el software del sistema de un controlador

de dominio. Los administradores de servicios pueden influir en el funcionamiento de cualquier

dominio del bosque, ver o manipular los datos de configuración del mismo, ver o manipular los

datos almacenados en cualquier dominio, y ver o manipular los datos almacenados en cualquier

equipo unido al bosque.

Por esta razón, los grupos que almacenan datos en unidades organizativas (OU) en el bosque y que unen equipos a un bosque deben confiar en los administradores de servicios. Un grupo que se una a un bosque debe decidir confiar en todos los administradores de servicios del bosque. Esto conlleva asegurarse de que:

Se puede confiar en que el propietario del bosque actuará conforme a los intereses del grupo y que

no tiene motivos para comportarse de forma malintencionada en contra del grupo.

El propietario del bosque limita adecuadamente el acceso físico a los controladores de dominio. Los

controladores de dominio de un bosque no se pueden aislar entre sí. Un atacante que tuviera acceso

físico a un solo controlador de dominio podría realizar sin conexión cambios en la base de datos del

directorio y, con ello, interferir en el funcionamiento de cualquier dominio del bosque, ver o

manipular datos almacenados en cualquier lugar del bosque, y ver o manipular datos almacenados

en cualquier equipo unido al bosque. Por este motivo, el acceso físico a los controladores de dominio

debe estar limitado al personal de confianza.

Entiende y acepta el riesgo potencial que supondría que los administradores de servicios de

confianza fueran coaccionados a poner en peligro la seguridad del sistema.

Algunos grupos podrían determinar que las ventajas en cuanto a colaboración y ahorro de costos que supone participar en una infraestructura compartida superan a los riesgos de que los administradores de servicios hagan un mal uso de su autoridad o sean coaccionados para ello. Estos grupos pueden compartir un bosque y usar unidades organizativas (OU) para delegar autoridad. Sin embargo, otros grupos podrían no aceptar este riesgo porque las consecuencias de poner en peligro la seguridad sean demasiado graves. Estos grupos requieren bosques independientes.

Autonomía y aislamiento

Autonomía y aislamiento



Es posible diseñar la estructura lógica de Active Directory para conseguir uno de estos dos objetivos:

Autonomía. Implica el control independiente pero no exclusivo de un recurso. Cuando se logra la

autonomía, los administradores tienen autoridad para administrar los recursos de forma

independiente; no obstante, hay administradores con mayor autoridad que también tienen el control

sobre dichos recursos y pueden retirar dicho control en caso necesario. Es posible diseñar la

estructura lógica de Active Directory para conseguir los siguientes tipos de autonomía:

Autonomía del servicio. Este tipo de autonomía conlleva el control sobre la totalidad o parte

de la administración del servicio.

Autonomía de datos. Este tipo de autonomía conlleva el control sobre la totalidad o parte de

los datos almacenados en el directorio o en equipos miembro unidos al directorio.

Aislamiento. Implica el control independiente y exclusivo de un recurso. Cuando se consigue el

aislamiento, los administradores tienen autoridad para administrar un recurso de forma

independiente, y ningún otro administrador puede retirar dicho control. Es posible diseñar la

estructura lógica de Active Directory para conseguir los siguientes tipos de aislamiento:

Aislamiento del servicio. Impide a los administradores (que no hayan sido designados

específicamente para controlar la administración del servicio) controlar o interferir en la

administración de los servicios.

Aislamiento de datos. Impide a los administradores (que no hayan sido designados

específicamente para controlar o ver los datos) controlar o ver un subconjunto de datos del

directorio o de los equipos miembro unidos al directorio.

Los administradores que requieren sólo autonomía aceptan que otros administradores con una autoridad administrativa mayor o igual a la suya tengan un control igual o mayor que ellos sobre la administración de los datos y servicios. Los administradores que requieren aislamiento tienen el control exclusivo sobre la administración de los datos y servicios. Por lo general, es menos caro crear un diseño para lograr autonomía que crear un diseño para lograr aislamiento.

En Servicios de dominio de Active Directory (AD DS), los administradores pueden delegar tanto la administración de datos como la de servicios para lograr bien autonomía o bien aislamiento entre las organizaciones. La combinación de los requisitos de administración de servicios, administración de datos, autonomía y aislamiento de una organización influye en los contenedores de Active Directory que se usan para delegar la administración.

Requisitos de aislamiento y autonomía

El número de bosques que es preciso implementar se basa en los requisitos de autonomía y aislamiento de cada grupo de la organización. Para identificar los requisitos de diseño del bosque deben identificarse los requisitos de autonomía y aislamiento de todos los grupos de la organización. Concretamente, hay que identificar la necesidad de aislamiento de datos, autonomía de datos, aislamiento de servicios y autonomía de servicios. También es necesario identificar las áreas de conectividad limitada de la organización.

Aislamiento de datosEl aislamiento de datos conlleva el control exclusivo sobre los datos por parte del grupo u organización dueños de los mismos. Es importante destacar que los administradores de servicios tienen la capacidad de retirar el control de un recurso a los administradores de datos. Los administradores de datos no pueden impedir que los administradores de servicios obtengan acceso a los recursos que ellos controlan. Por lo tanto, no se puede lograr el aislamiento de datos si otro grupo de la organización es responsable de la administración de los servicios. Si un grupo requiere aislamiento de datos, dicho grupo debe asumir también la responsabilidad de la administración de los servicios.

Puesto que los datos almacenados en AD DS y en equipos unidos a AD DS no se pueden aislar de los administradores de servicios, la única manera de que un grupo de una organización logre un completo aislamiento de datos es crear un bosque independiente para dichos datos. Las organizaciones para las que un ataque con software malintencionado o por parte de un administrador de servicios coaccionado puede tener consecuencias importantes podrían optar por crear un bosque independiente a fin de lograr el aislamiento de los datos. Normalmente, los requisitos legales crean la necesidad de este tipo de aislamiento de datos. Por ejemplo:

Por ley, una institución financiera se ve obligada a limitar el acceso a los datos pertenecientes a los

clientes de una jurisdicción concreta a los usuarios, equipos y administradores situados en dicha

jurisdicción. Aunque la institución confíe en administradores de servicios que trabajan fuera del área

protegida, si se infringe la limitación de acceso la institución no podrá volver a realizar negocios en

dicha jurisdicción. Por lo tanto, la institución financiera debe aislar los datos frente a los

administradores de servicios que se encuentran fuera de esa jurisdicción. Hay que tener en cuenta

que el cifrado no siempre es una alternativa a esta solución. El cifrado podría no proteger los datos

frente a los aministradores de servicios.

Un contratista de defensa está obligado por ley a limitar el acceso a los datos protegidos a un

conjunto de usuarios específico. Aunque el contratista confíe en administradores de servicios que

controlan sistemas informáticos relacionados con otros proyectos, cualquier infracción de esta

limitación de acceso provocará que el contratista pierda el negocio.

Autonomía de datosLa autonomía de datos tiene que ver con la capacidad de un grupo u organización para administrar sus propios datos, incluida la toma de decisiones administrativas acerca de los datos y la realización de cualquier tarea administrativa necesaria sin que sea precisa la aprobación de otra autoridad.

La autonomía de datos no impide a los administradores de servicios del bosque obtener acceso a los datos. Por ejemplo, los miembros de un grupo de investigación de una organización de gran tamaño podrían requerir la capacidad de administrar los datos específicos de un proyecto ellos mismos, pero no de proteger los datos frente a otros administradores del bosque.

Aislamiento de serviciosEl aislamiento de servicios conlleva el control exclusivo de la infraestructura de Active Directory. Los grupos que requieren aislamiento de servicios requieren que ningún administrador externo al grupo pueda interferir en el funcionamiento del servicio de directorio.

Los requisitos legales o de funcionamiento suelen crear la necesidad de aislamiento de servicios. Por ejemplo:

Una empresa de fabricación tiene una aplicación crítica que controla los equipos de la fábrica. No se

puede permitir que las interrupciones en el servicio de otras partes de la red de la organización

interfieran en el funcionamiento de la fábrica.

Una empresa de hospedaje da servicio a varios clientes. Cada uno de los clientes requiere

aislamiento de servicios para que ninguna interrupción de los mismos que afecte a un cliente pueda

afectar a los demás.

Autonomía del servicioLa autonomía del servicio conlleva la capacidad para administrar la infraestructura sin el requisito del control exclusivo; por ejemplo, cuando un grupo desea realizar cambios en la infraestructura (como agregar o eliminar dominios, modificar el espacio de nombres del Sistema de nombres de dominio (DNS) o modificar el esquema) sin la aprobación del propietario del bosque.

La autonomía de servicios podría requerirse dentro de una organización para un grupo que requiriera la capacidad de controlar el nivel de servicio de AD DS (agregando y eliminando controladores de dominio, en caso necesario) o para un grupo que requiriera la capacidad de instalar aplicaciones habilitadas para directorio que requiriesen extensiones de esquema.

Conectividad limitada

Si un grupo dentro de la organización posee redes que están separadas mediante dispositivos que restringen o limitan la conectividad entre las redes, como firewalls y dispositivos de traducción de direcciones de red (NAT), ello puede afectar al diseño del bosque. A la hora de identificar los requisitos de diseño del bosque, asegúrese de anotar las ubicaciones en las que tiene una conectividad de red limitada. Esta información es necesaria para poder tomar decisiones en relación con el diseño del bosque.

Determinación del número de bosques requeridos

Determinación del número de bosques requeridosActualizado: abril de 2008


Para determinar el número de bosques que deben implementarse es necesario identificar y evaluar cuidadosamente los requisitos de autonomía y aislamiento de cada grupo de la organización y asignar dichos requisitos a los modelos de diseño de bosque adecuados.

Tenga en cuenta lo siguiente a la hora de determinar el número de bosques que desea implementar en la organización:

Los requisitos de aislamiento limitan las opciones de diseño. Por lo tanto, si identifica requisitos de

aislamiento, asegúrese de que los grupos realmente necesitan aislamiento de datos y que la

autonomía de datos no es suficiente para ellos. Asegúrese de que los diversos grupos de la

organización entienden con claridad los conceptos de aislamiento y autonomía.

La negociación del diseño puede ser un proceso largo. Puede que los grupos tengan dificultades

para ponerse de acuerdo sobre la propiedad y los usos de los recursos disponibles. Asegúrese de

que los grupos de la organización tengan tiempo suficiente para realizar una investigación adecuada

que les permita identificar sus necesidades. Establezca plazos estrictos para tomar las decisiones de

diseño y obtenga el consenso de todas las partes respecto de los mismos.

La determinación del número de bosques que se van a implementar conlleva equilibrar costos y

beneficios. Un modelo de bosque único es la opción más rentable y la que menos sobrecarga

administrativa supone. Si bien algún grupo de la organización podría preferir un funcionamiento

autónomo de los servicios, quizá sea más rentable para la organización suscribirse a un grupo de

servicios centralizados de tecnologías de la información (TI) de confianza. Esto permite al grupo ser

dueño de la administración de los datos sin incurrir en los costos añadidos de la administración de

servicios. El equilibrio entre costos y beneficios podría requerir la intervención del patrocinador

ejecutivo.

Un bosque único es la configuración más fácil de administrar. Permite la máxima colaboración

dentro del entorno, ya que:

Todos los objetos de un bosque único se incluyen en el catálogo global. Por lo tanto, no es

necesaria ninguna sincronización entre bosques.

No es necesario administrar una infraestructura duplicada.

No se recomienda que dos organizaciones de TI autónomas e independientes compartan la

propiedad de un bosque único. En el futuro podrían cambiar los objetivos de los dos grupos de TI y

dejar de aceptar el control compartido.

No se recomienda subcontratar la administración de servicios con más de un asociado externo. Las

organizaciones multinacionales que tienen grupos en diferentes países o regiones podrían decidir

subcontratar la administración de los servicios con un asociado externo diferente en cada país o

región. Puesto que no es posible aislar entre sí a varios asociados externos, las acciones de uno de

ellos pueden repercutir en el servicio de otro, lo que hace difícil exigirle a cada uno las

correspondientes responsabilidades en el cumplimiento de los acuerdos de nivel de servicios.

Sólo debe haber una instancia de un dominio de Active Directory en cada momento. Microsoft no

permite clonar, dividir o copiar los controladores de dominio de un dominio para intentar establecer

una segunda instancia del mismo dominio. Para obtener más información sobre esta limitación,

consulte la siguiente sección.

Limitaciones de reestructuración

Cuando una empresa adquiere otra empresa, unidad de negocio o línea de productos, puede que desee adquirir también los correspondientes activos de TI al vendedor. Concretamente, el comprador podría desear adquirir la totalidad o parte de los controladores de dominio que hospedan las cuentas de usuario, cuentas de equipo y grupos de seguridad correspondientes a los activos comerciales que se van a comprar. Los únicos métodos que se admiten para que el comprador adquiera los activos de TI almacenados en el bosque de Active Directory del vendedor son los siguientes:

1. Adquirir la única instancia del bosque, incluidos todos los controladores de dominio y datos del

directorio del bosque entero del vendedor.

2. Migrar los datos del directorio necesarios desde los dominios o el bosque del vendedor a uno o más

dominios del comprador. El destino de dicha migración podría ser un bosque totalmente nuevo o

uno o más dominios existentes que ya estén implementados en el bosque del comprador.

Esta limitación existe porque:

A cada dominio de un bosque de Active Directory se le asigna una identidad única durante la

creación del bosque. Copiar controladores de dominio de un dominio original en un dominio clonado

pone en peligro la seguridad tanto de los dominios como del bosque. Entre las amenazas al dominio

original y el dominio clonado se incluyen las siguientes:

Uso compartido de contraseñas que se pueden usar para obtener acceso a los recursos

Conocimiento de los grupos y cuentas de usuario privilegiados

Asignación de direcciones IP a nombres de equipos

Adiciones, eliminaciones y modificaciones de información del directorio si los controladores de

dominio de un dominio clonado establecen alguna vez una conexión de red con los controladores

de dominio del dominio original

Los dominios clonados comparten una misma identidad de seguridad; por lo tanto, no pueden

establecerse entre ellos relaciones de confianza, aun cuando se haya cambiado el nombre de uno o

de los dos dominios.

Creación del diseño de un dominioActualizado: abril de 2008


El propietario del bosque es responsable de crear el diseño de un dominio para el bosque. Crear el diseño de un dominio conlleva examinar los requisitos de replicación y la capacidad de la infraestructura de red y, a continuación, crear una estructura de dominio que permita a los Servicios de dominio de Active Directory (AD DS) funcionar de la forma más eficiente. Los dominios se usan para crear una partición del directorio de manera que la información del mismo se pueda distribuir y administrar de forma eficiente en toda la empresa. El objetivo a la hora de diseñar un dominio es maximizar la eficacia de la topología de replicación de Active Directory y garantizar, al mismo tiempo, que la replicación no consuma demasiado ancho de banda y no interfiera en el funcionamiento diario de la red.

En esta sección

Revisión de los modelos de dominio

Revisión de los modelos de dominio



Los siguientes factores repercuten en el modelo de diseño del dominio que elija:

Capacidad disponible en la red que desea asignar a los Servicios de dominio de Active Directory

(AD DS). El objetivo es seleccionar un modelo que proporcione una replicación eficaz de la

información con una mínima repercusión sobre el ancho de banda disponible de la red.

Número de usuarios de la organización. Si la organización tiene un número elevado de usuarios,

implementar más de un dominio permite hacer una partición de los datos y proporciona un mayor

control sobre el volumen de tráfico de replicación que pasará a través de una determinada conexión

de red. Ello permite controlar dónde se replican los datos y reduce la carga creada por el tráfico de

replicación sobre los vínculos de baja velocidad de la red.

El diseño de dominio más sencillo es el dominio único. En un diseño de dominio único, toda la información se replica para la totalidad de los controladores del dominio. No obstante, en caso necesario es posible implementar dominios regionales adicionales. Esto podría ocurrir si partes de la infraestructura de red están conectadas por vínculos de baja velocidad y el propietario del bosque desea asegurarse de que el tráfico de replicación no sobrepasa la capacidad asignada a AD DS.

Es mejor minimizar el número de dominios que se implementan en el bosque. Así se reduce la complejidad general de la implementación y, como resultado, se reduce el costo total de propiedad. En la siguiente tabla se relacionan los costos administrativos asociados a la adición de dominios regionales.

Costo Implicaciones

Administración de varios grupos de administradores de servicios

Cada dominio tiene sus propios grupos de administradores de servicios que es preciso administrar de forma independiente. La pertenencia de estos grupos de administradores de servicios debe controlarse cuidadosamente.

Mantenimiento de la coherencia entre opciones de directiva de grupo que son comunes a varios dominios

La aplicación de las opciones de directiva de grupo que deban aplicarse en todo el bosque deberá realizarse por separado a cada dominio individual del bosque.

Mantenimiento de la coherencia entre opciones de auditoría y control de acceso que son comunes a varios dominios

La aplicación de las opciones de auditoría y control de acceso que deban aplicarse en el bosque deberá realizarse por separado a cada dominio individual del bosque.

Aumento de las probabilidades de que se muevan objetos entre dominios

A mayor número de dominios, mayor es la probabilidad de que los usuarios necesiten moverse de un dominio a otro. Este movimiento puede afectar a los usuarios finales.

Nota

Las directivas de bloqueo de cuenta y contraseña específica de Windows Server 2008 pueden repercutir también en el modelo de diseño del dominio que se seleccione. Antes de la aparición de esta versión de Windows Server 2008, sólo se podía aplicar una directiva de bloqueo de cuenta y contraseña, especificada en la directiva predeterminada de dominio del dominio, a todos los usuarios

del dominio. Como resultado, si quería disponer de una configuración de bloqueo de cuenta y contraseña distinta para varios conjuntos de usuarios, tenía que crear un filtro de contraseña, o bien implementar varios dominios. Ahora se pueden usar directivas de contraseña específica para establecer varias directivas de contraseña y para aplicar diversas restricciones de contraseña y directivas de bloqueo de cuenta a grupos de usuarios diferentes dentro de un solo dominio. Para obtener más información acerca de las directivas de bloqueo de cuenta y contraseña específica, consulte la Guía paso a paso de configuración de directivas de bloqueo de cuentas y contraseñas específicas en http://go.microsoft.com/fwlink/?LinkID=91477 (puede estar en inglés).

Modelo de dominio único

El modelo de dominio único es el más fácil de administrar y el menos costoso de mantener. Se compone de un bosque que contiene un solo dominio. Este dominio es el dominio raíz del bosque, y contiene todas las cuentas de grupo y usuario del bosque.

El modelo de bosque de dominio único reduce la complejidad administrativa y ofrece las siguientes ventajas:

Cualquier controlador del dominio puede autenticar a cualquier usuario del bosque.

Todos los controladores de dominio pueden ser catálogos globales, por lo que no es necesario

planear la ubicación de un servidor de catálogo global.

En un bosque de dominio único, todos los datos del directorio se replican en todas las ubicaciones geográficas que hospedan controladores de dominio. Si bien este modelo es el más fácil de administrar, también crea el mayor volumen de tráfico de replicación de los dos modelos de dominio. La partición del directorio en varios dominios limita la replicación de objetos a regiones geográficas específicas, pero da lugar a una mayor sobrecarga administrativa.

Modelo de dominio regional

Todos los objetos de datos de un dominio se replican en todos los controladores de dominio de dicho dominio. Por este motivo, si el bosque tiene un gran número de usuarios distribuidos en diferentes ubicaciones geográficas conectadas por una red de área extensa (WAN), podría ser necesario implementar dominios regionales a fin de reducir el tráfico de replicación a través de los vínculos WAN. Los dominios regionales basados geográficamente se pueden organizar en función de la conectividad WAN de red.

El modelo de dominio regional permite mantener un entorno estable a lo largo del tiempo. Base las regiones usadas para definir los dominios del modelo en elementos estables, como límites continentales. Los dominios basados en otros factores, como los grupos de la organización, pueden cambiar con frecuencia y podrían requerir la reestructuración del entorno.

El modelo de dominio regional consiste en un dominio raíz del bosque y uno o más dominios regionales. Crear el diseño de un modelo de dominio regional conlleva identificar el dominio raíz del bosque y determinar el número de dominios adicionales que se necesitan para satisfacer los requisitos de replicación. Si la organización incluye grupos que requieren el aislamiento de datos o de servicios frente a otros grupos de la organización, cree un bosque independiente para dichos grupos. Los dominios no proporcionan aislamiento de datos ni aislamiento de servicios.

Determinación del número de dominios requeridos

Determinación del número de dominios requeridos




Todos los bosques tienen al principio un único dominio. El número máximo de usuarios que puede contener un bosque de un solo dominio se basa en el vínculo de menor velocidad que debe dar cabida a la replicación entre los controladores de dominio y el ancho de banda disponible que se desea asignar a los Servicios de dominio de Active Directory (AD DS). En la tabla siguiente se indica el número máximo recomendado de usuarios que un dominio puede contener en función del bosque de un único dominio, la velocidad del vínculo más lento y el porcentaje de ancho de banda que se desea reservar para la replicación. Esta información se aplica a bosques que contienen un máximo de 100.000 usuarios y una conectividad igual o superior a 28,8 kilobits por segundo (Kbps). Consulte a un diseñador de Active Directory experimentado para que le indique las recomendaciones aplicables a los bosques que contienen más de 100.000 usuarios o una conectividad inferior a 28,8 Kbps. Los valores de la tabla siguiente se basan en el tráfico de replicación que se genera en un entorno con las siguientes características:

Cada año se une al bosque un 20% de nuevos usuarios.

Cada año deja el bosque un 15% de usuarios.

Cada usuario es miembro de cinco grupos globales y cinco grupos universales.

La relación entre usuarios y equipos es de 1:1.

Se usa el Sistema de nombres de dominio (DNS) integrado en Active Directory®.

Se usa la eliminación de DNS.

Nota

Las cifras indicadas en la tabla siguiente son aproximaciones. La cantidad de tráfico de replicación depende en gran medida en el número de cambios realizados en el directorio en un tiempo determinado. Confirme que la red puede dar cabida al tráfico de replicación comprobando en un laboratorio la cantidad y frecuencia estimadas de los cambios en el diseño antes de implementar los dominios.

Vínculo de menor velocidad que conecta un controlador de dominio (Kbps)

Número máximo de usuarios si se dispone de un 1% de ancho de banda



28.8 10,000 25,000 40,000

32 10,000 25,000 50,000

56 10,000 50,000 100,000

64 10,000 50,000 100,000

128 25,000 100,000 100,000

256 50,000 100,000 100,000

512 80,000 100,000 100,000

1,500 100,000 100,000 100,000

Para usar esta tabla:

1. En la columna Vínculo de menor velocidad que conecta un controlador de dominio, busque

el valor que coincida con la velocidad del vínculo más lento a través del cual AD DS se replicará en

el dominio.

2. En la fila correspondiente a la velocidad del vínculo más lento, busque la columna que representa el

porcentaje de ancho de banda que desea asignar a AD DS. El valor en dicha ubicación es el número

máximo de usuarios que puede contener el dominio de un bosque de un único dominio.

Si determina que el número total de usuarios del bosque es inferior al número máximo de usuarios que puede contener el dominio, puede usar un dominio único. Asegúrese de tener en cuenta el crecimiento futuro planeado al tomar esta decisión. Si determina que el número total de usuarios del bosque es superior al número máximo de usuarios que puede contener el dominio, necesitará reservar un porcentaje mayor de ancho de banda para la replicación, aumentar la velocidad del vínculo o dividir la organización en dominios regionales.

División de la organización en dominios regionales

Si no puede incluir a todos los usuarios en un único dominio, deberá seleccionar el modelo de dominio regional. Divida la organización en regiones de una manera que tenga sentido para la misma y para la red existente. Por ejemplo, podría crear regiones basadas en límites continentales.

Tenga en cuenta que, puesto que necesita crear un dominio de Active Directory para cada región que establezca, es recomendable minimizar el número de regiones que se van a definir para AD DS. Si bien es posible incluir un número ilimitado de dominios en un bosque, para facilitar la administración se recomienda que un boque no contenga más de 10 dominios. Al dividir la organización en dominios regionales deberá alcanzar el adecuado equilibrio entre optimizar el ancho de banda de replicación y minimizar la complejidad administrativa.

En primer lugar, determine el número máximo de usuarios que puede hospedar el bosque. Base esta decisión en el vínculo más lento del bosque a través del cual se replicarán los controladores de dominio y en la cantidad media de ancho de banda que desea asignar a la replicación de Active Directory. En la siguiente tabla se indica el número máximo recomendado de usuarios que puede contener un bosque. Este número se basa en la velocidad del vínculo más lento y en el porcentaje de ancho de banda que se desea reservar para la replicación. Esta información se aplica a bosques que contienen un máximo de 100.000 usuarios y una conectividad igual o superior a 28,8 Kbps. Los valores de la tabla se basan en las siguientes suposiciones:

Todos los controladores de dominio son servidores de catálogo global.


Cada año deja al bosque un 15% de usuarios.

Los usuarios son miembros de cinco grupos globales y cinco grupos universales.


Se usa DNS integrado en Active Directory.


Nota






28.8 10,000 50,000 75,000

32 10,000 50,000 75,000

56 10,000 75,000 100,000

64 25,000 75,000 100,000

128 50,000 100,000 100,000

256 75,000 100,000 100,000

512 100,000 100,000 100,000

1,500 100,000 100,000 100,000




el bosque.


porcentaje de ancho de banda que desea asignar a AD DS. El valor que aparece ahí es el número

máximo de usuarios que el bosque puede hospedar.

Si el número máximo de usuarios que el bosque puede hospedar es superior al número de usuarios que necesita hospedar, un único bosque funcionará para su diseño. Si necesita hospedar más usuarios que el número máximo identificado, necesita aumentar la velocidad mínima del vínculo, asignar un mayor porcentaje de ancho de banda para AD DS o implementar bosques adicionales.

Si determina que un único bosque dará cabida al número de usuarios que necesita hospedar, el siguiente paso es determinar el número máximo de usuarios que puede admitir cada región basándose en el vínculo más lento de dicha región. Divida los bosques en regiones que tengan sentido desde su punto de vista. Asegúrese de que su decisión se basa en factores que no es probable que cambien. Por ejemplo, use continentes en lugar de regiones de ventas. Estas regiones serán la base de la estructura del dominio cuando haya identificado el número máximo de usuarios.

Determine el número de usuarios que necesita hospedar en cada región y, a continuación, compruebe que no sobrepasa el máximo permitido conforme a la velocidad del vínculo más lento y el ancho de banda asignado a AD DS en dicha región. En la siguiente tabla se indica el número máximo recomendado de usuarios que puede contener un dominio regional. Este número se basa en la velocidad del vínculo más lento y en el porcentaje de ancho de banda que se desea reservar para la replicación. Esta información se aplica a bosques que contienen un máximo de 100.000 usuarios y una conectividad igual o superior a 28,8 Kbps. Los valores de la tabla se basan en las siguientes suposiciones:

Todos los controladores de dominio son servidores de catálogo global.


Cada año deja al bosque un 15% de usuarios.

Los usuarios son miembros de cinco grupos globales y cinco grupos universales.


Se usa DNS integrado en Active Directory.


Nota






28.8 10,000 18,000 40,000

32 10,000 20,000 50,000

56 10,000 40,000 100,000

64 10,000 50,000 100,000

128 15,000 100,000 100,000

256 30,000 100,000 100,000

512 80,000 100,000 100,000

1,500 100,000 100,000 100,000




la región.


porcentaje de ancho de banda que desea asignar a AD DS. Ese valor representa el número máximo

de usuarios que la región puede hospedar.

Evalúe cada una de las regiones propuestas y determine si el número máximo de usuarios de cada región es inferior al número máximo recomendado de usuarios que puede contener un dominio. Si determina que la región puede hospedar el número de usuarios que necesita, puede crear un dominio para dicha región. Si determina que no puede hospedar a tantos usuarios, considere la posibilidad de dividir el diseño en regiones más pequeñas y vuelva a calcular el número máximo de usuarios que se puede hospedar en cada una. Las otras alternativas son asignar más ancho de banda o aumentar la velocidad del vínculo.

Si bien el número total de usuarios que se puede incluir en un dominio de un bosque con varios dominios es menor que el número de usuarios del dominio de un bosque de dominio único, el número global de usuarios de un bosque con varios dominios puede ser más elevado. El número más pequeño de usuarios por dominio de un bosque con varios dominios se adapta a la sobrecarga de replicación adicional que se crea al mantener el catálogo global en dicho entorno. Consulte a un diseñador de Active Directory experimentado para que le indique las recomendaciones aplicables a los bosques que contienen más de 100.000 usuarios o una conectividad inferior a 28,8 Kbps.

Documentación de las regiones identificadas

Una vez dividida la organización en dominios regionales, documente las regiones que desea que estén representadas y el número de usuarios que habrá en cada una. Además, anote la velocidad de los vínculos más lentos de cada región que se usarán para la replicación de Active Directory. Esta información se usa para determinar si son necesarios dominios o bosques adicionales.

Para ver una hoja de trabajo que le ayude a documentar las regiones identificadas, descargue Job_Aids_Designing_and_Deploying_Directory_and_Security_Services.zip de Job Aids del Kit de implementación de Windows Server 2003 en http://go.microsoft.com/fwlink/?LinkID=102558 (puede estar en inglés) y abra "Identifying Regions" (DSSLOGI_4.doc).

Determinación de si hay que actualizar los dominios existentes o

implementar otros nuevos

Determinación de si hay que actualizar los dominios existentes o implementar otros nuevosActualizado: abril de 2008


Los dominios del diseño pueden ser dominios nuevos o actualizaciones de dominios existentes. Los usuarios de dominios existentes que no actualice deberán moverse a dominios nuevos.

Mover cuentas de un dominio a otro puede afectar a los usuarios finales. Antes de elegir entre mover los usuarios a un dominio nuevo o actualizar los dominios existentes, evalúe las ventajas administrativas a largo plazo de contar con un dominio de AD DS nuevo frente a los costos de mover a los usuarios al dominio.


Para obtener más información sobre la actualización de dominios de Active Directory a Windows Server 2008, consulte el tema que trata acerca de la actualización de dominios de AD DS a Windows Server 2008 en http://go.microsoft.com/fwlink/?LinkId=89032.

Para obtener más información acerca de la reestructuración de los dominios de AD DS dentro de los bosques y entre bosques, consulte la guía de migración de la herramienta de migración de Active Directory versión 3.1 en http://go.microsoft.com/fwlink/?LinkId=82740 (puede estar en inglés).

Para ver una hoja de trabajo que le ayude a documentar los planes de dominios nuevos y actualizados, descargue Job_Aids_Designing_and_Deploying_Directory_and_Security_Services.zip de Job Aids del Kit de implementación de Windows Server 2003 en http://go.microsoft.com/fwlink/?LinkID=102558 (puede estar en inglés) y abra "Domain Planning" (DSSLOGI_5.doc).

Asignación de nombres de dominio

Asignación de nombres de dominio

Actualizado: agosto de 2009


Debe asignarse un nombre a cada dominio del plan. Los dominios de Servicios de dominio de Active Directory (AD DS) tienen dos tipos de nombres: nombres DNS (Sistema de nombres de dominio) y nombres NetBIOS. En general, los usuarios finales pueden ver ambos nombres. Los nombres DNS de los dominios de Active Directory constan de dos partes: un prefijo y un sufijo. Al crear nombres de dominio hay que determinar primero el prefijo DNS. Se trata de la primera etiqueta en el nombre DNS del dominio. El sufijo se determina al seleccionar el nombre del dominio raíz del bosque. En la siguiente tabla se detallan las reglas de nomenclatura de prefijos para nombres DNS.

Regla Explicación

Seleccione un prefijo que no tenga probabilidades de quedarse obsoleto.

Evite nombres como los de una línea de productos o un sistema operativo que pudieran cambiar en el futuro. Se recomienda usar nombres geográficos.

Seleccione un prefijo que incluya únicamente caracteres estándar de Internet.

A-Z, a-z, 0-9 y (-), pero no enteramente numérico.

Incluya 15 caracteres o menos en el prefijo.

Si elige un prefijo de longitud igual o inferior a 15 caracteres, el nombre NetBIOS será igual al prefijo.

Para obtener más información, consulte todo lo relativo a las convenciones de nomenclatura de Active Directory para equipos, dominios, sitios y unidades organizativas (OU) en http://go.microsoft.com/fwlink/?LinkId=106629 (puede estar en inglés).

Si el nombre NetBIOS actual del dominio no es adecuado para representar la región o no satisface las reglas de nomenclatura de prefijos, seleccione otro prefijo. En este caso, el nombre NetBIOS del dominio será diferente al prefijo DNS del dominio.

Para cada dominio nuevo que implemente, seleccione un prefijo que sea apropiado a la región y que satisfaga las reglas de nomenclatura de prefijos. Se recomienda que el nombre NetBIOS del dominio sea el mismo que el prefijo DNS.

Documente el prefijo DNS y los nombres NetBIOS que seleccione para cada dominio del bosque. Puede agregar la información del nombre NetBIOS y DNS a la hoja de trabajo "Domain Planning" que creó para documentar el plan de los dominios nuevos y actualizados. Para abrirla, descargue


Job_Aids_Designing_and_Deploying_Directory_and_Security_Services.zip de Job Aids del Kit de implementación de Windows Server 2003 en http://go.microsoft.com/fwlink/?LinkID=102558 (puede estar en inglés) y abra "Domain Planning" (DSSLOGI_5.doc).

Selección del dominio raíz del bosque

Selección del dominio raíz del bosque



El primer dominio que se implementa en un bosque de Active Directory se denomina dominio raíz del bosque. Este dominio permanece como dominio raíz del bosque durante el ciclo de vida de la implementación de AD DS.

El dominio raíz del bosque contiene los grupos Administradores de organización y Administradores de esquema. Estos grupos de administradores de servicios se usan para administrar operaciones en el nivel del bosque, como la adición o eliminación de dominios y la implementación de cambios en el esquema.

Seleccionar el dominio raíz del bosque implica determinar si uno de los dominios de Active Directory del diseño puede funcionar como dominio raíz del bosque o si es necesario implementar uno dedicado.

Para obtener información sobre la implementación de un dominio raíz del bosque, consulte el tema que trata acerca de la implementación de un dominio raíz del bosque de Windows Server 2008 en http://go.microsoft.com/fwlink/?LinkId=89028 (puede estar en inglés).

Elección de un dominio raíz del bosque dedicado o regional

Si se aplica un modelo de dominio único, éste funcionará como dominio raíz del bosque. Si se aplica un modelo de dominio múltiple, es posible elegir entre implementar un dominio raíz del bosque dedicado o seleccionar un dominio regional para que funcione como dominio raíz del bosque.

Dominio raíz del bosque dedicadoUn dominio raíz del bosque dedicado es un dominio que se crea específicamente para funcionar como raíz del bosque. No contiene ninguna cuenta de usuario que no sean las cuentas del administrador del servicio para el dominio raíz del bosque. Además, no representa a ninguna región en la estructura de dominios. Todos los demás dominios del bosque son dominios secundarios del dominio raíz del bosque dedicado.

Usar una raíz del bosque dedicada ofrece las siguientes ventajas:

Separación operativa de los administradores de servicios del bosque de los administradores de

servicios del dominio. En un entorno de dominio único, los miembros de los grupos Administradores

del dominio y Administradores integrado pueden usar procedimientos y herramientas estándar para

convertirse a sí mismos en miembros de los grupos Administradores de organización y

Administradores de esquema. En un bosque que usa un dominio raíz del bosque dedicado, los

miembros de los grupos Administradores del dominio y Administradores integrado de los dominios

regionales no se pueden convertir en miembros de los grupos de administradores de servicios del

nivel del bosque usando procedimientos y herramientas estándar.

Protección frente a cambios operativos en otros dominios. Un dominio raíz del bosque dedicado no

representa a ninguna región concreta en la estructura del dominio. Por este motivo, no se ve

afectado por reorganizaciones u otros cambios que den lugar al cambio de nombre o

reestructuración de los dominios.



Funciona como raíz neutral, por lo que ninguna región aparece subordinada a otra. Algunas

organizaciones podrían preferir evitar que un país o región aparecieran subordinados a otros en el

espacio de nombres. Cuando se usa un dominio raíz del bosque dedicado, todos los dominios

regionales pueden encontrarse en el mismo nivel dentro de la jerarquía del dominio.

En un entorno de dominio regional múltiple en el que se usa una raíz del bosque dedicada, la replicación del dominio raíz del bosque tiene una repercusión mínima sobre la infraestructura de red. Esto es así porque la raíz del bosque sólo alberga cuentas de administradores de servicios. La mayoría de las cuentas de usuario del bosque y otros datos específicos del dominio se almacenan en los dominios regionales.

Una desventaja de usar un dominio raíz del bosque dedicado es que crea más carga administrativa para admitir el dominio adicional.

Dominio regional como dominio raíz del bosqueSi elige no implementar un dominio raíz del bosque dedicado, deberá seleccionar un dominio regional para que funcione como el dominio raíz del bosque. Este dominio es el dominio principal de todos los demás dominios regionales y será el primer dominio que implemente. El dominio raíz del bosque contiene cuentas de usuario y se administra de la misma manera que los demás dominios regionales. La diferencia principal es que incluye también los grupos Administradores de organización y Administradores de esquema.

La ventaja de seleccionar un dominio regional para que funcione como el dominio raíz del bosque es que no crea la carga administrativa adicional que conlleva mantener un dominio adicional. Seleccione un dominio regional adecuado para que sea la raíz del bosque, como el dominio que representa a sus oficinas centrales o la región que tiene las conexiones de red más rápidas. Si a su organización le resulta difícil seleccionar un dominio regional para que sea el dominio raíz del bosque, puede elegir en su lugar usar un modelo de raíz del bosque dedicado.

Asignación del nombre del dominio raíz del bosque

El nombre del dominio raíz del bosque es también el nombre del bosque. El nombre de la raíz del bosque es un nombre del Sistema de nombres de dominio (DNS) que se compone de un prefijo y de un sufijo con el formato prefijo.sufijo. Por ejemplo, una organización podría tener el nombre de raíz del bosque corp.contoso.com, donde "corp" es el prefijo y "contoso.com", el sufijo.

Seleccione el sufijo de una lista de nombres existente en la red. Para el prefijo, seleccione un nombre nuevo que no se haya usado en la red con anterioridad. Agregando un prefijo nuevo a un sufijo existente se crea un espacio de nombres único. La creación de un espacio de nombres nuevo para los Servicios de dominio de Active Directory (AD DS) garantiza que cualquier infraestructura DNS existente no tenga que modificarse para acomodar a AD DS.

Selección de un sufijoPara seleccionar un sufijo para el dominio raíz del bosque:

1. Póngase en contacto con el propietario de DNS de la organización para obtener una lista de los

sufijos de DNS registrados que se usan en la red que albergará a AD DS. Tenga en cuenta que los

sufijos usados en la red interna pueden ser diferentes de los que se usan externamente. Por

ejemplo, una organización podría usar contosopharma.com en Internet y contoso.com en la red

corporativa interna.

2. Consulte al propietario de DNS para seleccionar un sufijo que se pueda usar con AD DS. Si no

existen sufijos adecuados, registre un nombre nuevo en una entidad de nomenclatura de Internet.

Se recomienda usar nombres DNS que estén registrados en una entidad de Internet en el espacio de nombres de Active Directory. Sólo los nombres registrados tienen garantías de ser únicos globalmente. Si otra organización registra posteriormente el mismo nombre de dominio DNS (o si su organización se fusiona con, adquiere o es adquirida por otra empresa que usa el mismo nombre DNS), las dos infraestructuras no podrán interactuar entre sí.

Precaución

No use nombres DNS de etiqueta única. Para obtener más información, consulte todo lo relativo a la configuración de Windows para dominios con nombres DNS de etiqueta única en http://go.microsoft.com/fwlink/?LinkId=106631 (puede estar en inglés). Tampoco se recomienda usar sufijos no registrados, como .local.

Selección de un prefijoSi elige un sufijo registrado que ya se esté usando en la red, seleccione un prefijo para el nombre del dominio raíz del bosque usando las reglas para prefijos de la tabla siguiente. Agregue un prefijo que no se encuentre en uso actualmente para crear un nuevo nombre subordinado. Por ejemplo, si el nombre raíz de DNS es contoso.com, puede crear el nombre del dominio raíz del bosque de Active Directory concorp.contoso.com, siempre que el espacio de nombres concorp.contoso.com no se esté usando ya en la red. Esta nueva rama del espacio de nombres estará dedicará a AD DS y puede integrarse fácilmente con la implementación de DNS existente.

Si ha seleccionado un dominio regional para que funcione como dominio raíz del bosque, podría ser necesario seleccionar un nuevo prefijo para el dominio. Puesto que el nombre del dominio raíz del bosque afecta a todos los demás nombres de dominio del bosque, un nombre basado en una región podría no ser adecuado. Si usa un sufijo nuevo que no se está usando actualmente en la red, puede utilizarlo como nombre del dominio raíz del bosque sin elegir ningún prefijo adicional.

En la siguiente tabla se enumeran las reglas de selección de prefijos para nombres DNS registrados.

Regla Explicación

Seleccione un prefijo que no tenga probabilidades de quedarse obsoleto.

Evite nombres como los de una línea de productos o un sistema operativo que pudieran cambiar en el futuro. Se recomienda usar nombres genéricos, como corp o ds.

Seleccione un prefijo que incluya únicamente caracteres estándar de Internet.

A-Z, a-z, 0-9 y (-), pero no sólo números.

Incluya 15 caracteres o menos en el prefijo.

Si elige un prefijo de longitud igual o inferior a 15 caracteres, el nombre NetBIOS será igual al prefijo.

Es importante que el propietario de DNS de Active Directory y el propietario de DNS trabajen juntos para que la organización obtenga la propiedad del nombre que se usará para el espacio de nombres de Active Directory. Para obtener más información sobre cómo diseñar una infraestructura de DNS para admitir AD DS, consulte Creación del diseño de una infraestructura DNS.

Documentar el nombre del dominio raíz del bosque

Documente el sufijo y el prefijo de DNS seleccionados para el dominio raíz del bosque. Llegados a este punto, identifique el dominio que será la raíz del bosque. Puede agregar la información del nombre del dominio raíz del bosque a la hoja de trabajo "Domain Planning" que creó para documentar el plan de los dominios nuevos y actualizados y los nombres de dominio. Para abrirla, descargue Job_Aids_Designing_and_Deploying_Directory_and_Security_Services.zip de Job Aids del Kit de implementación de Windows Server 2003 en http://go.microsoft.com/fwlink/?LinkID=102558 (puede estar en inglés) y abra "Domain Planning" (DSSLOGI_5.doc).


http://technet.microsoft.com/es-mx/library/cc725625(WS.10).aspx


Creación del diseño de una infraestructura DNSActualizado: abril de 2008


Una vez creados los diseños del dominio y el bosque de Active Directory, es preciso diseñar una infraestructura de Sistema de nombres de dominio (DNS) que sea compatible con la estructura lógica de Active Directory. DNS permite a los usuarios usar nombres descriptivos fáciles de recordar para conectarse a los equipos y otros recursos de las redes IP. Los Servicios de dominio de Active Directory (AD DS) de Windows Server 2008 requieren DNS.

El proceso para diseñar un DNS que admita AD DS varía dependiendo de si en la organización existe ya un servicio Servidor DNS o si se está implementando un nuevo servicio Servidor DNS:

Si ya existe una infraestructura DNS, se debe integrar el espacio de nombres de Active Directory en

ese entorno. Para obtener más información, consulte Integración de AD DS en una infraestructura

DNS existente.

Si no tiene una infraestructura DNS, debe diseñar e implementar una nueva infraestructura DNS

para que sea compatible con AD DS. Para obtener más información, consulte el tema que trata

acerca de la implementación del Sistema de nombres de dominio (DNS) en

http://go.microsoft.com/fwlink/?LinkId=93656 (puede estar en inglés).

Si en la organización ya existe una infraestructura DNS, debe asegurarse de que comprende la forma en que ésta interactuará con el espacio de nombres de Active Directory. Para ver una hoja de trabajo que le ayude a documentar el diseño de la infraestructura DNS existente, descargue Job_Aids_Designing_and_Deploying_Directory_and_Security_Services.zip de Job Aids del Kit de implementación de Windows Server 2003 en http://go.microsoft.com/fwlink/?LinkID=102558 (puede estar en inglés) y abra "DNS Inventory" (DSSLOGI_8.doc).

Nota

Además de con las direcciones IP versión 4 (IPv4), Windows Server 2008 es compatible también con las direcciones IP versión 6 (IPv6). Para ver una hoja de trabajo que le ayude a realizar una lista de las direcciones IPv6 mientras documenta el método de resolución de nombres recursivos de la estructura DNS actual, consulte Apéndice A: Inventario de DNS.

Antes de diseñar la infraestructura DNS compatible con AD DS, puede ser útil leer información acerca de la jerarquía de DNS, el proceso de resolución de nombres de DNS y la compatibilidad de DNS con AD DS. Para obtener más información acerca del proceso de resolución de nombres y la jerarquía de DNS, consulte la referencia técnica de DNS en http://go.microsoft.com/fwlink/?LinkID=48145 (puede estar en inglés). Para obtener más información acerca de la compatibilidad de DNS y AD DS, consulte la referencia técnica de compatibilidad entre DNS y AD DS en http://go.microsoft.com/fwlink/?LinkID=48147 (puede estar en inglés).

En esta sección

Revisión de los conceptos de DNS

DNS y AD DS

Asignación de DNS para la función de propietario de AD DS

Integración de AD DS en una infraestructura DNS existente

Creación del diseño de una unidad organizativa



Los propietarios del bosque son los responsables de la creación de diseños de unidad organizativa (OU) para sus dominios. Crear un diseño de unidad organizativa implica diseñar la estructura de la unidad organizativa, asignar la función de propietario de la misma y crear unidades organizativas de recursos y cuentas.

En principio, diseñe la estructura de la unidad organizativa para habilitar la delegación de las tareas administrativas. Cuando haya terminado el diseño de la unidad organizativa, puede crear estructuras de unidad organizativa adicionales para aplicar la directiva de grupo a los usuarios y equipos y limitar la visibilidad de los objetos. Para obtener más información, consulte lo relativo al diseño de una infraestructura de directiva de grupo en http://go.microsoft.com/fwlink/?LinkId=106655 (puede estar en inglés).

Función de propietario de unidad organizativa

El propietario del bosque designa a un propietario para cada una de las unidades organizativas que diseñe para el dominio. Los propietarios de unidades organizativas son administradores de datos que controlan un subárbol de objetos en Servicios de dominio de Active Directory (AD DS). Los propietarios de las unidades organizativas pueden controlar la forma en que se delega la administración y se aplica la directiva a los objetos de sus unidades organizativas. También pueden crear nuevos subárboles y delegar la administración de las unidades organizativas de los mismos.

Puesto que los propietarios de una unidad organizativa no poseen ni controlan el funcionamiento del servicio de directorio, es posible separar la propiedad y la administración del servicio de directorio de la propiedad y la administración de los objetos, lo que reducirá el número de administradores de servicios que tienen niveles elevados de acceso.

Las unidades organizativas proporcionan autonomía administrativa y los medios para controlar la visibilidad de los objetos del directorio. Las unidades organizativas ofrecen aislamiento respecto de otros administradores de datos, pero no respecto de los administradores de servicios. Si bien los propietarios de una unidad organizativa tienen el control sobre un subárbol de objetos, el propietario del bosque conserva pleno control sobre todos los subárboles. Esto permite al propietario del bosque corregir errores, como un error en una lista de control de acceso (ACL), y recuperar subárboles delegados cuando los administradores de datos finalicen.

Unidades organizativas de recursos y de cuentas

Las unidades organizativas de cuentas contienen objetos de usuario, grupo y equipo. Los propietarios del bosque deben crear una estructura de unidad organizativa para administrar estos objetos y, a continuación, delegar el control de la estructura al propietario de la unidad organizativa. Si está implementando un nuevo dominio de AD DS, cree una unidad organizativa de cuenta para el dominio a fin de poder delegar el control de las cuentas del dominio.

Las unidades organizativas de recursos contienen recursos y las cuentas que son responsables de administrar dichos recursos. El propietario del bosque es responsable también de crear una estructura de unidad organizativa para administrar esos recursos y para delegar el control de dicha estructura en el propietario de la unidad organizativa. Cree las unidades organizativas de recursos que sean necesarias de acuerdo con los requisitos de cada grupo de la organización en materia de autonomía para la administración de datos y equipos.

Documentar el diseño de la unidad organizativa para cada dominio

Forme un equipo para diseñar la estructura de la unidad organizativa que usará para delegar el control sobre los recursos del bosque. El propietario del bosque podría intervenir en el proceso de diseño y deberá aprobar el diseño de la unidad organizativa. También podría implicar al menos a un administrador de servicios a fin de garantizar que el diseño sea válido. Entre los participantes en el equipo de diseño podría incluirse a los administradores de datos que trabajarán en las unidades organizativas y a los propietarios de las unidades organizativas que serán responsables de administrarlas.

Es importante documentar el diseño de la unidad organizativa. Haga una lista con los nombres de las unidades organizativas que planea crear. Y, para cada unidad organizativa, documente el tipo, propietario y origen de la unidad organizativa, así como la unidad organizativa principal (si procede).

Para ver una hoja de trabajo que le ayude a documentar el diseño de la unidad organizativa, descargue Job_Aids_Designing_and_Deploying_Directory_and_Security_Services.zip de Job Aids del Kit de implementación de Windows Server 2003 en http://go.microsoft.com/fwlink/?LinkID=102558 (puede estar en inglés) y abra "Identifying OUs for Each Domain" (DSSLOGI_9.doc).

En esta sección

Revisión de los conceptos de diseño de la unidad organizativa

Revisión de los conceptos de diseño de la unidad organizativaActualizado: abril de 2008


La estructura de una unidad organizativa (OU) para un dominio incluye lo siguiente:

Un diagrama de la jerarquía de la unidad organizativa

Una lista de unidades organizativas

Para cada unidad organizativa:

La finalidad de la unidad organizativa

Una lista de usuarios o grupos que tienen control sobre la unidad organizativa o los objetos de la

misma

El tipo de control que los usuarios y grupos tienen sobre los objetos de la unidad organizativa

La jerarquía de la unidad organizativa no tiene por qué reflejar la jerarquía de los departamentos de la organización o grupo. Las unidades organizativas se crean para una finalidad específica, como la delegación de tareas de administración o la aplicación de una directiva de grupo, o bien para limitar la visibilidad de los objetos.

Es posible diseñar una estructura de unidad organizativa propia con el fin de delegar la administración en individuos o grupos de la organización que requieran autonomía para administrar sus propios datos y recursos. Las unidades organizativas representan límites administrativos y permiten controlar el ámbito de autoridad de los administradores de datos.

Por ejemplo, puede crearse una unidad organizativa denominada OURecursos y usarla para almacenar todas las cuentas del equipo que pertenecen a los servidores de impresión y archivo administrados por un grupo. Posteriormente es posible configurar la seguridad de la unidad organizativa para que sólo los administradores del grupo tengan acceso a la misma. De esta manera se impide que los administradores de datos de otros grupos manipulen las cuentas del servidor de impresión y archivo.

La estructura de la unidad organizativa puede refinarse aun más mediante la creación de subárboles de unidades organizativas para fines concretos, como la aplicación de una directiva de grupo, o para limitar la visibilidad de los objetos protegidos de manera que sólo puedan verlos usuarios determinados. Por ejemplo, si necesita aplicar una directiva de grupo a un grupo seleccionado de usuarios o recursos, puede agregar dichos usuarios o recursos a una unidad organizativa y, a continuación, aplicarle a la misma la citada directiva de grupo. También se puede usar la jerarquía de la unidad organizativa para habilitar una mayor delegación del control administrativo.

Si bien, desde el punto de vista técnico, no existe límite en el número de niveles que puede tener la estructura de una unidad organizativa, por razones de capacidad de administración se recomienda que no supere los 10 niveles. Técnicamente, el número de unidades organizativas de cada nivel no tiene límite. Tenga en cuenta que las aplicaciones habilitadas para Servicios de dominio de Active Directory (AD DS) pueden imponer restricciones al número de caracteres usados en el nombre distintivo, es decir, la ruta LDAP (Protocolo ligero de acceso a directorios) completa al objeto del directorio o al número de niveles de la unidad organizativa dentro de la jerarquía.

No se pretende que la estructura de la unidad organizativa en AD DS sea visible para los usuarios finales. La estructura de la unidad organizativa es una herramienta administrativa para los administradores de datos y del servicios, y es fácil cambiarla. Siga revisando y actualizando el diseño de la estructura de la unidad

organizativa para reflejar los cambios en la estructura administrativa y admitir la administración basada en directiva.

Delegación de la administración mediante objetos de unidad organizativa

Delegación de la administración mediante objetos de unidad organizativaActualizado: abril de 2008


Las unidades organizativas pueden usarse para delegar la administración de los objetos, como usuarios o equipos, de la unidad organizativa en el individuo o grupo que se haya designado. Para delegar la administración usando una unidad organizativa, coloque al individuo o grupo en el que desee delegar los derechos administrativos dentro de un grupo, coloque el conjunto de objetos que desee controlar dentro de una unidad organizativa y, a continuación, delegue las tareas administrativas de la unidad organizativa a dicho grupo.

Servicios de dominio de Active Directory (AD DS) permite controlar las tareas administrativas que pueden delegarse en un nivel muy detallado. Por ejemplo, es posible asignar a un grupo el control total de todos los objetos de una unidad organizativa, asignar a otro grupo únicamente los derechos para crear, eliminar y administrar cuentas de usuario dentro de la unidad organizativa y, finalmente, asignar a un tercer grupo el derecho a restablecer contraseñas de cuentas de usuario. Estos permisos pueden hacerse heredables de manera que se apliquen a cualquier unidad organizativa que se coloque en subárboles de la unidad organizativa original.

Durante la instalación de AD DS se crean contenedores y unidades organizativas predeterminadas que controlan los administradores del servicio. Lo mejor es que los administradores del servicio sigan controlando dichos contenedores. Si es preciso delegar el control sobre los objetos del directorio, cree unidades organizativas adicionales y coloque en ellas dichos objetos. Delegue el control sobre dichas unidades organizativas en los administradores de datos apropiados. Ello hace posible delegar el control sobre los objetos del directorio sin cambiar el control predeterminado concedido a los administradores del servicio.

El propietario del bosque determina el nivel de autoridad que se delega al propietario de una unidad organizativa. Dicha autoridad puede oscilar entre la capacidad para crear y manipular objetos dentro de la unidad organizativa a tener únicamente el control sobre un solo atributo de un único tipo de objeto en la unidad organizativa. Conceder a un usuario la capacidad de crear un objeto en la unidad organizativa implica otorgar a dicho usuario la capacidad de manipular cualquier atributo de cualquier objeto creado por el usuario. Además, si el objeto que se crea es un contenedor, el usuario tiene la capacidad implícita de crear y manipular cualquier objeto que se coloque en el contenedor.

En esta sección

Delegación de la administración de unidades organizativas (OU) y contenedores predeterminados

Delegación de la administración de unidades organizativas (OU) y contenedores predeterminados



Todos los dominios de Active Directory contienen un conjunto estándar de contenedores y unidades organizativas (OU) que se crean durante la instalación de los Servicios de dominio de Active Directory (AD DS). A continuación se enumeran algunas:

Contenedor de dominio, que sirve de contenedor raíz para la jerarquía

Contenedor integrado, que tiene las cuentas de administrador de servicios predeterminadas

Contenedor de usuarios, que la ubicación predeterminada para las nuevas cuentas de usuario y

grupos creados en el dominio

Contenedor de equipos, que la ubicación predeterminada para las nuevas cuentas de equipo

creados en el dominio

Unidad organizativa (OU) Controladores de dominio, que es la ubicación predeterminada para las

cuentas de equipo de las cuentas de equipo de controladores de dominio

El propietario del bosque controla estas unidades organizativas y contenedores predeterminados.

Contenedor de dominio

El contenedor de dominio es el contenedor raíz de la jerarquía de un dominio. Los cambios que se realicen en las directivas o la lista de control de acceso (ACL) de este contenedor pueden repercutir en todo el dominio. No delegue el control de este contenedor, que debe estar en manos de los administradores de servicios.

Contenedores de equipos y usuarios

Cuando realice una actualización del dominio en vigor desde Windows Server 2003 a Windows Server 2008, los equipos y usuarios existentes se colocan automáticamente en los contenedores de equipos y de usuarios. Si está creando un nuevo dominio de Active Directory, los contenedores de equipos y de usuarios son las ubicaciones predeterminadas para todas las nuevas cuentas de usuario y cuentas de equipo que no sean de controlador de dominio del dominio.

Importante

Si necesita delegar el control sobre los usuarios o equipos, no modifique la configuración predeterminada de los contenedores de equipos y usuarios. En lugar de ello, cree una nueva unidad organizativa (en caso necesario) y mueva los objetos de equipo y de usuario desde sus contenedores predeterminados a las nuevas unidades organizativas (OU). Delegue el control sobre las nuevas unidades organizativas, en caso necesario. Se recomienda no modificar quién controla los contenedores predeterminados.

Tampoco pueden aplicarse las opciones de la directiva de grupo a los contenedores de equipos y usuarios predeterminados. Para aplicar la directiva de grupo a los usuarios y equipos, cree nuevas unidades organizativas y mueva los objetos de equipo y usuario a las mismas. Aplique las opciones de la directiva de grupo a las nuevas unidades organizativas.

Si lo desea, también puede redirigir la creación de los objetos que se colocan en los contenedores predeterminados para que se sitúen en los contenedores de su elección.

Grupos y usuarios conocidos y cuentas integradas

De manera predeterminada, en un nuevo dominio se crean varios grupos y usuarios conocidos y cuentas integradas. Se recomienda que la administración de estas cuentas permanezca bajo el control de los administradores de servicios. No delegue la administración de estas cuentas a una persona que no sea un administrador de servicios. En la tabla siguiente se enumeran los grupos y usuarios conocidos y las cuentas integradas que necesitan permanecer bajo el control de los administradores de servicios.

Grupos y usuarios conocidos Cuentas integradas

Publicadores de certificados Administrador

Controlador de dominio

Propietarios del creador de directivas de grupo

KRBTGT

Invitados de dominio

Administrador

Admins. del dominio

Administradores de esquema (sólo dominio raíz del bosque)

Administradores de organización (sólo dominio raíz del bosque)

Usuarios del dominio

Invitado

Invitados

Operadores de cuentas

Administradores

Operadores de copia de seguridad

Creadores de confianza de bosque de entrada

Operadores de impresión

Acceso compatible con versiones anteriores a Windows 2000

Operadores de servidores

Usuarios

Unidad organizativa Controlador de dominio

Cuando se agregan al dominio controladores de dominio, los objetos de sus equipos se agregan automáticamente a la unidad organizativa Controlador de dominio. Esta unidad organizativa tiene aplicadas un conjunto de directivas predeterminadas. Para garantizar que estas directivas se apliquen uniformemente a todos los controladores de dominio, se recomienda no mover los objetos de equipo de los controladores de dominio fuera de esta unidad organizativa. Si las directivas predeterminadas no se aplican, el controlador de dominio podría no funcionar adecuadamente.

De manera predeterminada, los administradores de servicios controlan esta unidad organizativa. No delegue el control de esta unidad organizativa a personas que no sean administradores de servicios.

Delegación de la administración de unidades organizativas de recursos y cuentas

Delegación de la administración de unidades organizativas de recursos y cuentas



Las unidades organizativas de cuentas contienen objetos de usuario, grupo y equipo. Las unidades organizativas de recursos contienen recursos y las cuentas que son responsables de administrar dichos recursos. El propietario del bosque es responsable de crear una estructura de unidad organizativa para administrar esos objetos y recursos y para delegar el control de dicha estructura en el propietario de la unidad organizativa.

Delegación de la administración de unidades organizativas de cuentas Delegue una estructura de unidad organizativa de cuenta en los administradores de datos si

necesitan crear y modificar objetos de usuario, grupo y equipo. La estructura de unidad organizativa de cuenta es un subárbol de unidades organizativas para cada tipo de cuenta que debe controlarse independientemente. Por ejemplo, el propietario de la unidad organizativa puede delegar un control específico en varios administradores de datos a través de unidades organizativas secundarias en una unidad organizativa de cuenta para usuarios, equipos, grupos y cuentas de servicio.

En la siguiente ilustración se muestra un ejemplo de una estructura de unidad organizativa de

cuenta.

En la siguiente tabla se enumeran y describen las posibles unidades organizativas secundarias que

se pueden crear en una estructura de unidad organizativa de cuenta.

OU Propósito

Usuarios Contiene cuentas de usuario para personal no administrativo.

Cuentas de servicio

Algunos servicios que requieren acceso a los recursos de red se ejecutan como cuentas de usuario. Esta unidad organizativa se crea para separar las cuentas de usuarios de servicios de las cuentas de usuario incluidas en la unidad organizativa de los usuarios. Así mismo, colocar los distintos tipos de cuentas de usuario en unidades organizativas independientes permite administrarlas conforme a sus requisitos administrativos específicos.

Equipos Contiene cuentas para equipos que no sean controladores de dominio.

Grupos Contiene grupos de todos los tipos, salvo grupos administrativos, que se administran por separado.

Admins Contiene cuentas de grupo y usuario para los administradores de datos de la estructura de la unidad organizativa de cuenta, a fin de poder administrarlos de forma independiente a los usuarios regulares. Habilite la auditoría para esta unidad organizativa con el fin de que pueda realizar un seguimiento de los cambios en los grupos y usuarios administrativos.

En la siguiente ilustración se muestra un ejemplo de un diseño de grupo administrativo para una

estructura de unidad organizativa de cuenta.

A los grupos que administran las unidades organizativas secundarias se les concede control total

únicamente sobre la clase específica de objetos de cuya administración son responsables.

Los tipos de grupos que se usan para delegar el control dentro de una estructura de unidad

organizativa se basan en la ubicación de las cuentas con respecto a la estructura de unidad organizativa que se va a administrar. Si las cuentas de usuarios administrativos y la estructura de la

unidad organizativa existen en un único dominio, los grupos que se creen para delegación deben ser grupos globales. Si la organización tiene un departamento que administra sus propias cuentas de usuario y está presente en más de una región, podría tener un grupo de administradores de datos responsables de administrar unidades organizativas de cuenta en más de un dominio. Si las cuentas de los administradores de datos existen todas en un dominio único y tiene estructuras de unidades organizativas en varios dominios en los que necesita delegar el control, convierta a dichas cuentas administrativas en miembros de grupos globales y delegue el control de las estructuras de unidad organizativa de cada dominio en dichos grupos globales. Si las cuentas de administradores de datos en las que delegue el control de una estructura de unidad organizativa proceden de varios dominios, debe usar un grupo universal. Los grupos universales pueden contener usuarios de diferentes dominios y, por tanto, se pueden usar para delegar el control en varios dominios.

Delegación de la administración de unidades organizativas de recursos Las unidades organizativas de recursos se usan para administrar el acceso a los recursos. El

propietario de la unidad organizativa de recursos crea cuentas de equipo para los servidores que están unidos al dominio en las que se incluyen recursos como recursos compartidos de archivos, bases de datos e impresoras. El propietario de la unidad organizativa de recursos crea también grupos para controlar el acceso a dichos recursos.

En la siguiente ilustración se muestran las dos posibles ubicaciones para la unidad organizativa de

recursos.

La unidad organizativa de recursos puede encontrarse en la raíz del dominio o como una unidad

organizativa secundaria de la unidad organizativa de cuenta correspondiente en la jerarquía administrativa de la unidad organizativa. Las unidades organizativas de recursos no tienen ninguna unidad organizativa secundaria estándar. Los equipos y grupos se colocan directamente en la unidad organizativa de recursos.

El propietario de la unidad organizativa de recursos posee los objetos de la unidad organizativa,

pero no el contenedor de la unidad organizativa en sí. Los propietarios de unidades organizativas de recursos administran únicamente objetos de grupo y equipo; no pueden crear otras clases de objetos dentro de la unidad organizativa, ni tampoco crear unidades organizativas secundarias.

Nota

El creador o propietario de un objeto tiene la capacidad de definir la lista de control de acceso (ACL) del objeto, con independencia de los permisos que se hereden del contenedor primario. Si el propietario de una unidad organizativa de recursos puede restablecer la ACL de una unidad organizativa, también puede crear cualquier clase de objeto en la unidad organizativa, incluidos usuarios. Por este motivo, los propietarios de unidades organizativas de recursos no tienen permiso para crear unidades organizativas.

Para cada unidad organizativa de recursos del dominio, cree un grupo global que represente a los

administradores de datos responsables de administrar el contenido de la unidad organizativa. Este grupo tiene control total sobre los objetos de equipo y grupo de la unidad organizativa, pero no sobre el contenedor de la unidad organizativa en sí.

En la siguiente ilustración se muestra el diseño de grupo administrativo para una unidad

organizativa de recursos.

Colocar las cuentas de equipo en una unidad organizativa de recursos otorga al propietario de la

misma el control sobre los objetos de cuenta, pero no le convierte en administrador de los equipos. En un dominio de Active Directory, el grupo Admins. del dominio se coloca, de forma predeterminada, en el grupo Administradores local de todos los equipos. Es decir, los administradores de servicios tienen el control sobre dichos equipos. Si los propietarios de unidades

organizativas de recursos requieren el control administrativo sobre los equipos de sus unidades organizativas, el propietario del bosque puede aplicar una directiva de grupo de grupos restringidos para convertir al propietario de la unidad organizativa de recursos en miembro del grupo Administradores en los equipos de dicha unidad organizativa.

WINS y DNS son los servicios de resolución de nombres para TCP / IP. Mientras WINS resuelve nombres en el espacio de nombres NetBIOS, DNS resuelve nombres en el espacio de nombres de dominio DNS. WINS apoya sobre todo los clientes que ejecutan versiones anteriores de Windows y las aplicaciones que utilizan NetBIOS. Windows 2000, Windows XP y Windows Server 2003 utilizan nombres DNS, además de los nombres NetBIOS. Entornos que incluyen algunos equipos que utilizan nombres NetBIOS y otros equipos que utilizan los nombres de dominio deben incluir tanto los servidores WINS y servidores DNS.

es UTF-8 WINS and DNS ar en|es WINS y DNS son

WINS y DNS son los servicios d

Enviar

Diseño de una estructura lógica para AD DS en Windows Server 2008

Documents

Transcript of Diseño de una estructura lógica para AD DS en Windows Server 2008