Uno de los blogs de Juansa

Qué tipo de grupos podemos crear y más importante, donde podemos usarlos.

Crear un grupo es tan sencillo como seguir estos pasos:

1. Abrir Administrar el servidor en un Controlador de Dominio (DC).
   
2. Expandir Roles.
   
3. Expandir Servicios de dominio de Active Directory.
   
4. Expandir Usuarios y equipos de Active Directory.
   
5. Expandir el dominio, en la imagen R2.local.
   
6. Seleccionar un contenedor, por ejemplo Users. Clic derecho, Nuevo, Grupo.
   
7. Introduce el nombre del grupo y selecciona el tipo y el ámbito.
   
8. Clic Aceptar para finalizar.
   

Un grupo de Active Directory se compone de una colección de objetos (usuarios y equipos, y otros grupos utilizados para simplificar el acceso a los recursos y envío de correos electrónicos). Los grupos pueden utilizarse para asignar derechos administrativos, acceso a recursos de red, o, para distribuir correo electrónico. Hay grupos de varios sabores, y dependerá del modo en que el dominio se esté ejecutando el que ciertas funcionalidades de grupo estén o no disponibles.

Active Directory de Windows Server 2008 R2 es compatible con dos tipos ditintos de grupos: Distribución y Seguridad. Ambos tienen sus propios usos y ventajas, siempre que se utilicen correctamente y se hayan entendido sus características.

Los grupos de distribución permiten el agrupamiento de contactos, usuarios o grupos, principalmente para la distribución de correo electrónico. Estos tipos de grupos no pueden utilizarse para permitir o denegar el acceso a recursos del dominio. Las Listas de Control de Acceso Discrecional (DACLs), que se utilizan para permitir y/o denegar el acceso a los recursos, o para definir los derechos de usuario, se componen de Entradas de Control de Acceso (ACEs). Los grupos de distribución no tienen habilitada la seguridad y no pueden usarse en las DACL. En algunos casos, esto puede simplificar la administración de la seguridad cuando necesitamos tener a distribuidores externos localizados en libretas de direcciones pero nunca necesitarán acceder a recursos del dominio o bosque.

Los grupos de seguridad tienen habilitada esta característica y por tanto pueden utilizarse en la asignación de derechos de usuario y en los permisos del recurso, o, en la aplicación de directivas de grupo basadas en AD o directivas de equipo. El uso de un grupo en lugar de usuarios de forma individual simplifica mucho la administración. Los grupos pueden crearse para recursos o tareas en particular, y cuando se efectúan cambios en la lista de usuarios que necesitan acceso, sólo debe modificarse la pertenencia de grupo para reflejar los cambios en cada recurso que utiliza este grupo.

Para llevar a cabo tareas administrativas, los grupos de seguridad pueden definirse dentro de distintos niveles de responsabilidad. La granularidad que podemos aplicar es vasta, de hecho una estructura de grupos funcional es una de las maneras de simplificar la administración de la empresa.

Los grupos de seguridad también pueden usarse con propósitos de correo electrónico, lo que significa que aunan ambos propósitos.

Además del tipo, los grupos disponen de un ámbito a seleccionar. El ámbito, simplemente, marca los límites de quién puede ser miembro, y dónde puede utilizarse el grupo. Sólo los grupos de seguridad pueden usarse para delegar control y asignar acceso a recursos. Una clasificación teniendo en cuenta el ámbito quedaría:

• Grupos locales de dominio.
• Grupos globales.
• Grupos universales.

*Referencias:

Administración de grupos I-2003	Administración de grupos V-2003	Administración de grupos IX-2003
Administración de grupos II-2003	Administración de grupos VI-2003	Administración de grupos X-2003
Administración de grupos III-2003	Administración de grupos VII-2003
Administración de grupos IV-2003	Administración de grupos VIII-2003

