[Kapitel 1] 1.4 Microsoft-Anwendungen

1.4 Microsoft-Anwendungen

Mit dieser Menge an Hintergrundwissen können wir nun über einige Microsoft-Anwendungen der vorhergehenden Konzepte in der CIFS/SMB Netzwerk-Welt sprechen. Und wie du erwarten könntest, sind einige komplexe Erweiterungen ebenfalls einzuführen.

1.4.1 Windows-Domains

Erinnere dich, dass eine Arbeitsgruppe eine Ansammlung von SMB-Computern ist, die sich alle im selben Subnetz befinden und auf dieselbe SMB-Gruppe abonniert sind. Eine Windows domain geht einen Schritt weiter. Sie ist eine Arbeitsgruppe von SMB-Maschinen, die eine Beigabe hat: einen Server, der als ein domain controller agiert. Du musst einen Domain-Controller besitzen, um eine Windows-Domain zu haben.[6] Im anderen Fall ist es nur eine Arbeitsgruppe. Siehe Figur 1.11.

[6] Windows-Domains heißen "Windows NT Domains" bei Microsoft, weil sie davon ausgehen, dass Windows NT-Maschinen die Rolle des Domain-Controllers übernehmen. Nun, weil Samba diese Funktion genauso gut erfüllen kann, nennen wir sie der Einfachheit halber "Windows-Domains", um Verwirrung zu vermeiden.

Figur 1.11: Eine einfache Windows-Domain

Es gibt zur Zeit zwei separate Protokolle bei einem Domain-Controller (Logon-Server) in Verwendung: eines für die Verständigung mit Windows 95/98-Maschinen und eines für die Kommunikation mit Windows NT-Maschinen. Während Samba momentan das Domain-Controller-Protokoll für Windows 95/98 anwendet (das ihm erlaubt, wie ein Domain-Controller für Windows 9 x Maschinen zu agieren), unterstützt es das Protokoll für Windows NT-Computer noch nicht voll. Obwohl - das Sambateam verspricht: die Unterstützung für das Windows NT Domain-Controller-Protokoll steht in Samba 2.1 bevor.

Warum all die Schwierigkeiten? Das Protokoll, das Windows Domain-Controller zur Verständigung mit ihren Clients und anderen Domain-Controllern verwenden, ist hauseigen und wurde von Microsoft nicht freigegeben. Dies hat das Samba Entwicklerteam gezwungen, das Domain-Controller-Protokoll in seiner Konstruktion zurückzuverfolgen, um zu sehen, welche Codes spezielle Aufgaben erfüllen.

1.4.1.1 Domain-Controller

Der Domain-Controller ist das Nervenzentrum einer Windows-Domain, soviel wie ein NIS-Server das Nervenzentrum des Unix Network Information Service ist. Domain-Controller haben eine Vielfalt an Verpflichtungen. Eine Verantwortung, mit der du dich beschäftigen musst, ist die authentication. Beglaubigung ist der Prozess der Bewilligung oder Verwehrung eines User-Zugriffs auf eine gemeinsame Ressource auf einer anderen Netzwerk-Maschine, typischerweise unter Benutzung eines Passworts.

Jeder Domain-Controller benützt einen security account manager (SAM), um eine Liste aus Username-Passwort-Kombinationen zu unterhalten. Dann formt der Domain-Controller ein zentrales Archiv der Passwörter, die an die Usernamen gebunden sind (ein Passwort pro User). Das ist effizienter, als dass jede Client-Maschine hunderte Passwörter für jede Netzwerk-Ressource unterhalten muss.

Wenn ein nicht-authentifizierter Client in einer Windows-Domain einen Zugriff auf Shares eines Servers verlangt, wird der Server vorher den Domain-Controller fragen, ob dieser User beglaubigt ist. Ist das der Fall, wird der Server eine Session "Verbindung" mit den Zugriffsrechten einrichten, die er für diesen Dienst und diesen User besitzt. Wenn nicht, wird die Verbindung abgebrochen. Ist ein User einmal bei einem Domain-Controller authentifiziert, wird ein besonderes Beglaubigungs-Zeichen zum Client retourniert, sodass der User sich nicht wieder an anderen Ressourcen bei dieser Domain einzuloggen braucht. In diesem Augenblick kann sich der User als in der Domain "eingeloggt" bezeichnen. Siehe Figur 1.12.

Figur 1.12: Verwendung eines Domain-Controllers für die Beglaubigung

1.4.1.2 Primary- und Backup-Domain-Controller

