Large expansion of my german book project.

Volker
(This used to be commit 768f90a6ca8538ffda5b46491281eea7673ae730)

1 files changed, 3167 insertions, 771 deletions

diff --git a/docs/textdocs/kurs.tex b/docs/textdocs/kurs.tex
index 6f5a24098e..93771c40e8 100644
--- a/docs/textdocs/kurs.tex
+++ b/docs/textdocs/kurs.tex
@@ -1,5 +1,5 @@
-\documentclass{scrartcl}
-\usepackage{pslatex}
+\documentclass{scrartcl}\usepackage{pslatex}\typearea{12}
+%\documentclass[ncs]{dpunkt}
 \usepackage[dvips,colorlinks=true,
             pdfauthor={Volker Lendecke, Service Network GmbH},
             pdftitle={Kursskript Samba},
@@ -12,28 +12,35 @@
 \usepackage[dvips]{epsfig}
 \newcommand{\prog}{\texttt}
 \newcommand{\param}{\texttt}
-\newcommand{\datei}{\texttt}
+\newcommand{\dateistyle}{\texttt}
 \newcommand{\nbname}{\texttt}
-\newcommand{\todo}{\texttt}
+\newcommand{\todo}[1]{}
 \newcommand{\defin}{\emph}
+\newcommand{\username}{\textbf}
 \hyphenation{Net-BIOS}
 
+\setcounter{tocdepth}{1}
+
 \usepackage{fancyheadings}
 \pagestyle{fancyplain}
 \lhead{}
 \rhead{\thepage}
-\rfoot{\copyright{} 1999, 2000, Volker Lendecke (http://www.sernet.de/vl/)}
+\rfoot{\copyright{} 1999, 2000, 2001, Volker Lendecke
+(http://www.sernet.de/vl/)}
 \cfoot{}
 
+\author{Volker Lendecke\\\texttt{VL@SerNet.DE}}
+\title{Samba for Runaways}
+
 \begin{document}
 
 \title{Kursskript\\[\baselineskip]
   \epsfig{file=logo.ps,width=6cm}}
 
 \author{Volker Lendecke\\
-Samba Team\\
 Service Network GmbH\\
 G"ottingen\\
+http://www.SerNet.DE/\\
 http://samba.SerNet.DE/}
 
 \date{\today}
@@ -59,29 +66,36 @@ http://samba.SerNet.DE/}
 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:
+Windows erscheinen. Das hei"st, man kann von Windows aus auf einen
+Unixrechner genau wie auf einen anderen Windowsrechner zugreifen. Der
+Clientrechner merkt gar nicht, da"s er es nicht mit einem echten
+Windowsserver zu tun hat. Im Detail bedeutet das, da"s sehr einfach
+Dateifreigaben erstellt werden k"onnen. Jeder Benutzer kann
+transparent Dateien auf seinem Heimatverzeichnis unter Unix und in
+anderen freigegebenen Verzeichnissen ablegen. Weiterhin kann man
+Drucker, die unter Unix ansprechbar sind, als Netzwerkdrucker in
+Windows ansprechen. 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[WINS-Server] Mit Samba kann sehr einfach ein WINS-Server
+  eingerichtet werden. Dieser stellt Namensdienste f"ur NetBIOS-Netze
+  zur Verf"ugung, damit sich Windows-Maschinen "uber Subnetzgrenzen
+  hinweg erreichen k"onnen
   
 \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
+\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[PDC] Die Funktionalit"at des echten Primary Domain Controller
+  ist nicht vollst"andig implementiert. F"ur viele Anwendungszwecke,
+  insbesondere Authentifizierung von NT-Workstation\-be\-nu\-tzern, reicht
+  Samba jedoch v"ollig aus.
   
 \item[Diagnosewerkzeuge] Samba bietet eine Reihe von kleinen, aber
 sehr effektiven Werkzeugen, die die oft m"uhselige Suche nach Fehlern
@@ -89,7 +103,7 @@ im Netz vereinfachen k"onnen.
 
 \end{description}
 
-Samba bietet gegen"uber den bekannten Implementationen des
+Samba bietet gegen"uber anderen Implementationen des
 SMB-Protokolls einige Vorteile. Teilweise sind diese Vorteile von Unix
 geerbt, teilweise sind sie in der Architektur von Samba begr"undet.
 
@@ -122,55 +136,197 @@ geerbt, teilweise sind sie in der Architektur von Samba begr"undet.
   
   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.
+  Verursacht also ein Client ein Problem auf Serverseite, wird
+  m"oglicherweise der f"ur diesen Client zust"andige Proze"s
+  abst"urzen. Die anderen Prozesse und damit Clients werden 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
+  erm"oglicht es, da"s auch Multiprozessormaschinen 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.
+  sind. Die meisten Optionen werden nur f"ur Spezialf"alle ben"otigt,
+  oder sind aus Kompatibilit"atsgr"unden zu sehr exotischen Clients
+  vorhanden.
+  
+  Soll Samba an spezielle Situationen angepa"st werden, ist es durch
+  ein sehr flexibles Schema von Makroersetzungen m"oglich, die
+  Konfigurationsdatei weitgehend dynamisch zu ver"andern. Damit sind
+  erheblich mehr Konfigurationsm"oglichkeiten gegeben als mit Windows.
+  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}
+
+Der Kostenaspekt ist hier bewu"st nicht mit aufgef"uhrt worden. Samba
+als freie Software\footnote{Samba wird hier bewu"st als \emph{freie}
+  Software im Sinne des GNU-Projektes verstanden. Samba ist dadurch
+  nat"urlich auch Open Source Software} ist unter den Bedingungen der
+GNU General Public License f"ur alle Zwecke kostenlos einsetzbar.
+Damit entstehen beim Einsatz von Samba keinerlei Lizenzkosten. Samba
+ist jedoch nicht kostenlos. Es m"ussen Administratoren eingewiesen
+werden, wenn Support ben"otigt wird, kann dieser viel Geld kosten.
+
+Das Hauptaugenmerk sollte hier auf dem Aspekt liegen, da"s Samba
+h"aufig einfach die technisch beste L"osung ist. Ein Kunde stand
+beispielsweise vor der Aufgabe, einige bestehende, kleinere NT-Server
+durch eine gr"o"sere L"osung zu ersetzen. Durch einen einzigen gro"sen
+NT-Server w"aren die bestehenden Server sehr wohl zu ersetzen gewesen.
+Das Problem bestand nun darin, da"s in vielen Dokumenten die
+vorhandenen Servernamen "uber Objektreferenzen auf vollst"andige
+UNC-Pfadnamen hart kodiert waren. Damit mu"sten die vorhandenen
+Servernamen definitiv erhalten bleiben, um nicht jedes Dokument
+anfassen zu m"ussen. Ein einziger Server unter NT kam also nicht in
+Frage, unter Samba jedoch sehr wohl. Samba erlaubt die Einrichtung
+virtueller Server unter verschiedenen Namen auf einer einzigen
+Maschine. Mehr dazu ab Seite \pageref{virtuelle-server}.
+
+\section{Eine einfache Konfiguration}
+
+F"ur den Anfang soll hier eine einfache Konfiguration beschrieben
+werden, mit der ein Samba-Server im Netz erscheint und einige, wenige
+Dienste anbietet. Diese einfache Konfiguration soll als Startpunkt das
+Experimentieren in den weiteren Kapiteln erleichtern. Die einzelnen
+Parameter werden hier kurz erkl"art, in weiteren Kapiteln gibt es
+ausf"uhrlichere Erkl"arungen.
+
+Samba wird mit der Datei \prog{smb.conf} konfiguriert. Je nach Unix
+oder Linux-Distribution kann diese Datei an unterschiedlichen Orten zu
+finden sein: \prog{/etc/smb.conf}, \prog{/etc/samba/smb.conf} oder
+auch \prog{/usr/local/samba/lib/smb.conf}, wenn Samba selbst
+kompiliert wurde. Wurde die Datei \prog{smb.conf} wie beschrieben
+angelegt, m"ussen zwei D"amonen gestartet werden: Der \prog{nmbd} und
+der \prog{smbd}. An dieser Stelle unterscheiden sich die Unix- und
+Linuxversionen erheblich, so da"s keine allgemeinen Hinweise gegeben
+werden k"onnen. Verschiedene M"oglichkeiten sind:
+
+\begin{verbatim}
+/etc/init.d/smb start
+/sbin/init.d/smb start
+/usr/local/samba/sbin/nmbd -D; /usr/local/samba/sbin/smbd -D
+rcsmb start
+\end{verbatim}
+
+Die \prog{smb.conf} f"ur eine einfache Konfiguration k"onnte so
+aussehen:
+
+\begin{verbatim}
+[global]
+   workgroup = samba
+   netbios name = sambaserver
+   interfaces = eth0
+
+   encrypt passwords = yes
+
+[homes]
+   valid users = %S
+   writeable = yes
+   browseable = no
+
+[cdrom]
+   path = /cdrom
 
+[public]
+   path = /pub
+   writeable = yes
+\end{verbatim}
+
+Wenn man mit dieser Einstellung Zugriff auf den Server erm"oglichen
+m"ochte, mu"s man f"ur jeden Benutzer einen Eintrag in der Datei
+\dateistyle{smbpasswd} machen, da verschl"usselte Pa"sw"orter
+(\param{encrypt passwords = yes}) eingesetzt werden. Dies geschieht
+beispielsweise f"ur den Benutzer \username{linux} "uber:
+
+\begin{verbatim}
+delphin:~ # smbpasswd -a linux
+New SMB password:
+Retype new SMB password:
+Added user linux.
+delphin:~ #
+\end{verbatim}
+
+Die einzelnen Zeilen haben folgende Wirkung:
+
+\begin{description}
+\item[\param{[global]}] leitet globale Servereinstellungen ein. Alle
+  anderen Abschnitte beschreiben Freigaben.
+\item[\param{workgoup = samba}] legt die Arbeitsgruppe fest, in der
+  der Server auftauchen soll.
+\item[\param{netbios name = sambaserver}] gibt dem Server einen Namen,
+  unter dem er im Netz erscheint.
+\item[\param{interfaces = eth0}] beschreibt das Netzwerkinterface, auf
+  dem Samba Dienste anbieten soll. Selbst wenn der Rechner nur ein
+  einziges Netzwerkinterface hat, sollte dieser Parameter angegeben
+  werden. Die vorhandenen Interfaces bekommt man bei den meisten
+  Unixsystemen "uber den Befehl \prog{netstat -ian} heraus.
+  \todo{netstat -ian?}
+\item[\param{encrypt passwords = yes}] verlangt vom Client, da"s keine
+  Klartextpa"sw"orter "ubertragen werden. Mit modernen Clients gibt es
+  Probleme, wenn man diese Option nicht aktiviert. Au"serdem m"ochte
+  man aus Sicherheitsgr"unden seine Pa"sw"orter nicht allen mitteilen.
+\item[\param{[homes]}] leitet die Freigabe der Heimatverzeichnisse
+  s"amtlicher Benutzer ein. Jeder Benutzer bekommt eine eigene
+  Freigabe unter seinem eigenen Namen und hat damit einen eigenen
+  Bereich, auf dem er schreiben kann.
+\item[\param{valid users = \%S}] beschr"ankt den Zugriff auf den
+  Benutzer, der sich verbinden m"ochte.
+\item[\param{writeable = yes}] vergibt Schreibrecht auf die Freigabe.
+  Standardm"a"sig wird nur Lesezugriff vergeben.
+\item[\param{browseable = no}] versteckt die Freigabe \param{[homes]}
+  in der Netzwerkumgebung. Der Client zeigt sie nicht mehr als
+  \param{[homes]} an, sondern nur noch unter dem Benutzernamen.
+\item[\param{[cdrom]}] leitet eine weitere Freigabe ein.
+\item[\param{path = /cdrom}] gibt den genannten Pfad frei. Dieser mu"s
+  selbstverst"andlich im Dateisystem existieren.
+\item[\param{[public]}] macht noch eine Freigabe im Netz. Die
+  Parameter sollten jetzt selbsterkl"arend sein.
 \end{description}
 
+Mit dieser minimalen \dateistyle{smb.conf} sollte es auf jeden Fall
+m"oglich sein, auf den Rechner zuzugreifen. Wenn man Probleme mit der
+Konfiguration weiterer Dienste bekommt, sollte man von einer
+m"oglichst einfachen Konfiguration ausgehen und dann Schritt f"ur
+Schritt weitere Parameter hinzunehmen.
+
+
+
 \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
+  Umgebungen nicht mehr richtig. Microsoft hat bei Windows 2000 die
+  NetBIOS-Ebene abgeschafft, Windows 2000 kommuniziert direkt "uber
+  TCP. Aus Kompatibilit"atsgr"unden kann Windows 2000 jedoch noch
+  "uber NetBIOS kommunizieren.}. Was ist NetBIOS? Je nachdem, wen man
+fragt, bekommt man unterschiedliche Antworten. Fragt man IBM, ist
+NetBIOS ein Protokoll, viele andere bezeichnen NetBIOS als 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
+kleinen, lokalen Netzen Kommunikation zu erm"oglichen. Beim Entwurf
+von NetBIOS wurde zun"achst darauf geachtet, die Dinge sehr einfach zu
+halten, um sie in kleinen lokalen Netzen anwendbar zu machen. Auf
 Skalierbarkeit und die Andwendung in Weitverkehrsnetzen wurde beim
 Design nicht geachtet.
 
+\subsection{NetBIOS-Dienste}
+
 Die Kommunikation mit NetBIOS wurde in drei Teilbereiche aufgeteilt,
-den Namensdienst, den Datagramm- und den Sitzungsdienst.
+den Namens-, den Datagramm- und den Sitzungsdienst.
 
 \begin{description}
   
@@ -180,40 +336,48 @@ den Namensdienst, den Datagramm- und den Sitzungsdienst.
   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.
+  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. Aufeinanderfolgende Pakete k"onnen au"serdem in
+  vertauschter Reihenfolge beim Empf"anger ankommen. Es kann sogar
+  sein, da"s Pakete auf dem Weg dupliziert werden, also mehrfach
+  ankommen.
+  
+  Ein solches Netzwerk ist folglich zun"achst einmal unzuverl"assig.
+  Diese Unzuverl"assigkeit des Netzes wird durch den Datagrammdienst
+  an die Benutzerprogramme weitergegeben. Das hei"st, wenn ein
+  Programm den Datagrammdienst nutzt, kann es nicht sicher sein, da"s
+  die Daten"ubertragung gew"ahrleistet ist. Das Programm mu"s selbst
+  daf"ur sorgen, da"s mit Paketverlust vern"unftig umgegangen wird.
+  
+  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.
+  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}
 
+\subsection{NetBIOS-Namensdienst}
+
 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
@@ -223,22 +387,25 @@ 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
+Wollen zwei Anwendungen per NetBIOS miteinander kommunizieren, 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
+  Unbenutzbarkeit zu st"oren. Man mu"s nur den Namen der Dom"ane mit
+  dem Namenstyp \nbname{1d} zum richtigen Zeitpunkt reservieren und
+  reserviert halten. Dann bootet der PDC nicht mehr sauber.}.
+
+Eine Reservierung geschieht, 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.
+wartet er auf Protest. Beklagt sich niemand, schickt er einen zweiten
+Reservierungsversuch und wartet wieder. Nach dem dritten
+Reservierungsversuch 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
@@ -247,6 +414,8 @@ Client jedoch die MAC-Adresse des Servers herausbekommen. Die
 Mechanismen, wie dies geschieht, h"angen davon ab, wie NetBIOS
 implementiert ist.
 
+\subsection{NetBIOS-Implementationen}
+
 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.
@@ -289,7 +458,7 @@ denen ein Rechner die MAC-Adresse des Servers herausbekommt.
   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
+  IPX-Router erkennen jedoch diese Namensanfragen und leiten sie per
   Broadcast in s"amtliche angeschlossenen Netze weiter, so da"s die
   Anfrage jedes Teilnetz erreicht.
   
@@ -311,11 +480,37 @@ denen ein Rechner die MAC-Adresse des Servers herausbekommt.
   beschrieben werden.
   
   Nachdem die IP-Adresse herausgefunden wurde, kommen die bekannten
-  Mechanismen von IP zum tragen. Befindet sich der Rechner im eigenen
+  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.
+  
+  Wenn NetBIOS "uber TCP/IP verwendet wird, kommen folgende Protokolle
+  und Ports zum Einsatz:
+
+  \label{protokolle-und-ports}
+%  \begin{tabular}{|L|L|L|L|}\hline
+%    \LCC
+%    \tabulargray&\tabulargray&\tabulargray&\tabulargray\\
+%    \tabularheader{Dienst}&\tabularheader{Protokoll}&\tabularheader{Port}&
+%    \tabularheader{Proze"s}\\
+%    \hline
+%    \ECC
+%    &&&\topseparation
+%    Namensdienst & UDP &137 & \prog{nmbd} \\
+%    Datagrammdienst & UDP &138 & \prog{nmbd} \\
+%    Sitzungsdienst & TCP &139 & \prog{smbd}
+%    \bottomseparationline
+%  \end{tabular}
+  \begin{center}\begin{tabular}{|l|l|l|l|}\hline
+    Dienst&Protokoll&Port&Samba-Proze"s\\
+    \hline\hline
+    Namensdienst & UDP &137 & \prog{nmbd} \\\hline
+    Datagrammdienst & UDP &138 & \prog{nmbd} \\\hline
+    Sitzungsdienst & TCP &139 & \prog{smbd}\\\hline
+  \end{tabular}
+\end{center}
 
 \end{description}
 
@@ -367,7 +562,14 @@ 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.
+benutzen. Daher werden die anderen Protokolle ab hier ignoriert. F"ur
+ein gut funktionierendes Netzwerk ist es jedoch sehr wichtig, da"s auf
+den Clients nur die Protokolle installiert sind, die \emph{wirklich}
+ben"otigt werden. Ist beispielsweise noch NetBEUI zus"atzlich zu
+TCP/IP installiert, ist nicht klar, ob die Netzwerkumgebung in der
+NetBEUI- oder die in der TCP/IP-Welt gelten soll. Normalerweise ist
+heute ausschlie"slich noch TCP/IP notwendig. IPX kann dann noch
+ben"otigt werden, wenn es Novellsysteme im Netz gibt.
 
 \section{Bestandteile von Samba}
 
@@ -375,21 +577,20 @@ Das Programmpaket Samba besteht aus mehreren Programmen, von denen
 einige der Serverseite und andere der Clientseite zugeordnet werden
 k"onnen.
 
-Die Servertools:
+\subsection{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
+  \prog{smbd}s im System finden. Einer dieser Prozesse h"ort 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
+  Verbindung st"o"st einen neuen \prog{smbd} Proze"s 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
+  Jeder \emph{aktive} Client ben"otigt etwa 1-2 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
@@ -397,59 +598,69 @@ Die Servertools:
   
 \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.
+  entsprechenden NetBIOS-Namen, er kann WINS-Server sein und ist 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
+\item[testparm] Mit diesem Programm kann man die \dateistyle{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.
+  
+\item[smbcontrol] Mit diesem Programm lassen sich die D"amonen von
+  Samba kontrollieren. Beispielsweise kann man f"ur einzelne D"amonen
+  den Debuglevel gezielt auf einen gew"unschten Wert setzen.
 
 \end{description}
 
-Die Clients:
+\subsection{Die Clients}
 
 \begin{description}
   
-\item[smbclient:] Mit dem Programm \prog{smbclient} kann man auf
+\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.
+  tar-Dateien sichern. Weiterhin kann mit \prog{smbclient} die Liste
+  der Server im Netz erfragt werden, 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
+  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 unter Windows ist das
   Kommandozeilenprogramm \prog{nbtstat}.
+  
+\item[smbcacls:] Mit diesem Programm lassen sich von Unix aus Access
+  Control Lists auf Windows-Dateien auslesen und setzen. Ist Samba mit
+  ACL-Support kompiliert, geht dies selbstverst"andlich auch f"ur die
+  auf Unix abgelegten Dateien.
 
 \end{description}
 
-Auf der Serverseite finden sich noch weitere Komponenten:
+\subsection{Weitere Serverkomponenten}
 
 \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}.
+  Regel unter \dateistyle{/etc/smb.conf}. Wurde Samba selbst
+  kompiliert, so liegt sie h"aufig unter
+  \dateistyle{/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}.
+  besondere Optionen selbst kompiliert, liegt dieses Verzeichnis unter
+  \dateistyle{/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.
+  verschl"usselten Pa"s\-w"ortern gearbeitet wird. Bei selbst
+  kompilierten Sambaversionen liegt diese Datei h"aufig im Verzeichnis
+  \dateistyle{/usr/local/samba/private/}.
 
 \end{description}
 
@@ -457,7 +668,7 @@ Auf der Serverseite finden sich noch weitere Komponenten:
 
 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:
+sollte die Datei \dateistyle{smb.conf} folgenderma"sen aussehen:
 
 \begin{verbatim}
 [global]
@@ -466,7 +677,7 @@ interfaces = <IP-Adresse>/<Netzmaske>
 \end{verbatim}
 
 \label{aufbau-smb.conf}
-Der grunds"atzliche Aufbau der \datei{smb.conf} gleicht dem Aufbau der
+Der grunds"atzliche Aufbau der \dateistyle{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.
@@ -482,25 +693,35 @@ 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.
+von Samba garantiert wird. Sp"ater wird deutlich werden, da"s gro"se
+Teile der Kommunikation auf Broadcasts basieren. Mit \prog{netstat
+  -ia} bekommt man auf den meisten Unix-Systemen Informationen "uber
+die vorhandenen Netzwerkinterfaces. Mit \prog{ifconfig <interface>}
+kann man sich dann n"ahere Informationen anzeigen lassen.
+
+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 Samba 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.
+
+Meistens funktioniert zus"atzlich zur Notation
+
+\begin{verbatim}
+interfaces = <IP-Adresse>/<Netzmaske>
+\end{verbatim}
+
+\noindent auch \prog{interfaces = <Interface-Name>}.
 
 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.}
+der Netzwerkumgebung sehen. Will man Tests auf NetBIOS-Ebene
+durchf"uhren, sollte man zur Vereinfachung zwei weitere Parameter
+setzen. Mit diesen drei Parametern bekommt man einen \emph{komplett
+  offenen} Server. Die Parameter werden in sp"ateren Abschnitten
+genauer erkl"art. Die vollst"andige \dateistyle{smb.conf} sieht
+folgenderma"sen aus:
 
 \begin{verbatim}
 [global]
@@ -510,8 +731,11 @@ security = share
 encrypt passwords = yes
 \end{verbatim}
 
-Mit dieser Konfiguration kann Samba gestartet werden. Unter SuSE Linux
-geschieht dies mit dem Aufruf:
+Mit dieser Konfiguration kann Samba gestartet werden. Es werden die
+beiden D"amonen \prog{nmbd} und \prog{smbd} ben"otigt. Diese kann man
+direkt von der Kommandozeile starten.
+
+Setzt man SuSE Linux ein, so kann man Samba mit dem Aufruf
 
 \begin{verbatim}
 rcsmb start
@@ -519,9 +743,7 @@ rcsmb start
 
 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.
+\dateistyle{/etc/rc.config} auf \texttt{yes} gesetzt werden.
 
 Es ist denkbar, den Aufruf beider Programme durch den \prog{inetd}
 durchf"uhren zu lassen. Bei Samba ist dies jedoch nicht sinnvoll.
@@ -553,22 +775,20 @@ vlendec@linux:/home/vlendec>
       
 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
+versendet, das hei"st an 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
+\param{interfaces =} der \dateistyle{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
+\begin{quote}\begin{small}\begin{verbatim}
+vlendec@delphin:~ > nmblookup -B 192.168.234.31 server
+querying server on 192.168.234.31
 name_query failed to find name server
-vlendec@linux:/home/vlendec>
-\end{verbatim}\end{small}
-\end{quote}
+vlendec@delphin:~ >
+\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
@@ -582,21 +802,37 @@ 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}.
+  \textbackslash{}\textbackslash{}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.
-
+Mit \prog{nmblookup} und \prog{nbtstat} 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{nmblookup -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.
+
+\begin{quote}\begin{small}\begin{verbatim}
+vlendec@delphin:~ > nmblookup -A 192.168.234.5
+Looking up status of 192.168.234.5
+received 6 names
+        NT4WKS          <00> -         B <ACTIVE>
+        SAMBA           <00> - <GROUP> B <ACTIVE>
+        NT4WKS          <03> -         B <ACTIVE>
+        ADMINISTRATOR   <03> -         B <ACTIVE>
+        NT4WKS          <20> -         B <ACTIVE>
+        SAMBA           <1e> - <GROUP> B <ACTIVE>
+num_good_sends=0 num_good_receives=0
+
+vlendec@delphin:~ >
+\end{verbatim}\end{small}\end{quote}
+  
 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
+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>}
@@ -608,11 +844,12 @@ 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
+als Einzelname 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.
+zu reservieren, ohne sich gegenseitig zu st"oren. Der Wert des
+Typfeldes wird hexadezimal in spitzen Klammern angegeben.
 
 Zun"achst die Einzelnamen, die h"aufig auftauchen:
 
@@ -632,8 +869,8 @@ 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
+\item[arbeitsgruppe$<$1d$>$] Dieser Rechner ist der so genannte
+  \defin{Locale Master Browser}, der die Liste s"amtlicher Rechner in
   der Netzwerkumgebung pflegt.
   
 \item[arbeitsgruppe$<$1b$>$] Dieser Rechner ist der \defin{Domain
@@ -651,23 +888,82 @@ Einige Gruppennamen werden ebenfalls reserviert:
   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}.
+\item[arbeitsgruppe$<$1c$>$] Jeder Domain Logon Server reserviert
+  diesen Namen f"ur sich. Clients finden ihre Domain Controller "uber
+  diesen NetBIOS-Namen.
+  
+\item[arbeitsgruppe$<$1e$>$] Wahlen zum Local Master Browser werden
+  "uber diesen Namen abgewickelt. Siehe hierzu Kapitel
+  \ref{netzwerkumgebung}.
 
 \end{description}
 
+Damit sind die f"ur Datei- und Druckerdienste wichtigsten Namenstypen
+beschrieben. Sobald unter NT andere Dienste installiert werden, kommen
+andere Namenstypen hinzu. Exchange zum Beispiel nutzt die Namenstypen
+22, 23 und 24. Mehr Namenstypen findet man in der Microsoft Knowlegde
+Base unter Artikel Nummer Q163409.
+
 \section{Netzwerkumgebung}
 \label{netzwerkumgebung}
 
+Die Netzwerkumgebung ist eine Anzeige, in der s"amtliche Server im Netz
+aufgef"uhrt sind. Alle Rechner, die Datei- oder Druckfreigaben
+zur Verf"ugung stellen, erscheinen dort oder sollten es zumindest, wenn alles
+reibungslos funktioniert. Jeder Client, der auf eine solche Resource
+zugreifen m"ochte, kann sich die Liste der Server im Netz geben lassen. Damit
+diese Anzeige nicht zu un"ubersichtlich ger"at, werden die Rechner in so
+genannte Arbeitsgruppen aufgeteilt. Jeder Rechner wird einer Arbeitsgruppe
+zugeordnet, in erscheint und die er als erstes beim Doppelklick auf das
+Symbol "`Netzwerkumgebung"' angezeigt. Die anderen Arbeitsgruppen sind
+ebenfalls "uber den Unterzweig "`Gesamtes Netzwerk"' sichtbar.
+
+Bez"uglich des Zugangs zu Arbeitsgruppen findet keinerlei Authentifizierung
+statt. Jeder Rechner kann frei f"ur sich entscheiden, in welcher Arbeitsgruppe
+er erscheinen m"ochte, jeder im Netz kann sich beliebige Arbeitsgruppen
+anzeigen. Dies gilt ebenfalls, wenn im Netz mit NT-Dom"anen gearbeitet wird.
+NT-Dom"anen haben nur eher zuf"allig im Netz ein der Arbeitsgruppe "ahnliches
+Erscheinungsbild.
+
+Das klingt verwirrend, ist es vermutlich beim ersten Lesen auch. Zum
+Verst"andnis des Windows-Networking mu"s man drei Begriffe ganz klar
+von einander trennen:
+
+\begin{description}
+\item[NetBIOS] Unter jeglicher Kommunikation von Windowsrechnern liegt
+  das API NetBIOS. Mit Hilfe des NetBIOS sind Rechner im Netz
+  ansprechbar, sie k"onnen verschiedenste Dienste anbieten. Einer
+  dieser Dienste ist die Netzwerkumgebung.
+\item[Arbeitsgruppe] Eine Arbeitsgruppe ist eine reine Liste von
+  Rechnern. Sie hat mit NetBIOS \emph{ausschlie"slich} als
+  Transportmedium zu tun. Der Dienst, der die Netzwerkumgebung bereit stellt,
+k"onnte theoretisch vollst"andig unabh"angig von NetBIOS implementiert werden,
+ist in der Praxis aber sehr von einem funktionierenden NetBIOS abh"angig. 
+  
+\item[Dom"ane] Eine Dom"ane bezeichnet etwas v"ollig anderes als eine
+  Arbeitsgruppe.Eine Dom"ane ist eine gemeinsam genutzte
+  Benutzerdatenbank. Microsoft hat in seiner Implementation einer
+  Dom"ane die Einschr"ankung gemacht, da"s alle Rechner einer Dom"ane
+  in einer Arbeitsgruppe auftauchen m"ussen. Das hei"st aber nicht,
+  da"s alle Rechner in der Arbeitsgruppe einer Dom"ane auch die
+  gemeinsame Benutzerdatenbank nutzen m"ussen.
+\end{description}
+
+Das Auftauchen eines Rechners in der Netzwerkumgebung hat nichts mit
+seiner Erreichbarkeit zu tun, es ist h"ochstens ein vager Hinweis
+darauf, da"s man es dort einmal versuchen kann. Ein Rechner
+erreichbar sein, aber nie auftauchen, oder er kann in der
+Netzwerkumgebung stehen, aber lange nicht mehr erreichbar sein.
+
 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
+Eine naive Implementation k"onnte so aussehen: Jeder Rechner,
+der Serverdienste anbietet, teilt dies regelm"a"sig per Broadcast im Netz
+mit. 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
@@ -675,31 +971,38 @@ 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.
+Der \defin{Local Master Browser\footnote{Der Local Master Browser
+    wird in der deutschen Dokumentation von Windows
+    \emph{Computersuchdienst} genannt. Der Domain Master Browser ist
+    der Dom"anenhauptsuchdienst. Local Master Browser finde ich sehr
+    viel handlicher, und daher werde ich den englischen Begriff
+    verwenden.}} (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 Local Master Browser gibt.  Beispielsweise
+kann der Explorer von Windows eine solche Wahl ansto"sen. Wenn Windows
+95 beim "Offnen der Netzwerkumgebung 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.
+beispielsweise das Betriebssystem des versendenden Rechners. Hieraus folgt,
+da"s es in einem Subnetz f"ur jede vorhandene Arbeitsgruppe einen LMB gibt.
 
 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.
+Paket jedoch von einem Rechner mit Windows 95, so h"alt sie sich
+selbst f"ur geeigneter, den Local 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}
@@ -712,10 +1015,10 @@ 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.
+"uberl"a"st jedoch Windows NT Rechnern den Local Master Browser.
 
-Drei Parameter in der \datei{smb.conf} bestimmen das Verhalten von
-Samba in der Wahl zum Lokalen Master Browser:
+Drei Parameter in der \dateistyle{smb.conf} bestimmen das Verhalten von Samba
+in der Wahl zum Local Master Browser:
 
 \begin{description}
   
@@ -731,16 +1034,17 @@ Windows 95/98 & 1 \\
 \hline
 Windows NT Workstation & 16 \\
 \hline
+Samba & 20 \\
+\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.
+der Software f"ur den Local 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.
+"ubernimmt.
 
 Der Parameter \param{os level} kann Werte von 0 bis 255 annehmen.
 Setzt man ihn auf 255, wird nach einer erfolgreichen Wahl niemand mehr
@@ -755,30 +1059,36 @@ Local Master Browser werden k"onnen.
   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.
+  anhand seines \param{os level} ein.
 
 \end{description}
 
-Mit den Einstellungen
+Es ist sehr sinnvoll, den Local Master Browser st"andig auf einer
+festen Maschine laufen zu lassen. H"aufige Wechsel des Local Master
+Browser lassen die Netzwerkumgebung aus zwei Gr"unden sehr instabil
+werden. Erstens m"ussen sich die Server im Netz h"aufig an neuen Local
+Master Browsern anmelden. Diese Anmeldung erfolgt per UDP und kann
+auch mal fehlschlagen. Zweitens kann es passieren, da"s ein Client den
+Wechsel eines Local Master Browser nicht mitbekommt und Informationen
+von einem nicht mehr aktuellen Local Master Browser beziehen m"ochte.
+Ein Sambaserver ist typischerweise eine Maschine, die als Server
+durchl"auft und auch deutlich stabiler als Windows-Clients ist. Mit
+den Einstellungen
 
 \begin{verbatim}
 [global]
-os level = 66
+os level = 100
 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.
+kann man sicher sein, da"s der Sambarechner immer den Local Master
+Browser innehat. \param{preferred master = yes} stellt sicher, da"s
+beim Start von Samba eine Wahl angesto"sen wird, und mit \param{os
+  level = 100} gewinnt Samba diese Wahl gegen alle anderen Maschinen
+im Netz. 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.
 
 \section{NetBIOS "uber Subnetzgrenzen}
 
@@ -812,9 +1122,13 @@ werden, wenn er in seinem Subnetz nicht der LMB ist.
 \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
+Die wenigsten Firmen haben heutzutage nur ein einziges LAN. Entweder
+sind verschiedene Geb"aude oder Standorte mit Routern verbunden, oder
+jemand w"ahlt sich in das Firmennetz ein. In diesen F"allen
+funktioniert die Namensaufl"osung nicht mehr wie beschrieben. 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]\[
@@ -840,36 +1154,63 @@ 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.
 
+\subsection{\nbname{LMHOSTS}}
+
 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
+liegt diese in der Datei \dateistyle{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
+"ahnlich aufgebaut wie die Datei \dateistyle{/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
+Die Eintr"age in der \dateistyle{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
+fehlschl"agt, wird in der \dateistyle{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.
+\dateistyle{LMHOSTS} verwendet.
+
+Die Namensaufl"osung "uber die Datei \dateistyle{LMHOSTS} hat wie die
+Datei \dateistyle{/etc/hosts} den entscheidenden Nachteil, da"s sie
+auf jedem Rechner einzeln gepflegt werden mu"s. Das macht diese Art
+der Namenspflege sehr schnell unwartbar. Die Syntax der
+\dateistyle{LMHOSTS} l"a"st einen einfachen Trick zu, mit dem zentral
+eine \dateistyle{LMHOSTS}\footnote{Zentrale LMHOSTS} vorgehalten
+werden kann, das Statement \nbname{\#INCLUDE}. Man stellt an zentraler
+Stelle eine Freigabe zur Verf"ugung, in der die \dateistyle{LMHOSTS}
+steht, und f"ugt sie automatisch bei jedem booten in die Liste auf den
+Clients ein.  Dazu mu"s einmalig auf den Clients die
+\dateistyle{LMHOSTS} folgenderma"sen aufgesetzt werden:
+
+\begin{verbatim}
+192.168.1.1 samba #PRE
+#INCLUDE \\samba\public\lmhosts
+\end{verbatim}
+
+Die einzelnen Werte sind nat"urlich den Gegebenheiten vor Ort
+anzupassen. Es ist darauf zu achten, da"s die Worte \nbname{\#PRE} und
+\nbname{\#INCLUDE} in Gro"sbuchstaben geschrieben sind. Bei den Namen
+selbst die Gro"sschreibung egal.
+
+\subsection{WINS}
+
+Die zweite M"oglichkeit, das Problem zu l"osen, ist ein zentraler
+Server, der die NetBIOS-Namen in einer Datenbank dynamisch pflegt.
+Dazu gibt es den WINS-Server.  Ein solcher Server ist ein Rechner, bei
+dem sich jede NetBIOS-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
+\dateistyle{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
@@ -904,21 +1245,21 @@ kann.
 \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.
+Samba kann als WINS-Server konfiguriert werden, indem der Parameter
+\param{wins support = yes} gesetzt wird. Ist dieser 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
+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
+\dateistyle{/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.
+Datei \dateistyle{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
+-HUP nmbd} senden. Au"serdem wird die \dateistyle{wins.dat} beim Beenden
 des \prog{nmbd} geschrieben.
 
 Diese Datenbank wird auf Festplatte gehalten, damit die Daten einen
@@ -946,14 +1287,14 @@ den WINS-Server, bei dem sich alle Rechner angemeldet haben.
 %\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
+Vorteile. Namensreservierung per Broadcast ben"otigt 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.
@@ -961,23 +1302,31 @@ 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
+WINS-Server geben. Setzt man mehrere WINS-Server ein, hat man
+getrennte Namensr"aume und handelt sich damit massive Probleme ein, da
+Windows Namen sowohl beim WINS als auch per Broadcast aufl"ost.
+
+Rechner im einen Namensraum k"onnen mit Rechnern, die an einem anderen
+WINS-Server angeschlossen sind, nicht kommunizieren, da die Namen
+nicht aufgel"ost werden k"onnen. Namen, die beim WINS nicht bekannt
+sind, werden von Windows zus"atzlich lokal per Broadcast aufgel"ost.
+Das hei"st, man findet beim einige Rechner nur per WINS, andere auch
+lokal. Die Fehlerdiagnose wird dadurch stark erschwert.
+
+Unter Windows NT kann man mehrere WINS-Server einsetzen, die sich
+gegenseitig abstimmen. Diese Replikation stellt sicher, da"s die
+Clients unabh"angig von der Anzahl der WINS-Server nur eine einzige
+Namensdatenbank sehen. Die WINS-Server stellen sich somit gegen"uber
+den Clients als eine konsistente Datenbank dar.
+
+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,
+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
@@ -985,34 +1334,141 @@ 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.
+mit \prog{wins server =} konfigurierten WINS-Server weiterleiten.
+Stellt man mit dieser Einstellung einen Samba-Server in ein Subnetz,
+werden 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
+\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
+Typischerweise wird er in der \dateistyle{/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
+\dateistyle{/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}
+\section{Windows-Namensaufl"osung im Detail}
+
+Um die Namensaufl"osung unter Windows zu verstehen, mu"s man zwei
+Arten von Anwendungen unterscheiden:
+
+\begin{description}
+\item[NetBIOS-Anwendungen:] Dies sind die klassischen
+  Windows-Programme, zum Beispiel um Laufwerke mit einem Server zu
+  verbinden, oder um Outlook mit dem Exchange-Server zu verbinden. Die
+  gesamte Netzwerkumgebung geh"ort ebenfalls zu den
+  NetBIOS-Anwen\-dun\-gen.
+\item[TCP/IP-Anwendungen:] Telnet, ping und Netscape geh"oren zu den
+  Anwendungen, die es nur in der TCP/IP-Protokollfamilie gibt. Bei
+  diesen funktioniert die Namensaufl"osung etwas anders als bei den
+  NetBIOS-Anwendungen.
+\end{description}
+
+Wenn eine {\bfseries NetBIOS-Anwendung} einen Namen aufl"osen will,
+dann geschieht dies in mehreren Schritten, die nacheinander
+ausgef"uhrt werden, bis der Name gefunden ist.
+
+\begin{enumerate}
+\item Das System schaut im NetBIOS-Namenscache nach. Dieser kann durch
+  \prog{nbtstat -c} vom Benutzer abgefragt werden.
+\item Ist ein WINS-Server konfiguriert, so wird dieser befragt.
+\item Kann der Name im WINS nicht aufgel"ost werden, so wird eine
+  Broadcast-Anfrage ausgel"ost.
+\item Es wird in der Datei \dateistyle{LMHOSTS} nachgesehen.
+\item Sofern in den Eigenschaften von TCP/IP die DNS-Aufl"osung f"ur
+  NetBIOS-Namen aktiviert ist, wird nun an das Aufl"osungssystem f"ur
+  TCP/IP-Anwendungen "ubergeben.
+\end{enumerate}
+
+Wenn man Namen in die Datei \dateistyle{LMHOSTS} eintr"agt, so werden diese
+erst nach den WINS- und Broadcast-Timeouts ber"ucksichtigt. Wenn man
+diese sofort aufgel"ost haben m"ochte, so kann man sie mit dem Zusatz
+\nbname{\#PRE} versehen. Dann werden sie beim n"achsten Reboot
+dauerhaft in den NetBIOS-Namenscache geladen. Im laufenden Betrieb
+kann man dieses Laden in den Namenscache durch ein \prog{nbtstat -R}
+erzwingen.
+
+Setzt man f"ur die IP-Adre"svergabe DHCP ein, kann man Windows-Clients
+die IP-Adresse des WINS-Servers auf diesem Weg mitteilen. Tut man
+dies, mu"s man den Clients ebenfalls einen Knotentyp zuweisen. Die
+oben beschriebene Tabelle gilt f"ur den Knotentyp 8, den sogenannten
+H-Knoten. Setzt man den Knotentyp auf 4, so bekommt man einen
+M-Knoten, der zuerst Broadcast und dann WINS ausf"uhrt. Diese
+Einstellung ist jedoch nur in Ausnahmef"allen sinnvoll, da jede
+Anfrage beim WINS die Broadcastlast im Netz reduziert.
+
+Die Namensaufl"osung f"ur {\bfseries TCP/IP-Anwendungen} ist
+einfacher.
+
+\begin{enumerate}
+\item Zun"achst wird in der Datei \dateistyle{HOSTS} nachgesehen.
+\item Ist ein DNS-Server konfiguriert, wird dieser befragt.
+\item Der DNS-Name wird, so wie er ist, an die
+  NetBIOS-Namensaufl"osung "ubergeben. Damit kann f"ur interne Systeme
+  vermeiden, sie ins DNS aufnehmen zu m"ussen. Will man etwa einen
+  Proxy unter dem Namen "`proxy"' einrichten, gen"ugt es, auf dieser
+  Maschine einen korrekt konfigurierten \prog{nmbd} zu installieren,
+  der den Namen "`proxy"' registriert. Damit kann man auf allen
+  Browsern einfach "`proxy"' eintragen.
+\end{enumerate}
+
+\todo{Tabelle}
+
+Die Namensaufl"osung von Samba ist weit weniger kritisch als die von
+Window-Systemen, da Samba in der Regel ausschlie"slich als Server
+auftritt. Samba als Server ist es gleichg"ultig, wie Namen aufgel"ost
+werden k"onnen. Es gibt zwei Situationen, in denen Samba Namen
+aufl"osen mu"s:
+
+\begin{description}
+\item[smbclient] Samba als Client mu"s offensichtlich Namen aufl"osen.
+\item[Samba als Dom"anenmitglied] Mit dem Parameter \param{password
+    server} wird Samba als Dom"anenmitglied mitgeteilt, welcher
+  Dom"anencontroller f"ur Pa"sw"orter zust"andig ist. Es ist enorm
+  wichtig, da"s f"ur diese Funktion die Namensaufl"osung korrekt
+  funktioniert.
+\end{description}
+
+Wie Windows kennt Samba vier Mechanismen zur Namensaufl"osung:
+Broadcast, WINS, LMHOSTS und die normale Unix-Namensaufl"osung. Die
+Reihenfolge, in der die Mechanismen abgefragt werden, wird durch den
+Parameter \param{name resolve order} festgelegt. Mit den vier Werten
+\param{bcast}, \param{wins}, \param{lmhosts} und \param{host} werden
+die vier Mechanismen beschrieben. Die Standardreihenfolge ist
+
+\begin{verbatim}
+name resolve order = lmhosts host wins bcast
+\end{verbatim}
+
+\noindent und legt fest, da"s vor der Windows-Namensaufl"osung zun"achst das
+DNS
+befragt wird. Dies ist h"aufig ein Problem f"ur \prog{smbclient}, da
+man m"oglicherweise auf einen DNS-Timeout warten mu"s, bevor die
+Windows-Namensaufl"osung benutzt wird. In vielen F"allen kann es von
+Vorteil sein, f"ur Samba als Client vollst"andig auf die
+DNS-Namensaufl"osung zu verzichten oder sie ans Ende der Liste zu
+stellen:
+
+\begin{verbatim}
+name resolve order = lmhosts wins bcast host
+\end{verbatim}
+
+\section{Browsing "uber Subnetzgrenzen}
+\label{browsing-im-wan}
 
 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
+betrachtet wurde, funktioniert sie nur in einem einzigen lokalen Netz.
+Die Wahl zum Local 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
@@ -1030,7 +1486,7 @@ 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}
+Originaldokumentation von Samba aus der Datei \dateistyle{BROWSING.txt}
 entnommen.
 
 \newcommand{\minicomputer}[1]{%
@@ -1069,19 +1525,19 @@ entnommen.
 \caption{Domain Master Browser}
 \end{figure}
 
-Dieses Netz besteht aus 3 Subnetzen (1,2,3), die durch 2 Router (R1
+Dieses Netz besteht aus drei Subnetzen (1,2,3), die durch zwei Router (R1
 und R2) verbunden sind. Die Router lassen keine Broadcasts durch. Alle
-Subnetze bestehen aus jeweils 4 Maschinen.  Nehmen wir der Einfachheit
+Subnetze bestehen aus jeweils vier 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
+Master Browser konfiguriert. Das hei"st, da"s er die Browserliste 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
+an, im Subnetz 1 gewinnt \nbname{N1B}, 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
@@ -1092,7 +1548,7 @@ 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
+Browserliste. In unserem Fall nehmen wir an, da"s alle Maschinen
 Serverdienste anbieten, das hei"st, da"s alle Maschinen in der Liste
 erscheinen.
 
@@ -1127,12 +1583,12 @@ 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
+Sehen wir uns nun Subnetz zwei 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
+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
@@ -1224,7 +1680,7 @@ Netz & LMB &  Liste \\ \hline \hline
 \end{tabular}\]
 \vspace{\baselineskip}
 
-Synchronisationen zwischen dem Domain Master Browser und den Lokalen
+Synchronisationen zwischen dem Domain Master Browser und den Local
 Master Browsern wird weiterhin auftreten, aber dies sollte den
 stabilen Zustand nur best"atigen.
 
@@ -1239,27 +1695,564 @@ so da"s sie in der Netzwerkumgebung weiterhin erscheinen.
 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
+\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}
 
+\subsection{Browsing mit vielen Arbeitsgruppen}
+
+Wenn man in der Netzwerkumgebung auf das Microsoft Windows Netzwerk
+klickt, bekommt man eine Liste s"amtlicher Arbeitsgruppen im Netz
+angezeigt. Diese Liste der Arbeitsgruppen wird vom Local Master
+Browser vorgehalten. Wie bekommt er diese Liste?
+
+Jeder Local Master Browser reserviert f"ur sich einen speziellen
+Gruppennamen, der folgenderma"sen dargestellt wird:
+\nbname{..\_\_MSBROWSE\_\_.<01>}. Die Punkte stehen dabei f"ur die
+Ascii-Werte eins und zwei. Regelm"a"sig wird jeder Local Master
+Browser seine Existenz an diesen Gruppennamen senden. Alle anderen
+Local Master Browser im Netz sammeln diese Ank"undigungen, damit sie
+Clients die Liste der vorhandenen Arbeitsgruppen und Local Master
+Browser mitteilen k"onnen.
+
+Wenn Domain Master Browser ins Spiel kommen, wird das Bild etwas
+komplizierter. Samba hat Erweiterungen implementiert, mit denen das
+Browsing "uber Subnetzgrenzen stabiler gemacht werden soll. Samba
+fragt den WINS-Server regelm"a"sig nach allen Domain Master Browsern.
+Diese werden in zuf"alligen Abst"anden kontaktiert, um die Browse
+Listen mit ihnen abzugleichen. Dadurch kann es passieren, da"s
+Arbeitsgruppen, die nicht mehr existieren, weiterhin in der
+Netzwerkumgebung auftauchen und sich nicht l"oschen lassen. Samba
+kennt den Parameter \param{enhanced browsing = no}, mit dem sich
+dieses Verhalten abstellen l"a"st.
+
+\section{Virtuelle Sambaserver}
+\label{virtuelle-server}
+
+Manchmal kann es notwendig sein, mehr als einen Sambaserver
+gleichzeitig auf einem Rechner laufen zu lassen. Zur
+Serverkonsolidierung kann es notwendig sein, unter mehreren Namen in
+der Netzwerkumgebung zu erscheinen. Dies ist mit dem Parameter
+\param{netbios aliases} sehr einfach m"oglich. Wenn es n"otig ist, in
+mehr als einer Arbeitsgruppe aufzutauchen, dann scheitert dies
+Verfahren jedoch, da der Parameter \param{workgroup} nur einmal
+angegeben werden kann.
+
+Eine andere Konfiguration ist die Einbindung von virtuellen Servern in
+eine Hochverf"ugbarkeitsumgebung. Es kann w"unschenswert sein, zwei
+physikalisch vorhandene Server unabh"angig voneinander arbeiten und
+sich gegenseitig "uberwachen zu lassen. Jeder der beiden Server hat
+seinen eigenen Namen und seine eigenen Freigaben. Stellt ein Server
+fest, da"s sein Partner defekt ist, mu"s er dessen Aufgaben
+"ubernehmen. Dies ist am einfachsten m"oglich, wenn die Aufgaben des
+defekten Servers isoliert in einer eigenen Samba-Instanz wahrgenommen
+werden. Die Hochverf"ugbarkeitssoftware mu"s nur daf"ur sorgen, da"s
+die Platten "ubernommen werden und der ausgefallene Dienst auf dem
+noch lebenden Server gestartet wird. Es ist keine Neukonfiguration des
+bereits laufenden Servers notwendig.
+
+Hier soll ein Beispiel aufgebaut werden, mit dem Samba auf einem
+Rechner f"ur verschiedene Arbeitsgruppen Local Master Browser
+wird. Ist dieser Rechner ein Unixserver, der 24 Stunden durchl"auft,
+kann so mit sehr einfachen Mitteln eine recht stabile Netzwerkumgebung
+f"ur beliebig viele Arbeitsgruppen erreicht werden.
+
+Zun"achst wird ein isolierter Local Master Browser f"ur die
+Arbeitsgruppe \nbname{GOETTINGEN} installiert. Der Name dieses
+Rechners soll der Einfachheit halber \nbname{GOE} hei"sen. Die gesamte
+Konfiguration wird unter \dateistyle{/samba/goe} abgelegt, so da"s sie
+recht einfach duplizierbar ist. Die Datei
+\dateistyle{/samba/goe/smb.conf} hat folgenden Aufbau:
+
+\begin{verbatim}
+[global]
+workgroup = goettingen
+netbios name = goe
+
+interfaces = eth0:1
+bind interfaces only = yes
+
+encrypt passwords = yes 
+smb passwd file = /samba/goe/smbpasswd
+
+log file = /samba/goe/var/log.smb
+lock directory = /samba/goe/locks
+
+os level = 100
+preferred master = yes
+\end{verbatim}
+\label{smbconf-goe}
+
+In dieser Konfigurationsdatei gibt es einige Einstellungen, die die
+Voreinstellungen vom Kompilieren "uberschreiben. Normalerweise finden
+sich die Logdateien unter Linux in \dateistyle{/var/log} oder bei
+selbstkompilierten Sambas in \dateistyle{/usr/local/samba/var}, hier
+sollen sie pro Server separat in einem eigenen Verzeichnis abgelegt
+werden.
+
+Die nicht offensichtlichen Einstellungen bedeuten:
+
+\begin{description}
+\item[bind interfaces only:] Normalerweise nimmt der \prog{smbd} auf
+  jeder im System konfigurierten IP-Adresse Verbindungen entgegen. Den
+  Vorgang, mit dem der \prog{smbd} dies dem Kernel mitteilt, nennt
+  sich "`An eine Adresse binden"'. Um auf jeder Adresse Verbindungen
+  entgegen zu nehmen, bindet Samba an die spezielle Adresse 0. Jede
+  konfigurierte IP-Adresse kann nur von einem einzigen Proze"s
+  gebunden werden. Versucht ein \prog{smbd}, eine bereits verwendete
+  Adresse zu binden, wird dies mit der Fehlermeldung \textbf{Address
+    already in use} verweigert. Mit \prog{bind interfaces only = yes}
+  wird der \prog{smbd} nur die im Parameter \prog{interfaces}
+  angegebenen Adressen beziehungsweise Interfaces verwenden.
+  
+  Der Unterschied wird im Vergleich zweier Ausgaben des Programms
+  \prog{netstat -nat} (hier unter Linux) deutlich. Zun"achst der
+  relevante Teil \emph{ohne} \param{bind interfaces only = yes}:
+
+\begin{verbatim}
+vlendec@server:~ > netstat -natu
+Active Internet connections (servers and established)
+Proto Recv-Q Send-Q Local Address           Foreign Address         State    
+ 
+tcp        0      0 0.0.0.0:139             0.0.0.0:*               LISTEN   
+  
+vlendec@server:~/ > 
+\end{verbatim}
+  
+  Im Vergleich dazu die Ausgabe des gleichen Programmaufrufs
+  \emph{mit} \param{bind interfaces only = yes}:
+
+\begin{verbatim}
+vlendec@server:~ > netstat -natu
+Active Internet connections (servers and established)
+Proto Recv-Q Send-Q Local Address           Foreign Address         State    
+ 
+tcp        0      0 192.168.42.1:139        0.0.0.0:*               LISTEN   
+  
+vlendec@server:~/ > 
+\end{verbatim}
+  
+  Mit \param{bind interfaces only = yes} wird ausschlie"slich an die
+  im Parameter \param{interfaces} referenzierte IP-Adresse gebunden,
+  so da"s sich mehrere \prog{smbd}s nicht st"oren.
+
+
+\item[log file:] Hier wird das Logfile nur f"ur den \prog{smbd}
+  festgelegt. Es ist m"oglich, f"ur alle Samba-Instanzen ein
+  gemeinsames Logfile zu verwenden, das kann jedoch sehr schnell
+  un"ubersichtlich werden. Der \prog{nmbd} ignoriert diese
+  Einstellung. Sein Logfile mu"s "uber den Kommandozeilenparameter
+  \prog{-l} festgelegt werden.
+\item[lock directory:] Die verschiedenen D"amonen von Samba
+  kommunizieren "uber viele Datenbanken miteinander. Sie haben die
+  Endung \dateistyle{.tdb}, und ihr Verzeichnis ist durch das
+  \param{lock directory} festgelegt. Jede Instanz von Samba ben"otigt
+  ihr eigenes \param{lock directory}, da die Datenbanken jeweils nur
+  f"ur eine Samba-Instanz ausgelegt sind.
+\end{description}
+
+Diese Samba-Instanz kann "uber die folgende Startdatei kontrolliert werden:
+
+\begin{verbatim}
+#!/bin/sh
+DIR=/samba/goe
+case "$1" in
+  start)
+    echo "Starte Samba in $DIR"
+    /usr/local/samba/bin/smbd -D -s $DIR/smb.conf
+    /usr/local/samba/bin/nmbd -D -s $DIR/smb.conf -l $DIR/var
+    ;;
+  stop)
+    echo "Fahre Samba in $DIR herunter"
+    kill -TERM $(cat $DIR/locks/smbd.pid)
+    kill -TERM $(cat $DIR/locks/nmbd.pid)
+    ;;
+  *)
+    echo "Usage: $0 [start|stop]"
+    ;;
+esac
+\end{verbatim}
+
+Diese Installation von Samba ist so weit isoliert, da"s eine zweite
+ungest"ort gleichzeitig laufen kann. Um jetzt eine zweite Installation
+zu bauen, m"ussen folgende Dinge angepa"st werden:
+
+\begin{description}
+\item[workgroup:] Die Arbeitsgruppe mu"s nur in dem aktuell
+  verwendeten Beispiel der Local Master Browser ge"andert werden. Ein
+  zweites Samba kann selbstverst"andlich auch in der gleichen
+  Arbeitsgruppe sein.
+\item[netbios name:] Jede Instanz braucht zwingend ihren eigenen
+  Namen.
+\item[interfaces:] Jede Instanz ben"otigt ihre eigene IP-Adresse.
+\item[smb passwd file:] Falls jede der Instanzen ihre eigene
+  Benutzerdatenbank m"ochte, so mu"s die Datei \dateistyle{smbpasswd}
+  separat angelegt werden. Die Unix-Benutzerdatenbank teilen jedoch
+  alle Instanzen. Das hei"st, Benutzer \username{meier} auf der einen
+  Instanz wird immer der gleiche Unixbenutzer wie Benutzer
+  \username{meier} auf allen anderen Instanzen sein.  Wenn man die
+  gleiche Benutzerdatenbank ben"otigt, kann man auf die gleiche
+  \dateistyle{smbpasswd} zugreifen. Empfehlenswerter ist es jedoch,
+  eine der beiden Instanzen als Dom"anencontroller einzurichten und
+  die andere als Dom"anenclient. Dann kann man v"ollig ohne
+  Unterbrechung die gesamte Konfiguration komplett auf einen anderen
+  Rechner migrieren, ohne da"s irgend etwas ge"andert werden m"u"ste.
+  Insbesondere f"ur Hochverf"ugbarkeitsl"osungen ist dies die
+  Konfiguration der Wahl.
+\item[log file:] Dies kann f"ur alle Instanzen gleich sein, meistens
+  wird man jedoch separate logfiles f"ur die einzelnen \prog{smbd}s
+  haben wollen.
+\item[lock directory:] Dieses mu"s zwingend f"ur jede Instanz separat
+  angelegt werden.
+\end{description}
+
+Als letztes ist die Variable DIR in der Startdatei anzupassen, und
+mehreren Instanzen von Samba steht nichts mehr im Wege.
+
+\section{Browsing im WAN -- schneller}
+
+Das im Kapitel \ref{browsing-im-wan} beschriebene Verfahren, mit dem
+"uber Subnetzgrenzen hinweg die Netzwerkumgebung gepflegt wird, ist
+au"serordentlich tr"age. Jede "Anderung mu"s vom Local Master Browser
+an den Domain Master Browser "ubergeben werden und von dort aus wieder
+an die anderen Local Master Browser zur"uck. Bis diese "Anderung beim
+Client ankommt, kann es sehr lange dauern.
+
+Zudem ist bei einem komplexen Setup die Zahl der beteiligten Rechner
+sehr hoch. Als Beispiel sei ein Netz auf 4 Subnetze verteilt. Jeder
+Mitarbeiter ist einer von 5 verschiedenen Arbeitsgruppen zugeteilt.
+Nun ist es gefordert, da"s die Mitarbeiter sich im Netz frei bewegen
+k"onnen m"ussen, da"s sie also unabh"angig von ihrem Standort im Netz
+immer ihre eigene Arbeitsgruppe vorfinden m"ussen. Dazu mu"s
+selbstverst"andlich ein WINS-Server eingerichtet sein. Damit das
+Browsing funktioniert, mu"s es zudem f"ur jede Arbeitsgruppe einen
+Domain Master Browser geben, der sich mit den jeweiligen Local Master
+Browsern abgleicht. Die Zahl der Local Master Browser ist hier recht
+hoch. Da jeder Mitarbeiter in jedem Subnetz seine Arbeitsgruppe sehen
+soll, mu"s es in jedem Subnetz f"ur jede Arbeitsgruppe einen eigenen
+Local Master Browser geben. Das hei"st, es werden 20 Local Master
+Browser ben"otigt.
+
+Um das folgende Beispiel zu verstehen, sollte man sich
+vergegenw"artigen, von welchen Rechnern welche Information bezogen
+wird, wenn man im Explorer die Netzwerkumgebung durchklickt. Man kann
+die Vorg"ange sehr gut nachvollziehen, wenn man an einer frisch
+angemeldeten Sitzung mit \prog{nbtstat -s} die aktiven
+NetBIOS-Sitzungen nach jedem Schritt nachvollzieht. Direkt nach dem
+anmelden sollte keine NetBIOS-Sitzung aktiv sein, mit jedem Klick in
+der Netzwerkumgebung kommt gegebenenfalls eine Verbindung hinzu.
+
+\begin{description}
+\item[Netzwerkumgebung:] Hier wird die eigene Arbeitsgruppe
+  dargestellt. Diese Information liefert der eigene Local Master
+  Browser. Dieser wird "uber eine Broadcast-Anfrage auf den Namen der
+  eigenen Arbeitsgruppe vom Typ \nbname{<\#1d>} herausgefunden.
+\item[Gesamtes Netzwerk:] Dieser Schritt liefert nur die lokal
+  installierten Clientsysteme. Wenn ein Novell-Client installiert ist,
+  wird hier das Novell-Netz neben dem Microsoft Windows-Netzwerk
+  angeboten, ansonsten nur das Microsoft-Windows Netzwerk. Da dies
+  rein lokal passiert, wird es keine zus"atzliche Verbindung geben.
+\item[Microsoft Windows Netzwerk:] Hier wird die Liste der
+  verf"ugbaren Arbeitsgruppen angezeigt. Diese Information liefert
+  ebenfalls der eigene Local Master Browser. Das kann man sich mit
+  einem \prog{smbclient -L} \emph{ lmb} verdeutlichen. Neben der Liste der
+  Freigaben und der Server liefert der LMB eine Liste der
+  Arbeitsgruppen, die er kennt. Zus"atzlich gibt er noch den jeweils
+  zust"andigen Local Master Browser heraus.
+\item[Arbeitsgruppe:] Diese Information liefert der jeweilige Local
+  Master Browser. Der eigene Local Master Browser hat im letzten
+  Schritt dessen Namen herausgegeben. Dessen IP-Adresse findet der
+  Client durch eine normale NetBIOS-Namensanfrage heraus.
+\item[Freigabeliste:] Ein Rechner ist f"ur seine Freigaben selbst
+  verantwortlich, nur der Rechner selbst kann die Liste der von ihm
+  freigegebenen Verzeichnisse herausgeben.
+\end{description}
+
+Gibt ein Rechner Informationen der genannten Art heraus, dann
+geschieht dies "uber eine vollst"andig aufgebaute SMB-Sitzung, die auf
+einer NetBIOS-Sitzung aufbaut. Kapitel \ref{smb-sitzungen} beschreibt
+dies im Detail. Wie auf Seite \pageref{protokolle-und-ports}
+dargestellt, nutzt der NetBIOS-Sitzungsdienst TCP "uber Port 139.
+
+\subsection{Trennung von \prog{nmbd} und \prog{smbd}}
+
+Die folgende Situation l"a"st sich erheblich einfacher und stabiler
+l"osen als mit einem Domain Master Browser. Das Beispielnetz besteht
+aus zwei Filialen einer Firma in G"ottinen und Heidelberg. F"ur das
+sp"ater vollst"andig aufgebaute Beispiel seien die beiden Netze
+192.168.1.0/24 in G"ottingen und 192.168.2.0/24 in Heidelberg
+vergeben.
+
+In jeder Filiale gibt es eine Arbeitsgruppe, also die Gruppen
+\nbname{GOETTINGEN} und \nbname{HEIDELBERG}. In G"ottingen stehen nur
+Rechner der Arbeitsgruppe \nbname{GOETTINGEN}, in Heidelberg nur
+Rechner der Arbeitsgruppen \nbname{HEIDELBERG}. Nun soll auf beiden
+Seiten jeweils die eigene und die entfernte Arbeitsgruppe sichtbar
+sein, um sich im Netz mit dem Explorer frei bewegen zu k"onnen.  Dazu
+mu"s es sowohl in G"ottingen als auch in Heidelberg jeweils einen
+Local Master Browser f"ur \nbname{GOETTINGEN} und \nbname{HEIDELBERG}
+geben. Es gibt im Beispiel vier Local Master Browser, die hier auch
+bereits mit IP-Adressen versehen wurden:
+
+\vspace{\baselineskip}
+\begin{center}
+\begin{tabular}{|l|l|l|}\hline
+&\nbname{GOETTINGEN}&\nbname{HEIDELBERG}\\
+\hline
+Ort: G"ottingen & \nbname{GOE}, 192.168.1.1 & \nbname{GOEHD}, 192.168.1.2 \\
+Ort: Heidelberg & \nbname{HDGOE}, 192.168.2.2 & \nbname{HD}, 192.168.2.1 \\
+\hline
+\end{tabular}
+\end{center}
+\vspace{\baselineskip}
+
+%\begin{tabular}{|L|L|L|}\hline
+%  \LCC
+%  \tabulargray&\tabulargray&\tabulargray\\
+%  &\tabularheader{\nbname{GOETTINGEN}}&\tabularheader{\nbname{HEIDELBERG}}\\
+%  \hline
+%  \ECC
+%  &&\topseparation
+%  Ort: G"ottingen & \nbname{GOE} & \nbname{GOEHD} \\
+%  Ort: Heidelberg & \nbname{HDGOE} & \nbname{HD}
+%  \bottomseparationline
+%\end{tabular}
+
+Die Idee f"ur die Konfiguration ist nun, die G"ottinger Anfragen an
+den Local Master Browser f"ur \nbname{HEIDELBERG} (Rechner
+\nbname{GOEHD}) direkt nach Heidelberg an den Rechner \nbname{HD}
+umzuleiten. In G"ottingen mu"s nur ein \prog{nmbd} behaupten, er sei
+Local Master Browser f"ur die Arbeitsgruppe \nbname{HEIDELBERG}. Dies
+tut er, indem er auf UDP Port 137 die NetBIOS-Namensanfragen f"ur
+\nbname{HEIDELBERG\#1D} beantwortet. Der TCP-Port 139 auf dem Rechner
+\nbname{GOEHD} in G"ottingen wird dann an den echten Local Master
+Browser \nbname{HD} weitergeleitet.
+
+Das Weiterleiten von TCP Port 139 auf dem Rechner \nbname{GOEHD} an
+Port 139 des Rechners \nbname{HD} kann unterschiedlich geschehen. 
+
+\setlength{\unitlength}{4144sp}%
+%
+\begingroup\makeatletter\ifx\SetFigFont\undefined%
+\gdef\SetFigFont#1#2#3#4#5{%
+  \reset@font\fontsize{#1}{#2pt}%
+  \fontfamily{#3}\fontseries{#4}\fontshape{#5}%
+  \selectfont}%
+\fi\endgroup%
+\begin{picture}(5019,4611)(1789,-4483)
+\thinlines
+{\color[rgb]{0,0,0}\put(1936,-1051){\framebox(945,405){}}}%
+{\color[rgb]{0,0,0}\put(2386,-646){\line( 0, 1){405}}}%
+{\color[rgb]{0,0,0}\put(3286,-1051){\framebox(945,405){}}}%
+{\color[rgb]{0,0,0}\put(3736,-646){\line( 0, 1){405}}}%
+{\color[rgb]{0,0,0}\put(4861,-1051){\framebox(945,405){}}}%
+{\color[rgb]{0,0,0}\put(5311,-646){\line( 0, 1){405}}}%
+{\color[rgb]{0,0,0}\put(4861,-3166){\framebox(945,405){}}}%
+{\color[rgb]{0,0,0}\put(5311,-2761){\line( 0, 1){405}}}%
+{\color[rgb]{0,0,0}\put(3826,-1276){\framebox(405,225){}}}%
+\put(3916,-1231){\makebox(0,0)[lb]{\smash{\SetFigFont{12}{14.4}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}139}%
+}}}
+{\color[rgb]{0,0,0}\put(4771,-4471){\framebox(405,225){}}}%
+\put(4861,-4426){\makebox(0,0)[lb]{\smash{\SetFigFont{12}{14.4}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}139}%
+}}}
+{\color[rgb]{0,0,0}\put(4231,-4246){\framebox(945,405){}}}%
+{\color[rgb]{0,0,0}\put(4681,-3841){\line( 0, 1){405}}}%
+{\color[rgb]{0,0,0}\put(5401,-4246){\framebox(945,405){}}}%
+{\color[rgb]{0,0,0}\put(5851,-3841){\line( 0, 1){405}}}%
+{\color[rgb]{0,0,0}\put(1801,-241){\line( 1, 0){4050}}}%
+{\color[rgb]{0,0,0}\put(5311,-2671){\line( 0, 1){1620}}}%
+{\color[rgb]{0,0,0}\put(5311,-3166){\line( 0,-1){270}}}%
+{\color[rgb]{0,0,0}\put(4231,-1141){\line( 3, 1){945}}\put(5176,-826){\line( 0,-1){2205}}
+\put(5176,-3031){\line(-1,-5){242.308}}}%
+{\color[rgb]{0,0,0}\put(3691,-3436){\line( 1, 0){3105}}}%
+\put(2071,-871){\makebox(0,0)[lb]{\smash{\SetFigFont{12}{14.4}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}GOE}%
+}}}
+\put(3466,-871){\makebox(0,0)[lb]{\smash{\SetFigFont{12}{14.4}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}GOEHD}%
+}}}
+\put(4366,-4111){\makebox(0,0)[lb]{\smash{\SetFigFont{12}{14.4}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}HD}%
+}}}
+\put(5581,-4111){\makebox(0,0)[lb]{\smash{\SetFigFont{12}{14.4}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}HDGOE}%
+}}}
+\put(2386,-16){\makebox(0,0)[lb]{\smash{\SetFigFont{12}{14.4}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}Goettingen}%
+}}}
+\put(5941,-3301){\makebox(0,0)[lb]{\smash{\SetFigFont{12}{14.4}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}Heidelberg}%
+}}}
+\end{picture}
+
+\subsection{Konfiguration}
+
+Als Beispiel soll hier die vollst"andige Konfiguration am Standort
+G"ottingen mit beiden Local Master Browsern beschrieben werden, die am
+Standort Heidelberg kann dann spiegelverkehrt aufgesetzt werden.
+
+Der Local Master Browser in G"ottingen hat die beiden IP-Adressen
+192.168.1.1 (Interface eth0) f"ur den LMB der Arbeitsgruppe
+\nbname{GOETTINGEN} und 192.168.1.2 (Interface eth0:1) f"ur die
+Arbeitsgruppe \nbname{HEIDELBERG}. Die Interface-Bezeichnungen sind
+hier Linux-spezifisch. Andere Unix-Versionen vergeben virtuelle
+IP-Adressen m"oglicherweise anders. Die beiden virtuellen Sambaserver
+werden mit ihren Konfigurationen in den Verzeichnissen
+\dateistyle{/samba/goe} und \dateistyle{/samba/goehd} abgelegt.
+
+Es m"ussen nun zwei Dateien \dateistyle{smb.conf} erstellt werden,
+f"ur jeden Local Master Browser eine. F"ur die Arbeitsgruppe
+\nbname{GOETTINGEN} kann direkt die \dateistyle{smb.conf} von Seite
+\pageref{smbconf-goe} verwendet werden. Nur die Zeile \prog{interfaces
+  =} mu"s angepa"st werden, so da"s sich die folgende
+\dateistyle{/samba/goe/smb.conf} ergibt:
+
+\begin{verbatim}
+; /samba/goe/smb.conf
+[global]
+workgroup = goettingen
+netbios name = goe
+interfaces = eth0
+bind interfaces only = yes
+encrypt passwords = yes 
+smb passwd file = /samba/goe/smbpasswd
+log file = /samba/goe/var/log.smb
+lock directory = /samba/goe/locks
+os level = 100
+preferred master = yes
+\end{verbatim}
+
+Entsprechend ist die Datei \dateistyle{/samba/goehd/smb.conf}
+aufgebaut. Um der K"urze willen sind s"amtliche Einstellungen, die
+ausschlie"slich den \prog{smbd} betreffen, weggelassen worden. In
+G"ottingen soll f"ur die Arbeitsgruppe \nbname{HEIDELBERG} kein
+\prog{smbd} gestartet werden, daf"ur ist der \prog{smbd} auf dem
+Rechner \nbname{HDGOE} in Heidelberg zust"andig.
+
+\begin{verbatim}
+; /samba/goehd/smb.conf
+[global]
+workgroup = heidelberg
+netbios name = goehd
+interfaces = eth0:1
+bind interfaces only = yes
+lock directory = /samba/goe/locks
+os level = 100
+preferred master = yes
+\end{verbatim}
+
+Die Startdatei f"ur die Local Master Browser kann folgenderma"sen
+aussehen. Es werden drei Prozesse gestartet, ein vollst"andiges Samba
+f"ur den Rechner \nbname{GOE} und nur den \prog{nmbd} f"ur
+\prog{GOEHD}.
+
+\begin{verbatim}
+#!/bin/sh
+SMBD=/usr/local/samba/bin/smbd
+NMBD=/usr/local/samba/bin/nmbd
+case "$1" in
+  start)
+    echo "Starte Samba"
+    $SMBD -D -s /samba/goe/smb.conf
+    $NMBD -D -s /samba/goe/smb.conf
+    $NNBD -D -s /samba/goehd/smb.conf -l /samba/goehd/var
+    ;;
+  stop)
+    echo "Fahre Samba herunter"
+    kill -TERM $(cat /samba/goe/locks/smbd.pid)
+    kill -TERM $(cat /samba/goe/locks/nmbd.pid)
+    kill -TERM $(cat /samba/goehd/locks/nmbd.pid)
+    ;;
+  *)
+    echo "Usage: $0 [start|stop]"
+    ;;
+esac
+\end{verbatim}
+
+Die Weiterleitung des TCP-Ports 139 von der IP-Adresse 192.168.1.2 in
+G"ottingen an die Adresse 192.168.2.1 Port 139 in Heidelberg kann mit
+unterschiedlichen Methoden geschehen. Die einfachste Methode mit dem
+Programm \prog{netcat} und dem \prog{inetd} funktioniert hier leider
+nicht, da dem \prog{inetd} leider nicht gesagt werden kann, da"s er
+bitte nur an ein spezielles Interfaces binden soll. G"abe es f"ur den
+Rechner \nbname{GOEHD} eine eigene Maschine, k"onnte man den
+\prog{inetd} jedoch problemlos verwenden. Die Zeile
+
+\begin{verbatim}
+netbios-ssn stream tcp nowait nobody /usr/bin/netcat netcat 192.168.2.1 139
+\end{verbatim}
+
+in der \dateistyle{/etc/inetd.conf} zusammen mit
+
+\begin{verbatim}
+netbios-ssn     139/tcp
+\end{verbatim}
+
+in der \prog{/etc/services} leiten eingehende TCP-Verbindungen auf
+Port 139 zum Port 139 des Rechners 192.168.2.1 weiter.
+
+Die zweite M"oglichkeit der Portweiterleitung bietet das Programm
+\prog{rinetd}. Der \prog{rinetd} ist f"ur genau diesen Zweck
+geschaffen worden und ist bei SuSE-Linux als fertiges Paket
+mitgeliefert. Im Gegensatz zum \prog{inetd} kann der \prog{rinetd} an
+spezielle Interfaces binden, so da"s sein Einsatz auch mit virtuellen
+Sambaservern m"oglich ist. Der \prog{rinetd} wird "uber die Datei
+\prog{/etc/rinetd.conf} konfiguriert. Die notwendige Datei besteht nur
+aus einer einzigen Zeile:
+
+\begin{verbatim}
+192.168.1.2 139 192.168.2.1
+\end{verbatim}
+
+Alternative drei besteht beim Einsatz des \prog{xinetd}, der den
+\prog{inetd} vollst"andig ersetzt und erheblich leistungsf"ahiger ist.
+Der \prog{xinetd} beherrscht einerseits das Binden an einzelne
+Interfaces, andererseits kennt er bereits die M"oglichkeit,
+TCP-Verbindungen weiterzuleiten. Der Abschnitt in der
+Konfigurationsdatei \dateistyle{/etc/xinetd.conf} k"onnte
+beispielsweise so aussehen\todo{CHECK}:
+
+\begin{verbatim}
+service goehd
+{
+   socket_type = stream
+   protocol    = tcp
+   wait        = no
+   port        = 139
+   redirect    = 192.168.2.1 139
+   bind        = 192.168.1.2
+}
+\end{verbatim}
+
+F"ur welche der Alternativen man sich entscheidet, h"angt von der
+Umgebung ab. Setzt man virtuelle Server ein, f"allt der \prog{inetd}
+aus. Die Entscheidung zwischen \prog{rinetd} und \prog{xinetd} wird
+vermutlich danach fallen, ob der eventuell vorhandene \prog{inetd}
+abgel"ost werden soll. Die Kombination von \prog{inetd} und virtuellen
+Servern l"a"st nur die Wahl, den \prog{rinetd} einzusetzen. Wird der
+\prog{xinetd} bereits verwendet, sollte man ihn selbstverst"andlich
+auch f"ur die Portweiterleitung nutzen.
+
 \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}:
