Tipos de nodos TCP/IP e inicio de sesión de cliente

Cuando está creando un dominio de varios sitios enrutado a través de varias subredes, puede suponer que colocar un controlador de dominio de copia de seguridad en un sitio remoto garantizará que los clientes de ese sitio se validen localmente. El propósito, por supuesto, es doble: reducir el tráfico que irá fuera de la LAN a través de un enlace costoso y garantizar que los inicios de sesión de los clientes no se retrasen por la velocidad (o la falta de ella) de la conexión WAN. La instalación de un controlador de dominio local puede funcionar, pero ¿tendrá éxito por diseño o por accidente?
Desafortunadamente, no hay forma de especificar el controlador de dominio que validará un cliente determinado, ya sea que ese cliente ejecute Windows NT Server, Windows NT Workstation o Windows 9x. Las versiones anteriores de Windows funcionarán de la misma manera, siempre que utilicen la pila TCP/IP de 32 bits o una pila TCP/IP de 16 bits compatible con WINS.
En este análisis Detallado Diario, le 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 un equipo cliente para atender su solicitud de inicio de sesión.
Background
Para aquellos de ustedes que no están familiarizados con el concepto de dominios de Windows NT, aquí hay un repaso rápido: Un dominio NT es una colección de servidores habilitados para la red y otros equipos que comparten información de seguridad y cuenta común. El dominio proporciona administración centralizada de usuarios, equipos y redes. La información de seguridad se almacena en una base de datos central en un servidor designado y configurado como controlador de dominio principal (PDC) y replicado en otros servidores especiales, designados y configurados como controladores de dominio de copia de seguridad (BDC). Solo un servidor puede ser el PDC a la vez, pero este rol especial se puede transferir a cualquier BDC según sea necesario. Cuando un cliente que ejecuta TCP / IP intenta iniciar sesión en este dominio NT, la solicitud de inicio de sesión es procesada por cualquiera de los controladores de dominio de la red que pertenecen al mismo dominio.
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 identificados como tipo <1C>. Por razones que solo ellos conocen, los diseñadores de WINS decidieron 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. Los clientes reciben esta lista cuando intentan encontrar un controlador de dominio para atender su solicitud de inicio de sesión.

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

1. Entradas de controlador de dominio registradas con el servidor WINS, en el orden de las entradas de controlador de dominio actualizadas más recientemente a las menos actualizadas
2. obtenidas de la replicación con otros servidores WINS
3. La primera entrada es siempre el PDC