Redundanz ist eine Schlüsselidee hinter einer Windows-Domain. Der Domain-Controller, der gerade auf einer Domain aktiv ist, wird primary domain controller (PDC) genannt. Es können auch einer oder mehr backup domain controllers (BDCs) in der Domain vorkommen, welche die Aufgaben übernehmen, falls der PDC gestört oder unerreichbar ist. BDCs synchronisieren ihre SAM-Daten häufig mit dem PDC, sodass irgendeiner von ihnen DC-Dienste transparent durchführen kann, ohne seine Clients aus dem Netz zu schmeißen. Beachte ferner, dass BDCs nur read-only Kopien der SAM-Daten besitzen; sie können ihre Daten nur durch Synchronisation mit einem PDC updaten. Ein Server in einer Windows-Domain kann den SAM jedes PDCs oder BDCs für die Authentifizierung eines Users verwenden, der versucht, auf seine Ressourcen zuzugreifen und auf der Domain einzuloggen.

Bedenke, dass sich die Verhaltensweisen einer Windows-Arbeitsgruppe und einer Windows-Domain in vielen Gesichtspunkten überlappen. Das ist nicht zufällig, weil das Konzept der Windows-Domains sich nicht entwickelte, bis Windows NT 3.5 eingeführt wurde, und Windows-Domains waren gezwungen, abwärts kompatibel zu den Arbeitsgruppen von Windows für Workgroups 3.1 zu bleiben. Die Sache, die man sich hier merken soll, ist einfach, dass eine Windows-Domain eine Windows-Arbeitsgruppe mit einem oder mehreren Domain-Controllern zusätzlich ist.

Samba kann ohne weiteres als ein PDC für Windows 95/98-Maschinen funktionieren. Jedoch, Samba 2.0 kann als PDC nur für Authentifizierungszwecke agieren; es kann zur Zeit keine anderen PDC-Aufgaben übernehmen. (Sobald du dies liest, könnte Samba 2.1 verfügbar sein, wo du Samba als PDC für NT-Clients verwenden kannst.) Ebenso kann Samba wegen des gesperrten Protokolls, das Microsoft für die Synchronisation der SAM-Daten verwendet, momentan nicht als BDC dienen.

1.4.2 Browsing

Browsing ist eine anspruchsvolle Antwort auf die Userfrage: "Welche Maschinen auf dem Netzwerk sind nicht da?" Beachte, dass hier kein Zusammenhang mit einem WWW-Browser vorliegt, abgesehen von der allgemeinen Idee des "Entdeckens, was da ist". Und, wie das Web, was es nicht gibt, kann sich ohne Warnung ändern.

Vor dem Browsing müssen die User den Namen desjenigen Computers kennen, mit dem sie sich auf dem Netzwerk verbinden wollen, und dann eine UNC wie die folgende in eine Applikation oder einen Dateimanager manuell eingeben, um auf die Ressourcen zuzugreifen:

\\HYDRA\network\

Mit dem Browsing kannst du den Inhalt einer Maschine mit dem üblichen Point-and-Click überprüfen - in diesem Fall das Fenster der Netzwerkumgebung auf einem Windows-Client.

1.4.2.1 Browsing-Ebenen

Wie wir am Anfang des Kapitels andeuteten, gibt es eigentlich zwei Typen des Browsing, die du in einem SMB/CIFS-Netzwerk antriffst:

Eine Liste von Maschinen (mit gemeinsamen Ressourcen) ansehen
Die gemeinsamen Ressourcen einer bestimmten Maschine ansehen

Schauen wir uns das erste an. Auf jedem Windows Arbeitsgruppen- (oder Domain-)Subnetz hat ein Computer die Verantwortung, eine Liste der gerade über das Netzwerk erreichbaren Maschinen instand zu halten. Dieser Computer heißt Local Master Browser, und die von ihm verwaltete Liste nennt sich Browse List. Maschinen in einem Subnetz benützen während des Browsings die Browse-List, die, in der Reihenfolge auf den Umfang des Netzverkehrs beschränkt, erzeugt wurde. Anstatt jeden Computer dynamisch anzuwählen, um eine Liste der gerade verfügbaren Maschinen zu ermitteln, kann der Computer einfach den Lokal-Master-Browser fragen, damit er eine vollständige, aktuelle Liste erhält.

Um die aktuellen Ressourcen auf einer Maschine zu sehen, muss sich der User mit der genannten Maschine verbinden; diese Information kann nicht von der Browse-List erhalten werden. Man kann die Ressourcenliste einer Maschine ansehen, indem man auf das Icon der Maschine klickst, wenn es in der Netzwerkumgebung von Windows 95/98 oder NT vorhanden ist. Wie du am Beginn des Kapitels sahst, wird die Maschine mit einer Liste der gemeinsamen Ressourcen antworten, auf die zugegriffen werden kann, wenn dieser User erfolgreich authentifiziert wurde.