+Warum setzt man Samba "uberhaupt ein? Einer der wichtigsten Dienste
+von Samba ist, Festplattenbereiche f"ur Clients zur Verf"ugung zu
+stellen. Damit ein Client Plattenplatz eines Servers erreichen kann,
+mu"s man eine sogenannte \emph{Freigabe} erstellen.
+
+Beispielsweise m"ochte man den Inhalt des Unix-CDROM-Laufwerks an
+Clients exportieren. Das Laufwerk sei unter \dateistyle{/cdrom}
+eingebunden, und soll f"ur Clients unter
+\nbname{\textbackslash{}\textbackslash{}servername\textbackslash{}cd}
+erreichbar sein. Dazu mu"s man in der \dateistyle{smb.conf} einen
+neuen Abschnitt einleiten, der den Namen \param{[cd]} tr"agt. Damit
+wird eine Freigabe eingeleitet, die im Netz unter dem Namen
+\nbname{cd} zu sehen ist.
+
+Das folgende Beispiel gibt genau dieses Verzeichnis frei. Dabei ist
+zus"atzlich die Zugriffskontrolle so angelegt, da"s wirklich
+\textbf{jeder} darauf zugreifen kann. Wenn Sie irgend eine Art von
+sch"utzenswerten Daten auf der exportierten CD haben, sollten Sie sich
+auf jeden Fall das Kapitel \ref{freigaberechte} zu Rechten an
+Freigaben und das Kapitel \ref{smb-sitzungen} ansehen, um die Freigabe
+sinnvoll sch"utzen zu k"onnen.
 
 \begin{verbatim}
 [global]