Nodos
Al configurar TCP/IP en un cliente, una de las opciones que puede ver (dependiendo de en 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.
Hay cuatro tipos de nodos en TCP / IP:

• Nodo B (nodo de difusión) : Cuando un cliente necesita encontrar un controlador de dominio, realizará una difusión. Al primer controlador de dominio que responda se le entregará el trabajo de atender la solicitud de inicio de sesión.
• nodo P (nodo punto a punto): En este entorno, las consultas de nombre van directamente al servidor WINS.
• Nodo M (nodo de varios nodos): Un entorno de nodo m utiliza primero el nodo b y luego, si es necesario, 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 cada tipo de nodo más a fondo.
Nodo B
El modo nodo b utiliza mensajes de difusión para el registro y la resolución de nombres. Por ejemplo, si un equipo llamado NT_PC1 quiere comunicarse con un equipo llamado NT_PC2, NT_PC1 envía un mensaje de difusión que está buscando NT_PC2. A continuación, espera un tiempo especificado para que NT_PC2 responda.
El 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 escuchan las solicitudes.

Los ejemplos de equipos de la red que podrían ser clientes de nodo b incluyen equipos que ejecutan MS-DOS, Windows 3.1 o Windows para grupos de trabajo que no tienen instalado el software de cliente WINS. Los servidores posibles incluyen servidores de red basados en bloques de mensajes de servidor (SMB), como IBM LAN Server, DEC PATHWORKS, AT&T StarLAN y LAN Manager para sistemas OS/2 o UNIX.
P-node
El modo p-node soluciona los problemas que b-node no resuelve. En un entorno de nodo p, los equipos no crean ni responden a mensajes de difusión. Todos los equipos se registran en el servidor WINS, que es responsable de conocer los nombres y direcciones de los equipos y de garantizar que no existan nombres duplicados en la red.

En este entorno, cuando NT_PC1 quiere comunicarse con NT_PC2, consulta al servidor WINS la dirección de NT_PC2. Al recibir la dirección, NT_PC1 va directamente a NT_PC2 sin emitir. Dado que las consultas de nombre van directamente al servidor WINS, p-node evita cargar la red con mensajes de difusión. Dado que los mensajes de difusión no se utilizan y la dirección se recibe directamente, las computadoras pueden estar en lados opuestos de los enrutadores.
Los problemas más significativos con el nodo p son:

• Todos los equipos deben estar configurados para conocer la dirección del servidor WINS.
• Si el servidor WINS no funciona, los equipos que dependen de él para resolver direcciones no pueden acceder a ningún otro sistema de la red.

Nodo M
El modo nodo m se creó principalmente para resolver los problemas asociados con el nodo b y el nodo p. En un entorno de nodo m, un equipo primero intenta el registro y la resolución con nodo b. Si eso falla, cambia a p-node. Las ventajas incluyen:

• M-node puede cruzar enrutadores
• Dado que el nodo b siempre se prueba primero, los equipos del mismo lado de un enrutador continúan funcionando como de costumbre si el servidor WINS está inactivo
• En teoría, el uso de m-node debería aumentar el rendimiento de la LAN

Nodo H
El modo nodo h resuelve los problemas más importantes asociados con los mensajes de difusión y las operaciones de entorno enrutado. Este modo es una combinación de nodo b y nodo p que utiliza mensajes de difusión como último recurso. El modo nodo-h hace más que cambiar el orden de uso de nodo-b y nodo-p: Si el servidor WINS está inactivo, lo que hace que los mensajes de difusión sean una necesidad, el equipo continúa sondeando el servidor WINS. Cuando se puede llegar de nuevo al servidor WINS, el sistema vuelve a p-node. El nodo H también se puede configurar para usar el archivo LMHOSTS después de que falle la resolución del nombre de difusión.
Dado que p-node se usa primero, no se generan mensajes de difusión si el servidor WINS se está ejecutando, y los equipos pueden estar en lados opuestos de los enrutadores. Si el servidor WINS no funciona, se utiliza el nodo b, de modo que los equipos del mismo lado de un enrutador siguen funcionando como de costumbre.
Otras combinaciones
Otra variación, conocida como nodo b modificado, también se utiliza en redes de Microsoft para que los mensajes puedan ir a través de enrutadores. El nodo b modificado no utiliza el modo nodo p ni un servidor WINS. En este modo, b-node utiliza una lista de equipos y direcciones que se almacenan en un archivo LMHOSTS. Si un intento de nodo b falla, el sistema busca en LMHOSTS un nombre y luego usa la dirección asociada para cruzar 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 para Grupos de trabajo 3.11 como LAN Manager 2.x usó un sistema de nodos 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 que sea más fácil de administrar, pero el nodo b modificado no es una solución ideal.

Algunos sitios pueden requerir los modos nodo b y nodo p. Aunque esta configuración puede funcionar, los administradores deben tener extrema precaución y usarla solo para situaciones de transición. Dado que los hosts de nodo p no tienen en cuenta los mensajes de difusión y los hosts de nodo b dependen de los mensajes de difusión para la resolución de nombres, los dos hosts pueden configurarse potencialmente con el mismo nombre NetBIOS, lo que genera resultados impredecibles. Además, si un equipo configurado para usar b-node tiene una asignación estática en la base de datos WINS, un equipo configurado para usar p-node no puede usar el mismo nombre de equipo.
Los equipos que ejecutan Windows NT se pueden configurar como agentes proxy WINS para facilitar la transición al uso de WINS. Los clientes de red basados en Windows (equipos Windows NT, Windows 95 o Windows para grupos de trabajo 3.11 habilitados para WINS) pueden usar WINS directamente. Los equipos no WINS compatibles con nodos b (como se describe en los RFC 1001 y 1002) pueden acceder a WINS a través de proxies. Un proxy WINS es un equipo habilitado para WINS que escucha los mensajes de difusión de consulta de nombres y, a continuación, responde a los nombres que no están en la subred local. Los proxies son ordenadores de nodo p.
Al configurar TCP, no encontrará ninguna forma de establecer el tipo de nodo. El tipo de nodo se establece en un valor predeterminado durante la configuración TCP. Los tipos de nodos TCP/IP predeterminados de Windows 95 son:
Si DHCP=False y WINS está deshabilitado, entonces el Tipo de nodo b-node (0x01)
Si DHCP=False y WINS se establece manualmente, luego el Tipo de nodo h-node (0x08)
Si DHCP=True y DHCP establece WINS, luego el Tipo de nodo h-node (0x08)
Si DHCP=True y WINS se establece manualmente, luego el Tipo de nodo h-node (0x08)
Si DHCP=True, y WINS está deshabilitado, entonces el tipo de nodo b-nodo (0x01)
Si las opciones del servidor WINS se proporcionan a través de DHCP, el Tipo de nodo se debe establecer con la opción 46 de DHCP; sin embargo, la definición local de un servidor WINS en el cliente anulará estas dos opciones porque los servidores WINS definidos localmente establecen automáticamente el tipo de nodo en nodo h.
El tipo de nodo se puede cambiar manualmente editando el Registro de Windows 95. La ubicación existe en el subárbol HKEY_LOCAL_MACHINE bajo la subclave
SYSTEM\CURRENTCONTROLSET \ SERVICES \ VXD\MSTCP \ Node Type
NodeType se puede agregar como un valor de cadena en MSTCP si aún no existe.

La solicitud de inicio de sesión
Ahora, veamos qué ocurre después de que el cliente ingrese el nombre de usuario, la contraseña y la información de dominio y haga clic en Aceptar en la ventana de solicitud de inicio de sesión (antes de que se realice el servicio de la solicitud de inicio de sesión). Windows 9x y Windows NT se comportan de manera ligeramente diferente, por lo que los discutiré por separado.
Cliente Windows 9x
El cliente intenta encontrar un controlador de dominio de una manera definida por el tipo de nodo con el que se ha configurado. A continuación se muestra una secuencia de eventos muy simplificada:

1. Un cliente de nodo b emitirá una solicitud. Si un servidor no responde, el inicio de sesión fallará.
2. Un cliente de nodo p solicitará la lista <1C> del servidor WINS. A continuación, transmitirá una solicitud a cada uno de los servidores de la lista <1C>, comenzando por la primera (el PDC).
3. Los clientes nodo m y nodo h hacen ambas cosas en el orden descrito anteriormente, excepto que, si el nombre del grupo de trabajo del cliente es el mismo que el dominio de cuenta al que se intenta iniciar sesión, se omite la búsqueda de controladores de dominio WINS en la subred local. Siempre que el servidor WINS esté activo y accesible, significa que el primer controlador de dominio de la lista <1C> que responda siempre gestionará la solicitud de inicio de sesión.

Como se mencionó anteriormente, para garantizar que el cliente esté validado por el controlador de dominio local, debe hacer que el nombre del grupo de trabajo sea el mismo que el dominio representado por ese controlador de dominio. Sin embargo, si desea utilizar grupos de trabajo dentro del entorno de oficina, es posible que este método para garantizar la validación local no sea aceptable. En este caso, el tipo de nodo debe establecerse en m para garantizar que el cliente difunda en la subred local inicialmente, de modo que haya una mayor probabilidad de que el controlador de dominio local responda primero. Tenga en cuenta que no es una regla dura y rápida. El controlador de dominio solo necesita estar un poco ocupado, lo que a menudo ocurre con los servidores de sitios remotos 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 entrar primero.
Alternativamente, WINS podría instalarse en el controlador de dominio local y los clientes podrían usarlo como servidor WINS principal. Este método puede ser una buena idea si los usuarios rara vez acceden a recursos fuera de la rama local, pero es una carga adicional para el servidor, que probablemente está proporcionando servicios de archivos e impresión, DHCP, SQL, Exchange y otras tareas.

Si el nombre del grupo de trabajo es diferente del dominio de la cuenta, el uso de m-node aumentará las posibilidades de que la solicitud de inicio de sesión sea atendida localmente.
Cliente Windows NT
El inicio de sesión de Windows NT es algo diferente del inicio de sesión de Windows 9x: la estación de trabajo NT tiene un ID de máquina en un dominio. Por lo tanto, el cliente pasa por cuatro pasos para la validación de inicio de sesión. En primer lugar, el cliente de estación de trabajo NT valida su ID de máquina con los controladores de dominio del dominio de recursos y, a continuación, envía la información de inicio de sesión del usuario para la validación de transferencia. El controlador de dominio del dominio de recursos pasa la información de inicio de sesión a un controlador de dominio del dominio de la cuenta. A continuación, el recurso controlador de dominio-dominio devuelve la información de autenticación del usuario (recibida de la cuenta controlador de dominio-dominio) al usuario.
Independientemente de que los usuarios inicien sesión en ellos o no, los clientes de la estación de trabajo NT pasan por la validación de 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 de estación de trabajo NT debe localizar un dominio de recurso: controlador de dominio. El proceso de detección que utiliza un cliente de estación de trabajo NT para encontrar un controlador de dominio de recursos es el mismo que utiliza el controlador de dominio de dominio de dominio de recursos para establecer una conexión de confianza con un controlador de dominio de dominio de cuenta.
A continuación, se valida el ID de máquina NT. El cliente de estación de trabajo NT siempre envía una transmisión de inicio de sesión local al Dominio de recursos < 1C> antes de enviar solicitudes de inicio de sesión unicast a controladores de dominio de dominio de recursos que se obtienen de WINS.
El cliente valida el ID de máquina de la estación de trabajo NT, con el primer controlador de dominio del dominio de recursos que responde a la solicitud de inicio de sesión.
El cliente de estación de trabajo NT solicita al controlador de dominio-dominio de recursos que enumere la lista de dominios de confianza. Los nombres de dominio obtenidos se muestran en el cuadro desplegable Dominio de la ventana de inicio de sesión.

El cliente de estación de trabajo NT pasa las credenciales de inicio de sesión del usuario al dominio de recursos: controlador de dominio y solicita autenticación de transferencia.
El controlador de dominio de dominio de recurso pasa las credenciales de inicio de sesión del usuario a la cuenta controlador de dominio de dominio con el que ha establecido una conexión de confianza y le solicita que autentique al usuario. A continuación, devuelve la información de validación al cliente de la estación de trabajo NT.
El cliente de estación de trabajo NT obtiene el nombre de la cuenta dominio-controlador de dominio del recurso dominio-controlador de dominio para conectarse y ejecutar el script/perfil de inicio de sesión, si se ha configurado.
El usuario NT ahora ha iniciado sesión en el dominio de la cuenta, ha ejecutado un script de inicio de sesión y ha realizado las conexiones de red adecuadas a los directorios personales.
Por supuesto, si el ID de la máquina está registrado con un dominio fuera de la subred local o si el usuario inicia 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 se trata de un enlace lento, el proceso de inicio de sesión se extenderá.
Conclusión
Con los clientes Windows 9x, la autenticación local se consigue haciendo que el nombre del grupo de trabajo sea el mismo que el inicio de sesión, la cuenta, el dominio o mediante el modo b o el nodo m para garantizar que la solicitud de inicio de sesión se difunda primero localmente. Obviamente, el nodo b no es muy versátil y causará un inicio de sesión fallido si el controlador de dominio local no responde rápidamente.
Con los clientes Windows NT, debe haber un controlador de dominio de recursos y un controlador de dominio de cuenta en el segmento local. (Podría ser un solo servidor si los dominios de recursos y cuentas son los mismos.)
Puede mejorar aún más el proceso teniendo varios servidores WINS y apuntando a los clientes al servidor WINS que registrará el controlador de dominio local o más cercano en la lista <1C>.

La carrera informática de Richard Charrington comenzó cuando comenzó a trabajar con PCs, cuando eran conocidos como microcomputadoras. Comenzando como programador, se abrió camino hasta las alturas de un administrador de sistemas Windows NT, y ha hecho casi todo en el medio. Richard ha estado trabajando con Windows desde antes de que tuviera una interfaz gráfica de usuario adecuada y con Windows NT desde que era LanManager. Ahora un contratista, se ha deslizado en la escritura de scripts para Windows NT y ha construido algunas utilidades de autoadministración muy útiles.

Los autores y editores han tenido cuidado en la preparación del contenido aquí contenido, pero no ofrecen ninguna garantía expresa o implícita de ningún tipo y no asumen ninguna responsabilidad por errores u omisiones. No se asume ninguna responsabilidad por daños y perjuicios. Siempre tenga una copia de seguridad verificada antes de realizar cualquier cambio.