Pinceladas de DNS en AD (La zona msdcs)

Hola a tod@s, lo primero que quiero pedir son disculpas por no poder aparecer por aquí durante algún tiempo. Tengo que admitir que mi fuerte no es escribir, pero durante estos meses que he estado desaparecido han sido varias las personas que me han pedido añadir alguna cosilla en el blog. Me han animado y como siempre me han convencido, voy a hacer todo lo que pueda por seguir aportando información sobre Active Directory que es a lo que me dedico principalmente.

En este post mi intención es aportar algo de información sobre la integración entre DNS y AD, comentar algo sobre los tipos de registros que existen, las zonas, sobre todo una en concreto (msdcs) y me gustaría incluir algo de Troubleshooting. Sobre DNS y AD se podrían escribir muchas páginas pero como siempre intentaré ser escueto, ir al grano y dar todos los datos que pueda sin aburrir. Bien, en primer lugar retrocedamos un poco en la historia, cuando hablamos de Sistemas Operativos de Red, todos recordamos de forma algo gris NT, Windows NT utilizaba como mecanismo de comunicación principal de Red NetBIOS. Esto significa que antiguamente teníamos la necesidad de instalar un servidor WINS para nuestros dominios, los administradores de Red necesitaban mantener dos bases de datos de consultas, DNS para resolución de nombres y WINS para resolución de nombres NetBIOS. Con la aparición de Windows Server 2000 y Active Directory esto ya no es necesario y solo necesitamos mantener nuestros servidores WINS por compatibilidad con aplicaciones antiguas y no por su necesidad en Active Director ()y.

DNS es un protocolo de  capa de aplicación de la pila de protocolos de TCP/IP y de la misma capa dentro del modelo OSI, trabaja por el puerto 53 tanto en TCP como en UDP y Active Directory se apoya en él. Inicialmente se publicaron las RFCs 882 y 883 que quedaron obsoletas con la publicación a partir de  1987 de las RFCs 1034, 1035, 1912, 1995, 1996 y 2181 recientemente,  en ellas podéis encontrar toda la información del protocolo.

DNS se compone de ZONAS, las ZONAS son porciones del espacio de nombres de dominio que almacenan los datos. Cada zona de autoridad abarca al menos un dominio y posiblemente sus subdominios, si estos últimos no son delegados a otras zonas de autoridad. Las zonas contienen los registros que es la unidad de información de DNS, en la siguiente tabla podemos ver los tipos de registros que hay.

Tipo de Registro	Nombre	Descripción
A	Address	Mapea un hostname a una IPv4
AAAA	Address	Mapea un hostname a una IPv6
PTR	Pointer	Mapea una IPv4 a un hostname
CNAME	Alias	Mapea un Alias a un hostname
MX	Mail Exchanger	Especifica una ruta de correo para un dominio
NS	Name Server	Especifica un nombre de servidor para un dominio dado
SOA	Start of Authority	Contiene datos administrativos sobre una zona incluido el nombre de servidor primario.
SRV	Service	Mapea un servicio a varios hostnames

Los clientes siguen un proceso sencillo para localizar un controlador de dominio utilizando consultas DNS, en la KB247811 y KB314861 de Microsoft podemos ver como un cliente localiza un controlador de dominio. Durante esta búsqueda, el cliente realizará varias consultas al DNS para localizar cualquier DC del dominio o bien un DC perteneciente a su site, dependiendo si el cliente ha logado en alguna ocasión o no, se seguirá un orden en la búsqueda. Para ello el cliente utilizará registros de tipo SRV como los que vemos a continuación:

• _ldap._tcp.<DnsDomainName>
• _ldap._tcp.dc._msdcs.<DnsDomainName>
• _ldap._tcp.<SiteName>._sites.<DnsDomainName>

NOTA: Para aquellos que no estéis familiarizados <DnsDomainName> es la zona con el nombre de vuestro dominio.

