Mes: febrero 2011

Configurando Sites

En el ejemplo usaré ubicaciones e IPs ficticias, cada sucursal se halla conectada con la oficina principal.

Valencia –> Principal –> 192.168.1.0/24

Gandia -> Sucursal –> 192.168.2.0/24 –> T1

Cullera –> Sucursal –> 192.168.3.0/24 –> T2

Oliva —> Sucursal –> 192.168.4.0/24 –> T3

Un Site

Al crear un sitio hemos de decidir la frecuencia con la que se replicará AD entre sitios. Para ello, tendremos en cuenta también la velocidad de los enlaces. También nos resultará interesante conocer las IP de los servidores que se replicarán para monitorizar el tráfico que se produzca y así estar listos para eventuales problemas.

Lo que necesitamos para la creación de un sitio: un nombre de Site, su subred y los otros Sites que se replicarán con él.

1. Lanzamos Administrador del servidor en un DC.
   
2. Extendemos Roles.
   
3. Extendemos Servicios de Dominio de Active Directory.
   
4. Extendemos Sitios y servicios de Active Directory.
5. Clic derecho en el contenedor Sites y pinchamos en Nuevo Sitio.
   
6. Escribimos el nombre del sitio y seleccionamos cualquier enlace existente de sitio, le damos al Aceptar para crearlo.
   
7. Puede que aparezca una ventana flotante, con las indicaciones de las tareas necesarias para completar la creación del sitio. Leerla, tomar nota si es necesario y le damos a Aceptar.
   

Repetiremos los pasos por cada Sitio que necesite crearse.

Subred de sitio

Después de crear un Site, se lista en la ventana de consola. Para completar el proceso llevaremos a cabo:

1. Dentro de Servicios y Sitios de Active Directory, clic derecho sobre el contenedor de Subnets y pinchamos en Nueva subred.
   
2. Escribimos el prefijo de dirección (no es más que la dirección de red y la máscara de red en notación de prefijo)– por ejemplo: 192.168.1.0/24 de Valencia.
3. Seleccionamos el Sitio apropiado de la lista de abajo para asociarlo con la nueva subred.
4. Le damos a Aceptar para crear la nueva subred.
   

Repetiremos esto para las subredes en cada ubicación.

Añadir DC al sitio

Si se añade un nuevo DC al bosque, se unirá de forma dinámica con el sitio que tenga la subred coincidente, si la topología del sitio ya está configurada y las subredes han sido definidas previamente. Sin embargo, un DC ya existente no cambiará automáticamente de sitio, a diferencia de las estaciones de trabajo y servidores miembro. Un DC ha de moverse manualmente si se cambia la topología. Si un DC ya existente ha de cambiarse a un nuevo Site, o la topología o la estrategia de replicación han cambiado, podemos realizar los siguientes pasos para el cambio a otro Site:

1. Iniciar Administrador del servidor en un DC.
2. Extendemos Roles.
3. Extendemos Servicios de dominio de Active Directory.
4. Extendemos Sitios y servicios de Active Directory.
5. Extendemos Sites.
6. Localizamos el Sitio que contiene el DC que queremos mover. Podemos explorarlo extendiendo el sitio y seleccionando el contenedor de Servidores del sitio.
7. Cuando lo tenemos localizado, documentar desde donde lo vamos a mover –por si acaso-, clic derecho sobre el servidor y escogemos Mover.
   
8. Cuando se abra la ventana que nos muestra la lista de todos los Sitios en el bosque, seleccionamos el Sitio de destino y le damos a Aceptar para iniciar el traslado.
   
9. Cuando ha finalizado el traslado, comprobar que el DC se ha emplazado en el contenedor de Servidores correcto del Sitio elegido.

 

Los sitios pueden ser distintas cosas según a quién le preguntes. Algunos dicen que es un sitio físico desde el que operan las empresas, vaya.

Dentro del ámbito de AD, un Sitio define los límites de replicación interna y externa y ayuda a los usuarios a localizar los servidores más cercanos para autentificarse y tener acceso a los recursos de red. También puede servir como límite administrativo, como delegar autoridad a un administrador local de su sitio AD.

Sitios

Un Site se compone de un nombre de sitio; subredes dentro del sitio; enlaces y puentes a otros sitios; políticas basadas en el sitio; y, claro está, los servidores, estaciones de trabajo y servicios proporcionados dentro de ese Sitio. Algunos de sus componentes, como servidores y estaciones, se configuran dinámicamente en el sitio basándose en su configuración de red. Los servicios de DC y las ubicaciones DFS también se localizan dentro de los sitios mediante la configuración de red del servidor en el que se ubican los recursos.