@@ -1273,34 +2266,56 @@ 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}
+\label{smb-sitzungen}
+
+Sobald ein Rechner Freigaben im Netz zur Verf"ugung stellt, k"onnen
+Clients darauf zugreifen. Bevor ein Client tats"achlich auf eine
+Freigabe zugreifen kann, werden sechs Schritte durchlaufen. Diese
+sechs Schritte im Detail zu verstehen, ist f"ur die Konfiguration
+einfacher Server nicht wirklich notwendig. Sobald es aber darum geht,
+Fehlerdiagnose zu betreiben, ist das Wissen um die genaue
+Fehlerursache sehr wertvoll. Die genaue Stelle, an der eine
+Freigabeverbindung scheitert, kann bei der Fehlersuche gute Hinweise
+geben.
+
+\subsection{NetBIOS-Namensaufl"osung}
+
+Ein Benutzer an einem Client gibt den Namen des Servers mit
+unterschiedlichen Methoden an. Ein typischer Weg geht "uber die
+Netzwerkumgebung "uber einen Doppelklick auf den Rechner. Das
+Erscheinen in der Netzwerkumgebung ist jedoch nicht notwendig, da ein
+Client auch auf der Kommandozeile "uber ein
 
-Wird am Client eine Verbindung zu einer Freigabe auf einem SMB-Server
-aufgebaut, so m"ussen mehrere Schritte durchlaufen werden.
-
-\subsection*{NetBIOS-Namensaufl"osung}
+\begin{verbatim}
+net use h: \\server\freigabe
+\end{verbatim}
 
-Zu einem Rechnernamen mu"s eine IP-Adresse herausgefunden werden. Dies
-wurde in den letzten Abschnitten eingehend behandelt.
+\noindent das Laufwerk H verbinden kann. Genauso kann im Explorer durch den
+Men"upunkt "`Netzwerklaufwerk verbinden"' eine direkte Verbindung
+ge"offnet werden. Ein weiterer Weg ist "uber Men"upunkt "`Ausf"uhren"'
+im Startmen"u von Windows 95. Wenn man dort \verb|\\server| angibt,
+bekommt man die Liste der Freigaben des Servers angezeigt,
+unabh"angig, in welcher Arbeitsgruppe sich der Server befindet.
 
-\subsection*{TCP-Verbindung}
+\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}
+Ob die TCP-Verbindung klappt, pr"uft man am besten mit
+
+\begin{verbatim}
+telnet <ip> 139
+\end{verbatim}
+
+\noindent und einem Test mit \prog{netstat}, ob die Verbindung
+im Zustand \prog{ESTABLISHED} ist.
+
+\subsection{NetBIOS-Sitzung}
 
 Auf einem Serverrechner arbeiten unter Umst"anden mehrere
 Applikationen, die Namen f"ur sich reserviert haben. Diese sind alle
@@ -1333,15 +2348,15 @@ IP-Adresse auf Port 139 direkt angesprochen, und der Name
 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.
+allgemeinen Namen \texttt{*smbserver}\footnote{Das SMB-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, der CIFS von seinem Urvater SMB unterscheidet.
+  Mit Windows 2000 werden diese NetBIOS-Namen beim Verbindungsaufbau
+  gar komplett unterschlagen. Daf"ur war 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
@@ -1376,9 +2391,9 @@ 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
+Beispielsweise kann man diese Dateien \dateistyle{/etc/smb.conf.birke},
+\dateistyle{/etc/smb.conf.eiche} und so weiter nennen. Die Datei
+\dateistyle{/etc/smb.conf} ist f"ur den Rechner \nbname{fichte} zust"andig
 und enth"alt neben den Einstellungen f"ur \nbname{fichte} den
 Parameter 
 
@@ -1394,7 +2409,7 @@ kann bei den einzelnen virtuellen Servern mit den Parametern
 \param{hosts allow} und \param{hosts deny} der Zugriff geregelt
 werden.
 
-\subsection*{Negotiate Protocol}
+\subsection{Negotiate Protocol}
 
 Die NetBIOS-Sitzung ist nun aufgebaut, und es k"onnen Daten
 "ubermittelt werden. Innerhalb dieser NetBIOS-Sitzung wird eine
@@ -1424,6 +2439,33 @@ Ausnahme des ausgestorbenen XENIX-Dialektes lassen sich die Protokolle
 gut in eine Hierarchie einordnen. Sp"atere Protokolle beherrschen alle
 Aspekte der vorherigen Varianten.
 
+Im Jahr 1996 wurde SMB in CIFS umbenannt. CIFS ist die Abk"urzung f"ur
+Common Internet File System. Warum diese neue Bezeichnung, und warum
+zu diesem Zeitpunkt? Kurz vorher hatte Sun Microsystems sein Protokoll
+NFS angepa"st, um "uber Weitverkehrsstrecken besser benutzbar zu sein.
+NFS setzt voraus, da"s zwischen Client und Server nur sehr kurze
+Pingzeiten vorliegen. F"ur jeden Dateizugriff sind mehrere Anfragen
+notwendig. Auch wenn jede Anfrage nur sehr kurz ist und wenig
+Bandbreite verbraucht, mu"s doch jedesmal die Antwort des Servers
+abgewartet werden. Hohe Pingzeiten belasten so die Leistung des NFS
+erheblich. Sun hat das NFS so ver"andert, da"s die Anzahl der Anfragen
+erheblich reduziert wurde. Das Ergebnis nannten sie WebNFS und haben
+um dieses "`neue"' Protokoll eine gro"se Marketinginitiative
+gestartet. Kurz vorher hatte Microsoft die Kr"ote namens Java von SUN
+schlucken m"ussen und wollte sich nicht ein zweites Mal von SUN eine
+Technologie aufzwingen lassen. Daher hat man einfach das hauseigene
+Datei- und Druckprotokoll so umbenannt, da"s das Wort Internet im
+Namen vorkam. Im Gegensatz zu SUN hat sich Microsoft bis auf ein
+kleines Detail\footnote{Dies Detail hat nichts mit SMB, sondern mit
+  NetBIOS zu tun. SMB-Server wollen im NetBIOS-Sitzungsaufbau mit
+  ihrem eigenen NetBIOS-Namen angesprochen werden. Ein CIFS-Server im
+  Internet ist aber nur unter seinem DNS-Namen oder seiner IP-Adresse
+  bekannt. Der NetBIOS-Name ist normalerweise nicht publiziert. Daher
+  lauschen alle CIFS-Server auf den eigentlich illegalen NetBIOS-Namen
+  \nbname{*SMBSERVER}. Das ist der ganze Unterschied zwischen SMB und
+  CIFS.} nicht die M"uhe gemacht, das Protokoll wirklich in Richtung
+Internet zu optimieren.
+
 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
@@ -1469,7 +2511,7 @@ 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}
+\subsection{Session Setup}
 
 Nachdem die Protokollversion ausgehandelt ist, wird vom Client ein
 \defin{Session Setup} verschickt. In diesem Session Setup schickt der
@@ -1480,7 +2522,7 @@ Identit"at des Benutzers festzustellen. Wenn \param{security = share}
 vereinbart wurde, dann ignoriert der Server ein hier eventuell
 mitgeschicktes Pa"swort.
 
-\subsection*{Tree Connect}
+\subsection{Tree Connect}
 
 Als letztes legt der Client fest, welche Freigabe er ansprechen will.
 Der entsprechende Aufruf hei"st \defin{Tree Connect}. Sofern
@@ -1492,7 +2534,8 @@ 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}
+\section{Rechte an Freigaben}
+\label{freigaberechte}
 
 Bei Windows NT kann man mit zwei unterschiedlichen Mechanismen Rechte
 vergeben. An einer Freigabe kann man "uber Schreib- und Lesezugriff
