Cómo garantizar la validación local de los clientes en un dominio multi-sitio

Cuando estás construyendo un dominio de múltiples sitios que se enruta a través de varias subredes, puede que asumas que poner un controlador de dominio de respaldo en un sitio remoto garantizará que los clientes en ese sitio sean validados localmente. El propósito, por supuesto, es doble: reducir el tráfico que circulará fuera de la LAN por un enlace costoso y garantizar que los inicios de sesión de los clientes no se retrasen debido a la velocidad (o falta de ella) de la conexión WAN. Instalar un controlador de dominio local puede funcionar, pero ¿será ese éxito diseñado o accidental?

El problema de la validación del cliente

Desafortunadamente, no hay forma de especificar el controlador de dominio que validará a un cliente en particular, ya sea que ese cliente esté ejecutando Windows NT Server, Windows NT Workstation o Windows 9x. Las versiones anteriores de Windows funcionarán de la misma manera, siempre que estén utilizando el conjunto TCP/IP de 32 bits o un conjunto TCP/IP de 16 bits compatible con WINS.

En este artículo, te daremos una visión general de los procesos involucrados. También explicaremos por qué un controlador de dominio ubicado en otro país en un enlace de módem lento puede ser el elegido por una máquina cliente para atender su solicitud de inicio de sesión.

Antecedentes

Para aquellos de ustedes que no están familiarizados con el concepto de dominios de Windows NT, aquí les recordamos rápidamente: Un dominio de NT es una colección de servidores y otros equipos habilitados para redes que comparten información común de seguridad y cuentas. El dominio proporciona administración centralizada de usuarios, equipos y redes. La información de seguridad se encuentra en una base de datos central en un servidor designado y configurado como controlador de dominio principal (PDC) y se replica en otros servidores especiales, que son designados y configurados como controladores de dominio de respaldo (BDC). Solo un servidor puede ser el PDC en un momento dado, pero este rol especial puede transferirse a cualquier BDC según sea necesario. Cuando un cliente que se está ejecutando TCP/IP intenta iniciar sesión en este dominio de NT, la solicitud de inicio de sesión se procesa por cualquiera de los controladores de dominio de la red que pertenecen al mismo dominio.

Controladores de dominio en WINS

Los servidores WINS mantienen una lista de todos los clientes habilitados para WINS en la red. Los servidores WINS también mantienen una lista de controladores de dominio que están identificados como tipo <1C>. Por razones que solo conocen los diseñadores de WINS, se decidió que debería haber un límite de 25 entradas en la lista <1C>, lo que significa que los controladores de dominio posteriores no aparecerán en esta lista. Cuando los clientes intentan encontrar un controlador de dominio para atender su solicitud de inicio de sesión, se les proporciona esta lista.

El orden en que aparecen los controladores de dominio en la lista sigue esta lógica:

Cuál es la mejor opción de protocolo de enrutamiento para una red empresarial

1. Entradas de controladores de dominio registrados en el servidor WINS, en orden de más refrescados a menos refrescados.
2. Entradas de controladores de dominio obtenidas de la replicación con otros servidores WINS.
3. La primera entrada siempre es el PDC.

Tipos de nodo

Cuando se configura TCP/IP en un cliente, una de las opciones que puedes ver (dependiendo de la instalación) es el tipo de nodo. El tipo de nodo se refiere a cómo el cliente encuentra un controlador de dominio para atender sus solicitudes de inicio de sesión.

Existen cuatro tipos de nodos en TCP/IP:

• Nodo B (nodo de difusión): Cuando un cliente necesita encontrar un controlador de dominio, realiza una difusión. El primer controlador de dominio en responder será el encargado de atender la solicitud de inicio de sesión.
• Nodo P (nodo punto a punto): En este entorno, las consultas de nombres se envían directamente al servidor WINS.
• Nodo M (nodo de múltiples nodos): Un entorno de nodo M utiliza primero el nodo B y, si es necesario, utiliza el nodo P para resolver nombres.
• Nodo H (nodo híbrido): Un entorno de nodo H utiliza primero el nodo P y luego el nodo B si el servicio de nombres no está disponible.

Examinemos más a fondo cada tipo de nodo.

Nodo B

El modo de nodo B utiliza mensajes de difusión para el registro y la resolución de nombres. Por ejemplo, si una computadora llamada NT_PC1 desea comunicarse con una computadora llamada NT_PC2, NT_PC1 envía un mensaje de difusión en el que busca a NT_PC2. Luego espera un tiempo especificado para que NT_PC2 responda.

El modo de nodo B tiene dos problemas principales:

• En un entorno grande, carga la red con mensajes de difusión.
• Por lo general, los enrutadores no reenvían mensajes de difusión, por lo que las computadoras en lados opuestos de un enrutador nunca reciben las solicitudes.