Hay diferentes niveles de funcionalidad y grupos, en cada nivel se añade más funcionalidad. La razón de estos distintos niveles es para proporcionar compatibilidad con controladores de dominio ejecutándose sobre diferentes plataformas. Esto nos permite una migración por etapas de los DC. Los cuatro niveles de funcionalidad de dominio actuales son:

> Windows 2000 Nativo – Este nivel permite DC’s con Windows 2000, 2003, 2008 y 2008 R2 dentro del dominio. Los grupos Universales se pueden aprovechar junto con el anidamiento de grupos de seguridad globales y universales. Este nivel puede ser elevado al nivel Windows Server 2003, que también nos habilita a cambiar algunos ámbitos de grupos existentes, y autenticación selectiva.

> Windows Server 2003 – Este nivel nos permite Dc’s con 2003, 2008 y 2008 R2. Proporciona todas las características del nivel anterior, más características de seguridad y funcionalidad añadidas, como renombrar un dominio, actualizaciones de marca de tiempos de inicio de sesión, y autenticación selectiva.

> Windows Server 2008 – El nivel funcional Windows Server 2008 permite sólo controladores 2008 y 2008 R2. Este nivel es compatible con todas las características del nivel anterior y además cuenta con características como cifrado AES 128 y 256 para Kerberos, última información de inicio de sesión interactivo para proporcionar visibilidad sobre la verdadera actividad de inicio de sesión por parte del usuario, políticas de contraseña más granulares para permitir establecerlas por grupo o por usuario y uso de DFSR para la replicación de AD.

> Windows Server 2008 R2 – Este nivel funcional añade garantía al mecanismo de autenticación. Esto esencialmente inserta en kerberos el metodo del tipo de inicio de sesión y permite a las aplicaciones determinar la autorización o acceso basado en el metodo de inicio de sesión. Por ejemplo: una aplicación puede permitir tan sólo el inicio de sesión tipo 2 (interactivo) y ningún otro, con tal de asegurarse que el usuario estaba realmente frente a la estación de trabajo.

En nuestro caso, lo importante es que todos los niveles de funcionalidad compatibles con Windows Server 2008 R2 permiten grupos de seguridad Universales.

 

Sobre Microsoft Platform Ready

Microsoft Platform Ready (MPR) ha sido diseñada para ofrecerte lo que necesitas en torno a la planificación, construcción, testeo y despliegue de tu solución. Hemos reunido un conjunto de plataformas de desarrollo en un solo espacio, incluyendo los aspectos técnicos, de soporte y recursos de marketing, así como ofertas exclusivas. Con MPR, tú puedes:

• Acceder a cursos y seminarios online que te ayudarán a hacer tu solución más compatible.
• Prueba tu aplicación con recursos online y herramientas de testeo.
• Utiliza herramientas de marketing incluyendo plantillas para email, cartas y presentaciones.

Tecnologías soportadas

Windows 7, Windows Server 2008 R2, SQL Server 2008 R2, Windows Phone, Microsoft Office 2010, SharePoint 2010, Exchange 2010 y Window Azure incluyendo SQL Azure

http://www.microsoftplatformready.com/spain/home.aspx

 

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.

 

Las mejoras de Windows Server 2008 R2 sobre la versión básica de BIND-DNS ayuda a ser al DNS más confiable y a tener una estrategia de resolución más robusta tanto para entornos Microsoft como No-Microsoft.

Quizás la más significativa de las características en la implementación de DNS en R2 sea que las zonas integradas de AD se almacenen en la partición de aplicación de AD. Para cada dominio en un bosque, una partición de aplicación separada se crea y se usa para almacenar los registros que existen en cada zona integrada de AD. Ya que esta partición no se incluye como parte del Catálogo global, las entradas del DNS no se incluyen como parte de la replicación de éste.

Con el concepto de partición de aplicación, la carga de replicación se ve reducida ahora mientras la información importante de la zona se delega a áreas de la red donde sea necesaria.

