Das SMB-Protokoll (Server Messages Block) legt fest, wie Windows-Computer im Netzwerk kommunizieren. SMB ermöglicht den Zugriff auf Dateien, Drucker, serielle Schnittstellen und Kommunikationskanäle wie benannte Pipes und Mail-Slots. Samba ist eine freie SMB-Implementierung.

SMB ist ein Client-Server-Protokoll, das nach dem Anfrage-Antwort-Prinzip arbeitet. Der Client sendet eine Anfrage an einen Server und der schickt eine Antwort an den Client zurück. Dass der Server sich ohne vorherige Anfrage beim Client meldet, geschieht nur in ganz bestimmten Fällen. In der SMB-Welt sind Clients Systeme, die Freigaben verwenden, und Server stellen die Freigaben zur Verfügung. Die meisten SMB-fähigen Computer lassen sich sowohl als Client als auch als Server einsetzen (Peer-to-Peer-Netzwerk).

Microsoft bezeichnet das SMB-Protokoll seit einiger Zeit auch als CIFS (Common Internet File System), was etwas moderner klingt. Die von Microsoft zur Verfügung gestellte Dokumentation ist alllerdings mager und unvollständig – es gibt keinen offiziellen Standard. Die Samba-Entwickler mussten ihre Protokollkenntnisse teilweise durch Analysen der Kommunikation erwerben.

Das Format der SMB-Nachrichten ist einfach. Eine SMB-Nachricht (auch SMB-Paket genannt) besteht aus einem Vorspann (Header) und dem eigentlichen Inhalt. Der Vorspann beginnt immer mit der Protokollidentifikation »0xFF«, gefolgt von einem 1 Byte langen Kommando-Code. Die weiteren Vorspannfelder sind die Fehlerklasse, der Fehlercode, der Tree Identifier (TID) sowie die jeweilige ID des aufrufenden Prozesses, eine Benutzerkennung und ein Multiplex Identifier.

Einfaches Nachrichten-format

Zwischen einigen dieser Felder befinden sich noch leere, die für eine zukünftige Verwendung reserviert sind. Der Inhalt der SMB-Nachricht besteht aus einem Kommando oder einer Antwort auf einen Befehl. Die Länge des Befehls beziehungsweise der Antwort ist variabel. Jedes Kommando besitzt eigene Parameter und Daten, die jeweils mitgeschickt werden. Das erste Feld des Befehls ist 1 Byte groß und gibt die Länge des Befehls an. Anschließend kommen noch Parameter-Wörter sowie eine Angabe für die Anzahl der Parameter und schließlich die Parameter selbst.

Es empfiehlt sich, zunächst einen Blick auf eine einfache Verbindung zu werfen, um das Protokoll besser zu verstehen. Wenn der Benutzer auf ein Netzwerkverzeichnis oder einen Drucker zugreifen will, kommt die Software-Schnittstelle NetBIOS ins Spiel, die die Sitzungsebene repräsentiert und somit der alleinige Ansprechpartner für Anwendungen ist. Der Client schickt ein Anfragepaket (Session Request) an den Server, das die NetBIOS-Namen des Servers und des Clients enthält. Der Server antwortet mit »Session Granted« – die Verbindung ist hergestellt.

Verbindungsaufnahme

Daraufhin beginnen Client und Server damit, die Protokollvariante auszuhandeln, wozu der Client dem Server ein weiteres Kommando schickt, nämlich »SMBnegprot«. Dieses Paket enthält eine Liste sämtlicher SMB-Protokollvarianten, die der Client beherrscht. Der Server antwortet mit einem Zeiger auf die von ihm gewünschte Protokollvariante, wobei »0« auf den ersten Protokolldialekt in der Liste zeigt, den der Client gesendet hat. Die Antwort »0xFF« bedeutet, dass der Server kein kompatibles Protokoll spricht und eine weitere Kommunikation ausgeschlossen ist.