Ejemplos de computadoras en la red que podrían ser clientes de nodo B incluyen computadoras que ejecutan MS-DOS, Windows 3.1 o Windows para Grupos de Trabajo y que no tienen software cliente de WINS instalado. Los servidores posibles incluyen servidores de red basados en SMB (Server Message Block), como IBM LAN Server, DEC PATHWORKS, AT&T StarLAN y LAN Manager para sistemas UNIX o OS/2.

Los 8 pasos para solucionar problemas de red y sistemas

Nodo P

El modo de nodo P aborda los problemas que el nodo B no resuelve. En un entorno de nodo P, las computadoras ni crean ni responden a mensajes de difusión. Todas las computadoras se registran con el servidor de WINS, que es responsable de conocer los nombres y direcciones de las computadoras y de asegurar que no existan nombres duplicados en la red.

En este entorno, cuando NT_PC1 desea comunicarse con NT_PC2, consulta al servidor WINS para obtener la dirección de NT_PC2. Una vez que recibe la dirección, NT_PC1 se conecta directamente a NT_PC2 sin realizar una difusión. Dado que las consultas de nombres se envían directamente al servidor WINS, el modo de nodo P evita saturar la red con mensajes de difusión. Dado que no se utilizan mensajes de difusión y la dirección se recibe directamente, las computadoras pueden estar en lados opuestos de enrutadores.

Los problemas más significativos con el nodo P son:

• Todas las computadoras deben estar configuradas para conocer la dirección del servidor WINS.
• Si el servidor WINS está inactivo, las computadoras que dependen de él para resolver direcciones no pueden acceder a otros sistemas en la red.

Nodo M

El modo de nodo M se creó principalmente para resolver los problemas asociados con los modos de nodo B y nodo P. En un entorno de nodo M, una computadora primero intenta el registro y la resolución con el nodo B. Si eso falla, cambia al nodo P. Las ventajas incluyen:

• El nodo M puede atravesar enrutadores.
• Dado que el nodo B siempre se intenta primero, las computadoras en el mismo lado de un enrutador siguen funcionando normalmente si el servidor WINS está inactivo.
• En teoría, el uso de nodo M debería mejorar el rendimiento de la LAN.

Nodo H

El modo de nodo H resuelve los problemas más significativos asociados con los mensajes de difusión y las operaciones en entornos de enrutamiento. Este modo es una combinación de los modos de nodo B y nodo P que utiliza mensajes de difusión como último recurso. El modo de nodo H hace más que cambiar el orden de uso de los modos de nodo B y nodo P: si el servidor WINS está inactivo y los mensajes de difusión son necesarios, la computadora sigue consultando al servidor WINS. Cuando se puede acceder nuevamente al servidor WINS, el sistema vuelve al modo de nodo P. El nodo H también se puede configurar para usar el archivo LMHOSTS después de que la resolución de nombres por difusión falle.

Dado que se utiliza primero el nodo P, no se generan mensajes de difusión si el servidor WINS está funcionando, y las computadoras pueden estar en lados opuestos de enrutadores. Si el servidor WINS está inactivo, se utiliza el nodo B, por lo que las computadoras en el mismo lado de un enrutador siguen funcionando normalmente.

Diferencias entre redes cliente/servidor y peer-to-peer

Otras combinaciones

Existe otra variación, conocida como nodo B modificado, que también se utiliza en redes de Microsoft para permitir que los mensajes atraviesen enrutadores. El nodo B modificado no utiliza el modo de nodo P ni un servidor WINS. En este modo, el nodo B utiliza una lista de computadoras y direcciones almacenadas en un archivo LMHOSTS. Si un intento del nodo B falla, el sistema busca un nombre en LMHOSTS y luego utiliza la dirección asociada para atravesar el enrutador. Sin embargo, cada computadora debe tener esta lista, lo que crea una carga administrativa porque la lista debe mantenerse y distribuirse. Tanto Windows for Workgroups 3.11 como LAN Manager 2.x utilizaban este sistema de nodo B modificado. Windows NT utiliza este método si no se utilizan servidores WINS en la red. En Windows NT, se han agregado algunas extensiones a este archivo para facilitar la administración, pero el nodo B modificado no es una solución ideal.

Algunos sitios pueden requerir tanto los modos de nodo B como de nodo P. Aunque esta configuración puede funcionar, los administradores deben tener cuidado extremo y utilizarla solo en situaciones de transición. Dado que los hosts de nodo P ignoran los mensajes de difusión y los hosts de nodo B dependen de los mensajes de difusión para la resolución de nombres, es posible que los dos hosts estén configurados con el mismo nombre de NetBIOS, lo que daría resultados impredecibles. Además, si una computadora configurada para utilizar el nodo B tiene una asignación estática en la base de datos WINS, una computadora configurada para utilizar el nodo P no podrá utilizar el mismo nombre de computadora.