La configuración del DNS usando el asistente permite la creación automática de una zona DNS paso a paso. Esta característica es de agradecer, ya que facilita la creación de zonas, especialmente para AD.

En anteriores versiones del DNS de Microsoft existía cierta cuestión conocida y documentada, ‘la isla’, que se manifestaba por un DNS que se apuntaba a sí mismo como servidor DNS. Si la IP cambiaba el DNS actualizaba su propia entrada pero el resto de DNS del dominio eran incapaces de recuperar actualizaciones desde el servidor original ya que lo solicitaban a la IP anterior. Esto convertía al servidor en una isla. Microsoft lo arregló en Windows Server 2003 y posteriores. R2 primero cambia sus registros Host en un número suficiente de servidores DNS autoritativos dentro del DNS haciendo que la IP cambiada se replicase con éxito, eliminando el problema de ‘isla’. El resultado es que ya no se necesita apuntar un DNS raíz sobre otro para las actualizaciones, como se aconsejaba anteriormente.

En AD, todos los inicios de sesión y búsquedas de los clientes se redirigen a los servidores DC y Catálogos Global mediante referencias a los registros SRV del DNS. Estos registros se almacenaron en un subdominio del dominio AD que se conoce como _msdcs subdominio.

En R2, _msdcs es una zona separada en el DNS, como vemos en la imagen:

Esta zona, almacenada en la partición de aplicación, se replica a todos los DC que sean servidores DNS. Esta lista de registros SRV se movió principalmente para cumplir con las necesidades de sitios remotos. En Windows 2000, estos sitios remotos tenía que replicar el DNS completo para acceder a los registros de _msdcs, qué producía un mayor tiempo de replicación y una capacidad de respuesta reducida. Si delegamos los registros SRV a su propia zona, sólo ésta puede designarse para la replicación de DNS remotos, ganando tiempo en la replicación y obteniendo mayor capacidad de respuesta.

DNS y un entorno AD DS

DNS es inseparable de AD. De hecho ambos se confunden uno por otro con frecuencia, debido quizás a su estructura similar.

AD utiliza una estructura jerárquica basada en X.500 que se diseñó para mapearla dentro de la jerarquía DNS, de ahí las similitudes. Además, AD usa el DNS para todas las búsquedas internas, desde los inicios de sesión a las búsquedas en el catálogo global.

Problemas con DNS pueden suponer un desastre para un entorno de AD.Ya que todos, servidores y clientes, están constantemente realizando búsquedas de unos a otros, y un corte en la resolución de nombres afecta seriamente a la funcionalidad de AD. Por estas y otras razones, DNS redundante en AD es muy recomendable, aun en pequeños entornos de AD.

Las consideraciones de seguridad para la BD de DNS no deben darse por sentadas. Actualizaciones seguras para las zonas integradas-AD son altamente recomendadas, y mantener los servidores DHCP fuera de los DC también ayudan a mantener seguro el DNS. Además, limitar el acceso administrativo al DNS ayudará a reducir problemas de ‘monerías’ no autorizadas en el DNS.

AD DS se escribió especifícamente para ser capaz de coexistir y, de hecho, utilizar implementaciones DNS que no son de Microsoft siempre que sean compatibles con actualizaciones dinámicas y registros SRV. Por ejemplo, AD funcionará en versiones UNIX BIND 8.1.2 y superiores. Con esta idea en mente sin embargo, no deja de ser recomendable que una empresa con una inversión significativa en tecnologías de Microsoft considere tener el DNS para AD en un R2, ya que las mejoras en funcionalidad y seguridad es la mejor opción en estas situaciones.

En entornos que usen versiones antiguas de DNS no no pueden alojar a clientes AD en sus BD, AD DNS puede simplemente ser delegado a una zona separada en la que puede ser autoritativo. Los R2 pueden funcionar como simples reenvíadores en implementaciones foráneas de DNS para proporcionar resolución de recursos en la zona original.