Im nächsten Schritt übermittelt der Client dem Server einen Benutzernamen mit dem zugehörigen Kennwort, den Namen der Arbeitsgruppe und die maximale Größe der übertragbaren Daten. Dazu kommt eine Angabe über die maximale Größe der Client-Warteschlange. Im selben Paket sendet der Client den nächsten Befehl, nämlich eine Verbindungsanforderung (Tree Connect). Der Server schickt dem Client einen Tree Identifier (TID), womit der Client nun Dateien öffnen, lesen, schreiben und schließen kann.

Außerdem schickt der Server dem Client noch die Dienstkennung »A«, die für eine Verzeichnisfreigabe steht. Weitere mögliche Dienstkennungen sind »PT1« für Druckerwarteschlangen, »COMM« für serielle Anschlüsse und »IPCQ« für Named Pipes.

Namensauflösung unter NetBIOS

Wie in anderen Netzwerken muss jeder Knoten eindeutig identifizierbar sein. Das geschieht mit Hilfe von NetBIOS-Namen, die 16 Bytes lang sind. Da das 16. Byte als Kennzeichen für einen Dienst fungiert (ähnlich den Ports bei TCP/IP), sind für den Endanwender nur 15 Zeichen sicht- und nutzbar. Im Gegensatz zu DNS verfügt SMB/CIFS über keine Hierarchie; der Namensraum ist also flach. Ein Host kann dabei mehrere Namen besitzen, solange sie im Netzwerk eindeutig sind.

Der Namensverwaltung im Netzwerk dient das Name Management Protocol, das dem Appletalk Binding Protocol ähnelt: Neue Knoten verschicken mehrfach hintereinander eine Namensanforderung als Rundsendung (Broadcast). Wenn kein anderer Computer antwortet, dass er den Namen bereits besitzt, trägt der anfragende Computer den Namen in eine lokale Tabelle ein. Auch die Zuordnung von NetBIOS-Namen zu Netzwerkadressen beruht auf Broadcasts.

Der Client schickt beim Verbindungsaufbau ein Paket mit der Anfrage nach einem bestimmten Namen an das lokale Netzwerk, der entsprechende Rechner beantwortet sie. Das Aushandeln von Namen und Adressen regelt das Name Management Protocol (NMP).

Mit Hilfe von Suchlisten können Clients schnell und einfach bestimmte Server und Freigaben finden. Letztere sind jene Listen, die Windows-Benutzer in der Netzwerkumgebung sehen. Der Suchdienst (Browse Service) stellt die Suchlisten zusammen und verteilt sie im Netzwerk. Zu den wichtigsten Komponenten gehört der Local Master Browser (LMB), der permanent eine mehr oder weniger aktuelle Suchliste seines Teilnetzes vorhält.

Suchdienste

Prinzipiell kann jeder SMB-Server die Rolle des LMB übernehmen; diverse Kriterien wie etwa Uptime oder Betriebssystemversion bestimmen, welcher Server diese Funktion übernimmt. Fährt ein SMB-Server hoch, der als potenzieller LMB konfiguriert ist, so kann er eine Auswahl erzwingen, die den LMB im lokalen Teilnetz bestimmt. Der Local Master Browser kann einen oder mehrere potenzielle LMBs zu Sicherungs-LMBs machen, indem er ihnen eine Kopie seiner Suchliste schickt.

Fällt der LMB aus, übernimmt ein Sicherungs-LMB seine Funktion, Clients können weiterhin das Netzwerk durchsuchen, ohne dass die Suchliste neu aufgebaut werden muss. Ein Microsoft-SMB-Server bestimmt die Anzahl der Sicherungs-LMBs abhängig von der Anzahl der NetBIOS-Knoten im Teilnetz.

Außerdem gibt es vom Administrator festgelegte Hosts, die als Domain Master Browser (DMB) fungieren. DMB verwalten die Suchlisten ganzer Domänen, auch über mehrere Teilnetze hinweg. Die Verteilung der Listen im Netzwerk ist relativ langsam, sodass neu eingeschaltete SMB-Server erst mit einiger Verzögerung in den Listen erscheinen und ausgeschaltete Server noch fast eine ganze Stunde in den Suchlisten herumgeistern können.

Die lange SMB-Geschichte