Las computadoras que ejecutan Windows NT se pueden configurar como agentes de proxy de WINS para ayudar en la transición hacia el uso de WINS. Los clientes de redes basadas en Windows (computadoras con Windows NT, Windows 95 o Windows for Workgroups 3.11 compatibles con WINS) pueden utilizar WINS directamente. Las computadoras sin WINS que son compatibles con el nodo B (como se describe en los RFC 1001 y 1002) pueden acceder a WINS a través de proxies. Un proxy de WINS es una computadora habilitada para WINS que escucha los mensajes de difusión de consulta de nombres y luego responde por los nombres que no están en la subred local. Los proxies son computadoras de nodo P.

Cambiando el tipo de nodo

Cuando configuras TCP/IP, no encontrarás una forma de establecer el tipo de nodo. El tipo de nodo se establece automáticamente durante la configuración de TCP/IP. Los tipos de nodo TCP/IP predeterminados en Windows 95 son:
Si DHCP=False y WINS está desactivado, entonces el tipo de nodo es b-node (0x01)
Si DHCP=False y WINS está configurado manualmente, entonces el tipo de nodo es h-node (0x08)
Si DHCP=True y DHCP establece WINS, entonces el tipo de nodo es h-node (0x08)
Si DHCP=True y WINS está configurado manualmente, entonces el tipo de nodo es h-node (0x08)
Si DHCP=True y WINS está desactivado, entonces el tipo de nodo es b-node (0x01)
Si se proporcionan opciones de servidor WINS a través de DHCP, el tipo de nodo debe establecerse utilizando la opción 46 de DHCP; sin embargo, si se define localmente un servidor WINS en el cliente, estas dos opciones se anularán porque los servidores WINS definidos localmente establecen automáticamente el tipo de nodo en h-node.

El tipo de nodo se puede cambiar manualmente editando el Registro de Windows 95. La ubicación existe en la subclave del siguiente subárbol del HKEY_LOCAL_MACHINE:
SYSTEM\CURRENTCONTROLSET\SERVICES\VXD\MSTCP\Node Type

El tipo de nodo se puede agregar como un valor de cadena en MSTCP si aún no existe.

Qué son los switches Cisco y cómo funcionan

La solicitud de inicio de sesión

Ahora, examinemos qué sucede después de que el cliente ingresa el nombre de usuario, la contraseña y la información del dominio y hace clic en Aceptar en la ventana de inicio de sesión (antes de que se atienda la solicitud de inicio de sesión). Windows 9x y Windows NT se comportan de manera ligeramente diferente, así que los discutiremos por separado.

Cliente Windows 9x

El cliente intenta encontrar un controlador de dominio de acuerdo con el tipo de nodo con el que se haya configurado. A continuación, se muestra una secuencia de eventos muy simplificada:

1. Un cliente de nodo B emitirá una solicitud de difusión. Si un servidor no responde, el inicio de sesión fallará.
2. Un cliente de nodo P solicitará la lista <1C> al servidor WINS. Luego enviará una solicitud de difusión a cada uno de los servidores en la lista <1C>, empezando por el primero (el PDC).
3. Los clientes de nodo M y de nodo H hacen las dos cosas en el orden descrito anteriormente, excepto que, si el nombre del grupo de trabajo del cliente es el mismo que el dominio de la cuenta a la que se está intentando el inicio de sesión, la búsqueda WINS de controladores de dominio en la subred local se saltea. Si el servidor WINS está activo y alcanzable, significa que el primer controlador de dominio en la lista <1C> que responda siempre manejará la solicitud de inicio de sesión.

Como se mencionó anteriormente, para garantizar que el cliente sea validado por el controlador de dominio local, debes hacer que el nombre del grupo de trabajo sea el mismo que el dominio representado por ese controlador de dominio. Sin embargo, si deseas usar grupos de trabajo dentro del entorno de la oficina, este método de garantizar la validación local puede no ser aceptable. En este caso, el tipo de nodo debe establecerse en m para asegurarse de que el cliente emita una difusión en la subred local inicialmente para tener una mejor oportunidad de que el controlador de dominio local responda primero. Ten en cuenta que no es una regla fija. El controlador de dominio solo necesita estar un poco ocupado, algo que los servidores de sitios remotos a menudo estarán porque es habitual que los administradores coloquen un solo controlador de dominio en un sitio remoto, y un controlador de dominio no local más receptivo podría atender la solicitud primero.

Alternativamente, se podría instalar WINS en el controlador de dominio local y los clientes podrían usarlo como el servidor WINS principal. Este método puede ser una buena idea si los usuarios rara vez acceden a recursos fuera de la sucursal local, pero supone una carga adicional para el servidor, que probablemente esté proporcionando servicios de archivos e impresión, DHCP, SQL, Exchange y otras funciones.

