Bevor ich damit beginne, die Konfiguration des Innenlebens von Samba detailliert darzustellen, gebe ich Ihnen in diesem Kapitel einen Überblick über die Konzepte, die Grundlage dieser Details sind. Die folgenden Abschnitte erklären die grundlegenden Gedanken hinter dem Vernetzungsmodell für die Microsoft-Betriebssysteme, von Windows für Workgroups bis Windows NT. Dieses Kapitel ist sozusagen ein Blick aus 3.000 Meter Höhe auf die von Microsoft- (und anderen) Clients verwendeten Netzwerkprotokolle, aber Sie erhalten hier die nötigen Grundkenntnisse, um Ihre Samba-Server in späteren Kapiteln besser verstehen und konfigurieren zu können.
Wenn Sie bereits seit einiger Zeit mit Intel-basierten Rechnern arbeiten, sind Sie sicher mit dem Start-BIOS-Bildschirm vertraut, der beim Neustart des Rechners erscheint. BIOS steht für Basic Input/Output System. Mitte der achtziger Jahre wurden die Konzepte des Computer-BIOS auf die noch neuen Netzwerkkonzepte ausgeweitet. Das Resultat war das Application Programming Interface (API) eines Programmierers, das NetBIOS genannt wurde, was für Network Basic Input/Output System steht. Die allgemein akzeptierte Definition des NetBIOS-API zu jener Zeit war das IBM PC Network Technical Reference Manual, das im September 1994 von IBM veröffentlicht wurde.
Kurz danach, 1985, entwickelte IBM ein Netzwerkprotokoll, um das NetBIOS-API einzukapseln und zu erweitern. Das resultierende Protokoll wurde NetBEUI genannt, was für NetBIOS Extended User Interface steht. NetBEUI ist optimiert für kleine LANs, kann aber nicht geroutet werden.
Zusätzlich zu NetBEUI kann NetBIOS über IPX laufen. Dies würde die Koexistenz von Novell-Netzwerken und Microsoft-Netzwerken ermöglichen.
1987 standardisierte die Internet Engineering Task Force (IETF) in den Requests for Comments (RFCs) 1001 und 1002 das Interface über TCP und UDP. NetBIOS über TCP/IP wird gewöhnlich NBT genannt.
Die RFCs 1001 und 1002 definieren drei Dienste, die von NetBIOS über TCP/IP zur Verfügung gestellt werden sollten:
Ein Name Service bildet die Brücke zwischen der Art und Weise, wie Computer andere Rechner sehen und lokalisieren und wie Menschen sie sehen und lokalisieren. Menschen können sich in der Regel Namen besser merken als Zahlen, aber Zahlen belegen weniger Speicherplatz im Arbeitsspeicher eines Computers. Also wird ein Mechanismus benötigt, der einen Namen in eine Zahl auflöst. Vom Prinzip her gleicht dies dem Heraussuchen einer Telefonnummer aus einem Telefonbuch.
Genau das tut der Name Service. Wenn Sie mit TCP/IP-Netzwerken vertraut sind, werden Sie wissen, dass jeder IP-Host einen Hostnamen hat, z.B. bilbo, und eine entsprechende IP-Adresse, z.B. 192.168.1.73. Wenn Sie an einem anderen Rechner telnet bilbo eingeben, muss der lokale Rechner, an dem Sie sich befinden, die entsprechende IP-Adresse zum Hostnamen bilbo finden, bevor er Pakete an den entfernten Rechner senden kann. Die Standardmethode für die Auflösung eines Internet-Hostnamens in eine IP-Adresse besteht entweder darin, eine lokale /etc/hosts-Datei oder einen Domain Name Server zu befragen. In beiden Fällen wird letztlich in einer Art »Telefonbuch« nachgeschaut, welche IP-Adresse zu dem Namen gehört.
Der NetBIOS-Name-Service, der in den RFCs 1001 und 1002 definiert ist, bietet dem Client die gleiche Art von Dienst wie DNS. Sie können den Hauptunterschied zwischen den beiden besser verstehen, wenn ich Ihnen erkläre, was ein NetBIOS-Name ist.
NetBIOS-Namen
NetBIOS-Namen existieren in einem flachen Namensbereich und bestehen aus 16 alphanumerischen Zeichen (z.B. a bis z, A bis Z und 0 bis 9) zusätzlich zu den folgenden:
Nur 15 der Zeichen werden für die Benennung des Client-Rechners verwendet. Das sechzehnte Byte ist eine Zahl von 0x00 bis 0xFF, die den Ressourcentyp des Namens kennzeichnet. Die Namen können entweder exklusiv einem Benutzer oder Rechner gehören oder, bei Gruppennamen, gemeinsam benutzt werden. Der NetBIOS-Name MYMACHINE<00> z.B. ist ein eindeutiger Name, der den Rechner MYMACHINE kennzeichnet. Der Name MYDOMAIN<1e> ist ein Gruppenname, der von Browsing-Clients benutzt wird, um einen Master-Browser zu wählen. Wenn Sie etwas Hintergrundwissen über TCP/IP haben, ist es vielleicht hilfreich, sich vorzustellen, dass die NetBIOS-Ressourcentypen den TCP- und UDP-Portnummern entsprechen. In den Tabellen 2.1 und 2.2 sind alle aktuellen NetBIOS-Ressourcenbezeichnungen mit einer kurzen Erklärung aufgelistet.
Tabelle 2.1: Eindeutige NetBIOS-Ressourcentypen
Ressourcenbyte |
Beschreibung |
<00> |
NetBIOS-Name, mit dem der Freigabename der Workstation bezeichnet wird |
<03> |
Messenger-Service-Name, der für das Übertragen und Empfangen von Nachrichten benutzt wird |
<06> |
RAS-Servername |
<1b> |
Domain-Masterbrowser-Name, der von einem Rechner benutzt wird, um den Primary Domain Controller einer Domain zu kontaktieren |
<1f> |
NetDDE-Dienst |
<20> |
Server-Dienstname, um Zugriffspunkte für freigegebene Dateien zu bieten |
<21> |
RAS-Client |
<be> |
Network Monitor Agent |
<bf> |
Network Monitor Utility |
Tabelle 2.2: NetBIOS Gruppen-Ressourcentypen
Ressourcenbyte |
Beschreibung |
<1c> |
Ein Domain-Gruppenname, der vom Domain Controller registriert wird und eine Liste von Computern enthält, die diesen Namen registriert haben |
<1d> |
Masterbrowser-Name, der vom Client benutzt wird, um auf den Masterbrowser zuzugreifen (möglicherweise ein lokaler Masterbrowser) |
<1e> |
Normaler Gruppenname, der bei der Wahl von Browse-Mastern benutzt wird |
<20> |
Internet-Gruppe, die benutzt wird, um eine Gruppe von Rechnern für administrative Zwecke zu identifizieren |
_MSBROWSE_ |
Wird an den Domainnamen angehängt und per Broadcast übertragen, um anderen Masterbrowsern die Domain bekannt zu geben |
Den praktischen Einsatz dieser Ressourcenbezeichnungen können Sie in der Ausgabe des Befehls nbtstat.exe sehen, die Sie in Listing 2.1 finden. Die Ausgabe wurde von einem Windows-95-OSR2-Rechner erstellt, und der untersuchte Rechner war eine Windows-NT-4.0-Workstation.
Listing 2.1: Ausgabe des Befehls nbtstat.exe
C:\users\jerry>nbtstat -a picanteDie Angaben in der Spalte Type und das Ressourcenbyte helfen Ihnen zu bestimmen, was der Name darstellt. So können Sie z.B. erkennen, dass der entfernte Rechner den Namen PICANTE hat, weil es ein eindeutiger Name mit der Bezeichnung <00> ist. Wenn Sie noch einmal einen Blick in Tabelle 2.1 werfen, sehen Sie diese Schlussfolgerung bestätigt.
Ich habe vorher erwähnt, dass NetBIOS-Namen in einem flachen Namensbereich existieren. Trotzdem ist es möglich, im gleichen logischen Subnetz einen Namensbereich von einem anderen zu unterscheiden, indem man benutzt, was als NetBIOS-Scope (NetBIOS-Bereich) bezeichnet wird. Der NetBIOS-Bereich ist ein Zeichenstring, der zusammen mit dem NetBIOS-Namen nicht länger als 256 Zeichen sein kann.
Der NetBIOS-Scope bietet keine hierarchische Organisation für den NetBIOS-Namensbereich. Er isoliert einfach nur die Namen in einem Bereich von Rechnern in einem anderen. Sie sollten diesen Bereich in der Regel einfach leer lassen, wenn Sie nicht einen besonderen Grund dafür haben, einen NetBIOS-Bereich einzurichten. Abbildung 2.1 zeigt die Einrichtung eines NetBIOS-Bereichs für die Segmentierung von Rechnern in einem Netzwerk. Die Rechner PICANTE und QUESO gehören beide der gleichen Arbeitsgruppe an, haben aber unterschiedliche Bereichs-IDs, die in der Abbildung an die Rechnernamen angehängt sind. PICANTE hat eine Bereichs-ID von »« und QUESO eine von »dept003«. Keiner von beiden kann mit dem anderen kommunizieren, solange beide eine unterschiedliche Bereichs-ID haben.
Abb. 2.1: Über die NetBIOS-Bereichs-ID NetBIOS-Clients segmentieren
Sie können unter Windows 95 die Bereichs-ID einrichten, indem Sie in der Systemsteuerung das Netzwerkkontrollfeld öffnen und sich unter den TCP/IP-Eigenschaften für Ihre Netzwerkadapterkarte die Registerkarte WINS-Konfiguration ansehen. Abbildung 2.2 zeigt das Feld Bereichs-ID mit einer Einstellung von »dept003«.
Abb. 2.2: Einstellung der Bereichs-ID im Netzwerkkontrollfeld von Windows 95
Registrierung und Auflösung
Der NetBIOS-Name-Service bietet eine Methode für die Registrierung der Namen von Client-Rechnern und deren Auflösung. Einen Namen registrieren heißt, dass der Client-Rechner ein erfolgreiches Namensangebot gemacht und den Namen für sich erhalten hat, so dass alle zukünftigen Anfragen an diesen Namen an den Client gehen werden. Während des Bootvorgangs versucht der Client, den Namen zu registrieren, indem er eine Anfrage an den Name Service sendet, welcher entweder kollaborativ oder singulär sein kann. Dieser Unterschied spielt jetzt keine Rolle.
Ist der gewünschte Name bereits an einen anderen Client vergeben, antwortet dieser, dass er den Namen bereits besitzt und ihn behalten möchte. Wenn Client Nr. 1 auf eine Anfrage von Client Nr. 2 antwortet, in der dieser den Namen von Client Nr. 1 verlangt, redet man auch davon, dass der erste Client seinen Namen verteidigt, d.h. dass er seinen Namen behalten möchte. NetBIOS-Clients werden ihre Namen immer behalten wollen, solange sie funktionieren. Die Verteidigung von registrierten Namen ist ein wichtiger Aspekt, da sie eine Methode bietet, Hosts zu entdecken, die inaktiv sind, aber den Besitz des Namens nicht offiziell aufgegeben haben.
Es ist außerdem hilfreich, sich klarzumachen, dass NetBIOS-Namen in eine bestimmte IP-Adresse aufgelöst werden, wenn ein NetBIOS-Interface über TCP/IP läuft. Stellen Sie sich vor, dass ein Client, der über DHCP erfolgreich eine IP-Adresse erhalten hat, einen Namen angibt, dann ohne Vorwarnung abstürzt und den Namen nicht offiziell freigeben kann. Wenn der Rechner neu gestartet wird, versucht er, den Namen wiederzubekommen, obwohl er potentiell eine andere IP-Adresse haben kann. Zwar können IP-Adressen dynamisch zugewiesen werden, aber NetBIOS-Namen sind hartcodiert. Wenn in einem Windows-Client der Client für Microsoft-Netzwerke installiert ist, können Sie den Namen finden, indem Sie in den Netzwerkeigenschaften (über Systemsteuerung und Netzwerk) die Registerkarte Identifikation ansehen (siehe Abbildung 2.3).
Abb. 2.3: Die Einstellungen für den Computernamen und die Arbeitsgruppe des NetBIOS-Rechners in den Netzwerkeigenschaften unter Windows 95
Dies mag etwas verwirrend erscheinen, wenn Sie aus der Standard-TCP/IP-Welt kommen, in der ein Host-Name im DNS oder einer Host-Datei registriert ist und der Zusammenprall von Namen durch gute Administration vermieden wird. Ich gebe zu, dass es etwas seltsam ist, wenn ein Rechner Namen dynamisch registriert, indem er verlangt, dass sie auf dem lokalen Host statisch aufgezeichnet werden.
Nach der Registrierung von NetBIOS-Namen müssen jetzt andere Clients in der Lage sein, den Namen in eine Netzwerkadresse aufzulösen. In diesem Fall ist das eine IP-Adresse.
Es gibt zwei Methoden für die Registrierung und Auflösung von Namen: Broadcast und Point-to-Point. Broadcast-Registrierung oder -Auflösung heißt, dass die Anfrage an alle Hosts im gleichen logischen Subnetz mit der gleichen Bereichs-ID übertragen wird. Router können für die Übertragung von Broadcasts konfiguriert werden, aber dies ist in der Regel keine gute Idee, da dann zu viel Datenverkehr erzeugt wird.
Point-to-Point-Registrierung und -Auflösung wird über einen NetBIOS-Nameserver (NBNS) durchgeführt. Der NBNS wird ebenfalls in den RFCs 1001 und 1002 definiert. Die NetBIOS-RFCs erlauben dem NBNS, in Hinsicht auf die Verwaltung und Authentifizierung von Namen unterschiedliche Grade von Verantwortung zu akzeptieren. Microsofts Implementierung des NBNS, der Windows Internet Name Service (WINS), agiert als Agent und ermöglicht Clients sowohl die Registrierung von Namen als auch deren Auflösung in eine IP-Adresse. Samba kann auch als WINS-Server arbeiten (siehe Kapitel 18, »NetBIOS-Namen ohne Broadcasts auflösen«).
Die Broadcast-Point-to-Point-Registrierung und -Auflösung erstellt die folgende Taxonomie:
In der Praxis sind die meisten NetBIOS-Clients entweder b-Knoten, d.h., sie benutzen keinen WINS-Server, oder h-Knoten, was heißt, dass sie einen WINS-Server benutzen. Sie können sich den aktuellen Knotentyp ansehen, indem Sie das Windows-IP-Konfigurations-Utility (winipcfg.exe) starten und auf die Schaltfläche Weitere Info klicken. Abbildung 2.4. zeigt die weiteren Informationen, die dann angezeigt werden.
Abb. 2.4: Den NetBIOS-Knotentyp in der Windows IP-Konfiguration ansehen
Der NetBIOS-Session-Service bietet eine Methode zur Unterstützung zuverlässiger Verbindungen und zum Austausch von Nachrichten zwischen zwei Clients. Für jede einzelne Verbindung hat der Sender einen Anrufernamen (calling name) und der Empfänger einen angerufenen Namen (called name). Ich erwähne diese Begriffe hier nur, weil sie manchmal in Fehlermeldungen der Windows-Clients sowie in einigen der in Samba enthaltenen Utilities auftauchen.
Vielleicht hilft es Ihnen, sich die Beziehung zwischen dem Nameserver und dem Session-Service als eine Telefonverbindung vorzustellen. Bevor Sie einen Anruf von Ihrem Freund Peter erhalten können, brauchen Sie eine Telefonnummer, die Ihnen von Ihrem Telekommunikationsanbieter zugewiesen wird (natürlich brauchen Sie zuerst auch noch ein Telefon). Dies entspricht der Registrierung Ihres NetBIOS-Namens. Wenn sowohl Peter als auch Sie registrierte Telefonnummern haben, kann Peter Sie anrufen.
Seine Seite der Verbindung ist der NetBIOS-Anrufername, und Ihre Seite der Verbindung ist der angerufene Name. Die Telefonkabel, die Sie verbinden, stellen den Session-Service dar, der die Daten (Ihre Konversation) überträgt. Jeder Anruf ist eine eigenständige Sitzung nur zwischen Ihnen und Peter (es sei denn, Ihr Telefon wird abgehört). Wenn Sie umziehen, ohne Peter davon zu unterrichten, und er versucht, Sie anzurufen, wird er eine fremde Person am anderen Ende haben, die den Anruf nicht entgegennimmt. Daher die NetBIOS-Meldung »Not listening on called name«. Sie erhalten diese Meldung, wenn Sie versuchen, eine Sitzung mit einem anderen Host einzugehen, aber den falschen Namen benutzen.
Dieser Dienst bietet NetBIOS-Anwendungen eine weitere Funktion: die Erkennung abgebrochener Sitzungen mit anderen NetBIOS-Clients. Ich erwähne dies mehr der Vollständigkeit halber, weniger als technische Einzelheit. Wenn Sie weitere Informationen über den NetBIOS-Session-Service wünschen, holen Sie sich eine Kopie der RFCs 1001 und 1002.
Der Datagram-Service ist sozusagen die Umkehrung des Session-Service. Er bietet einen verbindungslos-orientierten Dienst für die Übertragung von Paketen an einen bestimmten Host oder eine bestimmte Gruppe von Hosts innerhalb einer Arbeitsgruppe (Unicast/Multicast) oder die Übertragung an alle Hosts in einem logischen Subnetz oder einem NetBIOS-Bereich (Broadcast). Der Datagram-Service ermöglicht z.B. Dinge wie das Auffinden des aktuellen Browse-Masters für eine Arbeitsgruppe oder Domäne durch Übertragen der Anfrage per Multicast an den Arbeitsgruppennamen.
Vielleicht haben Sie den Begriff »Mailslots« anstelle des Begriffs »Datagramme« gehört. Mailslots ist der Microsoft-Name für NetBIOS-Datagramme.
Lassen Sie uns noch einmal zu dem Beispiel mit Ihrem Freund Peter zurückkehren. Nehmen wir an, Sie haben kein Telefon mehr. Wie könnte Peter Sie kontaktieren, vorausgesetzt, Sie wohnen nicht in seiner Nähe? Wahrscheinlich würde Peter Ihnen einen Brief schicken. Nehmen wir jetzt an, Sie haben Peter einen Brief geschickt, bevor Sie seinen erhalten haben. In diesem Beispiel ist Ihre Adresse der NetBIOS-Name und die Briefe sind Pakete. Peter sendet Ihnen jetzt einen weiteren Brief als Antwort auf Ihren Brief, aber Sie haben seinen ersten Brief nie erhalten. Diese Art von unzuverlässiger Auslieferung - ich kritisiere hier nicht die Post, es ist nur ein Beispiel - ist billiger als ein Anruf über große Entfernungen und weniger Bandbreiten-intensiv für das Telefonnetzwerk (d.h., es ist gar nicht bandbreiten-intensiv).
Um das Beispiel mit dem Postdienst fortzusetzen, nehmen wir an, Sie wollen Weihnachtskarten an all Ihre Freunde senden. Sie schicken 25 Karten los und alle kommen sicher an, aber Sie haben keinerlei Garantie, in welcher Reihenfolge Ihre Freunde die Karten erhalten. Haben Sie schon einmal eines dieser Gewinnspiele gesehen, in denen es heißt: »Der erste Anrufer gewinnt den Hauptpreis!« Das ist in etwa das Gleiche. Wenn das Unternehmen diese Aufforderung versendet, kann es nicht kontrollieren, wer sie zuerst bekommt, auch wenn die Briefe zu unterschiedlichen Zeiten versendet werden. Jetzt haben Sie eine Vorstellung des Datagram-Service.
CIFS steht für Common Internet File System und wird oft austauschbar mit der Abkürzung SMB verwendet. Tatsächlich ist CIFS einfach die nächste Generation des SMB-Protokolls. Wie auch immer Sie es nennen, lassen Sie sich nicht verwirren.
SMB wurde 1987 erstmals durch ein gemeinsames Dokument von Microsoft und Intel namens »Microsoft Network/OpenNET-File sharing Protocol« definiert. Seitdem wurde das Protokoll vielen Änderungen unterzogen, und Paul Leach und Dilip Naik dokumentieren seine letzte Version im CIFS-1.0-Spezifizierungsentwurf. Da es sich um einen Entwurf handelt, ist die tatsächliche Dokumentation in der Praxis einfach »wie NT es macht«.
Das Server-Message-Block-Protokoll läuft über NetBIOS (siehe Abbildung 2.5). Wie in den vorherigen Abschnitten dargestellt, kann NetBIOS über NetBEUI, IPX/SPX und TCP/IP laufen. Samba implementiert nur SMB über TCP/IP.
Abb. 2.5: SMB über NetBIOS und mögliche Transportschichtprotokolle
SMB ist ein verbindungsorientiertes Protokoll, d.h. dass alle SMB-Pakete innerhalb einer virtuellen Verbindung (VC-Virtual Circuit) zwischen dem Client und dem Server in der Reihenfolge übertragen werden, in der sie versendet wurden. Wird die virtuelle Verbindung abgebrochen, werden alle Informationen, die sich in dieser Verbindung befinden, ungültig. Betrachten Sie die folgenden vier Dinge, die eine SMB-Verbindungsumgebung ausmachen: eine virtuelle Verbindung zwischen dem Client und dem Server, eine Sitzungs-UID, eine ID für den Ressourcen-Verzeichnisbaum (Tree ID - TID) und ein Dateiidentifikator (File Identifier - FID) (siehe Abbildung 2.6). Die UID wird in Schritt 2 des SMB-Protokollüberblicks näher beschrieben. Die TID stellt die freigegebene Ressource dar und die FID die individuellen Dateizugriffe.
Abb. 2.6: SMB-Verbindungsumgebung
Wird ein Teil der Verbindungsumgebung ungültig, wird alles, was sich in diesem Teil der Umgebung befindet, ebenfalls ungültig. Das SMB-Protokoll verwaltet keine Informationen über frühere Verbindungen, d.h., wird eine Verbindung beendet, muss alles wieder von Null neu aufgebaut werden. Eine Sitzungs-UID, die ein Client aus einer früheren Verbindung erhalten hat, gilt nicht für eine neue Verbindung. Alle TIDs und FIDs müssen ebenfalls erneut geöffnet werden. Alle Zugriffe auf Dateien, die sich in der Netzwerkressource befinden, werden nutzlos, wenn die Verbindung beendet wird.
Darum stürzen PC-Anwendungen, die auf einer Netzwerkfreigabe laufen, ab, wenn die Verbindung beendet wird, während die Anwendung läuft. Die Anwendung versucht, die Datei-Handles zu benutzen, die vorher ausgegeben wurden. Die meisten Clients versuchen still und leise, die beendete Sitzung wiederherzustellen, damit die Freigabeverbindung verfügbar ist, aber alle von den Anwendungen verwendeten Datei-Handles sind inzwischen ungültig.
Abbildung 2.6 beschreibt die Umgebung für eine fiktive Verbindung. Nehmen wir jetzt an, dass die UID (0x0198) aus irgendeinem Grund beendet wird. Beide TIDs, x0x7c und 0xa8, werden ungültig, da sie Teil der UID-Umgebung sind. Nehmen wir nun an, die gesamte virtuelle Verbindung wird beendet. In diesem Fall werden alle UIDs, TIDs und FIDs ungültig, da sie alle innerhalb der virtuellen Verbindung bestehen.
Wenn sich ein Benutzer mit einer Freigabe auf einem SMB-Server verbindet, z.B. über das Dialogfeld Netzlaufwerk verbinden im Windows-Explorer oder durch Browsing in der Netzwerkumgebung, werden drei Startphasen durchlaufen, bevor er auf die Inhalte der Freigabe zugreifen kann. Die beschriebenen Schritte beziehen sich auf Dateifreigaben, aber die gleichen Anfragen und Reaktionen gelten auch für die Verbindung zu entfernten Druckern.
Abbildung 2.7 zeigt die notwendigen Schritte für den Aufbau einer SMB-Verbindung zwischen einem Client und einem Server. Die chronologische Reihenfolge des Diagramms ist von oben nach unten und von links nach rechts.
Abb. 2.7: Eine SMB-Verbindung zu einer freigegebenen Ressource aufbauen
Sind diese Schritte ausgeführt, kann der Benutzer Operationen in der Freigabe ausführen, z.B. ein Dokument drucken oder eine Datei, die sich in der Freigabe befindet, zum Bearbeiten öffnen.
Bevor es PCs gab, bestand das Netzwerkmodell aus einem zentralen Server und Terminals, auf die Benutzer zugreifen konnten. Diese Terminals hatten selbst keine Rechenleistung. Sie boten dem Benutzer nur eine interaktive Ansicht des Servers.
Mit der Invasion der PCs in den späten achtziger Jahren begannen Benutzer, ihre Dateien auf der lokalen Festplatte in ihren PCs zu speichern. Dies stellte jedoch ein Problem für die gemeinsame Nutzung von Dateien dar: etwas, das unproblematisch war, solange sich jeder von seinem Terminal in den gleichen Rechner (d.h. Mainframe) einloggte. Die Leute wollten ihre Dateien lokal speichern, damit sie auch während eines Server-Ausfalls (etwas, das sie nicht kontrollieren konnten) auf ihre Dateien zugreifen konnten, aber trotzdem anderen Benutzern den Zugriff auf die Dateien von ihren eigenen Rechnern ermöglichen. Dieses PC-zentrierte verteilte Modell wurde Peer-to-Peer-Netzwerk genannt, da alle Rechner gleichzeitig Client und Server sein konnten.
Die Idee einer Arbeitsgruppe geht Hand in Hand mit dem Konzept des Peer-to-Peer-Netzwerks. Eine Arbeitsgruppe ist eine Gruppe von Leuten, die sich die Verantwortung teilen, ein gemeinsames Ziel zu erreichen. Jeder muss seinen Teil übernehmen. Eine Computer-Arbeitsgruppe ist nichts anderes. Wie Sie sehen werden, kann das Konzept einer Computer-Arbeitsgruppe in zwei Zusammenhängen benutzt werden.
Das erste Konzept einer Arbeitsgruppe ist eine administrative Gruppe von Rechnern, die Benutzer- und Gruppen-Account-Informationen nicht teilen. Erinnern Sie sich noch an Schritt 2 des SMB-Protokollüberblicks? Hier sendet der Client einen Benutzernamen und einen Beweis seiner Identität. Die Frage ist dann: »Wer authentifiziert diese Anfrage?« Jeder Rechner hat eine separate und lokale Kopie einer Account-Datenbank. Daher findet jegliche Authentifizierung lokal statt. Denken Sie daran, dass dieses Modell Peer-to-Peer-Netzwerk genannt wird, weil alle Rechner prinzipiell gleichwertig sind. Jeder PC hat die Möglichkeit, Datei- und Druckerfreigaben zur Verfügung zu stellen und Zugriffsanfragen zu authentifizieren. Diese Gleichwertigkeit heißt natürlich nicht, dass alle Rechner diese Aufgaben gleich gut durchführen. Bedenken Sie außerdem, dass der Konfigurationsaufwand bei dieser Variante gegebenenfalls sehr hoch sein kann.
Abbildung 2.8 verdeutlicht die Idee des Arbeitsgruppen-Authentifizierungsmodells. Der Client, der unten dargestellt ist, versucht, auf die Festplattenfreigabe auf SERVER1 zuzugreifen. SERVER1 ist alleine verantwortlich für die Authentifizierung der Sitzungsanfrage mit Hilfe seiner lokalen Account-Datenbank, was immer dies auch sein mag. Wenn der Client versucht, auf die Druckerfreigabe auf SERVER2 zuzugreifen, ist dieser Server dafür verantwortlich, die Verbindung zu authentifizieren. Das Ergebnis ist völlig unabhängig von dem Ergebnis der Verbindung zu SERVER1. Jeder Server hat eine lokale und unabhängige Account-Datenbank, die mit der des anderen Rechners nichts zu tun hat.
Abb. 2.8: Beispiel für ein Arbeitsgruppen-Netzwerkmodell
Das Konzept einer Computer-Arbeitsgruppe kommt auch beim Browsing zur Anwendung, das in den Kapiteln 19 und 20 näher dargestellt wird. Die Motivation für das Netzwerk-Browsing liegt in der Art und Weise, in der Ressourcen im Netzwerk erscheinen und aus dem Netzwerk verschwinden, während Hosts gestartet und beendet werden. Im Gegensatz zu einem zentralen Netzwerkmodell, wie z.B. die Lösung mit Mainframe und Terminals, ist es viel schwieriger, eine große Anzahl von Hosts zu überblicken, die je nach Willen des PC-Besitzers im Netzwerk an- und abgemeldet werden. Browsing ermöglicht es Benutzern, die aktuell verfügbaren Server und Ressourcen dynamisch anzusehen. In diesem Zusammenhang sind eine Domäne und eine Arbeitsgruppe äquivalent.
Eine Domäne ist einer Arbeitsgruppe ähnlich, mit einer großen Ausnahme. In einer Domäne gibt es einen zentralen Authentifizierungsserver, der die Benutzer- und Gruppen-Accounts der Domäne verwaltet. Der Zugriff auf die Ressourcen in der Domäne wird durch den Domänen-Controller authentifiziert, egal auf welchem Rechner sich die Ressourcen befinden. Es handelt sich hierbei immer noch um ein Peer-to-Peer-Netzwerk, da alle Rechner die Möglichkeit haben, Datei- und Druckerfreigaben zur Verfügung zu stellen und die notwendige Authentifizierung durchzuführen. Der Unterschied besteht darin, dass die Authentifizierung mit Hilfe einer entfernten Account-Datenbank durchgeführt wird, die sich auf dem Domänen-Controller befindet.
Domänen vermeiden die Masse von Passwörtern, die notwendig ist, wenn jeder Rechner seine eigene lokale Account-Datenbank hat. Die Lösung versorgte Benutzer mit einem Account, der auf Wunsch Zugriff zu allen Ressourcen ermöglichen konnte.
Abb. 2.9: Beispiel für eine Domäne
Abbildung 2.9 zeigt eine Beispielverbindung zu einem Server, der einer Domäne angehört. Zunächst sendet der Client die Verbindungsanfrage mit den Benutzerinformationen an SERVER1 und verlangt Zugriff auf eine Festplattenfreigabe. SERVER1 sendet dann eine Authentifizierungsanfrage an den Domänen-Controller (DC). Diese enthält die Benutzerinformationen, die ursprünglich vom Client übertragen wurden. Wenn der DC den Client erfolgreich authentifiziert, sendet er eine positive Antwort an SERVER1, der wiederum eine positive Verbindungsantwort an den Client zurückgibt. Das heißt, dass sich ein Client mit einem einzigen Benutzernamen und Passwort mit jedem Server in der Domäne verbinden kann, vorausgesetzt dass die Zugriffskontrollmechanismen wie z.B. Berechtigungslisten es erlauben. In Abbildung 2.8 brauchte der Client für jede Verbindung zu einem Server einen separaten Benutzernamen und ein Passwort.
Die Protokolle NetBIOS und SMB umfassen noch viele Implementierungsdetails, die hier nicht dargestellt wurden. Die wichtigsten Punkte aus diesem Kapitel sind:
Der NBT-Name-Service benutzt Port 137/udp, der NBT-Session-Service Port 139/tcp und der NBT-Datagram-Service Port 138/udp.
Die ASCII-Versionen der RFCs 1001 und 1002 finden Sie auf der CD-ROM, die diesem Buch beiliegt. Natürlich können Sie sie auch jederzeit von der IETF-Website (http://www.ietf.org) herunterladen.
Microsoft hat aus offensichtlichen Gründen das SMB- (bzw. CIFS-)Protokoll vorangetrieben. Das Unternehmen verwaltet eine Sammlung von Links und Informationen unter http://www.microsoft.com/workshop/networking/cifs.
Broadcast-Namensregistrierung und -auflösung - Hosts übertragen Pakete an die Broadcast-Adresse des Netzwerks (z.B. aaa.bbb.ccc.255 für ein Standard-Klasse-C-Netzwerk), um Namen zu registrieren und aufzulösen.
Angerufener Name (Called Name) - Der NetBIOS-Name des Servers, der in einer Verbindungsanfrage kontaktiert wird.
Anrufername (Calling Name) - Der NetBIOS-Name des Clients in einer NetBIOS-Verbindungsanfrage.
Domäne - Eine Sammlung von Rechnern, bei der die endgültige Authentifizierung von Verbindungsanfragen für jegliche Freigabe auf einem beliebigen Rechner von einem Domänen-Controller durchgeführt wird.
Domänen-Controller - Ein Rechner, der für die Authentifizierung von Dienstanfragen durch die Server in der Domäne verantwortlich ist.
NetBEUI - Erweiterte NetBIOS-Benutzerschnittstelle. NetBEUI ist ein von IBM entwickeltes Netzwerkprotokoll, das die Funktionalität des NetBIOS-API einbettet und erweitert.
NetBIOS - Network Basic Input/Output System. Ein API, das für die Programmierung von Netzwerkapplikationen entwickelt wurde.
NetBIOS-Scope - Ein String für die Segmentierung des NetBIOS-Namensbereichs. Hosts in einem NetBIOS-Bereich können Hosts in einem anderen nicht sehen.
Point-to-Point-Namensregistrierung und -auflösung - Hosts übertragen Pakete an einen einzelnen Host (Unicast), der als zentraler Nameserver für die Registrierung und Auflösung von Namen dient.
Arbeitsgruppe - Eine Sammlung von Rechnern, bei der jeder Rechner Client-Verbindungsanfragen für seine eigenen Freigaben authentifiziert.