Bien, algunos de estos registros se encuentran en la zona msdcs, esta es una zona importantísima para muchas tareas de Active Directory, el primer ejemplo lo podéis ver en las KBs mencionadas, pero cuando un servidor de Exchange quiere localizar un Catálogo Global utiliza la zona msdcs, cuando un controlador de dominio quiere replicar contra otro usa la zona msdcs y para múltiples tareas más. Esta es una zona bastante crítica que casi nadie conoce. En Windows 2000 Server, msdcs estaba alojada dentro de la zona <DnsDomainName>, en Windows Server 2003, msdcs es una zona independiente de la zona <DnsDomainName> pero está delegada en todos los controladores de dominio, por eso aparece en gris en la siguiente imagen:

Otro punto importante del servicio es el DDNS (Dynamic DNS), está definido en la RFC 2136 y permite a los clientes añadir o eliminar registros en las zonas. Cuando un DC se agrega al dominio o arranca el servicio Netlogon se registra contra su DNS añadiendo una entrada con su nombre y su IP (host A), los controladores de dominio además de crear su registro A, también añaden los siguientes registros que tienen las funciones que detallo a continuación:

• _ldap._tcp.<DnsDomainName>, permite a los clientes localizar un servidor que corra ldap en su dominio.
• _ldap._tcp.<SiteName>._sites.<DnsDomainName>, permite a los clientes localizar un servidor que corra ldap en un site de un dominio especifico.
• _ldap._tcp.dc._msdcs.<DnsDomainName>, permite al cliente localizar un DC en un dominio.
• _ldap._tcp.<SiteName>._sites.dc._msdcs.<DnsDomainName>, permite al cliente localizar un DC en un site de un dominio especifico.
• _ldap._tcp.pdc._msdcs.<DnsDomainName>, permite al cliente localizar el PDC emulator, este registro solo lo grabara el DC con dicho rol.
• _ldap._tcp.gc._msdcs.<DnsDomainName>, permite al cliente localizar un Catálogo Global de su dominio, este registro sólo lo grabará el DC con dicho rol.
• _ldap._tcp.<SiteName>._sites.gc._msdcs.<DnsDomainName>, permite al cliente localizar un Catálogo Global de un site especifico de su dominio, este registro sólo lo grabará el DC con dicho rol.
• gc._tcp.<DnsDomainName>, permite al cliente localizar un Catálogo Global para este forest, este registro sólo lo grabará el DC con dicho rol.
• D1539E64-58F8-4C7F-A97B-1582D0D5B348._msdcs.<DnsDomainName>, este registro es el GUID del DC y lo utilizarán otros DCs para la replicación.

Este último registro es un ALIAS y es de vital importancia para la replicación, veremos qué es lo que ocurre cuando este registro no está. En primer lugar encontraremos información sobre este tipo de registro en la consola de Sitios y Servicios de Active Directory, usando el botón derecho contra NTDS Settings de cada controlador de dominio como vemos en la siguientes imágenes:

En las siguientes imágenes se puede comprobar que si usamos un ping contra el registro, este es resuelto y el controlador de dominio responde a la prueba de conectividad, también podemos ver que este tipo de registros para todos los controladores de dominio están almacenados en la zona msdcs.

Bien, una vez que tenemos claro que son estos registros y donde están, supongamos que realizando una serie de tareas rutinarias en nuestro Active Directory, forzamos la replicación entre dos DCs después de hacer unos cambios y nos aparece el siguiente mensaje en pantalla.

Este no es un error muy común ya que tienen que unirse una serie de factores, pero si es uno de los errores que más quebraderos de cabeza os pueden dar ya que hay veces que el propio mensaje de advertencia nos puede confundir y hacernos creer que existe un error en el servidor DNS. Puesto que sospechamos que existe un problema DNS y este error nos ha cantado al forzar una replicación, ejecutaremos el comando dnslint con el argumento /ad que permite realizar el test sobre Active Directory, el comando a ejecutar sería el siguiente:

