Usando Samba - Implementaciones de Microsoft

Con todo lo anterior de fondo, ahora podemos hablar sobre algunas de la implementaciones de Microsoft sobre los anteriores conceptos del mundo de las redes CIFS/SMB. Y como te esperas, también introduciremos sobre algunas más complejas extensiones.

Dominio Windows

Recuerda que un grupo de trabajo es una colección de computadoras SMB, las cuales residen todas en la misma subred y se encuentran suscritas al mismo grupo SMB. Un Dominio Windows va un paso más allá. Es un grupo de trabajo de máquinas SMB que tienen una añadido: un servidor que actúa como controlador de dominio. Debes tener un controlador de dominio para poder tener un dominio Windows [6]. Por otra parte, se trata sólo de un grupo de trabajo. Mira la Figura 11. [6] Los dominios Windows son llamados "Dominios Windows NT" por Microsoft porque ellos asumen que serán máquinas Windows NT las que asuman el papel de controladoras de dominio. Sin embargo, como Samba puede realizar ésta función también, nosotros simplemente hablaremos de "Dominios Windows" para evitar confusiones.

Figure: Un Simple Dominio Windows.

Hay actualmente dos protocolos separados usados por un controlador de dominio (logon server): uno para comunicar con máquinas Windows 95/98 y otro para comunicar con máquinas Windows NT. Mientras que Samba actualmente imlementa el protocolo controlador de dominio para máquinas Windows 95/98 (lo cual nos permite actuar como controlador de dominio para máquinas Windows 9 x), todavía no está completamente soportado el protocolo para máquinas Windows NT. Sin embargo, el equipo de desarrollo de Samba promete que dicho soporte para el protocolo controlador de dominio para máquinas Windows NT estará en la versión Samba 2.1.

¿Por qué tanta complejidad? El protocolo que el controlador de dominio de Windows usa para comunicar con sus clientes y con otros controladores de dominio es propietario y no ha sido liberado por Microsoft. Esto ha forzado al equipo de Samba a utilizar una ingerniería inversa sobre el protocolo controlador de dominio para ver qué códigos realizan qué taréas.

Controlador de Dominio

El controlador de dominio es el centro nervioso de un dominio Windows, tal como un servidor NIS lo es del servicio de información de una red Unix. Los controladores de dominio tienen una serie de responsabilidades. Una de las que te va a implicar a ti es la autentificación. La autentificación es el proceso de garantizar o denegar a un usuario el acceso a recursos compartidos o a otra máquina de la red, normalmente a través del uso de una password.

Cada controlador de dominio usa un security account manager (SAM) para mantener una lista de combinaciones nombre_usuario-contraseña. El controlador de dominio entonces forma una central repositoria de passwords que están enlzadas a nombres de usuarios (una password por usuario), lo cual es más eficiente que mantener en cada máquina cliente centenares de passwords para cada recurso de red disponible.

En un dominio Windows, cuando un cliente no autorizado solicita acceso a los recursos compartidos de un servidor, el servidor actúa y pregunta al controlador de dominio si ese usuario está autentificado. Si lo está, el servidor establecerá una conexión de sesión con los derechos de acceso correspondientes para ese servicio y usuario. Si no lo está, la conexión es denegada. Una vez un usuario es autentificado por el controlador de dominio, una ficha especial de autentificación será retornada al cliente, de manera que el usuario no necesitará relogearse a otros recursos en ese dominio. En éste punto, el usuario se considera "logeado" en el dominio. Mira la Figura 12.

Controlador de Dominio Primario y de Seguridad

La redundancia es una idea clave dentro de un dominio Windows. El controlador de dominio que está actualmente activo sobre un dominio es denominado como el Controlador Primario de Dominio (PDC). Además pueden existir uno o más Controladores de Dominio de Seguridad (BDCs) en el dominio, los cuales actuarán en caso de que el controlador primario falle o se vuelva inaccesible. Los BDCs frecuentemente sincronizan sus datos SAM con el controlador primario de dominio, de manera que si llegara el caso, cualquiera de ellos podría realizar servicios DC transparentemente sin provocar ningún tipo de impacto en los clientes. Advierte que los BDCs, sin embargo, sólo tienen copias de sólo lectura del SAM; pueden actualizar sus datos sólo mediante la sincronización con un PDC. Un servidor en un dominio Windows puede usar los SAM de cualquier controlador de dominio primario o de seguridad para autentificar a un usuario que intenta acceder a los recursos y logearse en el dominio.

Ten en cuenta que en muchos aspectos, las características de un grupo de trabajo de Windows y un dominio de Windows se pisan. Esto no es algo accidental, ya que el concepto de los dominios Windows no apareció hasta la aparición de Windows NT 3.5, y los dominios Windows fueron forzados a permanecer compatibles con los grupos de trabajo presentes en Windows for Workgroups 3.1. La cosa clave a recordar aquí es que un dominio es simplemente un grupo de trabajo de Windows con uno o más controladores de dominio añadidos.