Si el nombre del grupo de trabajo es diferente al dominio de la cuenta, entonces el uso del modo de nodo M aumentará las posibilidades de que la solicitud de inicio de sesión se atienda localmente.

Cliente de Windows NT

El inicio de sesión en Windows NT es algo diferente al inicio de sesión en Windows 9x: el cliente NT Workstation tiene un ID de máquina en un dominio. Por lo tanto, el cliente pasa por cuatro pasos para la validación del inicio de sesión. Primero, el cliente NT Workstation valida su ID de máquina con los controladores de dominio del dominio de recursos y luego envía la información de inicio de sesión del usuario para la validación interna. El controlador de dominio del dominio de recursos pasa la información de inicio de sesión a un controlador de dominio en el dominio de la cuenta. El controlador de dominio del dominio de recursos luego devuelve la información de autenticación del usuario (recibida del controlador de dominio del dominio de la cuenta) al usuario.

Técnicas para mejorar la seguridad en redes peer-to-peer

Independientemente de si los usuarios han iniciado sesión o no, los clientes de NT Workstation pasan por la validación del ID durante la inicialización y según sea necesario más adelante (por ejemplo, si alguien inicia sesión en la máquina NT con el perfil en caché local porque el controlador de dominio de recursos está inactivo).

Primero viene la resolución de nombres de los controladores de dominio. El cliente NT Workstation debe localizar un controlador de dominio del dominio de recursos. El proceso de descubrimiento utilizado por un cliente NT Workstation para encontrar un controlador de dominio del dominio de recursos es el mismo que el utilizado por el controlador de dominio del dominio de recursos para establecer una conexión de confianza con un controlador de dominio del dominio de cuenta.

A continuación, se valida el ID de máquina de NT. El cliente NT Workstation siempre envía una difusión de inicio de sesión local a Resource-Domain <1C> antes de enviar solicitudes de inicio de sesión unicast a los controladores de dominio del dominio de recursos obtenidos de WINS.

El cliente valida el ID de máquina de NT con el primer controlador de dominio del dominio de recursos que responda a la solicitud de inicio de sesión.

El cliente NT Workstation solicita al controlador de dominio del dominio de recursos que enumere la lista de dominios en los que confía. Los nombres de dominio obtenidos se muestran en el cuadro desplegable Dominio de la ventana de inicio de sesión.

El cliente NT Workstation pasa las credenciales de inicio de sesión del usuario al controlador de dominio del dominio de recursos y solicita una autenticación directa.

Cómo cargar y descargar módulos del kernel de Linux: una guía completa

El controlador de dominio del dominio de recursos pasa las credenciales de inicio de sesión del usuario al controlador de dominio del dominio de cuenta con el que ha establecido una conexión de confianza y le solicita que autentique al usuario. Luego, pasa la información de validación al cliente NT Workstation.

El cliente NT Workstation obtiene el nombre del controlador de dominio del dominio de cuenta del controlador de dominio del dominio de recursos para conectarse y ejecutar el script/perfil de inicio de sesión, si está configurado.

El usuario de NT ahora ha iniciado sesión en el dominio de cuenta, ha ejecutado un script de inicio de sesión y ha realizado conexiones de red adecuadas a los directorios personales.

Por supuesto, si el ID de máquina está registrado con un dominio fuera de la subred local o si el usuario está iniciando sesión en un dominio que no tiene un controlador de dominio en la subred local, el proceso de inicio de sesión requerirá comunicación a través de la WAN. Si es una conexión lenta, el proceso de inicio de sesión se prolongará.

Conclusión

Con los clientes de Windows 9x, lograr la autenticación local se logra haciendo que el nombre del grupo de trabajo sea el mismo que el dominio de inicio de sesión o mediante el uso del modo de nodo B o M para garantizar que la solicitud de inicio de sesión se difunda inicialmente en la subred local. Obviamente, el nodo B no es muy versátil y provocará un inicio de sesión fallido si el controlador de dominio local no responde rápidamente.

Con los clientes de Windows NT, debe haber un controlador de dominio de recursos y un controlador de dominio de cuenta en el segmento local (puede ser un solo servidor si el dominio de recursos y el dominio de cuenta son los mismos).

Control de acceso en tiempo real con PAM: ¡No pierdas ni un minuto!

Puedes mejorar el proceso aún más teniendo múltiples servidores WINS y dirigiendo a los clientes al servidor WINS que registrará el controlador de dominio local, o el más cercano, en la lista <1C>.

En Newsmatic nos especializamos en tecnología de vanguardia, contamos con los artículos mas novedosos sobre Redes, allí encontraras muchos artículos similares a Cómo garantizar la validación local de los clientes en un dominio multi-sitio , tenemos lo ultimo en tecnología 2023.