Added my course notes. Had asked Jeremy some weeks ago.

It's german language, feel free to remove it again.

Volker
(This used to be commit a40f22427a05903dfb98e9cb849698b33b8bca90)

3 files changed, 2804 insertions, 0 deletions

diff --git a/docs/textdocs/kurs.pdf b/docs/textdocs/kurs.pdf
new file mode 100644
index 00000000000..0846227020d
--- /dev/null
+++ b/docs/textdocs/kurs.pdf
diff --git a/docs/textdocs/kurs.tex b/docs/textdocs/kurs.tex
new file mode 100644
index 00000000000..6f5a24098e5
--- /dev/null
+++ b/docs/textdocs/kurs.tex
@@ -0,0 +1,2460 @@
+\documentclass{scrartcl}
+\usepackage{pslatex}
+\usepackage[dvips,colorlinks=true,
+            pdfauthor={Volker Lendecke, Service Network GmbH},
+            pdftitle={Kursskript Samba},
+            pdfsubject={Samba},
+            pdfkeywords={samba,training}
+            ]{hyperref}
+\usepackage[T1]{fontenc}
+\usepackage{german}
+\usepackage{pstricks}
+\usepackage[dvips]{epsfig}
+\newcommand{\prog}{\texttt}
+\newcommand{\param}{\texttt}
+\newcommand{\datei}{\texttt}
+\newcommand{\nbname}{\texttt}
+\newcommand{\todo}{\texttt}
+\newcommand{\defin}{\emph}
+\hyphenation{Net-BIOS}
+
+\usepackage{fancyheadings}
+\pagestyle{fancyplain}
+\lhead{}
+\rhead{\thepage}
+\rfoot{\copyright{} 1999, 2000, Volker Lendecke (http://www.sernet.de/vl/)}
+\cfoot{}
+
+\begin{document}
+
+\title{Kursskript\\[\baselineskip]
+  \epsfig{file=logo.ps,width=6cm}}
+
+\author{Volker Lendecke\\
+Samba Team\\
+Service Network GmbH\\
+G"ottingen\\
+http://samba.SerNet.DE/}
+
+\date{\today}
+
+\maketitle
+\thispagestyle{empty}
+
+\begin{quote}
+  Dieses Dokument ist eine Mitschrift des Sambakurses der Service
+  Network GmbH in G"ottingen. Es gibt einen guten "Uberblick "uber den
+  Kurs und kann gleichzeitig als generelle Einf"uhrung in NetBIOS und
+  Samba dienen.
+\end{quote}
+
+\break
+
+\tableofcontents
+
+\break
+
+\section{Einf"uhrung}
+
+Samba -- Was ist das?
+
+Kurz gesagt l"a"st Samba jeden Unixrechner in der Netzwerkumgebung von
+Windows NT erscheinen. Au"serdem lassen sich mit Samba Datei- und
+Druckfreigaben erstellen. Das hei"st, unter Unix vorhandener
+Plattenplatz kann ganz normal unter Windows genutzt werden, und unter
+Unix vorhandene Drucker kann man als Netzwerkdrucker unter Windows
+ansteuern. Dar"uber hinaus bietet Samba viele Dienste, die sonst nur
+von Windows NT geleistet werden. Dazu geh"oren:
+
+\begin{description}
+  
+\item[WINS Server] Mit Samba kann sehr einfach ein WINS Server
+  eingerichtet werden.
+  
+\item[Computersuchdienst] Samba als sehr stabiler Server kann alle
+  Aufgaben des Computersuchdienstes "ubernehmen. Die in Windowsumgebungen
+  oft nicht sehr vorhersagbare Netzwerkumgebung kann so etwas 
+  stabiler gemacht werden.
+  
+\item[Logon Server] F"ur Windows 95/98 ist Samba Logon-Server, kann
+  also die Dom"anenanmeldung f"ur diese Systeme "ubernehmen.
+  
+\item[PDC] Die Funktionalit"at des Primary Domain Controller ist in
+  einer noch nicht freigegebenen Version implementiert, ist jedoch
+  schon in vielen Installationen im produktiven Einsatz.
+  
+\item[Diagnosewerkzeuge] Samba bietet eine Reihe von kleinen, aber
+sehr effektiven Werkzeugen, die die oft m"uhselige Suche nach Fehlern
+im Netz vereinfachen k"onnen.
+
+\end{description}
+
+Samba bietet gegen"uber den bekannten Implementationen des
+SMB-Protokolls einige Vorteile. Teilweise sind diese Vorteile von Unix
+geerbt, teilweise sind sie in der Architektur von Samba begr"undet.
+
+\begin{description}
+  
+\item[Entfernte Administration] Der gr"o"ste Vorteil von Samba in
+  gr"o"seren Umgebungen ist die M"oglichkeit, die gesamte
+  Administration von der Kommandozeile aus durchzuf"uhren. Damit
+  bekommt man gegen"uber grafischen Oberfl"achen sehr viel bessere
+  M"oglichkeiten, von entfernten Standorten aus zu administrieren.
+  Werkzeuge wie PC Anywhere sind hier deutlich weniger flexibel.
+  
+  Zus"atzlich bietet Samba die M"oglichkeit der grafischen
+  Administration "uber einen Webbrowser. Auch hier ist es unerheblich,
+  wo sich Administrator und Server befinden.
+  
+\item[Zentrale Konfiguration] Die gesamte Konfiguration von Samba
+  befindet sich in einer einzigen Datei und ist nicht "uber viele
+  Dialogfelder verteilt. Das erleichtert die Administration erheblich.
+  So l"a"st sich eine funktionierende Konfiguration sehr einfach
+  sichern und wieder einspielen.
+  
+\item[Stabilit"at] Samba erbt von Unix eine hohe Stabilit"at.
+  Unixrechner sind daf"ur ausgelegt, "uber Monate hinweg durchzulaufen
+  und leisten dies auch. Samba als weiterer Proze"s profitiert von
+  dieser hohen Verf"ugbarkeit. Die modulare Struktur von Unix l"a"st
+  es dar"uber hinaus zu, da"s der Serverdienst Samba unabh"angig von
+  allen anderen Systemprozessen eigenst"andig neu gestartet werden
+  kann, sofern hier ein Problem vorliegen sollte.
+  
+  Samba hat eine Architektur, die die Stabilit"at weiter f"ordert.
+  F"ur jede Clientverbindung wird ein eigener Proze"s gestartet.
+  Verursacht also ein Client ein Problem auf Serverseite, dann wird
+  nur dieser Client in Mitleidenschaft gezogen.  Eventuell
+  st"urzt dieser eine Proze"s ab, die anderen werden jedoch 
+  nicht gest"ort.
+  
+\item[Skalierbarkeit] Samba kann von dem vielzitierten kleinen 386er
+  unter Linux bis hin zu den gr"o"sten heute verf"ugbaren Maschinen
+  jede Hardware optimal ausnutzen. Die Architektur von Samba
+  erm"oglicht es, da"s auch Multiprozessormaschinen optimal
+  ausgelastet werden. Multiprozessormaschinen k"onnen alle Prozessoren dann
+  besch"aftigen, wenn es viele unabh"angige Prozesse im System gibt.
+  Samba erstellt f"ur jeden Client einen Proze"s, der auf einem
+  eigenen Prozessor ablaufen kann.
+  
+\item[Flexibilit"at] Samba bietet eine riesige Anzahl von
+  Konfigurationsoptionen, die zun"achst einmal "uberw"altigend wirkt.
+  Im Laufe des Kurses wird sich herausstellen, da"s f"ur das
+  Funktionieren von Samba nur sehr wenige Optionen wirklich notwendig
+  sind. Die meisten Optionen werden nur f"ur Spezialf"alle ben"otigt.
+  Durch ein sehr flexibles Schema von Makroersetzungen ist mit Samba
+  sehr viel mehr m"oglich als mit NT. Als Beispiel sei genannt, da"s
+  man sehr einfach einen Sambaserver unter zwei verschiedenen Namen in
+  der Netzwerkumgebung erscheinen lassen kann, und beide virtuelle
+  Server unterschiedlich konfigurieren kann. Zu Testzwecken ist es 
+  sogar m"oglich,
+  zwei unterschiedliche Versionen gleichzeitig auf einer Maschine
+  laufen zu lassen.
+
+\end{description}
+
+\section{NetBIOS}
+
+Sobald Windowsrechner Dateisysteme austauschen, sich gegenseitig in
+der Netzwerkumgebung sehen oder Drucker freigeben, funktioniert die
+Kommunikation "uber NetBIOS\footnote{Dies ist in reinen Windows 2000
+  Umgebungen nicht mehr richtig. Microsoft hat die NetBIOS-Ebene
+  abgeschafft, Windows 2000 kommuniziert direkt "uber TCP. Aus
+  Kompatibilit"atsgr"unden kann Windows 2000 jedoch noch "uber NetBIOS
+  kommunizieren.}. NetBIOS ist eine reine
+Softwareschnittstelle zur Kommunikation von Rechnern. Mit dieser
+Schnittstelle werden Programmen unterschiedliche Dienste zur
+Kommunikation zur Verf"ugung gestellt. NetBIOS wurde entworfen, um in
+kleinen, lokalen Netzen Kommunikation zu erm"oglichen. Dabei lag der
+Schwerpunkt des Entwurfs auf der Einfachheit der Anwendung. Auf
+Skalierbarkeit und die Andwendung in Weitverkehrsnetzen wurde beim
+Design nicht geachtet.
+
+Die Kommunikation mit NetBIOS wurde in drei Teilbereiche aufgeteilt,
+den Namensdienst, den Datagramm- und den Sitzungsdienst.
+
+\begin{description}
+  
+\item[Namensdienst:] Im Rahmen des Namensdienstes sind die Rechner in
+  der Lage, sich gegenseitig im Netz zu identifizieren. Es sei an
+  dieser Stelle betont, da"s der NetBIOS-Namensdienst nichts mit der
+  Anzeige in der Netzwerkumgebung zu tun hat. Der Computersuchdienst,
+  der f"ur die Netzwerkumgebung zust"andig ist, h"angt jedoch sehr
+  stark von einem korrekt funktionierenden Namensdienst ab.
+
+\item[Datagrammdienst:] Betrachtet man die Rechnerkommunikation auf
+  dem Netz, so sieht man, da"s die versendeten Daten in einzelne
+  Pakete aufgeteilt werden.
+  Diese einzelnen Pakete werden dann vom Netz nach bestem Bem"uhen an
+  einen Zielrechner ausgeliefert. Geht ein Paket verloren, kann man
+  nichts machen, man bekommt unter Umst"anden nicht einmal eine
+  Benachrichtigung dar"uber, da"s etwas nicht stimmt. Aufeinander
+  folgende Pakete k"onnen in vertauschter Reihenfolge beim Empf"anger
+  ankommen. Es kann sogar sein, da"s Pakete auf dem Weg dupliziert
+  werden, also mehrfach ankommen. Diese Unzuverl"assigkeit des Netzes
+  wird durch den Datagrammdienst an die Benutzerprogramme
+  weitergegeben. Der Datagrammdienst hat jedoch nicht nur Nachteile.
+  Zwei Vorteile sind der geringe Aufwand, mit dem Pakete verschickt
+  werden k"onnen, und die M"oglichkeit, ein Datagramm an mehrere
+  Rechner gleichzeitig zu verschicken. Die Applikation mu"s selbst
+  entscheiden, wie sie mit der Unzuverl"assigkeit des Dienstes
+  klarkommt.
+  
+\item[Sitzungsdienst:] Die Unzuverl"assigkeit des Netzes ist f"ur
+bestimmte Applikationen wie Dateitransfer oder Terminalanwendungen
+nicht akzeptabel. Wenn man eine Datei "ubertr"agt, m"ochte man sicher
+sein, da"s die Datei komplett und korrekt "ubertragen wurde.  F"ur
+diese h"oheren Anforderungen wurde der Sitzungsdienst entworfen. Zwei
+Rechner vereinbaren eine NetBIOS-Sitzung. Die Daten, die "uber diese
+Verbindung "ubertragen werden, kommen auf jeden Fall an, und zwar in
+der richtigen Reihenfolge. K"onnen Daten einmal nicht "ubertragen
+werden, so erh"alt die versendende Applikation eine Fehlermeldung. Die
+Applikation kann nun versuchen, die abgebrochene Sitzung neu
+aufzubauen. Dieser Zuverl"assigkeit steht ein erh"ohter Aufwand beim
+Sitzungsauf- und -abbau gegen"uber.
+
+\end{description}
+
+Zwei Rechner, die kommunizieren wollen, m"ussen sich zun"achst gegenseitig
+identifizieren. NetBIOS sieht hierf"ur bis zu 16 Zeichen lange Namen
+vor.  Jede Applikation kann f"ur sich beliebig viele Namen reservieren
+und unter einem dieser Namen Verbindungen aufbauen und Daten austauschen.
+Diese Reservierung von Namen gilt sowohl f"ur Server, die vom Netz aus
+erreichbar sein m"ussen, als auch f"ur Clients, die Server im Netz
+erreichen wollen, da Server wissen m"ussen, wohin die Antworten
+gehen m"ussen.
+
+Zwei Anwendungen wollen nun per NetBIOS miteinander kommunizieren.
+Dazu mu"s zun"achst der Server seine Bereitschaft kundtun,
+Verbindungen entgegenzunehmen. Dazu meldet er sich im Netz mit seinem
+Namen an. Diese Anmeldung geschieht per Broadcast, so da"s alle im
+Netz mith"oren k"onnen. Jeder Rechner ist frei, beliebige Namen im
+Netz f"ur sich zu beanspruchen, sofern diese noch nicht belegt
+sind\footnote{Mit dieser Freiheit ergeben sich viele M"oglicheiten,
+  von einem beliebigen Rechner aus ein Windows-Netz bis zur
+  Unbenutzbarkeit zu st"oren. Man mu"s nur bestimmte, f"ur den PDC
+  vorgesehene Namen zum richtigen Zeitpunkt reservieren.}. Eine
+Reservierung geschieht also, indem ein Rechner per Broadcast
+ank"undigt, da"s er unter einem bestimmten Namen erreichbar ist. Dann
+wartet er auf Protest. Beklagt sich niemand, schickt er eine zweite
+Reservierung und wartet wieder. Nach der dritten Reservierung ist der
+Rechner ausreichend sicher, da"s kein anderer den Namen bereits f"ur
+sich eingenommen hat, und sieht ihn als f"ur sich reserviert an.
+
+Wenn nun ein Client mit einem Server reden m"ochte, dann mu"s er sich
+wie der Server einen eindeutigen Namen ausdenken und im Netz
+reservieren. Das Verfahren dazu ist identisch. Zus"atzlich mu"s der
+Client jedoch die MAC-Adresse des Servers herausbekommen. Die
+Mechanismen, wie dies geschieht, h"angen davon ab, wie NetBIOS
+implementiert ist.
+
+NetBIOS kann mit unterschiedlichen Protokollen implementiert werden.
+NetBEUI, IPX und TCP/IP sind drei heute verwendete Protokolle, wobei
+f"ur Neuinstallation TCP/IP das bevorzugte Protokoll sein sollte.
+Der Ablauf der Namensaufl"osung soll an einem
+Beispiel verdeutlicht werden.
+
+Auf einem Client soll eine Verbindung zu dem Server \nbname{samba}
+aufgebaut werden. Direkt erreicht man dies, indem man in der Taskleiste
+Start $\rightarrow$ Ausf"uhren $\rightarrow$ \verb|\\samba| eingibt.
+Im folgenden werden die unterschiedlichen Verfahren betrachtet, mit
+denen ein Rechner die MAC-Adresse des Servers herausbekommt.
+
+\begin{description}
+
+\item[NetBEUI:]
+
+  \textbf{"`Samba"'$\,\Rightarrow\,$MAC-Adresse}
+  
+  Bei diesem Protokoll findet der Client den Server ausschlie"slich
+  "uber Broadcasts. Er verschickt per Broadcast eine Anfrage, wer sich
+  f"ur den gesuchten Namen verantwortlich f"uhlt. Der Rechner, der
+  diesen Namen tats"achlich als Server reserviert hat, wird aufgrund
+  dieser Anfrage seine eigene MAC-Adresse aus dem ROM seiner
+  Netzwerkkarte auslesen und entsprechend antworten. Daraufhin kann
+  der Client dann die Verbindung aufbauen. "Uber NetBEUI k"onnen also
+  nur Rechner miteinander reden, die in der gleichen Broadcastdom"ane
+  liegen. Sobald Router zum Einsatz kommen sollen, kann reines NetBEUI
+  nicht mehr verwendet werden, da dann der Server, der kontaktiert
+  werden soll, von der Namensanfrage nichts mehr mitbekommt, also auch
+  nicht antworten kann.
+  
+\item[IPX]
+  
+  \textbf{"`Samba"'$\,\Rightarrow\,$IPX-Knotenadresse
+    $\,\Rightarrow\,$MAC-Adresse}
+  
+  Bei IPX liegt zwischen Servernamen und der MAC-Adresse die
+  IPX-Knotenadresse. Diese enth"alt eine 4 Byte lange Netzwerknummer
+  und die 6 Byte lange MAC-Adresse des Rechners. Die Knotenadresse
+  wird anhand des NetBIOS-Namens wie bei NetBEUI per Broadcast im
+  lokalen Netz gesucht. Damit w"aren Rechner hinter Routern nicht
+  erreichbar, da die Namensanfrage nicht zu ihnen durchdringt.
+  IPX-Router erkennen diese Namensanfragen und leiten sie per
+  Broadcast in s"amtliche angeschlossenen Netze weiter, so da"s die
+  Anfrage jedes Teilnetz erreicht.
+  
+  Jede Anfrage l"ost einen Broadcast in jedem angeschlossenen Subnetz
+  aus. Einige IPX-Router speichern eine Namenstabelle und k"onnen so
+  viele Anfragen selbst beantworten, so da"s die Broadcastlast
+  reduziert wird.
+
+\item[TCP/IP]
+  
+  \textbf{"`Samba"'$\,\Rightarrow\,$IP-Adresse$\,\Rightarrow\,
+    $MAC-Adresse}
+
+  Bei TCP/IP mu"s der Client die IP-Adresse des Servers herausfinden.
+  Dies geschieht wie bei den anderen Protokollen per Broadcast im
+  lokalen Netz. IP-Router k"onnen nicht angewiesen werden, die
+  Anfragen per Broadcast in alle angeschlossenen Netze weiterzuleiten.
+  Aus diesem Grund gibt es hier andere Mechanismen, die im folgenden
+  beschrieben werden.
+  
+  Nachdem die IP-Adresse herausgefunden wurde, kommen die bekannten
+  Mechanismen von IP zum tragen. Befindet sich der Rechner im eigenen
+  Subnetz, wird direkt eine ARP-Anfrage nach der MAC-Adresse
+  ausgel"ost. Andernfalls wird der entsprechende Router anhand der
+  Routingtabelle herausgefunden und dann dessen MAC-Adresse per ARP
+  festgestellt.
+
+\end{description}
+
+Die Protokolle ordnen sich folgenderma"sen ein:
+
+\begin{figure}[ht]
+\[\begin{pspicture}(12,6)
+\psframe(3,0)(9,1)
+\rput(6,0.5){Hardware}
+\psframe(3,1)(5,3)
+\rput(4,2){TCP/IP}
+\psframe(5,1)(7,3)
+\rput(6,2){NetBEUI}
+\psframe(7,1)(9,2)
+\rput(8,1.5){IPX}
+\psframe(7,2)(9,3)
+\rput(8,2.5){NWLink}
+\psframe(3,3)(9,4)
+\rput(6,3.5){{\bfseries NetBIOS}}
+\psframe(0,4)(2,5)
+\rput(1,4.5){ping}
+\psline(0,4)(3,3)
+\psline(2,4)(5,3)
+\psframe(10,3)(12,4)
+\rput(11,3.5){NWClient}
+\psline(7,2)(10,3)
+\psline(9,2)(12,3)
+\psframe(3,4)(6,5)
+\rput(4.5,4.5){SMB}
+\psframe(3,5)(6,6)
+\rput(4.5,5.5){Datei, Druck}
+\psframe(6,4)(9,6)
+\rput(7.5,5.5){Andere}
+\rput(7.5,5){NetBIOS-}
+\rput(7.5,4.5){Anwendungen}
+\end{pspicture}\]
+\caption{Protokollstapel}
+\label{protokollstapel}
+\end{figure}
+
+In dieser Grafik steht das Programm \prog{ping} f"ur beliebige
+Programme, die direkt auf TCP/IP aufsetzen. Dies gilt beispielsweise
+f"ur alle WWW-Browser und f"ur die Programme \prog{telnet} und
+\prog{ftp}.
+
+Man kann festhalten, da"s NetBEUI hier das einzige Protokoll ist, das
+nicht "uber Routergrenzen hinweg verwendbar ist. Sowohl IPX als auch
+IP sind f"ur den Einsatz in Weitverkehrsnetzen entworfen worden und
+k"onnen folglich mit Routern umgehen.
+
+Samba ist ausschlie"slich in der Lage, NetBIOS "uber TCP/IP zu
+benutzen. Daher werden die anderen Protokolle ab hier ignoriert.
+
+\section{Bestandteile von Samba}
+
+Das Programmpaket Samba besteht aus mehreren Programmen, von denen
+einige der Serverseite und andere der Clientseite zugeordnet werden
+k"onnen.
+
+Die Servertools:
+
+\begin{description}
+  
+\item[smbd] ist der zentrale Serverproze"s, der f"ur die eigentlichen
+  Datei- und Druckdienste zust"andig ist. Sie werden mehrere
+  \prog{smbd}s im System finden. Einer dieser Prozesse lauscht auf dem
+  TCP-Port 139, und nimmt neue Verbindungen entgegen. Jede neue
+  Verbindung st"o"st einen neuen Proze"s \prog{smbd} an. Wenn Sie
+  einen Client vom Sambaserver trennen wollen, m"ussen Sie nur mit
+  \prog{smbstatus} die Proze"snummer des zust"andigen \prog{smbd}
+  erfragen, und diesen einen Proze"s t"oten.
+  
+  Samba ist im Hauptspeicherverbrauch recht sparsam. Jeder
+  \emph{aktive} Client ben"otigt etwa 1 MB Hauptspeicher auf dem
+  Server. Clients, die gerade nicht aktiv Dateien mit dem Sambaserver
+  austauschen, ben"otigen praktisch "uberhaupt keine Resourcen. Viel
+  Hauptspeicher kann von Samba selbstverst"andlich gut als Cache
+  genutzt werden.
+  
+\item[nmbd] ist f"ur die NetBIOS Namens- und Datagrammdienste
+  zust"andig. Dieser Proze"s reserviert beim Start von Samba die
+  entsprechenden NetBIOS-Namen, er ist WINS-Server und f"ur den
+  Computersuchdienst zust"andig.
+  
+\item[testparm] Mit diesem Programm kann man die \datei{smb.conf} auf
+  syntaktische Korrektheit pr"ufen. Das Programm liest die
+  Konfigurationsdatei ein und gibt Fehlermeldungen aus, sofern es
+  unbekannte Parameter findet.
+  
+\item[smbpasswd] wird zur Pflege der verschl"usselten Pa"sw"orter auf
+  Serverseite verwendet. Wie dies funktioniert, wird im Kapitel
+  \ref{passwoerter} erkl"art.
+
+\end{description}
+
+Die Clients:
+
+\begin{description}
+  
+\item[smbclient:] Mit dem Programm \prog{smbclient} kann man auf
+  Freigaben von NT-Rechnern zugreifen. Man kann auf von NT zur
+  Verf"ugung gestellten Druckern drucken und man kann NT-Freigaben in
+  tar-Dateien sichern.  Weiterhin wird mit \prog{smbclient} die Liste
+  der Server im Netz erfragt, analog zu der Netzwerkumgebung unter
+  Windows.
+  
+\item[nmblookup] ist ein Diagnosewerkzeug f"ur die
+  NetBIOS-Namensaufl"osung. Wenn zwei Computer mit Windows sich
+  nicht finden k"onnen, kann man mit \prog{nmblookup} deren Versuche,
+  sich gegenseitig zu finden, genau nachstellen. Ebenso k"onnen
+  WINS-Server befragt werden und ein NetBIOS Node Status abgefragt
+  werden. Das entsprechende Programm auf Seiten von Windows ist das
+  Kommandozeilenprogramm \prog{nbtstat}.
+
+\end{description}
+
+Auf der Serverseite finden sich noch weitere Komponenten:
+
+\begin{description}
+  
+\item[smb.conf:] Die zentrale Konfigurationsdatei von Samba. Ist Samba
+  als fester Systembestandteil installiert, findet sie sich in der
+  Regel unter \datei{/etc/smb.conf}. Ist Samba selbst compiliert,
+  liegt sie h"aufig unter \datei{/usr/local/samba/lib/smb.conf}.
+  
+\item[/var/lock/samba:] Samba ben"otigt ein Verzeichnis, in dem es
+  tempor"are Lockdateien und Datenbanken ablegen kann. Wird Samba ohne
+  besondere Optionen selbst compiliert, liegt dies Verzeichnis unter
+  \datei{/usr/local/samba/var}.
+  
+\item[/etc/smbpasswd] ist die Pa"swortdatenbank von Samba, sofern mit
+  verschl"usselten Pa"s\-w"ortern gearbeitet wird.
+  \datei{/usr/local/samba/private/} ist das Standardverzeichnis f"ur
+  diese Datei.
+
+\end{description}
+
+\section{NetBIOS-Konfiguration mit Samba}
+
+Als erstes soll eine minimale Konfiguration von Samba erreicht werden,
+mit der jeder Rechner in der Netzwerkumgebung zu sehen ist. Dazu
+sollte die Datei \datei{smb.conf} folgenderma"sen aussehen:
+
+\begin{verbatim}
+[global]
+workgroup = arbeitsgruppe
+interfaces = <IP-Adresse>/<Netzmaske>
+\end{verbatim}
+
+\label{aufbau-smb.conf}
+Der grunds"atzliche Aufbau der \datei{smb.conf} gleicht dem Aufbau der
+.INI-Dateien von Windows 3. Die Datei ist in mehrere Abschnitte
+unterteilt, die jeweils durch einen Abschnittsnamen eingeleitet
+werden. Dieser Abschnittsname selbst wird in eckige Klammern gesetzt.
+Der Inhalt jedes Abschnitts besteht nun aus Parameterzuweisungen. Im
+Beispiel gibt es nur den Abschnitt \param{global}. In diesem werden
+Festlegungen getroffen, die den Server als ganzes betreffen. Wenn
+sp"ater Freigaben erstellt werden, geschieht dies durch Anlegen von
+weiteren Abschnitten.
+
+Mit dem Parameter \param{workgroup =} wird die Arbeitsgruppe
+festgelegt, in der sich der Server befinden soll.
+
+Der Parameter \label{interfaces}\param{interfaces =} ist einer der
+wichtigsten Parameter der Sambakonfiguration. Er ist deshalb so
+wichtig, weil damit das Funktionieren des NetBIOS-Systems innerhalb
+von Samba garantiert wird.  Sp"ater wird deutlich werden, da"s gro"se
+Teile der Kommunikation auf Broadcasts basieren. \prog{ifconfig
+  <interface>} unter Unix, oder unter Linux speziell \prog{ifconfig
+  eth0} gibt sowohl die IP-Adresse der Ethernetkarte als auch die dort
+gesetzte Broadcastadresse als Ausgabe. Der Parameter \param{interfaces
+  =} weist Samba an, diese und keine andere Schnittstelle zu nutzen.
+Dar"uberhinaus ist Samba nun in der Lage, die Broadcastadresse, die
+auf dieser Schnittstelle g"ultig ist, zu bestimmen. Theoretisch
+k"onnte man die Broadcastadresse selbst"andig herausfinden, aber es
+gibt keinen portablen Weg, dies "uber Systemgrenzen hinweg zu tun. Das
+sicherste ist, Samba direkt "uber die Broadcastadresse zu informieren.
+
+Mit diesen beiden Einstellungen wird man direkt den Sambarechner in
+der Netzwerkumgebung sehen. Zur Vereinfachung sollten noch zwei
+weitere Parameter gesetzt werden, die sp"ater erkl"art werden. Die
+vollst"andige \datei{smb.conf} sieht also folgenderma"sen
+aus:\footnote{Auf einem der Rechner sollte zus"atzlich \param{os level
+    = 67} und \param{preferred master = yes} im Abschnitt 
+    \param{[global]} der /etc/smb.conf gesetzt sein.}
+
+\begin{verbatim}
+[global]
+workgroup = arbeitsgruppe
+interfaces = <IP-Adresse>/<Netzmaske>
+security = share
+encrypt passwords = yes
+\end{verbatim}
+
+Mit dieser Konfiguration kann Samba gestartet werden. Unter SuSE Linux
+geschieht dies mit dem Aufruf:
+
+\begin{verbatim}
+rcsmb start
+\end{verbatim}
+
+Damit Samba beim n"achsten Hochfahren automatisch gestartet wird,
+sollte die Variable \texttt{START\_SMB} in der Datei
+\datei{/etc/rc.config} auf \texttt{yes} gesetzt werden. Es mu"s
+letztlich nur erreicht werden, da"s sowohl der \prog{nmbd} als auch
+der \prog{smbd} mit dem Parameter \texttt{-D} gestartet werden.
+
+Es ist denkbar, den Aufruf beider Programme durch den \prog{inetd}
+durchf"uhren zu lassen. Bei Samba ist dies jedoch nicht sinnvoll.
+Insbesondere der \prog{nmbd} mu"s auf jeden Fall beim Start des
+Systems hochfahren, da dieser im NetBIOS-System Namen f"ur sich
+reservieren mu"s. W"urde er erst bei der ersten Anfrage gestartet,
+h"atten Windowsrechner keine M"oglichkeit, den Sambarechner zu finden.
+Au"serdem wird sich der \prog{nmbd} nicht wieder beenden, sobald er
+einmal gestartet wurde. Der \prog{smbd} k"onnte durch den \prog{inetd}
+gestartet werden. Jedoch ist der Resourcenbedarf nicht so hoch, da"s
+die erh"ohte Startzeit damit gerechtfertigt werden k"onnte.
+
+Nachdem alle Sambaserver gestartet wurden, sollten diese in der
+Netzwerkumgebung der beteiligten Windowsrechner erscheinen.
+
+\section{Namensaufl"osung per Broadcast}
+
+Mit \prog{nmblookup} kann man direkt eine NetBIOS-Namensanfrage
+ausl"osen.
+
+\begin{quote}
+\begin{small}\begin{verbatim}
+vlendec@server:/home/vlendec> nmblookup server
+querying server on 192.168.1.255
+192.168.1.3 server<00>
+vlendec@linux:/home/vlendec>
+\end{verbatim}\end{small}
+\end{quote}
+      
+An diesem Beispiel wird deutlich, wie die NetBIOS-Namensaufl"osung
+normalerweise arbeitet. Es wird ein Paket an der Adresse 192.168.1.255
+versendet, die Broadcastadresse im lokalen Subnetz. Um
+NetBIOS-Namensanfragen zu erm"oglichen, mu"s Samba in der Lage sein,
+die Broadcastadresse herauszufinden, an die das Paket geschickt werden
+soll.  \prog{nmblookup} entnimmt diese Adresse der Zeile
+\param{interfaces =} der \datei{smb.conf}. F"ur Tests kann man
+\prog{nmblookup} mit dem Parameter -B anweisen, die Anfragen an eine
+andere Broadcastadresse zu versenden.
+
+\begin{quote}
+\begin{small}\begin{verbatim}
+vlendec@server:/home/vlendec> nmblookup -B 192.168.1.31 server
+querying server on 192.168.1.31
+name_query failed to find name server
+vlendec@linux:/home/vlendec>
+\end{verbatim}\end{small}
+\end{quote}
+
+In diesem Beispiel wurde die Broadcastadresse auf 192.168.1.31
+gesetzt. Diese Broadcastadresse gilt in Subnetz 192.168.1.0/27. Jedoch
+f"uhlte sich der \prog{nmbd}, der f"ur diesen Namen verantwortlich
+ist, nicht angesprochen. Folglich hat er nicht auf diese Namensanfrage
+geantwortet.
+      
+Unter Windows kann man die Namensanfrage so isoliert nicht ausl"osen,
+man mu"s eine Verbindung aufbauen. Windows unterh"alt einen Cache, in
+dem erfolgreiche Anfragen zwischengespeichert werden. Diesen kann man
+sich mit \prog{nbtstat -c} anzeigen und mit \prog{nbtstat -R} l"oschen.
+Man kann eine Anfrage erzwingen, indem man mit leerem Namenscache eine
+Verbindung aufbaut, beispielsweise durch ein \prog{net view
+  \symbol{'134}\symbol{'134}samba}.
+
+Die Fehlermeldung, wenn eine NetBIOS-Namensanfrage fehlschl"agt,
+lautet im GUI: "`Der Netzwerkpfad wurde nicht gefunden"'. Auf der
+Kommandozeile kommt noch die Fehlermeldung 53 dazu.
+
+Mit \prog{nmblookup} kann man sich zus"atzlich die von einem Rechner
+reservierten Namen ausgeben lassen. Die entsprechende Operation nennt
+sich \defin{Node Status Request} und wird durch den Parameter \prog{-A
+  <IP-Adresse>} ausgel"ost. Die Ausgabe eines solchen Node Status
+Request zeigt, da"s ein Rechner f"ur sich nicht nur einen einzigen
+Namen reserviert, sondern gleich mehrere.
+
+Zun"achst gibt es die Einzelnamen, zum Beispiel den Computernamen
+selbst.  F"ur diese gilt die Regel, da"s sie nur ein einziges Mal im
+gesamten Netz auftauchen d"urfen. Sie werden reserviert und stehen dem
+entsprechenden Rechner dann exklusiv zur Verf"ugung. Daneben gibt es
+die Gruppennamen, die im Node Status Request durch \texttt{<GROUP>}
+markiert sind. Diese kann es mehrfach im Netz geben. Die Gruppennamen
+sind insbesondere als Ziele f"ur NetBIOS-Datagramme interessant.
+Beispielsweise reserviert jeder Teilnehmer an einer Arbeitsgruppe den
+NetBIOS-Gruppennamen \nbname{arbeitsgruppe<00>}. Damit kann ein
+Rechner mit einem einzigen verschickten Datagramm an diesen Namen
+s"amtliche Rechner in dieser Arbeitsgruppe erreichen.
+
+Zus"atzlich f"allt auf, da"s beispielsweise der Computername selbst
+als Einzelnamen mehrfach reserviert ist. Hier kommen die
+unterschiedlichen Namenstypen ins Spiel. Das 16. Byte eines
+NetBIOS-Namens ist f"ur ein Typfeld reserviert. So sind
+unterschiedliche Anwendungen auf einem Rechner in der Lage, sich Namen
+zu reservieren, ohne sich gegenseitig zu st"oren.
+
+Zun"achst die Einzelnamen, die h"aufig auftauchen:
+
+\begin{description}
+
+\item[computername$<$00$>$] Hiermit tut der Rechner einfach seine
+Existenz kund. Wenn ein Rechner auf Resourcen anderer Rechner zugreift,
+wird als Clientname dieser Name benutzt.
+
+\item[computername$<$20$>$] Dieser Name wird f"ur den Serverdienst
+reserviert. Wenn ein Rechner als Datei- oder Druckserver angesprochen
+werden soll, dann wird eine Verbindung zu diesem NetBIOS-Namen aufgebaut.
+
+\item[computername$<$03$>$] Unter diesem Namen meldet sich der
+Nachrichtendienst des Rechners an. Kurze Meldungen, die unter Windows
+NT mit dem Kommando \prog{net send} abgesetzt werden, und unter
+Windows 95 mit dem Programm Winpopup verschickt werden, kann der
+Rechner damit empfangen und am Bildschirm anzeigen.
+
+\item[arbeitsgruppe$<$1d$>$] Dieser Rechner ist der sogenannte
+  \defin{Lokale Master Browser}, der die Liste s"amtlicher Rechner in
+  der Netzwerkumgebung pflegt.
+  
+\item[arbeitsgruppe$<$1b$>$] Dieser Rechner ist der \defin{Domain
+    Master Browser}, der "uber Subnetzgrenzen hinweg f"ur die
+  Netzwerkumgebung zust"andig ist.
+
+\end{description}
+
+Einige Gruppennamen werden ebenfalls reserviert:
+
+\begin{description}
+  
+\item[arbeitsgruppe$<$00$>$] Ein Rechner verk"undet hiermit seine
+  Zugeh"origkeit zu einer Arbeitsgruppe. Beispielsweise k"onnen
+  Winpopup-Meldungen an eine ganze Arbeitsgruppe versendet werden.
+  Dies geschieht per Datagramm an diesen Namen.
+  
+\item[arbeitsgruppe$<$1e$>$] Wahlen zum Lokalen Master Browser werden
+  "uber diesen Namen abgewickelt. Siehe hierzu Kapitel \ref{netzwerkumgebung}.
+
+\end{description}
+
+\section{Netzwerkumgebung}
+\label{netzwerkumgebung}
+
+Die \defin{Netzwerkumgebung} ist einer der instabileren Aspekte von
+Windows. Hiermit kann man sich, sofern alles funktioniert, alle
+Rechner in einer Arbeitsgruppe anzeigen lassen. Dabei dauert es
+mitunter geraume Zeit, bis ein Rechner in einer Anzeige erscheint, und
+es dauert unter Umst"anden noch l"anger, bis er wieder verschwindet.
+
+Eine naive Implementation k"onnte funktionieren, indem jeder Rechner,
+der Serverdienste anbietet, dieses regelm"a"sig per Broadcast im Netz
+mitteilt. Ein solches Vorgehen hat jedoch mehrere Nachteile. Erstens
+w"urde die Last im Netz mit jedem zus"atzlichen Rechner stark
+ansteigen. Zweitens mu"s jeder Rechner, der die Netzwerkumgebung anzeigen
+will, relativ komplexe Software laufen lassen. Und drittens scheitert dieses
+Schema auf jeden Fall an Subnetzgrenzen, die f"ur Broadcasts eine
+Grenze darstellen. Aus diesen Gr"unden ist man einen anderen Weg
+gegangen.
+
+Der \defin{Lokale Master Browser} (im folgenden auch LMB genannt) ist
+ein Rechner, der im Netz die Netzwerkumgebung pflegt. Dieser Rechner
+wird nirgendwo zentral bestimmt, sondern er wird gew"ahlt. Diese Wahl
+findet immer dann statt, wenn einer der beteiligten Rechner
+feststellt, da"s es im Moment keinen solchen Lokalen Master Browser
+gibt.  Beispielsweise kann der Explorer von Windows eine solche Wahl
+ansto"sen. Wenn Windows 95 die geschwenkte Taschenlampe anzeigt, wird
+der LMB gesucht. Ist keiner vorhanden, wird eine Wahl angesto"sen.
+
+Die Wahl erfolgt mit Datagrammen an den Gruppennamen
+\nbname{arbeitsgruppe<1e>}. Ein Rechner verschickt ein Datagramm an
+diesen Namen. Jeder Rechner, der diesen Namen reserviert hat, h"ort
+dieses Datagramm und entscheidet, wie er selbst vorgehen soll.  In dem
+Datagramm sind verschiedene Kriterien zur Wahl enthalten,
+beispielsweise das Betriebssystem des versendenden Rechners.
+
+Empf"angt beispielsweise eine Windows NT Workstation ein Paket von
+einem Windows NT Server, so entscheidet sie, da"s sie die Wahl
+verloren hat. Damit wird sie selbst nicht mehr aktiv. Kommt dieses
+Paket jedoch von einem Windows 95 Rechner, so h"alt sie sich selbst
+f"ur geeigneter, den Lokalen Master Browser zu "ubernehmen. Dann wird
+sie selbst ein solches Wahlpaket mit ihren Parametern versenden.  Der
+Windows 95 Rechner empf"angt dies, und sieht, da"s er verloren hat.
+Auf diese Weise schaukelt sich die Wahl hoch, bis der "`beste"'
+Rechner die Wahl gewinnt.
+
+Wenn es nun mehrere Windows NT Workstations im Netz g"abe, dann
+w"are die Wahl unentschieden. An dieser Stelle kommt die \emph{Uptime}
+der Rechner ins Spiel. Der Rechner, der am l"angsten l"auft, gewinnt
+die Wahl. Nun kann es sein, da"s nach einem Stromausfall zwei Rechner
+genau die gleiche Uptime haben. Dann kommt als letztes und eindeutiges
+Entscheidungskriterium der NetBIOS-Name des Rechners zum Zug. Der
+alphabetisch vorne stehende Rechner gewinnt. Mit diesen drei Kriterien
+ist eine eindeutige Wahl gesichert.
+
+Samba ordnet sich in der Standardeinstellung zwischen Windows 95 und
+Windows NT ein, das hei"st, gegen Windows 95 gewinnt Samba die Wahl,
+"uberl"a"st jedoch Windows NT Rechnern den Lokalen Master Browser.
+
+Drei Parameter in der \datei{smb.conf} bestimmen das Verhalten von
+Samba in der Wahl zum Lokalen Master Browser:
+
+\begin{description}
+  
+\item[\param{os level}] Damit wird die Einordnung von Samba in die
+  unterschiedlichen Betriebssysteme geregelt. Diese haben f"ur die
+  Betriebssystemstufe folgende Werte:
+
+\[\begin{tabular}{|l|r|}
+\hline
+Windows for Workgroups & 0 \\
+\hline
+Windows 95/98 & 1 \\
+\hline
+Windows NT Workstation & 16 \\
+\hline
+Windows NT Server & 32 \\
+\hline
+\end{tabular}\]
+
+Diese Werte sind nicht als fest anzusehen. Wenn ein neues Service Pack
+f"ur ein Betriebssystem herausgegeben wird, ist es m"oglich, da"s in
+der Software f"ur den Lokalen Master Browser Fehler bereinigt wurden.
+Dann ist es sinnvoll, da"s diese neue Software die Rolle des LMB
+"ubernimmt. Der einfachste Weg ist, den \param{os level} einfach
+hochzusetzen. Samba hat hier einen Vorgabewert von 20.
+
+Der Parameter \param{os level} kann Werte von 0 bis 255 annehmen.
+Setzt man ihn auf 255, wird nach einer erfolgreichen Wahl niemand mehr
+Local Master Browser werden k"onnen.
+
+\item[\param{local master}] M"ochte man auf keinen Fall den LMB auf
+  einem Sambarechner haben, so setzt man den Parameter \param{local
+    master = no}. Dann nimmt Samba an keiner Wahl teil.
+  
+\item[\param{preferred master}] Mit der Standardeinstellung
+  \param{preferred master = no} sucht Samba beim Start nach
+  einem LMB. Findet er einen, meldet er sich dort.  Findet er keinen
+  LMB, bleibt Samba passiv. Jemand anders mu"s eine Wahl ansto"sen.
+  Wenn dann eine Wahl stattfindet, nimmt Samba teil und ordnet sich
+  anhand seines \param{os level} ein. Wenn man sichergehen m"ochte,
+  da"s Samba auf jeden Fall nach dem Start den LMB "ubernimmt, dann
+  mu"s man den \param{os level} hoch genug setzen, und den Parameter
+  \param{preferred master = yes} setzen.  Damit wird Samba beim Start
+  des \prog{nmbd} auf jeden Fall eine Wahl ansto"sen und sie dann
+  unter Umst"anden gewinnen.
+
+\end{description}
+
+Mit den Einstellungen
+
+\begin{verbatim}
+[global]
+os level = 66
+preferred master = yes
+\end{verbatim}
+
+\noindent
+kann man sicher sein, da"s der Sambarechner immer den LMB innehat. Es
+sei denn, ein anderer Administrator von Samba kommt auf die Idee,
+einen noch h"oheren Wert f"ur den \param{os level} zu benutzen.
+
+Ein Primary Domain Controller kann unter Umst"anden erheblich gest"ort
+werden, wenn er in seinem Subnetz nicht der LMB ist.
+
+\section{NetBIOS "uber Subnetzgrenzen}
+
+\newcommand{\computer}[2]{%
+  \rput[t](0,0){%
+    \begin{pspicture}(2,2)
+      \psframe(0,0.5)(2,1.5)
+      \psline(1,1.5)(1,2)
+      \rput(1,1){\texttt{#1}}
+      \rput[b](1,0.2){{\footnotesize IP: #2}}
+    \end{pspicture}}}
+\newcommand{\network}[1]{%
+  \rput[l](0,0){%
+    \begin{pspicture}(#1,0.6)
+      \psline(0,0)(0,0.6)
+      \psline(0,0.3)(#1,0.3)
+      \psline(#1,0)(#1,0.6)
+    \end{pspicture}}}
+\newcommand{\routednet}{%
+\rput[lb](0,0){%
+\begin{pspicture}(10,5.5)
+\rput(0,5){\network{7}}
+\rput(2,5){\computer{WKS}{192.168.1.5}}
+\rput(3,2){\network{7}}
+\rput(8,2){\computer{SERVER}{192.168.2.8}}
+\rput(5.5,3.75){\psframe(-1,-0.25)(1,0.25)}
+\rput(5.5,3.75){{\footnotesize 192.168.1.1}}
+\rput(5.5,3.25){\psframe(-1,-0.25)(1,0.25)}
+\rput(5.5,3.25){{\footnotesize 192.168.2.1}}
+\psline(5.5,4)(5.5,5)
+\psline(5.5,2)(5.5,3)
+\end{pspicture}}}
+
+Wird die Namensreservierung und -aufl"osung ausschlie"slich per
+Broadcast durchgef"uhrt, kann man Rechner, die hinter Routern liegen,
+nicht erreichen. Broadcasts verbleiben in den Subnetzen, in denen sie
+ausgesendet wurden.
+
+\begin{figure}[ht]\[
+\begin{pspicture}(10,6)
+\rput(0,0){\routednet}
+\psline{<-}(0,5.5)(2.7,5.5)
+\psline{->}(4.3,5.5)(7,5.5)
+\rput(3.5,5.5){\texttt{SERVER?}}
+\end{pspicture}\]
+\caption{Namensanfrage per Broadcast}
+\label{broadcastanfrage}
+\end{figure}
+
+In der dargestellten Situation sind zwei Netze "uber einen Router
+verbunden. Jeder der beiden Rechner reserviert seinen Namen in dem ihm
+zugeordneten Subnetz. Die Workstation \nbname{WKS} schickt ihre
+Reservierungen per Broadcast an 192.168.1.255, und der Server
+\nbname{SERVER} wird seinen Namen auf 192.168.2.255 reservieren. Der
+Router zwischen beiden bekommt diese Reservierungen zwar mit, wird sie
+aber nicht in das jeweils andere Subnetz weiterleiten. Wenn nun
+\nbname{WKS} ihren Server \nbname{SERVER} sucht, geschieht dies
+ebenfalls per Broadcast an 192.168.1.255. Diese Anfrage bleibt wie
+dargestellt im oberen Subnetz und erreicht \nbname{SERVER} gar nicht,
+so da"s dieser auch nicht antworten kann.
+
+Der einfachste Weg, die Namensaufl"osung "uber Subnetzgrenzen hinweg
+zu realisieren, geht "uber eine statische Tabelle. Unter Windows
+liegt diese in der Datei \datei{LMHOSTS}. Sie liegt abh"angig von der
+Windowsversion in unterschiedlichen Verzeichnissen und l"a"st sich am
+einfachsten mit der Suchfunktion des Desktops finden. Diese Datei ist
+"ahnlich aufgebaut wie die Datei \datei{/etc/hosts} unter Unix. Ein
+Beispieleintrag ist der folgende:
+
+\verb|192.168.1.5 samba|
+
+Die Eintr"age in der \datei{LMHOSTS} k"onnen durch den Zusatz
+\texttt{\#PRE} erg"anzt werden. Dieser Zusatz legt fest, in welcher
+Reihenfolge die Namensaufl"osung vorgenommen wird. Ist kein
+\texttt{\#PRE} vorhanden, so wird zun"achst eine konventionelle
+Namensaufl"osung per Broadcast versucht. Erst, wenn diese
+fehlschl"agt, wird in der \datei{LMHOSTS} nachgeschaut. Ist der Zusatz
+vorhanden, so wird ohne Namensaufl"osung direkt der Wert in der
+\datei{LMHOSTS} verwendet.
+
+Die zweite M"oglichkeit, das Problem zu l"osen, ist eine zentrale
+Datei \datei{LMHOSTS}. Dazu gibt es den WINS-Server. Ein solcher Server
+ist ein Rechner, bei dem sich jede Applikation im Netz mit ihren Namen
+anmeldet. Die IP-Adresse dieses Servers mu"s jedem Rechner mitgeteilt
+werden. Bei Windows geschieht dies in den Eigenschaften des TCP/IP
+Protokolls im Reiter WINS-Adresse. Setzt man DHCP-Server ein, kann man
+ebenfalls den WINS-Server festlegen. Samba bekommt die Adresse mit dem
+Parameter \param{wins server = <ip-adresse>} im Abschnitt
+\param{[global]} der \datei{smb.conf} mitgeteilt. Sobald ein Client
+die IP-Adresse des WINS Servers kennt, ist es v"ollig gleichg"ultig,
+ob sich dieser im gleichen Subnetz befindet oder nicht.
+
+Die Namensreservierung erfolgt nicht mehr per Broadcast, sondern mit
+einem gerichteten UDP-Paket an den WINS-Server.  Gerichtete Pakete
+leitet der Router wie jedes andere Paket an den WINS-Server weiter.
+Dieser sieht in seiner Tabelle nach, ob der Name bereits reserviert
+ist. Ist das nicht der Fall, so wird er spontan eine Best"atigung der
+Reservierung zur"uckschicken. Diese Reservierung gilt nun f"ur eine
+bestimmte Zeit und mu"s rechtzeitig erneuert werden.
+
+Ist der Name bereits reserviert, wird der WINS-Server den bisherigen
+Besitzer befragen, ob er den Namen noch ben"otigt. Bekommt er keine
+Antwort, wird er dem neuen Besitzer ebenfalls eine Best"atigung
+schicken. M"ochte der alte Besitzer den Namen noch verwenden, so wird
+der Anfragende eine Ablehnung der Reservierung erhalten. Diese
+Nachfrage ist notwendig, um einem abgest"urzten Rechner das spontane
+Booten zu erm"oglichen, da bei einem Absturz keine Freigabe der
+Namensreservierung erfolgen kann.
+
+Die Namensanfrage, die in Abbildung \ref{broadcastanfrage} den Server
+nicht erreichte, weil der Router keine Broadcasts weitergibt, wird nun
+direkt an den WINS-Server gerichtet, der in seiner Tabelle nachsehen
+kann.
+
+\begin{figure}[ht]\[
+\begin{pspicture}(10,6)
+\rput(0,0){\routednet}
+\rput(4,2){\computer{WINS}{192.168.2.5}}
+\psline[linestyle=dashed,linearc=0.25]
+      {->}(2.5,4.5)(3.2,4.9)(5.3,4.9)(5.3,2)(4.5,1.5)
+\rput(3.5,5.8){\texttt{SERVER?}}
+\end{pspicture}\]
+\caption{WINS-Anfrage}
+\end{figure}
+
+Samba kann ganz normal als WINS-Server konfiguriert werden, indem der
+Parameter \param{wins support = yes} gesetzt wird. Ist diese Parameter
+gesetzt, kann Samba nach einem Neustart bei allen Clients und allen
+sonstigen Servern als WINS-Server eingetragen werden. Werden diese
+dann neu gestartet, melden sie sich beim WINS Server an.
+
+Wenn nun ein Rechner mit Samba als WINS Server konfiguriert ist, und
+sich die anderen Rechner dort anmelden, werden diese in der Datei
+\datei{/var/lock/samba/wins.dat} abgelegt. Der \prog{nmbd} pflegt
+diese Datei dynamisch, je nach Reservierungen und Abmeldungen. Die
+Datei \datei{wins.dat} wird in regelm"a"sigen Abst"anden geschrieben.
+Wenn es notwendig sein sollte, den wirklich aktuellen Stand
+unabh"angig von diesem Zeitintervall zu erhalten, so kann man dem
+\prog{nmbd} das \prog{HANGUP}-Signal durch den Befehl \prog{killall
+-HUP nmbd} senden. Au"serdem wird die \datei{wins.dat} beim Beenden
+des \prog{nmbd} geschrieben.
+
+Diese Datenbank wird auf Festplatte gehalten, damit die Daten einen
+Neustart von Samba "uberleben. Jeder Rechner, der einen Namen f"ur
+sich reserviert hat, hat diese Reservierung f"ur einen bestimmten
+Zeitraum ausgesprochen. Wenn Samba jetzt neu gestartet werden sollte,
+und dadurch die Datenbank verloren ginge, w"are der gesamte
+NetBIOS-Namensraum nicht mehr verf"ugbar. Au"serdem kann ein WINS
+Server die angeschlossenen Clients weder von sich aus finden, noch sie
+darum bitten, sich erneut zu registrieren. Daher ist die WINS
+Datenbank "uber Neustarts von Samba hinaus zu erhalten.
+
+Die Anfrage, die die Workstation \nbname{WKS} absetzt, wird nun nicht
+mehr per Broadcast gestellt, sondern mit einem gerichteten Paket an
+den WINS-Server, bei dem sich alle Rechner angemeldet haben.
+
+%\[\setlength{\unitlength}{1mm}
+%\begin{picture}(100,60)(0,20)
+%\put(0,0){\routednet}
+%\put(30,75){\makebox(0,0)[l]{{\ttfamily\bfseries SERVER?}}}
+%\curve(17,65, 20,72, 29,75)
+%\tagcurve(40,75, 50,75, 57,65, 57,45, 45,38, 40,30, 30,20)
+%\put(50,45){\circle*{1}}
+%\put(40,40){\computer{WINS}{192.168.2.5}}
+%\end{picture}\]
+
+WINS hat gegen"uber der broadcastbasierten Namensreservierung einige
+Vorteile. Namensreservierung per Broadcast erfolgt durch Wartezeiten.
+Es wird die Reservierung angek"undigt, es wird gewartet, die
+Reservierung wird erneut angek"undigt, und es wird wieder gewartet.
+Dieses Spiel wiederholt sich mehrfach, bis der Rechner sicher sein
+kann, da"s ein eventueller Vorbesitzer des Namens genug Zeit hatte,
+sich zu beklagen. Beim Einsatz von WINS entfallen diese Wartezeiten,
+da hier ein einziger Rechner s"amtliche reservierte Namen registriert
+und in seiner Tabelle nachschauen kann. Daher ist die Reservierung per
+NetBIOS deutlich schneller, und auch weniger netzbelastend. Selbst
+wenn man also nur ein einziges Subnetz hat, sollte man zur Reduzierung
+der Netzlast den Einsatz eines WINS-Servers in Erw"agung ziehen.
+
+Zus"atzlich sei hier angemerkt, da"s es netzwerkweit nur einen
+einzigen WINS-Server geben darf. Selbst wenn es unterschiedliche
+Arbeitsgruppen oder Dom"anen gibt, darf es nicht mehr als einen
+WINS-Server geben. Setzt man mehrere WINS-Server ein, hat man getrennte
+Namensr"aume.  Rechner im einen Namensraum k"onnen mit Rechnern, die
+an einem anderen WINS-Server angeschlossen sind, nicht kommunizieren.
+Es kann trotzdem zu Kollisionen kommen, da Windowsrechner bestimmte
+Namen unabh"angig von WINS-Einstellungen ausschlie"slich per Broadcast
+reservieren. Unter Windows NT kann man mehrere WINS-Server einsetzen,
+die sich gegenseitig abstimmen. Diese WINS-Server treten gegen"uber
+den Clients als ein einziger Server auf, unabh"angig von ihrer Anzahl.
+
+Die Abfrage eines WINS Servers durch \prog{nmblookup} erfolgt
+beispielhaft folgenderma"sen:
+
+\begin{verbatim}
+nmblookup -R -U 192.168.1.5 samba
+\end{verbatim}
+
+Hiermit wird der WINS Server, der auf dem Rechner 192.168.1.5 liegt,
+nach dem Namen \nbname{samba} befragt.
+
+Samba kennt zwei zus"atzliche Funktionen, die es im Zusammenhang mit
+WINS interessant machen. Einerseits kann Samba als WINS Proxy
+eingerichtet werden, indem \param{wins proxy = yes} gesetzt wird. Ist
+diese Einstellung aktiv, dann wird Samba s"amtliche Reservierungen und
+Anfragen, die es aus dem lokalen Netz per Broadcast erh"alt, an den
+mit \prog{wins server =} konfigurierten WINS Server weiterleiten.
+Damit kann man einen Samba-Server in ein Subnetz stellen. S"amtliche
+Rechner in diesem Netz werden nun beim WINS angemeldet, und nutzen
+diesen auch. Dies ist auch dann der Fall, wenn sie entweder selbst
+keinen WINS Server ansprechen k"onnen oder nicht daf"ur konfiguriert
+sind. Man sollte jedoch in jedem Fall eine echte Konfiguration des
+WINS Servers auf dem Client vorziehen. Ein WINS Proxy kann nur eine
+Behelfsl"osung sein, da man sich damit auf einen weiteren
+Rechner verl"a"st.
+
+Unter Windows kann man statische Eintr"age im WINS vornehmen. Dies
+geht so direkt unter Samba nicht. Man mu"s hierzu den Parameter
+\param{dns proxy = yes} auf dem WINS Server setzen. Empf"angt der WINS
+Server nun eine Anfrage, die er nicht aus seiner Datenbank beantworten
+kann, wird er eine ganz normale Unix-Hostnamenanfrage machen.
+Typischerweise wird er in der \datei{/etc/hosts} nachschauen und
+danach dann das DNS anhand der Konfiguration in der Datei
+\datei{/etc/resolv.conf} befragen. Damit ist es durch einen Eintrag
+auf dem WINS Server m"oglich, den gesamten DNS-Namensraum auch in der
+NetBIOS-Namenswelt zur Verf"ugung zu stellen.
+
+\section{Netzwerkumgebung "uber Subnetzgrenzen}
+
+So, wie die Netzwerkumgebung in Abschnitt \ref{netzwerkumgebung}
+betrachtet wurde, funktioniert sie nur in einem einzigen lokalen
+Netz. Die Wahl zum lokalen Master Browser funktioniert per Datagramm,
+das an den Namen \nbname{arbeitsgruppe<1e>} gesendet
+wird. \nbname{arbeitsgruppe<1e>} ist ein Gruppenname, der von mehreren
+Rechnern reserviert sein kann. Das hei"st, da"s ein Datagramm an
+diesen Namen mehrere Rechner erreichen mu"s. Dies geschieht bei
+NetBIOS "uber TCP/IP mit einem UDP-Paket an die Broadcastadresse im
+lokalen Netz. Allein hieraus ergibt sich, da"s es pro Arbeitsgruppe in
+jedem Subnetz einen eigenen LMB geben mu"s. Jeder LMB bekommt aus
+seinem Subnetz die Informationen "uber vorhandene Server.
+
+Um diese Einschr"ankung zu umgehen, gibt es den Domain Master Browser
+(DMB). Der DMB ist ein Rechner, der die Serverlisten von allen LMBs
+einsammelt und auf Anforderung wieder herausgibt. Dabei sitzt der DMB
+nur passiv da und wartet darauf, da"s sich ein LMB mit ihm
+synchronisieren will. Es ist Aufgabe der LMBs, sich regelm"a"sig
+danach zu erkundigen, wo der DMB sitzt, und mit diesem dann die
+Serverlisten abzugleichen.
+
+Die Vorg"ange werden am deutlichsten, wenn man ein Beispiel
+betrachtet. Dieses Beispiel ist im wesentlichen der
+Originaldokumentation von Samba aus der Datei \datei{BROWSING.txt}
+entnommen.
+
+\newcommand{\minicomputer}[1]{%
+\begin{picture}(10,9)(5,9)
+\put(0,0){\framebox(10,5){{\ttfamily #1}}}
+\put(5,5){\line(0,1){4}}
+\end{picture}}
+\newcommand{\mininetz}[1]{%
+\begin{picture}(62,12)
+\put(10,10){\minicomputer{N#1A}}
+\put(25,10){\minicomputer{N#1B}}
+\put(40,10){\minicomputer{N#1C}}
+\put(55,10){\minicomputer{N#1D}}
+\put(3,10){\line(1,0){59}}
+\put(3,8){\line(0,1){4}}
+\put(62,8){\line(0,1){4}}
+\end{picture}}
+
+\begin{figure}[ht]
+\[\setlength{\unitlength}{1.1mm}
+\begin{picture}(120,60)(0,5)
+\put(0,20){\mininetz{1}}
+\put(25,19){\makebox(0,0){\textit{{\small DMB,LMB}}}}
+\put(30,50){\mininetz{2}}
+\put(85,49){\makebox(0,0){\textit{{\small WINS}}}}
+\put(55,49){\makebox(0,0){\textit{{\small LMB}}}}
+\put(50,5){\mininetz{3}}
+\put(105,4){\makebox(0,0){\textit{{\small LMB}}}}
+\put(48,48){\minicomputer{R1}}
+\put(48,48){\line(0,1){12}}
+\put(48,39){\line(0,-1){9}}
+\put(77,48){\minicomputer{R2}}
+\put(77,48){\line(0,1){12}}
+\put(77,39){\line(0,-1){24}}
+\end{picture}\]
+\caption{Domain Master Browser}
+\end{figure}
+
+Dieses Netz besteht aus 3 Subnetzen (1,2,3), die durch 2 Router (R1
+und R2) verbunden sind. Die Router lassen keine Broadcasts durch. Alle
+Subnetze bestehen aus jeweils 4 Maschinen.  Nehmen wir der Einfachheit
+halber an, da"s alle Maschinen in der gleichen Arbeitsgruppe
+konfiguriert sind. Rechner \nbname{N1B} im Subnetz 1 ist als Domain
+Master Browser konfiguriert. Das hei"st, da"s er die Browseliste f"ur
+die ganze Arbeitsgruppe aufsammelt. Rechner \nbname{N2D} ist als WINS
+Server konfiguriert und alle anderen Maschinen registrieren ihre
+NetBIOS Namen dort.
+
+Wenn alle diese Maschinen gebootet werden, werden in jedem der drei
+Subnetze Wahlen um einen Local Master Browser abgehalten. Nehmen wir
+an, im Subnetz 1 gewinnt \nbname{N1C}, im Subnetz 2 gewinnt
+\nbname{N2B} und im Subnetz 3 gewinnt \nbname{N3D}. Diese Maschinen
+sind als Local Master Browser in ihrem Subnetz bekannt.  Im Subnetz 1
+liegen der LMB und der DMB auf der gleichen Maschine, was nicht der
+Fall sein mu"s. Diese beiden Rollen sind vollst"andig unabh"angig
+voneinander.
+
+Alle Maschinen, die Serverdienste anzubieten haben, k"undigen dies per
+Broadcast auf ihrem Subnetz an. Der Local Master Browser in jedem
+Subnetz empf"angt diese Broadcasts und tr"agt alle Server in einer
+Liste ein. Diese Liste von Eintr"agen ist die Basis f"ur die
+Browseliste. In unserem Fall nehmen wir an, da"s alle Maschinen
+Serverdienste anbieten, das hei"st, da"s alle Maschinen in der Liste
+erscheinen.
+
+F"ur jedes Subnetz wird der Local Master Browser als
+\emph{ma"sgeblich} angesehen, und zwar f"ur alle Namen, die er per
+lokalem Broadcast empf"angt. Broadcasts verlassen das Subnetz nicht,
+und die Broadcasts im lokalen Subnetz werden als ma"sgeblich
+angesehen. Daher wird dem Local Master Browser bei diesen Servern
+geglaubt. Rechner, die sich in anderen Subnetzen befinden, und "uber
+die der Local Master Browser von anderen Local Master Browsern
+informiert wurde, werden als nicht ma"sgeblich angesehen.
+
+An diesem Punkt sieht die Browse Liste folgenderma"sen aus: (dies sind
+die Maschinen, die Sie in Ihrer Netzwerkumgebung sehen w"urden, wenn
+Sie sie in einem bestimmten Subnetz ansehen)
+
+\vspace{\baselineskip}
+\[\begin{tabular}{|c|c|l|}
+\hline
+Netz & LMB &  Liste \\ \hline \hline
+1 & \nbname{N1C} & \nbname{N1A}, \nbname{N1B}, \nbname{N1C}, \nbname{N1D}\\
+\hline
+2 & \nbname{N2B} & \nbname{N2A}, \nbname{N2B}, \nbname{N2C}, \nbname{N2D}\\
+\hline
+3 & \nbname{N3D} & \nbname{N3A}, \nbname{N3B}, \nbname{N3C}, \nbname{N3D}\\
+\hline
+\end{tabular}\]
+\vspace{\baselineskip}
+
+An diesem Punkt sind alle Subnetze vollst"andig separat, keine
+Maschine wird in anderen Subnetzen gesehen. Die
+Microsoft-Dokumentation spricht davon, da"s die Arbeitsgruppen in den
+Subnetzen getrennt sind.
+
+Sehen wir uns nun Subnetz 2 an. Sobald \nbname{N2B} der Local Master
+Browser geworden ist, sucht er den Domain Master Browser, um mit ihm
+die Browse Listen zu synchronisieren. Dies tut er, indem er den WINS
+Server (\nbname{N2D}) nach der IP-Adresse fragt, die zum NetBIOS-Namen
+\nbname{arbeitsgruppe<1B>} geh"ort. Diesen Namen hat der Domain Master
+Browser (\nbname{N1C}) beim WINS Server f"ur sich beim booten
+registriert.
+
+\nbname{N2B} kennt nun den Domain Master Browser. Er k"undigt sich als
+Local Master Browser f"ur Subnetz 2 bei ihm an. Dann synchronisiert
+\nbname{N2B} sich mit \nbname{N2D}, indem er einen
+NetServerEnum2-Aufruf abschickt. Der Domain Master Browser schickt
+alle Server, die er kennt, zur"uck. Sobald der Domain Master Browser
+die Ank"undigung von \nbname{N2B} als Lokaler Master Browser erhalten
+hat, wird auch er sich mit dem Local Master Browser
+synchronisieren. Nachdem beide Synchronisationen stattgefunden haben,
+sehen die Browse Listen so aus:
+
+\vspace{\baselineskip}
+\[\begin{tabular}{|c|c|l|}
+\hline
+Netz & LMB &  Liste \\ \hline \hline
+1 & \nbname{N1C} & \nbname{N1A}, \nbname{N1B}, \nbname{N1C}, \nbname{N1D}\\
+  & & \nbname{N2A*}, \nbname{N2B*}, \nbname{N2C*}, \nbname{N2D*}\\
+\hline
+2 & \nbname{N2B} & \nbname{N2A}, \nbname{N2B}, \nbname{N2C}, \nbname{N2D}\\
+& & \nbname{N1A*}, \nbname{N1B*}, \nbname{N1C*}, \nbname{N1D*}\\
+\hline
+3 & \nbname{N3D} & \nbname{N3A}, \nbname{N3B}, \nbname{N3C}, \nbname{N3D}\\
+\hline
+\end{tabular}\]
+\vspace{\baselineskip}
+
+Die mit * bezeichneten Eintr"age werden als nicht ma"sgeblich
+angesehen, da sie von anderen Master Browsern erhalten wurden. F"ur
+den Client macht dies jedoch keinen Unterschied. Nur der LMB darf
+diese Eintr"age selbstverst"andlich beim n"achsten Abgleich nicht an
+den DMB als seine eigenen zur"uckmelden.
+
+Zu diesem Zeitpunkt werden Benutzer in den Subnetzen 1 und 2, die die
+Netzwerkumgebung ansehen, die Server in beiden Subnetzen sehen,
+Benutzer im Subnetz 3 sehen immer noch nur die Server in ihrem eigenen
+Subnetz.
+
+Der lokale Master Browser im Subnetz 3 (\nbname{N3D}) macht nun exakt
+das gleiche wie \nbname{N2B}. Wenn er die Browse Listen mit dem Domain
+Master Browser (\nbname{N1B}) abgeglichen hat, bekommt er sowohl die
+Server in Subnetz 1, als auch die im Subnetz 2. Nachdem sich
+\nbname{N3D} mit \nbname{N1C} synchronisiert hat und umgekehrt, sehen
+die Browse Listen folgenderma"sen aus:
+
+\vspace{\baselineskip}
+\[\begin{tabular}{|c|c|l|}
+\hline
+Netz & LMB &  Liste \\ \hline \hline
+1 & \nbname{N1C} & \nbname{N1A}, \nbname{N1B}, \nbname{N1C}, \nbname{N1D}\\
+  & & \nbname{N2A*}, \nbname{N2B*}, \nbname{N2C*}, \nbname{N2D*}\\
+  & & \nbname{N3A*}, \nbname{N3B*}, \nbname{N3C*}, \nbname{N3D*}\\
+\hline
+2 & \nbname{N2B} & \nbname{N2A}, \nbname{N2B}, \nbname{N2C}, \nbname{N2D}\\
+  & & \nbname{N1A*}, \nbname{N1B*}, \nbname{N1C*}, \nbname{N1D*}\\
+\hline
+3 & \nbname{N3D} & \nbname{N3A}, \nbname{N3B}, \nbname{N3C}, \nbname{N3D}\\
+  & & \nbname{N1A*}, \nbname{N1B*}, \nbname{N1C*}, \nbname{N1D*}\\
+  & & \nbname{N2A*}, \nbname{N2B*}, \nbname{N2C*}, \nbname{N2D*}\\
+\hline
+\end{tabular}\]
+\vspace{\baselineskip}
+
+Jetzt sehen Benutzer in den Subnetzen 1 und 3 alle Server in allen
+Subnetzen, Benutzer im Subnetz 2 sehen jedoch immer noch nur die
+Server von Subnetz 1 und 2, nicht jedoch die im Subnetz 3.
+
+Zum guten Schlu"s wird sich der lokale Master Browser im Subnetz 2
+(\nbname{N2B}) erneut mit dem Domain Master Browser abstimmen, und die
+fehlenden Servereintr"age bekommen. Endlich sehen die Browse Listen
+als stabiler Zustand so aus:
+
+\vspace{\baselineskip}
+\[\begin{tabular}{|c|c|l|}
+\hline
+Netz & LMB &  Liste \\ \hline \hline
+1 & \nbname{N1C} & \nbname{N1A}, \nbname{N1B}, \nbname{N1C}, \nbname{N1D}\\
+  & & \nbname{N2A*}, \nbname{N2B*}, \nbname{N2C*}, \nbname{N2D*}\\
+  & & \nbname{N3A*}, \nbname{N3B*}, \nbname{N3C*}, \nbname{N3D*}\\
+\hline
+2 & \nbname{N2B} & \nbname{N2A}, \nbname{N2B}, \nbname{N2C}, \nbname{N2D}\\
+  & & \nbname{N1A*}, \nbname{N1B*}, \nbname{N1C*}, \nbname{N1D*}\\
+  & & \nbname{N3A*}, \nbname{N3B*}, \nbname{N3C*}, \nbname{N3D*}\\
+\hline
+3 & \nbname{N3D} & \nbname{N3A}, \nbname{N3B}, \nbname{N3C}, \nbname{N3D}\\
+  & & \nbname{N1A*}, \nbname{N1B*}, \nbname{N1C*}, \nbname{N1D*}\\
+  & & \nbname{N2A*}, \nbname{N2B*}, \nbname{N2C*}, \nbname{N2D*}\\
+\hline
+\end{tabular}\]
+\vspace{\baselineskip}
+
+Synchronisationen zwischen dem Domain Master Browser und den Lokalen
+Master Browsern wird weiterhin auftreten, aber dies sollte den
+stabilen Zustand nur best"atigen.
+
+Wenn Router R1 oder R2 ausfallen, wird das folgende passieren:
+
+\begin{enumerate}
+\item Namen der Computer auf beiden Seiten der nicht mehr erreichbaren
+Subnetze werden f"ur 36 Minuten weiter in den Browse Listen gehalten,
+so da"s sie in der Netzwerkumgebung weiterhin erscheinen.
+
+\item Versuche, Verbindungen zu diesen Rechnern aufzubauen, werden
+scheitern, aber die Namen werden nicht von den Browse Listen entfernt
+werden.
+
+\item Wenn ein Subnetz vom WINS Server getrennt wird, wird es nur noch
+auf die lokalen Server zugreifen k"onnen, deren Namen mit lokaler
+Broadcast NetBIOS-Namensaufl"osung aufgel"ost werden k"onnen. Das ist
+vergleichbar mit der Situation, keinen Zugriff auf einen DNS Server
+mehr zu haben.
+\end{enumerate}
+
+\section{Einfache Freigaben}
+
+Der grunds"atzliche Aufbau der Datei \datei{smb.conf} wurde bereits
+auf Seite (\pageref{aufbau-smb.conf}) erw"ahnt. Bis zu diesem Punkt
+hat sich s"amtliche Konfiguration im Abschnitt \texttt{[global]}
+abgespielt, der globale Servereinstellungen beinhaltet. Wenn der
+Sambarechner nicht nur im Netz gesehen werden soll, sondern auch
+sinnvolle Dinge tun soll, mu"s man Freigaben zur Verf"ugung stellen.
+Dies tut man, indem man einfach einen neuen Abschnitt beginnt, dessen
+Name gerade nicht \texttt{[global]} ist. Um eine Freigabe vollst"andig
+zu machen, mu"s man mit dem Parameter \texttt{path} angeben, welches
+Verzeichnis man freigeben m"ochte. Eine f"ur alle Zugriffe offene
+Freigabe des Verzeichnisses \datei{/cdrom} erreicht man mit folgender
+\datei{smb.conf}:
+
+\begin{verbatim}
+[global]
+workgroup = arbeitsgruppe
+interfaces = <IP-Adresse>/<Netzmaske>
+security = share
+encrypt passwords = yes
+
+[cd]
+path = /cdrom
+guest ok = yes
+\end{verbatim}
+
+\noindent
+Damit entsteht auf dem Server eine Freigabe namens \texttt{CD}, die
+das Verzeichnis \datei{/cdrom} im Netz f"ur alle zum Lesen zur
+Verf"ugung stellt.
+
+\textbf{Achtung:} 
+Es findet hier \emph{keine} "Uberpr"ufung der Zugriffsrechte statt. Um
+diese "Uberpr"ufung zu erm"oglichen, sollte zun"achst einmal der
+Aufbau einer Verbindung zu einer Freigabe genauer beleuchtet werden.
+
+\section{SMB-Sitzungen}
+
+Wird am Client eine Verbindung zu einer Freigabe auf einem SMB-Server
+aufgebaut, so m"ussen mehrere Schritte durchlaufen werden.
+
+\subsection*{NetBIOS-Namensaufl"osung}
+
+Zu einem Rechnernamen mu"s eine IP-Adresse herausgefunden werden. Dies
+wurde in den letzten Abschnitten eingehend behandelt.
+
+\subsection*{TCP-Verbindung}
+
+Wenn die IP-Adresse klar ist, wird eine TCP-Verbindung zu Port 139 des
+Servers aufgebaut. Um vorhandene TCP-Verbindungen anzuzeigen, gibt es
+sowohl auf Unix- als auch auf Windowsrechnern das Werkzeug
+\prog{netstat}.
+
+\subsection*{NetBIOS-Sitzung}
+
+Auf einem Serverrechner arbeiten unter Umst"anden mehrere
+Applikationen, die Namen f"ur sich reserviert haben. Diese sind alle
+unter der IP-Adresse des Rechners und dem TCP-Protokoll auf Port 139
+erreichbar. Anhand des TCP-Verbindungsaufbaus ist nicht klar, welche
+Serverapplikation angesprochen werden soll. Die Unterscheidung wird
+durch den Servernamen getroffen, der in der TCP-Verbindung als erstes
+"ubertragen wird.
+
+Da"s der Servername "ubertragen wird, kann man ganz einfach mit Hilfe
+des Programms \prog{smbclient} sehen. Man versucht, sich die Liste der
+Freigaben eines realen Windowsrechners geben zu lassen, indem man
+folgendes aufruft:
+
+\verb|smbclient -L smallwin|
+
+Damit wird zun"achst eine NetBIOS-Namensanfrage ausgel"ost, und dann
+eine Verbindung zum entsprechenden Server ausgel"ost. \prog{smbclient}
+hat jedoch die M"oglichkeit, einen Server unter einem anderen Namen
+anzusprechen, indem man
+
+\verb|smbclient -L test -I ip-adresse|
+
+\noindent
+eingibt. \prog{smbclient} wird zun"achst versuchen, eine Verbindung
+zum NetBIOS-Namen \texttt{test} aufzubauen, und zwar ohne da"s eine
+NetBIOS-Namensanfrage ausgel"ost wird. Stattdessen wird die angegebene
+IP-Adresse auf Port 139 direkt angesprochen, und der Name
+\texttt{test} als Servername angegeben. Windows merkt, da"s das nicht
+stimmen kann und verweigert den Verbindungsaufbau mit einer
+Fehlermeldung. Erst im zweiten Versuch wird es \prog{smbclient}
+gelingen, eine Verbindung aufzubauen, da diese Verbindung zum
+allgemeinen Namen \texttt{*smbserver}\footnote{Das Protokoll wurde als
+Antwort auf das WebNFS von SUN in Common Internet File System umbenannt.
+Im Gegensatz zur Firma SUN, die tats"achlich das NFS-Protokoll verbessert
+hat, hat sich Microsoft die Arbeit einfacher gemacht. Der Name
+\texttt{*SMBSERVER} ist der einzige echte Unterschied, den CIFS von
+seinem Urvater SMB unterscheidet. Mit Windows 2000 werden diese
+NetBIOS-Namen beim Verbindungsaufbau gar komplett unterschlagen.
+Daf"ur ist es aber notwendig, einen weiteren Port zu reservieren, und
+zwar Port 445.} aufgebaut wird.
+
+Auch der Clientname wird in der Verbindung "ubergeben. Dies testet man
+am besten mit
+
+\verb|smbclient //win/c\$ -n blafasel| 
+
+\noindent und schaut sich
+die Verbindungstabelle auf der Windowsmaschine mit \verb|nbtstat -s|
+an.
+
+Mit dem "ubergebenen Servernamen kann man sehr nette Tricks anstellen.
+Man stelle sich vor, da"s einige Freigaben nur f"ur bestimmte
+Clientrechner sichtbar sein sollen. Dies ist mit Bordmitteln von Samba
+so nicht m"oglich. Man kann zwar mit dem Parameter \param{browseable}
+festlegen, ob bestimmte Freigaben in der Netzwerkumgebung erscheinen.
+Dieser Parameter hat aber zwei Nachteile.  Erstens sind die Freigaben nur
+unsichtbar geworden, darauf zugreifen kann man immer noch. Zweitens kann man
+Freigaben nur f"ur alle Rechner verstecken oder freigeben.
+
+Samba bietet die Option, unter zwei oder mehreren verschiedenen Namen
+in der Netzwerkumgebung zu erscheinen. Mit dem Parameter
+\param{netbios name} gibt man einen Namen f"ur den Server an.
+Zus"atzliche Namen kann man mit \param{netbios aliases} vergeben. Mit
+
+\begin{verbatim}
+netbios name = fichte
+netbios aliases = birke eiche kiefer buche
+\end{verbatim}
+
+\noindent
+handelt man sich einen ganzen Wald in der Netzwerkumgebung ein. Klickt
+man auf die einzelnen Server, sieht man "uberall die gleichen
+Freigaben und Zugriffsrechte. Nun kann man f"ur jeden dieser
+virtuellen Rechner eine eigene Konfigurationsdatei anlegen.
+Beispielsweise kann man sie \datei{/etc/smb.conf.birke},
+\datei{/etc/smb.conf.eiche} und so weiter nennen. Die Datei
+\datei{/etc/smb.conf} ist f"ur den Rechner \nbname{fichte} zust"andig
+und enth"alt neben den Einstellungen f"ur \nbname{fichte} den
+Parameter 
+
+\param{config file = /etc/smb.conf.\%L}
+
+\noindent Dabei steht
+\param{\%L} f"ur den Servernamen, unter dem Samba angesprochen wird.
+Wenn es eine passende Datei gibt, dann bewirkt der Parameter
+\param{config file}, da"s die komplette Konfiguration neu eingelesen
+wird. Existiert keine passende Datei, so wird der Parameter einfach
+ignoriert. Um nun den Zugriff nur f"ur einzelne Clients zu erlauben,
+kann bei den einzelnen virtuellen Servern mit den Parametern
+\param{hosts allow} und \param{hosts deny} der Zugriff geregelt
+werden.
+
+\subsection*{Negotiate Protocol}
+
+Die NetBIOS-Sitzung ist nun aufgebaut, und es k"onnen Daten
+"ubermittelt werden. Innerhalb dieser NetBIOS-Sitzung wird eine
+SMB-Sitzung schrittweise aufgebaut. SMB ist ein Protokoll, bei dem im
+Prinzip der Client jede Aktion durch eine Anfrage anst"o"st, und der
+Server diese beantwortet\footnote{Im Prinzip deshalb, da mit Oplocks
+  auch der Server von sich aus aktiv werden kann.}.
+
+SMB (Server Message Block) ist ein gewachsenes Protokoll. Es ist mit
+den F"ahigkeiten der Betriebssysteme gewachsen, die damit arbeiten.
+Zun"achst ist es entstanden, um die Dateisystemaufrufe der MS-DOS
+Systemschnittstelle INT 0x21 auf das Netz zu verlagern. Mit einer
+gewissen Weitsicht hat man jedoch vorausgesehen, da"s die Entwicklung
+nicht bei MS-DOS stehen bleiben w"urde, sondern sich die
+Dateisystemaufrufe "andern w"urden. Man hat im Protokoll also eine
+M"oglichkeit vorgesehen, mit der unterschiedliche Protokollvarianten
+ausgehandelt werden k"onnen. Die unterschiedlichen Protokolle
+orientieren sich immer an den F"ahigkeiten der jeweiligen
+Betriebssysteme. Beispielsweise wurde mit dem LAN Manager, der eine
+Benutzerverwaltung besitzt, das Konzept des Benutzers im Protokoll
+aufgenommen. OS/2 hat ein recht weitgehendes Konzept der
+Druckerverwaltung, das entsprechend mit Protokollerweiterungen bedacht
+wurde. Sogar f"ur XENIX gibt es einen eigenen Protokolldialekt, der
+das Unix-Zugriffsrechtekonzept im SMB-Protokoll abbildet. Diese
+Protokollvariante beherrscht nur leider kein moderner Client. Mit
+Ausnahme des ausgestorbenen XENIX-Dialektes lassen sich die Protokolle
+gut in eine Hierarchie einordnen. Sp"atere Protokolle beherrschen alle
+Aspekte der vorherigen Varianten.
+
+Die erste Anfrage, die der Client an den Server schickt, ist ein
+\defin{Negotiate Protocol Request}. In dieser Anfrage schickt der
+Client an den Server eine Liste der Protokollvarianten, die er
+beherrscht. Der Server w"ahlt nun aus dieser Liste der Protokolle eins
+aus, und schickt eine entsprechende Antwort zur"uck. Die verschiedenen
+Protokolle bauen aufeinander auf. Daher kann man mit dem Parameter
+\param{protocol} das h"ochste Protokoll festlegen, mit dem Samba
+arbeiten soll.
+
+In der Antwort auf diese erste Anfrage werden zwei weitere
+Einstellungen verschickt, die Teile des weiteren Ablaufs festlegen.
+
+Der Server entscheidet, ob er die Zugriffssteuerung auf Benutzer- oder
+auf Freigabeebene regeln m"ochte. Damit wird festgelegt, zu welchem
+Zeitpunkt der Benutzer ein Pa"swort liefern mu"s. Entweder kann es
+beim direkt folgenden \defin{Session Setup} erfolgen, oder erst beim
+\defin{Tree Connect} danach.
+
+Der Parameter \param{security} legt fest, welche Art der
+Zugriffssteuerung gew"ahlt wurde.  Mit \param{security = share} wird
+die Freigabeebene eingestellt, \param{security = user} legt die
+Clients auf die Benutzerebene fest.
+
+Sichtbar wird diese Unterscheidung in der Windowswelt nur bei Windows
+95 und Windows 98. Diese Betriebssysteme beherrschen zun"achst einmal
+nur die Zugriffssteuerung auf Freigabeebene, da sie nicht "uber eine
+Benutzerdatenbank verf"ugen.  Es ist nicht m"oglich, einzelnen
+Benutzern den Zugriff auf Freigaben zu gew"ahren oder zu
+verweigern. Um trotzdem benutzerbasiert Zugriffssteuerung zu
+erm"oglichen, mu"s ein Server angegeben werden, der f"ur Windows die
+Benutzerdatenbank pflegt. Damit k"onnen Pa"sw"orter benutzerbasiert
+"uberpr"uft werden.
+
+Weiterhin gibt der Server dem Client vor, ob Klartextpa"sw"orter
+verwendet werden sollen, oder ob die Pa"sw"orter verschl"usselt
+werden. Wenn der Server festlegt, da"s verschl"usselte Pa"sw"orter
+verwendet werden, wird zus"atzlich die Herausforderung f"ur das
+\defin{Challenge Response} Verfahren mitgeschickt.
+
+Die Entscheidung "uber Klartextpa"sw"orter mu"s also getroffen werden,
+ohne da"s der Server den Benutzernamen, der sich anmelden will,
+kennt. Es ist also nicht m"oglich, f"ur einige Benutzer
+Klartextpa"sw"orter und f"ur andere Benutzer verschl"usselte
+Pa"sw"orter zu verwenden.
+
+\subsection*{Session Setup}
+
+Nachdem die Protokollversion ausgehandelt ist, wird vom Client ein
+\defin{Session Setup} verschickt. In diesem Session Setup schickt der
+Client seinen Benutzernamen an den Server. Sofern dieser
+\param{security = user} verlangt hat, wird an dieser Stelle das
+Pa"swort mitgeschickt. Damit ist der Server in der Lage, die
+Identit"at des Benutzers festzustellen. Wenn \param{security = share}
+vereinbart wurde, dann ignoriert der Server ein hier eventuell
+mitgeschicktes Pa"swort.
+
+\subsection*{Tree Connect}
+
+Als letztes legt der Client fest, welche Freigabe er ansprechen will.
+Der entsprechende Aufruf hei"st \defin{Tree Connect}. Sofern
+\param{security = share} vereinbart wurde, wird an dieser Stelle das
+Pa"swort "uberpr"uft. Der Benutzername kann in diesem Fall nicht zur
+Zugriffsregelung verwendet werden. Dieser wurde unter Umst"anden gar
+nicht "ubermittelt, da der Client den Session Setup komplett auslassen
+darf. Andererseits hat er bei einem durchgef"uhrten Session Setup kein
+Pa"swort angeben m"ussen, anhand dessen die Identit"at des Benutzers
+zweifelsfrei h"atte festgestellt werden k"onnen.
+
+\section{Zugriffsrechte}
+
+Bei Windows NT kann man mit zwei unterschiedlichen Mechanismen Rechte
+vergeben. An einer Freigabe kann man "uber Schreib- und Lesezugriff
+entscheiden. Innerhalb des Dateisystems kann man detailiert Rechte
+vergeben.
+
+Ist bei Samba \param{security = user} gesetzt, so hat der Server die
+M"oglichkeit, anhand des angemeldeten Benutzers Zugriffsrechte zu
+vergeben oder zu verweigern. Wenn bez"uglich der Zugriffsrechte bei
+einer Freigabe nichts gesagt wird, hat jeder korrekt angemeldete
+Benutzer Leserecht. Man kann auch Gastbenutzern Leserecht geben, indem
+man \param{guest ok = yes} setzt.
+
+Mit den Optionen zur Rechtevergabe an Freigaben hat man die
+M"oglichkeit, einzelnen Benutzern und ganzen Unixgruppen Rechte zu
+geben oder zu nehmen. Die M"oglichkeiten sind hier deutlich weitergehend 
+als die Semantik, die Unix mit den Rechtemasken f"ur den
+Dateibesitzer, die besitzende Gruppe und den Rest der Welt bereit
+stellt. Von den m"oglichen Anwendungen sollen hier drei h"aufig
+ben"otigte F"alle dargestellt werden.
+
+\begin{itemize}
+\item {\bf \emph{Alle} Benutzer haben gleichen Zugriff}
+
+\begin{verbatim}
+[projekt]
+path = /data/projekt
+\end{verbatim}
+
+Bei dieser Freigabe bekommen alle Benutzer, die sich mit Namen und
+Pa"swort am Server angemeldet haben, \emph{Leserecht} auf die
+Freigabe. Schreibrecht vergibt man, indem man den Parameter
+\param{writeable = yes} setzt:
+
+\begin{verbatim}
+[projekt]
+path = /data/projekt
+writeable = yes
+\end{verbatim}
+
+\item {\bf \emph{Einige} Benutzer haben gleichen Zugriff}
+
+Will man den Zugriff auf einige Benutzer einschr"anken, erstellt man
+eine Liste \param{valid users} auf:
+
+\begin{verbatim}
+[projekt]
+path = /data/projekt
+valid users = mueller, meier
+\end{verbatim}
+
+Zu dieser Freigabe haben die Benutzer mueller und meier
+Lesezugriff. Sollen diese Benutzer Schreibzugriff bekommen, so ist wie
+im vorangegangenen Beispiel der Parameter \param{writeable = yes} zu
+setzen:
+
+\begin{verbatim}
+[projekt]
+path = /data/projekt
+valid users = mueller, meier
+writeable = yes
+\end{verbatim}
+
+F"ur den Parameter \param{valid users} spielt der Benutzer root keine
+besondere Rolle. Das hei"st, da"s er auf die Freigabe \param{projekt}
+keinen Zugriff hat. Soll er Zugriff bekommen, mu"s man ihn wie jeden
+anderen Benutzer in die Liste \param{valid users} mit aufnehmen.
+
+Der Parameter \param{valid users} gibt die M"oglichkeit, ganze
+Unixgruppen in den Zugriff mit aufzunehmen. Um dies zu erreichen, mu"s
+man das at-Zeichen voranstellen:
+
+\begin{verbatim}
+[projekt]
+path = /data/projekt
+valid users = root, @users
+writeable = yes
+\end{verbatim}
+
+Mit dieser Einstellung haben alle Benutzer, die in der Unixgruppe
+users sind, Schreibzugriff auf die Freigabe. Zus"atzlich kann der
+Benutzer root schreiben.
+
+\item {\bf Einige Benutzer haben Leserecht, andere Schreibrecht}
+
+Will man differenziert Rechte vergeben, so mu"s man s"amtliche
+Benutzer, die "uberhaupt Zugriff auf die Freigabe bekommen sollen, in
+die Liste \param{valid users} aufnehmen, und mit \param{writeable =
+no} nur Leserechte vergeben. Die Benutzer, die "uber diese
+Standardeinstellung hinaus Schreibrecht bekommen sollen, m"ussen in
+die \param{write list} aufgenommen werden.
+
+\begin{verbatim}
+[projekt]
+path = /data/projekt
+valid users = @users, @admins
+writeable = no
+write list = @admins
+\end{verbatim}
+
+Mit diesen Einstellungen haben die Benutzer der Gruppe users
+Leserecht, und die Benutzer der Gruppe admins haben Schreibrecht.
+
+\end{itemize}
+
+\section{Unix-Zugriffsrechte}
+
+Unter Windows NT gibt es zwei M"oglichkeiten, Zugriff auf Dateien zu
+gew"ahren. "Uber eine Freigabe kann ein Lese- oder ein Schreibrecht
+vergeben werden. Im zweiten Schritt k"onnen dann "uber eine
+Rechtevergabe im Dateisystem weitere Rechte vergeben werden. Samba
+regelt die Zugriffskontrolle ebenfalls in zwei Schritten. Die
+freigabebezogenen Rechte werden "uber Parameter wie \param{valid
+users} und \param{write ok} geregelt. Die Zugriffsrechte innerhalb des
+Dateisystems regelt Samba nicht selbst, sondern verl"a"st sich
+hierf"ur auf das darunterliegende Betriebssystem Unix.
+
+Zwischen Unix und DOS bestehen gro"se Unterschiede. DOS und alle seine
+Nachfolger sind Einzelbenutzersysteme, Unix ist von Anfang an als
+Multiusersystem entworfen worden. Diese Unterschiede werden besonders
+deutlich, wenn man die Attribute betrachtet, die auf Dateien vergeben
+werden. DOS kennt vier Attribute:
+
+\begin{description}
+\item[Read-Only] Der Inhalt dieser Datei kann nur gelesen, aber nicht
+geschrieben werden. Die Datei kann nicht gel"oscht werden.
+\item[System] Diese Datei ist f"ur spezielle Betriebssystemzwecke
+vorgesehen.
+\item[Hidden] Diese Datei wird mit dem Kommando 'DIR' nicht angezeigt.
+\item[Archiv] Das Archivbit wird bei jedem Schreibzugriff gesetzt.
+Backupprogrammen ist es freigestellt, dieses Bit zur"uckzusetzen.
+Damit kann eine inkrementelle Sicherung erm"oglicht werden.
+\end{description}
+
+Diese Bits k"onnen vom Benutzer frei gesetzt und wieder zur"uckgesetzt
+werden. Sie bieten also keinen echten Zugriffsschutz, sondern nur eine
+gewisse Sicherung gegen Fehlbedienung.
+
+Unix f"uhrt mit jeder Datei einen Satz von Zugriffsrechten mit. Diese
+sind aufgeteilt in 3 Gruppen von Benutzern: Der Dateibesitzer, die
+besitzende Gruppe und alle anderen. Jeder Gruppe k"onnen 3
+Rechte zugeteilt werden: Lesen, Schreiben und ausf"uhren.
+
+Unter DOS werden Ausf"uhrungsrechte nicht verwendet. Sie stehen f"ur
+Samba zur Verf"ugung, um die DOS-Attribute im Unix-Dateisystem
+abzubilden. Das Schreibschutzbit unter DOS hat mit dem Schreibrecht
+des Dateibesitzers unter Unix eine Entsprechung. Bis auf die Umsetzung
+des Schreibschutzbits kann die Umsetzung der Attribute unter Samba mit
+den entsprechenden Parametern \param{map <xxx>} gesteuert werden,
+wobei das Archivbit ohne Zusatzangabe umgesetzt wird, die anderen
+beiden Attribute nicht. Die Attributumsetzung erfolgt anhand der
+folgenden Tabelle:
+
+\[ \begin{tabular}{|l|l|c|l|l|}
+\hline
+DOS-Attribut & Unix-Recht & Maske & Parameter & Standard \\
+\hline\hline
+Schreibschutz & Schreibrecht Besitzer & 200 & - & immer \\
+\hline
+Archiv & Ausf"uhrung Besitzer & 100 & \param{map archive} & \param{yes} \\
+\hline
+System & Ausf"uhrung Gruppe & 010 & \param{map system} & \param{no} \\
+\hline
+Versteckt & Ausf"uhrung Andere & 001 & \param{map hidden} & \param{no} \\
+\hline
+\end{tabular} \]
+
+Samba mu"s nun diese beiden Dateiattribute ineinander "uberf"uhren.
+Samba mu"s neu erstellten Dateien Unixrechte zuordnen.  Wird eine
+Datei neu erstellt, dann gibt der Client dem Server die DOS-Attribute
+mit, mit der er die Datei erstellt haben m"ochte. Daraus formt Samba
+einen Satz von Unix-Zugriffsrechten. Diese Rechte werden vom Parameter
+\param{create mask} eingeschr"ankt. Die Standardvorgabe f"ur die
+\param{create mask} ist gleich \param{744}, was der Rechtemaske
+\param{rwxr--r--} entspricht. Der Dateieigent"umer hat Schreib- und
+Leserecht, alle anderen haben reines Leserecht. Samba schr"ankt die
+Rechte ein, indem der gew"unschte Satz an Rechten mit einer logischen
+UND-Operation mit der \param{create mask} verkn"upft wird. Nur die
+Rechte, die in der \param{create mask} gesetzt sind, k"onnen
+m"oglicherweise in der neu erzeugten Datei auftauchen. In einem
+weiteren Schritt setzt Samba explizit gew"unschte Zugriffsrechte
+anhand des Parameters \param{force create mode}, dessen Standardwert
+auf \param{000} steht. Dies geschieht durch eine ODER-Verkn"upfung mit
+diesem Wert.
+
+Diese Zusammenh"ange werden an einem Beispiel deutlicher. Es kann
+gew"unscht sein, da"s auf neu erstellten Dateien nur der
+Dateibesitzer und die Gruppe Leserecht haben sollen. Der Rest der Welt
+soll diese Dateien nicht lesen k"onnen. Das wird dadurch erreicht,
+da"s man die \param{create mask = 740} setzt, also das Leserecht f"ur
+den Rest der Welt ausmaskiert. Es kann dar"uber hinaus gew"unscht
+sein, da"s die besitztende Gruppe ein Schreibrecht einger"aumt
+bekommt. Das kann man durch \param{force create mode = 020} erreichen.
+Tabellarisch dargestellt hei"st dies:
+
+\[ \begin{tabular}{|l|l||c|l|}
+\hline
+Wunsch & & & \texttt{rw-r-{}-r-{}-} \\
+\hline
+create mask & 740 & UND & \texttt{rw-r-{}-{}-{}-{}-} \\
+\hline
+\hline
+& & & \texttt{rw-r-{}-{}-{}-{}-} \\
+\hline
+force create mode & 020 & ODER & \texttt{-{}-{}-{}-w-{}-{}-{}-} \\
+\hline
+\hline
+Ergebnis & & & \texttt{rw-rw-{}-{}-{}-} \\
+\hline
+\end{tabular} \]
+
+Die Ausf"uhrungsrechte auf Dateien werden unter DOS nicht verwendet,
+sie k"onnen also verwendet werden, um DOS-Attribute im
+Unix-Dateisystem abzulegen. Ausf"uhrungsrechte auf Dateiverzeichnissen
+wirken sich jedoch auf das Verhalten von Samba aus, da durch sie der
+Zugriff zu den Verzeichnissen geregelt wird.  Daher kann es
+w"unschenswert sein, da"s die Rechtezuweisung auf Dateien und
+Verzeichnissen unterschiedlich geregelt wird. Die Parameter
+\param{create mask} und \param{force create mode} wirken daher nur auf
+neu angelegte Dateien.  F"ur Verzeichnisse sind die Parameter
+\param{directory mask} und \param{force directory mode}
+verantwortlich. Der Vorgabewert f"ur \param{directory mask} ist
+hierbei \param{755}, um den Zutritt f"ur die Gruppe und den Rest der
+Welt zu erm"oglichen, die Vorgabe f"ur \param{force directory mode}
+besetzt mit dem Wert \param{000} kein zus"atzliches Recht.
+
+\section{Beispiel: Projektverzeichnisse}
+
+Folgendes Problem stellt sich bei der Migration von Novell zu Samba
+recht h"aufig. Unter Novell kann man anhand von
+Gruppenzugeh"origkeiten den Zugriff auf Verzeichnisse regeln. Dies ist
+unter Samba anhand von Unixrechten ebenfalls m"oglich. Was Unix leider
+nicht zur Verf"ugung stellt, ist die M"oglichkeit, Verzeichnisse vor
+Benutzern zu verstecken. Ein Benutzer sieht grunds"atzlich alle
+Verzeichnisse, bekommt aber bei vielen dieser Verzeichnisse die
+Meldung, da"s der Zugriff verweigert wurde. Wenn es jetzt anhand der
+Gruppenzugeh"origkeit des Benutzers m"oglich w"are, nur die
+Verzeichnisse anzuzeigen, auf die er tats"achlich Zugriff hat,
+k"onnten die Verzeichnisse deutlich "ubersichtlicher werden.
+
+Die Flexibilit"at von Samba erm"oglicht es, diese von Unix
+vorgegeben Beschr"ankung zu umgehen, und zwar unter Benutzung von
+Skripten, die vor dem Verbinden mit einer Freigabe ausgef"uhrt werden.
+
+Folgendes Szenario wird vorausgesetzt: Jeder Benutzer ist in mehrere
+Gruppen eingeteilt, die jeweils Projekte, Arbeitsgruppen oder
+Abteilungen darstellen k"onnen. Jede dieser Gruppen hat unter
+\datei{/data/groups} ein eigenes Verzeichnis, auf das sie schreiben
+darf. Die einzelnen Verzeichnisse haben das Set Group ID Bit gesetzt,
+damit die neu angelegten Dateien den jeweiligen Gruppen angeh"oren.
+
+Als Beispiel gebe es die drei Gruppen \param{edv}, \param{fibu} und
+\param{verkauf}. Das Gruppenverzeichnis \datei{/data/groups} sieht
+folgenderma"sen aus:
+
+{\small\begin{verbatim}
+root@server:/data/groups> ls -l
+total 12
+drwxrws---   2 root     edv          4096 Jan 31 06:43 edv
+drwxrws---   2 root     fibu         4096 Jan 31 06:43 fibu
+drwxrws---   2 root     verkauf      4096 Jan 31 06:43 verkauf
+root@server:/data/groups>
+\end{verbatim}
+}
+
+Die korrekten Rechte erreicht man unter Unix durch:
+
+{\small\begin{verbatim}
+root@server:/root> mkdir /data/groups/edv
+root@server:/root> chgrp edv /data/groups/edv
+root@server:/root> chmod 2770 /data/groups/edv
+\end{verbatim}
+}
+
+Eine Freigabe, die jedem Benutzer anhand seiner Rechte hierauf Zugriff
+gew"ahrt, kann folgenderma"sen aussehen:
+
+{\small\begin{verbatim}
+[allgroups]
+path = /data/groups
+writeable = yes
+create mode = 740
+directory mode = 750
+force create mode = 020
+force directory mode = 020
+\end{verbatim}
+}
+
+Zu beachten ist hier, da"s keine zus"atzlichen Einschr"ankungen anhand
+von \param{valid users} notwendig sind, da der Zugriff durch die
+Unixrechte beschr"ankt ist. Die Parameter \param{create mask} und
+\param{directory mask} sind nicht strikt notwendig, da bereits auf der
+Ebene \datei{/data/share} die Benutzer abgewiesen werden. Die
+Parameter \datei{force create mode} und \param{force directory mode}
+sind hingegen notwendig, da ohne sie neu angelegte Dateien nicht die
+notwendigen Gruppenschreibrechte erhalten w"urden, die zum gemeinsamen
+Zugriff notwendig sind.
+
+Diese Freigabe erf"ullt funktional genau die Anforderungen, da"s
+jeder in die Verzeichnisse schreiben darf, f"ur die er die
+Gruppenmitgliedschaft hat. Der Nachteil an diesem Verfahren ist, da"s
+er alle anderen Verzeichnisse sieht, was bei gro"sen Servern mit
+vielen Gruppen recht un"ubersichtlich werden kann.
+
+Die preexec-Skripte von Samba erm"oglichen die "ubersichtliche
+Darstellung der Gruppenstruktur. Ein preexec-Skript wird ausgef"uhrt,
+bevor der Benutzer tats"achlich mit der Freigabe verbunden wird.
+
+{\small\begin{verbatim}
+[gruppen]
+path = /data/users/%U
+root preexec = /usr/local/bin/mklinks %U
+writeable = yes
+\end{verbatim}
+}
+
+Die Datei \datei{mklinks} hat folgenden Inhalt:
+
+{\small\begin{verbatim}
+#!/bin/sh
+umask 022
+cd /data/users
+rm -rf "$1"
+mkdir "$1"
+cd "$1"
+for i in `groups $1`
+do
+        ln -s /data/groups/$i .
+done
+\end{verbatim}
+}
+    
+Beim Verbinden an die Freigabe wird das Verzeichnis
+\datei{/data/users/username} frisch erstellt, das anhand der
+Gruppenzugeh"origkeit des Benutzers eine Liste von symbolischen
+Links erstellt, die auf die eigentlichen Gruppenverzeichnisse
+verweisen. Damit bekommt er nur die Verzeichnisse im Explorer
+angezeigt, auf die er tats"achlich Zugriff hat. Durch die Angabe
+\param{path = /data/users/\%U} ist zudem sichergestellt, da"s die
+Freigabe f"ur alle Benutzer gleich hei"st, aber f"ur jeden
+Benutzer auf ein eigenes Verzeichnis verweist. Das Skript wird in
+diesem Beispiel als \param{root preexec} ausgef"uhrt, um den
+Verwaltungsaufwand beim Anlegen neuer Benutzer zu minimieren. Mit
+einem reinen \param{preexec} ohne Rootrechte w"are es notwendig,
+f"ur jeden Benutzer unterhalb von \param{/data/users} ein eigenes
+Verzeichnis mit den notwendigen Rechten anzulegen. Alternativ
+k"onnte man das Verzeichnis mit der Gruppenliste im
+Heimatverzeichnis des Benutzers anlegen, wobei dabei Zweifel
+bez"uglich der "Ubersichtlichkeit angebracht sind. Ein weiteres
+Argument, das Skript unter Rootrechten auszuf"uhren, ist die
+Betriebssicherheit. Ohne dies w"are es dem Benutzer m"oglich, sich
+vollst"andig von einem Gruppenverzeichnis auszuschlie"sen indem er
+das gesamte Verzeichnis inklusive symbolischem Link l"oscht. Mit
+der dargestellten Version geh"ort das Verzeichnis mit den
+symbolischen Links dem Benutzer root, und Fehlbedienungen in
+dieser Ebene sind ausgschlossen.
+
+Wenn man die Freigabe \param{[allgroups]} auf \param{[browseable =
+  no]} setzt, so hat man maximale "Ubersichtlichkeit bei vollem
+Zugriff auf s"amtliche Gruppenverzeichnisse durch den Administrator
+gegeben.
+
+"Andern sich die Gruppenzugeh"origkeiten eines Benutzers, so kann
+er einfach durch ein Neuverbinden an die Freigabe die neue Sicht auf
+die Verzeichnisstruktur bekommen. Dieses Neuverbinden kann erzwungen
+werden, indem der richtige Serverprozess get"otet wird. Dieser kann
+anhand des Programms \prog{smbstatus} leicht herausgefunden werden.
+
+\section{Pa"sw"orter}
+\label{passwoerter}
+
+Protokolle der IP-Welt wie telnet, ftp und pop3 "ubertragen die
+Pa"sw"orter zur Benutzerauthentifizierung im Klartext. Damit kann
+jeder, der den Netzverkehr abh"oren kann, s"amtliche Pa"sw"orter
+mitschreiben. Daf"ur existieren fertige Programme, die Benutzernamen
+und dazugeh"orige Pa"sw"orter ausgeben. In der Unixwelt wurde dies
+zun"achst nicht als problematisch angesehen, da zum Zugriff auf das
+Netz Administratorrechte oder physikalischer Zugriff zum Netz
+notwendig sind. Beides war historisch oft nicht gegeben, so da"s das
+Risiko als relativ gering eingesch"atzt wurde. Mit dem Aufkommen von
+DOS und Ethernet hat jeder Benutzer Administratorrechte, kann also den
+Netzverkehr mitschneiden.
+
+Benutzerauthentifizierung mu"s vor allem eins leisten: Der Benutzer
+mu"s beweisen, da"s er sein Pa"swort kennt. Ein
+Authentifizierungsprotokoll kann es dabei erm"oglichen, da"s das
+Pa"swort nicht "ubertragen werden mu"s.
+
+Im SMB-Protokoll wird zur Authentifizierung ein Challenge-Response
+Verfahren eingesetzt. Der Server verschickt an den Client eine
+Zufallszahl, die sogenannte Herausforderung. Der Client kennt das
+Benutzerpa"swort, und verschl"usselt die Herausforderung mit dem
+Pa"swort als Schl"ussel. Diesen verschl"usselten Wert verschickt der
+Client anstelle des Pa"sworts. Der Server kennt das Benutzerpa"swort
+ebenfalls, und kann den versch"usselten Wert entschl"usseln. Entsteht
+bei der Entschl"usselung wieder die Herausforderung, so hat der
+Benutzer die Herausforderung offensichtlich mit dem korrekten Pa"swort
+verschl"usselt. Kommt etwas anderes heraus, war das Pa"swort nicht
+richtig.
+
+\begin{figure}\[
+\begin{pspicture}(11.5,6.5)
+%\psgrid[subgriddiv=1,griddots=10]
+\psframe(11.5,6.5)
+\psline(3,6.5)(3,0)
+\psline(7,6.5)(7,0)
+\psframe[fillstyle=solid,fillcolor=lightgray](3,0)(7,6.5)
+\rput(2,6){{\sffamily\bfseries Client}}
+\rput(5,6){{\sffamily\bfseries Zuh"orer}}
+\rput(8,6){{\sffamily\bfseries Server}}
+\psline(0,5.7)(11.5,5.7)
+
+\psline{->}(2.5,5)(7.5,5)
+\rput(5,5.2){Negotiate Protocol}
+
+\rput[lB](8,4.5){H: Herausforderung}
+\psline{->}(7.5,4.5)(2.5,4.5)
+\rput(5,4.3){{\bfseries H}}
+
+\psline{->}(2.5,3)(7.5,3)
+\rput(5,3.2){Session Setup}
+\rput(5,2.8){{\bfseries Username, PW(H)}}
+\rput[lB](0.3,3.9){Herausforderung}
+\rput[lB](0.3,3.5){Username}
+\rput[lB](0.3,3.1){Pa"swort}
+
+\rput[lB](8,2.9){Username}
+\rput[lB](8.2,2.5){$\Rightarrow$ Pa"swort}
+\rput[lB](8.2,2.1){entschl"ussle PW(H)}
+
+\pscurve{->}(5.8,2.7)(8,1.8)(9.5,1.8)(10,2)
+\rput[tl](9.8,1.9){$\Rightarrow$ H}
+
+\pscurve{<->}(10.5,1.6)(10.8,1.5)(11.3,2)(11,3)(8.3,4.4)
+\rput[t](10.8,1.4){=?}
+
+\psline{->}(7.5,0.8)(2.5,0.8)
+\rput(5,0.6){{\bfseries Ok?}}
+\end{pspicture}\]
+\caption{Challenge-Response Verfahren}
+\end{figure}
+
+Ein Zuh"orer verf"ugt
+"uber die Herausforderung und den verschl"usselten Wert. Mit
+diesen beiden Werten k"onnte er einen Known Plaintext Angriff gegen
+die Verschl"usselung starten. Das hei"st, es mu"s ein
+Verschl"uselungsalgorithmus gew"ahlt werden, der gegen einen solchen
+Angriff immun ist. Er kann keine Replay Attacke starten, da er bei
+jedem neuen Verbindungsaubau eine neue Herausforderung bekommt, die er
+verschl"ussen mu"s.
+
+Windows NT verh"alt sich diesbez"uglich vern"unftig. Windows 95 denkt
+sich jedoch nur alle 15 Minuten eine neue Herausforderung aus. Das
+hei"st, da"s jemand nur einen Verbindungsaufbau mitschneiden mu"s, und
+sich sofort danach mit der gleichen Benutzerkennung bei der gleichen
+Maschine anmelden kann. Man kann sich
+fast sicher darauf verlassen, die gleiche Herausforderung zu
+bekommen, und mit der mitgeschnittenen Antwort Zugriff zu erhalten.
+Dies gilt selbstverst"andlich nur f"ur die Zugriffe, bei denen Windows
+95 als Server benutzt wird. Und wer tut das schon?
+
+Dieses Verfahren setzt voraus, da"s der Server "uber das
+Benutzerpa"swort im Klartext verf"ugt. Unter Unix tut er das nicht,
+sondern der Server kennt nur eine zerhackte Version des Pa"swortes,
+den Wert aus der Datei \datei{/etc/shadow}.
+
+Eine Hashfunktion, wie sie unter Unix eingesetzt wird, hat drei
+Eigenschaften.
+
+\begin{enumerate}
+
+\item Sie ist leicht zu berechnen. Dies ist notwendig, damit die
+Pa"swort"uberpr"ufung nicht zu lange dauert.
+
+\item Sie ist nur sehr schwer umkehrbar. Das hei"st, aus dem zerhackten 
+Pa"swort
+ist das Klartextpa"swort nicht berechenbar. Als Beispiel f"ur eine
+solche Einwegfunktion soll hier die Multiplikation
+herhalten. 98453*34761=3422324733 ist relativ einfach zu
+berechnen. Da"s die Zahl 3422324733 aus den beiden Ursprungszahlen
+entstanden ist, ist schon sehr viel schwieriger herauszufinden. Es
+gibt Verfahren, mit denen der R"uckweg ausgeschlossen ist\footnote{Wie
+"uberall in der Kryptographie gilt dies auch nur so lange, bis jemand
+den R"uckweg gefunden hat.}.
+
+Mit dieser Eigenschaft war es zu rechtfertigen, da"s in den fr"uhen
+Tagen von Unix die Hashwerte der Pa"sw"orter f"ur alle Benutzer lesbar
+waren, da niemand daraus etwas ableiten konnte. Mit dem "Uberflu"s an
+Rechenleistung kann man aber sogenannte crack-Programme verwenden, die
+die erste Eigenschaft der Hashfunktion ausnutzen: Sie probieren
+einfach tausende von Pa"sw"ortern pro Sekunde aus. Schlechte
+Pa"sw"orter k"onnen so sehr schnell gefunden werden. Daher hat man die
+Pa"sw"orter in die nicht allgemein lesbare Datei \datei{/etc/shadow}
+ausgelagert.
+
+\item Zwei verschiedene Pa"sw"orter f"uhren zu zwei verschiedenen
+Hashwerten. Damit kann das Loginprogramm ausreichend sicher sein, da"s
+ein korrekter Hashwert aus dem korrekten Pa"swort entstanden ist.
+
+\end{enumerate}
+
+Authentifizierung unter Unix setzt voraus, da"s der Client dem Server
+das Klartextpa"swort pr"asentiert. Der Server kann daraus den Hashwert
+berechnen, und mit dem gespeicherten Wert vergleichen. Leider verf"ugt
+er nicht "uber das Klartextpa"swort des Benutzers, um das
+Challenge-Response Verfahren durchf"uhren zu k"onnen. Daher mu"s unter
+Samba f"ur die Pa"swortversch"usselung eine zweite Pa"swortdatenbank
+gepflegt werden, die Datei \datei{smbpasswd}.
+
+Auch in der Datei \datei{smbpasswd} stehen keine
+Klartextpa"sw"orter. Bevor die Herausforderung mit dem Pa"swort
+verschl"usselt wird, wird das Pa"swort unter Windows ebenfalls durch
+eine Hashfunktion geschickt. Von dieser Hashfunktion gibt es zwei
+Varianten, die beide nicht mit den unter Unix verwendeten Funktionen
+"ubereinstimmen. Das hei"st, da"s man mit den dort enthaltenen Werten
+so direkt nicht mehr anfangen kann als mit den Werten aus der Datei
+\datei{/etc/shadow} unter Unix, denn wenn man sie als Pa"swort
+eingeben w"urde, w"urde Windows sofort wieder den Hash darauf anwenden,
+und einen anderen, also falschen Wert daraus errechnen. Das Programm
+\prog{smbclient} mu"s diese Operation ebenfalls durchf"uhren, nur hat
+man hierzu den Quellcode und kann die entsprechenden Stellen
+auskommentieren. So hat man die M"oglichkeit, sich anhand der Werte in
+der \datei{smbpasswd} ohne Einsatz von crack bei einem NT-Rechner
+anzumelden.
+
+Alles nicht dramatisch, sagt Microsoft. Das "Aquivalent zur Datei
+\datei{smbpasswd} liegt unter NT verschl"usselt vor. Diese
+Verschl"usselung mu"s jedoch reversibel sein, um das
+Challenge-Response Verfahren durchf"uhren zu k"onnen. Ein Teil der
+Sicherheitsargumentation liegt darin, da"s dieses
+Verschl"usselungsverfahren nicht offengelegt wurde. Das Verfahren war
+solange geheim, bis Jeremy Allison das Programm \prog{pwdump}
+ver"offentlicht hat. Dieses Programm extrahiert aus der
+Benutzerdatenbank von NT eine Datei, die direkt als \datei{smbpasswd}
+verwendet werden kann\footnote{Allerdings nur f"ur Samba 1.9, zu 2.0
+  hin wurde das Format ge"andert. Es gibt in Samba 2.0 aber ein
+  Konvertierungsskript.}.
+
+Das hei"st, der Administrator unter NT verf"ugt direkt "uber die
+Pa"sw"orter aller Benutzer oder zumindest "uber etwas Gleichwertiges.
+Damit hat er automatisch die M"oglichkeit, sich bei fremden Systemen
+anzumelden, sofern dort das Pa"swort gleich ist. Bei Unix kann sich
+der Administrator zwar in die Identit"at jedes Benutzers versetzen.
+Dies bleibt aber auf das lokale System beschr"ankt, da er das Pa"swort
+des Benutzers nicht kennt.
+
+Sollte ein neugieriger Administrator einmal an den tats"achlichen
+Pa"sw"orten seiner Benutzer interessiert sein, dann macht NT es ihm
+deutlich einfacher als Unix dies tut. Unix verwendet sogenannte
+versalzene Pa"sw"orter. Wenn ein Pa"swort ge"andert wird, dann wird
+ein Zufallswert berechnet, dem Pa"swort hinzugef"ugt und dann die
+Hashfunktion durchgef"uhrt. Der Zufallswert wird der Datei
+\datei{/etc/shadow} im Klartext hinzugef"ugt, damit die "Uberpr"ufung
+die gleichen Operationen durchf"uhren kann. So kann man keine Tabelle
+von Pa"sw"ortern und den zugeh"origen Hashwerten anlegen. Man kann
+auch nicht erkennen, wenn zwei Benutzer das gleiche Pa"swort
+verwenden. Windows NT verwendet dieses Verfahren nicht.
+
+Aus Kompatibilit"atsgr"unden mu"s NT auch noch zus"atzlich einen sehr
+schlechten Hashwert mitf"uhren. Bei alten Windowsversionen konnte das
+Pa"swort bis zu 14 Zeichen lang sein. War es k"urzer, wurde es mit
+Leerzeichen aufgef"ullt. Dann wurde mit den ersten 7 Zeichen ein
+Hashwert berechnet, und dann mit den zweiten 7 Zeichen. Das hei"st, es
+sind sofort alle Pa"sw"orter erkennbar, die weniger als 7 Zeichen
+haben, da die zweite H"alfte des Hashwertes immer gleich ist.
+
+\section{Druckfreigaben}
+
+Um Drucker unter Samba zur Verf"ugung zu stellen, m"ussen diese von
+Unix aus ansprechbar sein. Unter Linux mit einem BSD-kompatiblen
+Drucksystem geschieht dies durch Eintr"age in der Datei
+\datei{/etc/printcap}. Alle Drucker, die dort definiert sind, kann man
+als Netzwerkdrucker f"ur Windowsclients freigeben.
+
+Unter Linux ist die Frage der Druckertreiber noch nicht
+zufriedenstellend gel"ost. Druckertreiber unter Windows w"urde man
+unter Linux nicht als solche bezeichnen. In der Linuxwelt sind Treiber
+Softwaremodule, die direkt Hardware wie Netzwerkkarten oder den
+parallelen Port ansprechen. Druckertreiber im Sinne von Windows sind
+unter Linux sogenannte Filter, die Druckdaten in ein f"ur den Drucker
+akzeptables Format aufbereiten. Das einheitliche Druckformat unter
+Linux ist Postscript, das mit dem Programm Ghostscript in viele
+druckereigene Formate umgewandelt werden kann. Druckertreiber unter
+Windows gehen vom Windows Metafile-Format aus, und wandeln dies
+entsprechend um. Das Windows Metafile-Format enth"alt Aufrufe an die
+Graphische Komponente von Windows, das GDI.
+
+Wenn man einen Drucker, der "uber Unix angesprochen wird, von Windows
+aus nutzen m"ochte, mu"s man planen, wo die Aufbereitung in das
+druckereigene Format geschehen soll. Zwei Wege sind denkbar.
+
+\begin{itemize}
+\item Auf den Arbeitspl"atzen wird ein generischer Postscripttreiber
+  installiert. Die Clients m"ussen nicht wissen, welches Druckermodell
+  sich hinter einer Freigabe verbirgt.  Die Umwandlung findet auf dem
+  Druckerserver mittels \prog{ghostscript} statt.
+\item Der Druckertreiber reicht die Daten weiter, ohne sie weiter zu
+  behandeln. Auf den Arbeitspl"atzen werden f"ur jeden Netzdrucker die
+  korrekten Treiber installiert.
+\end{itemize}
+
+Beide Wege haben Vor- und Nachteile. Im ersten Fall hat man weniger
+Aufwand mit der Administration auf Clientseite. Man mu"s den korrekten
+"`Druckertreiber"' nur einmal definieren, am Druckerserver.  Beim
+zweiten Weg kann man die bessere Unterst"utzung der Druckerhersteller
+f"ur die Windowsplattformen nutzen. Druckertreiber f"ur Windows bieten
+in der Regel die M"oglichkeit, Sonderfunktionen wie die Auswahl des
+Papierschachtes zu nutzen. Dieser erh"ohte Komfort zieht jedoch nach
+sich, da"s auf jedem Client der korrekte Druckertreiber installiert
+ist.
+
+Nutzt eine Windows NT Workstation einen Drucker, der von einem Windows
+NT Server freigegeben wurde, so gibt es noch die M"oglichkeit, die
+Druckaufbereitung komplett vom NT Server vornehmen zu lassen, und
+trotzdem s"amtliche Komfortfunktionen auf der Workstation zu nutzen.
+Dazu mu"s auf der Workstation kein Druckertreiber installiert sein.
+Diese sogenannten EMF-Druckerwarteschlangen kann Samba zur Zeit nicht
+exportieren. Samba wird dies voraussichtlich auch nicht so schnell
+erm"oglichen, da hierf"ur gro"se Teile von Windows, n"amlich das GDI,
+auf Sambaseite implementiert werden m"u"ste.
+
+Eine Druckfreigabe wird genau wie eine Dateifreigabe in einem eigenen
+Abschnitt erstellt, wobei f"ur die Druckfunktion drei Optionen
+notwendig sind:
+
+\begin{verbatim}
+[deskjet]
+printable = yes
+printer = lp
+path = /tmp
+\end{verbatim}
+
+Zu einer Druckfreigabe wird die Definition durch die Angabe
+\param{printable = yes}.
+
+Mit der Option \param{printer =} wird festgelegt, welche
+Druckerwarteschlange unter Unix angesprochen werden soll. Dieser
+Drucker mu"s das Format verstehen, das vom Windowsdruckertreiber
+geliefert wird. Also sollte hier entweder Postscript angenommen
+werden, oder die Daten sollten per sogenannter Raw-Queue direkt ohne
+Umwandlung an den Drucker weitergeleitet werden.
+
+Die Option \param{path =} legt einen Spoolbereich fest. Ein Druckjob,
+den ein Windowsrechner an Samba schickt, mu"s zun"achst in einer Datei
+abgespeichert werden. Wenn diese Datei geschlossen wird, teilt der
+Client dem Server mit, da"s diese nun zum Drucker geschickt werden
+soll. Samba realisiert dies, indem das Programm \prog{lpr} mit der
+Druckdatei als Argument aufgerufen wird. Samba mu"s also f"ur sich die
+M"oglichkeit haben, Druckjobs in Dateien zu speichern, bevor sie an
+den \prog{lpd} "ubergeben werden. Dies sollte nicht das
+Spoolverzeichnis sein, das der \prog{lpd} selbst f"ur den Drucker
+vorsieht.
+
+\section{Samba als Logon-Server}
+
+Wenn sich in einem Netz Windows 95/98 Clients befinden, kann es
+w"unschenswert sein, da"s sich die Benutzer dieser Arbeitspl"atze nur
+mit einem Pa"swort anmelden k"onnen, das zentral auf einem Server
+vorgehalten wird. Dazu mu"s der entsprechende Server spezielle Aufrufe
+von Clients entgegennehmen und korrekt beantworten. In der reinen
+Windowswelt ist dazu ein Windows NT Server notwendig, der als
+sogenannter Primary Domain Controller (PDC) installiert ist. Samba ist
+ebenfalls in der Lage, dies zu tun. Dazu ist im Abschnitt
+\param{[global]} der Parameter \param{domain logons = yes} zu setzen.
+Die Implementation, die Microsoft gew"ahlt hat, um Dom"anenanmeldungen
+zu erm"oglichen, erzwingt zus"atzlich, da"s der Domain Master Browser
+auf dem gleichen Rechner liegt wie der Logon Server. Das hei"st, man
+ben"otigt f"ur Dom"anenanmeldungen die folgenden Parameter:
+
+\begin{verbatim}
+[global]
+workgroup = samba
+domain logons = yes
+domain master = yes
+\end{verbatim}
+
+Hat man diese Parameter gesetzt, kann man in den Eigenschaften des
+Clients f"ur Microsoft-Netzwerke einstellen, da"s der Client sich an
+der Dom"ane \texttt{samba} anmelden soll. Hat man verschl"usselte
+Pa"sw"orter (Siehe Abschnitt \ref{passwoerter}) aktiviert, kann man
+vom Client aus sein SMB-Pa"swort "andern, indem man das entsprechende
+Kontrollfeld in der Systemsteuerung von Windows benutzt.
+
+\section{Windows NT Dom"anen}
+
+Die Dom"anenanmeldung unter Windows 95/98 ist eine relativ einfache
+Sache, da es sich dabei praktisch nur um eine "Uberpr"ufung der
+Benutzerpa"sw"orter handelt. So etwas wie Benutzer kennt Windows 95
+praktisch nicht, jeder Benutzer hat vollen Zugriff auf das gesamte
+System. Erst mit Windows NT hat Microsoft den Schritt hin zu einem
+Betriebssystem gemacht, das Benutzerkonten und Zugriffsrechte
+verwalten kann. Damit sind sie sehr viel weiter gegangen, als Unix
+dies getan hatte. Um das Konzept der Windows NT Dom"ane zu
+verdeutlichen, soll hier zun"achst auf das Konzept des Benutzers unter
+Windows und unter Unix eingegangen werden.
+
+Unter Unix besteht ein Benutzer im wesentlichen aus einer numerischen
+Userid, und nicht mehr. Das Programm \prog{login} mu"s beim Anmelden
+des Benutzers anhand seines Namens herausfinden, welche numerische
+Userid er hat. Dazu sieht es in der Datei \datei{/etc/passwd} nach.
+Mit der Datei \datei{/etc/shadow} pr"uft \prog{login} das Pa"swort.
+Ist es korrekt, wird in die gefundene Userid umgeschaltet und die
+Loginshell des Benutzers gestartet.  Nach diesem Vorgang ist es Unix
+v"ollig egal, wie der Benutzer hei"st, das einzige, was interessiert,
+ist der numerische Wert. Damit h"angt an jedem Proze"s eine endeutige
+Identifikation der Rechte, die er hat.
+
+Unter Unix ist es so, da"s Userids nur auf dem Rechner gelten, auf dem
+sie zugeordnet wurden. Es gibt keine M"oglichkeit, Rechte von einem
+Rechner auf den n"achsten zu "ubernehmen oder global Benutzer
+zuzuordnen. Die einzige M"oglichkeit, die man zu Vereinheitlichung
+hat, ist der Austausch der jeweils auf einem Rechner geltenden
+Tabellen "uber verschiedene Rechner hinweg. Genau das tut NIS oder
+Yellow Pages. Die Benutzerdatenbank wird verteilt, gilt aber auf jedem
+Rechner rein lokal.
+
+Unter NT sieht das sehr "ahnlich aus, nur da"s hier der Benutzer nicht
+durch eine kleine Zahl, sondern durch einen Security Identifier SID
+repr"asentiert wird. Ein solcher SID ist mehrteilig. Der erste Teil
+dieses SID beinhaltet eine Kennung der Benutzerdatenbank, zu der
+dieser Benutzer geh"ort. Ein solcher SID ist 96 Bit lang und Microsoft
+behauptet, da"s dieser Wert zuf"allig genug gew"ahlt ist, da"s es
+keine zwei Benutzerdatenbanken geben kann, die die gleiche SID haben.
+Der zweite Teil besteht aus einem sogenannten Relative Identifier RID,
+der den Benutzer innerhalb der Dom"ane eindeutig identifiziert. Die
+Kennung f"ur die Dom"ane besteht aus 3 32-Bit Zahlen, die zusammen 96
+Bit ergeben.
+
+Unter Windows NT hat nun jeder Rechner eine eigene Benutzerdatenbank,
+genau wie unter Unix. Da aber jede Benutzerdatenbank eindeutig
+identifiziert ist, kann es keine zwei Benutzer mit gleicher Userid
+geben. Der Relative Identifier mag gleich sein, der Identifier f"ur
+die Benutzerdatenbank unterscheidet sich aber auf jeden Fall.
+
+Microsoft unterscheidet verschiedene Netzwerkmodelle. Das Peer-To-Peer
+Netz ist das Modell, das auch Unix zugrunde liegt. Hier hat jeder
+beteiligte Rechner eine eigene Benutzerdatenbank, eigene Pa"sw"orter
+und eigene Rechtezuordnungen. Das Dom"anenmodell ist das Modell, das
+sich signifikant von Unix unterscheidet. Mit dem Dom"anenmodell wird
+eine Workstation in die Lage versetzt, mehr als eine Benutzerdatenbank
+zu benutzen. Neben der eigenen Benutzerdatenbank, die jede Workstation
+hat, kann sie eine Benutzerdatenbank von einem anderen Rechner
+importieren. In einer Windows NT Dom"ane gibt es einen Rechner, der
+seine eigene Benutzerdatenbank anderen zur Verf"ugung stellt, den
+sogenannten Primary Domain Controller. Dieser reserviert f"ur sich
+spezielle NetBIOS-Namen, um sich den Workstations als Logonserver
+anzubieten.  Eine Workstation befragt den Primary Domain Controller
+nach allen relevanten Daten zu den Benutzern, die sich bei ihr
+anmelden wollen, und die Rechte auf der Workstation wahrnehmen
+k"onnen.
+
+Die Kommunikation zwischen der Workstation und dem Primary Domain
+Controller l"auft verschl"usselt ab. Um eine solche Verschl"usselung
+zu erm"oglichen, mu"s ein gemeinsamer Schl"ussel vereinbart werden. Um
+sich "uber einen Schl"ussel einig zu werden, gibt es spezialisierte
+Protokolle, wie beispielsweise der Diffie-Hellmann
+Schl"usselaustausch. Um jeglichen Problemen mit Patenten oder
+Exportrestriktionen zu umgehen, ist Microsoft einen anderen Weg
+gegangen.  Beim Schl"usselaustausch geht es im wesentlichen darum,
+sich "uber ein gemeinsames Geheimnis einig zu werden. Um ein
+gemeinsames Geheimnis zu wahren und zu pr"ufen, kennt Microsoft
+bereits eine Gruppe von Protokollen: Die Protokolle zum Pr"ufen und
+Austauschen von Benutzerpa"sw"ortern. Genau diese Protokolle werden
+verwendet, um die Kommunikation zwischen PDC und Workstation zu
+sichern. Daher mu"s jede Workstation explizit in die Dom"ane
+aufgenommen werden.
+
+Bei Samba ist es so, da"s es zu jedem Benutzer, der ein Pa"swort in
+der \datei{/etc/smb.conf} hat, einen Benutzer im System geben mu"s.
+Der zu einer Workstation geh"orende Benutzer mu"s den NetBIOS-Namen
+der Workstation, erg"anzt um ein \$-Zeichen, haben. Man ben"otigt also
+zwei Schritte, um eine Workstation in die Dom"ane aufzunehmen. Im
+ersten Schritt wird der Unixbenutzer angelegt. Dies geschieht in
+vielen Linuxsystemen mit dem Kommando \texttt{useradd -m $<$user$>$}.
+Der angelegte Benutzer ben"otigt im Unixsystem weder ein Pa"swort noch
+ein Heimatverzeichnis. Er ist notwendig, da die Workstation in der
+Dom"ane eine eigene SID bekommt, die aus der Unix userid berechnet
+wird. Dann mu"s die Workstation ein Pa"swort in der
+\datei{/etc/smbpasswd} bekommen, und zwar mit dem Befehl
+\texttt{smbpasswd -a -m name}. Ein Beispiel sieht folgenderma"sen aus:
+
+\begin{verbatim}
+root@erde: useradd -m wks\$
+root@erde: smbpasswd -a -m wks
+\end{verbatim}
+
+Man beachte, da"s beim Befehl \texttt{useradd} ein Dollarzeichen,
+maskiert durch den Backslash, hinzugef"ugt wurde. Der Befehl
+\prog{smbpasswd} f"ugt diesen bei Verwendung des Parameters \prog{-m}
+selbst hinzu.
+
+\section{Samba als Dom"anenmitglied}
+
+Mit dem Parameter \param{security} kann man den Zeitpunkt steuern, zu
+dem das Benutzerpa"swort gepr"uft wird. \param{security = share} legt
+fest, da"s die Pr"ufung beim Tree Connect stattfindet, das hei"st,
+wenn die Freigabe angesprochen wird. Ist \param{security = user}
+angegeben, wird das Pa"swort bereits einen Schritt vorher, also beim
+Session Setup gepr"uft. Bei \param{security = user} wird also die
+Kombination von Benutzer und Pa"swort gepr"uft bei \param{security =
+  share} die Kombination Freigabe und Pa"swort.
+
+Der Parameter \param{security} kann noch zwei weitere Werte annehmen:
+\param{server} und \param{domain}.  Bei beiden Einstellungen verh"alt
+sich Samba gegen"uber dem Client genau wie bei \param{security =
+  user}, der Benutzer mu"s sich unter seinem Namen beim Server
+authentifizieren. Die Unterschiede liegen in der Art und Weise, wie
+das Pa"swort "uberpr"uft wird.
+
+\begin{itemize}
+\item \param{security = user}: Die "Uberpr"ufung findet anhand einer
+  lokalen Datenbank statt. Werden Klartextpa"sw"orter verwendet
+  (\param{encrypt passwords = no}), so wird die lokale
+  Unix-Pa"swortdatenbank in \datei{/etc/passwd}, \datei{/etc/shadow}
+  oder die entsprechende NIS-Tabelle herangezogen. Bei
+  verschl"usselten Pa"sw"ortern mit wird die Samba-eigene
+  Pa"swortdatenbank in der Datei \datei{smbpasswd} zur "Uberpr"ufung
+  herangezogen.
+\item \param{security = server}: Bei dieser Einstellung bekommt der
+  Sambaserver vom Client einen Benutzernamen und ein Pa"swort
+  pr"asentiert. Er versucht daraufhin, sich mit diesem Pa"swort bei
+  einem weiteren Server anzumelden. Funktioniert dies, hat der
+  Benutzer sein Pa"swort offensichtlich richtig eingegeben.  Schl"agt
+  dies fehl, wird auch dem Client des Sambaservers der Fehler
+  mitgeteilt und der Zugriff verweigert. Der Pa"swortserver, der zur
+  "Uberpr"ufung herangezogen wird, mu"s mit seinem NetBIOS-Namen im
+  Parameter \param{password server} angegeben werden.
+\item \param{security = domain}: Auch hierbei wird die "Uberpr"ufung
+  einem Pa"swortserver "uberlassen. Dieser mu"s jedoch ein Primary
+  Domain Controller sein, der den Sambaserver in die Dom"ane
+  aufgenommen hat. Der Hauptvorteil gegen"uber \param{security =
+    server} besteht in einer deutlich reduzierten Last auf dem
+  Pa"swortserver und einer verschl"usselten Kommunikation zwischen
+  Samba und Pa"swortserver.
+\end{itemize}
+
+Um einen Windowsrechner dazu zu bringen, f"ur einen Sambaserver die
+Pa"swort"uberpr"ufung zu "ubernehmen, mu"s man nur \param{security =
+  server} und den \param{password server} passend setzen. Dabei
+"ubernimmt der Server ausschlie"slich die "Uberpr"ufung der
+Pa"s\-w"orter.  Bei verschl"usselten Pa"sw"ortern k"onnen Benutzer nur
+dann in die \datei{smbpasswd} aufgenommen werden, wenn sie in der
+Unix-Benutzerdatenbank existieren. Genau so verh"alt es sich bei
+\param{security = server}. Benutzer k"onnen auf Samba nur dann
+zugreifen, wenn sie als normale Unixbenutzer existieren.
+
+\param{security = server} ist nicht die optimale L"osung f"ur die
+"Uberpr"ufung von Pa"sw"ortern durch einen weiteren Rechner.
+
+Um die Vorteile der Dom"anenmitgliedschaft zu nutzen, ist etwas mehr
+Aufwand notwendig. Mitglied einer Dom"ane zu sein hei"st, mit dem
+Primary Domain Controller "uber einen verschl"usselten Kanal
+kommunizieren zu k"onnen. Diese Verschl"usselung wird verwendet, um
+Benutzerinformationen verdeckt austauschen zu k"onnen. Als
+Verschl"usselungsverfahren kommt ein symmetrisches oder auch secret
+key Verfahren zum Einsatz. Um ein symmetrisches Verfahren anwenden zu
+k"onnen, m"ussen sich beide Partner "uber ein gemeinsames Geheimnis,
+den \emph{secret key} einig sein.  Ein solches gemeinsames Geheimnis
+mu"s regelm"a"sig ge"andert werden, um einer gro"sen Klasse von
+kryptographischen Angriffen auszuweichen. Eine solche "Anderung darf
+selbstverst"andlich nicht abgeh"ort werden k"onnen, da ein Zuh"orer
+damit die gesamte Kommunikation abh"oren kann. F"ur die "Anderung
+eines Geheimnisses gab es bereits vor der Implementation des
+Dom"anenprotokolls ein fertiges Protokoll, das man direkt verwenden
+konnte: Die M"oglichkeit, Benutzerpa"sw"orter "uber das Netz zu
+"andern, war mir einem gesicherten Protokoll implementiert. Um dieses
+Protokoll zur verschl"usselten Kommunikation zwischen einer
+Workstation oder einem Mitgliedsserver und dem Dom"anencontroller
+nutzen zu k"onnen, mu"s es f"ur jedes Dom"anenmitglied ein
+Benutzerkonto geben.  Genau dies wird auf dem Dom"anencontroller
+erstellt, wenn man eine Workstation oder einen Server mit dem
+Servermanager in die Dom"ane aufnimmt. Betritt man danach mit der
+Workstation die Dom"ane, wird als erstes das Pa"swort des
+Computerkontos ge"andert.
+
+Um einen Sambaserver in eine Dom"ane aufzunehmen, sind zwei Schritte
+notwendig.
+
+\begin{itemize}
+\item Auf dem Server mu"s der Sambaserver mit seinem NetBIOS-Namen in
+  die Dom"ane aufgenommen werden.
+\item Der Sambaserver selbst mu"s dar"uber informiert werden, da"s er
+  sich in der Dom"ane befindet, und er mu"s sein Pa"swort "andern.
+  Dies geschieht mit dem Befehl
+
+\verb|smbpasswd -j DOM -r PDC|
+
+Dabei steht \texttt{DOM} f"ur die Dom"ane, die betreten wird.  Mit
+\texttt{PDC} wird der NetBIOS-Name des Dom"anencontrollers der Dom"ane
+benannt.
+\end{itemize}
+
+Mit diesem Kommando wird das Maschinenpa"swort auf dem PDC auf einen
+neuen, zuf"alligen Wert ge"andert. Dieses neue Maschinenpa"swort f"ur
+den Samba Server wird in einer Datei im gleichen Verzeichnis wie die
+Datei \texttt{smbpasswd} abgespeichert und hat folgenden Namen:
+
+\verb|<NT DOMAENENNAME>.<Samba Servername>.mac|
+
+Die Endung .mac steht f"ur \emph{Machine ACcount} Pa"swortdatei. Im obigen
+Beispiel w"urde die Datei also \texttt{DOM.SERV1.mac} hei"sen.
+
+Diese Datei wird von root erstellt und ist f"ur keinen anderen
+Benutzer lesbar. Sie ist der Schl"ussel zu Ihrer Dom"anensicherheit
+und sollte genau so vorsichtig behandelt werden wie die Datei
+\texttt{/etc/shadow}.
+
+Nach diesen beiden Schritten kann man mit \param{security = domain},
+\param{password server = PDC BDC1 BDC2} und \param{encrypt passwords =
+  yes} die Pa"swort"uberpr"ufung an einen der Dom"anencontroller
+delegieren. Dies sind die Prim"aren und Backup Dom"anencontroller, die
+Samba der Reihe nach kontaktieren wird, um Benutzer zu
+authentifizieren. Samba wird sie in der aufgef"uhrten Reihenfolge
+ansprechen. Sie k"onnen also die Reihenfolge ver"andern, um eine
+g"unstigere Lastverteilung zu erreichen. Eine weitere Option ist die
+Angabe \param{password server = *}. Damit sucht Samba mit den
+Standardmethoden\footnote{Windows NT findet einen Dom"anencontroller,
+  indem der NetBIOS-Name \nbname{DOMAIN<1C>} gesucht wird.} von
+Windows NT nach einem Dom"anencontroller und befragt die Server, die
+es bei dieser Anfrage herausbekommen hat.
+
+Warum ist \param{security = domain} besser als \param{security =
+  server}?
+
+Der Vorteil der Dom"anensicherheit ist, da"s Samba die
+Authentifizierung "uber einen gesicherten RPC Kanal schickt, genau wie
+ein Windows NT Server es tun w"urde. Das hei"st, da"s Samba nun genau
+wie ein Windows NT Server an einer Vertrauensstellung teilnehmen kann.
+Das hei"st, Sie k"onnen einen Samba Server in eine Resourcendom"ane
+aufnehmen, und Sie k"onnen die Authentifizierung via Resourcen PDC vom
+PDC der Benutzerdom"ane vornehmen lassen.
+
+Zus"atzlich mu"s in der Einstellung \texttt{security = server} der
+Samba D"amon eine Verbindung zum Authentifizierungsserver w"ahrend
+seiner gesamten Laufzeit offenhalten. Dies kann die Anzahl der offenen
+Verbindungen auf einem Windows NT Server in die H"ohe treiben, so da"s
+dieser keine Verbindungen mehr annimmt. Mit \texttt{security = domain}
+verbinden sich die Samba D"amonen nur so lange mit dem PDC, wie es
+f"ur die Benutzerauthentifizierung notwendig ist. Danach wird die
+Verbindung wieder abgebaut, so da"s die Verbindungen wieder
+anderweitig verwendbar sind.
+
+Und nicht zuletzt bekommt der Samba Server als Teil der Antwort auf
+die Authentifizierungsanforderung Informationen "uber den Security
+Identifier, die Gruppenzuordnungen und andere Informationen "uber den
+Benutzer. All diese Informationen werden Samba zuk"unftig erlauben, in
+einem sogenannten Appliance Modus zu laufen. In diesem Modus wird
+kein manuell angelegter Unixbenutzer mehr notwendig sein. Samba wird Unix
+Benutzer und Gruppen aus der Authentifizierungsantwort des PDC
+erzeugen. Damit wird Samba wirklich ein Plug and Play Mitglied einer
+Dom"ane.
+
+Dieser Appliance Modus kann heute schon ann"ahernd erreicht werden,
+indem bei Samba der Parameter \param{add user script} angegeben wird.
+In diesem Parameter wird ein Unixprogramm angegeben, das dynamisch
+einen Unixbenutzer erzeugen mu"s, nachdem ein Pa"swortserver die
+Korrektheit eines Pa"sworts best"atigt hat. Ein Beispiel kann sein:
+
+\verb|add user script = /usr/bin/useradd -m %U|
+
+Damit wird einfach ein Benutzer hinzugef"ugt, wenn er noch nicht
+existiert, aber der PDC das Pa"swort best"atigt hat.
+
+\end{document}
+
diff --git a/docs/textdocs/logo.ps b/docs/textdocs/logo.ps
new file mode 100644
index 00000000000..4fa39aef368
--- /dev/null
+++ b/docs/textdocs/logo.ps
@@ -0,0 +1,344 @@
+%!PS-Adobe-3.0
+%%Pages: (atend)
+%%BoundingBox: 0 261 683 580
+%.....................................
+%%Creator: Aladdin Ghostscript 601 (pswrite)
+%%CreationDate: 2000/08/03 14:15:29
+%%DocumentData: Clean7Bit
+%%EndComments
+%%BeginProlog
+% This copyright applies to everything between here and the %%EndProlog:
+% Copyright (C) 2000 Aladdin Enterprises, Menlo Park, CA.  All rights reserved.
+%%BeginResource: procset GS_pswrite_ProcSet
+/GS_pswrite_ProcSet 80 dict dup begin
+/!{bind def}bind def/#{load def}!/N/counttomark #
+/rG{3{3 -1 roll 255 div}repeat setrgbcolor}!/G{255 div setgray}!/K{0 G}!
+/r6{dup 3 -1 roll rG}!/r5{dup 3 1 roll rG}!/r3{dup rG}!
+/w/setlinewidth #/J/setlinecap #
+/j/setlinejoin #/M/setmiterlimit #/d/setdash #/i/setflat #
+/m/moveto #/l/lineto #/c/rcurveto #/h{p closepath}!/H{P closepath}!
+/lx{0 rlineto}!/ly{0 exch rlineto}!/v{0 0 6 2 roll c}!/y{2 copy c}!
+/re{4 -2 roll m exch dup lx exch ly neg lx h}!
+/^{3 index neg 3 index neg}!
+/P{N 0 gt{N -2 roll moveto p}if}!
+/p{N 2 idiv{N -2 roll rlineto}repeat}!
+/f{P fill}!/f*{P eofill}!/s{H stroke}!/S{P stroke}!
+/q/gsave #/Q/grestore #/rf{re fill}!
+/Y{initclip P clip newpath}!/Y*{initclip P eoclip newpath}!/rY{re Y}!
+/|={pop exch 4 1 roll 3 array astore cvx exch 1 index def exec}!
+/|{exch string readstring |=}!
+/+{dup type/nametype eq{2 index 7 add -3 bitshift 2 index mul}if}!
+/@/currentfile #/${+ @ |}!
+/Ix{[1 0 0 1 11 -2 roll exch neg exch neg]exch}!
+/,{true exch Ix imagemask}!/If{false exch Ix imagemask}!/I{exch Ix image}!
+/|X{exch string readhexstring |=}!/$X{+ @ |X}!
+/@X{{currentfile ( ) readhexstring pop}}!
+/PS{1 index where{pop cvx exec pop pop}{pop/setpage where
+{pop pageparams 3{exch pop}repeat setpage}{pop pop}ifelse}ifelse}!
+end def
+%%EndResource
+%%EndProlog
+%%Page: 1 1
+%%BeginPageSetup
+/pagesave save def GS_pswrite_ProcSet begin
+612 792 /letter PS
+0.1 0.1 scale
+480 0 translate
+%%EndPageSetup
+mark
+75 w
+4 M
+255 15 0 rG
+481.48 4361.14 m
+-66 41.75 -145.25 62.64 -237.74 62.64 c
+-24.49 0 -47.76 -3.02 -69.76 -9 c
+-31.49 -8.49 -46.23 -21.97 -44.23 -40.43 c
+1.99 -16.99 28.47 -38.2 79.51 -63.66 c
+78.49 -38.96 125.74 -63.66 141.74 -74.15 c
+51.97 -33.95 79.98 -69.9 83.99 -107.81 c
+7 -64.92 -39.99 -117.36 -141.01 -157.3 c
+-90.5 -35.94 -199.74 -53.9 -327.74 -53.9 c
+-89.01 0 -168.99 7.23 -239.97 21.71 c
+-90.53 18.45 -137.02 39.43 -139.51 62.9 c
+-0.53 3.48 -0.03 6.97 1.49 10.49 c
+45 140.04 p
+74 -54.26 149.24 -81.39 225.76 -81.39 c
+36.97 0 54.23 12.21 51.74 36.68 c
+-3.52 30.41 -24.76 58.85 -63.75 85.31 c
+-20.51 12.95 -56.78 36.91 -108.75 71.84 c
+-43.51 29.91 -65.24 65.83 -65.24 107.75 c
+0 75.32 60.73 130.69 182.26 166.11 c
+84.49 24.44 182.72 36.68 294.72 36.68 c
+119.48 0 224.24 -16.81 314.24 -50.42 c
+17.25 -164.09 h
+S
+1304.6 4343.04 m
+-22.5 -58.8 -50.01 -109.87 -82.5 -153.2 c
+-45.5 -60.29 -92.26 -90.44 -140.25 -90.44 c
+-35.01 0 -52.5 23.91 -52.5 71.75 c
+0 38.85 12.25 82.94 36.74 132.27 c
+37.5 75.24 91.23 112.86 161.25 112.86 c
+105.76 0 -28.5 -73.24 h
+1108.1 4573.78 m
+-132.51 0 -249.26 -30.5 -350.24 -91.5 c
+-120 -72.5 -180 -170.77 -180 -294.75 c
+0 -13.51 0.73 -27.51 2.25 -42.01 c
+7.97 -76.5 42.98 -134.24 105 -173.24 c
+53.49 -34.01 120.99 -51 202.5 -51 c
+149.01 0 267.75 57.86 356.25 173.61 c
+-51.76 -164.24 426 0 195.76 626.25 p
+-169.51 11.25 -404.76 16.88 -705.76 16.88 c
+h
+S
+5755.04 4343.04 m
+-22.5 -58.8 -50.01 -109.87 -82.5 -153.2 c
+-45.5 -60.29 -92.26 -90.44 -140.25 -90.44 c
+-35 0 -52.5 23.91 -52.5 71.75 c
+0 38.85 12.25 82.94 36.74 132.27 c
+37.5 75.24 91.23 112.86 161.25 112.86 c
+105.76 0 -28.5 -73.24 h
+5558.54 4573.78 m
+-132.5 0 -249.25 -30.5 -350.24 -91.5 c
+-120 -72.5 -180 -170.77 -180 -294.75 c
+0 -13.51 0.73 -27.51 2.26 -42.01 c
+7.96 -76.5 42.97 -134.24 105 -173.24 c
+53.49 -34.01 120.99 -51 202.5 -51 c
+149 0 267.74 57.86 356.25 173.61 c
+-51.77 -164.24 426 0 195.77 626.25 p
+-169.52 11.25 -404.77 16.88 -705.77 16.88 c
+h
+S
+4670.96 5042.19 -297.33 668.31 -574.48 -685.34 202.89 3.96 -315.84 -1098.47 436.49 0 23.24 59.24 P
+50.5 -49.51 136.75 -74.24 258.75 -74.24 c
+132.01 0 247.99 31.94 348.01 95.83 c
+115.49 73.89 173.26 173.21 173.26 298.01 c
+0 13.95 -0.76 28.19 -2.25 42.66 c
+-15.5 147.74 -141.01 221.63 -376.5 221.63 c
+-63.01 0 -138.77 -10.64 -227.25 -31.88 c
+123.99 490.32 227.02 9.97 h
+4464.7 4260.71 m
+-48.01 -126.3 -109.01 -189.43 -182.99 -189.43 c
+-26.51 0 -49.01 3.69 -67.52 11.13 c
+-11.02 5.45 -22 10.9 -32.99 16.35 c
+16.49 45.32 p
+35.98 100.05 70.49 166.67 103.51 199.87 c
+28.01 28.21 68 42.33 120 42.33 c
+90.76 0 -47.26 -125.57 h
+S
+3637.84 4406.7 m
+-12.01 112.61 -97.53 168.95 -256.52 168.95 c
+-199.51 0 -348.49 -20.01 -446.98 -60 c
+-56.52 39.99 -147.02 60 -271.5 60 c
+-204.52 0 -428.26 -5.77 -671.25 -17.25 c
+-196.5 -627.75 436.5 0 23.26 62.26 p
+73.48 195 138.72 313.74 195.74 356.25 c
+32.98 24.99 77.48 37.5 133.5 37.5 c
+-19.02 -46.52 -33.25 -85.52 -42.75 -117.01 c
+-107.25 -339 442.5 0 24 62.26 p
+45.46 115.99 77.22 192.74 95.24 230.24 c
+30.49 62.49 60.23 104.51 89.24 126.01 c
+32.99 24.99 77.49 37.5 133.5 37.5 c
+-19.01 -46.52 -33.25 -85.52 -42.74 -117.01 c
+-292.57 -917.2 -223.62 3.05 297.33 -668.31 543.98 656.81 -177.09 2.42 295.99 923.64 p
+16 50.53 21.97 96.09 17.99 136.64 c
+h
+S
+K
+457.11 4402.39 m
+-66 41.75 -145.25 62.64 -237.74 62.64 c
+-24.49 0 -47.76 -3.02 -69.76 -9 c
+-31.49 -8.49 -46.23 -21.97 -44.23 -40.43 c
+1.99 -16.99 28.47 -38.2 79.51 -63.66 c
+78.49 -38.96 125.74 -63.66 141.74 -74.15 c
+51.97 -33.95 79.98 -69.9 83.99 -107.81 c
+7 -64.92 -39.99 -117.36 -141.01 -157.3 c
+-90.5 -35.94 -199.74 -53.9 -327.74 -53.9 c
+-89.01 0 -168.99 7.23 -239.97 21.71 c
+-90.53 18.45 -137.02 39.43 -139.51 62.9 c
+-0.53 3.48 -0.03 6.97 1.49 10.49 c
+45 140.04 p
+74 -54.26 149.24 -81.39 225.76 -81.39 c
+36.97 0 54.23 12.21 51.74 36.68 c
+-3.52 30.41 -24.76 58.85 -63.75 85.31 c
+-20.51 12.95 -56.78 36.91 -108.75 71.84 c
+-43.51 29.91 -65.24 65.83 -65.24 107.75 c
+0 75.32 60.73 130.69 182.26 166.11 c
+84.49 24.44 182.72 36.68 294.72 36.68 c
+119.48 0 224.24 -16.81 314.24 -50.42 c
+17.25 -164.09 p f
+45 w
+0 255 r6
+457.11 4402.39 m
+-66 41.75 -145.25 62.64 -237.74 62.64 c
+-24.49 0 -47.76 -3.02 -69.76 -9 c
+-31.49 -8.49 -46.23 -21.97 -44.23 -40.43 c
+1.99 -16.99 28.47 -38.2 79.51 -63.66 c
+78.49 -38.96 125.74 -63.66 141.74 -74.15 c
+51.97 -33.95 79.98 -69.9 83.99 -107.81 c
+7 -64.92 -39.99 -117.36 -141.01 -157.3 c
+-90.5 -35.94 -199.74 -53.9 -327.74 -53.9 c
+-89.01 0 -168.99 7.23 -239.97 21.71 c
+-90.53 18.45 -137.02 39.43 -139.51 62.9 c
+-0.53 3.48 -0.03 6.97 1.49 10.49 c
+45 140.04 p
+74 -54.26 149.24 -81.39 225.76 -81.39 c
+36.97 0 54.23 12.21 51.74 36.68 c
+-3.52 30.41 -24.76 58.85 -63.75 85.31 c
+-20.51 12.95 -56.78 36.91 -108.75 71.84 c
+-43.51 29.91 -65.24 65.83 -65.24 107.75 c
+0 75.32 60.73 130.69 182.26 166.11 c
+84.49 24.44 182.72 36.68 294.72 36.68 c
+119.48 0 224.24 -16.81 314.24 -50.42 c
+17.25 -164.09 h
+S
+13 16 255 rG
+1280.22 4384.29 m
+-22.5 -58.8 -50.01 -109.87 -82.5 -153.2 c
+-45.5 -60.29 -92.25 -90.44 -140.24 -90.44 c
+-35.01 0 -52.5 23.91 -52.5 71.75 c
+0 38.85 12.24 82.94 36.74 132.27 c
+37.5 75.24 91.23 112.86 161.25 112.86 c
+105.76 0 -28.51 -73.24 h
+1083.73 4615.03 m
+-132.51 0 -249.26 -30.5 -350.25 -91.5 c
+-120 -72.5 -180 -170.77 -180 -294.75 c
+0 -13.51 0.73 -27.51 2.25 -42.01 c
+7.97 -76.5 42.98 -134.24 105 -173.24 c
+53.49 -34.01 120.99 -51 202.5 -51 c
+149 0 267.74 57.86 356.25 173.61 c
+-51.77 -164.24 426.01 0 195.76 626.25 p
+-169.51 11.25 -404.77 16.88 -705.76 16.88 c
+f
+0 255 r6
+1280.22 4384.29 m
+-22.5 -58.8 -50.01 -109.87 -82.5 -153.2 c
+-45.5 -60.29 -92.25 -90.44 -140.24 -90.44 c
+-35.01 0 -52.5 23.91 -52.5 71.75 c
+0 38.85 12.24 82.94 36.74 132.27 c
+37.5 75.24 91.23 112.86 161.25 112.86 c
+105.76 0 -28.51 -73.24 h
+1083.73 4615.03 m
+-132.51 0 -249.26 -30.5 -350.25 -91.5 c
+-120 -72.5 -180 -170.77 -180 -294.75 c
+0 -13.51 0.73 -27.51 2.25 -42.01 c
+7.97 -76.5 42.98 -134.24 105 -173.24 c
+53.49 -34.01 120.99 -51 202.5 -51 c
+149 0 267.74 57.86 356.25 173.61 c
+-51.77 -164.24 426.01 0 195.76 626.25 p
+-169.51 11.25 -404.77 16.88 -705.76 16.88 c
+h
+S
+13 16 255 rG
+5730.66 4384.29 m
+-22.5 -58.8 -50.01 -109.87 -82.5 -153.2 c
+-45.49 -60.29 -92.25 -90.44 -140.24 -90.44 c
+-35.01 0 -52.5 23.91 -52.5 71.75 c
+0 38.85 12.25 82.94 36.74 132.27 c
+37.5 75.24 91.23 112.86 161.25 112.86 c
+105.76 0 -28.51 -73.24 h
+5534.17 4615.03 m
+-132.51 0 -249.26 -30.5 -350.24 -91.5 c
+-120.01 -72.5 -180.01 -170.77 -180.01 -294.75 c
+0 -13.51 0.74 -27.51 2.26 -42.01 c
+7.97 -76.5 42.98 -134.24 105 -173.24 c
+53.5 -34.01 121 -51 202.5 -51 c
+149.01 0 267.75 57.86 356.25 173.61 c
+-51.77 -164.24 426.01 0 195.76 626.25 p
+-169.51 11.25 -404.76 16.88 -705.76 16.88 c
+f
+0 255 r6
+5730.66 4384.29 m
+-22.5 -58.8 -50.01 -109.87 -82.5 -153.2 c
+-45.49 -60.29 -92.25 -90.44 -140.24 -90.44 c
+-35.01 0 -52.5 23.91 -52.5 71.75 c
+0 38.85 12.25 82.94 36.74 132.27 c
+37.5 75.24 91.23 112.86 161.25 112.86 c
+105.76 0 -28.51 -73.24 h
+5534.17 4615.03 m
+-132.51 0 -249.26 -30.5 -350.24 -91.5 c
+-120.01 -72.5 -180.01 -170.77 -180.01 -294.75 c
+0 -13.51 0.74 -27.51 2.26 -42.01 c
+7.97 -76.5 42.98 -134.24 105 -173.24 c
+53.5 -34.01 121 -51 202.5 -51 c
+149.01 0 267.75 57.86 356.25 173.61 c
+-51.77 -164.24 426.01 0 195.76 626.25 p
+-169.51 11.25 -404.76 16.88 -705.76 16.88 c
+h
+S
+K
+4646.58 5083.44 -297.33 668.31 -574.48 -685.34 202.9 3.96 -315.85 -1098.47 436.5 0 23.23 59.24 P
+50.51 -49.51 136.76 -74.24 258.75 -74.24 c
+132.01 0 248 31.94 348.02 95.83 c
+115.48 73.89 173.26 173.21 173.26 298.01 c
+0 13.95 -0.76 28.19 -2.26 42.66 c
+-15.5 147.74 -141 221.63 -376.49 221.63 c
+-63.02 0 -138.78 -10.64 -227.26 -31.88 c
+123.99 490.32 227.02 9.97 h
+4440.33 4301.96 m
+-48.02 -126.3 -109.01 -189.43 -182.99 -189.43 c
+-26.51 0 -49.01 3.69 -67.53 11.13 c
+-11.01 5.45 -22 10.9 -32.99 16.35 c
+16.5 45.32 p
+35.97 100.05 70.48 166.67 103.5 199.87 c
+28.01 28.21 68 42.33 120 42.33 c
+90.77 0 -47.26 -125.57 p f
+0 255 r6
+4646.58 5083.44 -297.33 668.31 -574.48 -685.34 202.9 3.96 -315.85 -1098.47 436.5 0 23.23 59.24 P
+50.51 -49.51 136.76 -74.24 258.75 -74.24 c
+132.01 0 248 31.94 348.02 95.83 c
+115.48 73.89 173.26 173.21 173.26 298.01 c
+0 13.95 -0.76 28.19 -2.26 42.66 c
+-15.5 147.74 -141 221.63 -376.49 221.63 c
+-63.02 0 -138.78 -10.64 -227.26 -31.88 c
+123.99 490.32 227.02 9.97 h
+4440.33 4301.96 m
+-48.02 -126.3 -109.01 -189.43 -182.99 -189.43 c
+-26.51 0 -49.01 3.69 -67.53 11.13 c
+-11.01 5.45 -22 10.9 -32.99 16.35 c
+16.5 45.32 p
+35.97 100.05 70.48 166.67 103.5 199.87 c
+28.01 28.21 68 42.33 120 42.33 c
+90.77 0 -47.26 -125.57 h
+S
+K
+3613.46 4447.95 m
+-12.01 112.61 -97.53 168.95 -256.52 168.95 c
+-199.51 0 -348.49 -20.01 -446.98 -60 c
+-56.51 39.99 -147.01 60 -271.5 60 c
+-204.52 0 -428.26 -5.77 -671.25 -17.25 c
+-196.49 -627.75 436.49 0 23.27 62.26 p
+73.47 195 138.72 313.74 195.73 356.25 c
+32.99 24.99 77.49 37.5 133.5 37.5 c
+-19.01 -46.52 -33.25 -85.52 -42.74 -117.01 c
+-107.26 -339 442.5 0 24 62.26 p
+45.47 115.99 77.22 192.74 95.24 230.24 c
+30.5 62.49 60.24 104.51 89.24 126.01 c
+32.99 24.99 77.49 37.5 133.51 37.5 c
+-19.02 -46.52 -33.25 -85.52 -42.75 -117.01 c
+-292.57 -917.2 -223.62 3.05 297.33 -668.31 543.99 656.81 -177.1 2.42 296 923.64 p
+15.99 50.53 21.97 96.09 17.98 136.64 c
+f
+0 255 r6
+3613.46 4447.95 m
+-12.01 112.61 -97.53 168.95 -256.52 168.95 c
+-199.51 0 -348.49 -20.01 -446.98 -60 c
+-56.51 39.99 -147.01 60 -271.5 60 c
+-204.52 0 -428.26 -5.77 -671.25 -17.25 c
+-196.49 -627.75 436.49 0 23.27 62.26 p
+73.47 195 138.72 313.74 195.73 356.25 c
+32.99 24.99 77.49 37.5 133.5 37.5 c
+-19.01 -46.52 -33.25 -85.52 -42.74 -117.01 c
+-107.26 -339 442.5 0 24 62.26 p
+45.47 115.99 77.22 192.74 95.24 230.24 c
+30.5 62.49 60.24 104.51 89.24 126.01 c
+32.99 24.99 77.49 37.5 133.51 37.5 c
+-19.02 -46.52 -33.25 -85.52 -42.75 -117.01 c
+-292.57 -917.2 -223.62 3.05 297.33 -668.31 543.99 656.81 -177.1 2.42 296 923.64 p
+15.99 50.53 21.97 96.09 17.98 136.64 c
+h
+S
+cleartomark end showpage pagesave restore
+%%PageTrailer
+%%Trailer
+%%Pages: 1
+%%EOF