Den Ursprung hat SMB mit NetBIOS, das Sytec 1983 für IBM programmiert hatte, gemeinsam. NetBIOS war sowohl eine Software-Schnittstelle (API, Application Programming Interface) als auch ein passendes Transportprotokoll. Während das Transportprotokoll heute praktisch nicht mehr verwendet wird (und auch kein Bestandteil mehr von NetBIOS ist), blieb die Software-Schnittstelle die vielen Jahre lang erhalten.

Zur Kommunikation zwischen Server und Client werden Nachrichten versendet, die so genannten Server Messages Blocks (SMB). Das in NetBIOS enthaltene Transportprotokoll nennt IBM NetBIOS Frame Protocol (NBF). Häufig wird auch vom NetBIOS-Protokoll gesprochen, obwohl dieser Begriff streng genommen nicht korrekt ist. Eingesetzt wurde es zunächst nur in proprietären IBM-PC-Netzwerken, die maximal 80 Nodes adressieren konnten.

Weil das IBM-PC-Netzwerk im Laufe der Zeit immer weniger den Anforderungen genügte, entwickelte IBM Token Ring, das bis zu 260 Knoten enthalten kann und Teilnetze erlaubt (Ringe lassen sich über Bridges miteinander verbinden). 1985 schrieb IBM eine Emulation, die die Nutzung der NetBIOS-Schnittstelle auch in diesen Netzwerken ermöglichte, damit die vorhandenen Applikationen weiterhin funktionierten.

Das NBF wurde durch das NetBIOS Extended User Protocol (NetBEUI) ersetzt. Erst zu diesem Zeitpunkt wurde NetBIOS zu einer reinen Software-Schnittstelle. Das für Token Ring entwickelte Transportprotokoll NetBEUI funktioniert auch in Ethernet-Netzwerken und ist für kleine Windows-Netzwerke ohne Internetanschluss eine gute Wahl, da es keinerlei Konfiguration erfordert. Das Namensschema – jeder Knoten besitzt einen oder mehrere NetBIOS-Namen – wurde mit NetBEUI beibehalten.

Abbildung 1: Die Namenstabelle eines Microsoft NetBIOS Name Servers.

Kooperation mit Fremden

Kompliziert wird es, wenn andere Transportprotokolle zum Einsatz kommen. In diesem Fall ist eine Zuordnung von NetBIOS-Namen zu Netzwerkadressen erforderlich. Zudem enthalten Adressen in routbaren Netzwerken neben der Host- auch eine Netzwerkadresse, die weder NetBIOS noch NetBEUI kennen. Das einzige Protokoll, das bei der Kommunikation zwischen Linux- und Windows-Rechnern eine nennenswerte Bedeutung hat, ist TCP/IP.

Erst die später entwickelte Möglichkeit, SMB-Daten in anderen Transportprotokolle zu kapseln, ermöglichte die Nutzung von Netzwerkfreigaben auch über Router hinweg. Die Kapselung in TCP/IP wird von Microsoft NetBIOS over TCP/IP (abgekürzt NBT oder NetBT) genannt. Zuständig dafür sind die RFCs 1001 (Protocol Standard for a NetBIOS Service on a TCP/UDP Transport; Concepts and Methods) sowie 1002 (Protocol Standard for a NetBIOS Service on a TCP/UDP Transport; Detailed Specifications). Die dort beschriebenen Vorgehensweisen sollen es ermöglichen, bereits bestehende NetBIOS-Dienste unter gültigen Standards weiterhin zu verwenden.

Zentraler Punkt der Integration ist die Auflösung von NetBIOS-Namen in IP-Adressen. Da Broadcasts, wie sie zur Namensauflösung in NetBEUI-Netzwerken üblich sind, keine Routergrenzen überwinden können, war eine andere Möglichkeit zur Namensauflösung zu finden: Sie besteht aus eigenen Namens-Servern für NetBIOS, den NBNS (NetBIOS Name Server). Microsoft verwendet für seine NBNS den Begriff WINS (Windows Internet Name Service).

DNS hat nicht nur Vorteile

NetBIOS Name Server funktionieren ähnlich wie DNS-Server, nur eben für das SMB-Protokoll statt für TCP/IP. Ein großer Vorteil von WINS gegenüber DNS ist, dass sich Clients selbstständig beim Server registrieren, sodass normalerweise keine Wartung nötig ist. Auch das manuelle Eintragen von Zuordnungen entfällt, ist aber möglich.