dnslint.exe /ad 100.1.0.254 /s 10.1.0.253 /v

Este comando nos emite un reporte en html que entre otras cosas mostrará la siguiente información:

Alias (CNAME) and glue (A) records for forest GUIDs from server:

Total number of CNAME records found on this server: 0

Total number of CNAME records missing on this server: 3

Total number of glue (A) records this server could not find: 0

CNAME records for forest GUIDs missing on server:
GUID: d1539e64-58f8-4c7f-a97b-1582d0d5b348._msdcs.contoso.com
DC: ROOTDC

GUID: e3415b00-f56f-405e-b851-ebfb00554a1a._msdcs.contoso.com
DC: CORPDC01

GUID: ed44cd9d-58c1-4300-8cb5-44acc61de1b9._msdcs.contoso.com
DC: CORPDC02

Este mensaje nos informa que este servidor tiene algún problema con los CNAME en la zona _msdcs.contoso.com por lo que vamos a comprobar esta zona y vemos lo siguiente:

Este forest está compuesto por dos dominios, contoso.com y su subdominio corp.contoso.com, si os fijáis en la imagen anterior hay tres registros de tipo NS y sólo dos de tipo CNAME, ¡Falta el CNAME del servidor corpdc01!. Parece que hemos encontrado la solución por lo que vamos a reiniciar el servicio NetLogon del DC para que este vuelva a registrar el CNAME. Una vez reiniciado el servicio comprobamos que nada ha cambiado por lo que vamos a extraer información de la zona con el comando dnscmd.exe /zoneinfo _msdcs.contoso.com, con este comando vemos lo siguiente:

Si repasamos todos los datos hay uno en especial que llama la atención, las zonas de DNS tienen tres opciones para las actualizaciones, 0-None, 1-Nonsecure and Secure y 2-Secure. En la imagen anterior la opción de update está en cero por lo cual eso significa que la zona no permite actualizaciones, este es el motivo por el cual el servidor no ha actualizado su registro CNAME. Cambiamos la opción como se puede ver en la siguiente imagen, reiniciamos el servicio NetLogon y comprobamos de nuevo la zona _msdcs.contoso.com y que el DC actualizó la información:

 

Como podemos comprobar en la imagen anterior el DC corpdc01 ya tiene su CNAME en la zona _msdcs.contoso.com y ya no existirá ningún tipo de problema a la hora de replicar contra el resto de controladores de dominio. Podría extenderme muchísimo más hablando de DNS y su integración con AD, mi intención con este post es dar un poco de luz a la zona _msdcs ya que esta es una zona poco conocida por los administradores. Como podéis comprobar su importancia es alta ya que son muchas las tareas para las cuales Active Directory necesita consultar esta zona. Espero que este post os sea de utilidad y como siempre espero vuestros comentarios, para mí es importante saber que os es útil todo el sermón que os he pegado :D, muchas gracias a todos.

Limite 48 Horas!!!!!

Buenas a todos, en primer lugar quería pedir disculpas por este mes de ausencia en mi blog, ha habido algunos cambios en mi entorno laboral y aún estoy intentando engancharme a la nueva estructura, también he tenido que renovar alguna certificación por lo que entre unas cosas y otras no he tenido mucho tiempo para actualizar el blog. Aclarado todo esto quería incluir entre los demás artículos un ajuste importante en la configuración de Active Directory que viene a completar varios puntos que se tocaron en otros post.