Los sitios de AD se pueden configurar para coincidir con una o varias ubicaciones que dispongan de conectividad de banda-ancha entre ellas. Éstas pueden optimizarse para la replicación y requiera poco ancho de banda. Después de definir un Sitio, los servidores y los equipos cliente usan la información almacenada en la configuración del sitio para localizar los más cercanos DC, Catálogos globales y los DFS. La configuración de un sitio puede ser una simple tarea, pero si la topología del sitio no está bien definida, la velocidad de acceso de la red puede sufrir ya que los servidores y usuarios pueden conectarse a los recursos mediante la WAN en lugar de usar los recursos locales. En la mayoría de las ocasiones definir y levantar un sitio tomará unas pocas horas. Después de dicha configuración, los sitios raramente necesitaran ser modificados, a no ser que se hayan hecho cambios en el direccionamiento de red, se hayan añadido o quitado DCs, se definan nuevos sitios o se quiten algunos antiguos.

Subredes

Las subredes marcan la frontera de un sitio y limitan el tráfico WAN permitiendo a los clientes encontrar servicios locales antes de buscar a través de un enlace WAN. Muchos administradores no definen subredes para  ubicaciones que no disponen de servidores locales, en su lugar, ellos relacionan las subredes del site sólo para la replicación de controlador de dominio de AD.

Si un usuario de una estación de trabajo de una subred no se encuentra definido dentro de AD, la estación de trabajo tomará aleatoriamente otro controlador de dominio. Este DC puede que sea uno de los que hay en su misma ubicación física o puede que sea cualquier otro accesible mediante los enlaces WAN. El usuario de la estación podrá autenticarse y descargar las políticas o ejecutar servicios desd un DC que no está conectado directamente a la LAN. Esto crea un tráfico innecesario y tiempos de respuesta inaceptables.

Al analizar la infraestructura de AD, podría parecer que las sucursales sin DC pueden simplemente agruparse con el Site de la central con añadir las subredes de la sucursal al Site principal. Esto ahorraría mucho tiempo de configuración necesario para crear estos Sites de sucursal.

Esto es algo obtuso o de vista corta, y que afectará al comportamiento de otras aplicaciones compatibles con AD. Así pues, es importante definir completamente la arquitectura de Sites en AD, incluyendo las subredes para reflejar la arquitectura WAN de la organización.

Todas las subredes deben definirse en Sites y Services de AD para asegurarse que el DC más próximo es el asignado a las estaciones de trabajo. Y todas las ubicaciones deben tener su propio Site y subred definidos, incluso si no hay DC actualmente en el lugar. Esto asegura que los recursos están localizados correctamente por AD y no sólo por los servicios de dominio, sino también por otros servicios.

Vínculos de Site

Los vínculos controlan la replicación de AD y conectan Sites individuales directamente entre ellos. Un vínculo de Sitio se configura para un tipo de protocolo en particular (a saber, IP o SMTP) y la frecuencia y la agenda de la replicación se configura dentro de éste vínculo. Los vínculos de sitio se utilizan por Active Directory Knowledge Consistency (KCC) para realizar las conexiones y asegurarse que la replicación tiene lugar de la manera más eficiente.

Una vez más, algunos administradores no definen completamente la arquitectura de Sites y no los crean para ubicaciones en las que no hay DC. El razonamiento es que los Sites los utiliza AD para la replicación y las ubicaciones a las que le falta DC no necesitan definir Site.

Al igual que con el diseño de subredes, esto también es de vista corta…  Los vínculos de Site también se usan por las aplicaciones compatibles con AD para entender la topología física y optimizar las comunicaciones WAN.

Así pues, sirva de repetición, es importante definir completamente la arquitectura de sitios de AD, incluyendo tanto las subredes como los vínculos de sitio para reflejar la arquitectura WAN de la organización.

Ejemplos de vínculos de Site incluyen un vínculo por lada enlace WAN, como el de la oficina principal a cada una de las sucursales.

Directivas de grupo de Site