@@ -1501,10 +2544,10 @@ 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.
+vergeben oder zu verweigern. Wenn bei der Einstellung einer Freigabe
+keine Parameter f"ur die Zugriffsrechte gesetzt sind, 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
@@ -1512,7 +2555,7 @@ 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.
+ben"otigte F"alle dargestellt werden:
 
 \begin{itemize}
 \item {\bf \emph{Alle} Benutzer haben gleichen Zugriff}
@@ -1529,8 +2572,8 @@ Freigabe. Schreibrecht vergibt man, indem man den Parameter
 
 \begin{verbatim}
 [projekt]
-path = /data/projekt
-writeable = yes
+   path = /data/projekt
+   writeable = yes
 \end{verbatim}
 
 \item {\bf \emph{Einige} Benutzer haben gleichen Zugriff}
@@ -1589,7 +2632,6 @@ die \param{write list} aufgenommen werden.
 [projekt]
 path = /data/projekt
 valid users = @users, @admins
-writeable = no
 write list = @admins
 \end{verbatim}
 
@@ -1598,43 +2640,86 @@ Leserecht, und die Benutzer der Gruppe admins haben Schreibrecht.
 
 \end{itemize}
 
-\section{Unix-Zugriffsrechte}
+\section{Zugriffsrechte im Dateisystem}
+
+Unter Windows NT gibt es zwei M"oglichkeiten, Netzzugriff auf Dateien
+zu kontrollieren. "Uber eine Freigabe kann ein Lese- oder ein
+Schreibrecht vergeben werden. Ist das freigegebene Dateisystem mit
+NTFS formatiert, k"onnen durch Access Control Lists im Dateisystem
+Rechte vergeben werden. Damit mu"s ein Benutzer sowohl durch die
+Freigabe- als auch durch die Dateisystemrechte zu einer Operation
+berechtigt sein.
+
+Auch bei Samba auf Unix gibt es zwei Stellen, an denen Zugriff auf
+Dateien und Verzeichnisse geregelt ist. Die im Kapitel
+\ref{freigaberechte} beschriebenen Zugriffsrechte beziehen sich
+ausschlie"slich auf die von Samba selbst vergebenen Rechte. Diese von
+Samba vergebenen Rechte k"onnen die darunter liegenden Unixrechte
+nicht erweitern. Das hei"st, Samba kann f"ur bestimmte Freigaben
+Schreibrecht vergeben. Der Benutzer, der zugreift, kann aber nur dann
+wirklich in den freigegebenen Dateien und Verzeichnissen schreiben,
+wenn er dies unter Unix ebenfalls darf. Diese Einschr"ankung durch
+Unixrechte ist ein wichtiges Prinzip von Samba: Im Dateisystem
+implementiert Samba keine eigenen Zugriffskontrollen, sondern
+verl"a"st sich auf die Unixmechanismen.
+
+Samba k"onnte theoretisch eine eigene Datenbank von Zugriffsrechten
+f"uhren. In dieser Datenbank k"onnte die vollst"andige NT-Semantik von
+Access Control Lists abgelegt und implementiert werden. Zwei Gr"unde
+sprechen gegen diesen Ansatz:
 
-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.
+\begin{itemize}
+\item Wenn Samba tats"achlich Dateisystemrechte implementieren w"urde,
+  w"aren die Entwickler daf"ur verantwortlich, da"s diese korrekt
+  eingehalten werden. Zugriffsrechte auf Dateien werden vom
+  Betriebssystem bereits hervorragend implementiert, warum sollte man
+  sich also die zus"atzliche Komplexit"at einhandeln?\footnote{Unter
+    Marketinggesichtspunkten kann es wichtig sein, vollst"andige
+    NT-Kompatibilit"at zu implementieren, die Samba mit dem
+    Unix-Rechtemodell bisher nicht bietet. Es existieren Patches, die
+    eine eigene ACL-Datenbank implementieren. Diese sind jedoch leider
+    momentan noch nicht frei verf"ugbar. Dies ist mit der GPL durchaus
+    m"oglich, da sie niemandem zug"anglich gemacht wurden. Es wird
+    jedoch in der Zukunft eine ver"offentlichte Version geben.}
+\item Sobald Samba eine eigene ACL-Datenbank implementiert, gilt diese
+  ausschlie"slich f"ur den Dateizugriff via SMB. Es ist nicht
+  m"oglich, Samba-ACL synchron mit dem Unix-Dateisystem zu halten,
+  wenn auch noch Zugriff von Unixprozessen aus erlaubt wird. Wenn sich
+  Verzeichnisb"aume "andern, ohne da"s Samba involviert ist, wie soll
+  Samba dann die ACLs korrekt anpassen?
+\end{itemize}
 
-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:
+Eng verwoben mit den Unix-Zugriffsrechten auf Dateien ist in der
+Implementation von Samba die Behandlung der DOS-Attribute. Diese
+Attribute sind Eigenschaften von Dateien, die es in dieser Form unter
+Unix nicht gibt. Viele Applikationen, die auf ein Netzwerklaufwerk
+zugreifen, setzen jedoch funktionierende Attribute voraus.
+Insbesondere das Archiv-Attribut wird von vielen Programmen verwendet.
+Insgesamt kennt DOS vier verschiedene Attribute, die f"ur Dateien
+vergeben werden k"onnen:
 
 \begin{description}
 \item[Read-Only] Der Inhalt dieser Datei kann nur gelesen, aber nicht
-geschrieben werden. Die Datei kann nicht gel"oscht werden.
+  geschrieben werden. Die Datei kann nicht gel"oscht werden.
 \item[System] Diese Datei ist f"ur spezielle Betriebssystemzwecke
-vorgesehen.
+  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.
+  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.
+Diese Bits k"onnen unter DOS von jedem Benutzer frei gesetzt und
+wieder zur"uckgesetzt werden. Das Schreibschutzbit ist also nicht als
+echter Zugriffschutz zu verstehen, sondern nur als kleine
+Hilfestellung gegen Fehlbedienungen.
+
+\subsection{Abbildung DOS-Attribute zu Unix-Rechten}
 
 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.
+sind aufgeteilt in drei Gruppen von Benutzern: Der Dateibesitzer, die
+besitzende Gruppe und alle anderen. Jeder Gruppe k"onnen drei
+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
@@ -1667,7 +2752,7 @@ 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
+\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
@@ -1684,7 +2769,7 @@ 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
+sein, da"s die besitzende Gruppe ein Schreibrecht einger"aumt
 bekommt. Das kann man durch \param{force create mode = 020} erreichen.
 Tabellarisch dargestellt hei"st dies:
 
@@ -1719,7 +2804,133 @@ 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}
+\subsection{Beispiel: Ein Projektverzeichnis}
+
+H"aufig mu"s man einer Anzahl von Benutzern gemeinsamen Schreibzugriff
+auf eine Freigabe, beispielsweise auf die Freigabe \param{fibu},
+geben. Das Beispiel der Projektverzeichnisse wird noch mehrfach
+betrachtet werden. Es gibt mit Samba viele M"oglichkeiten der
+Realisation, die alle f"ur unterschiedliche Situation geeignet sind.
+
+Ein einfaches Projektverzeichnis l"a"st sich folgenderma"sen
+realisieren:
+
+\begin{verbatim}
+[fibu]
+   path        = /data/fibu
+   writeable   = yes
+   valid users = @fibu, mueller, meier
+\end{verbatim}
+
+Damit darf die Gruppe \username{fibu} das Recht, auf diese Freigabe
+schreibend zuzugreifen. \username{mueller} und \username{meier}, die
+nicht Mitglied der Finanzbuchhaltung sind, d"urfen ebenfalls
+schreiben.  Damit problemloser gemeinsamer Zugriff m"oglich ist, mu"s
+die Rechtevergabe im Unix-Dateisystem geregelt werden. Dabei wird hier
+vorausgesetzt, da"s im Unix selbst nur die Benutzer der Gruppe
+\username{fibu} auf \dateistyle{/data/fibu} zugreifen sollen.
+\username{meier} und \username{mueller} sind \emph{nicht} Mitglieder
+der Gruppe \username{fibu}, sollen aber trotzdem schreiben k"onnen.
+F"ur sie mu"s eine Sonderregelung geschaffen werden, die sich mit
+Standard-Unixrechten nicht abbilden l"a"st. Dazu ben"otigt man die
+ACLs aus Kapitel \ref{acl}.
+
+Hat man keine ACLs zur Verf"ugung, gibt es eine sehr einfache
+M"oglichkeit, jegliche Probleme im gemeinsamen Dateizugriff zu
+vermeiden, ist der Parameter \param{force user}. Will man diesen
+Parameter anwenden, so sollte man f"ur diese Freigabe oder f"ur alle
+solchen Gruppenfreigaben einen separaten User anlegen, und diesem dann
+das freigegebene Verzeichnis "ubergeben:
+
+\begin{verbatim}
+root@delphin:~ > mkdir -p /data/fibu
+root@delphin:~ > useradd fibuuser
+root@delphin:~ > chown projektuser /data/fibu/
+root@delphin:~ > chmod 770 /data/fibu
+\end{verbatim}
+
+Die Freigabe sieht dann folgenderma"sen aus:
+
+\begin{verbatim}
+[fibu]
+   path        = /data/fibu
+   writeable   = yes
+   valid users = @fibu, mueller, meier
+   force user  = fibuuser
+\end{verbatim}
+
+Die Zugriffskontrolle wird bei dieser Definition ganz normal anhand
+von \param{valid users} vorgenommen. Nur die dort erw"ahnten Benutzer
+bekommen Zugriff auf die Freigabe. \emph{Nachdem} der Zugriff gew"ahrt
+wurde, vergi"st Samba den Namen, mit dem sich der Benutzer angemeldet
+hat. Samba schaltet f"ur jegliche Zugriffe im Dateisystem in den
+Benutzer \username{fibuuser}. Man mu"s sich damit nicht mehr um
+gemeinsame Zugriffsrechte im Unix k"ummern, da man ohnehin nur unter
+einer einzigen Userid arbeitet. Man verliert jedoch die
+Nachvollziehbarkeit. Alle Dateien geh"oren \username{pcuser}. Dies
+wird insbesondere auch so im entsprechenden Dialog von Windows
+angezeigt.
+
+Mit etwas mehr Aufwand kann man es schaffen, den Dateibesitzer korrekt
+zu behalten und gleichzeitig gemeinsames Schreiben zu erm"oglichen.
+Das Verzeichnis \dateistyle{/data/fibu} selbst kann mit den
+korrekten Gruppenschreibrechten angelegt werden:
+
+\begin{verbatim}
+root@delphin:~ > mkdir -p /data/fibu
+root@delphin:~ > groupadd fibu
+root@delphin:~ > chgrp fibu /data/fibu/
+root@delphin:~ > chmod 770 /data/fibu
+\end{verbatim}
+
+Die Benutzer der Gruppe \username{fibu} k"onnen in diesem
+Verzeichnis einwandfrei Dateien anlegen und ihre eigenen Dateien auch
+"andern. Es gibt jedoch noch zwei Probleme.
+
+\begin{itemize}
+\item \username{mueller} und \username{meier} k"onnen nicht auf das
+  Verzeichnis zugreifen, da Unix ihnen den Zugriff verweigert.
+\item Die Benutzer aus der Gruppe \username{fibu} m"ussen nicht
+  notwendigerweise diese Gruppe als Hauptgruppe haben. Das hei"st, neu
+  angelegte Dateien geh"oren m"oglicherweise anderen Gruppen an.
+  Dieses spezielle Problem lie"se sich mit dem set-group-id Bit auf
+  dem Verzeichnis \dateistyle{/data/fibu} l"osen:
+
+\begin{verbatim}
+chmod g+s /data/fibu
+\end{verbatim}
+  
+  \username{mueller} und \username{meier} blieben jedoch immer noch
+  au"sen vor, da sie nicht in der Gruppe \username{fibu} sind, also
+  auf dem Verzeichnis \dateistyle{/data/fibu} kein Schreibrecht haben.
+\end{itemize}
+
+Beide Probleme bekommt man mit dem Parameter \param{force group =
+  fibu} in den Griff. Dieser Parameter arbeitet genau so wie
+\param{force user}, nur da"s er sich anstatt der User-ID auf die
+Group-ID bezieht. Jegliche Dateisystemzugriffe werden damit als Gruppe
+\username{fibu} vorgenommen, die User-ID bleibt unangetastet.
+
+Als letztes mu"s nun noch sichergestellt werden, da"s die Gruppe, in
+diesem Fall \username{fibu}, immer schreiben kann, und da"s der
+Rest der Welt keinen Zugriff bekommt. Die vollst"andige
+Freigabedefinition sieht demnach folgenderma"sen aus:
+
+\begin{verbatim}
+[fibu]
+   path                 = /data/fibu
+   writeable            = yes
+   valid users          = @fibu, mueller, meier
+   force group          = fibu
+   create mask          = 740
+   directory mask       = 750
+   force create mode    = 020
+   force directory mode = 020
+\end{verbatim}
+
+\todo{Global- und shareparameter, copy = freigabe}
+
+\section{Projektverzeichnisse, zum zweiten}
 
 Folgendes Problem stellt sich bei der Migration von Novell zu Samba
 recht h"aufig. Unter Novell kann man anhand von