Jeder Server in einer Windows-Arbeitsgruppe muss seine Anwesenheit dem Local Master Browser melden, nachdem er einen NetBIOS-Namen registriert hat, und (theoretisch) mitteilen, dass er die Arbeitsgruppe verlässt, wenn er niederfährt. Der Local Master Browser hat die Pflicht, zu protokollieren, was die Server gemeldet haben. Beachte, dass der Local Master Browser nicht notwendigerweise dieselbe Maschine wie ein NetBIOS-Nameserver (NBNS) ist, den wir weiter oben besprachen.

WARNUNG: Die Windows-Netzwerkumgebung kann sich seltsam verhalten: bis du eine besondere Maschine zum Browsen gewählt hast, könnte das Netzwerkumgebungsfenster Daten enthalten, die nicht aktuell sind. Das heißt, das Netzwerkumgebungsfenster kann Maschinen zeigen, die abgestürzt sind, oder Maschinen vermissen, die bis jetzt noch nicht bemerkt wurden. Kurz und bündig - wenn du einmal einen Server angewählt hast und mit ihm verbunden bist, kannst du ruhig ein bisschen überzeugter sein, dass die Shares und Drucker wirklich auf dem Netzwerk existieren.

Unbeschadet der Rollen, die du vorher gesehen hast, kann beinahe jede Windows-Maschine (NT-Server, NT-Workstation, 98,95 oder Windows 3.1 für Workgroups) als ein Local Master Browser arbeiten. Wie beim Domain-Controller, kann der Local Master Browser einen oder mehr Backup browser auf dem lokalen Subnetz haben, die in dem Moment übernehmen, wenn der Local Master Browser versagt oder unerreichbar wird. Zur Sicherstellung einer flüssigen Operation, synchronisieren die Local Backup Browser häufig ihre Browse-Liste mit dem Local Master Browser. Ergänzen wir unser Windows-Domain-Diagramm um einen Local Master und einen Local Backup Browser. Das Ergebnis zeigt Figur 1.13.

Figur 1.13: Eine Windows-Domain mit einem Local Master und einem Local Backup Browser

Hier wird gezeigt, wie man die kleinste Zahl an Backup Browsern berechnet, die einer Arbeitsgruppe zugewiesen werden:

Wenn zwischen 1 und 32 Windows-NT-Arbeitsstationen oder 1 bis 16 Windows 95/98-Maschinen im Netzwerk sind, vergibt der Local Master Browser einen Backup Browser zusätzlich zum Local Master Browser.
Wenn die Zahl der Windows-NT-Workstations zwischen 33 und 64 oder die Zahl der Windows 95/98-Workstations zwischen 17 und 32 fällt, verteilt der Local Master Browser zwei Backup Browser.
Für jede Gruppe von 32 NT-Workstations oder von 16 Windows 95/98-Maschinen darüber hinaus verteilt der Local Master Browser einen anderen Backup Browser.

Es gibt zur Zeit kein oberes Limit für die Zahl der Backup-Browser, die vom Local Master Browser verteilt werden können.

1.4.2.2 Browsing-Wahlen

Browsing ist ein kritischer Aspekt jeder Windows-Workgroup. Jedoch, nicht alles läuft perfekt auf einem Netzwerk. Nehmen wir zum Beispiel an, dass der Windows NT-Server CEO auf dem Schreibtisch einer kleinen Firma der Local Master Browser ist - das ist er, bis der User ihn ausschaltet, während er seinen Massagestuhl einsteckt. In diesem Augenblick könnte die Windows NT-Workstation in der Ersatzteil-Abteilung einwilligen, den Job zu übernehmen. Nun, auf diesem Computer läuft gerade ein großes, schlecht geschriebenes Programm, das dessen Prozessor in die Knie zwang. Die Moral der Geschichte: Browsing muss sehr tolerant gegenüber dem Kommen und Gehen von Servern sein. Weil nahezu jede Windows-Maschine als Browser dienen kann, so muss es jederzeit eine Möglichkeit zur Entscheidung geben, wer den Job übernehmen wird. Dieser Prozess des Entscheidens heißt election (Wahl).

Ein Election-Algorithmus ist in fast alle Windows-Betriebssysteme eingebaut, so dass sie sich einigen können, wer Local Master Browser wird und welche Local Backup Browser werden. Eine Wahl kann jederzeit erzwungen werden. Nehmen wir zum Beispiel an, dass der CEO seine Massage beendet hat und seinen Server hochfährt. Wenn der Server online geht, meldet er seine Anwesenheit und es findet eine Wahl statt, um zu sehen, ob der PC in der Ersatzteil-Abteilung noch der Master Browser bleiben soll.

