Kapitel 1

Samba ist für jeden, der sowohl Windows- als auch Unix-Systeme in seinem Netzwerk betreibt, ein außergewöhnlich nützliches Werkzeug. Es läuft auf einem Unix-System und erlaubt dabei Windows, Dateien und Drucker auf dem Unix-Host freizugeben, und Unix-Benutzern, auf Ressourcen zuzugreifen, die durch Windows-Systeme freigegeben wurden.

Es mag zwar nur natürlich sein, einen Windows-Server einzusetzen, um Dateien und Drucker in einem Netzwerk bereitzustellen, das Windows-Clients enthält, allerdings gibt es gute Gründe, für diese Aufgabe einen Samba-Server vorzuziehen. Samba ist eine zuverlässige Software, die auf zuverlässigen Unix-Betriebssystemen läuft. Dadurch treten weniger Probleme auf, und die Wartungskosten verringern sich. Samba bietet darüber hinaus eine bessere Leistung bei starker Last, wobei beispielsweise ein Server mit Windows 2000 auf identischer PC-Hardware um den Faktor 2 übertroffen wird (entsprechend veröffentlichten unabhängigen Benchmarks). Wenn gewöhnliche, preiswerte PC-Hardware den Anforderungen einer großen Client-Last nicht mehr gerecht wird, kann der Samba-Server leicht auf ein proprietäres Unix-Mainframe umgesetzt werden, dessen Leistungsfähigkeit die von Windows auf einem PC um ein Vielfaches übertrifft. Und als wenn all dies noch nicht genug wäre, bietet Samba einen ausgesprochen netten Kostenvorteil: Es ist nämlich kostenlos. Nicht nur die Software selbst steht frei zur Verfügung, es werden auch keine Client-Lizenzen benötigt. Außerdem läuft es auf qualitativ hochwertigen, freien Betriebssystemen wie Linux und FreeBSD.

Nach dem Lesen des vorangegangenen Absatzes könnten Sie zu dem Schluss kommen, dass Samba üblicherweise von großen Einrichtungen mit tausenden von Benutzern im Netzwerk eingesetzt wird - und Sie könnten Recht haben! Zu den Benutzern von Samba jedoch gehören Organisationen auf der ganzen Welt, in allen Arten und Größen: von internationalen Unternehmen über kleine und mittelständische Firmen bis hin zu Einzelpersonen, die Samba auf ihren Linux-Laptops ausführen. Im letzten Fall wird ein Programm wie VMware verwendet, um Windows auf dem gleichen Computer laufen zu lassen, wobei Samba es den beiden Betriebssystemen erlaubt, Dateien gemeinsam zu nutzen.

Die Vielfalt der Benutzer ist sogar noch größer - Samba wird von Unternehmen, Banken und anderen Finanzeinrichtungen, Regierungen und Militäreinrichtungen, Schulen, Bibliotheken, Kunstgalerien, Familien und sogar Autoren benutzt! Dieses Buch wurde auf einem Linux-System mit VMware und Windows 2000 erstellt. Der Adobe FrameMaker lief unter Windows, und die Dokumentdateien wurden mittels Samba auf dem Linux-Dateisystem bereitgestellt.

Hört sich all das verlockend an? In diesem Fall ermuntern wir Sie, weiterzulesen, Samba kennen zu lernen und unseren Beispielen zu folgen, um einen eigenen Samba-Server einzurichten. In diesem und den folgenden Kapiteln werden wir Ihnen genau sagen, wie Sie anzufangen haben.

Was ist Samba?

Samba ist eine Sammlung mehrerer Unix-Anwendungen, die über das SMB-Protokoll (Server Message Block-Protokoll) kommunizieren. Die Betriebssysteme Microsoft Windows und OS/2 verwenden SMB für Client/Server-Netzwerke zum Bereitstellen gemeinsam genutzter Dateien und Drucker sowie verwandter Operationen. Weil Samba dieses Protokoll unterstützt, können Sie Unix-Server einbeziehen, indem diese über das gleiche Netzwerkprotokoll wie Microsoft Windows-Produkte kommunizieren. Dadurch kann sich eine Unix-Maschine mit Samba in Ihrem Microsoft Windows-Netzwerk als Server ausgeben. Ein Samba-Server stellt folgende Dienste zur Verfügung:

Das Samba-Programmpaket enthält außerdem Client-Werkzeuge, die es Benutzern auf einem Unix-System erlauben, auf Ordner und Drucker zuzugreifen, die Windows-Systeme und Samba-Server im Netzwerk bereitstellen.

Samba verdanken wir Andrew Tridgell, der derzeitig das Samba-Entwicklerteam leitet. Andrew begann das Projekt im Jahr 1991, als er mit einem DEC-Programm namens Pathworks arbeitete, das DEC-VAX-Computer mit Computern anderer Hersteller verbinden sollte. Ohne sich der Wichtigkeit dessen bewusst zu sein, was er tat, schuf Andrew ein Datei-Server-Programm für ein eigenartiges Protokoll, das Bestandteil von Pathworks war. Später stellte sich heraus, dass es sich bei diesem Protokoll um SMB handelte. Einige Jahre später erweiterte er den auf seine Bedürfnisse zugeschnittenen Server und begann, ihn im Internet unter dem Namen »SMB Server« zu verteilen. Allerdings konnte Andrew diesen Namen nicht lange benutzen, da eine Firma ihn bereits für ihre Produkte hatte eintragen lassen - er schlug daraufhin folgenden Unix-Weg ein, um sein Programm umzubenennen:

Heutzutage konzentriert sich die Samba-Sammlung um einige Unix-Daemons, die freigegebene Ressourcen - so genannte Freigaben oder Dienste (oder Services) - für SMB-Clients im Netzwerk bereitstellen. Dabei handelt es sich um folgende Daemons:

Ein Daemon, der Verzeichnisse und Drucker in einem SMB-Netzwerk freigibt und die Echtheit von Clients überprüft (authentifiziert) und bestätigt (autorisiert).

Ein Daemon, der den NetBIOS-Namensdienst und WINS, die Microsoft-Implementierung eines NetBIOS-Name-Servers (NBNS), unterstützt. Er hilft außerdem beim Durchsuchen des Netzwerks.