@@ -1740,13 +2951,13 @@ 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
+\dateistyle{/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:
+\param{verkauf}. Unter \dateistyle{/data/groups} kann man folgende
+Gruppenverzeichnisse anlegen:
 
 {\small\begin{verbatim}
 root@server:/data/groups> ls -l
@@ -1785,8 +2996,8 @@ 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}
+Ebene \dateistyle{/data/share} die Benutzer abgewiesen werden. Die
+Parameter \dateistyle{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.
@@ -1809,7 +3020,7 @@ writeable = yes
 \end{verbatim}
 }
 
-Die Datei \datei{mklinks} hat folgenden Inhalt:
+Die Datei \dateistyle{mklinks} hat folgenden Inhalt:
 
 {\small\begin{verbatim}
 #!/bin/sh
@@ -1818,40 +3029,49 @@ cd /data/users
 rm -rf "$1"
 mkdir "$1"
 cd "$1"
-for i in `groups $1`
+for i in $(groups $1)
 do
-        ln -s /data/groups/$i .
+        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
+\dateistyle{/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. Jedoch darf dieses
+Verfahren nur dann angewendet werden, wenn die Benutzernamen unter
+vertrauensw"urdiger Kontrolle stehen. Wenn es m"oglich ist, da"s
+Benutzernamen beispielsweise von einem NIS-Server bezogen werden, kann "uber
+einen Benutzernamen \username{../..} das gesamte Dateisystem
+gel"oscht werden. Ist ein NIS-Server beteiligt, mu"s man das Verfahren
+ohne \param{root preexec} und nur mit \param{preexec} ohne Root-Rechte
+verwenden.
+
+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
+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
+ausgechlossen.
+
+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.
 
@@ -1861,6 +3081,364 @@ 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{ACLs}
+\label{acl}
+
+Die Zugriffsrechte unter Unix werden durch den Dateimodus bestimmt.
+Dieser Dateimodus enth"alt neun Bits, die den Zugriff auf die Datei
+regeln. Dazu kommen drei zus"atzliche Bits f"ur spezielle Anwendungen.
+Mit diesen neun Bits k"onnen Zugriffsrechte f"ur drei Benutzerklassen
+vergeben werden: Den Dateibesitzer, die besitzende Gruppe und den Rest
+der Welt. Mit dem Befehl \prog{chmod} werden diese Rechte gesetzt.
+
+Dieser Mechanismus hat einen unsch"atzbaren Vorteil: Er ist einfach.
+Mit insgesamt zw"olf Bits kann ein sehr gro"ses Spektrum an Szenarien
+abgedeckt werden. Jedoch ist es oft notwendig, Zugriffsrechte feiner
+zu vergeben, als dies mit Unix m"oglich ist. Insbesondere haben viele
+Unternehmensanwendungen komplexere Anforderungen an die
+Zugriffsrechte.
+
+Beispielsweise soll auf einem Verzeichnis die Gruppe \username{fibu}
+Schreibrecht haben und die Gruppe \username{controlling} soll Leserecht
+bekommen. Der Benutzer \username{mueller} ist nun in der Gruppe
+\username{controlling} und hat sich bei der Finanzbuchhaltung unbeliebt
+gemacht. Er soll auf dieses Verzeichnis keinen Zugriff mehr haben. Eine
+solche Konfiguration ist mit den traditionellen Unix-Zugriffsrechten nicht
+mehr abzubilden.
+
+Die Hersteller von Unix haben sich irgendwann zusammengefunden, um das
+beschr"ankte Rechtemodell zu erweitern. Geplant war eine Erweiterung, die
+sich in das vorhandene Rechtemodell von Unix nahtlos einbinden l"a"st, aber
+die dem Benutzer erheblich mehr M"oglichkeiten zur
+Rechtesteuerung gibt.
+
+Zugriffskontrollisten (Access Control Lists oder ACLs) unterst"utzen genau
+diese weitergehenden Zugriffsrechte. Beliebige Benutzer und
+Gruppen k"onnen Rechte auf Dateien und Verzeichnissen bekommen oder
+verweigert bekommen. Die klassischen drei Benutzerklassen kann man als drei
+Eintr"age in einer ACL ansehen.
+
+Das Modell der ACLs erweitert M"oglichkeiten, wem man Rechte geben
+kann. Es erweitert nicht die Art der Rechte, die vergeben werden
+k"onnen. Es geht weiterhin nur um die Rechte Lesen, Schreiben und
+Ausf"uhren, mit der bekannten Bedeutung auf Dateien und
+Verzeichnissen.
+
+\subsection{Rechte unter Unix}
+
+Die Auswertung der Zugriffsrechte unter Unix funktioniert, indem
+zuerst entschieden wird, welche der drei Rechtegruppen Benutzer,
+Gruppe und Andere benutzt werden soll. Im zweiten Schritt wird
+nachgesehen, ob das gew"unschte Recht auf der Datei gesetzt ist.
+
+Die Zugriffsrechte eines Benutzers werden bestimmt durch seinen
+Sicherheitskontext. Dieser Sicherheitskontext besteht aus seiner
+effektiven User ID (EUID), seiner prim"aren Gruppe (EGID) und seinen
+zus"atzlichen Gruppen (GIDs). Die Entscheidung f"ur eine Rechtegruppe
+funktioniert in drei Schritten:
+
+\begin{itemize}
+\item Ist EUID gleich dem Dateibesitzer? In diesem Fall wird die erste
+  Rechtegruppe, die f"ur den User benutzt.
+\item Ist der Benutzer in der besitzenden Gruppe? Dann wird die zweite
+  Rechtegruppe f"ur Group benutzt. Die tats"achliche Pr"ufung
+  passiert, indem die besitzende Gruppe in der Liste GID's gesucht
+  wird, in der der Benutzer aufgenommen ist.
+\item Ist beides nicht der Fall, so wird die dritte Rechtemaske f"ur
+  Others benutzt.
+\end{itemize}
+
+Wenn entschieden wurde, welche Rechtemaske verwendet werden soll, wird
+nicht mehr versucht, eine andere Rechtemaske zu verwenden. Wenn ein
+Benutzer sich selbst das Leserecht auf einer Datei genommen hat, und
+dem Rest der Welt "uber die Maske Others Leserecht gegeben hat, wird
+er die Datei nicht lesen k"onnen.
+
+\subsection{Eintr"age in einer ACL}
+
+Da ACLs eine reine Erweiterung des Unix-Rechtemodells sind, gibt es
+weiterhin einen Dateibesitzer und eine besitzende Gruppe f"ur jede
+Datei. Eine Access Control List kennt eine Anzahl unterschiedlicher
+Eintr"age:
+
+\begin{description}
+\item[ACL\_USER\_OBJ:] Dies ist die Rechtemaske f"ur den
+  Dateibesitzer. Sie entspricht der ersten Rechtemaske f"ur den User
+  im klassischen Rechtemodell.
+\item[ACL\_GROUP\_OBJ:] Dies ist die Entsprechung der
+  Group-Rechtemaske im klassischen Modell.
+\item[ACL\_OTHER:] Die Rechtemaske f"ur den Rest der Welt unter Unix.
+  Von diesen ersten drei Eintr"agen gibt es jeweils genau einen in
+  jeder ACL.
+\item[ACL\_USER:] Ein Eintrag f"ur einen benannten Benutzer.  Von
+  diesem Eintrag kann es mehrere geben, mit denen f"ur
+  unterschiedliche Benutzer unterschiedliche Rechte vergeben werden.
+  Gibt es einen Benutzereintrag ohne jegliche Rechte, kann dieser auf
+  die Datei nicht zugreifen.
+\item[ACL\_GROUP:] Eintrag f"ur eine Gruppe. Auch von diesem Eintrag
+  kann es mehrere geben.
+\item[ACL\_MASK:] Die Maske f"ur die effektiven Rechte. Sobald f"ur
+  eine Datei ACLs verwendet werden, wird \prog{ls -l} diese
+  Rechtemaske als Gruppenrecht anzeigen. Sobald mit \prog{chmod} die
+  Rechte f"ur die besitzende Gruppe ver"andert werden (etwa per
+  \prog{chmod g-rx}), wird die ACL\_MASK ver"andert.
+\end{description}
+
+\subsection{Rechte mit ACLs}
+
+Wenn ein Prozess auf eine Datei zugreifen will, wird mit dem folgenden
+Algorithmus festgestellt, ob der Zugriff zugelassen oder verweigert
+wird.
+
+\begin{itemize}
+\item Ist die EUID des Prozesses gleich dem Dateibesitzer, wird der
+  Zugriff gew"ahrt, wenn der Eintrag f"ur ACL\_USER\_OBJ die
+  ben"otigten Zugriffsrechte enth"alt.
+\item Wenn es in der ACL einen ACL\_USER Eintrag gibt, der der EUID
+  entspricht, wird dieser Eintrag verwendet. Ist dass gew"unschte
+  Recht in diesem Eintrag vorhanden, wird der Zugriff gew"ahrt, sofern
+  es \emph{auch} im Eintrag ACL\_MASK vorhanden ist. Ist das Recht
+  entweder im ACL-Eintrag oder in ACL\_MASK \emph{nicht} vorhanden,
+  wird das Recht verweigert.
+\item Ist der Benutzer in der besitzenden Gruppe der Datei ist
+  (Eintrag f"ur ACL\_GROUP\_OBJ), oder wenn der Benutzer in einer
+  Gruppeneintr"age vom Typ ACL\_GROUP ist, wird folgendes getestet:
+  Sind die gew"unschten Rechte in einem der Eintr"age vollst"andig
+  vorhanden, so wird der Zugriff gew"ahrt, sofern das Recht ebenfalls
+  im Eintrag ACL\_MASK vorhanden ist. Ansonsten wird der Zugriff
+  verweigert.
+\item Wenn kein Eintrag gefunden werden konnte, wird der Zugriff
+  anhand des Eintrags ACL\_OTHER gew"ahrt.
+\end{itemize}
+
+Es ist hier wichtig festzustellen, da"s die Benutzereintr"age in einer
+ACL immer \emph{vor} Gruppeneintr"agen durchsucht werden. Damit werden
+die spezifischeren Eintr"age grunds"atzlich vorrangig vor den weniger
+spezifischen Eintr"agen behandelt.
+
+\subsection{ACL-Beispiel}
+
+Linux unterst"utzt mit dem richtigen Kernelpatch die beschriebenen
+ACLs auf dem Ext2-Dateisystem. Der Kernelpatch ist zu diesem Zeitpunkt
+(Sommer 2001) notwendig, da Linus Torvalds ihn noch nicht in den
+Standardkernel aufgenommen hat. Unter
+\href{http://acl.bestbits.at/}{http://acl.bestbits.at} findet man den
+entsprechenden Kernelpatch und die notwendigen Utilities. ACLs setzen
+kann man mit \prog{setfacl}, mit \prog{getfacl} werden ACLs angezeigt.
+
+Das oben beschriebene Beispiel eines Verzeichnisses f"ur die
+Finanzbuchhaltung l"a"st sich folgenderma"sen erstellen:
+
+\begin{verbatim}
+root@delphin:~ > cd /
+root@delphin:/ > mkdir fibu
+root@delphin:/ > chmod o-rwx fibu
+root@delphin:/ > setfacl -m group:fibu:rwx fibu
+root@delphin:/ > setfacl -m group:controlling:rx fibu
+root@delphin:/ > setfacl -m user:mueller:--- fibu
+root@delphin:/ > getfacl fibu
+# file: fibu
+# owner: root
+# group: root
+user::rwx
+user:mueller:---
+group::r-x
+group:fibu:rwx
+group:controlling:r-x
+mask:rwx
+other:---
+\end{verbatim}
+
+Obwohl der Benutzer \username{mueller} Mitglied der Gruppe
+\username{controlling} ist, hat er keinen Zugriff auf dieses
+Verzeichnis, da der ACL-Eintrag f"ur ihn keinen Zugriff erlaubt, und
+dieser vor seinem Gruppeneintrag gefunden wird.
+
+Interessant an diesem Beispiel ist die Behandlung der ACL-mask. Sie
+wird in der Anzeige von \prog{ls -l} als Gruppenberechtigung
+angezeigt. 
+
+\begin{verbatim}
+root@delphin:/ > ls -ld fibu
+drwxrwx---   2 root     root         4096 Aug 28 07:56 fibu
+\end{verbatim}
+
+An der Ausgabe von \prog{getfacl} ist zu sehen, da"s die besitzende
+Gruppe \username{root} nur Lese- und Ausf"uhrungsrechte hat. Trotzdem
+zeigt \prog{ls -l} f"ur die Gruppe ein \prog{rwx} an. Dies wird
+gemacht, um Benutzer vor "Uberraschungen zu sch"utzen. "Uber ACLs sind
+auf dem Verzeichnis \dateistyle{fibu} mehr Rechte vergeben, als aus
+der Ausgabe von \prog{ls -l} ersichtlich ist. Will man die
+Rechtevergabe durch ACLs ausschalten, gen"ugt es, mit \prog{chmod
+  g-rwx fibu} die Rechte f"ur die besitzende Gruppe komplett
+wegzunehmen.
+
+\subsection{Default ACLs}
+
+Das vorangegangene Beispiel ist noch nicht vollst"andig. F"ur das
+Verzeichnis \dateistyle{fibu} sind die Rechte korrekt gesetzt. Wenn
+jedoch Benutzer in diesem Verzeichnis Dateien anlegen, gelten wieder
+nur die normalen Regeln von Unix. Erreichen m"ochte man jedoch in der
+Regel, da"s f"ur neue Dateien unterhalb eines solchen Verzeichnisses
+wieder die gleichen Regeln gelten wie f"ur das Verzeichnis selbst.
+
+Wenn eine neue Datei oder ein Verzeichnis erstellt wird, mu"s "uber
+die Zugriffsrechte entschieden werden, die darauf gesetzt werden. Im
+traditionellen Unixmodell wird die Rechtemaske auf neuen Dateien und
+Verzeichnissen durch die so genannte \emph{umask} eingeschr"ankt. Ein
+Programm, das eine Datei erzeugt, kann einen Satz von Zugriffsrechten
+bestimmen, mit dem die Datei erzeugt werden soll. Bevor die Datei
+tats"achlich mit diesen Rechten erzeugt wird, wird dieser Satz von
+Rechten um die Bits eingeschr"ankt, die in der \emph{umask} gesetzt
+sind. Wenn ACLs verwendet werden, ist dieses einfache Modell nicht
+mehr verwendbar. Stattdessen kann man f"ur jedes Verzeichnis eine
+so genannte \emph{Default ACL} vergeben. Diese werden an Dateien und
+Verzeichnisse weitergegeben.
+
+Setzen kann man die Default ACL, indem man dem Befehl \prog{setfacl}
+den Schalter \prog{-d} mitgibt:
+
+\begin{verbatim}
+root@delphin:/ > setfacl -d -m group:fibu:rwx fibu/
+root@delphin:/ > setfacl -d -m group:controlling:r-x fibu
+root@delphin:/ > setfacl -d -m user:mueller:--- fibu
+root@delphin:/ > getfacl fibu
+# file: fibu
+# owner: root
+# group: root
+user::rwx
+user:mueller:---
+group::r-x
+group:fibu:rwx
+group:controlling:r-x
+mask:rwx
+other:---
+default:user::rwx
+default:user:mueller:---
+default:group::r-x
+default:group:fibu:rwx
+default:group:controlling:r-x
+default:mask:rwx
+default:other:---
+\end{verbatim}
+
+Mit diesen Eintr"agen ist das Beispielverzeichnis vollst"andig. Die
+Default-Eintr"age werden an neue Dateien und Verzeichnisse
+weitergegeben. 
+
+Zu beachten ist hier noch die umask des Benutzers. Sobald ACLs benutzt
+werden, wirken die Gruppenrechte, die im \prog{ls} dargestellt und mit
+\prog{chown} ge"andert werden, als \emph{mask} einschr"ankend auf die
+ACLs. Wenn die umask eines Unix-Benutzers so gesetzt ist, da"s die
+Gruppe eingeschr"ankt wird, so wirkt sich das beim Einsatz von ACLs so
+aus, da"s bei neu angelegten Dateien und Verzeichnissen diese
+Gruppeneinschr"ankungen als \emph{mask} wirken und somit die default
+ACLs beschr"anken.
+
+\subsection{ACLs aus Windows-Sicht}
+
+Was hat das ganze mit Samba zu tun? Zun"achst einmal sind
+Windows-Administratoren gewohnt, deutlich st"arker mit ACLs zu
+arbeiten, als Unixbenutzer. Dies mag daran liegen, da"s Unix lange
+Zeit keine ACLs unterst"utzt hat und man vieles auch mit den
+traditionellen Zugriffsrechten erreichen kann. Bei der Planung eines
+Sambaservers als Ersatz f"ur einen NT-Server stellt sich so
+zwangsl"aufig die Frage nach der Unterst"utzung von ACLs.
+
+Der Zusammenhang mit Samba ergibt sich nun daraus, da"s mit Samba 2.2
+diese ACLs von Windows aus angeschaut und sogar gesetzt werden
+k"onnen. Dazu mu"s bei der Kompilation von Samba die Option
+\prog{-{}-with-acl-support} an das Skript \prog{configure} "ubergeben
+worden sein, und beim Kompilieren mu"s die ACL-Unterst"utzung in den
+Headerfiles des Kernels vorhanden sein. Ist beides der Fall, kann man
+"uber die Sicherheitseigenschaften von Dateien und Verzeichnissen
+deren ACLs editieren. Dabei ergibt sich bei der Umsetzung von den sehr
+komplexen NT-ACLs zu den deutlich einfacheren Posix-ACLs h"aufig eine
+gewisse Einschr"ankung der Funktionalit"at, aber dies ist leider nicht
+zu vermeiden. Die Anforderungen, die im obigen Beispiel skizziert
+wurden, werden jedoch korrekt umgesetzt. Wer sich f"ur die genaue
+Umsetzung der ACLs zwischen der NT- und der Posix-Welt interessiert,
+mag sich die Datei \dateistyle{samba-acls.ag.pdf} aus dem
+Unterverzeichnis \prog{slides} eines Samba-FTP Servers ansehen. Dies
+sind die Folien eines Vortrags von Jeremy Allison "uber jene
+Umsetzung, den er bei der CIFS 2001 Konferenz in Bellevue gehalten
+hat.
+
+\section{oplocks}
+
+Dateizugriffe "uber ein Netzwerk sind trotz leistungsf"ahiger
+Netzwerkhardware meistens deutlich langsamer als auf einer lokalen
+Festplatte. Der lokale Hauptspeicher, der heutzutage in den meisten
+Workstations im "Uberflu"s vorhanden ist, ist nochmal um
+Gr"o"senordnungen schneller. F"ur lokale Festplatten gibt es in allen
+Systemen Caches im Hauptspeicher, und so w"are es Verschwendung,
+Caching nicht auch auf Netzwerkdateien anzuwenden. Netzwerkzugriffe,
+die gar nicht erst gemacht werden m"ussen, sind die schnellsten
+Zugriffe. Im Gegensatz zu einem lokalen Festplattencache kann ein
+Cache von Netzwerkdateien nicht davon ausgehen, die Datei alleine zu
+benutzen\footnote{Geteilte Blockger"ate in einem Storage Area Network
+  sei hier einmal au"sen vor gelassen.}. Zugriffe unterschiedlicher
+Clients m"ussen koordiniert werden.
+
+Opportunistic Locks (Oplocks) sind ein Mechanismus, mit dem Clients
+erlaubt werden kann, Dateiinhalte zu cachen. Mit einem Oplock bekommt
+der Client eine Datei solange exklusiv f"ur sich, bis der Server ihn
+auffordert, die "Anderungen zur"uckzuschreiben und die Sperre
+freizugeben.
+
+Ein Client A m"ochte eine Datei "offnen und beantragt ein Oplock auf
+die Datei. Wenn der Server dieses Oplock gew"ahrt, ist das die Zusage,
+da"s niemand anders auf die Datei zugreift. Damit mu"s Client A
+weder bei jedem Lesezugriff den Server befragen, noch mu"s er jeden
+Schreibzugriff unverz"uglich an den Server liefern. Moderne
+Windowsclient nutzen dieses Feature sehr ausgiebig und erreichen damit
+in typischen Applikationen zwischen drei"sig und vierzig Prozent mehr
+Geschwindigkeit.
+
+Wenn ein zweiter Client, B, auf die Datei "offnen m"ochte, schickt der
+Server dem Client A ein so genanntes Oplock Break. Dies ist die
+Anweisung, s"amtliche lokalen "Anderungen zur"uckzuschreiben und den
+Schreibcache auf dieser Datei in Zukunft auszuschalten. Erst nachdem
+Client A alle "Anderungen zur"uckgeschrieben hat, wird Client B die
+Datei "offnen k"onnen. Da keiner von beiden noch ein Oplock bekommt,
+sehen beide s"amtliche "Anderungen sofort.
+
+Dieses Schema funktioniert innerhalb von Samba hervorragend. Sobald
+Unix-Prozesse ebenfalls auf Dateien zugreifen m"ussen, die von Samba
+freigegeben sind, gibt es Probleme mit Oplocks. Beispielsweise wird es
+nicht m"oglich sein, vern"unftig Datensicherung zu betreiben, da
+Clients m"oglicherweise nicht alle Daten zum Server geschickt haben.
+
+Es gibt mehrere M"oglichkeiten, dieses Problem in den Griff zu
+bekommen:
+
+\begin{description}
+\item[Keine Oplocks:] Durch den Parameter \param{oplocks = no} k"onnen
+  Oplocks f"ur eine Freigabe komplett abgeschaltet werden. Damit
+  handelt man sich aber massive Performanceprobleme ein.
+\item[Keine Oplocks f"ur einzelne Dateien:] Der Parameter \param{veto
+    oplock files} verweigert Oplocks f"ur einzelne Dateien. Dieser
+  Parameter verlangt eine Liste von Unix-Pfadnamen oder
+  DOS-Wild\-cards. Die Syntax ist in der Beschreibung zum Parameter
+  \param{veto files} zu finden.
+\item[Kernel Oplocks:] Das Problem mit Oplocks liegt darin, da"s Samba
+  vom Kernel nicht informiert werden kann, wenn ein Unixproze"s eine
+  Datei "offnen will. Samba k"onnte f"ur diese Datei ein Oplock
+  vergeben haben und m"u"ste es vom Client zur"uckfordern, bevor der
+  Unixproze"s die Datei "offnen kann. IRIX und Linux 2.4 sind um ein
+  API erweitert worden, das genau dies leistet. Um Kernel Oplocks zu
+  nutzen, mu"s Samba entsprechend kompiliert werden. Liegen bei der
+  Kompilation die Quellen des Kernel 2.4 vor, erkennt Samba diese
+  automatisch. Sollten sich bei der Nutzung dieses Features Probleme
+  herausstellen, kann es mit \param{kernel oplocks = no} abgeschaltet
+  werden, obwohl dies nie notwendig sein sollte.
+\end{description}
+
+Bevor Samba Oplocks unterst"utzt hat, konnte man mit \param{fake
+  oplocks = yes} f"ur read only Freigaben jegliche Oplocks vergeben,
+ohne sie jemals zur"uckzufordern. Dies sollte man heutzutage
+\emph{nicht} mehr einsetzen.
+
 \section{Pa"sw"orter}
 \label{passwoerter}
 
@@ -1872,7 +3450,7 @@ 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
+Risiko als relativ gering eingesch"atzt wurde. Seit dem Aufkommen von
 DOS und Ethernet hat jeder Benutzer Administratorrechte, kann also den
 Netzverkehr mitschneiden.
 
@@ -1881,17 +3459,155 @@ 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.
+Klassische symmetrische Verschl"usselung funktioniert folgenderma"sen:
+Jemand m"ochte einem Bekannten\footnote{In der Literatur hei"sen diese
+  beiden Bekannten Alice und Bob. Es gibt ganze Abhandlungen dazu, was
+  diesen beiden schon alles passiert ist$\ldots$} eine geheime
+Nachricht zukommen lassen. Das hei"st, jemand, der die "Ubertragung
+abh"ort, soll diese Nachricht nicht lesen k"onnen. Dazu kann man ein
+symmetrisches Verfahren wie DES, IDEA oder AES einsetzen. Diese
+Verfahren zerst"uckeln die Nachricht so, da"s sie niemand mehr lesen
+kann, au"ser jemand wei"s, mit welchem Verfahren die Nachricht
+verschl"usselt wurde. Zu jedem Verschl"usselungsverfahren gibt es
+n"amlich ein Gegenst"uck, das aus der zerst"uckelten Nachricht das
+Original wieder herstellt. Es gibt auch Verfahren, bei denen es keinen
+R"uckweg gibt. Diese sind zwar f"ur die genannte Anwendung nicht
+brauchbar, denn man kommt nicht mehr an die Nachricht, aber in anderen
+Bereichen sind diese so genannten Hashverfahren sehr weit verbreitet.
+
+Alle heute verwendeten symmetrischen Verschl"usselungsverfahren
+verwenden zus"atzlich Schl"ussel. Erst mit einem Schl"ussel wird die
+genaue Methode festgelegt, mit der die Nachricht verschl"usselt wird.
+Jemand, der die verschl"usselte Nachricht liest, mu"s also nicht nur
+das grunds"atzliche Verfahren kennen, sondern insbesondere mu"s er den
+Schl"ussel herausbekommen, um die Nachricht lesen zu k"onnen. Das
+Raten des Schl"ussels ist meistens der viel schwierigere Teil, da es
+sehr viel mehr Schl"ussel gibt als Verschl"usselungsverfahren. An
+dieser Stelle kommt die vielzitierte Schl"ussell"ange ins Spiel. Wenn
+ein Schl"ussel wie bei DES 56 Bit lang ist, dann gibt es $2^56 =
+72.057.594.037.927.936$ verschiedene Schl"ussel. Mit heutiger
+Technologie k"onnen diese Schl"ussel alle in kurzer Zeit ausprobiert
+werden, daher arbeiten moderne Verfahren mit mindestens 128 Bit langen
+Schl"usseln. Man nimmt an, da"s $2^128$ Schl"ussel auch in der
+absehbaren Zukunft nicht alle durchprobiert werden k"onnen. Abbildung
+\ref{symmetrisch} verdeutlicht die symmetrische Verschl"usselung.
+
+\begin{figure}\[
+\setlength{\unitlength}{1cm}
+\begin{picture}(11,3.5)
+
+\put(0,0){\framebox(11,3.5){}}
+
+\put(4,0){\line(0,1){3.5}}
+\put(7,0){\line(0,1){3.5}}
+\put(0,2.5){\line(1,0){11}}
+
+\put(2,3){\makebox(0,0){Alice}}
+\put(5.5,3){\makebox(0,0){Eve}}
+\put(9,3){\makebox(0,0){Bob}}
+
+\put(0.2,1.5){\framebox(1,0.5){Pssst!}}
+\put(1.2,1.75){\vector(1,0){0.8}}
+\put(2,1.5){\framebox(1,0.5){AES}}
+\put(3,1.75){\vector(1,0){1.6}}
+\put(1.6,0.3){\framebox(1.8,0.5){Schl"ussel}}
+\put(2.5,0.8){\vector(0,1){0.7}}
+
+\put(4.6,1.5){\framebox(1.8,0.5){@Yx!?a\{}}
+\put(6.4,1.75){\vector(1,0){1.6}}
+
+\put(8,1.5){\framebox(1,0.5){AES}}
+\put(7.6,0.3){\framebox(1.8,0.5){Schl"ussel}}
+\put(8.5,0.8){\vector(0,1){0.7}}
+\put(9,1.75){\vector(1,0){0.8}}
+\put(9.8,1.5){\framebox(1,0.5){Pssst!}}
+
+\end{picture}\]
+\caption{Symmetrische Verschl"usselung}
+\label{symmetrisch}
+\end{figure}
+
+\subsection{Challenge-Response Verfahren}
+
+Werden im SMB-Protokoll verschl"usselte Pa"sw"orter verwendet, so wird
+die symmetrische Verschl"usselung trickreich eingesetzt. Der Client
+m"ochte eine Verbindung zum Server aufbauen. Bevor dies geschieht,
+mu"s der Benutzer seinen Namen und sein Pa"swort eingeben. Erst danach
+baut der Client die Verbindung zum Server auf. In der Antwort auf die
+erste Anfrage des Clients, der Negotiate Protocol Response, schickt
+der Server dem Client eine Zufallszahl. Diese Zufallszahl wird
+Herausforderung genannt.
+
+Der Client verf"ugt nun "uber drei Werte: Den Benutzernamen, das
+Pa"swort des Benutzers und die Herausforderung. Das Pa"swort soll nun
+verschl"usselt "uber das Netz "ubertragen werden. Ein naiver Ansatz
+w"are, die Herausforderung als Schl"ussel f"ur ein symmetrisches
+Verschl"usselungsverfahren einzusetzen. Der Server kennt die
+Herausforderung, da er sie selbst verschickt hat, kann also das
+verschl"usselte Pa"swort wieder entschl"usseln. Das Problem liegt
+darin, da"s jeder Zuh"orer ebenfalls den Schl"ussel kennt, also auch
+das Pa"swort entschl"usseln kann. Daher wird anders vorgegangen: Das
+Pa"swort wird als Schl"ussel benutzt, um die Herausforderung zu
+verschl"usseln. Diese mit dem Pa"swort verschl"usselte Herausforderung
+schickt der Client im Session Setup zusammen mit dem Benutzernamen an
+den Server.
+
+Wor"uber verf"ugt der Server, wenn er den Session Setup erhalten hat?
+Er hat sich die Zufallszahl gemerkt, und der Client hat im den
+Benutzernamen geschickt. Aus der Benutzerdatenbank kann er damit das
+Pa"swort des Benutzers auslesen. Mit diesem ausgelesenen Pa"swort als
+Schl"ussel entschl"usselt der Server die verschl"usselte
+Herausforderung und pr"uft, ob wieder die versendete Zufallszahl
+herauskommt. Ist dies der Fall, stimmen die beiden Schl"ussel
+"uberein. Das hei"st, der Client hat die als Herausforderung gesendete
+Zufallszahl mit dem gleichen Pa"swort verschl"usselt, das auch der
+Server in seiner Benutzerdatenbank gespeichert hat. Stimmt der
+entschl"usselte Wert nicht mit der gesendeten Zufallszahl "uberein,
+wurde f"ur die Verschl"usselung ein anderer Schl"ussel, also ein
+anderes Pa"swort, benutzt, als f"ur die Entschl"usselung. Das am
+Client eingegebene Pa"swort stimmt also nicht mit dem "uberein, das
+der Server in seiner Benutzerdatenbank gespeichert hat. Der Server
+bekommt nicht heraus, welches Pa"swort der Client benutzt hat, aber
+das mu"s er auch gar nicht. Das Pa"swort war in jedem Fall falsch.
+
+Abbildung \ref{encrypt-challenge} verdeutlicht die verwendete
+Verschl"usselung, Abbildung \ref{challenge-requests} den zeitlichen
+Ablauf des Protokolls.
+
+\begin{figure}\[
+\setlength{\unitlength}{1cm}
+\begin{picture}(11,3.5)
+
+\put(0,0){\framebox(11,3.5){}}
+
+\put(4,0){\line(0,1){3.5}}
+\put(7,0){\line(0,1){3.5}}
+\put(0,2.5){\line(1,0){11}}
+
+\put(2,3){\makebox(0,0){Client}}
+\put(5.5,3){\makebox(0,0){Zuh"orer}}
+\put(9,3){\makebox(0,0){Server}}
+
+\put(0.2,1.5){\framebox(1.2,0.5){Zufall}}
+\put(1.4,1.75){\vector(1,0){0.6}}
+\put(2,1.5){\framebox(1,0.5){DES}}
+\put(3,1.75){\vector(1,0){1.6}}
+\put(1.6,0.3){\framebox(1.8,0.5){Pa"swort}}
+\put(2.5,0.8){\vector(0,1){0.7}}
+
+\put(4.6,1.5){\framebox(1.8,0.5){@Yx!?a\{}}
+\put(6.4,1.75){\vector(1,0){1.6}}
+
+\put(8,1.5){\framebox(1,0.5){DES}}
+\put(7.6,0.3){\framebox(1.8,0.5){Pa"swort}}
+\put(8.5,0.8){\vector(0,1){0.7}}
+\put(9,1.75){\vector(1,0){0.5}}
+\put(9.5,1.5){\framebox(1.3,0.5){Zufall?}}
+
+\end{picture}\]
+\caption{Verschl"usselung der Herausforderung}
+\label{encrypt-challenge}
+\end{figure}
 
 \begin{figure}\[
 \begin{pspicture}(11.5,6.5)
@@ -1923,113 +3639,131 @@ richtig.
 \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{->}(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){=?}
+% \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}
+\label{challenge-requests}
 \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.
+Warum ist das Verfahren sicher? Die mit dem Pa"swort verschl"usselte
+Herausforderung hat den Server davon "uberzeugt, da"s der Benutzer
+sein Pa"swort kennt. Man k"onnte vermuten, da"s man diese
+verschl"usselte Herausforderung einfach nochmal schicken mu"s, um die
+Rechte des Benutzers zu bekommen. Dieser so genannte Replay-Angriff
+schl"agt jedoch fehl, da bei jeder neuen Anmeldung eine neue
+Herausforderung verschl"usselt werden mu"s. Dies gilt nat"urlich nur,
+wenn der Server sich jedes Mal eine neue Herausforderung
+ausdenkt$\ldots$
 
 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.
+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?
+
+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"usselungsalgorithmus gew"ahlt werden, der
+gegen einen solchen Angriff f"ur alle praktischen Belange immun ist.
+
+\subsection{Vor- und Nachteile von verschl"usselten Pa"sw"ortern}
+
+Das Challenge-Response 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. Die meisten
+Linuxsysteme speichern diesen Wert in der Datei \dateistyle{/etc/shadow},
+andere Unixe k"onnen die Pa"swortdatenbank in anderen Dateien abspeichern. Der
+Wert, der dort gespeichert wird, ist f"ur die Authentifizierung benutzbar. Der
+Server ist jedoch nicht in der Lage, daraus das Klartextpa"swort des Benutzers
+zu berechnen.
+
+Die Authentifizierung unter Unix benutzt eine Hashfunktion, die drei
+Eigenschaften erf"ullt:
 
 \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.
+\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, bei denen es keinen R"uckweg gibt, der
+irgendwie berechnet werden kann. Um f"ur einen Funktionswert den Ausgangswert
+herauszubekommen, mu"s man alle m"oglichen Ausgangswerte durchprobieren oder
+gleich eine Wertetabelle mit allen Ausgangswerten anlegen.\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 so genannte 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 \dateistyle{/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.
+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"swortdatenbankgepflegt
+werden, die Datei \dateistyle{smbpasswd}.
+
+Was bis jetzt beschrieben wurde, entspricht nur fast der Wahrheit. Oben wurde
+beschrieben, da"s die Verschl"usselung der Herausforderung mit dem Pa"swort des
+Benutzers geschieht. Dies ist so nicht ganz richtig. Die Verschl"usselung
+geschieht mit einem Hashwert des Pa"swortes. Dieser Hashwert wird vom Client
+direkt nach Eingabe des Pa"swortes gebildet und gespeichert. Das gesamte oben
+beschriebene Verfahren wird dann mit diesem Hashwert durchgef"uhrt. Das hei"st,
+da"s auch in der Datei \dateistyle{smbpasswd} keine echten Klartextpa"sw"orter
+gespeichert werden m"ussen, sondern diese Hashwerte. Das hei"st, da"s man mit
+den dort enthaltenen Werten so direkt nicht mehr anfangen kann als mit den
+Werten aus der Datei \dateistyle{/etc/shadow} unter Unix. 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
+\dateistyle{smbpasswd} ohne Einsatz von crack bei einem NT-Rechner
+anzumelden. Damit sind die Werte aus der \dateistyle{smbpasswd} so gut wie
+Klartextpa"sw"orter.
 
 Alles nicht dramatisch, sagt Microsoft. Das "Aquivalent zur Datei
-\datei{smbpasswd} liegt unter NT verschl"usselt vor. Diese
+\dateistyle{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.}.
+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
+\dateistyle{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.
@@ -2037,19 +3771,22 @@ 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.
+des Benutzers nicht kennt. Windows 2000 mit dem dort eingesetzten
+Kerberos-Verfahren ist in dieser Hinsicht "ubrigens nicht besser. Der
+Dom"anencontroller kennt hier ebenfalls die Klartextpa"sw"orter der Benutzer.
+Ihm wird also genau so vertraut wie einem NT4-Dom"anencontroller.
 
 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.
+Klartextpa"sw"ortern seiner Benutzer interessiert sein, dann macht NT
+es ihm deutlich einfacher als Unix dies tut. Unix verwendet so
+genannte 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
+\dateistyle{/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
@@ -2059,20 +3796,128 @@ 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.
 
+\subsection{NT4 Service Pack 3}
+
+Um die Pa"swortverschl"usselung im Zusammenhang mit Windows NT 4
+Service Pack 3 und Windows 95 in sp"ateren Versionen gibt es immer
+noch weitverbreitete Mi"sverst"andnisse. Beispielsweise da"s alle
+Systeme vorher nicht in der Lage waren, mit verschl"usselten
+Pa"sw"ortern zu arbeiten. Richtig ist folgendes:
+
+\begin{itemize}
+\item \emph{Alle} Clients sind in der Lage, mit verschl"usselten
+  Pa"sw"ortern umzugehen. Das gilt f"ur alle aktuellen Clients
+  sowieso. Aber sogar der DOS-LanManager-Client, den man sich heute
+  noch von Microsofts FTP-Server laden kann, kann Pa"sw"orter
+  verschl"usseln.
+\item Auch die neuen Clients k"onnen sowohl mit verschl"usselten
+  Pa"sw"ortern, als auch mit Klartextpa"sw"ortern umgehen.
+\item Windows NT4 Service Pack 3 ist das erste NT-System, das sich in
+  der Default-Einstellung weigert, Klartextpa"sw"orter zu verschicken.
+\end{itemize}
+
+Ein Client wirkt an der Entscheidung "uber verschl"usselte Pa"sw"orter
+zun"achst einmal "uberhaupt nicht mit. Der Server wird f"ur
+verschl"usselte oder f"ur Klartextpa"sw"orter mit der Einstellung
+\param{encrypt passwords} konfiguriert. In der Antwort zum Negotiate
+Protocol teilt der Server dem Client seine Entscheidung mit. Der
+Server verschickt im Falle der verschl"usselten Pa"sw"orter noch eine
+Herausforderung mit. Der Server teilt dem Client m"oglicherweise mit,
+da"s er ein Klartextpa"swort sehen will. Der Client kann nur noch die
+Verbindung sofort abbrechen, sofern er keine Pa"sw"orter im Klartext
+verschicken m"ochte. Windows NT tut dies ab Service Pack 3 mit der
+Fehlermeldung, da"s man sich micht diesem Konto nicht an dem Server
+anmelden kann. 
+
+\begin{center}
+\epsfig{file=konto.eps,width=6cm}
+\end{center}
+
+Windows 95 und folgende fragen immer wieder nach dem Kennwort f"ur die
+Freigabe \texttt{IPC\$}. F"ur alle Clientbetriebssysteme liefert Samba
+im Unterverzeichnis \dateistyle{docs/} Registrierungsdateien mit, mit
+denen diese Verweigerung von Klartextpa"sw"ortern abgestellt werden
+kann.
+
+Mit Klartextpa"sw"ortern bekommt man den gro"sen Vorteil, da"s man
+nicht zwei verschiedene Pa"swortdatenbanken pflegen mu"s. Einige
+Nachteile handelt man sich jedoch ein:
+
+\begin{itemize}
+\item Man mu"s heutzutage jeden Client anfassen, um die Registrierung
+  zu "andern.
+\item Man versendet Pa"sw"orter im Klartext, man hat also ein
+  m"oglicherweise erhebliches Sicherheitsproblem. Tools wie
+  \prog{dsniff}\footnote{Suchen Sie einmal auf http://freshmeat.net
+    nach dsniff und lesen Sie das README.} sammeln die Pa"sw"orter
+  automatisch auf.
+\item Man verliert jegliche Dom"anenfunktionalit"at, auf die weiter
+  unten noch genauer eingegangen wird. Ein Dom"anencontroller kann nur
+  mit verschl"usselten Pa"sw"ortern funktionieren.
+\end{itemize}
+
+Insgesamt kann man nur zu verschl"usselten Pa"sw"ortern raten, wenn
+nicht wirklich wichtige Gr"unde f"ur Klartextpa"sw"orter sprechen.
+
+\subsection{Migration zu verschl"usselten Pa"sw"ortern}
+
+Sind momentan Klartextpa"sw"ortern auaf einem Server im Einsatz, und
+ist die Migration zu verschl"usselten Pa"sw"ortern geplant, gibt es
+einen sehr einfachen Weg, dies binnen einer Woche ohne gro"se Arbeit
+zu erledigen. Direkt aus der \dateistyle{/etc/shadow} bekommt man die
+die NT- und LanManager-Hashes leider nicht heraus, da man dazu die
+Klartextpa"sw"orter ben"otigt. Nur aus diesen k"onnen die
+Windows-Hashwerte berechnet werden. Die Clients liefern die
+Pa"sw"orter jedoch bei jedem Anmelden im Klartext zum Server, und
+daraus k"onnen dann die Hashwerte berechnet werden. Dazu mu"s man aus
+der \dateistyle{/etc/passwd} mit dem Skript
+\dateistyle{mksmbpasswd.sh} zun"achst eine Datei
+\dateistyle{smbpasswd} machen, in der alle Benutzer mit leerem
+Pa"swort angelegt sind. Dieses Skript findet sich in den Samba-Quellen
+im Unterverzeichnis \dateistyle{source/script}. Die neu angelegte
+\dateistyle{smbpasswd} mu"s dann mit den korrekten Zugriffsrechten
+versehen werden:
+
+\begin{verbatim}
+sh mksmbpasswd.sh < /etc/passwd > /etc/smbpasswd
+chown root.root /etc/smbpasswd
+chmod 700 /etc/smbpasswd
+\end{verbatim}
+
+Die Migration leitet man mit den folgenden Einstellungen ein:
+
+\begin{verbatim}
+[global]
+   encrypt passwords = no
+   update encrypted = yes
+\end{verbatim}
+
+Jeder Benutzer, der sich anmeldet, liefert sein Pa"swort im Klartext
+an den Server. Dieser berechnet daraus die beiden Windows-Hashwerte
+und tr"agt sie in der \dateistyle{/etc/smpasswd} ein. Das hei"st, man
+mu"s jetzt nur abwarten, bis sich alle Benutzer einmal angemeldet
+haben, und kann dann verschl"usselte Pa"sw"orter aktivieren:
+
+\begin{verbatim}
+[global]
+   encrypt passwords = yes
+   update encrypted = no
+\end{verbatim}
+
 \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.
+\dateistyle{/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
+unter Linux so genannte 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
@@ -2109,7 +3954,7 @@ 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
+Diese so genannten 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.
@@ -2129,10 +3974,10 @@ 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
+Druckerwarteschlange unter Unix angesprochen werden soll. Diese
+Warteschlange 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
+werden, oder die Daten sollten per so genannter Raw-Queue direkt ohne
 Umwandlung an den Drucker weitergeleitet werden.
 
 Die Option \param{path =} legt einen Spoolbereich fest. Ein Druckjob,
@@ -2146,315 +3991,866 @@ 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}
+\section{Windows NT Dom"anen}
 
-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:
+Installiert man eine Arbeitsgruppe von Windows NT Rechnern, dann
+bekommt man komplett getrennte Benutzerdatenbanken auf den einzelnen
+Rechnern. Erstellt man auf einem Server eine Freigabe und m"ochte f"ur
+diese Freigabe Rechte vergeben, so mu"s man zun"achst die
+Benutzer\footnote{Windows NT benutzt grunds"atzlich \param{security =
+    user}} einrichten, die Rechte auf dieser Freigabe bekommen sollen.
+Greift ein Benutzer von einer anderen Workstation auf die Freigabe zu,
+so probiert die Workstation das so genannte transparente Anmelden: Die
+Workstation versucht es erst einmal mit dem lokal angemeldeten
+Benutzer und seinem Pa"swort. Dadurch sieht es so aus, als ob man nur
+ein Benutzerkonto verwenden w"urde.
+
+Die Administration der Benutzerdatenbanken kann komplett von einem
+zentralen Rechner aus erfolgen. Dazu ben"otigt man den Benutzermanager
+f"ur Dom"anen\footnote{Benutzermanager f"ur Dom"anen}, der
+normalerweise bei Windows NT Server mitgeliefert wird. Man kann sich
+diesen aber auch kostenlos von Microsoft von der Webseite
+\url{http://www.microsoft.com/} beziehen. Man mu"s zu dem Rechner, den
+man administrieren m"ochte, eine Verbindung als Administrator
+aufbauen. Dazu mu"s man auf der Workstation, von der aus man
+administriert, auf der Kommandozeile mit 
+
+\begin{verbatim}
+net use \\remote\ipc$ /user:administrator
+\end{verbatim}
+
+eine Verbindung aufgebaut werden. Kommt dann die Fehlermeldung
+\emph{Die Referenzen passen nicht zu einer bestehenden
+  Referenzenmenge}, so besteht unter einer anderen Benutzerkennung
+bereits eine Verbindung. In diesem Fall mu"s man sich ab- und neu
+anmelden, und den Befehl als allererstes absetzen, bevor irgend eine
+Verbindung zum entfernten Rechner \nbname{remote} aufgebaut werden
+kann. Hat man eine solche Verbindung, kann man im Benutzermanager f"ur
+Dom"anen im Men"upunkt \emph{Dom"ane ausw"ahlen} mit
+\nbname{\textbackslash{}\textbackslash{}remote} die Benutzerdatenbank
+von \nbname{remote} ausw"ahlen und voll administrieren.
+
+Diese Art der Administration skaliert nicht besonders gut. Jeden
+Benutzer mu"s es auf jedem Server geben, die lokalen Workstations
+brauchen ebenfalls separat gepflegte Benutzer. Mit Windows NT wurde,
+um dieses Problem zu l"osen, das Dom"anenkonzept eingef"uhrt. Mit
+einer Windows NT Dom"ane bekommt jeder Benutzer ein zentrales Konto,
+das auf allen Dom"anenmitgliedern g"ultig ist.
+
+Realisiert ist die Dom"ane durch einen speziellen Rechner, den Primary
+Domain Controller PDC, der seine Benutzerdatenbank f"ur andere im Netz
+zur Verf"ugung stellt. Alle Dom"anenmitglieder importieren diese
+Benutzerdatenbank. Somit sind auf den Dom"anenmitgliedern zwei
+Benutzerdatenbanken g"ultig: Die lokale und die des PDC.
+
+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 den 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. Das hei"st, es mu"s f"ur jedes Dom"anenmitglied ein
+Benutzerkonto auf dem PDC geben, damit f"ur dieses Konto ein Pa"swort
+vergeben werden kann. Dieses Benutzerkonto hei"st "ublicherweise
+Computerkonto.
+
+\section{Samba als Primary Domain Controller}
+
+Um Samba als PDC zu konfigurieren, sind in der \dateistyle{smb.conf}
+im Abschnitt \param{[global]} 2 Einstellungen notwendig:
 
 \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.
+Eine vollst"andige \dateistyle{smb.conf} f"ur einen PDC sieht damit
+folgenderma"sen aus\label{pdc-smbconf}:
 
-\section{Windows NT Dom"anen}
+\begin{verbatim}
+[global]
+  workgroup = samba
+  encrypt passwords = yes
+  domain master = yes
+  domain logons = yes
+\end{verbatim}
+
+Da"s ein PDC auch gleichzeitig Domain Master Browser sein mu"s, ist
+eine Einschr"ankung der Implementation der Microsoft-Clients.
+Eigentlich hat die Funktion des Domain Master Browsers (siehe
+Abschnitt \ref{browsing-im-wan}) nichts mit der Funktion als zentraler
+Server f"ur die Benutzerdatenbank zu tun. Die Clientimplementation von
+Microsoft setzt aber voraus, da"s beide Funktionen auf einer Maschine
+vereinigt sind. Auch funktionieren die Dom"anenfunktionen
+ausschlie"slich mit verschl"usselten Pa"sw"ortern. Ist man auf
+Klartextpa"sw"orter angewiesen, kann man Samba nicht als PDC
+einsetzen.
+
+Befinden sich Windows 9x Clients im Netz, k"onnen diese den Samba-PDC
+sofort ohne weitere Konfiguration als Anmeldeserver nutzen. Dazu
+tr"agt man in den Eigenschaften des Clients f"ur Microsoft-Netzwerke
+ein, da"s sich die Clients an der Samba-Dom"ane anmelden m"ussen. Ist
+dies erfolgreich, so kann man "uber die Systemsteuerung des Clients
+direkt sein SMB-Pa"swort auf dem Server "andern.
+
+\subsection{Manuelles Erstellen der Computerkonten}
+
+F"ur Dom"anenmitglieder unter Windows NT oder 2000 m"ussen noch die
+Computerkonten erstellt werden. Jedes Maschinenkonto mu"s unter Unix
+als normaler Benutzer existieren. Dieser Benutzer braucht weder ein
+Unixpa"swort, noch eine Login-Shell oder ein Heimatverzeichnis.  Der
+Name des Benutzers ist der Name der Workstation, erg"anzt um ein
+\$-Zeichen. Erstellt wird ein solcher Benutzer f"ur die Workstation
+\nbname{WKS} unter Linux beispielsweise mit
+
+\begin{verbatim}
+root@erde: useradd -d /dev/null -s /bin/false wks\$
+root@erde: smbpasswd -a -m wks
+\end{verbatim}
+
+Der Befehl \prog{smbpasswd -a -m wks} f"ugt den Benutzer mit einem
+Standardpa"swort in die Datei \dateistyle{smbpasswd} ein. Das
+Standardpa"swort f"ur Computerkonten ist der Name der Workstation, in
+diesem Fall also \nbname{wks}. 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.
+
+Nachdem das Computerkonto auf dem PDC erstellt wurde, kann in den
+Eigenschaften der Netzwerkumgebung in die Dom"ane gewechselt werden.
+Dabei wird das Pa"swort des Computerkontos ge"andert. Sollte aus
+irgendwelchen Gr"unden ein erneutes Betreten der Dom"ane notwendig
+sein, dann mu"s der Befehl \prog{smbpasswd -a -m wks} erneut
+ausgef"uhrt werden, um das Pa"swort des Computerkontos auf den
+Anfangswert zur"uckzusetzen.
+
+\subsection{Automatisches Erstellen der Computerkonten}
+
+Windows NT 4 bietet in dem Dialog, in dem in die Dom"ane gewechselt
+wird, die M"oglichkeit, das Computerkonto automatisch erstellen zu
+lassen. Dies geschieht unter Angabe eines Benutzers und Kennwortes,
+der auf dem PDC berechtigt ist, Computerkonten zu erstellen. Dies ist
+unter Unix nur \emph{root}, da die \dateistyle{/etc/passwd} hierzu
+ge"andert werden mu"s.
+
+Um das Computerkonto automatisch erstellen zu lassen, m"ussen zwei
+Dinge auf dem PDC konfiguriert sein:
 
-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.
+\begin{itemize}
+\item \emph{root} oder ein anderer Benutzer mit der UID 0 mu"s ein
+  Pa"swort in der \dateistyle{smbpasswd} haben. Dieses Pa"swort mu"s
+  nicht mit dem Systempa"swort von \emph{root} "ubereinstimmen. Wenn
+  man nicht \emph{root}, sondern beispielsweise einen Benutzer
+  \emph{admin} mit der UID 0 verwendet, braucht dieser Benutzer nicht
+  einmal eine Login-Shell auf Unix. Er mu"s nur in die
+  \dateistyle{/etc/passwd} schreiben d"urfen.
+\item Der Parameter \param{add user script} mu"s korrekt konfiguriert
+  werden. Mit \param{add user script} wird ein Unix-Script angegeben,
+  mit dem das Computerkonto in der \dateistyle{/etc/passwd} angelegt
+  wird. Beispielsweise kann man mit
+
+\begin{verbatim}
+add user script = useradd -d /dev/null -s /bin/false %u
+\end{verbatim}
+
+  die gleiche Wirkung erzielen wie mit der manuellen Konfiguration aus
+  dem letzten Abschnitt.
+\end{itemize}
+
+\subsection{BDCs mit Samba}
+
+In einer echten NT Dom"ane gibt es zwei Arten von Dom"anencontrollern:
+Prim"are Dom"anencontroller (PDCs) und Backup Dom"anencontroller
+(BDCs). Der PDC besitzt die Hauptkopie der Benutzerdatenbank
+SAM\todo{uebersetzung}, die BDCs halten read-only Kopien der SAM vor,
+um Authentifizierungsanfragen von Workstations und Mitgliedsservern
+beantworten zu k"onnen. Alle "Anderungen an der Benutzerdatenbank,
+beispielsweise Pa"swort"anderungen, m"ussen auf dem PDC durchgef"uhrt
+werden. Der PDC "ubertr"agt diese "Anderungen dann an die BDCs, damit
+diese wieder "uber den aktuellen Stand der Datenbank verf"ugen.
+
+Samba 2.2.2 ist noch kein voller Ersatz f"ur einen Backup Domain
+Controller in einer echten NT-Dom"ane. Auch kann Samba als PDC keinen
+echten NT-BDC mit Dom"anendaten versorgen. Die Protokolle zur
+Replikation der Benutzerdatenbank sind noch nicht vollst"andig
+implementiert. Das Samba Team, insbesondere Tim Potter, arbeitet
+jedoch daran, die Protokolle zu verstehen und in Samba zu integrieren.
+Vermutlich ist mit Erscheinen dieses Buches die echte
+BDC-Funktionalit"at bereits in Samba integriert.
+
+Wird Samba als PDC eingesetzt, k"onnen weitere Sambaserver jedoch als
+Backup Domain Controller eingesetzt werden. Die Replikation der
+Benutzerdatenbank zwischen den Servern kann mit Unix-Bordmitteln
+vorgenommen werden. Die wesentliche Idee beim Einsatz eines BDC ist
+seine \dateistyle{smb.conf}:
+
+\begin{verbatim}
+workgroup = samba
+encrypt passwords = yes
+domain master = no
+domain logons = yes
+\end{verbatim}
+
+Der Unterschied zum PDC ist die Zeile \param{domain master = no} im
+Gegensatz zu \param{domain master = yes}. Mit dieser
+\dateistyle{smb.conf} sehen die Workstations den BDC als
+Dom"anencontroller f"ur die Dom"ane \nbname{SAMBA} an.
+
+Wenn eine Workstation einen Benutzer authentifizieren mu"s, tut sie
+dies nicht selbst, sondern sucht ihren Dom"anencontroller f"ur die
+Best"atigung der Identit"at des Benutzers. Dies tut sie, indem sie
+eine NetBIOS-Namensanfrage nach dem Namen \nbname{SAMBA<1c>} absetzt.
+\nbname{SAMBA<1c>} ist ein NetBIOS-Gruppenname, den jeder
+Dom"anencontroller per Broadcast oder beim WINS-Server reserviert.
+Diese Reservierung wird bei Samba durch den Parameter \nbname{domain
+  logons = yes} angesto"sen. Im n"achsten Schritt authentifizieren
+sich die Workstation und der Dom"anencontroller gegenseitig anhand des
+Workstationkontos. Dieses Workstationkonto mu"s somit sowohl auf dem
+PDC, als auch auf den BDCs vorhanden sein, damit die Workstation auch
+die BDCs als Dom"anencontroller akzeptiert. Auch die gesamte restliche
+Benutzerdatenbank mu"s vom PDC auf die BDCs "ubertragen werden.
+
+\subsection{Hintergrund: Benutzerdatenbanken und SIDs}
 
 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.
+Userid er hat. Dazu sieht es in der Datei \dateistyle{/etc/passwd}
+nach.  Mit der Datei \dateistyle{/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.
+Tabellen "uber verschiedene Rechner hinweg. Genau das tut NIS. Die
+Benutzerdatenbank wird im Netz kopiert, gilt aber
+auf jedem Rechner rein lokal.
+
+Unter NT ist das zun"achst genau so. Es gibt eine numerische Userid,
+der Name des Benutzers ist nur w"ahrend der Anmeldung f"ur das System
+interessant. Nach der Anmeldung ist nur noch die numerische Userid
+relevant. Windows NT Benutzer sind jedoch im Gegensatz zu Unix
+Benutzern "uber Rechnergrenzen hin g"ultig. Um dies zu erreichen, wird
+der Benutzer nicht durch eine kleine Zahl beschrieben, sondern durch
+einen so genannten Security Identifier SID. Dieser SID besteht aus zwei
+wesentlichen Teilen. Der erste Teil besteht aus einer 96 Bit langen
+Zahl, die die Benutzerdatenbank des SID eindeutig identifiziert. Der
+zweite Teil ist der so genannte Relative Identifier RID. Der RID ist
+mit der numerischen Userid unter Unix vergleichbar. Da eine Userid
+unter NT jedoch \emph{nur} zusammen mit den 96 Bit der
+Benutzerdatenbank verwendet werden, sind Benutzer unterschiedlicher
+Maschinen oder Dom"anen unterscheidbar.
+
+Mit dieser eindeutigen Zuordnung von Benutzern zu ihren jeweiligen
+Benutzerdatenbanken wird es m"oglich, da"s eine Workstation
+gleichnamige Benutzer aus mehreren Benutzerdatenbanken lokal v"ollig
+gleichwertig verwenden kann. Je nachdem, ob sich ein Dom"anenbenutzer
+oder ein lokaler Benutzer an der Workstation anmelden m"ochte, wird
+die lokale Benutzerdatenbank oder die des PDC um Best"atigung des
+Kennwortes gebeten. Ist dies erfolgt, ist der Benutzer dem System nur
+noch unter dem numerischen SID bekannt. Dabei ist es v"ollig
+gleichg"ultig, ob es sich bei diesem SID um einen lokalen, oder einen
+Dom"anen-SID handelt.
+
+Jeder Sambaserver generiert beim ersten Start seine eigene
+Maschinenkennung und speichert sie in der Datei
+\dateistyle{MACHINE.SID} ab. Die Maschinenkennung wird sp"atestens
+dann ben"otigt, wenn der Sambaserver als Dom"anencontroller
+konfiguriert wird. Die Benutzer, die sich an den Workstations
+anmelden, m"ussen eine eindeutige Dom"anenkennung als Teil ihres SID
+bekommen. Selbst wenn der Sambaserver nicht als Dom"anencontroller
+fungiert, wird die Maschinenkennung verwendet. Beispielsweise bei der
+Anzeige der ACLs in den Sicherheitseigenschaften von Dateien und
+Verzeichnissen wird die Liste der Benutzer in Form eine SID-Liste
+"ubergeben. Diese SIDs m"ussen eindeutig sein und mit separaten
+Aufrufen in Benutzernamen "ubersetzt werden k"onnen.
+
+\section{Profile, Logon Scripts und Policies}
+
+Unter Unix gibt es f"ur jeden Benutzer ein Heimatverzeichnis als
+einzigen Bereich im System, in dem der Benutzer schreiben kann. So
+etwas kennt Windows in dieser restriktiven Form nicht, da viele
+Anwendungen voraussetzen, "uberall im System schreiben zu k"onnen. Aus
+Kompatibilit"atsgr"unden mu"s Windows also relativ offen sein. Dem
+Heimatverzeichnis am n"achsten kommt unter NT das Profil des
+Benutzers, ein ihm zugeordneter Bereich unter
+\verb|c:\winnt\profiles\<benutzername>|. Dort ist der Desktop, der
+benutzereigene Teil des Startmen"us, der Zweig HKEY\_CURRENT\_USER der
+Registry und vieles andere abgelegt. Also alles, was zur
+Arbeitsumgebung des Benutzers geh"ort.
+
+Meldet sich ein Benutzer bei NT das erste Mal an, wird aus
+\verb|c:\winnt\profiles\default user| eine Kopie in das benutzereigene
+Profil gelegt. Beim Anmelden an der n"achsten Workstation wird der
+gleiche Vorgang wiederholt. Das hei"st, jeder Benutzer hat an jeder
+Workstation ein anderes Profil. In einer Dom"anenumgebung m"ochte man
+nat"urlich erreichen, da"s ein Benutzer sein Profil mitnehmen kann,
+da"s er also an jedem Arbeitsplatz seine eigene Umgebung vorfindet.
+Windows l"ost dies mit den serverbasierten Profilen.
+
+F"ur jeden Benutzer kann ein Pfad angegeben werden, in dem sein Profil
+abgelegt wird. Viele Anwendungen setzen aber voraus, da"s das Profil auf
+einer lokalen Platte abgelegt wird. Folglich kopiert Windows beim Anmelden
+des Benutzers das Profil von seinem Serverpfad nach \verb|c:\winnt\profiles|
+und bei jedem abmelden wieder zur"uck auf den Serverpfad.
+
+Der Pfad f"ur das serverbasierte Profil wird bei Samba mit dem
+Parameter \param{logon path} festgelegt. Der Standardpfad steht auf
+\param{logon path =
+\textbackslash{}\textbackslash{}\%N\textbackslash{}\%U\textbackslash{}profile}
+.
+Damit wird im Heimatverzeichnis des Benutzers auf dem PDC ein
+Verzeichnis namens \dateistyle{profile} angelegt und das Profil dort
+gespeichert.  Leider kann man mit Samba nicht sauber f"ur einzelne
+Benutzer festlegen, da"s sie ihre Profile auf einem Server ablegen,
+andere Benutzer ihre Profile aber lokal auf den Workstations belassen.
+
+\todo{logon home f"ur win95}
+
+\subsection{Anmeldeskripte}
+
+Meldet sich ein Benutzer an einer Dom"ane an, kann der Primary Domain
+Controller der Workstation mitteilen, da"s unter den Rechten des Benutzers
+eine Batchdatei automatisch ausgef"uhrt werden soll, das so genannte
+\emph{Logon Script}. Samba kennt den Parameter \param{logon
+  script}, mit dem der Name des Logon Schriptes festgelegt wird.
+Standarm"a"sig gibt es kein Logon Script. Wird eines festgelegt,
+bezieht es sich immer auf eine \dateistyle{.bat}-Datei in der
+festgelegten Freigabe \param{[netlogon]}. Eine vollst"andige
+\dateistyle{smb.conf} f"ur einen PDC s"ahe so aus:
 
-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
+\begin{verbatim}
+[global]
+workgroup = samba
+encrypt passwords = yes
+domain master = yes
+domain logons = yes
+
+logon script = logon.bat
+
+[homes]
+writeable = yes
+valid users = %S
+
+ [netlogon]
+path = /data/netlogon
 \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.
+Ein einfaches Logon Script in \dateistyle{/data/netlogon/logon.bat}
+kann so aussehen:
+
+\begin{verbatim}
+@echo off^M
+net use h: \\pdc\homes^M
+\end{verbatim}
+
+Die \verb|^M|-Zeichen am Zeilenende bezeichnen die
+DOS-Zeilenendekonvention, bei der an jedem Zeilenende zuerst ein
+Carriage Return und dann ein Linefeed kommt. Unix kennt nur den
+Linefeed als Zeilenende. Der Carriage Return ist hier entscheidend, da
+ansonsten Windows diese Batchdatei nicht ausf"uhren wird. Wenn ein
+Logon Script unter Unix editiert wird, bekommt man den Carriage Return
+im Editor normalerweise durch die Kombination Control-V Control-M.
+Moderne Editoren wie der vim oder der Emacs erkennen eine existierende
+Datei mit DOS-Zeilenendekonvention automatisch und speichern sie auch
+entsprechend wieder ab.
 
 \section{Samba als Dom"anenmitglied}
+\label{domain-member}
+Wenn man mehr als einen Sambaserver betreibt oder einen echten Windows-Server
+betreibt, ben"otigt man genau so wie mit einer echten Windows-Dom"ane eine
+zentrale Benutzerverwaltung.
+
+Die zentrale Verwaltung der Pa"sw"orter ist ein erster Schritt. Um dies zu
+erreichen, mu"s man mit Samba eine Windows NT-Dom"ane betreten.  Dazu setzt
+man in der \dateistyle{smb.conf} folgende Parameter:
+
+\begin{verbatim}
+[global]
+  workgroup = windows
+  security = domain
+  password server = *
+  encrypt passwords = yes
+  name resolve order = wins bcast
+\end{verbatim}
+
+Im Kapitel \ref{smb-sitzungen} wurde beschrieben, wie eine SMB-Sitzung
+aufgebaut wird. Dort wurde auf den Unterschied zwischen \param{security
+= share} und \param{security = user} eingegangen. \param{security = domain}
+verh"alt sich aus der Sicht eines Clients genau wie \param{security = user},
+es wird vom Benutzer im Session
+Setup ein Benutzername, eine Dom"ane und ein Kennwort verlangt. Ist das
+Kennwort nicht korrekt, so wird der Benutzer zur"uckgewiesen.  Der Parameter
+\param{security = domain} bewirkt nun, da"s das Pa"swort nicht wie bei
+\param{security = user} in der lokalen \dateistyle{smbpasswd} nachgesehen
+wird, sondern an einen PDC weitergeleitet wird. Dieser entscheidet dann, ob
+das Pa"swort korrekt ist oder nicht. Best"atigt der PDC das Pa"swort,
+akzeptiert Samba den Benutzer. Kann der PDC die Benutzeridentit"at nicht
+best"atigen, macht Samba einen zweiten Versuch anhand der lokalen
+\dateistyle{smbpasswd}. Damit kann man es erreichen, da"s f"ur Administratoren
+der Zugriff auf den Sambaserver noch m"oglich ist, falls einmal kein
+Dom"anencontroller verf"ugbar sein sollte.
+
+Zus"atzlich zu \param{security = domain} gibt es noch
+\param{security = server}. Diese Einstellung ist jedoch nicht mehr zu
+empfehlen, dazu mehr am Ende des Kapitels.
+
+F"ur den Parameter \param{password server} gibt es zwei
+M"oglichkeiten.  Entweder man setzt ihn auf * wie im Beispiel
+geschehen. Dann sucht sich Samba mit NT-konformen Mitteln selbst den
+PDC oder einen BDC, um Benutzer zu authentifizieren. Man kann aber
+auch eine Liste von NetBIOS-Namen angeben, mit denen Samba arbeiten
+soll. In beiden F"allen ist es wichtig, da"s die Namensaufl"osung
+einwandfrei funktioniert. Samba mu"s in der Lage sein, einen
+Dom"anencontroller f"ur die Authentifizierung zu finden. Dies ist eine
+der wenigen Stellen, bei denen Samba als NetBIOS-Client arbeitet.
+Daher ist es hier m"oglicherweise n"otig, die \param{name resolve
+  order} korrekt zu setzen. Insbesondere ist dies wichtig, wenn die
+Namen der PDCs im DNS bereits vergeben sind und vielleicht auf andere
+Maschinen zeigen als die entsprechenden NetBIOS-Namen.
+
+Um f"ur bestimmte Benutzer nicht auf den PDC angewiesen zu sein,
+versucht Samba bei einem erfolglosen Versuch der Dom"anenanmeldung
+zus"atzlich, den Benutzer in der \dateistyle{smbpasswd} zu finden.
+Damit kann der Server mit m"oglicherweise nicht aktuellen Pa"sw"ortern
+funktionsf"ahig gehalten werden, auch wenn der PDC einmal ausfallen
+sollte.
+
+Samba mu"s, um Pa"sw"orter an den PDC weiterzuleiten, genau wie eine
+NT-Workstation ein Computerkonto auf dem PDC besitzen und die Dom"ane
+betreten. Das Computerkonto kann auf dem PDC mit dem Servermanager
+oder mit dem Kommando
+
+\begin{verbatim}
+net computer <name> /add
+\end{verbatim}
+
+auf der Kommandozeile erledigt werden. Danach kann Samba mit dem
+Aufruf
+
+\begin{verbatim}
+smbclient -j DOMAIN -r PDCNAME
+\end{verbatim}
+
+die Dom"ane betreten. Seit Samba 2.2.2 ist es zus"atzlich m"oglich,
+das Computerkonto wie von einer NT Workstation aus beim Betreten der
+Dom"ane automatisch erstellen zu lassen. Dies geschieht, indem man dem
+Aufruf von \prog{smbpasswd -j} noch einen berechtigten Benutzer
+mitgibt:
+
+\begin{verbatim}
+smbclient -j DOMAIN -r PDCNAME -U Administrator
+\end{verbatim}
 
-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.
+\prog{smbclient} erfragt das Pa"swort des Dom"anenadministrators. Nach
+Eingabe des Pa"swortes wird das Computerkonto auf dem PDC erstellt und
+das entsprechende Pa"swort korrekt gesetzt.
+
+Ist Samba Dom"anenclient, so wird das Pa"swort zum Computerkonto in
+der Datei \dateistyle{secrets.tdb} abgespeichert. Diese
+"ubernimmt damit die Aufgabe der Datei
+\dateistyle{DOMAIN.MACHINE.mac}, die es bis Samba 2.0 gab. Geht diese
+Datei verloren, mu"s die Dom"ane neu betreten werden. Dies kann durch
+Entfernen und wieder Hinzuf"ugen zur Dom"ane mit dem Servermanager und
+nachfolgendes \prog{smbpasswd -j} oder durch ein automatisches
+Erstellen des Computerkontos geschehen.
+
+\todo{allow trusted domains}
+
+Mit der Dom"anenmitgliedschaft wird der Sambaserver nur von der
+Pa"swortverwaltung befreit. Um die Benutzer und Gruppen mu"s er sich
+weiterhin selbst k"ummern. Eine gewisse Erleichterung kann dabei das
+\param{add user script} bringen, das bei Samba als PDC daf"ur gesorgt
+hat, die Computerkonten in der \param{/etc/passwd} automatisch zu
+erstellen.  Ist Samba Dom"anenmitglied, so wird bei einer
+Benutzeranfrage auf den Server zun"achst der PDC nach der Richtigkeit
+des Pa"swortes befragt.  Best"atigt dieser das Pa"swort und will der
+Benutzer dann auf das Dateisystem des Sambaservers zugreifen, so wird
+eine Unix UID ben"otigt, Samba schaut in die \dateistyle{/etc/passwd}.
+Findet Samba dort trotz erfolgreicher Anmeldung am PDC keinen
+Benutzer, so wird das \param{add user script} mit entsprechenden
+Argumenten aufgerufen, um den Benutzer zu erstellen.
+
+Damit mu"s man sich teilweise nicht mehr um die Verwaltung der
+Benutzer auf dem Sambaserver k"ummern. Teilweise deswegen, da von dem
+neu anzulegenden Benutzer ausschlie"slich der Name bekannt ist. Es
+fehlt jegliche Information dar"uber, in welchen Gruppen sich der
+Benutzer in der Dom"ane befindet. Diese Einschr"ankung macht eine
+Rechteverwaltung auf dem Sambaserver sehr schwierig bis unm"oglich.
+
+Unter Unix gibt es mehrere M"oglichkeiten, "uber Rechnergrenzen hinweg die
+Benutzerdatenbanken zu synchronisieren. Das reicht vom unsicheren NIS bis hin
+zur skriptgesteuerten Verteilung der Dateien \dateistyle{/etc/passwd} und
+\dateistyle{/etc/group} "uber rsync und ssh. Setzt man f"ur die Datei- und
+Druckdienste komplett auf Unix mit Samba, kann man so eine zentrale
+Verwaltung der Server erreichen. Die \dateistyle{smbpasswd} mu"s dabei in die
+Verteilung der Benutzerdatenbanken nicht mit einbezogen werden, da hierf"ur
+eine Dom"ane aufgebaut werden kann. Einer der Server wird zum
+Dom"anencontroller erkl"art, die anderen Server sind ganz normale
+Mitgliedsserver, die die Pa"sw"orter vom Dom"anencontroller "uberpr"ufen lassen.
+
+\subsection{Hintergrund: \param{security = server}}
+
+Vor Samba 2.0 gab es f"ur die zentrale Verwaltung von Pa"sw"ortern nur
+die M"oglichkeit, \param{security = server} zu setzen. Damit konnte
+ein Sambaserver sehr einfach die Anmeldung von einem weiteren Server
+oder einer NT Workstation beziehen. Samba 2.0 und 2.2 beherrschen
+diese M"oglichkeit immer noch, man sollte jedoch strikt von ihrer
+Nutzung abraten, da sie erhebliche Probleme mit sich bringt.
+\param{security = server} nutzt nicht das Dom"anencontrollerprotokoll,
+sondern leitet den Benutzernamen und das Pa"swort an einen Server
+weiter. Dies ist im Prinzip nicht schlecht, birgt aber ein subtiles
+Problem. Setzt man keine verschl"usselten Pa"sw"orter ein, verschicken
+viele Clients die Pa"sw"orter in Gro"sbuchstaben. Verlangt der
+Pa"swortserver nun verschl"usselte Pa"sw"orter, mu"s Samba raten. Dies
+kostet Last und Zeit. Setzt man auf dem Sambaserver verschl"usselte
+Pa"sw"orter ein, handelt man sich ein noch subtileres Problem ein. Um
+das zu verstehen, sollte man sich das Kapitel \ref{passwoerter} auf
+jeden Fall genau angesehen haben.
+
+In der Antwort zur Anfrage Negotiate Protocol liefert der Server dem
+Client eine Herausforderung. Im Session Setup mu"s der Client die mit
+dem Pa"swort verschl"usselte Herausforderung liefern. Will Samba dies
+nun gegen"uber einem Pa"swortserver machen, so mu"s er zun"achst einen
+Negotiate Protocol absetzen, um vom Pa"swortserver eine
+Herausforderung zu erhalten. Diese Herausforderung liefert er seinem
+Client direkt weiter, damit dieser sie dann mit dem Pa"swort
+verschl"usseln kann. Da es pro Verbindung vom Client zum Server nur
+einen Negotiate Protocol Request gibt, gilt die Herausforderung f"ur
+die gesamte Verbindung.  Viele Clients setzen aber mehrere Session
+Setups "uber die gleiche Verbindung ab. Damit der Sambaserver zwischen
+Client und Pa"swortserver immer mit der gleichen Herausforderung
+arbeiten kann (der Client sieht nur diese eine Herausforderung), mu"s
+er zum Pa"swortserver st"andig eine Verbindung offen halten. Br"ache
+diese Verbindung ab, bek"ame der Sambaserver vom Pa"swortserver eine
+neue Herausforderung mitgeteilt. Der Sambaserver hat leider keine
+M"oglichkeit, den Client dazu zu zwingen, eine neue Herausforderung zu
+verlangen. Die einzige M"oglichkeit ist, die Verbindung zum Client
+abzubrechen, um einen neuen Negotiate Protocol zu verlangen. Damit
+gibt es zwei Probleme:
 
 \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.
+\item Pro Clientsystem mu"s der Sambaserver st"andig eine Verbindung
+zum Pa"swortserver offenhalten. Damit werden auf dem Pa"swortserver
+erhebliche Resourcen gebunden.
+\item Das Netz wird au"serordentlich instabil, sollte sich der
+Pa"swortserver entscheiden, diese vielen nicht besonders aktiven
+Verbindungen abzubrechen. Clients werden sich am Sambaserver
+erneut anmelden m"ussen.
 \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.
+Das Dom"anencontrollerprotokoll l"ost diese beiden Probleme, indem es
+dem Sambaserver erlaubt, sich eine eigene Herausforderung pro Client
+auszudenken und diese bei der Netzwerkanmeldung beim PDC
+mitzuschicken.  Um kein Sicherheitsproblem aufkommen zu lassen, mu"s
+diese Netzwerkanmeldung vom Sambserver zum PDC verschl"usselt sein,
+daher das Computerkonto, dessen Pa"swort als Schl"ussel f"ur die
+symmetrische Verschl"usselung zwischen Sambaserver und PDC verwendet
+wird.
+
+\section{winbind}
+
+Wenn man Samba als Dom"anenmitglied betreibt, hat man die gr"o"ste
+H"urde zu einer problemlosen Integration bereits genommen: Die
+Pa"swortverwaltung. Jeder Benutzer kann sein Pa"swort in der Dom"ane
+"andern, und die "Anderung wird sofort auf allen Dom"anenmitgliedern
+sichtbar. Ein Problem bleibt jedoch bestehen. Man mu"s auf den
+Sambaservern, die Dom"anenmiglieder sind, die Benutzer
+nachpflegen. Wird ein neuer Benutzer in der Dom"ane angelegt, oder
+werden Gruppenmitgliedschaften ge"andert, mu"s dies manuell auf den
+Sambaservern eingetragen werden. Ist auch der Primary Domain Cotroller
+ein Sambaserver, kann man sich mit dem Network Information System NIS
+behelfen, aber wenn die Benutzerdatenbank auf einem echten NT-Server
+liegt, ist dieser Weg verschlossen.
+
+Eine wirklich zwischen Windows NT und Unix vereinheitlichte
+Benutzerdatenbank bietet seit Samba 2.2.2 der D"amon
+\defin{winbind}. Er erm"oglicht die volle Einbindung eines Unixsystems
+in eine NT-Dom"ane. Voraussetzung daf"ur ist die Unterst"utzung der
+\prog{nsswitch}-Module. Momentan bieten dies Linux und Solaris. Die
+anderen von Samba unterst"utzten Unixsysteme bleiben au"sen vor.
+
+\subsection{nsswitch-Module}
+
+Viele Programme unter Unix m"ussen auf Datenbanken im Verzeichnis
+\dateistyle{/etc} zugreifen. Beispielsweise mu"s \prog{ls -l} den
+Dateibesitzer, der in der Datei nur in numerischer Form vorliegt, in
+einen Benutzernamen "ubersetzen. Dazu mu"s die numerische User-ID in
+der Datei \dateistyle{/etc/passwd} gesucht werden. Da"s diese
+"Ubersetzung tats"achlich stattfindet, kann man leicht folgenderma"sen
+"uberpr"ufen. Man mu"s nur testweise die Leserechte f"ur
+\username{others} von der Datei \dateistyle{/etc/passwd} mit
+\prog{chmod o-r /etc/paswd} wegnehmen und \prog{ls -l} aufrufen. Die
+Dateibesitzer werden nur noch numerisch angezeigt\footnote{Sollte dies
+nicht spontan funktionieren, kann der \prog{nscd} schuld sein. Siehe
+hierzu Seite \pageref{nscd}.}
+
+Sauber geschriebene Programme greifen nicht direkt auf die Dateien in
+\dateistyle{/etc} zu, sondern durch Bibliotheksaufrufe wie beispielsweise
+\prog{getpwuid(2)}. Seit der glibc-Version 2 werden diese Bibliotheksaufrufe
+in dynamisch geladenen Modulen implementiert. Gesteuert werden diese Module
+"uber die Datei \dateistyle{/etc/nsswitch.conf}. F"ur jede der Dateien in
+\dateistyle{/etc}, die von allgemeinem Interesse ist, gibt es eine
+Zeile in der \dateistyle{/etc/nsswitch.conf}. Beispielsweise wird der
+Zugriff auf die Datei \dateistyle{/etc/passwd} "uber die Zeile
 
-\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
+\begin{verbatim}
+passwd: compat
+\end{verbatim}
 
-\verb|smbpasswd -j DOM -r PDC|
+\noindent oder
 
-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}
+\begin{verbatim}
+passwd: files nis
+\end{verbatim}
 
-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.
+\noindent gesteuert. Durch die erste Version wird ein
+Kompatibilit"atsmodul zum Zugriff herangezogen, die zweite Variante
+legt explizit fest, da"s zuerst in der lokalen Datei
+\prog{/etc/passwd} nach Benutzern gesucht werden soll. Schl"agt dies
+fehl, wird das NIS befragt.
+
+Wie funktioniert diese Steuerung? Die Option \param{compat} bewirkt,
+da"s zur Laufzeit eines Programms die dynamische Bibliothek
+\dateistyle{/lib/libnss\_{\bfseries compat}.so.2} geladen wird und die
+Anfrage beantworten mu"s. \param{files} und \param{nis} beziehen sich
+entsprechend auf die Dateien \dateistyle{/lib/libnss\_{\bfseries
+    files}.so.2} und \dateistyle{/lib/libnss\_{\bfseries nis}.so.2}.
+
+\prog{winbind} besteht aus zwei Teilen: Einer Datei
+\dateistyle{libnss\_winbind.so} und einem D"amon \prog{winbind}. In
+den Samba-Quellen findet sich der winbind unter
+\dateistyle{source/nsswitch}. Dort wird auch die Datei
+\dateistyle{libnss\_winbind.so} abgelegt. Zur Installation mu"s sie
+manuell nach \dateistyle{/lib} kopiert werden:
 
-\end{document}
+\begin{verbatim}
+cp source/nsswitch/libnss_winbind.so /lib/libnss_winbind.so.2
+\end{verbatim}
+
+Der \prog{winbindd} selbst wird automatisch mit im
+\dateistyle{sbin}-Unterverzeichnis von Samba installiert.
+
+\subsection{Konfiguration von Winbind}
+
+Um Winbind zu aktivieren, m"ussen in der Datei
+\dateistyle{/etc/nsswitch.conf} die beiden Zeilen f"ur \param{passwd}
+und \param{group} durch die Angabe \param{winbind} erg"anzt werden,
+etwa so:
+
+\begin{verbatim}
+# /etc/nsswitch.conf
+passwd: files winbind
+group: files winbind
+\end{verbatim}
+
+Damit werden Benutzer und Gruppen zuerst in den lokalen Dateien
+gesucht. Danach wird der \prog{winbindd} befragt, der im Hintergrund
+laufen mu"s.
+
+F"ur die Konfiguration des \prog{winbindd} mu"s Samba ein normales
+Dom"anenmitglied sein. Siehe hierzu Kapitel \ref{domain-member}. Der
+\prog{winbindd} ben"otigt in der \dateistyle{/etc/smb.conf} einige
+zus"atzliche Parameter. Eine vollst"andige Beispielkonfiguration ist
+die folgende:
+
+\begin{verbatim}
+; Samba als Domaenenmitglied
+workgroup = windows
+security = domain
+password server = *
+encrypt passwords = yes
+
+; Winbind-Konfiguration
+winbind separator = +
+winbind uid = 10000-20000
+winbind gid = 10000-20000
+template shell = /bin/bash
+template homedir = /home/%D/%u
+\end{verbatim}
+
+Die Parameter bedeuten im einzelnen:
+
+\begin{description} 
+  
+\item[winbind separator:] Unter Windows wird ein vollst"andiger
+  Benutzername mit Dom"ane in der Form
+  \username{DOMAENE\textbackslash{}benutzername} angegeben. Unter Unix
+  hat dies Nachteile, da der Backslash \textbackslash{} f"ur die Shell
+  eine Sonderbedeutung hat. Daher kann man den Trenner zwischen
+  Dom"ane und Benutzername separat konfigurieren. Als unkritisch
+  erweist sich das +-Zeichen. Ein Benutzer wird somit als
+  \username{DOMAENE+benutzername} angegeben.
+  
+\item[winbind uid:] Der \prog{winbindd} mu"s dynamisch f"ur
+  Dom"anenbenutzer numerische User-IDs vergeben. Um dies tun zu
+  k"onnen, wird ihm mit dem Parameter \param{winbind uid} eine Menge
+  von User-IDs "ubergeben, die nicht in der \dateistyle{/etc/passwd}
+  oder im NIS verwendet werden. Wird auf einen Benutzernamen das erste
+  Mal zugegriffen, w"ahlt der \prog{winbindd} f"ur diesen Benutzer aus
+  seinem Pool die n"achste freie User-ID aus und speichert diese
+  Zuordnung fest in der Datei \dateistyle{winbindd\_idmap.tdb}.
+  
+\item[winbind gid:] F"ur Group-IDs gilt das gleiche wie f"ur User-IDs.
+  
+\item[template shell:] Der Primary Domain Controller kennt das Konzept
+  der Login-Shell nicht. Diese mu"s zentral f"ur alle Winbind-Benutzer
+  in der \dateistyle{smb.conf} vergeben werden.
+  
+\item[template homedir:] Auch ein Heimatverzeichnis wird in der SAM
+  von Windows nicht abgespeichert und mu"s in der
+  \dateistyle{smb.conf} vorgegeben werden. Hierbei sollte man auf
+  jeden Fall die Dom"ane des Benutzers in den Pfad mit aufnehmen, um
+  Namenskollisionen bei Vertrauensstellungen zu behandeln. Der
+  Benutzer \username{schmidt} in der Dom"ane \username{GOE} sollte ein
+  anderes Heimatverzeichnis bekommen als der Benutzer
+  \username{schmidt} in der Dom"ane \username{HD}. Die
+  Heimatverzeichnisse werden selbstverst"andlich nicht automatisch
+  erzeugt, sondern m"ussen manuell angelegt und den Benutzern
+  "ubergeben werden. Auf einem reinen Fileserver mit gemeinsamen
+  Dateien ist es jedoch m"oglicherweise nicht notwendig, f"ur jeden
+  Benutzer eigene Heimatverzeichnisse anzulegen.
+\end{description}
+
+Mit diesen Einstellungen kann man den \prog{winbindd} zus"atzlich zu
+\prog{smbd} und \prog{nmbd} starten, die ebenfalls laufen m"ussen.
+
+\subsection{Winbindd abfragen: wbinfo}
+
+Laufen \prog{winbindd}, \prog{smbd} und \prog{nmbd} in der Dom"ane,
+kann man das ganze testen. Das Utility zum Testen hei"st
+\prog{wbinfo}. Der wichtigste Test ist der Aufruf \prog{wbinfo -t}.
+Damit wird die Verbindung zum Dom"anencontroller gepr"uft,
+\prog{winbindd} sucht den PDC und meldet sich mit dem Workstationkonto
+an. Das Programm \prog{wbinfo} mu"s die Ausgabe \texttt{Secret is
+  good} geben. Gibt \prog{wbinfo} diese Ausgabe, so ist der
+\prog{winbindd} g"ultiges Dom"anenmitglied und kann Informationen vom
+PDC abrufen.
+
+\prog{wbinfo} kennt noch eine Reihe weiterer Parameter, mit denen die
+Benutzerdatenbank der Dom"ane abgefragt werden kann. Die Ausgabe des
+Aufrufts \prog{wbinfo} ohne Parameter gibt einen Hilfetext mit den
+verf"ugbaren Optionen aus.
+
+Schl"agt \prog{wbinfo -t} fehl, so mu"s die Dom"anenmitgliedschaft
+"uberpr"uft werden. Hierzu siehe Kapitel \ref{domain-member}.
+
+Verl"auft der Test mit \prog{wbinfo -t} erfolgreich, so kann man sich
+s"amtliche verf"ugbaren Benutzer mit \prog{getent passwd} und die
+Gruppen mit \prog{getent group} auflisten lassen.
+
+\todo{valid users = @DOMAIN+group}
+
+\todo{pam\_winbind}
+
+\subsection{nscd}
+\label{nscd}
+
+Unter Linux ist der Name Service Caching Daemon \prog{nscd} ist ein
+Programm, mit dem s"amtliche Abfragen durch den nsswitch-Mechanismus
+gecached werden k"onnen. Der \prog{nscd} macht Sinn, wenn diese
+Anfragen sehr lange dauern. Dies kann der Fall sein, wenn die Dateien
+sehr gro"s sind, etwa wenn hunderte von Usern im System angelegt sind.
+Ein anderer Verz"ogerungsgrund ist die Abfrage von Benutzerdaten "uber
+ein Netzwerk beim Einsatz von NIS.
+
+Ein Nachteil des \prog{nscd} kann sein, da"s er "Anderungen in der
+Benutzerdatenbank nicht schnell genug mitbekommt. Insbesondere beim
+Testen des \prog{winbind} kann dies sehr hinderlich sein. Wer
+beispielsweise folgendes schon einmal erlebt hat, hat ein Problem mit
+dem \prog{nscd}:
+
+\begin{verbatim}
+delphin:~ # useradd -m vl
+delphin:~ # passwd vl
+passwd: Unknown user vl
+delphin:~ #
+\end{verbatim}
 
+In diesem Falle sollte man den \prog{nscd} schleunigst killen und
+daf"ur sorgen, da"s er beim n"achsten booten nicht wiederkommt.
+
+
+\section{smbcontrol}
+
+Bis zur Version 2.0 hatte man relativ wenig M"oglichkeiten, in das
+laufende Samba einzugreifen. Man konnte mit dem Signal \texttt{USR1}
+den Debuglevel um einen Punkt erh"ohen und mit \texttt{USR2} um einen
+Punkt erniedrigen. Dar"uber hinaus blieb h"aufig nur die M"oglichkeit,
+einzelne Sambaprozesse oder sogar das ganze Samba herunterzufahren,
+wenn man Konfigurations"anderungen vorgenommen hatte. Mit Samba 2.2
+gibt es f"ur diese Anwendungen ein neues Werkzeug: \prog{smbcontrol}.
+\prog{smbcontrol} bietet die M"oglichkeit, einzelne Dinge anzusto"sen.
+\prog{smbcontrol} verschickt hierzu Nachrichten an einzelne
+Sambaprozesse, oder an alle \prog{smbd}s.
+
+Man kann jetzt im Gegensatz zu Samba 2.0 den Debuglevel einzelner
+Prozesse direkt setzen. Dies geschieht wie in folgendem Beispiel:
+
+\begin{verbatim}
+root@server:~ > smbcontrol smbd debuglevel
+Current debug level of PID 4423 is 0 
+Current debug level of PID 17392 is 0 
+Current debug level of PID 22272 is 0 
+root@server:~ > smbcontrol 17392 debug 1  
+root@server:~ > smbcontrol smbd debuglevel
+Current debug level of PID 4423 is 0 
+Current debug level of PID 17392 is 1 
+Current debug level of PID 22272 is 0 
+\end{verbatim}
+
+An diesem Beispiel ist deutlich, wie \prog{smbcontrol} zu benutzen
+ist. Als ersten Parameter verlangt \prog{smbcontrol} das Ziel der
+Nachricht, die es verschicken soll. Zweiter Parameter ist die
+Nachricht, die verschickt werden soll. Daran schlie"sen sich dann
+weitere Parameter an, die m"oglicherweise zu der Nachricht geh"oren.
+
+Die Nachrichten im Einzelnen:
+
+\begin{description}
+\item[debug:] Mit dieser Nachricht wird der Debuglevel anhand des
+  weiteren Parameters gesetzt.
+\item[debuglevel:] \prog{smbcontrol} liest hiermit den aktuellen
+  Debuglevel von Prozessen aus.
+\item[force-election:] Mit dieser Nachricht wird eine Wahl zum Local
+  Master Browser erzwungen. Diese Nachricht kann nur an den
+  \prog{nmbd} geschickt werden. Der \prog{smbd} hat mit der Wahl
+  nichts zu tun.
+\item[ping:] Mit dieser Nachricht k"onnen Prozesse einfach zum
+  Antworten bewegt werden. {\bfseries ping} erwartet einen Parameter,
+  der die Anzahl der Pings zum Ziel festlegt.
+\item[profile:] Diese Nachricht ist f"ur Entwickler gedacht. Um das
+  Profiling zu nutzen, mu"s Samba mit der \prog{configure}-Option
+  \texttt{-{}-with-profiling-data} compiliert werden. Dann kann mit
+  dieser Nachricht der interne Profiling-Code gesteuert werden.  Damit
+  k"onnen Entwickler die Teile des Codes bestimmen, in denen am
+  meisten Zeit verbraucht wird.
+\item[profilelevel:] Diese Nachricht ist ebenfalls f"ur Entwickler
+  gedacht.
+\item[close-share:] Der \prog{smbd} kann mit dieser Nachricht dazu
+  bewegt werden, alle Verbindungen zu einer bestimmten Freigabe zu
+  beenden, ohne die restlichen Verbindungen zu st"oren. Dies kann
+  insbesondere dann sinnvoll sein, wenn "Anderungen an den
+  Zugriffsrechten einer Freigabe vorgenommen wurden.
+\item[printer-notify:] Wenn Sie von Windows NT Clients aus mit
+  Druckern verbunden sind, nutzen Sie m"oglicherweise das neue
+  Drucksystem von Samba. In diesem Fall sind Druckereinstellungen auf
+  dem Server gespeichert. "Andern sich diese Einstellungen, k"onnen
+  Sie mit dieser Nachricht die momentan verbundenen Clients "uber
+  diese "Anderungen informieren.
+\end{description}
+
+\end{document}