Wenn eine Wahl vollzogen ist, broadcastet jede Maschine via Datagramm eine Information über sich selbst. Diese Information schließt Folgendes ein:

Die Version des verwendeten Wahl-Protokolls
Das Betriebssystem auf der Maschine
Die Verweildauer des Clients im Netzwerk
Der Hostname des Clients

Diese Werte bestimmen, welches Betriebssystem Vorrang hat und die Rolle des Local Master Browsers spielen wird. (Kapitel 6, User, Security und Domains, beschreibt den Wahl-Prozess genauer.) Die Architektur, die entwickelt wurde, um das zu erreichen, ist nicht elegant und enthält Sicherheitsprobleme. Obwohl eine browsende Domain mit Domain-Security integriert werden kann, nimmt der Wahl-Algorithmus nicht Rücksicht, welche Computer Browser werden. Somit ist es für jede Maschine, die einen Browser-Dienst laufen hat, möglich, sich selbst als Teilnehmer an der Browserwahl zu registrieren, und (nach dem Gewinn) fähig zu sein, die Browse-Liste zu ändern. Dennoch ist Browsing ein Schlüssel-Werkzeug beim Windows-Networking, und die Erfordernisse der Abwärts-Kompatibilität werden dafür sorgen, dass es in den nächsten Jahren in Verwendung bleibt.

1.4.3 Kann eine Windows-Workgroup mehrere Subnetze umfassen?

Ja, aber die meisten Leute, die das gemacht haben, hatten ihre Kopfschmerzen-Share. Das Umfassen mehrerer Subnetze war nicht Bestandteil des Ausgangsentwurfs von Windows NT 3.5 oder Windows für Workgroups. Folglich ist eine Windows-Domain, die zwei oder mehr Subnetze umfasst, in Wirklichkeit der gemeinsame "Klebstoff" für zwei oder mehr Arbeitsgruppen, die sich einen identischen Namen teilen. Die gute Nachricht ist, dass du nach wie vor einen PDC zur Kontrolle der Authentifizierung quer über jedes der Subnetze verwenden kannst. Die schlechte Nachricht ist, dass die Dinge mit Browsing nicht so einfach sind.

Wie vorher erwähnt, muss jedes Subnetz seinen eigenen Local Master Browser besitzen. Sobald eine Windows-Domain mehrere Subnetze umfasst, muss ein System-Administrator eine der Maschinen als den Domain Master Browser bestimmen. Der Domain Master Browser wird eine Browse-Liste für die gesamte Windows-Domain führen. Diese Browse-Liste wird erzeugt bei der periodischen Synchronisation der Browse-Listen jedes der Local Master Browser mit der Browse-Liste des Domain Master Browsers. Nach der Synchronisation sollten Local Master Browser und Domain Master Browser die gleichen Einträge enthalten. Siehe Figur 1.14 zur Illustration.

Figur 1.14: Eine Arbeitsgruppe, die mehr als ein Subnetz umspannt

Klingt gut? Tja, es ist nicht ganz Nirwana aus den folgenden Gründen:

Ein bestehender PDC spielt immer die Rolle eines Domain Master Browsers. Nach Microsofts Entwurf teilen sich die beiden immer den NetBIOS Ressourcetyp <1B> und können (unglücklicherweise) nicht getrennt werden.
Windows 95/98-Maschinen können nicht Domain Master Browser werden, ja nicht einmal mit ihm Verbindung aufnehmen. Die Samba-Gruppe empfindet das als Marketing-Entscheidung von Microsoft, das Kunden zwingt, wenigstens eine Windows NT-Workstation (oder einen Samba-Server) auf jedem Subnetz einer Multi-Subnetz-Workgroup zu haben.

Der Local Master Browser jedes Subnetzes hält andauernd die Browse-Liste für sein Subnetz instand, für das er verantwortlich ist. Wenn also ein Computer eine Serverliste innerhalb seines eigenen Subnetzes sehen will, wird der Local Master Browser dieses Subnetzes befragt. Wenn ein Computer eine Serverliste außerhalb des Subnetzes sehen will, kann es nur noch gehen, soweit der Local Master Browser sieht. Das funktioniert, weil die maßgebliche Browse-Liste des Local Master Browsers eines Subnetzes in bestimmten Intervallen mit dem Domain Master Browser synchronisiert wird, welcher mit den Local Master Browsern der anderen Subnetze in der Domain synchronisiert wird. Das nennt man browse list propagation.