Samba puede funcionar como controlador primario de dominio para máquinas Windows 95/98 sin ningún tipo de problemas. Sin embargo, Samba 2.0 puede actuar como controlador primario de dominio sólo para procesos de autentificación; actualmente no puede asumir ninguna otra de las responabilidades de un PDC. (mientras lees este manual, Samba 2.1 puede que ya esté disponible, de forma que podrás usar Samba como PDC para clientes NT). Por otra parte, y "gracias" a la privacidad del protocolo usado por Microsoft para sincronizar datos SAM, Samba actualmente no puede servir como controlador de dominio de seguridad.

Visualización (Browsing)

La visualización, navegación o browsing es una respuesta de alto nivel para la pregunta del usuario: "¿Qué máquinas están ahí en la red Windows?". Recuerda que no hay conexión alguna con un navegador web, aparte de la idea general de "descubrir qué hay por ahí fuera". Y, al igual que en la web, lo que está ahí fuera puede cambiar sin previo aviso.

Antes de visualizar, los usuarios deben connocer el nombre de la máquina específica a la que quieren conectarse desde la red, y entonces manualmente introducir un UNC al como el siguiente en una aplicación o gestor de ficheros para acceder a los recursos:

\\HYDRA\network\
 

Con la visualización, sin embargo, puedes examinar los contenidos de una máquina usando un típico interfaz apuntar-y-hacer-click. Por ejemplo, la ventana de Entorno de Red desde un cliente Windows.

Niveles de Visualización

Como indicamos al principio del capítulo, existen actualmente dos tipos de visualización, navegación o browsing con los que te podrás encontrar en una red SMB/CIFS:

• Visualizar una lista de máquinas (con recursos compartidos).
• Visualizar los recursos compartidos de una máquina determinada.

Veamos el primero de ellos. En cada subred de cada grupo de trabajo Windows (o dominio), una computadora tiene la responsabilidad de mantener una lista de las máquinas que están actualmente accesibles a través de la red. Esta computadora es denominada la visualizadora local maestra, y la lista que mantiene es llamada la Lista de Visualización. Las máquinas de una subred usan la lista de visualización para reducir la cantidad de tráfico de la red que se genera durante la visualización. En vez de que cada máquina genere su propia lista de máquinas disponibles, la computadora puede simplemente interrogar al visualizador maestro local para obtener una completa y actualizada lista.

Para visualizar los recursos actuales de una máquina, un usuario debe conectar a la máquina específica; esa información no puede ser obtenida de la lista de visualización. El ver la lista de recursos compartidos de una máquina se puede hacer haciendo click cobre el icono que la representa en la ventana de Entorno de Red de Windows 95/98 o NT. Como ya vimos al principio del capítulo, la máquina responderá con una lista de recursos compartidos que pueden ser accedidos si ese usuario se encuentra debidamente autentificado.

Cada uno de los servidores de un grupo de trabajo de Windows está obligado a anunciar su presencia al visualizador maestro local una vez haya registrado su nombre NetBIOS, y (teóricamente) a anunciar que está dejando el grupo de trabajo cuando se apaga. Es responsabilidad del visualizador maestro local registrar las máquinas. Advierte que el visualizador maestro local no tiene por qué ser necesariamente la misma máquina que el servidor de nombres NetBIOS (NBNS), sobre el cual hablamos anteriormente.

ADVERTENCIA: El Entorno de Red de Windows puede comportarse de forma extraña: hasta que no selecciones una máquina determinada para visualizarla, la ventana del Entrono de Red puede contener datos no actualizados. Esto significa que en la ventana del Entorno de Red pueden aparecer máquinas que están actualmente apagadas, o bien puede obviar a otras máquinas que actualmente están declaradas en el grupo de trabajo. Una vez hayas seleccionado un servidor y hayas conectado a él, entonces puedes tener la seguridad de que los recursos compartidos que muestra realmente existen.

Al contrario de los roles que hemos visto antes, casi cualquier máquina Windows (NT Server, NT Workstation, 98, 95, o Windows 3.1 for Workgroups) puede actuar como visualizador maestro local. Como con los controladores de dominio, el visualizador maestro local puede tener uno o más visualizadores de seguridad en la subred local que pueden actuar en el caso de que el visualizador maestro local falle o se vuelva inaccesible. Para asegurar una operación fluida, los visualizadores de seguridad locales sincronizarán frecuentemente su lista de visualización con el visualizador maestro local. Actualicemos nuestro diagrama de dominio Windows para incluir un visualizador maestro local y otro de seguridad.

Los resultados se muestran en la Figura 13.

Figure: Un dominio Windows con un visualizador maestro local y otro de seguridad.