Como sabéis el valor de marca horaria es muy importante para muchos temas de validación, es aspecto fundamental de Active Directory que la hora sea correcta tanto en los clientes como en los servidores. Como ya he comentado en otro post, el PDC Emulator es el servidor contra el cual va a sincronizar todo el dominio. El orden exacto es que el PDC sincronice la hora contra un servidor NTP fiable, los DCs lo harán contra el PDC y los servidores miembro y clientes contra el DC de validación. Las configuraciones de sincronización de hora se deben establecer tal y como describo en el post Configuración y Tuning de Active Directory (Parte I). En el Post de Configuración y Tuning de Active Directory (Parte II) hacía mención al valor de TombStone LifeTime, si recordáis este valor determinaba entre otras cosas durante cuánto tiempo como máximo pueden estar sin replicar dos controladores de dominio para que uno considere al otro como válido.

Ahora vamos a plantear el siguiente escenario, yo he configurado el PDC Emulator de mi dominio para que apunte a un servidor de hora en Internet, el resto de controladores de dominio están configurados en NT5DS para seguir la jerarquía del dominio. Supongamos que alguien con fines no muy saludables suplanta la identidad del servidor NTP de internet y le envía a mi controlador de dominio una actualización de fecha y hora del año 2006, ¿Qué podría ocurrir?. Según Microsoft esto es un riesgo importante ya que los controladores de dominio podrían considerar que ese servidor ha superado el tiempo establecido en el Tombstone Lifetime y dejar esa máquina fuera del dominio. Ahora, supongamos que mi dominio tiene 8 DCs y la actualización que le llega al PDC emulator desde su servidor de hora es del año 2010, ¿Qué ocurriría entonces?. Bien es este caso el servidor que determina cual es la hora correcta está configurado en el año 2010 y podría considerar que el resto de DCs están fuera de ese límite de tiempo establecido por el Tombstone, por lo que entendería que el resto de DCs no son válidos y los consideraría fuera de dominio.

Para evitar este tipo de confusiones se puede establecer que nuestros DCs no acepten como actualizaciones válidas de hora aquellas que superen las 48 horas tanto de atraso como de adelanto. Si esto ocurre, en cualquier caso lo más traumático que nos podría ocurrir sería que dejaran de validar clientes contra nuestro dominio ya que como sabéis el límite que establece kerberos para determinar si un cliente es válido o no es de 300 segundos, en ningún caso las máquinas se saldrían del dominio.

Para poder activar estas opciones tenemos que acceder a la siguiente clave de registro:
HKLM\System\CurrentControlSet\Services\W32Time\Config
Una vez allí tenemos las opciones MaxNegPhaseCorrection y MaxPosPhaseCorrection que nos permitirán establecer en segundos el tiempo máximo que se espera recibir como sincronización de hora tanto positivo como negativo. Para establecer las 48 horas recomendadas por Microsoft tendremos que colocar el valor en 2880 segundos.

Espero que esta información os sea de utilidad y como siempre espero vuestros comentarios.

Ya de Vuelta!!!

Bueno, pues el verano se acaba y llega el otoño, empezamos a trabajar, los días se acortan y llegan las granizadas que te fastidian el coche, el frio. Pero bueno, no todo va a ser malo, también está la calefacción, la mantita de la cama, las tardes de películas mientras llueve en la calle, las tardes de futbol y en breve tendréis más cosas interesantes sobre AD y Cisco, espero que os sean de utilidad. Hasta dentro de un ratito.

Feliz Verano a Todos

Bueno, llegó la hora de las vacaciones, espero que podáis disfrutar todos de la playa, la montaña o lo que os apetezca. Nos leemos en Septiembre.

Soluciones con Etherchannel de Capa2

 

 

Hay mucha gente que aun no conoce el concepto de Etherchannel y por culpa de este desconocimiento estamos perdiendo una gran ventaja del switching actual. Un Etherchannel nos permite sumar la velocidad nominal de cada puerto físico y así obtener un único enlace troncal de alta velocidad. Supongamos que tenemos la topología de la siguiente figura:

 

 

