Puesto que Samba es, fundamentalmente, una implementación para Unix del protocolo SMB, quizás la mejor forma de entender Samba es comenzar por describir SMB con un poco más de detalle. Esta sección realiza una pequeña revisión de este protocolo.
SMB es un protocolo de comunicación de alto nivel que puede implementarse sobre diversos protocolos como TCP/IP, NetBEUI y IPX/SPX, tal como muestra la Figura 4.1, “Protocolos sobre los que puede implementarse SMB.”, junto con la ubicación de dichos protocolos en los niveles OSI y en la pila TCP/IP. Entre todas esas alternativas, tanto en el caso de Samba como de Windows 2000/XP, SMB se implementa habitualmente encima de NetBIOS sobre TCP/IP (esta alternativa se ha convertido en el estándar de facto para compartir recursos entre sistemas Windows). Sin embargo, no incidiremos más en los protocolos que soportan SMB o en su implementación, puesto que todo ello queda fuera del contexto de este tema.
Históricamente, este protocolo fue desarrollado inicialmente por IBM como el IBM PC Network SMB Protocol o Core Protocol a principios de los años 80. Desde entonces, diversos fabricantes (especialmente Microsoft) han ido ampliando su funcionalidad progresivamente, creando diferentes variantes (versiones) de SMB. Desafortunadamente, en ocasiones el cambio de versión ha conllevado el rebautizar el propio protocolo. En este sentido, SMB ha recibido, entre otros,los siguientes nombres: Core Protocol, DOS Lan Manager, LAN Manager, NTLM (NT Lan Manager), y en los últimos años, CIFS (Common Internet File System). Todos ellos, por tanto, hacen referencia a SMB, aunque se diferencien en algunos detalles de su funcionalidad y/o implementación.
Si nos fijamos en su interfaz, SMB es un protocolo de tipo cliente/servidor, donde el ordenador "servidor" ofrece recursos (archivos, impresoras, etc.) que pueden ser utilizados remotamente por los ordenadores "cliente" a través de la red. Asimismo, es un protocolo de los denominados petición/respuesta, indicando que las comunicaciones se inician siempre desde el cliente como una petición de servicio al servidor (dicha petición se denomina precisamente SMB), que la procesa y retorna una respuesta a dicho cliente. (En realidad, existe un caso en que el servidor envía un mensaje al cliente sin haber recibido una petición de éste, pero la discusión del protocolo a ese nivel queda fuera del ámbito de este texto). La respuesta del servidor puede ser positiva (con el resultado de procesar la petición del cliente) o negativa (mensaje de error), en función del tipo de petición, la disponibilidad del recurso, el nivel de acceso (permisos) del cliente, etc.
El siguiente aspecto relevante de SMB es saber qué mecanismos de autentificación soporta este protocolo para controlar el acceso del cliente a los recursos compartidos. En concreto, SMB soporta dos modos de autentificación alternativos, denominados share y user:
Cuando compartimos un recurso en modo share, la protección de dicho recurso recae en una contraseña que asociamos al mismo, de forma que cualquier usuario de un sistema cliente remoto que conozca dicha palabra de paso podrá acceder sin mayores restricciones al recurso (este es el mecanismo de autentificación por defecto en las implemementaciones de SMB para Windows 9X, por ejemplo).
Sin embargo, en modo user, el servidor recibe incialmente del sistema cliente unas credenciales de usuario (nombre, dominio y contraseña), que debe autentificar para autorizar el acceso al recurso. Concretamente, si el dominio de las credenciales es conocido, la autentificación se delega a algún controlador de dicho dominio; y en caso contrario, el usuario y la contraseña se autentifican contra la base de datos local del equipo servidor. En cualquier caso, en modo user, el control de acceso sobre el recurso se realiza en función de qué permisos posee sobre dicho recurso el usuario cuyas credenciales se han enviado desde el cliente. En otras palabras, una vez el sistema servidor ha identificado y autentificado al usuario que desea conectarse al recurso, este sistema dispone ya de un SID válido con el que puede contrastar los permisos que dicho SID posee sobre el recurso. Es conveniente recordar en este punto que si el recurso en cuestión es una carpeta compartida, se tienen en cuenta tanto los permisos del recurso, como los permisos NTFS de la carpeta y sus archivos. El modo user es el mecanismo de autentificación por defecto en las versiones de SMB de sistemas Windows NT y posteriores.
Finalmente, revisaremos brevemente el funcionamiento interno del protocolo SMB, utilizando para ello un ejemplo concreto. Supongamos que un sistema cliente desea acceder a una carpeta compartida que exporta el servidor (en modo user). En este escenario, se produciría el siguiente intercambio de mensajes entre ellos:
Petición: Sesión NetBIOS. El objetivo de este mensaje es establecer una sesión fiable para subsiguientes mensajes entre los ordenadores cliente y servidor. Es imprescindible que el cliente conozca el nombre NetBIOS del servidor para poder alcanzarlo; el nombre NetBIOS del cliente es parte del mensaje, por lo que ambos saben quién es el otro.
Respuesta: Sesión NetBIOS. Si no hay error en el mensaje anterior, el servidor envía un mensaje de reconocimiento (ACK), aceptando la conexión.
Petición: Dialecto SMB. El cliente envía en este mensaje una lista con los dialectos o variantes de SMB que soporta, puesto que es habitual que un sistema Windows soporte varias versiones de SMB simultáneamente.
Respuesta: Dialecto SMB. El servidor contesta con el dialecto que prefiere para la comunicación subsiguiente, o un código de error si no soporta ninguna de las alternativas ofrecidas por el cliente.
Petición: Inicio de sesión. El cliente envía las credenciales de usuario (usuario, dominio,contraseña) con las que éste desea conectarse al servidor. Recuérdese que por defecto, se emplean las credenciales con las que el usuario se conectó interactivamente al sistema cliente, pero se pueden especificar otras explícitamente.
Respuesta: Inicio de sesión. El servidor autentifica las credenciales de usuario (ver modo user descrito arriba). Si las credenciales son buenas, el servidor posee ya un SID válido que le permite, antes que nada, comprobar si el usuario posee el derecho de conectarse al servidor (directiva "tener acceso a este equipo desde la red"). En caso afirmativo, se acepta la conexión y el servidor construye un identificador numérico particular para esa coexión (denominado User ID o UID) que devuelve al cliente. Los UIDs pueden ser reutilizados durante la vida del sistema, pero son únicos para todas las conexiones simultáneas que mantiene el servidor en un momento dado, por lo que identifican unívocamente una conexión (aceptada). Todos los mensajes posteriores del cliente deben contener este identificador para ser aceptados por el servidor.
Por otro lado, si las credenciales estaban mal (o si los derechos eran insuficientes), el servidor envía un código de error en lugar del UID.
Petición: Conexión a un recurso concreto. El cliente envía entonces un mensaje que contiene una cadena que identifica el recurso al que desea acceder (por ejemplo,
\\pc01\impresorao\\pc01\carpeta).Respuesta: Conexión a un recurso concreto. Si el recurso solicitado por el cliente existe (y el SID asociado a la conexión posee suficientes permisos), el servidor construye un identificador denominado Tree ID o TID, que será utilizado por el cliente para hacer referencia a dicho recurso en posteriores mensajes de esa conexión.
Tras esta secuencia típica de conexión al recurso (carpeta compartida), y si todo ha fucionado correctamente, el sistema cliente ya está en condiciones de acceder a la carpeta. Mediante el envío de los SMBs correspondientes, el cliente ya puede abrir archivos, leerlos, modificarlos, etc., utilizando siempre los identificadores (UID y TID) que el servidor ha construido durante el intercambio de mensajes inicial.