Aquí tienes cómo calcular el número mínimo de visulizadores de seguridad que deben existir en un grupo de trabajo:

• Si hay entre 1 y 32 Windows NT workstations en la red, o entre 1 y 16 máquinas Windows 95/98 en la red, el visualizador maestro local coloca un visualizador de seguridad en adición al maestro.
• Si el número de Windows NT workstations está entre 33 y 64, o el número de máquinas Windows 95/98 está entre 17 y 32, el visualizador maestro local ubica dos visualizadores de seguridad.
• Por cada grupo de 32 NT workstations o 16 máquinas Windows 95/98 de más,el visualizador maestro local coloca un visualizador de seguridad más.

Actualmente no existe límite de visualizadores de seguridad que se puedan ubicar por parte del visualizador maestro local.

Elección de Visualizador

La visualización es un aspecto crítico de cualquier grupo de trabajo Windows. Sin embargo, no todo funciona perfectamente en cualquier red. Por ejemplo, digamos que el servidor Windows NT del despacho del CEO de una pequeña compañía es el visualizador maestro local -esto es, hasta que él lo apague mientras se va a su sesión de masaje-. En éste punto, la estación de trabajo Windows NT Workstation de la sección del departamento de repuestos podría estar de acuerdo en tomar el relevo. Sin embargo, esa máquina está actualmente ejecutando un programa realmente enorme, pobremente escrito, y que está comiéndose literalmente la capacidad de proceso del microprocesador. La moraleja: la visualización debe ser muy tolerante con los servidores que vienen y van. Debido a que cada máquina Windows puede llegar a actuar como un visualizador, debe existir una forma de decidir en cada momento quién se va a hacer cargo del trabajo. Este proceso de toma de decisión se denomina elección.

Un algoritmo de elección se construye en casi todos los sistemas operativos Windows, de manera que cada uno de ellos puede ponerse de acuerdo con los demás sobre quién va a ser el visualizador maestro local y quiénes van a actuar como visualizadores de seguridad. Una elección puede forzarse en cualquier momento. Por ejemplo, asumamos que el CEO ha finalizado su masaje y reinicia el servidor. Cuando el servidor se activa de nuevo, éste anuncia su presencia y una elección tendrá lugar para ver si el PC en el departamento de repuestos debería continuar siendo el visualizador maestro.

Cuando se realiza una elección, cada máquina difunde información sobre sí misma en forma de datagramas. Esta indormación incluye:

• La versión del protocolo de elección usado.
• El sistema operativo de la máquina.
• La cantidad de tiempo que el cliente ha estado en la red.
• El nombre de host del cliente.

Estos valores determinan qué sistema operativo tiene más potencia y cumplirá mejor el rol de visualizador maestro local. (El Cap. 6, Usuarios Seguridad y Dominios, describe el proceso de elección con más detalle). La arquitectura desarrollada para conseguir esto no es demasiado elegante que digamos, y ha llevado a muchos problemas de seguridad. Mientras que un dominio de visualización puede estar integrado con un dominio de seguridad, el algoritmo de elección no toma en consideración qué computadoras se vuelven visualizadores. Así, es posible para cualquier máquina ejecutar un servicio de visualización para registrarse a sí misma como participante en la elección de visualizador, y (tras ganar) estar habilitada para cambiar la lista de visualización. No obstante, la visualización es un rasgo importante de las redes Windows, y los requerimientos de mantener la compatibilidad con versiones anteriores de s.o. Windows le asegura estar en uso durante muchos años.

¿Puede un Grupo de Trabajo Windows abarcar varias SubRedes?

Sí, pero la mayoría de la gente que se ha metido con esto ha tenido muchos quebraderos de cabeza. Abarcar múltiples subredes no era parte del diseño inicial de Windows NT 3.5 o Windows for Workgroups. Como resultado, un dominio Windows que que abarca dos o más subredes es, en realidad, un "encolado" de dos o más grupos de trabajo que comparten un nombre idéntico. La buena noticia es que todavía podrás usar un controlador primario de dominio para control de autentificación en cada una de las subredes. La mala noticia es que las cosas no son tan sencillas en el caso de la visualización.

Como mencionamos antes, cada subred tiene su propio visualizador maestro local. Cuando un dominio Windows abarca múltiples subredes, un administrador del sistema tendrá que asignar una de las máquinas como el visualizador maestro de dominio. El visualizador maestro de dominio mantendrá una lista de visualización para todo el dominio Windows. Esta lista de visualización es creada por la sincronización periódica de la lista de visualización del visualizador maestro de dominio con las listas de visualización de cada uno de los visualizadores maestros locales. Tras la sincronización, el visualizador maestro y el visualizador maestro de dominio deberían contener entradas idénticas. Mira la Figura 14 como ilustración.

Figure: Un grupo de trabajo que abarca más de una subred.

