miércoles, 8 de abril de 2009

Pinceladas de DNS en AD (La zona msdcs)

ServerAD copia

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:

DNS2

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:

DNS3

DNS4

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.

DNS5

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.

DNS6

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:

DNS8

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:

DNS9

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:

DNS10

DNS11

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.

3 comentarios:

David Carrasco dijo...

¡Qué cosa más bonita!

A ver si publicas un poco más a menudo, que tus perlas de sabiduría saben a poco ;)

¡Abrazos!

Cerealkiller dijo...

Buenos días:
Ya que te veo tan puesto en este tema, y que yo tengo un problema similar al replicar las zonas de los DNS, me he decidido a preguntarte. Al ir a replicar las zonas me daba el error de RPC que figura en tu artículo. Te cuento como tenemos el tema:

Resulta que hemos cambiado un segundo controlador de Dominio que era un Windows 2000, por un Windows 2003 Server Standard R2. En nuestra red, hay un controlador de dominio llamado SERVIDOR1, en la IP 192.168.11.1, que tienen un Windows 2003 Server Standard de 64 Bits, y este servidor nuevo que hemos puesto se llama SERVIDOR2, y está en la ip 192.168.10.1. Ambas redes están unidas por una VPN. Evidentemente despromocionamos el Windows 200o viejo y metimos el nuevo al dominio, con dcpromo, y en un principio entro sin problemas. Pero cual es la sorpresa que cuando abrimos la consola de DNS, las Zonas del dominio del servidor 1, no están replicadas en el Servidor2.
La configuración de red de ambos servidores está correcta, ambos tienen dos tarjetas de red, con un puente de red, que es el que realmente tiene la direccion ip fisica:
SERVIDOR 1
IP:192.168.11.1
MASK:255.255.255.0
PE:192.168.11.101
DNS:192.168.11.1
SERVIDOR2
IP:192.168.10.1
MASK:255.255.255.0
PE:192.168.10.101
DNS:192.168.10.1

En los sitios y servicios de Active Directory, dentro de Nombre Predeterminado Primer sitio, me aparecian los dos server, pero solo en uno de ellos habia creado en NTDS settings, la conexión de active directory, concretamente en el servidor 1, la conexión, de la siguiente manera:

NOMBRE DESDE EL SERVIDOR DESDE EL SITIO TIPO
genrado automaticamente SERVIDOR2 nombre-predeterminado-primer sitio CONEXION

En el servidor 2, no hay ninguna cadena de conexión creada. Evidentemente, creamos una nueva conexion, para hacer la replicacion, apuntando al Servidor 1.

Intentamos replicar, entre ambos servidores, y al intentarlo desde el Servidor 2 al 1, nos da el siguiente mensaje de error:

"se ha producido el siguiente error cuando se intentaba sincronizar contexto de nombres DOMINIO del controlador de dominio SERVIDOR1 al controlador de dominio SERVIDOR2. Acceso Denegado, esta operacion no continuará."

Al intentar hacerlo desde el Servidor 1 al 2, nos da el mismo error pero a la inversa.

Por aportar algo más, decir que se nos están registrando en el visor de sucesos los siguientes errores de continuo.

SUCESOS DE SISTEMA:
error 26 y 29, con origen en W32TIME
error 40960, con origen SPNEGO

SUCESOS DNS:
error 4000 y 4013

SUCESOS APLICACION
error 1053 con origen USERENV

He intentando buscar toda la información posible tanto en los foros como en microsoft para solventar estos problemas, pero no los he conseguido solventar, con lo que otra gente si.

Ya he buscado en los foros, post de gente que tuvo problemas para hacer la replicacion y ninguna de ellas es como en mi caso. Supongo que el problema principal es de DNS, porque en la consola, no me aparecen las Zonas creadas en el servidor 1 en el 2, además yo si miro en "Usuarios y equipos de active directory", las propiedades del controlador de dominio SERVIDOR 2, no me aparece en la pestaña general,el nombre DNS del equipo, ni curiosamente me lee el sistema operativo que tiene, ni nada.

Ambos servidores están marcados como Catalogo Global, y las redes hacen ping entre ellas perfectamente, tanto por IP, como por nombre DNS.

F. Javier Cazallas Blanco dijo...

Hola Cerealkiller, no suelo responder dudas en mi Blog ya que no es el objetivo del mismo, aún así tu caso me llama mucho la atención, evidentemente para que la replicación funcione correctamente se tiene que generar un configuración NTDS, para poder generar esa configuración, es necesario que la zona msdcs este completa, a bote pronto, yo comprobaría las siguientes configuraciones.
Apertura de puertos, para la réplica los controladores de dominio trabajan con RPC, eso significa que van a negociar por el puerto 135 y a partir de ahí, utilizarán un puerto aleatorio superior al 1024, eso supondría tener abiertos prácticamente todos los puertos ya que aparte de este necesitas Kerberos, DNS, etc etc. En la práctica existe un Blog de Micro en el que se indica que Windows nunca utilizará puertos superiores al 5000, te dejo el Link.
http://blogs.technet.com/plataformas/archive/2008/11/27/directorio-activo-rpc-puertos-ef-meros-y-firewalls.aspx
Roles entre ellos PDC Emulator, tienes que tener todos los roles FSMO, entiendo que al depromicionar el antiguo, si este tenía roles, estos roles los pasaste al nuevo DC.
Por los errores que me indicas tienes un error de W32Time, comprueba que la jerarquía de replicación de hora está configurada de forma correcta, en mi artículo Configuración y tuning de Active Directory parte 1 comento como ha de estar configurada la sincronización de Hora (http://sysandnet.blogspot.com/2008/06/configuracin-y-tuning-de-active.html)
USERENV suele ser error en la aplicación de políticas, si tienes errores de DNS los tiro pueden venir por ahí, el error indica claramente “Windows cannot determine the user or computer name” y entiendo que es porque no llega al DNS.
Si los DCs son todos DNS, tienen que tener en la configuración de la tarjeta su dirección IP como primer DNS y la dirección IP del otro DNS, estos han de ser siempre del dominio y en los reenviadores configuras los DNS del proveedor de Internet. Cuando promocionas un DC, el DNS que tienes que tener configurado es uno del dominio, NUNCA los de tu proveedor de internet.
Sobre los errores de DNS es claro, no llega al Dominio. El error de SPNEGO no puedo averiguar nada ya que ese error no lo conozco y por ultimo sobre los errores de W32Time, parece que está intentando sincronizar la hora contra algo y no puede, revisa la configuración que te comento.
Yo de momento empezaría por ahí, y seguro que algo tienes que sacar en claro, yo me aseguraría del tema de puertos y una vez hecho esto, depromocionaría el DC, le configuraría bien los DNS del dominio y lo volvería a promocionar, espero que esto te sea de ayuda.