SMB-Server, die sich nicht beim Name Server registrieren, sind zwar nicht in den Suchlisten enthalten, aber trotzdem im Netzwerk verfügbar; wer auf sie zugreifen will, muss ihre Namen kennen. Sind in einem Netzwerk mehrere NBNS aktiv, können sie ihre Daten untereinander austauschen, damit alle Server auf dem aktuellen Stand sind, und Clients können den jeweils nächsten NBNS fragen, wenn Sie einen Namen zu einer Adresse auflösen müssen. Das verringert den Netzwerkverkehr und entlastet zudem die Router.

Verwirrende Knotenvielfalt

In einer TCP/IP-Umgebung gibt es unterschiedliche Konfigurationsmöglichkeiten für Clients und Server. Als B-Node (B für Broadcast) verschickt ein SMB-Rechner Rundsendungen sowohl zur Registrierung seines eigenen Namens als auch zur Namensauflösung. Normalerweise leiten Router keine Broadcasts weiter, sodass B-Nodes nur Server im lokalen Netzwerk sehen können.

B-Nodes unter Microsoft Windows werfen bei der Namensauflösung zunächst einen Blick in den eigenen NetBIOS-Namens-Cache und versenden, wenn der kein Ergebnis bringt, ein Broadcast-Paket. Ist auch dies erfolglos, schaut das System in der Datei »lmhosts« (vergleichbar mit der »hosts«-Datei für TCP/IP) nach.

P-Nodes (P für Point-to-Point) kommunizieren ausschließlich mit NetBIOS-Namens-Servern, und zwar sowohl zur Registrierung ihres eigenen Namens als auch zum Herausfinden von NetBIOS-Namen anderer Computer. Voraussetzung ist natürlich, dass Clients die IP-Adresse mindestens eines NBNS kennen. Die kann der Administrator manuell festlegen oder dem Client über die Option 044 des DHCP (Dynamic Host Configuration Protocol) festlegen.

Der Nachteil der P-Node-Konfiguration ist, dass beim Ausfall eines NBNS die gesamte SMB-Kommunikation zusammenbricht, sogar im lokalen Teilnetz. Einen Ausweg bietet die Betriebsweise M-Node (M für Mixed), bei der zunächst die Broadcast-Methode ausprobiert wird. Schlägt sie fehl, ist die Point-to-Point-Kommunikation mit einem NBNS dran. Das steigert zumindest in der Theorie die Leistung in lokalen Netzwerken. Ist der NBNS nicht verfügbar, kann der Computer immerhin noch auf SMB-Server in seinem Teilnetz zugreifen.

Genau umgekehrt arbeitet der H-Node (H für Hybrid): Nur wenn der NBNS unerreichbar ist, verschickt er Rundsendungen. Außerdem versucht ein H-Node, den NBNS in gewissen Abständen zu kontaktieren, um bei seiner Verfügbarkeit wieder die Point-to-Point-Betriebsart zu wählen.

Da das Samba-Projekt erst lange nach der Erfindung von SMB mit der Arbeit begann, hat sich das Entwicklerteam erst gar nicht mit dem NetBIOS Frame Protocol auseinandergesetzt, sondern von Anfang an eine TCP/IP-Implementierung programmiert. Um mit anderen Implementierungen kompatibel zu sein, muss allerdings auch Samba die Besonderheiten unter TCP/IP berücksichtigen, beispielsweise die speziellen Namensauflösung.

Flexibler als das Original

Über zahlreiche Parameter in der »smb.conf« lässt sich das Verhalten der Server-Software genau einstellen. Samba bietet deutlich mehr Konfigurationsmöglichkeiten als Windows selbst. Dazu gehören so nützliche Merkmale wie beispielsweise die Verwendung mehrerer SMB-Namen gleichzeitig. Das ist besonders praktisch, wenn ein Linux-System mehrere Windows-Server ersetzen soll. Auch bei Sicherheitsfunktionen wie etwa einer Zugriffsbeschränkung anhand von IP-Adressen bietet Samba mehr als das Original. (uwo)