Cuando tenemos una serie de servidores que salen por un único enlace trocal, pueda ser que el tráfico generado llegue a colapsar el enlace. Una de las soluciones más prácticas que se suele implementar en estos casos es el uso de Etherchannel. Cuando generamos un Etherchannel lo que estamos haciendo es sumar la velocidad de los puertos que agregamos al enlace lógico obteniendo el siguiente resultado.

Esta es una solución muy implementada en servidores Blade, un servidor de estas características es una maquina diseñada para poder ahorrar espacio en los CPD, reducir consumo y simplificar la administración. Un chasis de Blade incorpora las fuentes de alimentación, elementos de ventilación y de conectividad LAN y SAN. Los servidores son delgadas tarjetas que incorporan los componentes propios del servidor como el procesador la memoria y los buses.

Un chasis de Blade puede tener hasta 16 servidores dependiendo del fabricante y estos chasis en su parte posterior suelen llevar entre uno y cuatro switches. Si queremos sacar todo este tráfico hacia el exterior sin sufrir colapsos en los troncales la solución más recomendable es configurar un Etherchannel. La conexión física quedaría como se puede ver a continuación:

Existen varias formas de configurar un Etherchannel, el objetivo de este post no es explicar en profundidad como funciona cada uno de los protocolos, pero intentaré dejar lo suficientemente claro cuando usar cada uno de ellos. Podemos configurar un Etherchannel de tres formas diferentes, Port Aggregation Protocol (PAgP), Link Aggregation Control Protocol (LACP) o en modo ON, además ambos extremos se han de configurar en el mismo modo. Cuando se configura PAgP o LACP el switch negocia con el otro extremo que puertos deben ponerse activos, aquellos puertos que no sean compatibles se dejan desactivados en versiones anteriores a la 12.2(35) SE, a partir de esta versión el puerto queda activo pero no se agrega al Etherchannel, este puerto seguirá trabajando de forma independiente. Cuando configuramos en modo ON no se realiza ningún tipo de negociación, el switch obliga a todos los puertos compatibles a ponerse activos.

PAgP es un protocolo propietario de Cisco, PAgP se encarga de agrupar puertos de características similares de forma automática. PAgP es capaz de agrupar puertos de la misma velocidad, modo dúplex, troncales o de asignación a una misma VLAN.
PAgP se puede configurar de dos modos:
•    Auto, establece el puerto en una negociación pasiva, el puerto solo responderá a paquetes PAgP cuando los reciba, pero nunca iniciará la negociación.
•    Desirable, establece el puerto en modo de negociación activa, este puerto negociará el estado cuando reciba paquetes PAgP y también podrá iniciar una negociación contra otros puertos.

Hay que tener en cuenta que un puerto en modo desirable puede formar grupo con otro puerto en el mismo modo, también podrá formar grupo con un puerto en modo auto. Dos puertos en modo auto nunca podrán formar grupo ya que ninguno de ellos puede iniciar una negociación.

LACP es un protocolo definido en el estándar 802.1ad y que puede ser implementado en switches cisco. LACP y PAgP funcionan de forma muy similar ya que LACP también puede agrupar puertos por su velocidad, modo dúplex, trocales, VLAN nativas, etc.

LACP también tiene dos modos de configuración:
•    Activo, un puerto en este estado es capaz de iniciar negociaciones con otros puertos para establecer el grupo.
•    Pasivo, un puerto en este estado es un puerto que no iniciará ningún tipo de negociación pero si responderá a las negociaciones generadas por otros puertos.
Al igual que LAgP, dos puertos pasivos nunca podrán formar grupo.

El modo ON es un modo de configuración en el cual se establece toda la configuración del puerto de forma manual, no existe ningún tipo de negociación entre los puertos para establecer un grupo. En este tipo de configuración es totalmente necesario que ambos lados estén en modo ON.