Samba wird derzeit von einer Gruppe Freiwilliger unter der Leitung von Andrew Tridgell gewartet und erweitert. Wie das Linux-Betriebssystem wird auch Samba von seinen Autoren als Open Source Software (http://open-source.org) angesehen und unter der GNU General Public License (GPL) vertrieben. Seit seiner Einführung wurde die Entwicklung von Samba teilweise von der Australian National University gesponsert, an der Andrew Tridgell promoviert hat. Seitdem haben viele andere Organisationen Samba-Entwickler unterstützt, einschließlich LinuxCare, VA Linux Systems, Hewlett-Packard und IBM. Es zeugt von einer hohen Wertschätzung für Samba, dass sowohl kommerzielle als auch nicht-kommerzielle Einrichtungen bereit sind, ein Open Source-Projekt zu unterstützen.

Auch Microsoft leistete einen Beitrag, indem die Firma im Jahr 1996 ihre Definitionen des SMB-Protokolls der Internet Engineering Task Force (IETF) als Common Internet File System (CIFS) zur Verfügung stellte. In diesem Buch ziehen wir es zwar vor, den Begriff »SMB« zu benutzen, allerdings werden Sie das Protokoll auch oft unter der Bezeichnung »CIFS« finden. Das gilt besonders für die Website von Microsoft.

Was leistet Samba?

Wie bereits beschrieben, kann Samba Ihnen dabei helfen, Windows- und Unix-Systeme in einem Netzwerk nebeneinander einzusetzen. Es gibt jedoch noch weitere Gründe, die Sie zur Verwendung von Samba in Ihrem Netzwerk bewegen können:

Lassen Sie uns eine kurze Tour durch ein Samba-System im Einsatz machen. Gehen Sie von folgender grundlegender Netzwerkkonfiguration aus: ein Unix-System mit Samba und dem Namen toltec sowie ein paar Windows-Clients mit den Namen maya und aztec; alle Computer sind über ein LAN miteinander verbunden. Nehmen Sie weiterhin an, dass lokal an toltec der Tintenstrahldrucker lp angeschlossen ist. Außerdem ist auf diesem Computer ein Verzeichnis namens spirit im Netzwerk freigegeben. Beide Ressourcen können den beiden anderen Computern angeboten werden. Ein Modell dieses Netzwerks sehen Sie in Abbildung 1-1.

Abbildung 1-1

Ein einfaches Netzwerk mit einem Samba-Server

In diesem Netzwerk befinden sich alle erwähnten Computer in derselben Arbeitsgruppe. Eine Arbeitsgruppe ist einfach nur eine Kennzeichnung für eine beliebige Sammlung von Computern mit ihren Ressourcen in einem SMB-Netzwerk. Mehrere Arbeitsgruppen können friedlich nebeneinander existieren - in unserem Beispiel aber gibt es ausschließlich die Arbeitsgruppe METRAN.

Ein Verzeichnis freigeben

Wenn alles korrekt konfiguriert ist, sollten Sie in der Lage sein, den Samba-Server toltec in der Netzwerkumgebung des Windows-Rechners maya zu sehen. Und in der Tat, Abbildung 1-2 zeigt die Netzwerkumgebung auf dem Computer maya, die toltec und alle anderen Rechner enthält, die sich in der Arbeitsgruppe METRAN befinden. Beachten Sie das Symbol Gesamtes Netzwerk ganz oben in der Liste. Wie wir bereits erwähnten, kann es in einem SMB-Netzwerk mehrere Arbeitsgruppen gleichzeitig geben. Klickt ein Benutzer auf das Symbol Gesamtes Netzwerk, erscheint eine Liste aller Arbeitsgruppen, die momentan im Netzwerk existieren.

Abbildung 1-2

Das Verzeichnis Netzwerkumgebung

Sie können sich den Server toltec näher ansehen, indem Sie auf das entsprechende Symbol doppelklicken. Dadurch wird toltec selbst angesprochen und eine Liste seiner bereitgestellten Freigaben - der Datei- und Druckerressourcen - angefordert. In unserem Fall gibt es auf dem Server einen Drucker namens lp, ein Home-Verzeichnis namens jay und eine Verzeichnisfreigabe namens spirit, wie Sie in Abbildung 1-3 sehen.

Abbildung 1-3

Freigaben des Servers Toltec, von maya aus gesehen

Beachten Sie, dass Windows standardmäßig eine gemischte Schreibweise für Computernamen verwendet (Toltec). Die Groß-/Kleinschreibung spielt bei Computernamen keine Rolle, so dass Sie je nach verwendeter Anzeige oder Ausgabe toltec, Toltec und TOLTEC sehen werden - sämtliche Namen beziehen sich auf dasselbe System. Dank Samba sieht Windows 98 den Unix-Server als gültigen SMB-Server an und kann auf das freigegebene Verzeichnis spirit zugreifen, als handele es sich dabei um einen weiteren Systemordner.

Ein beliebtes Merkmal von Windows ist, dass Sie einem bekannten, freigegebenen Verzeichnis im Netzwerk einen Laufwerkbuchstaben (wie etwa E:, F: oder Z:) zuweisen können, indem Sie im Windows-Explorer die Funktion Netzlaufwerk verbinden verwenden.¹ Sobald Sie das getan haben, können Ihre Anwendungen den Ordner im Netzwerk über den Laufwerkbuchstaben ansprechen. Sie können Daten darauf speichern, Programme darauf installieren und ausführen und ihn sogar mit einem Kennwort gegen unerwünschte Besucher schützen. In Abbildung 1-4 sehen Sie, wie ein Laufwerkbuchstabe einem Netzwerkverzeichnis zugeordnet wird.

Abbildung 1-4

Zuordnung eines Netzlaufwerks zu einem Windows-Laufwerkbuchstaben

Schauen Sie sich den Eintrag Pfad: in der Dialogbox von Abbildung 1-4 an. Eine andere Schreibweise für ein Verzeichnis auf einem Netzwerk-Computer besteht aus zwei Rückstrichen (Backslashes), gefolgt vom Namen des Computers im Netzwerk, einem weiteren Backslash sowie dem Namen des Netzwerkverzeichnisses:

Diese Angabe wird in der Windows-Welt Universal Naming Convention (UNC) genannt. Die Dialogbox in Abbildung 1-4 repräsentiert beispielsweise das Netzwerkverzeichnis auf dem Server toltec als:

Wenn Ihnen diese Schreibweise bekannt vorkommt, denken Sie wahrscheinlich an Uniform Resource Locators (URLs), die Adressen darstellen, die von Webbrowsern wie Netscape Navigator und Internet Explorer verwendet werden, um Systeme im Internet zu finden. Verwechseln Sie die beiden besser nicht: URLs wie http://www.oreilly.com benutzen normale (d.h. vorwärts geneigte) Schrägstriche an Stelle von Backslashes, und vor den Schrägstrichen steht die Abkürzung für das verwendete Datenübertragungsprotokoll (z.B. ftp, http) mit einem Doppelpunkt (:). URLs und UNCs sind also zwei völlig unterschiedliche Dinge, obwohl Sie manchmal eine SMB-Freigabe mit Hilfe einer URL an Stelle eines UNC angeben können. In der URL-Schreibweise würde die Freigabe \\toltec\spirit so aussehen: smb://toltec/spirit.

Sobald das Netzlaufwerk eingerichtet ist, verhalten sich Windows und seine Programme, als wäre das Netzwerkverzeichnis eine lokale Festplatte. Falls Sie Anwendungen besitzen, die eine Mehrbenutzerfunktionalität im Netzwerk unterstützen, können Sie diese auf dem Netzlaufwerk installieren.² Abbildung 1-5 zeigt das resultierende Netzlaufwerk, wie es zusammen mit anderen Speichermedien im Windows 98-Client erscheint. Beachten Sie das Symbol des Laufwerks J:, es zeigt ein Kabel, das Sie darauf hinweist, dass es sich um ein Netzlaufwerk und nicht um eine lokale Festplatte handelt.

Abbildung 1-5

Das dem Buchstaben J auf dem Client zugewiesene Netzwerkverzeichnis

Die Netzwerkumgebung von Windows Me, 2000 und XP funktioniert anders als die Netzwerkumgebung von Windows 98. Es müssen mehr Symbole angeklickt werden, aber schließlich erhalten Sie auch hier die Darstellung des Servers toltec aus Abbildung 1-6. Sie sehen hier ein Windows 2000-System. Das Einrichten des Netzlaufwerks mit Hilfe der Option Netzlaufwerk verbinden funktioniert unter Windows 2000 ähnlich wie auf anderen Windows-Versionen.

Abbildung 1-6

Auf Toltec verfügbare Freigaben (von dine aus gesehen)

Einen Drucker freigeben

Sie haben wahrscheinlich bemerkt, dass der Drucker lp als Freigabe des Servers toltec in Abbildung 1-3 erscheint. Das bedeutet, dass der Unix-Server einen Drucker besitzt, der von den diversen SMB-Clients in der Arbeitsgruppe verwendet werden kann. Daten, die von einem der Clients an den Drucker gesandt werden, werden auf dem Unix-Server zwischengespeichert und in der Reihenfolge ihres Eintreffens an den Drucker weitergeleitet.

Einen Samba-Drucker unter Windows einzurichten ist sogar noch einfacher, als ein Netzlaufwerk zu verwenden. Doppelklicken Sie auf den Drucker und geben Sie dessen Hersteller und Modellbezeichnung an, um auf dem Windows-Client den passenden Druckertreiber zu installieren. Windows ist dann in der Lage, Daten für den Drucker korrekt aufzubereiten und auf ihn zuzugreifen, als würde es sich um einen lokalen Drucker handeln. Unter Windows 98 wird durch einen Doppelklick auf das Drucker-Symbol in der Systemsteuerung das Drucker-Fenster geöffnet, das Sie in Abbildung 1-7 sehen. Beachten Sie auch hier das mit dem Kabel versehene Symbol, das den Drucker als Netzwerkgerät kennzeichnet.

Abbildung 1-7

Ein auf Toltec verfügbarer Netzwerkdrucker

Die Dinge von der Unix-Seite aus sehen

Wie bereits erwähnt, besteht Samba unter Unix aus einer Sammlung von Daemon-Programmen. Sie können sie mit dem Unix-Befehl ps sehen und von ihnen erzeugte Nachrichten in eigenen Protokolldateien oder im Unix-syslog finden (je nachdem, wie Samba eingerichtet ist). Außerdem können Sie Samba in einer einzigen Datei konfigurieren: smb.conf. Falls Sie darüber hinaus eine Vorstellung davon bekommen wollen, was die einzelnen Daemons tun, verwenden Sie das Programm smbstatus, das alle wichtigen Informationen ausgibt. Es funktioniert folgendermaßen:

Der Samba-Statusbericht in dieser Ausgabe besteht aus drei Datenbereichen, die als einzelne Abschnitte dargestellt werden. Dem ersten Abschnitt können Sie entnehmen, welche Systeme eine Verbindung zum Samba-Server hergestellt haben, wobei jeder Client sowohl durch seinen Namen (maya und aztec) als auch durch seine IP-Adresse identifiziert wird. Der zweite Abschnitt enthält den Namen und den Zustand der Dateien, die gegenwärtig über eine Freigabe auf dem Server verwendet werden, und zwar einschließlich ihres Schreib-/Lesestatus und aller Dateisperren. Schließlich zeigt Samba an, wie viel Speicher es momentan für die verwalteten Freigaben belegt, einschließlich des für aktive Freigaben und andere Verwaltungszwecke benutzten Speichers. (Beachten Sie, dass diese Größe nicht der Gesamtgröße entspricht, die die Prozesse smbd und nmbd verwenden.)

Machen Sie sich nichts daraus, falls Sie diese Statistiken nicht verstehen; das wird sich ändern, während Sie dieses Buch lesen.

Sich mit einem SMB-Netzwerk vertraut machen

Jetzt, da wir Ihnen Samba kurz erläutert haben, wollen wir ein wenig Zeit damit verbringen, Sie mit der Umgebung von Samba vertraut zu machen: mit einem SMB-Netzwerk. Ein Netzwerk mit SMB unterscheidet sich deutlich vom Arbeiten mit herkömmlichen TCP/IP-Protokollen wie FTP und Telnet, da es verschiedene neue Konzepte zu lernen und viele neue Informationen zu verstehen gilt. Zunächst beschreiben wir die grundlegenden Konzepte eines SMB-Netzwerks, gefolgt von einigen Microsoft-Implementierungen. Schließlich zeigen wir Ihnen, wann ein Samba-Server sich nahtlos einpassen lässt und wann nicht.

NetBIOS verstehen

Lassen Sie uns das Rad der Zeit auf das Jahr 1984 zurückdrehen. IBM schrieb für die Vernetzung seiner Computer eine einfache Programmierschnittstelle (Application Programming Interface; API) mit dem Namen Network Basic Input/Output System (NetBIOS). Die NetBIOS-API war äußerst simpel gestrickt und ermöglichte es Anwendungen, Verbindungen zu anderen Computern aufzubauen und auf deren Daten zuzugreifen.

Stellen Sie sich die NetBIOS-API vereinfacht als eine Art Netzwerkerweiterung der bekannten API-Aufrufe des BIOS vor. Das BIOS enthält Anweisungen auf niedriger Ebene zur Ausführung von Dateisystem-Operationen auf dem lokalen Computer. NetBIOS musste ursprünglich Anweisungen mit anderen Computern über IBM-PC- oder Token-Ring-Netzwerke austauschen. Es benötigte daher ein Transportprotokoll auf niedriger Ebene, um seine Anforderungen von einem Computer zum nächsten weiterzuleiten.

Ende 1985 veröffentlichte IBM ein solches Protokoll und verschmolz es mit der NetBIOS-API zum NetBIOS Extended User Interface (NetBEUI ). NetBEUI war für (kleine) lokale Netzwerke (Local Area Network; LAN) gedacht. Jeder Computer konnte einen Namen (mit maximal 15 Zeichen) beanspruchen, sofern er nicht bereits im Netzwerk verwendet wurde. Mit einem »kleinen« Netzwerk meinen wir eines mit nicht mehr als 255 Systemen - das galt 1985 noch als ausgesprochen großzügig bemessen!

Das NetBEUI-Protokoll war bei Netzwerkanwendungen sehr beliebt, auch bei denen, die unter Windows for Workgroups liefen. Später kamen Implementierungen von NetBIOS mit den IPX-Netzwerkprotokollen von Novell auf, die dann in Konkurrenz zu NetBEUI traten. Die wachsende Internet-Gemeinschaft verwendete als Transportprotokolle hingegen TCP/IP und UDP/IP, so dass eine Implementierung der NetBIOS-APIs über diese Protokolle erforderlich wurde.

Denken Sie daran, dass TCP/IP Zahlen verwendet, um Computer zu identifizieren (zum Beispiel 192.168.220.100), während NetBIOS ausschließlich Namen benutzt. Dies stellte ein ziemlich großes Problem dar, als versucht wurde, die beiden Protokolle zusammenzufassen. 1987 veröffentlichte die Internet Engineering Task Force (IETF) Dokumente mit den Titeln RFC 1001 und 1002, die beschrieben, wie NetBIOS über ein TCP/UDP-Netzwerk funktionieren kann. Diese Dokumente bestimmen alle heute existierenden Implementierungen, und zwar einschließlich derjenigen, die Microsoft in den Windows-Betriebssystemen verwendet, sowie die der Samba-Programme.

Seitdem ist der durch diese Dokumente geregelte Standard als NetBIOS over TCP/IP oder kurz NBT bekannt.³ Der NBT-Standard (RFC 1001/1002) beschreibt derzeit drei Netzwerkdienste:

Der Namensdienst löst das bereits erwähnte Problem, dass IP numerische Adressen und NetBIOS alphanumerische Namen verwendet. Er ermöglicht es allen Computern im Netzwerk, einen bestimmten Namen im Netzwerk kundzutun. Dieser kann in eine IP-Adresse umgewandelt werden, die von Computern verwendet wird, ganz ähnlich, wie das im heutigen Domain Name System (DNS) im Internet geschieht. Sowohl Datagramm- als auch Sitzungsdienste sind sekundäre Kommunikationsprotokolle, die Daten zwischen den NetBIOS-Computern im Netzwerk transportieren.

Einen Namen erhalten

In der NetBIOS-Welt will jeder Computer, der gestartet wird, einen Namen für sich selbst beanspruchen. Dieser Vorgang wird Namensregistrierung genannt. Es darf jedoch nicht vorkommen, dass zwei Computer im selben Netzwerk denselben Namen beanspruchen, denn dadurch entstünde heillose Verwirrung für jeden Computer, der mit einem der beiden Systeme kommunizieren will. Um dieses mögliche Problem zu vermeiden, gibt es zwei Ansätze:

Abbildung 1-8 veranschaulicht eine (fehlgeschlagene) Namensregistrierung mit und ohne NBNS.

Abbildung 1-8

Namensregistrierung mit und ohne NBNS

Außerdem muss es - wie bereits erwähnt - eine Möglichkeit geben, einen NetBIOS-Namen in eine entsprechende IP-Adresse umzuwandeln. Dieser Vorgang wird als Namensauflösung bezeichnet. Auch hier kann man bei NBT auf zweierlei Weise vorgehen:

Abbildung 1-9 veranschaulicht die beiden Verfahren zur Namensauflösung.

Abbildung 1-9

Namensauflösung mit und ohne NBNS

Wie Sie sich wahrscheinlich schon denken, kann Ihnen ein NBNS im Netzwerk eine enorme Hilfe sein. Um Ihnen zu erklären, warum das so ist, beschreiben wir zunächst die Broadcast-Methode (ohne NetBIOS-Name-Server).

Wenn ein Client-Computer bootet, verschickt er eine Broadcast-Meldung (eine Nachricht, die an alle lokalen Systeme gerichtet ist, also quasi ein Rundschreiben) mit dem Inhalt, dass er für sich einen bestimmten NetBIOS-Namen registrieren möchte. Falls kein System Einspruch erhebt, verwendet er den Namen. Benutzt jedoch ein anderer Computer im lokalen Subnetz bereits den angeforderten Namen, sendet er dem anfragenden System die Nachricht, dass der Name schon vergeben ist. Diesen Vorgang nennt man Verteidigung des Hostnamens. Dieses Verfahren der Namensregistrierung ist praktisch, wenn ein Client unerwartet aus dem Netzwerk genommen wird - kann doch ein anderer seinen Namen übernehmen -, aber es belastet das Netzwerk für so einfache Dinge wie die Namensregistrierung.

Mit einem NBNS verläuft die Namensregistrierung ähnlich, mit dem Unterschied, dass die Daten lediglich zwischen dem anfragenden Computer und dem NetBIOS-Name-Server ausgetauscht werden. Es sind keine Broadcast-Meldungen erforderlich, wenn ein System seinen Namen registrieren lassen will. Die Registrierungsanforderung wird direkt vom Client an den NBNS gesendet, und der NBNS antwortet unabhängig davon, ob der Name bereits belegt ist. Diese Art des Datenaustauschs wird häufig Punkt-zu-Punkt-Kommunikation genannt und erweist sich oft in Netzwerken als nützlich, die mehr als ein Subnetz besitzen. Der Grund dafür liegt darin, dass Router im Allgemeinen so konfiguriert sind, dass sie eingehende Pakete blockieren, die als Broadcast an alle Computer im Subnetz gerichtet sind.

Die gleichen Prinzipien gelten für die Namensauflösung. Ohne NBNS würde die NetBIOS-Namensauflösung ebenfalls über den Broadcast-Mechanismus ausgeführt werden. Jede Anfrage nach einer IP-Adresse würde also an jeden Computer des lokalen Subnetzes gesendet werden, in der Hoffnung, dass das betroffene System direkt antworten kann. Die Verwendung eines NetBIOS-Name-Servers und der Punkt-zu-Punkt-Kommunikation für diesen Zweck belastet das Netzwerk viel weniger stark, als es die Broadcast-Nachrichten tun, die das Netzwerk für jede Namensanfrage »fluten«.

Jetzt könnte man ja einwenden, dass Broadcast-Pakete in modernen Netzwerken mit hoher Bandbreite, in denen Rechner mit schnellen CPUs verbunden sind, keine nennenswerten Probleme verursachen, wenn sich nur wenige Hosts im Netzwerk befinden oder der Bandbreitenbedarf gering ist. Sicherlich gibt es Fälle, in denen dies zutrifft. Unser Rat in diesem Buch lautet jedoch, sich möglichst nicht auf Broadcasts zu verlassen. Für große, ausgelastete Netzwerke ist dieser Ratschlag sehr wichtig, und falls Sie ihn auch beim Einrichten eines kleinen Netzwerks befolgen, werden Sie in der Lage sein, bei einer möglichen Erweiterung des Netzwerks Probleme zu vermeiden, die später nur schwer zu diagnostizieren sind.

Knotentypen

Wie aber erfahren Sie, welche Strategie ein Client im Netzwerk verfolgt, wenn er seinen Namen registriert und Namen auflösen will? Jeder Computer (auch Knoten genannt) in einem NBT-Netzwerk besitzt einen bestimmten Typ, der festlegt, wie die Namensregistrierung und -auflösung arbeitet: b-Knoten, p-Knoten, m-Knoten und h-Knoten. Wie sich die einzelnen Knotentypen verhalten, ist in Tabelle 1-1 zusammengefasst.

Tabelle 1-1

NetBIOS-Knotentypen
Funktion	Wert
b-Knoten	Verwendet ausschließlich Broadcast-Meldungen zur Registrierung und Auflösung.
p-Knoten	Verwendet ausschließlich die Punkt-zu-Punkt-Kommunikation zur Registrierung und Auflösung.
m-Knoten (gemischt)	Verwendet Broadcast zur Registrierung. Ist dies erfolgreich, wird der NBNS von dem Ergebnis unterrichtet. Verwendet Broadcast zur Auflösung und greift auf den NBNS zurück, falls der Broadcast erfolglos ist.
h-Knoten (hybrid)	Verwendet den NBNS zur Registrierung und Auflösung. Greift auf Broadcast zurück, falls der NBNS nicht antwortet oder nicht funktioniert.

Im Fall von Windows-Clients werden Sie üblicherweise h-Knoten bzw. Hybrid-Knoten aufgelistet finden. Die ersten drei Knotentypen stehen in RFC 1001/1002; h-Knoten dagegen wurden erst zu einem späteren Zeitpunkt von Microsoft erfunden, um die Fehlertoleranz zu erhöhen.

Sie können den Knotentyp eines Windows 95/98/Me-Computers ermitteln, indem Sie den Befehl winipcfg ausführen (über Start > Ausführen oder in der MS-DOS-Eingabeaufforderung) und auf den Button Weitere Info>> klicken. Unter Windows NT/2000/XP können Sie den Befehl ipconfig /all in einer Eingabeaufforderung verwenden. Suchen Sie in jedem Fall nach der Zeile mit der Bezeichnung Knotentyp.

Woraus besteht ein Name?

Die NetBIOS-Namen unterscheiden sich erheblich von den DNS-Hostnamen, mit denen Sie möglicherweise vertraut sind. Zum einen existieren NetBIOS-Namen in einem flachen Namensraum. Das heißt, es gibt keine hierarchischen Ebenen wie in oreilly.de (zwei Ebenen) oder ftp.samba.org (drei Ebenen). NetBIOS-Namen bestehen aus einem einzigen eindeutigen String wie navaho oder hopi innerhalb jeder Arbeitsgruppe oder Domäne. Zum anderen dürfen NetBIOS-Namen maximal 15 Zeichen lang sein und nur aus alphanumerischen Zeichen (a-z, A-Z, 0-9) sowie den folgenden Zeichen bestehen:

Auch wenn Sie einen Punkt (.) in einem NetBIOS-Namen verwenden dürfen, raten wir davon ab, weil diese Namen möglicherweise nicht in künftigen Versionen von NBT funktionieren werden.

Es ist kein Zufall, dass gültige DNS-Namen auch gültige NetBIOS-Namen sind. In der Tat wird der unqualifizierte DNS-Name eines Samba-Servers (das ist der Name ohne den Domänen-Anteil) häufig auch als sein NetBIOS-Name eingesetzt. Wenn Sie beispielsweise ein System mit dem Hostnamen mixtec.ora.com hätten, wäre sein NetBIOS-Name wahrscheinlich MIXTEC (gefolgt von neun Leerzeichen).

Namen und Typen von Ressourcen

Ein NetBIOS-Computer kündigt nicht nur seine Anwesenheit an, sondern gibt auch bekannt, welche Arten von Diensten er anbietet. mixtec könnte also zum Beispiel mitteilen, dass er nicht nur eine Workstation, sondern auch ein Datei-Server ist und Windows Messenger-Nachrichten empfangen kann. Dazu wird an das Ende des Maschinen-(Ressourcen-)Namens ein 16. Byte angehängt, das den Ressourcentyp angibt und den Namen mehrfach - für jeden angebotenen Dienst - registriert (siehe Abbildung 1-10).

Abbildung 1-10

Die Struktur von NetBIOS-Namen

Der ein Byte große Ressourcentyp bezeichnet einen bestimmten Dienst, den der Computer bereitstellt. In diesem Buch kennzeichnen wir den Ressourcentyp häufig durch spitze Klammern (<>), wie in:

Sie können feststellen, welche Namen für einen bestimmten NBT-Computer registriert sind, indem Sie das Windows-Kommandozeilen-Programm nbtstat einsetzen. Da diese Dienste eindeutig sind (d.h., sie können nur jeweils einmal registriert sein), werden sie in der Ausgabe als UNIQUE (engl. eindeutig) bezeichnet. Der folgende Ausschnitt aus einer Ausgabe beschreibt zum Beispiel den Server toltec:

Diese Ausgabe besagt, dass der Server den NetBIOS-Namen toltec als Maschinen- (d.h. Computer-)Namen, als Empfänger von Nachrichten des Windows Messenger-Diensts und als Datei-Server registriert hat. Mögliche Attribute eines Namens sind in Tabelle 1-2 aufgeführt.

Tabelle 1-2

Eindeutige NetBIOS-Ressourcentypen
Benannte Ressource	Hexadezimaler Wert des Byte
Standard-Workstation-Dienst	00
Messenger-Dienst	03
Modem/ISDN-Server-Fernzugriffsdienst (RAS, Remote Access Service)	06
Domain Master Browser Service (Domänen-Hauptsuchdienst; ausgeführt auf primären Domänen-Controllern)	1B
Hauptsuchdienst	1D
NetDDE-Dienst	1F
Datei-Server (einschließlich Drucker-Server)	20
RAS-Client-Dienst	21
Netzwerkmonitoragent	BE
Netzwerkmonitor	BF

Gruppennamen und -typen

SMB kennt auch das Konzept der Gruppen, bei denen sich die Computer selbst registrieren können. Wir haben bereits an früherer Stelle erwähnt, dass die Computer in unserem Beispiel einer Arbeitsgruppe angehören. Eine Arbeitsgruppe fasst mehrere Computer in einem Netzwerk zusammen. Eine Firma kann zum Beispiel die Arbeitsgruppen BUCHHALTUNG und VERKAUF besitzen, die mit jeweils eigenen Servern und Druckern ausgestattet sind. In der Windows-Welt entsprechen Arbeitsgruppen den SMB-Gruppen.

Führen wir unser nbtstat-Beispiel fort. Der Samba-Server toltec ist Mitglied der Arbeitsgruppe METRAN (GROUP-Attribut: hexadezimal 00) und steht bei der Auswahl als Hauptsuchdienst zur Verfügung (GROUP-Attribut: hexadezimal 1E). Hier ist der Rest der Ausgabe von nbtstat:

Die möglichen GROUP-Attribute, die ein Computer besitzen kann, sind in Tabelle 1-3 aufgeführt. Weitere Informationen finden Sie im Buch Windows NT in a Nutshell von Eric Pearce, ebenfalls im O'Reilly Verlag erschienen.

Tabelle 1-3

NetBIOS-Ressourcentypen für Gruppen
Benannte Ressource	Hexadezimaler Wert des Byte
Standard-Workstation-Gruppe	00
Anmelde-Server	1C
Hauptsuchdienst	1D
Normaler Gruppenname (wird bei der Bestimmung des Suchdienstes verwendet)	1E
Internet-Gruppenname (administrativ)	20
<01><02>_ _MSBROWSE_ _<02>	01

Der letzte Eintrag, _ _ MSBROWSE _ _ , wird dazu verwendet, eine Gruppe anderen Hauptsuchdiensten anzukündigen. Die nicht-druckbaren Zeichen im Namen werden in der Ausgabe von nbtstat als Punkte angezeigt. Stören Sie sich nicht daran, wenn Sie nicht alle Ressourcen- oder Gruppentypen verstehen. Sie werden einige davon für Samba nicht benötigen. Die Bedeutung der anderen werden wir im Laufe dieses Kapitels erläutern. Was Sie sich unbedingt merken sollten, ist die Funktionsweise des Namensmechanismus.

Bereichs-ID

In den Anfangstagen der SMB-Netzwerke, bevor NetBIOS-Gruppen eingeführt wurden, gab es eine sehr primitive Methode, um Gruppen von Computern vom Rest des Netzwerks zu isolieren. Jedes SMB-Paket enthält ein Feld namens Bereichs-ID (Scope ID). Dahinter steckte die Idee, dass die Systeme im Netzwerk so konfiguriert werden können, dass sie nur Pakete akzeptieren, deren Bereichs-ID ihrer Konfiguration entspricht. Dieses Merkmal wurde kaum eingesetzt, ist jedoch leider in modernen Implementierungen immer noch vorhanden. Einige der in der Samba-Distribution vorhandenen Programme erlauben es, die Bereichs-ID zu setzen. Allerdings wird dies in einem Netzwerk mit hoher Wahrscheinlichkeit Probleme verursachen. Wir erwähnen die Bereichs-ID nur, damit Sie sich nicht wundern, falls sie Ihnen irgendwo einmal begegnet.

Datagramme und Sitzungen

Lassen Sie uns an dieser Stelle ein wenig abschweifen, um eine andere Aufgabe zu beschreiben, die in der Verantwortung von NBT liegt: die Bereitstellung der Verbindungsdienste zwischen zwei NetBIOS-Computern. NBT bietet zwei Dienste an: den Sitzungsdienst und den Datagrammdienst. Sie müssen diese Dienste nicht vollständig verstehen, um mit Samba zu arbeiten, aber Sie erhalten zumindest eine Vorstellung davon, wie NetBIOS over TCP/IP (NBT) funktioniert und wo Sie nach Fehlern suchen müssen, falls Samba einmal nicht funktionieren sollte.

Der Datagrammdienst stellt keine stabilen Verbindungen zwischen Computern her. Datenpakete werden einfach von einem Computer an einen anderen (oder per Broadcast an alle Rechner im lokalen Netzwerk) gesendet, ohne dass beachtet wird, in welcher Reihenfolge die Pakete am Ziel eintreffen oder ob sie überhaupt ankommen. Datagramme erfordern einen geringeren Verarbeitungsaufwand als Sitzungen, allerdings kann die Zuverlässigkeit der Verbindung leiden. Datagramme werden daher für das schnelle Versenden weniger wichtiger Datenblöcke an einen oder mehrere Computer verwendet. Der Datagrammdienst benutzt für die Kommunikation die einfachen, in Tabelle 1-4 gezeigten Funktionen.

Tabelle 1-4

Datagrammfunktionen
Funktion	Beschreibung
Datagramm senden (Send Datagram)	Sendet ein Datagrammpaket an einen Computer oder an Gruppen von Computern.
Broadcast-Datagramm senden (Send Broadcast Datagram)	Sendet ein Broadcast-Datagramm an alle Computer, die mit der Funktion Receive Broadcast Datagram eines erwarten.
Datagramm empfangen (Receive Datagram)	Empfängt ein Datagramm von einem Computer.
Broadcast-Datagramm empfangen (Receive Broadcast Datagram)	Erwartet ein Broadcast-Datagramm.

Der Sitzungsdienst ist komplizierter. Sitzungen bedienen sich einer Kommunikationsmethode, durch die theoretisch problematische oder unterbrochene Verbindungen zwischen zwei NetBIOS-Anwendungen erkannt werden können. Stellen Sie sich eine NBT-Sitzung mit den Begriffen einer Telefonverbindung vor, einer Analogie, die ganz offensichtlich die Gestaltung des CIFS-Standards beeinflusst hat.

Eine einmal aufgebaute Verbindung bleibt während der gesamten Dauer des Gesprächs bestehen, jede Seite weiß, wer der Anrufer und wer der angerufene Computer ist, und beide können über die einfachen Funktionen miteinander kommunizieren, die Sie in Tabelle 1-5 finden.

Tabelle 1-5

Sitzungsfunktionen
Funktion	Beschreibung
Anrufen	Eine Sitzung zu einem Computer herstellen, der unter einem bestimmten Namen empfangsbereit ist.
Hören	Auf einen Anruf eines bekannten oder anderen Anrufers warten.
Auflegen	Ein Gespräch beenden.
Senden	Daten an den anderen Computer senden.
Empfangen	Daten vom anderen Computer empfangen.
Sitzungszustand	Informationen über die angeforderten Sitzungen erhalten.

Sitzungen bilden das Rückgrat der Ressourcenfreigabe in einem NBT-Netzwerk. Sie werden üblicherweise verwendet, um stabile Verbindungen zwischen Client-Computern und Verzeichnis- oder Druckerfreigaben auf einem Server herzustellen. Der Client »ruft« den Server an und teilt ihm mit, welche Dateien er öffnen möchte, welche Daten er austauschen will usw. Diese »Anrufe« können sehr lange dauern, unter Umständen mehrere Stunden oder sogar Tage - alles während einer einzigen Verbindung. Tritt ein Fehler auf, sorgt die Sitzungs-Software (TCP) für eine erneute Übertragung der Daten, bis sie korrekt übermittelt worden sind. Im Gegensatz dazu verwendet der Datagrammdienst, der ohne Kontrolle arbeitet, das verbindungslose UDP-Protokoll.

In der Realität funktioniert die Abwicklung problematischer Sitzungen häufig nicht ganz korrekt. Wenn die Verbindung aus irgendeinem Grund unterbrochen wird, können die Sitzungsinformationen leicht ungültig werden. In diesem Fall kann die Sitzung nur wieder hergestellt werden, indem einer der Computer den anderen »anruft« und von vorn beginnt.

Wenn Sie weitere Informationen zu diesem Thema wünschen, sehen Sie sich RFC 1001 an. Folgende Punkte sollten Sie sich aber auf jeden Fall merken:

Eine Einführung in das SMB-Protokoll

Nun werden wir einige grundlegende technische Details betrachten und die Einzelheiten des SMB-Protokolls erkunden. Vermutlich müssen Sie gar nicht so viel darüber wissen, um ein einfaches Samba-Netzwerk zu implementieren, und werden deshalb beim ersten Lesen diesen Abschnitt möglicherweise auslassen oder überspringen und sich gleich dem nächsten Abschnitt widmen (»Windows-Arbeitsgruppen und -Domänen«). Da wir jedoch davon ausgehen, dass Sie länger für die Wartung eines Samba-Netzwerks zuständig sein werden, denken wir, dass es Ihnen hilft, wenn Sie verstehen, wie es tatsächlich funktioniert. Sie werden schneller in die Lage versetzt, auftretende Probleme zu diagnostizieren und zu beheben.

Auf einer höheren Ebene ist die SMB-Protokollsammlung relativ einfach. Sie enthält Befehle für alle Datei- und Druck-Operationen, die Sie auf einer lokalen Festplatte oder einem lokalen Drucker ausführen könnten:

Jede Operation kann in Form einer SMB-Nachricht kodiert und zu bzw. von einem Server übermittelt werden. Der Originalname »SMB« stammt von der Art und Weise, in der die Befehle formatiert sind: Es handelt sich um Versionen der Datenstrukturen für die normalen DOS-Systemaufrufe oder Server Message Blocks, die für die Übertragung an einen anderen Computer im Netzwerk umgestaltet wurden.

Das SMB-Format

Richard Sharpe vom Samba-Team definiert SMB als ein Request-Response-Protokoll (Anforderung/Antwort-Protokoll).⁴ Im Prinzip bedeutet dies, dass ein Client eine SMB-Anforderung an einen Server sendet. Der Server übermittelt dann eine SMB-Antwort an den Client. Es gibt nur einen einzigen, selten auftretenden Fall, in dem ein Server eine Nachricht sendet, die keine Antwort an einen Client darstellt.

Eine SMB-Nachricht ist nicht so kompliziert, wie Sie vielleicht glauben. Schauen wir uns die interne Struktur einer solchen Nachricht einmal genauer an. Sie kann in zwei Teile unterteilt werden: den Header, der eine feste Größe hat, und den Befehls-String, dessen Größe je nach dem Inhalt der Nachricht deutlich variieren kann.

Das SMB-Header-Format

Tabelle 1-6 zeigt das Format eines SMB-Headers. Das COM-Feld kennzeichnet den ausgeführten Befehl. SMB-Befehle müssen nicht unbedingt alle Felder des SMB-Headers verwenden. Wenn beispielsweise ein Client das erste Mal versucht, eine Verbindung zu einem Server herzustellen, besitzt er nicht einmal einen TID-Wert (Tree Identifier) - dieser Wert wird nach einem erfolgreichen Verbindungsaufbau zugeordnet -, daher wird in das entsprechende Header-Feld keine TID eingetragen. Andere Felder können bei Nichtbenutzung mit Nullen aufgefüllt werden.

Tabelle 1-6

SMB-Header-Felder
Feld	Größe (Bytes)	Beschreibung
0xFF 'SMB'	1	Protokollkennzeichnung
COM	1	Befehlscode, von 0x00 bis 0xFF
RCLS	1	Fehlerklasse
REH	1	Reserviert
ERR	2	Fehlercode
REB	1	Reserviert
RES	14	Reserviert
TID	2	TID; eine eindeutige ID für eine Ressource, die vom Client benutzt wird
PID	2	Prozess-ID des Anrufers
UID	2	Benutzer-ID
MID	2	Multiplex-ID; wird verwendet, um Anfragen innerhalb eines Prozesses zu leiten

Das SMB-Befehlsformat

Unmittelbar hinter dem Header steht eine variable Anzahl von Bytes, die einen SMB-Befehl oder eine SMB-Antwort bilden. Jeder Befehl, wie etwa Open File (COM-Feld-ID: SMBopen) oder Get Print Queue (SMBsplretq ), besitzt seine eigene Gruppe von Parametern und Daten. Wie die SMB-Header-Felder müssen auch die Befehlsfelder nicht unbedingt alle ausgefüllt sein - je nachdem, um welchen Befehl es sich handelt. So setzt beispielsweise der Befehl Get Server Attributes (SMBdskattr) die Felder WCT und BCC auf null. Die Felder des Befehlssegments werden in Tabelle 1-7 dargestellt.

Tabelle 1-7

Inhalt eines SMB-Befehls
Feld	Größe (Bytes)	Beschreibung
WCT	1	Wortzähler
VWV	Variable	Parameterwörter (Größe durch WCT vorgegeben)
BCC	2	Parameter-Byte-Zähler
DATA	Variable	Daten (Größe durch BCC vorgegeben)

Machen Sie sich keine Sorgen, falls Sie nicht jedes Feld verstehen - dies ist für die Benutzung von Samba auf Administratorebene nicht notwendig. Allerdings sind sie für das Auswerten von Systemmeldungen ganz nützlich. Weiter hinten in diesem Abschnitt werden wir Ihnen einige der gebräuchlicheren SMB-Meldungen zeigen, die Clients und Server mit Hilfe einer angepassten Version von tcpdump versenden. (Falls Sie einen SMB-Sniffer mit einer grafischen Oberfläche bevorzugen, versuchen Sie es einmal mit Ethereal, der die GTK-Bibliotheken verwendet. Unter http://www.ethereal.com finden Sie nähere Informationen über dieses Werkzeug.)

Weitere Informationen über die einzelnen Befehle im SMB-Protokoll finden Sie in der CIFS Technical Reference unter http://www.snia.org/ tech_activities/CIFS.

SMB-Variationen

Das SMB-Protokoll wurde seit seiner Einführung mehrere Male um neue Befehle erweitert. Jede neue Version ist abwärts kompatibel zu den vorangegangenen Versionen. Dadurch ist es möglich, in einem LAN Clients und Server zu betreiben, die gleichzeitig unterschiedliche Versionen des SMB-Protokolls benutzen.

Tabelle 1-8 stellt die wichtigsten Versionen des SMB-Protokolls vor. Innerhalb jedes »Dialekts« von SMB gibt es viele Unterversionen, die Befehle enthalten, die wiederum bestimmte Releases wichtiger Betriebssysteme unterstützen. Der ID-String in Spalte 2 wird von Clients und Servern verwendet, um festzustellen, auf welcher Ebene des Protokolls sie miteinander kommunizieren werden.

Tabelle 1-8

SMB-Protokolldialekte
Protokollname	ID-String	Verwendet durch
Core	PC NETWORK PROGRAM 1.0
Core Plus	MICROSOFT NETWORKS 1.03
LAN Manager 1.0	LANMAN1.0
LAN Manager 2.0	LM1.2X002
LAN Manager 2.1	LANMAN2.1
NT LAN Manager 1.0	NT LM 0.12	Windows NT 4.0
Sambas NT LM 0.12	Samba	Samba
Common Internet File System	CIFS 1.0	Windows 2000/XP

Samba implementiert die Spezifikation NT LM 0.12 für NT LAN Manager 1.0. Sie ist abwärts kompatibel mit all den anderen SMB-Varianten. Die CIFS-Spezifikation ist in Wirklichkeit LAN Manager 0.12 mit einigen speziellen Ergänzungen.

SMB-Clients und -Server

Wie bereits erwähnt, handelt es sich bei SMB um ein Client/Server-Protokoll. Im Wortsinn bedeutet dies, dass ein Client eine Anforderung an einen Server sendet, der auf die Anforderung reagiert und eine Antwort zurückschickt. Die Rollen von Client und Server können allerdings oft vertauscht werden, manchmal sogar innerhalb einer einzigen SMB-Sitzung. Betrachten Sie zum Beispiel die beiden Windows 95/98/Me-Computer in Abbildung 1-11. Der Rechner mit dem Namen maya gibt einen Drucker im Netzwerk frei, und der Rechner mit dem Namen toltec hat ein Festplattenverzeichnis freigegeben. Beim Zugriff auf das Netzlaufwerk von toltec übernimmt maya die Rolle des Clients. Führt maya dagegen einen Druckjob für toltec aus, ist er in der Rolle des Servers.

Abbildung 1-11

Zwei Computer, die Ressourcen freigeben

Bei Microsoft Windows-Produkten ist sowohl der SMB-Client als auch der SMB-Server in das Betriebssystem integriert. Oft kommt es in einem normalen Netzwerk vor, dass Windows zu einem bestimmten Zeitpunkt als Server, als Client, in beiden Rollen oder als keiner von beiden agiert. Samba wurde zwar vorrangig dafür entwickelt, als Server zu fungieren, es gibt jedoch auch Möglichkeiten, es selbst und die mit ihm verbundene Software als SMB-Client agieren zu lassen. Es ist sogar möglich, ein Unix-System so einzurichten, dass es als SMB-Client und nicht als Server arbeitet. In Kapitel 5 finden Sie weitere Informationen zu diesem Thema.

Eine einfache SMB-Verbindung

Client und Server müssen drei Schritte ausführen, um eine Verbindung zu einer Ressource aufzubauen:

Wir werden jeden Schritt durch die Augen eines nützlichen Werkzeugs betrachten, das wir bereits erwähnten: das modifizierte tcpdump, das auf der Samba-Website zur Verfügung steht.

Sie können das Programm tcpdump von http://www.samba.org aus dem Verzeichnis samba/ftp/tcpdump-smb herunterladen; die neueste Version war beim Schreiben dieses Buches die Version 3.7.2. Benutzen Sie dieses Programm genau wie das normale tcpdump-Programm, fügen Sie jedoch die Option -s 1500 hinzu, um sicherzugehen, dass Sie das ganze Paket und nicht nur die ersten paar Bytes erhalten.

Eine NetBIOS-Sitzung beginnen

Wenn ein Benutzer zum ersten Mal die Anforderung für den Zugriff auf ein Netzlaufwerk ausgibt oder einen Druckjob an einen entfernten Drucker sendet, sorgt NetBIOS dafür, dass eine Verbindung auf der Sitzungsschicht aufgebaut wird. Das Ergebnis ist ein bidirektionaler Kanal zwischen dem Client und dem Server. Client und Server benötigen nur zwei Nachrichten, um diese Verbindung zu etablieren. Sie sehen dies im folgenden Request-Response-Beispiel, das von tcpdump aufgezeichnet wurde.

Zuerst sendet der Client eine Anforderung, um eine Sitzung zu öffnen. tcpdump gibt Folgendes aus:

Die Protokollvariante aushandeln

Als Nächstes sendet der Client eine Nachricht an den Server, um ein SMB-Protokoll auszuhandeln. Wie bereits erwähnt, setzt der Client sein TID-Feld (Tree Identifier) auf null, weil er noch nicht weiß, welche TID er benutzen soll. Ein Tree Identifier ist eine Zahl, die eine Verbindung zu einer Freigabe auf einem Server repräsentiert.

Der Befehl in der Nachricht lautet SMBnegprot, das ist eine Anforderung zur Aushandlung einer Protokollvariante, die während der gesamten Sitzung verwendet werden soll. Beachten Sie, dass der Client dem Server eine Liste aller Varianten schickt, die er versteht, und nicht umgekehrt:

Der Server antwortet auf die SMBnegprot-Anforderung mit einem Index (bei dem der Zähler bei 0 beginnt) in die Liste der Varianten, die der Client anbietet, oder dem Wert 0xFF, falls keine der Protokollvarianten akzeptabel ist:

In diesem Beispiel antwortet der Server mit dem Wert 5, der angibt, dass für den Rest der Sitzung der NT LM 0.12-Dialekt verwendet werden wird.

Setzen der Sitzungs- und Anmeldeparameter

Der nächste Schritt besteht darin, die Sitzungs- und Anmeldeparameter für die Sitzung zu übermitteln. Dies erledigen Sie mit dem Befehl SMBSesssetupX. Zu den Parametern gehören unter anderem:

In diesem Beispiel erlaubt es der Befehl zum Einrichten der Sitzung SMBsesssetupX, dass ein zusätzlicher SMB-Befehl an ihn angehängt wird (dies erkennt man an dem Buchstaben X am Ende des Befehlsnamens). Der hexadezimale Code des zweiten Befehls wird im Com2-Feld angegeben. Hier lautet der Befehl 0x75, das ist der Befehl SMBtconX (Tree Connect and X). Die Nachricht SMBtconX sucht nach dem Namen der Ressource im smb_buf-Puffer. In diesem Beispiel enthält smb_buf den String \\TOLTEC\SPIRIT, also den vollständigen Pfadnamen zu einem freigegebenen Verzeichnis auf toltec. Durch die Benutzung solcher »and X«-Befehle werden die einzelnen Transaktionen beschleunigt, da der Server nicht darauf warten muss, dass der Client eine zweite Anforderung stellt.

Beachten Sie, dass die TID immer noch null ist. Schließlich liefert der Server eine TID an den Client zurück, wodurch angezeigt wird, dass der Zugriff des Benutzers autorisiert wurde und die Ressource benutzt werden kann:

Das Feld ServiceType wurde auf »A« gesetzt. Dies bedeutet, dass es sich um einen Dateidienst handelt. Verfügbare Diensttypen sind:

Nachdem eine TID zugewiesen wurde, kann der Client diese als Handle benutzen, um alle Operationen auszuführen, die er auch auf einem lokalen Laufwerk ausführen würde. Er kann Dateien öffnen, lesen und schreiben, sie löschen, neue Dateien erzeugen, nach Dateinamen suchen und so weiter.

Windows-Arbeitsgruppen und -Domänen

Bisher haben wir die grundlegende SMB-Technik behandelt. Gäbe es in Ihrem Netzwerk lediglich einfache MS-DOS-Clients, wäre dies völlig ausreichend für Sie. Wir gehen aber davon aus, dass Sie Windows-Clients, vor allem neueren Datums, unterstützen wollen; deshalb wollen wir als Nächstes die Microsoft-Erweiterungen für den SMB-Netzwerkbetrieb beschreiben - das heißt Windows-Arbeitsgruppen und Windows-Domänen.

Windows-Arbeitsgruppen

Windows-Arbeitsgruppen sind den bereits beschriebenen SMB-Gruppen sehr ähnlich. Sie müssen nur einige zusätzliche Dinge wissen.

Durchsuchen

Das Durchsuchen (Browsing) bezeichnet den Vorgang des Auffindens anderer Computer und freigegebener Ressourcen im Windows-Netzwerk. Beachten Sie, dass es keine Verbindung zu einem Webbrowser gibt, abgesehen vom allgemeinen Konzept des »Entdeckens, was es gibt«. Andererseits ähnelt das Durchsuchen des Windows-Netzwerks dem Durchsuchen des Webs dahingehend, dass sich Dinge ohne Warnung ändern können.

Bevor es die Möglichkeit zum Durchsuchen des Netzwerks gab, mussten Benutzer den Namen des Computers wissen, mit dem sie eine Verbindung aufnehmen wollten, und manuell einen UNC-Pfad wie den folgenden in eine Anwendung oder einen Datei-Manager eingeben, um auf Ressourcen zuzugreifen:

Das Durchsuchen ist bedeutend bequemer. Sie können den Inhalt eines Netzwerks auf einem Windows-Client mit Hilfe des grafischen Mittels der Netzwerkumgebung⁵ untersuchen.

Schauen wir uns zunächst das erste Verfahren an. In jedem LAN (oder Subnetz) mit einer Windows-Arbeitsgruppe oder -Domäne ist einer der Computer dafür verantwortlich, die Liste der Computer zu verwalten, die gerade über das Netzwerk erreichbar sind. Dieser Computer wird Lokaler Hauptsuchdienst (Local Master Browser; LMB) genannt, die von ihm verwaltete Liste heißt Suchliste (Browse List). Computer in einem Subnetz verwenden die Suchliste, um den Netzwerkverkehr während des Durchsuchens zu verringern. Damit nicht jeder Computer dynamisch eine Liste der verfügbaren Computer erstellen muss, können die Computer einfach den lokalen Hauptsuchdienst befragen, der ihnen eine vollständige und aktuelle Liste zurückliefert.

Um die Ressourcen eines Computers zu durchsuchen, muss der Benutzer sich mit diesem Computer verbinden; die bereitgestellten Ressourcen sind nicht in der Suchliste enthalten. Sie gelangen an die Ressourcenliste eines Computers, indem Sie auf sein Symbol in der Netzwerkumgebung doppelklicken. Wie zu Beginn dieses Kapitels beschrieben, antwortet der Computer mit der Liste der freigegebenen Ressourcen, sofern der Benutzer sich erfolgreich angemeldet hat.

Jeder Server in einer Windows-Arbeitsgruppe muss seine Anwesenheit dem lokalen Hauptsuchdienst ankündigen, nachdem er seinen NetBIOS-Namen erfolgreich registriert hat. Zudem muss er sich (zumindest theoretisch) beim lokalen Hauptsuchdienst abmelden, wenn er herunterfährt oder aus anderen Gründen die Arbeitsgruppe verlässt. Es liegt in der Verantwortung des lokalen Hauptsuchdienstes, die gemeldeten Computernamen zu speichern.

Die Windows-Netzwerkumgebung kann sich merkwürdig verhalten: Solange Sie einen Computer nicht zum Durchsuchen auswählen, kann das Fenster Netzwerkumgebung veraltete Daten anzeigen. Es kann also abgestürzte oder ausgeschaltete Computer zeigen, oder es können Namen von Computern fehlen, die bereits erfolgreich registriert sind. Kurz gesagt, erst wenn Sie einen Server ausgewählt und eine Verbindung zu ihm hergestellt haben, können Sie sicher sein, dass die Freigaben und Drucker tatsächlich im Netzwerk verfügbar sind.

Im Gegensatz zu den Rollen, die wir bereits beschrieben haben, kann fast jedes Windows-System (einschließlich Windows for Workgroups sowie Windows 95/98/Me und NT/2000/XP) als lokaler Hauptsuchdienst fungieren. Der lokale Hauptsuchdienst kann einen oder mehrere Sicherungssuchdienste im lokalen Subnetz besitzen, die seine Aufgabe übernehmen, falls er ausfällt oder unerreichbar wird. Um einen laufenden Betrieb zu gewährleisten, synchronisieren die lokalen Sicherungssuchdienste ihre Suchlisten häufig mit dem lokalen Hauptsuchdienst.

Und so berechnen Sie die minimale Anzahl der Sicherungssuchdienste, die in einer Arbeitsgruppe eingesetzt werden:

Momentan gibt es keine obere Grenze für die Anzahl der Sicherungssuchdienste, die vom lokalen Hauptsuchdienst eingesetzt werden können.

Suchdienstwahlen

Das Durchsuchen ist ein wichtiger Aspekt bei jeder Windows-Arbeitsgruppe. Aber nicht alles läuft in jedem Netzwerk perfekt. Nehmen wir an, dass der Windows-Rechner auf dem Schreibtisch des Geschäftsführers einer kleinen Firma der lokale Hauptsuchdienst ist - dies gilt nur so lange, bis er ihn herunterfährt, um die frei gewordene Steckdose für seinen Massagestuhl zu verwenden. Zu diesem Zeitpunkt kann die Windows NT-Workstation im Ersatzteillager damit einverstanden sein, den Suchdienst zu übernehmen. Aber dieser Computer führt gerade eine große, schlecht geschriebene Anwendung aus, die den Prozessor bis zum Äußersten belastet. Also muss das Durchsuchen sehr tolerant auf neu hinzukommende und abwandernde Computer reagieren. Da fast jeder Windows-Computer als Suchdienst fungieren kann, muss es eine Möglichkeit geben, den Computer zu bestimmen, der diese Aufgabe zu erledigen hat. Dieser Vorgang heißt Wahl (election).

In fast jedes Windows-Betriebssystem ist ein Auswahlalgorithmus integriert, so dass die Windows-Computer gemeinsam entscheiden können, wer den lokalen Hauptsuchdienst und wer lokale Sicherungssuchdienste übernehmen soll. Eine solche Wahl kann jederzeit erzwungen werden. Lassen Sie uns annehmen, dass unser Geschäftsführer seine Massage beendet hat und den Server neu startet. Wenn der Server hochgefahren ist, kündigt er seine Anwesenheit an und erzwingt eine Wahl, über die festgestellt wird, ob der PC im Ersatzteillager weiterhin den Hauptsuchdienst ausführen soll.

Wird eine Wahl durchgeführt, sendet jeder Computer mittels Datagrammen Angaben über sich selbst an das Netzwerk. Zu diesen Angaben gehören:

Diese Werte legen fest, welcher Computer den höheren Rang besitzt und deshalb den lokalen Hauptsuchdienst ausführen wird. (Kapitel 7 beschreibt diesen Vorgang genauer.) Die Architektur, die dies gewährleisten soll, ist nicht gerade elegant gestaltet und birgt überdies Sicherheitsprobleme. Während das Durchsuchen einer Domäne in die Domänensicherheit integriert werden kann, berücksichtigt der Algorithmus nicht, welche Computer Suchdienste übernehmen. Daher ist es jedem Computer, der einen Suchdienst ausführt, möglich, sich als Teilnehmer bei Suchdienstwahlen zu registrieren und (nach dem Gewinnen einer Wahl) die Suchliste zu verändern. Nichtsdestotrotz ist das Durchsuchen eines der Schlüsselmerkmale von Windows-Netzwerken, und die Erfordernisse der Abwärtskompatibilität stellen sicher, dass dies noch mehrere Jahre lang so bleibt.

Windows 95/98/Me-Authentifizierung

Wenn mit Windows 95/98/Me in einer Windows-Arbeitsgruppe gearbeitet wird, können drei Arten von Kennwörtern auftreten:

Die Funktionsweise des Windows-Kennworts kann bei Unix-Systemadministratoren Verwirrung und Kopfschütteln auslösen. Das Kennwort dient nicht dazu, nicht-autorisierten Benutzern die Benutzung des Computers zu verwehren. (Falls Sie das nicht glauben, klicken Sie einfach einmal den Abbrechen-Button und warten, was passiert!) Stattdessen wird das Windows-Kennwort dazu verwendet, den Zugang zu einer Datei zu erlangen, die die Kennwörter für das Windows-Netzwerk und die Netzwerkressource enthält. Für jeden im System registrierten Benutzer gibt es eine solche Datei. Diese befindet sich im Verzeichnis C:\Windows. Ihr Name besteht aus dem Namen des jeweiligen Benutzer-Accounts, gefolgt von der Erweiterung .pwl. Lautet beispielsweise der Name des Benutzer-Accounts »sarah«, ist die Datei unter C:\Windows\sarah.pwl zu finden. Diese Datei ist mit dem Windows-Kennwort verschlüsselt.

Als Sicherheitsmaßnahme könnten Sie auf Windows 95/98/Me-Clients nach »falschen« .pwl-Dateien suchen, die angelegt worden sind, weil Benutzern bei der Anmeldung Fehler unterlaufen sind. Eine .pwl-Datei lässt sich leicht knacken und enthält möglicherweise gültige Kennwörter für Samba-Accounts und Netzwerkfreigaben.

Beim ersten Zugriff auf das Netzwerk versucht Windows, das Windows-Kennwort als Kennwort für das Windows-Netzwerk zu verwenden. Ist dies erfolgreich, wird der Benutzer nicht nach zwei separaten Kennwörtern gefragt. Bei nachfolgenden Anmeldungen am Windows-System wird der Benutzer automatisch auch am Windows-Netzwerk angemeldet, wodurch sich die Angelegenheit für ihn deutlich vereinfacht.

Auch freigegebenen Netzwerkressourcen in der Arbeitsgruppe können Kennwörter zugewiesen werden, um ihre Erreichbarkeit einzuschränken. Versucht ein Benutzer das erste Mal, auf die Ressource zuzugreifen, wird er nach deren Kennwort gefragt. Eine Checkbox in der Kennwort-Dialogbox ermöglicht es dem Benutzer, das Kennwort in seine Kennwortliste aufzunehmen. Das ist die Standardeinstellung. Wird dies akzeptiert, speichert Windows das Kennwort in der .pwl-Datei des Benutzers. Alle späteren Authentifizierungen bei dieser Ressource werden automatisch durch Windows erledigt.

Sambas Ansatz für die Arbeitsgruppen-Authentifizierung ist ein wenig anders. Dies liegt daran, dass das Arbeitsgruppenmodell von Windows mit dem des Unix-Hosts gemischt wird, auf dem Samba läuft. In Kapitel 9 gehen wir darauf näher ein.

Windows NT-Domänen

Das Peer-to-Peer-Netzwerkmodell der Arbeitsgruppen funktioniert ziemlich gut, solange die Anzahl der Computer im Netzwerk klein ist und es eine eng verwobene Gemeinschaft von Benutzern gibt. In größeren Netzwerken erweist sich jedoch die Einfachheit der Arbeitsgruppen als einschränkender Faktor. Arbeitsgruppen bieten nur die einfachste Stufe an Sicherheit, und da jede Ressource ihr eigenes Kennwort besitzen darf, ist es für die Benutzer unbequem, sich das Kennwort für jede einzelne Ressource in einem großen Netzwerk zu merken. Und auch wenn dies kein Problem darstellen würde, finden es viele Leute frustrierend, ihren Arbeitsfluss zu unterbrechen, um jedes Mal ein Kennwort in eine Dialogbox einzugeben, wenn auf eine freigegebene Ressource im Netzwerk zugegriffen wird.

Um die Ansprüche größerer Netzwerke zu befriedigen, führte Microsoft mit Windows NT 3.51 das Konzept der Domänen ein. Eine Windows NT-Domäne ist im Prinzip eine Arbeitsgruppe von SMB-Computern, die ein zusätzliches Element besitzen: einen Server, der als Domänen-Controller fungiert (siehe Abbildung 1-12).

Abbildung 1-12

Eine einfache Windows-Domäne

Domänen-Controller

Ein Domänen-Controller in einer Windows NT-Domäne funktioniert fast wie ein NIS-Server (Network Information Service) in einem Unix-Netzwerk. Das heißt, er verwaltet eine domänenweite Datenbank mit Benutzer- und Gruppeninformationen und führt verwandte Dienste aus. Die Aufgaben, für die ein Domänen-Controller verantwortlich ist, drehen sich hauptsächlich um Sicherheit, einschließlich der Authentifizierung, das heißt dem Vorgang des Gewährens oder Verweigerns des Zugriffs eines Benutzers auf die Ressourcen einer Domäne. Üblicherweise wird dies durch den Einsatz eines Benutzernamens und eines Kennworts erledigt. Der Dienst, der die Datenbank auf den Domänen-Controllern verwaltet, wird Security Account Manager (SAM) genannt.

Das Windows NT-Sicherheitsmodell setzt Sicherheits-IDs (Security Identifier; SIDs) und Zugriffskontrolllisten (Access Control Lists; ACLs) ein. Sicherheits-IDs werden dazu verwendet, Objekte in der Domäne zu repräsentieren. Dazu gehören unter anderem Benutzer, Gruppen, Computer und Prozesse. SIDs werden üblicherweise in ASCII-Form als durch Bindestriche getrennte Felder geschrieben:

Der Teil der SID, der mit dem »S« beginnt und bis zum am weitesten rechts gelegenen Bindestrich führt, identifiziert eine Domäne. Die Zahl hinter dem ganz rechten Bindestrich wird relative ID (Relative Identifier; RID) genannt und ist eine eindeutige Nummer innerhalb der Domäne, die den Benutzer, die Gruppe, den Computer oder ein anderes Objekt kennzeichnet. Die RID ist analog zur Benutzer-ID (UID) oder Gruppen-ID (GID) auf einem Unix-System oder innerhalb einer NIS-Domäne.

ACLs stellen die gleiche Funktionalität zur Verfügung wie die »rwx«-Dateizugriffsrechte bei Unix-Systemen. Allerdings sind ACLs vielseitiger. Die Unix-Dateizugriffsrechte setzen nur die Rechte für den Eigentümer und die Gruppe, zu denen die Datei gehört, sowie für »andere«, das heißt alle anderen Benutzer. Windows NT/2000/XP-ACLs erlauben es, Zugriffsrechte individuell für eine beliebige Anzahl zufällig ausgewählter Benutzer und/oder Gruppen einzustellen. ACLs bestehen aus einem oder mehreren Zugriffskontrolleinträgen (Access Control Entries; ACEs), die jeweils eine SID und die damit verknüpften Zugriffsrechte enthalten.

Bei einigen Unix-Varianten wurde die ACL-Unterstützung als Standardmerkmal hinzugefügt, für andere steht sie als Zusatzfunktion zur Verfügung. Samba unterstützt die Zuordnung von Windows- auf Unix-ACLs und umgekehrt. Dies wird in Kapitel 8 näher behandelt.

Primärer Domänen-Controller und Backup-Domänen-Controller

Sie haben bereits etwas über Haupt- und Sicherungssuchdienste erfahren. Das Konzept der Domänen-Controller ist ähnlich. Eine Domäne besitzt einen primären Domänen-Controller (PDC) und kann außerdem einen oder mehrere Backup-Domänen-Controller (Backup Domain Controller; BDC) besitzen. Fällt der PDC aus oder wird unerreichbar, werden seine Pflichten automatisch von einem der BDCs übernommen. Die BDCs synchronisieren ihre SAM-Daten häufig mit dem PDC. Im Bedarfsfall kann einer von ihnen daher sofort damit beginnen, die Dienste des Domänen-Controllers zu übernehmen, ohne die Clients zu beeinträchtigen. Allerdings verfügen die BDCs nur über schreibgeschützte Kopien der SAM-Datenbank; sie können ihre Daten nur aktualisieren, indem sie sie mit einem PDC abgleichen. Ein Server in einer Windows-Domäne kann die SAM-Datenbank eines beliebigen PDC oder BDC verwenden, um einen Benutzer zu authentifizieren, der versucht, auf seine Ressourcen zuzugreifen und sich an der Domäne anzumelden.

Alle aktuellen Windows-Versionen können sich als Clients an einer Domäne anmelden, um auf die Ressourcen des Domänen-Servers zuzugreifen. Die Systeme, die als Mitglieder der Domäne betrachtet werden, gehören einer etwas exklusiveren Kategorie an, die aus dem PDC und den BDCs sowie den Domänen-Member-Servern besteht. Das sind Systeme, die einer Domäne als Mitglieder beigetreten sind und den Domänen-Controllern bekannt sind, da sie einen Account in der SAM-Datenbank besitzen.

Authentifizierung

Wenn ein Benutzer sich an einer Windows-Domäne anmeldet, indem er einen Benutzernamen und ein Kennwort eingibt, wird durch den Client-Computer und einen Domänen-Controller ein sicheres Challenge-Response-Protokoll gestartet, um zu überprüfen, ob der Benutzername und das Kennwort gültig sind. Anschließend sendet der Domänen-Controller eine SID an den Client zurück, der diese verwendet, um ein Security Access Token (SAT) zu erzeugen, das nur für dieses System gilt und für die weitere Authentifizierung benutzt wird. In dieses Zugriffs-Token sind Informationen über den Benutzer kodiert, einschließlich des Benutzernamens, der Gruppe und der Rechte, die dieser Benutzer innerhalb der Domäne besitzt. Nun ist der Benutzer an der Domäne angemeldet.

Versucht der Client danach, auf eine freigegebene Ressource innerhalb der Domäne zuzugreifen, tritt das Client-System in einen sicheren Challenge-Response-Austausch mit dem Server der Ressource ein. Der Server wiederum beginnt seinerseits eine sichere Challenge-Response-Kommunikation mit einem Domänen-Controller, um festzustellen, ob der Client gültig ist. (Tatsächlich geschieht Folgendes: Der Server nutzt Informationen, die er vom Client erhalten hat, um so zu tun, als sei er der Client, und sich bei dem Domänen-Controller zu authentifizieren. Wenn der Domänen-Controller die Daten ausgewertet hat, schickt er eine SID an den Server zurück, der diese einsetzt, um sein eigenes SAT für den Client zu erzeugen und im Namen des Clients den Zugriff auf seine lokale Ressource zu erlauben.) An dieser Stelle ist der Client für die Ressourcen auf dem Server authentifiziert und darf auf sie zugreifen. Der Server verwendet die SID im Zugriffs-Token, um festzustellen, welche Zugriffsrechte der Client besitzt, um die angeforderte Ressource zu nutzen und zu modifizieren. Dazu vergleicht er die Rechte mit den Einträgen in der ACL der Ressource.

Diese Authentifizierungsmethode mag zwar überaus kompliziert erscheinen, allerdings erlaubt sie es Clients, sich zu authentifizieren, ohne Klartextkennwörter durch das Netzwerk zu schicken. Darüber hinaus ist sie bedeutend schwieriger zu knacken als die relativ schwache Arbeitsgruppensicherheit, die wir zuvor beschrieben haben.

Namendienst mit WINS und DNS

Der Windows Internet Name Service (WINS) ist Microsofts Implementierung eines NetBIOS-Name-Servers (NBNS). Als solcher hat WINS viele der Eigenschaften von NetBIOS übernommen. Zunächst ist der Namensraum »flach«. Sie können Ihren Computern also nur einfache Namen wie inca, mixtec oder navaho und Ihren Arbeitsgruppen Namen wie PERU, MEXICO oder USA geben. Außerdem ist WINS dynamisch: Wenn ein Client hochfährt, muss er seinen Hostnamen, seine Adresse und seine Arbeitsgruppe an den lokalen WINS-Server melden. Der WINS-Server behält diese Informationen, solange der Client seine WINS-Registrierung regelmäßig erneuert, womit er seine Anwesenheit im Netzwerk kundtut. Beachten Sie, dass WINS-Server nicht Arbeitsgruppen- oder domänenbezogen arbeiten. Sie können Informationen für mehrere Domänen und/oder Arbeitsgruppen enthalten, die in mehr als einem Subnetz existieren.

Es ist möglich, mehrere WINS-Server so einzurichten, dass sie sich gegenseitig synchronisieren. Damit können Einträge von Computern, die sich am Netzwerk an- oder abmelden, zwischen den WINS-Servern ausgetauscht werden. In der Theorie klingt das effizient, aber in der Praxis kann sich dieses Verfahren als schwerfällig erweisen, wenn Sie mehrere WINS-Server im Netzwerk einsetzen. Da WINS-Dienste mehrere Subnetze überbrücken können (Sie können die Adresse des WINS-Servers in jedem Client fest einstellen oder sie über DHCP beziehen), ist es häufig effektiver, für alle Windows-Clients denselben WINS-Server zu verwenden, unabhängig von der Anzahl der Windows-Domänen. Auf diese Weise gibt es nur einen autoritativen WINS-Server mit den richtigen Daten, anstatt dass mehrere WINS-Server ständig aushandeln müssen, welche Daten aktueller sind.

Der momentan aktive WINS-Server wird auch als primärer WINS-Server bezeichnet. Sie können ebenfalls einen sekundären WINS-Server installieren, der die Aufgaben des primären WINS-Servers übernimmt, falls dieser ausfällt oder unerreichbar wird. Der primäre sowie alle anderen WINS-Server synchronisieren ihre Adressdatenbanken regelmäßig.

In der Windows-Betriebssystemfamilie können Sie nur die Server-Ausgabe von Windows NT/2000 als WINS-Server einsetzen. Auch Samba 2.2 kann als primärer WINS-Server arbeiten, ist aber nicht in der Lage, seine Datenbank mit anderen WINS-Servern zu synchronisieren. Daher kann es nicht als sekundärer WINS-Server oder als primärer WINS-Server für einen sekundären WINS-Server mit Windows fungieren.

Standardmäßig führt WINS den Namensdienst aus, obwohl Microsoft mit Windows NT 4 Server DNS eingeführt hat. Es ist kompatibel mit DNS, das auf praktisch jedem Unix-System Standard ist. Ein Unix-Server (wie etwa der Samba-Host) kann ebenfalls für DNS eingesetzt werden.

Vertrauensbeziehungen

Ein weiterer Aspekt von Windows NT-Domänen, der in Samba 2.2 noch nicht unterstützt wird, ist die Tatsache, dass es möglich ist, eine Vertrauensbeziehung zwischen Domänen einzurichten, die es Clients in einer Domäne erlaubt, auf die Ressourcen in einer anderen Domäne zuzugreifen, ohne eine weitere Authentifizierung zu durchlaufen. Das dabei befolgte Protokoll wird als Pass-Through Authentication bezeichnet. Die Zugangsdaten des Benutzers werden vom Client-System in der ersten Domäne an den Server in der zweiten Domäne übermittelt, der einen Domänen-Controller in der ersten (vertrauenswürdigen) Domäne konsultiert, um zu überprüfen, ob der Benutzer gültig ist, bevor er Zugang zur Ressource gewährt.

Beachten Sie, dass sich die Verhaltensweisen einer Windows-Arbeitsgruppe und einer Windows NT-Domäne an vielen Stellen überschneiden. So sind die Haupt- und die Sicherungssuchdienste in einer Domäne immer PDC bzw. BDC. Wir wollen unsere Darstellung der Windows-Domäne so anpassen, dass sie einen lokalen Hauptsuchdienst sowie einen lokalen Sicherungssuchdienst enthält. Das Ergebnis sehen Sie in Abbildung 1-13.

Abbildung 1-13

Eine Windows-Domäne mit einem lokalen Hauptsuchdienst und einem lokalen Sicherungssuchdienst

Die Ähnlichkeit zwischen Arbeitsgruppen und NT-Domänen ist nicht zufällig. Das Konzept der Windows-Domänen kam erst mit der Einführung von Windows NT 3.5 auf. Windows-Domänen sollten dann abwärts kompatibel zu den Arbeitsgruppen bleiben, die es in Windows for Workgroups gab.

Samba kann für Windows 95/98/Me- sowie für Windows NT/2000/XP-Clients als primärer Domänen-Controller (PDC) agieren, nicht jedoch als Backup-Domänen-Controller (BDC).

Außerdem kann Samba als Domänen-Member-Server arbeiten. Das bedeutet, dass es einen Computer-Account in der Account-Datenbank des PDC besitzt und daher als Bestandteil der Domäne erkannt wird. Ein Domänen-Member-Server dient nicht zur Authentifizierung von Benutzern, die sich an der Domäne anmelden, führt aber Sicherheitsfunktionen (etwa Dateizugriffsrechte) für Domänen-Benutzer aus, die auf seine Ressourcen zugreifen.

Active Directory-Domänen

Beginnend mit Windows 2000 hat Microsoft Active Directory eingeführt, das noch einen Schritt weiter geht als Windows NT-Domänen. Wir werden uns mit dem Thema Active Directory nicht näher befassen, da es doch sehr umfangreich ist. Samba 2.2 unterstützt Active Directory überhaupt nicht, und in Samba 3.0 beschränkt sich die Unterstützung darauf, dass es als Client agiert. Für den Moment sollten Sie sich lediglich merken, dass das Authentifizierungsmodell von Active Directory LDAP (Lightweight Directory Access Protocol) einsetzt und der Namensdienst über DNS und nicht über WINS zur Verfügung gestellt wird. Die Domänen in Active Directory können in einer hierarchischen Baumstruktur organisiert werden, in der jeder Domänen-Controller als Peer arbeitet und nicht zwischen primären und Sicherheits-Controllern unterschieden wird wie in Windows NT-Domänen.

Windows 2000/XP-Systeme können als einfache Arbeitsgruppen oder als Clients einer Windows NT-Domäne eingerichtet werden (die mit Samba arbeiten). Die Server-Editionen von Windows 2000 lassen sich so einrichten, dass sie Active Directory ausführen und aus Gründen der Abwärtskompatibilität Windows NT-Domänen unterstützen (Mixed Mode). In diesem Fall arbeitet Samba 2.2 mit Windows 2000-Servern auf die gleiche Weise wie mit Windows NT 4.0-Servern. Werden sie für den Native Mode eingerichtet, unterstützen Windows 2000-Server nur Active Directory. Selbst dann kann Samba 2.2 als Server in einer Domäne arbeiten, die von einem Windows 2000-Server im Native Mode verwaltet wird, indem der PDC-Emulationsmodus des Windows 2000-Servers eingesetzt wird. Samba 2.2 oder 3.0 dagegen können in einer Windows 2000 Active Directory-Domäne nicht als Domänen-Controller auftreten.

Falls Sie mehr über Active Directory erfahren wollen, raten wir Ihnen, sich das Buch Windows 2000 Active Directory von O'Reilly zu kaufen.

Kann eine Windows-Arbeitsgruppe mehrere Subnetze umfassen?

Ja, aber den meisten Menschen, die eine solche Konfiguration eingerichtet haben, hat dies einiges Kopfzerbrechen bereitet. Windows NT 3.5 oder Windows for Workgroups waren ursprünglich nicht für Umgebungen mit mehreren Subnetzen gedacht. Das Ergebnis ist, dass eine Windows-Domäne, die zwei oder mehr Subnetze umfasst, in Wirklichkeit aus zwei oder mehr notdürftig miteinander verbundenen Arbeitsgruppen besteht, die den gleichen Namen verwenden. Die gute Nachricht ist, dass Sie weiterhin einen primären Domänen-Controller verwenden können, um die Authentifizierung in allen Subnetzen zu gewährleisten. Die schlechte Nachricht ist, dass das Durchsuchen in diesem Fall eine komplizierte Angelegenheit ist.

Wie bereits erwähnt, muss jedes Subnetz seinen eigenen lokalen Hauptsuchdienst besitzen. Umfasst eine Windows-Domäne mehrere Subnetze, muss der Administrator in jedem Subnetz einen der Computer zum Domänen-Hauptsuchdienst (Domain Master Browser; DMB) ernennen. Der Domänen-Hauptsuchdienst verwaltet eine Suchliste der gesamten Windows-Domäne. Der Computer erstellt diese Suchliste, indem er die Suchlisten der lokalen Hauptsuchdienste regelmäßig mit der Suchliste des Domänen-Hauptsuchdienstes synchronisiert. Nach dem Synchronisieren sollten daher die Suchlisten der lokalen Suchdienste und des Domänen-Hauptsuchdienstes identisch sein. Abbildung 1-14 verdeutlicht dies.

Abbildung 1-14

Eine Arbeitsgruppe, die mehrere Subnetze umfasst

Hört sich doch gut an? Nun, aus folgenden Gründen ist es nicht ganz das Nirwana:

Die lokalen Hauptsuchdienste eines jeden Subnetzes verwalten weiterhin die Suchliste des Subnetzes, für das sie zuständig sind. Wenn also ein Computer eine Liste von Servern in seinem eigenen Subnetz sehen will, fragt er den lokalen Hauptsuchdienst dieses Subnetzes. Möchte ein Computer eine Liste mit Computern außerhalb seines Subnetzes erhalten, kann er ebenfalls nur so weit gehen wie der lokale Hauptsuchdienst. Das funktioniert, weil die autoritative Suchliste der lokalen Hauptsuchdienste mit der Liste des Domänen-Hauptsuchdienstes abgeglichen wird. Die Suchliste des Domänen-Hauptsuchdienstes wiederum wird aus den lokalen Hauptsuchdiensten aller Subnetze zusammengestellt. Dieser Vorgang heißt Suchlistenverteilung.

Samba kann als Domänen-Hauptsuchdienst in einer Windows NT-Domäne dienen. Es kann auch als lokaler Hauptsuchdienst für ein Subnetz arbeiten, um seine Suchliste mit der des Domänen-Hauptsuchdienstes zu synchronisieren.

Was ist neu in Samba 2.2?

Mit Version 2.2 bietet Samba eine bessere Unterstützung für Windows-Netzwerke, einschließlich der Fähigkeit, die wichtigeren Aufgaben auszuführen, die für das Arbeiten in einer Windows NT-Domäne notwendig sind. Darüber hinaus enthält Samba 2.2 einige Unterstützung für Techniken, die Microsoft in Windows 2000 eingeführt hat. Allerdings hat das Samba-Team die Unterstützung für Active Directory erst für Version 3.0 angekündigt.

PDC-Unterstützung für Windows 2000/XP-Clients

Samba konnte schon zuvor als PDC arbeiten, um Windows 95/98/Me- und Windows NT 4-Systeme zu authentifizieren. Diese Funktionalität wurde in Release 2.2 erweitert und umfasst nun auch Windows 2000 und Windows XP. Das heißt, nun ist es möglich, einen Samba-Server zu betreiben, der Domänen-Anmeldungen für ein Netzwerk aus Windows-Clients unterstützt, einschließlich der neuesten Releases von Microsoft. Als Ergebnis erhalten Sie ein sehr stabiles, leistungsfähiges Netzwerk mit größerer Sicherheit. Außerdem müssen Sie nicht für jeden Arbeitsplatz Windows-CALs von Microsoft erwerben.

Unterstützung für Microsoft Dfs

Microsoft Dfs (Distributed file system; verteiltes Dateisystem) erlaubt die Zusammenfassung von freigegebenen Ressourcen, die über mehrere Server im Netzwerk verteilt sind. Für die Benutzer sieht es dann so aus, als würden diese Ressourcen in einem einzigen Verzeichnisbaum auf dem Server existieren. Diese Art der Organisation erleichtert den Benutzern das Leben ganz erheblich. Anstatt das Netzwerk auf der Suche nach der gewünschten Ressource durchwühlen zu müssen, können sie sich direkt zum Dfs-Server begeben und dort auf die Ressource zugreifen. Samba 2.2 bietet Unterstützung für Dfs, für diesen Zweck wird also nicht länger ein Windows-Server benötigt.

Unterstützung für das Drucken unter Windows NT/2000/XP

Windows NT/2000/XP besitzt eine andere RPC-basierte (Remote Procedure Call) Druckerschnittstelle als Windows 95/98/Me. Bei Samba 2.2 wird die Windows NT/2000/ XP-Schnittstelle unterstützt. Dazu hat das Samba-Team die Möglichkeit vorgesehen, den Druckertreiber automatisch vom Samba-Server herunterzuladen, während auf einem Windows-Client ein neuer Drucker angelegt wird.

Zugriffskontrolllisten

Samba erlaubt nun auf seinem Unix-Host Zugriffskontrolllisten (Access Control Lists; ACLs) für Unix-Varianten, die diese unterstützen. Dazu gehören unter anderem Solaris 2.6, 7 und 8, Irix, AIX, Linux (entweder mit dem ACL-Patch für das ext2/ext3-Dateisystem von http://acl.bestbits.at oder beim Einsatz des XFS-Dateisystems) und FreeBSD (Version 5.0 und später). Werden ACLs unterstützt, übersetzt Samba zwischen Unix-ACLs und Windows NT/2000/XP-ACLs. Aus Sicht der Windows-Clients sieht der Samba-Host in diesem Fall mehr aus wie ein Windows NT/2000/XP-Server und verhält sich auch so.

Unterstützung für Werkzeuge zur Administration von Windows-Clients

Windows enthält Werkzeuge, die von einem Client aus benutzt werden können, um freigegebene Ressourcen auf einem Windows-Server von außen zu verwalten. Samba 2.2 erlaubt außerdem das Arbeiten mit diesen Werkzeugen auf Freigaben auf dem Samba-Server.

Die Integration mit Winbind

Winbind ist eine Einrichtung, die es Benutzern, deren Account-Informationen in einer Windows-Domänen-Datenbank gespeichert sind, erlaubt, sich an einem Unix-System zu authentifizieren. Das Ergebnis ist eine einheitliche Anmeldeumgebung, in der ein Benutzerzugang entweder auf dem Unix-System oder auf einem Windows NT/2000-Domänen-Controller vorgehalten werden kann. Dadurch wird die Account-Verwaltung auf großartige Weise unterstützt, da die Administratoren nun nicht mehr zwei Systeme synchronisiert halten müssen. Außerdem ist es für Benutzer, deren Accounts in einer Windows-Domäne liegen, möglich, sich zu authentifizieren, wenn sie auf Samba-Freigaben zugreifen.

Unix-CIFS-Erweiterungen

Die Unix-CIFS-Erweiterungen wurden bei Hewlett-Packard entwickelt und mit Samba 2.2.4 eingeführt. Sie erlauben es Samba-Servern, Unix-Dateisystemattribute, wie Links und Zugriffsrechte, zu unterstützen, wenn sie Dateien mit anderen Unix-Systemen gemeinsam nutzen. Samba kann dadurch als Alternative zu NFS (Network File Sharing) für das Filesharing zwischen Unix-Systemen genutzt werden. Als vorteilhaft beim Einsatz von Samba erweist es sich, dass Samba einzelne Benutzer authentifiziert, während NFS nur Clients authentifiziert (und zwar auf der Grundlage ihrer IP-Adresse, was ein ausgesprochen armseliges Sicherheitsmodell ist). Samba kann daher im Bereich Sicherheit Punkte sammeln und bietet darüber hinaus noch eine bessere Konfigurierbarkeit. In Kapitel 5 finden Sie nähere Informationen darüber, wie Sie Unix-Systeme als Samba-Clients betreiben.

Und mehr ...

Wie üblich hat der Code eine Reihe von Verbesserungen erfahren, die sich auf Administratorebene nicht sofort oder offensichtlich zeigen. Samba funktioniert nun besser auf Systemen, die PAMs (Pluggable Authentication Modules) verwenden, und es gibt eine bessere Unterstützung für Profile. Sambas Unterstützung für opportunistische Sperren (Oplocks) wurde verbessert; es wird nun eine bessere Integration mit Server-terminierten NFS-Leases (momentan nur auf Irix und Linux) und mit der Abbildung von SMB-Sperren auf POSIX-Sperren in das lokale Dateisystem geboten (dies hängt von der Implementierung der POSIX-Sperren in den einzelnen Unix-Varianten ab). Und natürlich wurden eine Menge Fehler beseitigt.

Was ist neu in Samba 3.0?

Das wichtigste Unterscheidungsmerkmal für Samba 3.0 besteht darin, dass es Unterstützung für die Kerberos 5-Authentifizierung und LDAP bietet, die beide notwendig sind, um als Clients in einer Active Directory-Domäne zu arbeiten. Ein weiteres neues Merkmal in Samba 3.0 ist die Unterstützung für Unicode, das den Einsatz unterschiedlicher Sprachen vereinfacht.

Für spätere Releases von Version 3 plant das Samba-Team die Entwicklung einer Unterstützung der WINS-Replikation, wodurch es Samba möglich wird, als sekundärer WINS-Server oder als primärer WINS-Server mit sekundären Windows- oder Samba-WINS-Servern zu arbeiten. Weiterhin ist die Unterstützung für den Betrieb als Windows NT-BDC und die Unterstützung für Windows NT-Domänen-Vertrauensbeziehungen geplant.

Was leistet Samba?

Wir wollen nun noch einmal zusammenfassen, was Samba leisten kann und an welchen Stellen ihm Beschränkungen auferlegt sind. In Tabelle 1-9 ist aufgeführt, welche Rollen Samba in einer Windows NT- oder Active Directory-Domäne oder in einer Windows-Arbeitsgruppe spielen kann und welche nicht. Viele der Windows-Domänen-Protokolle sind proprietär und wurden von Microsoft nicht dokumentiert; sie mussten daher vom Samba-Team rekonstruiert werden, bevor Samba sie unterstützen konnte. Bis Version 3.0 kann Samba in den meisten Rollen nicht als Sicherungssystem arbeiten und bietet keine vollständige Unterstützung für Active Directory.

Tabelle 1-9

Samba-Funktionen (bis Version 3.0)
Funktion (Rolle)	Beherrscht Samba sie?
Datei-Server	Ja
Druck-Server	Ja
Microsoft-Dfs-Server	Ja
Primärer Domänen-Controller	Ja
Backup-Domänen-Controller	Nein
Active Directory-Domänen-Controller	Nein
Windows 95/98/Me-Authentifizierung	Ja
Windows NT/2000/XP-Authentifizierung	Ja
Lokaler Hauptsuchdienst	Ja
Lokaler Sicherungssuchdienst	Ja
Domänen-Hauptsuchdienst	Ja
Primärer WINS-Server	Ja
Sekundärer WINS-Server	Nein

Ein Überblick über die Samba-Distribution

Wie bereits beschrieben, besteht Samba aus mehreren Programmen, die unterschiedliche, aber miteinander verknüpfte Aufgaben erfüllen. Diese Programme sind in Anhang C vollständig dokumentiert. An dieser Stelle wollen wir sie nur kurz vorstellen und beschreiben, wie sie zusammenarbeiten.

Die meisten Programme der Samba-Distribution beziehen sich auf seine zwei Daemons. Schauen wir uns zunächst die Funktionen der Daemons genauer an:

Der nmbd-Daemon ist ein einfacher Name-Server, der die Funktionalität eines WINS-Servers zur Verfügung stellt. Dieser Daemon wartet auf Name-Server-Anfragen und liefert bei einer Anfrage die entsprechenden IP-Adressen. Er stellt außerdem Suchlisten für die Netzwerkumgebung bereit und nimmt an Suchdienstwahlen teil.

Der smbd-Daemon verwaltet die freigegebenen Ressourcen zwischen dem Samba-Server und seinen Clients. Er stellt SMB-Clients in einem oder mehreren Netzwerken Datei-, Druck- und Suchdienste zur Verfügung und verarbeitet alle Nachrichten, die zwischen dem Samba-Server und den Clients ausgetauscht werden. Außerdem ist dieser Daemon für die Benutzerauthentifizierung, das Sperren von Ressourcen und für die Datenfreigabe über das SMB-Protokoll verantwortlich.

Dieser Daemon wird zusammen mit dem Name Service Switch verwendet, um an Informationen über Benutzer und Gruppen eines Windows NT-Servers zu gelangen. Außerdem erlaubt er es Samba, Benutzer durch einen Windows NT/2000-Server zu autorisieren.

Ein Programm, das das lokale Netzwerk nach Computern durchsucht, die auf das SMB-Protokoll antworten, und Informationen auf ihnen ausgibt.

Dieses Programm wird beim Arbeiten mit Sambas Internationalisierungsfunktionen verwendet. Es teilt Samba mit, wie in verschiedenen Zeichensätzen zwischen Groß- und Kleinschreibung umgeschaltet wird.

Ein weiteres Internationalisierungsprogramm, das zum Kompilieren von Unicode-Map-Dateien benutzt wird, die Samba einsetzt, um DOS-Codepages oder Unix-Zeichensätze in 16-Bit-Unicode zu übersetzen.

Mit diesem neuen Programm, das in Samba 3.0 enthalten ist, können Administrationsaufgaben auf entfernten Servern erledigt werden.

Ein Programm, das NBT-Namens-Lookups ermöglicht, um bei einem vorgegebenen Computernamen die IP-Adresse eines Rechners zu ermitteln.

Ein neues Programm, das mit Samba 3.0 ausgeliefert wird und bei der Verwaltung von Benutzer-Accounts in SAM-Datenbanken hilft.

Ein Befehl, mit dem Zuordnungen zwischen Windows NT-Gruppen und Unix-Gruppen definiert werden können. Dieser Befehl ist neu in Samba 3.0.

Ein Programm, das ein smbfs-Dateisystem mountet und es dadurch entfernten SMB-Freigaben erlaubt, in das Dateisystem des Samba-Hosts gemountet zu werden.

Ein Werkzeug, das ähnlich einer Kommando-Shell funktioniert, um den Zugriff auf ein entferntes SMB-Dateisystem zu erlauben und es Unix-Programmen zu ermöglichen, darauf zu arbeiten. Dieser Befehl wird in Kapitel 5 behandelt.

Ein Druck-Spooling-Programm, das verwendet wird, um Dateien an entfernte Drucker zu senden, die in einem SMB-Netzwerk freigegeben sind.

Jede wichtige neue Samba-Version wird vor ihrer Ankündigung ausführlich getestet. Wenn Probleme oder unerwünschte Nebenwirkungen auftreten, werden diese schnell beseitigt. Als wir diese Zeilen schrieben, war die neueste stabile Distribution Samba 2.2.6. Dieses Buch konzentriert sich auf die Funktionalität von Samba 2.2.6, weniger auf die älteren Versionen von Samba.

Woher bekomme ich Samba?

Quell- und Binärdistributionen von Samba gibt es auf Mirror-Sites im Internet. Die Haupt-Website für Samba ist unter http://www.samba.org / zu finden. Von dort können Sie eine Mirror-Site in Ihrer Nähe wählen.

Die meisten Linux- und viele Unix-Hersteller bieten Binärpakete. Diese sind möglicherweise bequemer zu installieren und zu warten als die Quell- oder Binärpakete des Samba-Teams, da die Hersteller üblicherweise versuchen, ein Paket zu liefern, das den Eigenschaften ihres speziellen Produkts entgegenkommt.

¹Sie können auch in der Netzwerkumgebung mit der rechten Maustaste auf die freigegebene Ressource klicken und den Menüpunkt Netzlaufwerk verbinden wählen.

²Seien Sie davor gewarnt, dass viele Lizenzvereinbarungen für Endbenutzer es nicht gestatten, ein Programm auf einem Netzlaufwerk zu installieren, so dass mehrere Clients darauf zugreifen können. Prüfen Sie den der jeweiligen Software beigelegten Lizenzvertrag, um ganz sicherzugehen.

⁵Beachten Sie, dass sich die Netzwerkumgebung in den neueren Windows-Versionen Windows Me/2000/XP an einigen Stellen etwas anders verhält als in den älteren Versionen Windows 95/98/NT.

Samba, 2. Auflage

Kapitel 1

Lerne den Samba

Was ist Samba?

Was leistet Samba?

Ein Verzeichnis freigeben

Einen Drucker freigeben

Die Dinge von der Unix-Seite aus sehen

Sich mit einem SMB-Netzwerk vertraut machen

NetBIOS verstehen

Einen Namen erhalten

Knotentypen

Woraus besteht ein Name?

Namen und Typen von Ressourcen

Gruppennamen und -typen

Bereichs-ID

Datagramme und Sitzungen

Eine Einführung in das SMB-Protokoll

Das SMB-Format

Das SMB-Header-Format

Das SMB-Befehlsformat

SMB-Variationen

SMB-Clients und -Server

Eine einfache SMB-Verbindung

Eine NetBIOS-Sitzung beginnen

Die Protokollvariante aushandeln

Setzen der Sitzungs- und Anmeldeparameter

Windows-Arbeitsgruppen und -Domänen

Windows-Arbeitsgruppen

Durchsuchen

Suchdienstwahlen

Windows 95/98/Me-Authentifizierung

Windows NT-Domänen

Domänen-Controller

Primärer Domänen-Controller und Backup-Domänen-Controller

Authentifizierung

Namendienst mit WINS und DNS

Vertrauensbeziehungen

Active Directory-Domänen

Kann eine Windows-Arbeitsgruppe mehrere Subnetze umfassen?

Was ist neu in Samba 2.2?

PDC-Unterstützung für Windows 2000/XP-Clients

Unterstützung für Microsoft Dfs

Unterstützung für das Drucken unter Windows NT/2000/XP

Zugriffskontrolllisten

Unterstützung für Werkzeuge zur Administration von Windows-Clients

Die Integration mit Winbind

Unix-CIFS-Erweiterungen

Und mehr ...

Was ist neu in Samba 3.0?

Was leistet Samba?

Ein Überblick über die Samba-Distribution

Woher bekomme ich Samba?