Las directivas de Site permiten definir configuraciones de equipo y usuario, y permisos en una ubicación y aplicarse a todos los equipos y/o usuarios dentro de ese sitio. Ya que el ámbito de un Site puede abarcar todos los dominios y DCs en un bosque, las directivas de Site deben aplicarse con precaución. Debido a esto no suelen usarse excepto para definir los valores de seguridad de red para sitios con requerimientos altos o para delegación de derechos administrativos cuando la administración se lleva a cabo principalmente sobre una base geográfica.

*Ya que normalmente se definen los Sites de acuerdo con su conectividad de ancho de banda, hemos de tener en cuenta ciertos consejos cuando queremos definir las necesidades de un Site. Si es posible, los Sites deben contener servicios locales de red, como DC, Global Catalog, DNS, DHCP, WINS. De esta forma si la comunicación entre sitios se corta, el Site local seguirá funcionando a nivel de autenticación, resolución de nombres y identificación de recursos. Colocar servidores de archivos en el Site puede mejorarlo también, siempre que los archivos servidos no deban hallarse de forma central por otras razones.

¿Cómo administramos nuestro R2?

En principio aprendiendo tareas simples y su aplicación a distintos niveles y objetos. Esto nos permitirá escalar fácilmente la administración de la infraestructura sin un incremento excesivo de trabajo. Todo esto sin embargo, requiere que definamos y apliquemos un modelo administrativo.

La administración completa de un entorno se compone de tareas administrativas que tocan casi todos los aspectos de la red, administración de usuarios, administración de servidores y equipos y la propia administración de la red. Cada día, por ejemplo, un administrador puede comprobar la copia de seguridad, reiniciar contraseñas de usuario, agregar o eliminar usuarios y/o grupos, comprobar hardware, etc… Aunque cada una de estas tareas pueda, de forma independiente, ser muy simple o complicada por naturaleza, los administradores debemos, al menos, entender su parte del total de la red empresarial y entender cómo los diferentes componentes que conforman la red se comunican y dependen unos de otros.

Active Directory es la base para el modelo administrativo en Windows Server 2008 R2. La estructura de AD se usa para controlar la autorización y acceso a otras tecnologías, como Exchange, SCOM, Sharepoint…

Definir el modelo

Antes de que un entorno de redes y equipos pueda administrarse con efectividad, debe definirse cómo se asignarán y administrarán las tareas. El trabajo de delegar responsabilidades en la Red define el modelo administrativo. Tres tipos distintos de modelos son los utilizados para la administración:

• Centralizado
• Distribuido
• Mixto

Si no hay modelo administrativo, la gestión del entorno es caótico y la mayor parte del trabajo es de ‘apaga fuegos’. Las actualizaciones y modificaciones de servidores se llevan a cabo demasiado frecuentemente sin comprobación anterior. Además, si las tareas no se llevan a cabo correctamente y con consistencia, el asegurar o auditar el entorno se hace imposible. Aquéllos entornos que no siguen un modelo definido son administrados más de forma reactiva que proactiva.

Para una elección o definición del modelo correcto, hemos de descubrir que servicios son necesarios y en qué lugares y donde ubicar a los administradores para su gestión.

Modelo centralizado

El modelo centralizado es simple en concepto: Toda la administración depende de un único grupo localizado en una ubicación física determinada. Aquí, todos los servidores críticos están ubicados en un lugar en vez de distribuirlos en varios lugares. Esta disposición permite una copia de seguridad central y siempre tener al miembro correcto del equipo de administración disponible por sí un servidor falla.

Modelo distribuido

Modelo opuesto al anterior (centralizado), las tareas se reparten entre miembros de diversos grupos y diversas ubicaciones. Los derechos y permisos para la realización de tareas administrativas se asignam geográficamente, por departamento, o según su ocupación. También se puede asigar el control de servicios específicos. Esto permite la dispersión de la administración de servidores y equipos sin conceder derechos o permisos a usuarios no cualificados para modificar la configuración de red o de seguridad.

Windows Server 2008 R2 permite una granularidad en la asignación de derechos y permisos dando a los administradores más flexibilidad cuando asignan tareas a otros miembros. La distribución por próximidad geográfica es la más común en estos casos. Después de todo, si se necesita una visita física a un servidor o equipo o dispositivo de red, tener a la persona más cercana y cualificada para ello puede resultar más eficaz.

Modelo mixto

Que voy a decir si la palabra ya lo dice todo, mixto, es decir, una conjunción de los dos modelos anteriores. Parte de la administración se realiza de forma centralizada y parte se delega de forma distribuida por sitios o departamentos.

Esta configuración añade la ACL de administrador a la ruta de perfiles móviles de usuario.