Samba kann als Domain Master Browser auf einer Windows-Domain agieren, falls notwendig. Zusätzlich kann es ebenso als Local Master Browser für ein Windows-Subnetz arbeiten, indem es seine Browse-Liste mit dem Domain Master Browser abgleicht.

1.4.4 Das Windows Internet Name Service (WINS)

Das Windows Internet Name Service (WINS) ist Microsofts Ausführung eines NetBIOS-Nameservers (NBNS). An sich erbt WINS viel von den Charakteristiken von NetBIOS. Erstens ist WINS flach, du kannst nur Maschinen mit Namen wie fred oder Workgroups wie CANADA oder USA haben. Weiters ist WINS dynamisch: sobald ein Client online geht, ist es notwendig, dass er seinen Hostnamen, seine Adresse und seine Workgroup dem lokalen WINS-Server bekanntgibt. Dieser WINS-Server wird die Information so lange speichern, als der Client periodisch seine WINS-Registrierung erneuert, welche anzeigt, das er noch mit dem Netzwerk verbunden ist. Beachte, dass WINS-Server nicht Domain- oder Arbeitsgruppen-spezifisch sind; sie können irgendwo vorkommen und irgend jemand bedienen.

Mehrere WINS-Server können gesetzt werden, um sich miteinander nach einer bestimmten Zeitdauer zu synchronisieren. Das erlaubt Eingänge für Maschinen auf dem Netzwerk, die online und offline kommen, um sich von einem WINS-Server zu einem anderen zu verbreiten. Während das theoretisch effizient erscheint, kann es schnell schwerfällig werden, wenn es einige WINS-Server gibt, die ein Netzwerk verdecken. Weil WINS-Dienste mehrere Subnetze überschneiden können (du wirst entweder die Adresse eines WINS-Servers in jeden deiner Clients fix eintragen oder sie via DHCP erhalten), ist es oft effizienter, jeden Windows-Client, egal wie viele Windows-Domains vorkommen, auf denselben WINS-Server ausgerichtet zu haben. In diesem Fall wird es nur einen maßgeblichen WINS-Server mit der richtigen Information geben, anstatt einiger WINS-Server, die unablässig kämpfen, sich mit den neuesten Veränderungen zu synchronisieren.

Der momentan aktive WINS-Server ist als Primary WINS Server bekannt. Du kannst auch einen sekundären WINS-Server einrichten, der in dem Fall übernimmt, falls der Primary WINS Server gestört oder ausgefallen ist. Beachte, dass es keine Wahl gibt, die bestimmt, welche Maschine ein Primary oder ein Backup WINS-Server wird - die Auswahl von WINS-Servern ist statisch und muss vom System-Administrator vorherbestimmt werden. Beide, der Primary und irgendwelche Backup WINS-Server, werden ihre Adressen-Datenbanken auf periodischer Basis abgleichen.

In der Familie der Windows-Betriebssysteme kann nur eine NT-Workstation oder ein NT-Server WINS Serverdienste anbieten. Samba kann ebenfalls als Primary WINS-Server, nicht aber als Secondary WINS-Server arbeiten.

1.4.5 Was kann Samba tun?

Wuff! Wetten, dass du nie gedacht hast, Microsoft-Netzwerke würden so komplex sein? Nun, vertiefen wir uns, indem wir zeigen, wo Samba aushelfen kann. Tabelle 1.6 fasst zusammen, welche Rolle Samba in einer Windows NT-Domain oder Windows-Workgroup spielen kann und welche nicht. Wie du sehen kannst, kann Samba seine Daten mit einem Microsoft-Server nicht richtig abstimmen und in den meisten Fällen nicht als Backup arbeiten, weil viele NT-Domain-Protokolle hauseigen sind und von Microsoft nicht dokumentiert wurden. Wie auch immer, mit der Version 2.0. x hat Samba die Unterstützung für die Beglaubigungs-Protokolle des Primary Domain Controllers erreicht und erwirbt jeden Tag mehr Funktionsfähigkeit.

Tabelle 1.6: Samba-Funktionen (unter 2.0.4b)
Funktion	Kann durchgeführt werden?
File Server	Yes
Printer Server	Yes
Primary Domain Controller	Yes (Samba 2.1 oder höher erforderlich)
Backup Domain Controller	No
Windows 95/98 Authentication	Yes
Local Master Browser	Yes
Local Backup Browser	No
Domain Master Browser	Yes
Primary WINS Server	Yes
Secondary WINS Server	No


1.3 Mit einem SMB/CIFS Netzwerk vertraut werden		1.5 Eine Übersicht über die Samba Distribution

Using Samba