Ciertas situaciones en AD requieren el uso de zonas secundarias para manejar resolución específica. En ciertos modelos de dominio donde árboles separados forman distintos espacios de nombres dentro de un mismo bosque, se necesitan zonas secundarias de cada raíz DNS en Windows 2000 para mantener una sincronización correcta del bosque. Ya que cada árbol en este modelo se compone de dominios independientes que pueden no tener privilegios de seguridad en los otros dominios, se necesitará un mecanismo en el lugar para permitir las búsquedas entre los dos árboles. La creación de zonas secundarias en cada entorno de DNS proporcionarán una solución. R2 dispone de la opción de replicar estos árboles separados a todos los DNS en el bosque, reduciendo la necesidad de las zonas secundarias. La replicación de zonas secundarias fuera del bosque es aun, algunas veces, necesarios sin embargo. El reenvío condicional y las zonas de rutas internas pueden también utilizarse en ciertos casos para obtener un resultado similar sin necesidad de replicación de los datos.

SRV y resolución de Sites

Todos los clientes de AD DS usan DNS para cualquier tipo de búsqueda basada en dominio. Inicios de sesión, por ejemplo, necesitan de una búsqueda dentro de AD para un SRV específico que indica la ubicación de los DC y Global Catalog. R2, como se ha dicho, divide la ubicación de los SRV dentro de zonas separadas, que se replican al resto de DCs que tienen DNS instalado.

Se crean subdominios para cada Site en esta zona; Indican que recursos están disponibles en quéllos Sites específicos. En dos palabras, si un SRV en un subdominio de un Site específico es incorrecto, u otro servidor de un Site distinto está en la lista, todos los clientes de ese Site están obligados a autentificarse en otros Sites. Esto es importante ya que un problema común es qué cuando los Sites se creaban antes se llenaban de servidores, un SRV desde la ubicación central se añade para este subdominio del Site en el DNS. Cuando se añade un nuevo servidor a estos Sites, sus SRV se unen a los otros SRV que se colocaron cuando se creó el Site. Estos registros no se eliminan automáticamente y ellos consecuentemente dirigen a los clientes a servidores a través de lentos enlaces WAN, y con ello hacen que los inicios de sesión sean lentos.

Además de los contenedores Site, la raíz de dichos contenedores contienen una lista de todos los DC en un dominio específico. Estas listas se usan para resolución cuando un servidor de Site no responde. Sí un DC de Site está caído, los clientes de forma aleatoria eligen un DC en este Site.

Zona GlobalNames

En algunos casos, no es conveniente el uso de nombre de dominio cualificado FQDN por los usuarios finales. Esto es especialmente cierto para los novatos o en el caso de nombres de dominio largos. Un usuario escribe una URL, http://intranet.r2.local y a veces es fácil equivocarse. WINS proporciona facilidad en esto, en que puede utilizarse etiquetas simples en su lugar. Esto permite que el usuario escriba sólo http://intranet para acceder al recurso.

Sin embargo, con la llegada de IPv6, WINS no será compatible con el nuevo direccionamiento. Hay otras ventajas de DNS sobre WINS, menor carga administrativa, repositorio único de resolución de nombres, seguridad y estándares abiertos.

R2 proporciona una característica que se introdujo en 2008 para tratar esto, la zona GlobalNames (GNZ). Esta zona proporciona una resolución de etiqueta simple via zona DNS, parecido a WINS. La zona es una zona de búsqueda directa normal, si bien es cierto que con un nombre especial (GlobalNames), y que se usa por el DNS de una manera especial. Si el DNS es incapaz de resolver una dirección en sus zonas locales, intentará resolver la etiqueta simple contra la zona GlobalNames.

GNZ ofrece la promesa, finalmente, de terminar con la resolución WINS y NetBIOS.

Si queremos configurar una zona GlobalNames:

1. Administración del servidor
2. Expandimos los Roles, Servidor DNS, nodo DNS, Servidor DNS.
3. Seleccionamos el nodo de Zonas de búsqueda directa.
4. Nueva Zona (clic derecho o desde Acción)
   