Podríamos profundizar aún más pero creo que con esto es suficiente, se puede aplicar diferentes configuraciones a un Etherchannel según las necesidades, establecer prioridades y otras opciones pero nos extenderíamos demasiado, por eso voy a pasar a explicar una configuración sencilla en la cual generamos un Etherchannel de cuatro puertos en modo ON. Como ya he comentado es imprescindible configurar los puertos en modo ON en ambos lados y no requiere mucho esfuerzo.

Cuando se crea un Etherchannel todos los puertos que pertenecen a este adquieren todos los parámetros del primer puerto agregado al grupo, por eso una recomendación es configurar este primer puerto con todas las opciones que le queramos establecer (STP, VLANs, etc…).

También sería importante seguir estas recomendaciones:
•    No se debe configurar un puerto en dos grupos diferentes.
•    No se debe configurar un puerto en dos modos diferentes, LACP y PAgP.
•    No configurar Switched Port Analyzer (SPAN) como parte de un Etherchannel.
•    No configurar securización de puertos.
•    Asignar todos los puertos del Etherchannel a la misma VLAN o configurar todos como troncales.
•    Verificar que todos los puertos del grupo están en un mismo modo de encapsulación, ISL o  802.1Q

En la Web de cisco podréis encontrar más detalladamente todas estas recomendaciones y alguna más.

Configuración de link troncal de Etherchannel L2 modo ON (Switch 1)

Switch1# configure terminal
Switch1(config)# interface range gigabitethernet0/1 - 4
Switch1(config-if-range)# switchport mode trunk
Switch1(config-if-range)# channel-group 1 mode on
Switch1(config-if-range)# exit
Switch1(config)# exit
Switch1# copy run start

Configuración de link troncal de Etherchannel L2 modo ON (Switch 2)

Switch2# configure terminal
Switch2(config)# interface range gigabitethernet0/1 - 4
Switch2(config-if-range)# switchport mode trunk
Switch2(config-if-range)# channel-group 1 mode on
Switch2(config-if-range)# exit
Switch2(config)# exit
Switch2# copy run start

Configuración de link troncal de Etherchannel L2 con LACP (Switch 1)

Switch# configure terminal
Switch1(config)# interface range gigabitethernet0/1 - 4
Switch1(config-if-range)# switchport mode trunk
Switch1(config-if-range)# channel-group encapsulation LACP
Switch1(config-if-range)# channel-group 1 mode active
Switch1(config-if-range)# exit
Switch1(config)# exit
Switch1# copy run start

Configuración de link troncal de Etherchannel L2 con LACP (Switch 2)

Switch2# configure terminal
Switch2(config)# interface range gigabitethernet0/1 - 4
Switch2(config-if-range)# switchport mode trunk
Switch2(config-if-range)# channel-group encapsulation LACP
Switch2(config-if-range)# channel-group 1 mode active
Switch2(config-if-range)# exit
Switch2(config)# exit
Switch2# copy run start

Una vez hecho esto podemos configurar la interfaz lógica de la siguiente forma:

Switch1# configure terminal
Switch1(config)# interface port-channel 1
Switch1(config-if)#

Desde este modo de configuración podemos configurar parámetros que se aplicaran a todos los puertos del grupo. Para chequear que el Etherchannel esta funcionando usamos el siguiente comando:

Switch1> show port channel 1
Port        Status      Channel   Channel      Neighbor                   Neighbor
                   mode      status       device                                                   port
-----        ----------     -------     -----------  -------------------------  ----------
0/1       connected     on         channel      Switch2                             0/1
0/2       connected     on         channel      Switch2                            0/2
0/3       connected     on         channel      Switch2                            0/3
0/4       connected     on         channel      Switch2                            0/4
Switch1>

Como ya he comentado, este es un tema que podríamos extenderlo bastante más pero creo que con estos datos podríais configurar un Etherchannel sencillo para evitar que se pueda saturar un enlace troncal o aprovechar los puertos del switch que viene integrado en el chasis del Blade. Espero que os haya sido de utilidad y como siempre espero vuestros comentarios.