¿Te suena bien? Bueno, pues eso no es "el cielo" por las siguientes razones:

• Si existe, un controlador primario de dominio siempre juega el papel de visualizador maestro de dominio. Debido al diseño de Microsoft, los dos siempre comparten el tipo de recurso NetBIOS <1B>, y (desafortunadamente) no pueden ser separados.
• Las máquinas Windows 95/98 no pueden convertirse, ni siquiera contactar con un visualizador maestro de dominio. El equipo de Samba cree que esto es una decisiónd e marketing por parte de Microsoft, que fuerza a los consumidores a tener, al menos una máquina Windows NT workstation (o servidor Samba) en cada subred de un grupo de trabajo multi-red.

Cada visualizador maestro de cada subred local continua manteniendo la lista de visualización para su subred, para la cual se vuelve autoritativo. Así, si una computadora desea ver una lista de los servidores dentro de su propia subred, el visualizador maestro local de esa subred será interrogado. Si una computadora quiere ver una lista de servidores fuera de su subred, sólo podrá llegar hasta donde le lleve el visualizador maestro local. Pero esto funciona porque, a intervalos fijados, la lista de visualización autoritativa del visualizador maestro local de una subred es sincronizado con el visualizador maestro de dominio, el cual está sincronizado con el visualizador maestro local de las otras subredes en el dominio. Esto se denomina propagación de la lista de visualización.

Samba puede actuar como visualizador maestro de dominio en un dominio Windows si es necesario. En adición, también puede actuar como visualizador maestro local para una subred Windows, sincronizando su lista de visualización con el visualizador maestro de dominio.

El Servicio de Nombres de Internet de Windows (WINS)

El Servicio de Nombres de Internet de Windows, o "Windows Internet Name Service" (WINS) es la implementación de Microsoft de un servidor de nombres NetBIOS (NBNS). Como tal, WINS hereda muchas de las características de NetBIOS. Primero, WINS funciona con nombres simples o llanos; sólo puedes tener máquinas llamadas fred o grupos de trabajo como CANADA o USA. En adición, WINS es dinámico: cuando un cliente se vuelve "aparece" en la red, se le requiere para que reporte su nombre de máquina, su dirección y su grupo de trabajo al servidor WINS local. Este servidor WINS retendrá la información mientras el cliente periódicamente refresque su registro WINS, lo cual indica que todavía está conectado a la red. Advierte que los servidores WINS no son específicos de un grupo de trabajo o dominio; pueden aparecer en cualquier lugar y servir a cualquiera.

Pueden configurarse múltiples servidores WINS para sincronizarse unos con otros tras determinado paso de tiempo. Esto permite entradas de máquinas que aparecen y desaparecen en la red para propagarse de un servidor WINS a otro. Mientras que en teoría esto debería ser eficiente, podría volverse problemático rápidamente si hay varios servidores WINS cubriendo una red. Debido a que los servicios WINS pueden controlar múltiples subredes, frecuentemente es más eficiente tener a cada cliente Windows, no importa cuántos dominios Windows haya, apuntando al mismo servidor WINS. De esa forma, sólo habrá un servidor WINS autoritativo con la información correcta, en lugar de tener varios servidores WINS esforzándose contínuamente en sincronizarse entre ellos con los cambios más recientes.

El actual servidor WINS activo es conocido como el servidor WINS primario. También puedes instalar un servidor WINS secundario, el cual entrará en acción en el caso de que el primario falle o se vuelva inaccesible. Advierte que no hay un proceso de elección para determinar qué máquina se convierte en servidor WINS primario o de seguridad -la elección de servidores WINS es estática y debe ser predeterminada por el administrador del sistema. Tanto el servidor WINS primario como el de seguridad sincronizarán sus bases de datos de direcciones cada ciertos períodos determinados de tiempo.

En la familia de sistemas operativos Windows, sólo un servidor NT Workstation o NT pueden actuar como servidores WINS. Samba también puede funcionar como servidor WINS primario, pero no como secundario.

¿Qué puede hacer Samba?

¡Vaya! nunca habrías pensado que las redes Microsoft podrían ser tan complejas, verdad? Ahora, centrémonos en ver dónde nos puede ayudar Samba. La Tabla 6 sumariza los roles que Samba puede y no puede asumir en un dominio Windows NT o en un dominio Windows para Trabajo en Grupos. Como podrás ver, debido a que la mayoría de protocolos del dominio NT son propietarios y no han sido documentados por Microsoft, Samba no puede sincronizar correctamente sus datos con un servidor Microsoft y no puede actuar como servidor de seguridad en la mayoría de los roles. Sin embargo, con las versiones 2.0. x, Samba ofrece soporte limitado para los protocolos de autentificación del controlador primario de dominio y está adquiriendo nuevas funcionalidades cada día.