Category: DNS


Windows Server 2008 R2–Administración de Sites 

Dentro del Active directory, un Sitio define los límites de replicación interna y externa, ademas  ayuda a los usuarios a localizar el pool de 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 Sitio 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.

Seguramente tengas la necesidad de agregar servidores DNS adicionales así no hay un unico punto punto de falla. En lugar de agregar estándar servidores DNS secundarios, puede convertir el servidor de un servidor DNS principal a un servidor de Active Directory primario integrado y configurar otro controlador de dominio DNS  en otro servidor. Con servidores principales integrados, todos los servidores son servidores principales, por lo que cuando se realiza un cambio de zona en un servidor, se replica en otros, lo que elimina el requisito para una transferencia de zona.
Convertir el servidor DNS principal a Active Directory principal integrado

  1. En el servidor DNS actual, inicie el Administrador de DNS.
  2. Haga clic con el botón secundario en una zona DNS, haga clic en Propiedades , haga clic en la ficha General y, a continuación, tenga en cuenta el tipo de valor. Esto será zona principal zona secundaria zona de código auxiliar .
  3. Haga clic en cambiar .
  4. En el cuadro Cambiar tipo de zona , haga clic para seleccionar el almacenar la zona en Active Directory (disponible sólo si DNS servidor es un controlador de dominio) casilla de verificación. Cuando se le pida para responder a si desea que esta zona sea integrada en Active Directory, haga clic en Sí y a continuación, haga clic enAceptar .
    En el dominio propiedades, el tipo ahora muestra “Activo” Directory-Integrated.

Cuando finalice la replicación al controlador de dominio que está agregando como otro servidor de Active Directory primaria integrada, a continuación, puede instalar el servicio servidor DNS en ese controlador de dominio. En el Administrador de DNS, se muestra la información de zona DNS. Puede agregar DNS adicional tantos servidores como la desee.

Causa replicación inmediata

Si desea que se produzca inmediatamente en lugar de esperar el ciclo de replicación normal la replicación, siga estos pasos:

  1. En Herramientas administrativas , iniciar sitios y servicios .
  2. Expanda sitios . Debe haber al menos un sitio con la etiqueta “predeterminado-primer-sitio-name” (o en otros) si han configurado manualmente.
  3. Expanda predeterminado-primer-sitio-name , expanda servidores y, a continuación, expanda equipo .
  4. Expanda configuración de NTDS . Uno o más objetos se muestran en el panel derecho. Uno de esos objetos es un vínculo al controlador de dominio que desee. Para ver el nombre “descriptivo”, haga clic con el botón secundario en una entrada y ver el nombre. Uno de los objetos apunta al controlador de dominio que desee. Haga clic con el botón secundario en esa entrada y, a continuación, haga clic en Replicar ahora . La replicación se realiza inmediatamente.

Linux resuelva DNS de Windows

El inconveniente principalmente se presenta cuando estas trabajando en la consola, y no dispones de la IP del equipo con Windows, entonces, recordas el nombre del puesto de trabajo y haces via Terminal:

ping Equipo1

y lamentablemente nos encontramos con que el equipo “no existe” y nos devolverá algo parecido a:

ping: unknown host Equipo1

Ahora bien, este inconveniente se presenta por la prioridad para resolver los nombres seteados en el nsswitch, en principio haremos lo siguiente:

1) sudo -s [Get SUDO!!! sisi, es la única forma en la consola]
2) apt-get install winbind [Instalaremos el Bind para Wins]
3) nano /etc/nsswitch.conf [editamos el archivo nsswitch]

Buscamos la linea que dice:

hosts: files dns [es probable como yo que tengas mas items]

y lo cambias por:

hosts: files wins dns

Lesto!, Con esto estamos en condiciones de resolver los equipos de Windows, bajo nuestro entorno linux, por lo tanto ping Equipo1 nos devolverá respuesta.

Nota:
El archivo nsswitch, es empleado para configurar cual servicio sera usado para determinar la información relacionada a los hosts, archivo de contraseñas, y archivos de grupos.

Saludos.-