5. Siguiente en la página de bienvenida.
6. Seleccionamos Zona principal y marcamos la casilla de Almacenar la Zona en AD. Siguiente.
7. Seleccionamos Para todos los servidores DNS que se ejecutan en controladores de dominio en este bosque, siguiente.
8. Introducimos el nombre de la Zona, GlobalNames y siguiente.
9. Dejamos la configuración predeterminada de actualizaciones dinámicas, siguiente.
10. Finalizar para crear la zona.
    
11. Abrimos una ventana de símbolo del sistema y ejecutamos el comando:
    1. dnscmd /config /EnableGlobalNamesSupport
    2. Debe recibirse el mensaje “Propiedad del Registro EnableGlobalNamesSupport restablecida correctamente”

    
    

El comando debe ejecutarse en cada DNS del que se espere que resuelva GlobalNames, a menos de que la zona se les replique ya.

Ahora la Zona GlobalNames está lista para responder consultas. Para cualquier servidor que necesite responder a una etiqueta simple, introducimos un registro CNAME en esta zona con el apropiado FQDN del recurso.

Apuntes

Sugerencias de raíz:

Se usan si no se configuran reenvíadores o sí estos no responden.  De forma predeterminada una instalación de DNS incluye un listado de nombres de servidores en internet para utilizarse en la resolución de nombres .com, .net, .es, y resto de dominios de internet. Cuando un servidor DNS no puede resolver un nombre en sus zonas o su caché, realizará la consulta en la lista de sugerencias de raíz, que indicará que servidores hay que consultar.

El archivo de sugerencias debe actualizarse regularmente para estar seguros que los servidores listados siguen estando disponibles. El archivo se encuentra en ruta_del_sistemasystem32DNScache.dns y puede actualizarse por internet, en ftp://ftp.rs.internic.net/domain/named.cache

Podemos ver las sugerencias de raíz de nuestro 2008 R2 abriendo el Administrador del servidor, seleccionamos el servidor DNS, clic derecho, propiedades, pestaña Sugerencias de raíz.

Reenvíadores:

Los reenvíadores son servidores de nombres que manejan todas las consultas iterativas para un DNS, Es decir, si un servidor no puede responder una consulta de un cliente, los servidores que tienen reenvíadores simplemente reenvían la consulta a uno de los configurados que procesará la consulta a los DNS raíz en Internet. Se utilizan con frecuencia en entornos en los que las empresas usan DNS de sus proveedores de internet para el manejo de todo el tráfico DNS, o, si el DNS maneja la resolución interna de nombres de AD y al tiempo reenvía las solicitudes externas a otros DNS.

En el reenvío condicional, las consultas realizadas sobre un dominio específico o conjunto de dominios se envían a un reenviador específico. Esto normalmente se usa para definir rutas que el tráfico interno seguirá.

Los servidores de sólo reenvío no están destinados a realizar consultas iterativas, sino a transmitir todas las solicitudes que no pueden responder localmente a un reenvíador o conjunto de reenvíadores. Si estos no responden se produce un mensaje de error.

Los reenvíadores se configuran en la pestaña de Reenvíadores de las propiedades del Servidor DNS.

Wins:

En entornos en los que aún es necesario, la bd de WINS se utiliza junto a DNS para la resolución de nombres. Si un DNS ha finalizado todos los métodos para resolver, un WINS puede ser consultado para proporcionar dicha resolución.

Para habilitar WINS, Pestaña WINS de las propiedades de la zona de búsqueda directa de nuestro servidor DNS, marcaremos la casilla de Usar búsqueda directa WINS e indicaremos la IP del servidor, luego pulsamos en el botón agregar y Aceptar para guardar los cambios.

Zonas DNS

