Este post es una demostración de cómo el entorno puede afectar lo más simple de configurar.
La situación
El diagrama de red consta de dos sitios (A y B), vinculados a traves de dos cajas Linksys armando un Tunel IPSec. Del lado “A” existen dos domain controllers del dominio viejo.net y del lado “B” (parece un disco de vinílo), un nuevo controlador de dominio de un nuevo forest nuevo.corp
Las estaciones de trabajo del sitio “B” recibían la IP desde el DHCP del Linksys y los DNS que recibían eran los del proveedor de Internet. Esta situación hacía que las máquinas estuviesen llenas de errores de ubicación del domain controller del dominio viejo.net. El administrador recibía quejas de que la validación era lenta, y que el correo, que recibían desde Microsoft Outlook, conectado a un Exchange que estaba en el sitio “A”, ocasionalmente perdía la conexión y la volvía a levantar.
Que se modificó
Entre viejo.net y nuevo.corp se estableció una relación de confianza bidireccional de tipo Forest Trust. El dominio viejo.net estaba en modo Interim y se elevó a Windows Server 2003, en conjunto con el forest, y el dominio nuevo.corp recién se habia instalado, elevándose inmediatamente a Windows Server 2003 Forest Functional Mode
Por otro lado, se configuraron Forwarders Condicionales en los DNS de cada sitio, para qué las zonas de Active Directory se vieran entre sí y se pudiese establecer la relación de confianza.
Empiezan los Problemas
Al finalizar el asistente para crear el Forest Trust, empezó el primer problema. Cuando se quiso agregar el grupo Domain Users del dominio viejo.net en el grupo domain local Users del dominio nuevo.corp, la consola de Active Directory veía al dominio pero no podía traer ningún grupo (esto ocurría de ambos lados del trust)
Por otro lado los siguientes eventos empezaron a ocurrir del lado del dc1.viejo.net y dc3.viejo.corp:
Event Type: Warning
Event Source: LSASRV
Event Category: SPNEGO (Negotiator)
Event ID: 40960
Date: 27/06/2008
Time: 11:36:59 a.m.
User: N/A
Computer: dc1
Description:
The Security System detected an authentication error for the server ldap/dc3.nuevo.corp/nuevo.corp@nuevo.CORP. The failure code from authentication protocol Kerberos was "There are currently no logon servers available to service the logon request.
(0xc000005e)".
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Data:
0000: 5e 00 00 c0 ^..À
a parte en dc3.nuevo.corp aparecía el siguiente error:
Tipo de suceso: Error
Origen del suceso: NETLOGON
Categoría del suceso: Ninguno
Id. suceso: 5719
Fecha: 27/06/2008
Hora: 13:10:31
Usuario: No disponible
Equipo: dc3
Descripción:
Este equipo no pudo establecer una sesión segura con un controlador de dominio en el dominio viejo.net debido a lo siguiente:
No hay servidores de inicio de sesión disponibles para atender la petición de inicio de sesión.
Esto puede derivar en problemas de autenticación. Asegúrese de que el equipo esté conectado a la red. Si el problema persiste, póngase en contacto con el administrador del dominio.
INFORMACIÓN ADICIONAL
Si este equipo es un controlador de dominio para el dominio especificado, establece la sesión segura con el emulador del controlador de dominio primario en el dominio especificado. De lo contrario, este equipo establece la sesión segura con cualquier controlador de dominio en el dominio especificado.
Para obtener más información, vea el Centro de ayuda y soporte técnico en http://go.microsoft.com/fwlink/events.asp.
Datos:
0000: 5e 00 00 c0 ^..À
Además, cuando las estaciones de trabajo del sitio “B” empezaron a renovar las IP, empezaron a encontrar a los domain controllers del sitio “A” (hasta ahora solo se había movido una estación de trabajo de un dominio a otro). Esto produjo que quisiesen levantar tickets kerberos para poder validar contra otros servidores. El inicio de sesión era lamentable (8 a 10 minutos de demora hasta que aparecía el escritorio) y además las estaciones de trabajo llenas de errores de sucesos de NETLOGON y LSASRV, similares a las que se observan entre los DCs).
Que se realizó
El evento LSASRV 40960 en conjunto con el código de error 0xc0O0005e refieren al error ” STATUS_NO_LOGON_SERVERS “. Lo primero que se pensó fue que las zonas DNS no resolvían como correspondían. Si bien las pruebas con NSLookup no tenían inconvenientes, se procedió a realizar una transferencia de ZONAS desde los servidores DNS de cada sitio. Además se inició un troubleshooting de resolución, vaciando el caché de resolución DNS y verificando los registros que obtenían los DCs y las estaciones de trabajo. Se observó que los únicos registros de tipo SRV que se obtenían eran de los KDC (Kerberos Key Distribution Centers) de cada dominio.
Esto motivo a investigar que pasaba con dicho servicio. Las observaciones preliminares indicaban que el servicio estaba operando sin inconvenientes y escuchando en el puerto UDP 88 en cada KDC (se llegó a pensar que habría otro servicio escuchando en el mismo puerto, o que el firewall local o del túnel estaba bloqueando el tráfico, ninguna de esas situaciones estaba ocurriendo)
Una llamada al teléfono del administrador de red nos alertó de algo más. Las estaciones de trabajo no podían enviar ni recibir correos mediante Outlook, ya que este no se conectaba. En una máquina virtual se comenzó a capturar el tráfico en el momento del inicio de la estación de trabajo y el logon. Se observaron múltiples paquetes TCP pero, sospechosamente ningún paquete UDP. Kerberos, por default, utiliza UDP 88 para el tráfico de la solicitudes de Tickets.
Como se solucionó
La falta de paquetes UDP hizo muy sospechoso el inconveniente. Unas llamadas al sitio “A” nos despejaron algunas dudas: El problema se limitaba al tráfico de validación desde el Sitio B contra el sitio A y viceversa. Del sitio A al sitio B solamente ocurría con el trust entre dominios. Pero del sitio B al sitio A, los usuarios tenían demoras en validarse y la imposibilidad de acceder a su buzón. Las validaciones contra el mismo sitio funcionaban a la perfección. El problema estaba en el vínculo.
El artículo KB244474 me dió una pista acerca de lo que podría estar ocurriendo. En este artículo se indica como proceder para que el tráfico de kerberos se realice por TCP y no por UDP. Dependiendo de varios factores, el paquete kerberos pueden llegar a exceder los 1500 bytes. Dado que UDP es un protocolo NO orientado a la conexión (los paquetes se envían, sin esperar confirmación de recepción) pueden llegar a descartarse si llegan desordenados.
Un simple checkeo con el comando ping nos permitió afirmar que el problema venía por ese lado. Se realizaron Pings con la siguiente sintáxis
ping x.x.x.x -l 1000 -f
donde:
x.x.x.x es la dirección IP – en este caso se probaba desde el sitio A al B y viceversa
-l 1000 es el tamaño de bytes que se enviará (por default son 32 bytes)
-f NO Fragmentar el paquete
Si el router no puede pasar el paquete sin fragmentar, el paquete se devuelve, y en la pantalla aparece esto:
Packet needs to be fragmented but DF set.
Este comando tenía diferentes respuestas, inclusive desde el mismo sitio (ej. en mi máquina virtual, ese ping me devolvía que debía ser fragmentado, en otra estación pasaba sin problemas, en el Domain controller el primer paquete lo reportaba como que no podía pasar, y los otros tres pasaban).
Una investigación a la configuración de los routers Linksys determinó que el campo MTU estaba en “Automático”
Simplemente se cambió dicha configuración a manual, y se puso el valor del frame ethernet por default que es 1500 en ambas cajas.
Conclusión
Este cambio resolvió directamente todos los problemas de comunicación y las estaciones de trabajo empezaron a funcionar. Existiendo tantos componentes hoy en día que interactúan entre sí, es necesario realizar un proceso de troubleshooting que nos permita acercarnos a la solución de una manera eficaz. Investigar como funcioná normamlmente el servicio de Kerberos me permitió acercarme al KB en el que se hace referencia, y ahí obtener la información necesaria para que se pudiese resolver el problema. Si bien el KB indica como hacer que el servicio funcione mediante TCP, tambien me indicaba que los paquetes UDP podrían llegar a ser fragmentados. Lo que me llevó a verificar el problema del MTU.