Una zona DNS es una parte de un espacio de nombres DNS que se controla por un grupo de servidores o un Servidor DNS particular. La zona es el primer mecanismo de delegación en DNS y se usa para establecer límites sobre cual servidor puede resolver las consultas. Cualquier servidor que aloja una zona concreta se dice que es autoritativo para dicha zona, con la excepción de las zonas de código auxiliar (stub zones).

Hay que entender que cualquier sección o subsección de DNS puede existir dentro de una sola zona. Una empresa puede decidir emplazar  un espacio de nombres de un dominio, subdominios y sub-subdominios en una sola zona. O secciones específicas de este espacio de nombres puede ser dividido en zonas separadas. De hecho, el espacio de nombres de internet puede ser visto como un solo espacio de nombres con el punto . como raíz, que se divide en multitud de zonas distintas.

Zonas de búsqueda directa

Una zona de búsqueda directa, como el nombre sugiere, realiza búsquedas directas en la base de datos de DNS, es decir, este tipo de zona resuelve nombres a direcciones IP e información de recursos. Por ejemplo, si un usuario realiza una consulta sobre el nombre R2.local se devolverá la IP 192.168.1.77, que es la que consta en la base de datos.

Zonas de búsqueda inversa

Una zona de búsqueda inversa lleva a cabo exactamente lo contrario que una zona de búsqueda directa. Las direcciones IP se emparejan con nombres comunes. Es parecido a conocer un número de telefóno pero no el nombre al que pertenece. Estas zonas de búsqueda inversa son normalmente creadas de forma manual y no existen en todas las implementaciones. Los registros presentes son los PTR.

Zonas primarias

En un DNS tradicional (no integrado en AD DS), un único servidor sirve como maestro para una zona, y todos los cambios que se hacen en una zona en particular quedan hechos en el mismo servidor. Un servidor único puede alojar múltiples zonas, puede ser primario para una zona y ser secundario para otra. Si una zona es primaria, sin embargo, todos los cambios hechos para ella se deben hacer en el servidor que mantiene la copia maestra de la zona.

Zonas secundarias

Una zona secundaria se añade para proporcionar redundancia y balanceo de carga para la zona primaria. Cada copia de la BD en DNS es de sólo lectura, es decir no admite cambios desde la zona secundaria, estos deben realizarse en el servidor que mantenga la copia primaria. Un único servidor puede contener varias zonas primarias y varias zonas secundarias. El proceso de creación de una zona secundaria es similar al de una zona primaria, con la diferencia de que los datos se tranferirán desde el servidor que aloje la zona primaria.

Zonas de rutas internas

El concepto de zona de rutas internas es único para el DNS de Microsoft. Esta zona esencialmente no contiene información sobre los miembros de un dominio sino que sirve simplemente las consultas directas hacia una lista designada de nombres de servidor para distintos dominios. Por tanto una zona de rutas internas sólo contiene registros NS y SOA y de adherencia de host. Los registros de adherencia son esencialmente registros A que trabajan conjuntamente con un NS concreto para resolver la dirección IP de un nombre de servidor particular.

Este tipo de zona puede crearse una vez tenemos claro las necesidades para este tipo de recurso. Los pasos serían:

1. Abrimos Administración del servidor
   
2. Expandimos Roles, Servidor DNS, DNS y seleccionamos el servidor.
   
3. Seleccionamos Zonas de búsqueda directa.
   
4. En Acción, Nueva Zona
   
5. Siguiente en la pantalla del asistente,
   
6. Seleccionamos zona de rutas internas, ya que esta zona no será integrada en AD desmarcamos la casilla de Almacenar la zona en AD, y pinchamos en siguiente.
   
7. Escribimos el nombre de la zona que se creará y pinchamos en siguiente.
   
8. Después seleccionamos Crear un archivo nuevo con este nombre de archivo: dejamos el valor predeterminado a no ser que estemos migrando un archivo de zona ya existente. Siguiente.
   
9. Escribimos la dirección IP del servidor o servidores desde donde se copiarán los registros de zona. Enter para validar cada servidor, al acabar siguiente.
   
10. Finalizar