path: root/docs/textdocs/kurs.tex

\documentclass{scrartcl}
\usepackage{pslatex}
\usepackage[dvips,colorlinks=true,
            pdfauthor={Volker Lendecke, Service Network GmbH},
            pdftitle={Kursskript Samba},
            pdfsubject={Samba},
            pdfkeywords={samba,training}
            ]{hyperref}
\usepackage[T1]{fontenc}
\usepackage{german}
\usepackage{pstricks}
\usepackage[dvips]{epsfig}
\newcommand{\prog}{\texttt}
\newcommand{\param}{\texttt}
\newcommand{\datei}{\texttt}
\newcommand{\nbname}{\texttt}
\newcommand{\todo}{\texttt}
\newcommand{\defin}{\emph}
\hyphenation{Net-BIOS}

\usepackage{fancyheadings}
\pagestyle{fancyplain}
\lhead{}
\rhead{\thepage}
\rfoot{\copyright{} 1999, 2000, Volker Lendecke (http://www.sernet.de/vl/)}
\cfoot{}

\begin{document}

\title{Kursskript\\[\baselineskip]
  \epsfig{file=logo.ps,width=6cm}}

\author{Volker Lendecke\\
Samba Team\\
Service Network GmbH\\
G"ottingen\\
http://samba.SerNet.DE/}

\date{\today}

\maketitle
\thispagestyle{empty}

\begin{quote}
  Dieses Dokument ist eine Mitschrift des Sambakurses der Service
  Network GmbH in G"ottingen. Es gibt einen guten "Uberblick "uber den
  Kurs und kann gleichzeitig als generelle Einf"uhrung in NetBIOS und
  Samba dienen.
\end{quote}

\break

\tableofcontents

\break

\section{Einf"uhrung}

Samba -- Was ist das?

Kurz gesagt l"a"st Samba jeden Unixrechner in der Netzwerkumgebung von
Windows NT erscheinen. Au"serdem lassen sich mit Samba Datei- und
Druckfreigaben erstellen. Das hei"st, unter Unix vorhandener
Plattenplatz kann ganz normal unter Windows genutzt werden, und unter
Unix vorhandene Drucker kann man als Netzwerkdrucker unter Windows
ansteuern. Dar"uber hinaus bietet Samba viele Dienste, die sonst nur
von Windows NT geleistet werden. Dazu geh"oren:

\begin{description}
  
\item[WINS Server] Mit Samba kann sehr einfach ein WINS Server
  eingerichtet werden.
  
\item[Computersuchdienst] Samba als sehr stabiler Server kann alle
  Aufgaben des Computersuchdienstes "ubernehmen. Die in Windowsumgebungen
  oft nicht sehr vorhersagbare Netzwerkumgebung kann so etwas 
  stabiler gemacht werden.
  
\item[Logon Server] F"ur Windows 95/98 ist Samba Logon-Server, kann
  also die Dom"anenanmeldung f"ur diese Systeme "ubernehmen.
  
\item[PDC] Die Funktionalit"at des Primary Domain Controller ist in
  einer noch nicht freigegebenen Version implementiert, ist jedoch
  schon in vielen Installationen im produktiven Einsatz.
  
\item[Diagnosewerkzeuge] Samba bietet eine Reihe von kleinen, aber
sehr effektiven Werkzeugen, die die oft m"uhselige Suche nach Fehlern
im Netz vereinfachen k"onnen.

\end{description}

Samba bietet gegen"uber den bekannten Implementationen des
SMB-Protokolls einige Vorteile. Teilweise sind diese Vorteile von Unix
geerbt, teilweise sind sie in der Architektur von Samba begr"undet.

\begin{description}
  
\item[Entfernte Administration] Der gr"o"ste Vorteil von Samba in
  gr"o"seren Umgebungen ist die M"oglichkeit, die gesamte
  Administration von der Kommandozeile aus durchzuf"uhren. Damit
  bekommt man gegen"uber grafischen Oberfl"achen sehr viel bessere
  M"oglichkeiten, von entfernten Standorten aus zu administrieren.
  Werkzeuge wie PC Anywhere sind hier deutlich weniger flexibel.
  
  Zus"atzlich bietet Samba die M"oglichkeit der grafischen
  Administration "uber einen Webbrowser. Auch hier ist es unerheblich,
  wo sich Administrator und Server befinden.
  
\item[Zentrale Konfiguration] Die gesamte Konfiguration von Samba
  befindet sich in einer einzigen Datei und ist nicht "uber viele
  Dialogfelder verteilt. Das erleichtert die Administration erheblich.
  So l"a"st sich eine funktionierende Konfiguration sehr einfach
  sichern und wieder einspielen.
  
\item[Stabilit"at] Samba erbt von Unix eine hohe Stabilit"at.
  Unixrechner sind daf"ur ausgelegt, "uber Monate hinweg durchzulaufen
  und leisten dies auch. Samba als weiterer Proze"s profitiert von
  dieser hohen Verf"ugbarkeit. Die modulare Struktur von Unix l"a"st
  es dar"uber hinaus zu, da"s der Serverdienst Samba unabh"angig von
  allen anderen Systemprozessen eigenst"andig neu gestartet werden
  kann, sofern hier ein Problem vorliegen sollte.
  
  Samba hat eine Architektur, die die Stabilit"at weiter f"ordert.
  F"ur jede Clientverbindung wird ein eigener Proze"s gestartet.
  Verursacht also ein Client ein Problem auf Serverseite, dann wird
  nur dieser Client in Mitleidenschaft gezogen.  Eventuell
  st"urzt dieser eine Proze"s ab, die anderen werden jedoch 
  nicht gest"ort.
  
\item[Skalierbarkeit] Samba kann von dem vielzitierten kleinen 386er
  unter Linux bis hin zu den gr"o"sten heute verf"ugbaren Maschinen
  jede Hardware optimal ausnutzen. Die Architektur von Samba
  erm"oglicht es, da"s auch Multiprozessormaschinen optimal
  ausgelastet werden. Multiprozessormaschinen k"onnen alle Prozessoren dann
  besch"aftigen, wenn es viele unabh"angige Prozesse im System gibt.
  Samba erstellt f"ur jeden Client einen Proze"s, der auf einem
  eigenen Prozessor ablaufen kann.
  
\item[Flexibilit"at] Samba bietet eine riesige Anzahl von
  Konfigurationsoptionen, die zun"achst einmal "uberw"altigend wirkt.
  Im Laufe des Kurses wird sich herausstellen, da"s f"ur das
  Funktionieren von Samba nur sehr wenige Optionen wirklich notwendig
  sind. Die meisten Optionen werden nur f"ur Spezialf"alle ben"otigt.
  Durch ein sehr flexibles Schema von Makroersetzungen ist mit Samba
  sehr viel mehr m"oglich als mit NT. Als Beispiel sei genannt, da"s
  man sehr einfach einen Sambaserver unter zwei verschiedenen Namen in
  der Netzwerkumgebung erscheinen lassen kann, und beide virtuelle
  Server unterschiedlich konfigurieren kann. Zu Testzwecken ist es 
  sogar m"oglich,
  zwei unterschiedliche Versionen gleichzeitig auf einer Maschine
  laufen zu lassen.

\end{description}

\section{NetBIOS}

Sobald Windowsrechner Dateisysteme austauschen, sich gegenseitig in
der Netzwerkumgebung sehen oder Drucker freigeben, funktioniert die
Kommunikation "uber NetBIOS\footnote{Dies ist in reinen Windows 2000
  Umgebungen nicht mehr richtig. Microsoft hat die NetBIOS-Ebene
  abgeschafft, Windows 2000 kommuniziert direkt "uber TCP. Aus
  Kompatibilit"atsgr"unden kann Windows 2000 jedoch noch "uber NetBIOS
  kommunizieren.}. NetBIOS ist eine reine
Softwareschnittstelle zur Kommunikation von Rechnern. Mit dieser
Schnittstelle werden Programmen unterschiedliche Dienste zur
Kommunikation zur Verf"ugung gestellt. NetBIOS wurde entworfen, um in
kleinen, lokalen Netzen Kommunikation zu erm"oglichen. Dabei lag der
Schwerpunkt des Entwurfs auf der Einfachheit der Anwendung. Auf
Skalierbarkeit und die Andwendung in Weitverkehrsnetzen wurde beim
Design nicht geachtet.

Die Kommunikation mit NetBIOS wurde in drei Teilbereiche aufgeteilt,
den Namensdienst, den Datagramm- und den Sitzungsdienst.

\begin{description}
  
\item[Namensdienst:] Im Rahmen des Namensdienstes sind die Rechner in
  der Lage, sich gegenseitig im Netz zu identifizieren. Es sei an
  dieser Stelle betont, da"s der NetBIOS-Namensdienst nichts mit der
  Anzeige in der Netzwerkumgebung zu tun hat. Der Computersuchdienst,
  der f"ur die Netzwerkumgebung zust"andig ist, h"angt jedoch sehr
  stark von einem korrekt funktionierenden Namensdienst ab.

\item[Datagrammdienst:] Betrachtet man die Rechnerkommunikation auf
  dem Netz, so sieht man, da"s die versendeten Daten in einzelne
  Pakete aufgeteilt werden.
  Diese einzelnen Pakete werden dann vom Netz nach bestem Bem"uhen an
  einen Zielrechner ausgeliefert. Geht ein Paket verloren, kann man
  nichts machen, man bekommt unter Umst"anden nicht einmal eine
  Benachrichtigung dar"uber, da"s etwas nicht stimmt. Aufeinander
  folgende Pakete k"onnen in vertauschter Reihenfolge beim Empf"anger
  ankommen. Es kann sogar sein, da"s Pakete auf dem Weg dupliziert
  werden, also mehrfach ankommen. Diese Unzuverl"assigkeit des Netzes
  wird durch den Datagrammdienst an die Benutzerprogramme
  weitergegeben. Der Datagrammdienst hat jedoch nicht nur Nachteile.
  Zwei Vorteile sind der geringe Aufwand, mit dem Pakete verschickt
  werden k"onnen, und die M"oglichkeit, ein Datagramm an mehrere
  Rechner gleichzeitig zu verschicken. Die Applikation mu"s selbst
  entscheiden, wie sie mit der Unzuverl"assigkeit des Dienstes
  klarkommt.
  
\item[Sitzungsdienst:] Die Unzuverl"assigkeit des Netzes ist f"ur
bestimmte Applikationen wie Dateitransfer oder Terminalanwendungen
nicht akzeptabel. Wenn man eine Datei "ubertr"agt, m"ochte man sicher
sein, da"s die Datei komplett und korrekt "ubertragen wurde.  F"ur
diese h"oheren Anforderungen wurde der Sitzungsdienst entworfen. Zwei
Rechner vereinbaren eine NetBIOS-Sitzung. Die Daten, die "uber diese
Verbindung "ubertragen werden, kommen auf jeden Fall an, und zwar in
der richtigen Reihenfolge. K"onnen Daten einmal nicht "ubertragen
werden, so erh"alt die versendende Applikation eine Fehlermeldung. Die
Applikation kann nun versuchen, die abgebrochene Sitzung neu
aufzubauen. Dieser Zuverl"assigkeit steht ein erh"ohter Aufwand beim
Sitzungsauf- und -abbau gegen"uber.

\end{description}

Zwei Rechner, die kommunizieren wollen, m"ussen sich zun"achst gegenseitig
identifizieren. NetBIOS sieht hierf"ur bis zu 16 Zeichen lange Namen
vor.  Jede Applikation kann f"ur sich beliebig viele Namen reservieren
und unter einem dieser Namen Verbindungen aufbauen und Daten austauschen.
Diese Reservierung von Namen gilt sowohl f"ur Server, die vom Netz aus
erreichbar sein m"ussen, als auch f"ur Clients, die Server im Netz
erreichen wollen, da Server wissen m"ussen, wohin die Antworten
gehen m"ussen.

Zwei Anwendungen wollen nun per NetBIOS miteinander kommunizieren.
Dazu mu"s zun"achst der Server seine Bereitschaft kundtun,
Verbindungen entgegenzunehmen. Dazu meldet er sich im Netz mit seinem
Namen an. Diese Anmeldung geschieht per Broadcast, so da"s alle im
Netz mith"oren k"onnen. Jeder Rechner ist frei, beliebige Namen im
Netz f"ur sich zu beanspruchen, sofern diese noch nicht belegt
sind\footnote{Mit dieser Freiheit ergeben sich viele M"oglicheiten,
  von einem beliebigen Rechner aus ein Windows-Netz bis zur
  Unbenutzbarkeit zu st"oren. Man mu"s nur bestimmte, f"ur den PDC
  vorgesehene Namen zum richtigen Zeitpunkt reservieren.}. Eine
Reservierung geschieht also, indem ein Rechner per Broadcast
ank"undigt, da"s er unter einem bestimmten Namen erreichbar ist. Dann
wartet er auf Protest. Beklagt sich niemand, schickt er eine zweite
Reservierung und wartet wieder. Nach der dritten Reservierung ist der
Rechner ausreichend sicher, da"s kein anderer den Namen bereits f"ur
sich eingenommen hat, und sieht ihn als f"ur sich reserviert an.

Wenn nun ein Client mit einem Server reden m"ochte, dann mu"s er sich
wie der Server einen eindeutigen Namen ausdenken und im Netz
reservieren. Das Verfahren dazu ist identisch. Zus"atzlich mu"s der
Client jedoch die MAC-Adresse des Servers herausbekommen. Die
Mechanismen, wie dies geschieht, h"angen davon ab, wie NetBIOS
implementiert ist.

NetBIOS kann mit unterschiedlichen Protokollen implementiert werden.
NetBEUI, IPX und TCP/IP sind drei heute verwendete Protokolle, wobei
f"ur Neuinstallation TCP/IP das bevorzugte Protokoll sein sollte.
Der Ablauf der Namensaufl"osung soll an einem
Beispiel verdeutlicht werden.

Auf einem Client soll eine Verbindung zu dem Server \nbname{samba}
aufgebaut werden. Direkt erreicht man dies, indem man in der Taskleiste
Start $\rightarrow$ Ausf"uhren $\rightarrow$ \verb|\\samba| eingibt.
Im folgenden werden die unterschiedlichen Verfahren betrachtet, mit
denen ein Rechner die MAC-Adresse des Servers herausbekommt.

\begin{description}

\item[NetBEUI:]

  \textbf{"`Samba"'$\,\Rightarrow\,$MAC-Adresse}
  
  Bei diesem Protokoll findet der Client den Server ausschlie"slich
  "uber Broadcasts. Er verschickt per Broadcast eine Anfrage, wer sich
  f"ur den gesuchten Namen verantwortlich f"uhlt. Der Rechner, der
  diesen Namen tats"achlich als Server reserviert hat, wird aufgrund
  dieser Anfrage seine eigene MAC-Adresse aus dem ROM seiner
  Netzwerkkarte auslesen und entsprechend antworten. Daraufhin kann
  der Client dann die Verbindung aufbauen. "Uber NetBEUI k"onnen also
  nur Rechner miteinander reden, die in der gleichen Broadcastdom"ane
  liegen. Sobald Router zum Einsatz kommen sollen, kann reines NetBEUI
  nicht mehr verwendet werden, da dann der Server, der kontaktiert
  werden soll, von der Namensanfrage nichts mehr mitbekommt, also auch
  nicht antworten kann.
  
\item[IPX]
  
  \textbf{"`Samba"'$\,\Rightarrow\,$IPX-Knotenadresse
    $\,\Rightarrow\,$MAC-Adresse}
  
  Bei IPX liegt zwischen Servernamen und der MAC-Adresse die
  IPX-Knotenadresse. Diese enth"alt eine 4 Byte lange Netzwerknummer
  und die 6 Byte lange MAC-Adresse des Rechners. Die Knotenadresse
  wird anhand des NetBIOS-Namens wie bei NetBEUI per Broadcast im
  lokalen Netz gesucht. Damit w"aren Rechner hinter Routern nicht
  erreichbar, da die Namensanfrage nicht zu ihnen durchdringt.
  IPX-Router erkennen diese Namensanfragen und leiten sie per
  Broadcast in s"amtliche angeschlossenen Netze weiter, so da"s die
  Anfrage jedes Teilnetz erreicht.
  
  Jede Anfrage l"ost einen Broadcast in jedem angeschlossenen Subnetz
  aus. Einige IPX-Router speichern eine Namenstabelle und k"onnen so
  viele Anfragen selbst beantworten, so da"s die Broadcastlast
  reduziert wird.

\item[TCP/IP]
  
  \textbf{"`Samba"'$\,\Rightarrow\,$IP-Adresse$\,\Rightarrow\,
    $MAC-Adresse}

  Bei TCP/IP mu"s der Client die IP-Adresse des Servers herausfinden.
  Dies geschieht wie bei den anderen Protokollen per Broadcast im
  lokalen Netz. IP-Router k"onnen nicht angewiesen werden, die
  Anfragen per Broadcast in alle angeschlossenen Netze weiterzuleiten.
  Aus diesem Grund gibt es hier andere Mechanismen, die im folgenden
  beschrieben werden.
  
  Nachdem die IP-Adresse herausgefunden wurde, kommen die bekannten
  Mechanismen von IP zum tragen. Befindet sich der Rechner im eigenen
  Subnetz, wird direkt eine ARP-Anfrage nach der MAC-Adresse
  ausgel"ost. Andernfalls wird der entsprechende Router anhand der
  Routingtabelle herausgefunden und dann dessen MAC-Adresse per ARP
  festgestellt.

\end{description}

Die Protokolle ordnen sich folgenderma"sen ein:

\begin{figure}[ht]
\[\begin{pspicture}(12,6)
\psframe(3,0)(9,1)
\rput(6,0.5){Hardware}
\psframe(3,1)(5,3)
\rput(4,2){TCP/IP}
\psframe(5,1)(7,3)
\rput(6,2){NetBEUI}
\psframe(7,1)(9,2)
\rput(8,1.5){IPX}
\psframe(7,2)(9,3)
\rput(8,2.5){NWLink}
\psframe(3,3)(9,4)
\rput(6,3.5){{\bfseries NetBIOS}}
\psframe(0,4)(2,5)
\rput(1,4.5){ping}
\psline(0,4)(3,3)
\psline(2,4)(5,3)
\psframe(10,3)(12,4)
\rput(11,3.5){NWClient}
\psline(7,2)(10,3)
\psline(9,2)(12,3)
\psframe(3,4)(6,5)
\rput(4.5,4.5){SMB}
\psframe(3,5)(6,6)
\rput(4.5,5.5){Datei, Druck}
\psframe(6,4)(9,6)
\rput(7.5,5.5){Andere}
\rput(7.5,5){NetBIOS-}
\rput(7.5,4.5){Anwendungen}
\end{pspicture}\]
\caption{Protokollstapel}
\label{protokollstapel}
\end{figure}

In dieser Grafik steht das Programm \prog{ping} f"ur beliebige
Programme, die direkt auf TCP/IP aufsetzen. Dies gilt beispielsweise
f"ur alle WWW-Browser und f"ur die Programme \prog{telnet} und
\prog{ftp}.

Man kann festhalten, da"s NetBEUI hier das einzige Protokoll ist, das
nicht "uber Routergrenzen hinweg verwendbar ist. Sowohl IPX als auch
IP sind f"ur den Einsatz in Weitverkehrsnetzen entworfen worden und
k"onnen folglich mit Routern umgehen.

Samba ist ausschlie"slich in der Lage, NetBIOS "uber TCP/IP zu
benutzen. Daher werden die anderen Protokolle ab hier ignoriert.

\section{Bestandteile von Samba}

Das Programmpaket Samba besteht aus mehreren Programmen, von denen
einige der Serverseite und andere der Clientseite zugeordnet werden
k"onnen.

Die Servertools:

\begin{description}
  
\item[smbd] ist der zentrale Serverproze"s, der f"ur die eigentlichen
  Datei- und Druckdienste zust"andig ist. Sie werden mehrere
  \prog{smbd}s im System finden. Einer dieser Prozesse lauscht auf dem
  TCP-Port 139, und nimmt neue Verbindungen entgegen. Jede neue
  Verbindung st"o"st einen neuen Proze"s \prog{smbd} an. Wenn Sie
  einen Client vom Sambaserver trennen wollen, m"ussen Sie nur mit
  \prog{smbstatus} die Proze"snummer des zust"andigen \prog{smbd}
  erfragen, und diesen einen Proze"s t"oten.
  
  Samba ist im Hauptspeicherverbrauch recht sparsam. Jeder
  \emph{aktive} Client ben"otigt etwa 1 MB Hauptspeicher auf dem
  Server. Clients, die gerade nicht aktiv Dateien mit dem Sambaserver
  austauschen, ben"otigen praktisch "uberhaupt keine Resourcen. Viel
  Hauptspeicher kann von Samba selbstverst"andlich gut als Cache
  genutzt werden.
  
\item[nmbd] ist f"ur die NetBIOS Namens- und Datagrammdienste
  zust"andig. Dieser Proze"s reserviert beim Start von Samba die
  entsprechenden NetBIOS-Namen, er ist WINS-Server und f"ur den
  Computersuchdienst zust"andig.
  
\item[testparm] Mit diesem Programm kann man die \datei{smb.conf} auf
  syntaktische Korrektheit pr"ufen. Das Programm liest die
  Konfigurationsdatei ein und gibt Fehlermeldungen aus, sofern es
  unbekannte Parameter findet.
  
\item[smbpasswd] wird zur Pflege der verschl"usselten Pa"sw"orter auf
  Serverseite verwendet. Wie dies funktioniert, wird im Kapitel
  \ref{passwoerter} erkl"art.

\end{description}

Die Clients:

\begin{description}
  
\item[smbclient:] Mit dem Programm \prog{smbclient} kann man auf
  Freigaben von NT-Rechnern zugreifen. Man kann auf von NT zur
  Verf"ugung gestellten Druckern drucken und man kann NT-Freigaben in
  tar-Dateien sichern.  Weiterhin wird mit \prog{smbclient} die Liste
  der Server im Netz erfragt, analog zu der Netzwerkumgebung unter
  Windows.
  
\item[nmblookup] ist ein Diagnosewerkzeug f"ur die
  NetBIOS-Namensaufl"osung. Wenn zwei Computer mit Windows sich
  nicht finden k"onnen, kann man mit \prog{nmblookup} deren Versuche,
  sich gegenseitig zu finden, genau nachstellen. Ebenso k"onnen
  WINS-Server befragt werden und ein NetBIOS Node Status abgefragt
  werden. Das entsprechende Programm auf Seiten von Windows ist das
  Kommandozeilenprogramm \prog{nbtstat}.

\end{description}

Auf der Serverseite finden sich noch weitere Komponenten:

\begin{description}
  
\item[smb.conf:] Die zentrale Konfigurationsdatei von Samba. Ist Samba
  als fester Systembestandteil installiert, findet sie sich in der
  Regel unter \datei{/etc/smb.conf}. Ist Samba selbst compiliert,
  liegt sie h"aufig unter \datei{/usr/local/samba/lib/smb.conf}.
  
\item[/var/lock/samba:] Samba ben"otigt ein Verzeichnis, in dem es
  tempor"are Lockdateien und Datenbanken ablegen kann. Wird Samba ohne
  besondere Optionen selbst compiliert, liegt dies Verzeichnis unter
  \datei{/usr/local/samba/var}.
  
\item[/etc/smbpasswd] ist die Pa"swortdatenbank von Samba, sofern mit
  verschl"usselten Pa"s\-w"ortern gearbeitet wird.
  \datei{/usr/local/samba/private/} ist das Standardverzeichnis f"ur
  diese Datei.

\end{description}

\section{NetBIOS-Konfiguration mit Samba}

Als erstes soll eine minimale Konfiguration von Samba erreicht werden,
mit der jeder Rechner in der Netzwerkumgebung zu sehen ist. Dazu
sollte die Datei \datei{smb.conf} folgenderma"sen aussehen:

\begin{verbatim}
[global]
workgroup = arbeitsgruppe
interfaces = <IP-Adresse>/<Netzmaske>
\end{verbatim}

\label{aufbau-smb.conf}
Der grunds"atzliche Aufbau der \datei{smb.conf} gleicht dem Aufbau der
.INI-Dateien von Windows 3. Die Datei ist in mehrere Abschnitte
unterteilt, die jeweils durch einen Abschnittsnamen eingeleitet
werden. Dieser Abschnittsname selbst wird in eckige Klammern gesetzt.
Der Inhalt jedes Abschnitts besteht nun aus Parameterzuweisungen. Im
Beispiel gibt es nur den Abschnitt \param{global}. In diesem werden
Festlegungen getroffen, die den Server als ganzes betreffen. Wenn
sp"ater Freigaben erstellt werden, geschieht dies durch Anlegen von
weiteren Abschnitten.

Mit dem Parameter \param{workgroup =} wird die Arbeitsgruppe
festgelegt, in der sich der Server befinden soll.

Der Parameter \label{interfaces}\param{interfaces =} ist einer der
wichtigsten Parameter der Sambakonfiguration. Er ist deshalb so
wichtig, weil damit das Funktionieren des NetBIOS-Systems innerhalb
von Samba garantiert wird.  Sp"ater wird deutlich werden, da"s gro"se
Teile der Kommunikation auf Broadcasts basieren. \prog{ifconfig
  <interface>} unter Unix, oder unter Linux speziell \prog{ifconfig
  eth0} gibt sowohl die IP-Adresse der Ethernetkarte als auch die dort
gesetzte Broadcastadresse als Ausgabe. Der Parameter \param{interfaces
  =} weist Samba an, diese und keine andere Schnittstelle zu nutzen.
Dar"uberhinaus ist Samba nun in der Lage, die Broadcastadresse, die
auf dieser Schnittstelle g"ultig ist, zu bestimmen. Theoretisch
k"onnte man die Broadcastadresse selbst"andig herausfinden, aber es
gibt keinen portablen Weg, dies "uber Systemgrenzen hinweg zu tun. Das
sicherste ist, Samba direkt "uber die Broadcastadresse zu informieren.

Mit diesen beiden Einstellungen wird man direkt den Sambarechner in
der Netzwerkumgebung sehen. Zur Vereinfachung sollten noch zwei
weitere Parameter gesetzt werden, die sp"ater erkl"art werden. Die
vollst"andige \datei{smb.conf} sieht also folgenderma"sen
aus:\footnote{Auf einem der Rechner sollte zus"atzlich \param{os level
    = 67} und \param{preferred master = yes} im Abschnitt 
    \param{[global]} der /etc/smb.conf gesetzt sein.}

\begin{verbatim}
[global]
workgroup = arbeitsgruppe
interfaces = <IP-Adresse>/<Netzmaske>
security = share
encrypt passwords = yes
\end{verbatim}

Mit dieser Konfiguration kann Samba gestartet werden. Unter SuSE Linux
geschieht dies mit dem Aufruf:

\begin{verbatim}
rcsmb start
\end{verbatim}

Damit Samba beim n"achsten Hochfahren automatisch gestartet wird,
sollte die Variable \texttt{START\_SMB} in der Datei
\datei{/etc/rc.config} auf \texttt{yes} gesetzt werden. Es mu"s
letztlich nur erreicht werden, da"s sowohl der \prog{nmbd} als auch
der \prog{smbd} mit dem Parameter \texttt{-D} gestartet werden.

Es ist denkbar, den Aufruf beider Programme durch den \prog{inetd}
durchf"uhren zu lassen. Bei Samba ist dies jedoch nicht sinnvoll.
Insbesondere der \prog{nmbd} mu"s auf jeden Fall beim Start des
Systems hochfahren, da dieser im NetBIOS-System Namen f"ur sich
reservieren mu"s. W"urde er erst bei der ersten Anfrage gestartet,
h"atten Windowsrechner keine M"oglichkeit, den Sambarechner zu finden.
Au"serdem wird sich der \prog{nmbd} nicht wieder beenden, sobald er
einmal gestartet wurde. Der \prog{smbd} k"onnte durch den \prog{inetd}
gestartet werden. Jedoch ist der Resourcenbedarf nicht so hoch, da"s
die erh"ohte Startzeit damit gerechtfertigt werden k"onnte.

Nachdem alle Sambaserver gestartet wurden, sollten diese in der
Netzwerkumgebung der beteiligten Windowsrechner erscheinen.

\section{Namensaufl"osung per Broadcast}

Mit \prog{nmblookup} kann man direkt eine NetBIOS-Namensanfrage
ausl"osen.

\begin{quote}
\begin{small}\begin{verbatim}
vlendec@server:/home/vlendec> nmblookup server
querying server on 192.168.1.255
192.168.1.3 server<00>
vlendec@linux:/home/vlendec>
\end{verbatim}\end{small}
\end{quote}
      
An diesem Beispiel wird deutlich, wie die NetBIOS-Namensaufl"osung
normalerweise arbeitet. Es wird ein Paket an der Adresse 192.168.1.255
versendet, die Broadcastadresse im lokalen Subnetz. Um
NetBIOS-Namensanfragen zu erm"oglichen, mu"s Samba in der Lage sein,
die Broadcastadresse herauszufinden, an die das Paket geschickt werden
soll.  \prog{nmblookup} entnimmt diese Adresse der Zeile
\param{interfaces =} der \datei{smb.conf}. F"ur Tests kann man
\prog{nmblookup} mit dem Parameter -B anweisen, die Anfragen an eine
andere Broadcastadresse zu versenden.

\begin{quote}
\begin{small}\begin{verbatim}
vlendec@server:/home/vlendec> nmblookup -B 192.168.1.31 server
querying server on 192.168.1.31
name_query failed to find name server
vlendec@linux:/home/vlendec>
\end{verbatim}\end{small}
\end{quote}

In diesem Beispiel wurde die Broadcastadresse auf 192.168.1.31
gesetzt. Diese Broadcastadresse gilt in Subnetz 192.168.1.0/27. Jedoch
f"uhlte sich der \prog{nmbd}, der f"ur diesen Namen verantwortlich
ist, nicht angesprochen. Folglich hat er nicht auf diese Namensanfrage
geantwortet.
      
Unter Windows kann man die Namensanfrage so isoliert nicht ausl"osen,
man mu"s eine Verbindung aufbauen. Windows unterh"alt einen Cache, in
dem erfolgreiche Anfragen zwischengespeichert werden. Diesen kann man
sich mit \prog{nbtstat -c} anzeigen und mit \prog{nbtstat -R} l"oschen.
Man kann eine Anfrage erzwingen, indem man mit leerem Namenscache eine
Verbindung aufbaut, beispielsweise durch ein \prog{net view
  \symbol{'134}\symbol{'134}samba}.

Die Fehlermeldung, wenn eine NetBIOS-Namensanfrage fehlschl"agt,
lautet im GUI: "`Der Netzwerkpfad wurde nicht gefunden"'. Auf der
Kommandozeile kommt noch die Fehlermeldung 53 dazu.

Mit \prog{nmblookup} kann man sich zus"atzlich die von einem Rechner
reservierten Namen ausgeben lassen. Die entsprechende Operation nennt
sich \defin{Node Status Request} und wird durch den Parameter \prog{-A
  <IP-Adresse>} ausgel"ost. Die Ausgabe eines solchen Node Status
Request zeigt, da"s ein Rechner f"ur sich nicht nur einen einzigen
Namen reserviert, sondern gleich mehrere.

Zun"achst gibt es die Einzelnamen, zum Beispiel den Computernamen
selbst.  F"ur diese gilt die Regel, da"s sie nur ein einziges Mal im
gesamten Netz auftauchen d"urfen. Sie werden reserviert und stehen dem
entsprechenden Rechner dann exklusiv zur Verf"ugung. Daneben gibt es
die Gruppennamen, die im Node Status Request durch \texttt{<GROUP>}
markiert sind. Diese kann es mehrfach im Netz geben. Die Gruppennamen
sind insbesondere als Ziele f"ur NetBIOS-Datagramme interessant.
Beispielsweise reserviert jeder Teilnehmer an einer Arbeitsgruppe den
NetBIOS-Gruppennamen \nbname{arbeitsgruppe<00>}. Damit kann ein
Rechner mit einem einzigen verschickten Datagramm an diesen Namen
s"amtliche Rechner in dieser Arbeitsgruppe erreichen.

Zus"atzlich f"allt auf, da"s beispielsweise der Computername selbst
als Einzelnamen mehrfach reserviert ist. Hier kommen die
unterschiedlichen Namenstypen ins Spiel. Das 16. Byte eines
NetBIOS-Namens ist f"ur ein Typfeld reserviert. So sind
unterschiedliche Anwendungen auf einem Rechner in der Lage, sich Namen
zu reservieren, ohne sich gegenseitig zu st"oren.

Zun"achst die Einzelnamen, die h"aufig auftauchen:

\begin{description}

\item[computername$<$00$>$] Hiermit tut der Rechner einfach seine
Existenz kund. Wenn ein Rechner auf Resourcen anderer Rechner zugreift,
wird als Clientname dieser Name benutzt.

\item[computername$<$20$>$] Dieser Name wird f"ur den Serverdienst
reserviert. Wenn ein Rechner als Datei- oder Druckserver angesprochen
werden soll, dann wird eine Verbindung zu diesem NetBIOS-Namen aufgebaut.

\item[computername$<$03$>$] Unter diesem Namen meldet sich der
Nachrichtendienst des Rechners an. Kurze Meldungen, die unter Windows
NT mit dem Kommando \prog{net send} abgesetzt werden, und unter
Windows 95 mit dem Programm Winpopup verschickt werden, kann der
Rechner damit empfangen und am Bildschirm anzeigen.

\item[arbeitsgruppe$<$1d$>$] Dieser Rechner ist der sogenannte
  \defin{Lokale Master Browser}, der die Liste s"amtlicher Rechner in
  der Netzwerkumgebung pflegt.
  
\item[arbeitsgruppe$<$1b$>$] Dieser Rechner ist der \defin{Domain
    Master Browser}, der "uber Subnetzgrenzen hinweg f"ur die
  Netzwerkumgebung zust"andig ist.

\end{description}

Einige Gruppennamen werden ebenfalls reserviert:

\begin{description}
  
\item[arbeitsgruppe$<$00$>$] Ein Rechner verk"undet hiermit seine
  Zugeh"origkeit zu einer Arbeitsgruppe. Beispielsweise k"onnen
  Winpopup-Meldungen an eine ganze Arbeitsgruppe versendet werden.
  Dies geschieht per Datagramm an diesen Namen.
  
\item[arbeitsgruppe$<$1e$>$] Wahlen zum Lokalen Master Browser werden
  "uber diesen Namen abgewickelt. Siehe hierzu Kapitel \ref{netzwerkumgebung}.

\end{description}

\section{Netzwerkumgebung}
\label{netzwerkumgebung}

Die \defin{Netzwerkumgebung} ist einer der instabileren Aspekte von
Windows. Hiermit kann man sich, sofern alles funktioniert, alle
Rechner in einer Arbeitsgruppe anzeigen lassen. Dabei dauert es
mitunter geraume Zeit, bis ein Rechner in einer Anzeige erscheint, und
es dauert unter Umst"anden noch l"anger, bis er wieder verschwindet.

Eine naive Implementation k"onnte funktionieren, indem jeder Rechner,
der Serverdienste anbietet, dieses regelm"a"sig per Broadcast im Netz
mitteilt. Ein solches Vorgehen hat jedoch mehrere Nachteile. Erstens
w"urde die Last im Netz mit jedem zus"atzlichen Rechner stark
ansteigen. Zweitens mu"s jeder Rechner, der die Netzwerkumgebung anzeigen
will, relativ komplexe Software laufen lassen. Und drittens scheitert dieses
Schema auf jeden Fall an Subnetzgrenzen, die f"ur Broadcasts eine
Grenze darstellen. Aus diesen Gr"unden ist man einen anderen Weg
gegangen.

Der \defin{Lokale Master Browser} (im folgenden auch LMB genannt) ist
ein Rechner, der im Netz die Netzwerkumgebung pflegt. Dieser Rechner
wird nirgendwo zentral bestimmt, sondern er wird gew"ahlt. Diese Wahl
findet immer dann statt, wenn einer der beteiligten Rechner
feststellt, da"s es im Moment keinen solchen Lokalen Master Browser
gibt.  Beispielsweise kann der Explorer von Windows eine solche Wahl
ansto"sen. Wenn Windows 95 die geschwenkte Taschenlampe anzeigt, wird
der LMB gesucht. Ist keiner vorhanden, wird eine Wahl angesto"sen.

Die Wahl erfolgt mit Datagrammen an den Gruppennamen
\nbname{arbeitsgruppe<1e>}. Ein Rechner verschickt ein Datagramm an
diesen Namen. Jeder Rechner, der diesen Namen reserviert hat, h"ort
dieses Datagramm und entscheidet, wie er selbst vorgehen soll.  In dem
Datagramm sind verschiedene Kriterien zur Wahl enthalten,
beispielsweise das Betriebssystem des versendenden Rechners.

Empf"angt beispielsweise eine Windows NT Workstation ein Paket von
einem Windows NT Server, so entscheidet sie, da"s sie die Wahl
verloren hat. Damit wird sie selbst nicht mehr aktiv. Kommt dieses
Paket jedoch von einem Windows 95 Rechner, so h"alt sie sich selbst
f"ur geeigneter, den Lokalen Master Browser zu "ubernehmen. Dann wird
sie selbst ein solches Wahlpaket mit ihren Parametern versenden.  Der
Windows 95 Rechner empf"angt dies, und sieht, da"s er verloren hat.
Auf diese Weise schaukelt sich die Wahl hoch, bis der "`beste"'
Rechner die Wahl gewinnt.

Wenn es nun mehrere Windows NT Workstations im Netz g"abe, dann
w"are die Wahl unentschieden. An dieser Stelle kommt die \emph{Uptime}
der Rechner ins Spiel. Der Rechner, der am l"angsten l"auft, gewinnt
die Wahl. Nun kann es sein, da"s nach einem Stromausfall zwei Rechner
genau die gleiche Uptime haben. Dann kommt als letztes und eindeutiges
Entscheidungskriterium der NetBIOS-Name des Rechners zum Zug. Der
alphabetisch vorne stehende Rechner gewinnt. Mit diesen drei Kriterien
ist eine eindeutige Wahl gesichert.

Samba ordnet sich in der Standardeinstellung zwischen Windows 95 und
Windows NT ein, das hei"st, gegen Windows 95 gewinnt Samba die Wahl,
"uberl"a"st jedoch Windows NT Rechnern den Lokalen Master Browser.

Drei Parameter in der \datei{smb.conf} bestimmen das Verhalten von
Samba in der Wahl zum Lokalen Master Browser:

\begin{description}
  
\item[\param{os level}] Damit wird die Einordnung von Samba in die
  unterschiedlichen Betriebssysteme geregelt. Diese haben f"ur die
  Betriebssystemstufe folgende Werte:

\[\begin{tabular}{|l|r|}
\hline
Windows for Workgroups & 0 \\
\hline
Windows 95/98 & 1 \\
\hline
Windows NT Workstation & 16 \\
\hline
Windows NT Server & 32 \\
\hline
\end{tabular}\]

Diese Werte sind nicht als fest anzusehen. Wenn ein neues Service Pack
f"ur ein Betriebssystem herausgegeben wird, ist es m"oglich, da"s in
der Software f"ur den Lokalen Master Browser Fehler bereinigt wurden.
Dann ist es sinnvoll, da"s diese neue Software die Rolle des LMB
"ubernimmt. Der einfachste Weg ist, den \param{os level} einfach
hochzusetzen. Samba hat hier einen Vorgabewert von 20.

Der Parameter \param{os level} kann Werte von 0 bis 255 annehmen.
Setzt man ihn auf 255, wird nach einer erfolgreichen Wahl niemand mehr
Local Master Browser werden k"onnen.

\item[\param{local master}] M"ochte man auf keinen Fall den LMB auf
  einem Sambarechner haben, so setzt man den Parameter \param{local
    master = no}. Dann nimmt Samba an keiner Wahl teil.
  
\item[\param{preferred master}] Mit der Standardeinstellung
  \param{preferred master = no} sucht Samba beim Start nach
  einem LMB. Findet er einen, meldet er sich dort.  Findet er keinen
  LMB, bleibt Samba passiv. Jemand anders mu"s eine Wahl ansto"sen.
  Wenn dann eine Wahl stattfindet, nimmt Samba teil und ordnet sich
  anhand seines \param{os level} ein. Wenn man sichergehen m"ochte,
  da"s Samba auf jeden Fall nach dem Start den LMB "ubernimmt, dann
  mu"s man den \param{os level} hoch genug setzen, und den Parameter
  \param{preferred master = yes} setzen.  Damit wird Samba beim Start
  des \prog{nmbd} auf jeden Fall eine Wahl ansto"sen und sie dann
  unter Umst"anden gewinnen.

\end{description}

Mit den Einstellungen

\begin{verbatim}
[global]
os level = 66
preferred master = yes
\end{verbatim}

\noindent
kann man sicher sein, da"s der Sambarechner immer den LMB innehat. Es
sei denn, ein anderer Administrator von Samba kommt auf die Idee,
einen noch h"oheren Wert f"ur den \param{os level} zu benutzen.

Ein Primary Domain Controller kann unter Umst"anden erheblich gest"ort
werden, wenn er in seinem Subnetz nicht der LMB ist.

\section{NetBIOS "uber Subnetzgrenzen}

\newcommand{\computer}[2]{%
  \rput[t](0,0){%
    \begin{pspicture}(2,2)
      \psframe(0,0.5)(2,1.5)
      \psline(1,1.5)(1,2)
      \rput(1,1){\texttt{#1}}
      \rput[b](1,0.2){{\footnotesize IP: #2}}
    \end{pspicture}}}
\newcommand{\network}[1]{%
  \rput[l](0,0){%
    \begin{pspicture}(#1,0.6)
      \psline(0,0)(0,0.6)
      \psline(0,0.3)(#1,0.3)
      \psline(#1,0)(#1,0.6)
    \end{pspicture}}}
\newcommand{\routednet}{%
\rput[lb](0,0){%
\begin{pspicture}(10,5.5)
\rput(0,5){\network{7}}
\rput(2,5){\computer{WKS}{192.168.1.5}}
\rput(3,2){\network{7}}
\rput(8,2){\computer{SERVER}{192.168.2.8}}
\rput(5.5,3.75){\psframe(-1,-0.25)(1,0.25)}
\rput(5.5,3.75){{\footnotesize 192.168.1.1}}
\rput(5.5,3.25){\psframe(-1,-0.25)(1,0.25)}
\rput(5.5,3.25){{\footnotesize 192.168.2.1}}
\psline(5.5,4)(5.5,5)
\psline(5.5,2)(5.5,3)
\end{pspicture}}}

Wird die Namensreservierung und -aufl"osung ausschlie"slich per
Broadcast durchgef"uhrt, kann man Rechner, die hinter Routern liegen,
nicht erreichen. Broadcasts verbleiben in den Subnetzen, in denen sie
ausgesendet wurden.

\begin{figure}[ht]\[
\begin{pspicture}(10,6)
\rput(0,0){\routednet}
\psline{<-}(0,5.5)(2.7,5.5)
\psline{->}(4.3,5.5)(7,5.5)
\rput(3.5,5.5){\texttt{SERVER?}}
\end{pspicture}\]
\caption{Namensanfrage per Broadcast}
\label{broadcastanfrage}
\end{figure}

In der dargestellten Situation sind zwei Netze "uber einen Router
verbunden. Jeder der beiden Rechner reserviert seinen Namen in dem ihm
zugeordneten Subnetz. Die Workstation \nbname{WKS} schickt ihre
Reservierungen per Broadcast an 192.168.1.255, und der Server
\nbname{SERVER} wird seinen Namen auf 192.168.2.255 reservieren. Der
Router zwischen beiden bekommt diese Reservierungen zwar mit, wird sie
aber nicht in das jeweils andere Subnetz weiterleiten. Wenn nun
\nbname{WKS} ihren Server \nbname{SERVER} sucht, geschieht dies
ebenfalls per Broadcast an 192.168.1.255. Diese Anfrage bleibt wie
dargestellt im oberen Subnetz und erreicht \nbname{SERVER} gar nicht,
so da"s dieser auch nicht antworten kann.

Der einfachste Weg, die Namensaufl"osung "uber Subnetzgrenzen hinweg
zu realisieren, geht "uber eine statische Tabelle. Unter Windows
liegt diese in der Datei \datei{LMHOSTS}. Sie liegt abh"angig von der
Windowsversion in unterschiedlichen Verzeichnissen und l"a"st sich am
einfachsten mit der Suchfunktion des Desktops finden. Diese Datei ist
"ahnlich aufgebaut wie die Datei \datei{/etc/hosts} unter Unix. Ein
Beispieleintrag ist der folgende:

\verb|192.168.1.5 samba|

Die Eintr"age in der \datei{LMHOSTS} k"onnen durch den Zusatz
\texttt{\#PRE} erg"anzt werden. Dieser Zusatz legt fest, in welcher
Reihenfolge die Namensaufl"osung vorgenommen wird. Ist kein
\texttt{\#PRE} vorhanden, so wird zun"achst eine konventionelle
Namensaufl"osung per Broadcast versucht. Erst, wenn diese
fehlschl"agt, wird in der \datei{LMHOSTS} nachgeschaut. Ist der Zusatz
vorhanden, so wird ohne Namensaufl"osung direkt der Wert in der
\datei{LMHOSTS} verwendet.

Die zweite M"oglichkeit, das Problem zu l"osen, ist eine zentrale
Datei \datei{LMHOSTS}. Dazu gibt es den WINS-Server. Ein solcher Server
ist ein Rechner, bei dem sich jede Applikation im Netz mit ihren Namen
anmeldet. Die IP-Adresse dieses Servers mu"s jedem Rechner mitgeteilt
werden. Bei Windows geschieht dies in den Eigenschaften des TCP/IP
Protokolls im Reiter WINS-Adresse. Setzt man DHCP-Server ein, kann man
ebenfalls den WINS-Server festlegen. Samba bekommt die Adresse mit dem
Parameter \param{wins server = <ip-adresse>} im Abschnitt
\param{[global]} der \datei{smb.conf} mitgeteilt. Sobald ein Client
die IP-Adresse des WINS Servers kennt, ist es v"ollig gleichg"ultig,
ob sich dieser im gleichen Subnetz befindet oder nicht.

Die Namensreservierung erfolgt nicht mehr per Broadcast, sondern mit
einem gerichteten UDP-Paket an den WINS-Server.  Gerichtete Pakete
leitet der Router wie jedes andere Paket an den WINS-Server weiter.
Dieser sieht in seiner Tabelle nach, ob der Name bereits reserviert
ist. Ist das nicht der Fall, so wird er spontan eine Best"atigung der
Reservierung zur"uckschicken. Diese Reservierung gilt nun f"ur eine
bestimmte Zeit und mu"s rechtzeitig erneuert werden.

Ist der Name bereits reserviert, wird der WINS-Server den bisherigen
Besitzer befragen, ob er den Namen noch ben"otigt. Bekommt er keine
Antwort, wird er dem neuen Besitzer ebenfalls eine Best"atigung
schicken. M"ochte der alte Besitzer den Namen noch verwenden, so wird
der Anfragende eine Ablehnung der Reservierung erhalten. Diese
Nachfrage ist notwendig, um einem abgest"urzten Rechner das spontane
Booten zu erm"oglichen, da bei einem Absturz keine Freigabe der
Namensreservierung erfolgen kann.

Die Namensanfrage, die in Abbildung \ref{broadcastanfrage} den Server
nicht erreichte, weil der Router keine Broadcasts weitergibt, wird nun
direkt an den WINS-Server gerichtet, der in seiner Tabelle nachsehen
kann.

\begin{figure}[ht]\[
\begin{pspicture}(10,6)
\rput(0,0){\routednet}
\rput(4,2){\computer{WINS}{192.168.2.5}}
\psline[linestyle=dashed,linearc=0.25]
      {->}(2.5,4.5)(3.2,4.9)(5.3,4.9)(5.3,2)(4.5,1.5)
\rput(3.5,5.8){\texttt{SERVER?}}
\end{pspicture}\]
\caption{WINS-Anfrage}
\end{figure}

Samba kann ganz normal als WINS-Server konfiguriert werden, indem der
Parameter \param{wins support = yes} gesetzt wird. Ist diese Parameter
gesetzt, kann Samba nach einem Neustart bei allen Clients und allen
sonstigen Servern als WINS-Server eingetragen werden. Werden diese
dann neu gestartet, melden sie sich beim WINS Server an.

Wenn nun ein Rechner mit Samba als WINS Server konfiguriert ist, und
sich die anderen Rechner dort anmelden, werden diese in der Datei
\datei{/var/lock/samba/wins.dat} abgelegt. Der \prog{nmbd} pflegt
diese Datei dynamisch, je nach Reservierungen und Abmeldungen. Die
Datei \datei{wins.dat} wird in regelm"a"sigen Abst"anden geschrieben.
Wenn es notwendig sein sollte, den wirklich aktuellen Stand
unabh"angig von diesem Zeitintervall zu erhalten, so kann man dem
\prog{nmbd} das \prog{HANGUP}-Signal durch den Befehl \prog{killall
-HUP nmbd} senden. Au"serdem wird die \datei{wins.dat} beim Beenden
des \prog{nmbd} geschrieben.

Diese Datenbank wird auf Festplatte gehalten, damit die Daten einen
Neustart von Samba "uberleben. Jeder Rechner, der einen Namen f"ur
sich reserviert hat, hat diese Reservierung f"ur einen bestimmten
Zeitraum ausgesprochen. Wenn Samba jetzt neu gestartet werden sollte,
und dadurch die Datenbank verloren ginge, w"are der gesamte
NetBIOS-Namensraum nicht mehr verf"ugbar. Au"serdem kann ein WINS
Server die angeschlossenen Clients weder von sich aus finden, noch sie
darum bitten, sich erneut zu registrieren. Daher ist die WINS
Datenbank "uber Neustarts von Samba hinaus zu erhalten.

Die Anfrage, die die Workstation \nbname{WKS} absetzt, wird nun nicht
mehr per Broadcast gestellt, sondern mit einem gerichteten Paket an
den WINS-Server, bei dem sich alle Rechner angemeldet haben.

%\[\setlength{\unitlength}{1mm}
%\begin{picture}(100,60)(0,20)
%\put(0,0){\routednet}
%\put(30,75){\makebox(0,0)[l]{{\ttfamily\bfseries SERVER?}}}
%\curve(17,65, 20,72, 29,75)
%\tagcurve(40,75, 50,75, 57,65, 57,45, 45,38, 40,30, 30,20)
%\put(50,45){\circle*{1}}
%\put(40,40){\computer{WINS}{192.168.2.5}}
%\end{picture}\]

WINS hat gegen"uber der broadcastbasierten Namensreservierung einige
Vorteile. Namensreservierung per Broadcast erfolgt durch Wartezeiten.
Es wird die Reservierung angek"undigt, es wird gewartet, die
Reservierung wird erneut angek"undigt, und es wird wieder gewartet.
Dieses Spiel wiederholt sich mehrfach, bis der Rechner sicher sein
kann, da"s ein eventueller Vorbesitzer des Namens genug Zeit hatte,
sich zu beklagen. Beim Einsatz von WINS entfallen diese Wartezeiten,
da hier ein einziger Rechner s"amtliche reservierte Namen registriert
und in seiner Tabelle nachschauen kann. Daher ist die Reservierung per
NetBIOS deutlich schneller, und auch weniger netzbelastend. Selbst
wenn man also nur ein einziges Subnetz hat, sollte man zur Reduzierung
der Netzlast den Einsatz eines WINS-Servers in Erw"agung ziehen.

Zus"atzlich sei hier angemerkt, da"s es netzwerkweit nur einen
einzigen WINS-Server geben darf. Selbst wenn es unterschiedliche
Arbeitsgruppen oder Dom"anen gibt, darf es nicht mehr als einen
WINS-Server geben. Setzt man mehrere WINS-Server ein, hat man getrennte
Namensr"aume.  Rechner im einen Namensraum k"onnen mit Rechnern, die
an einem anderen WINS-Server angeschlossen sind, nicht kommunizieren.
Es kann trotzdem zu Kollisionen kommen, da Windowsrechner bestimmte
Namen unabh"angig von WINS-Einstellungen ausschlie"slich per Broadcast
reservieren. Unter Windows NT kann man mehrere WINS-Server einsetzen,
die sich gegenseitig abstimmen. Diese WINS-Server treten gegen"uber
den Clients als ein einziger Server auf, unabh"angig von ihrer Anzahl.

Die Abfrage eines WINS Servers durch \prog{nmblookup} erfolgt
beispielhaft folgenderma"sen:

\begin{verbatim}
nmblookup -R -U 192.168.1.5 samba
\end{verbatim}

Hiermit wird der WINS Server, der auf dem Rechner 192.168.1.5 liegt,
nach dem Namen \nbname{samba} befragt.

Samba kennt zwei zus"atzliche Funktionen, die es im Zusammenhang mit
WINS interessant machen. Einerseits kann Samba als WINS Proxy
eingerichtet werden, indem \param{wins proxy = yes} gesetzt wird. Ist
diese Einstellung aktiv, dann wird Samba s"amtliche Reservierungen und
Anfragen, die es aus dem lokalen Netz per Broadcast erh"alt, an den
mit \prog{wins server =} konfigurierten WINS Server weiterleiten.
Damit kann man einen Samba-Server in ein Subnetz stellen. S"amtliche
Rechner in diesem Netz werden nun beim WINS angemeldet, und nutzen
diesen auch. Dies ist auch dann der Fall, wenn sie entweder selbst
keinen WINS Server ansprechen k"onnen oder nicht daf"ur konfiguriert
sind. Man sollte jedoch in jedem Fall eine echte Konfiguration des
WINS Servers auf dem Client vorziehen. Ein WINS Proxy kann nur eine
Behelfsl"osung sein, da man sich damit auf einen weiteren
Rechner verl"a"st.

Unter Windows kann man statische Eintr"age im WINS vornehmen. Dies
geht so direkt unter Samba nicht. Man mu"s hierzu den Parameter
\param{dns proxy = yes} auf dem WINS Server setzen. Empf"angt der WINS
Server nun eine Anfrage, die er nicht aus seiner Datenbank beantworten
kann, wird er eine ganz normale Unix-Hostnamenanfrage machen.
Typischerweise wird er in der \datei{/etc/hosts} nachschauen und
danach dann das DNS anhand der Konfiguration in der Datei
\datei{/etc/resolv.conf} befragen. Damit ist es durch einen Eintrag
auf dem WINS Server m"oglich, den gesamten DNS-Namensraum auch in der
NetBIOS-Namenswelt zur Verf"ugung zu stellen.

\section{Netzwerkumgebung "uber Subnetzgrenzen}

So, wie die Netzwerkumgebung in Abschnitt \ref{netzwerkumgebung}
betrachtet wurde, funktioniert sie nur in einem einzigen lokalen
Netz. Die Wahl zum lokalen Master Browser funktioniert per Datagramm,
das an den Namen \nbname{arbeitsgruppe<1e>} gesendet
wird. \nbname{arbeitsgruppe<1e>} ist ein Gruppenname, der von mehreren
Rechnern reserviert sein kann. Das hei"st, da"s ein Datagramm an
diesen Namen mehrere Rechner erreichen mu"s. Dies geschieht bei
NetBIOS "uber TCP/IP mit einem UDP-Paket an die Broadcastadresse im
lokalen Netz. Allein hieraus ergibt sich, da"s es pro Arbeitsgruppe in
jedem Subnetz einen eigenen LMB geben mu"s. Jeder LMB bekommt aus
seinem Subnetz die Informationen "uber vorhandene Server.

Um diese Einschr"ankung zu umgehen, gibt es den Domain Master Browser
(DMB). Der DMB ist ein Rechner, der die Serverlisten von allen LMBs
einsammelt und auf Anforderung wieder herausgibt. Dabei sitzt der DMB
nur passiv da und wartet darauf, da"s sich ein LMB mit ihm
synchronisieren will. Es ist Aufgabe der LMBs, sich regelm"a"sig
danach zu erkundigen, wo der DMB sitzt, und mit diesem dann die
Serverlisten abzugleichen.

Die Vorg"ange werden am deutlichsten, wenn man ein Beispiel
betrachtet. Dieses Beispiel ist im wesentlichen der
Originaldokumentation von Samba aus der Datei \datei{BROWSING.txt}
entnommen.

\newcommand{\minicomputer}[1]{%
\begin{picture}(10,9)(5,9)
\put(0,0){\framebox(10,5){{\ttfamily #1}}}
\put(5,5){\line(0,1){4}}
\end{picture}}
\newcommand{\mininetz}[1]{%
\begin{picture}(62,12)
\put(10,10){\minicomputer{N#1A}}
\put(25,10){\minicomputer{N#1B}}
\put(40,10){\minicomputer{N#1C}}
\put(55,10){\minicomputer{N#1D}}
\put(3,10){\line(1,0){59}}
\put(3,8){\line(0,1){4}}
\put(62,8){\line(0,1){4}}
\end{picture}}

\begin{figure}[ht]
\[\setlength{\unitlength}{1.1mm}
\begin{picture}(120,60)(0,5)
\put(0,20){\mininetz{1}}
\put(25,19){\makebox(0,0){\textit{{\small DMB,LMB}}}}
\put(30,50){\mininetz{2}}
\put(85,49){\makebox(0,0){\textit{{\small WINS}}}}
\put(55,49){\makebox(0,0){\textit{{\small LMB}}}}
\put(50,5){\mininetz{3}}
\put(105,4){\makebox(0,0){\textit{{\small LMB}}}}
\put(48,48){\minicomputer{R1}}
\put(48,48){\line(0,1){12}}
\put(48,39){\line(0,-1){9}}
\put(77,48){\minicomputer{R2}}
\put(77,48){\line(0,1){12}}
\put(77,39){\line(0,-1){24}}
\end{picture}\]
\caption{Domain Master Browser}
\end{figure}

Dieses Netz besteht aus 3 Subnetzen (1,2,3), die durch 2 Router (R1
und R2) verbunden sind. Die Router lassen keine Broadcasts durch. Alle
Subnetze bestehen aus jeweils 4 Maschinen.  Nehmen wir der Einfachheit
halber an, da"s alle Maschinen in der gleichen Arbeitsgruppe
konfiguriert sind. Rechner \nbname{N1B} im Subnetz 1 ist als Domain
Master Browser konfiguriert. Das hei"st, da"s er die Browseliste f"ur
die ganze Arbeitsgruppe aufsammelt. Rechner \nbname{N2D} ist als WINS
Server konfiguriert und alle anderen Maschinen registrieren ihre
NetBIOS Namen dort.

Wenn alle diese Maschinen gebootet werden, werden in jedem der drei
Subnetze Wahlen um einen Local Master Browser abgehalten. Nehmen wir
an, im Subnetz 1 gewinnt \nbname{N1C}, im Subnetz 2 gewinnt
\nbname{N2B} und im Subnetz 3 gewinnt \nbname{N3D}. Diese Maschinen
sind als Local Master Browser in ihrem Subnetz bekannt.  Im Subnetz 1
liegen der LMB und der DMB auf der gleichen Maschine, was nicht der
Fall sein mu"s. Diese beiden Rollen sind vollst"andig unabh"angig
voneinander.

Alle Maschinen, die Serverdienste anzubieten haben, k"undigen dies per
Broadcast auf ihrem Subnetz an. Der Local Master Browser in jedem
Subnetz empf"angt diese Broadcasts und tr"agt alle Server in einer
Liste ein. Diese Liste von Eintr"agen ist die Basis f"ur die
Browseliste. In unserem Fall nehmen wir an, da"s alle Maschinen
Serverdienste anbieten, das hei"st, da"s alle Maschinen in der Liste
erscheinen.

F"ur jedes Subnetz wird der Local Master Browser als
\emph{ma"sgeblich} angesehen, und zwar f"ur alle Namen, die er per
lokalem Broadcast empf"angt. Broadcasts verlassen das Subnetz nicht,
und die Broadcasts im lokalen Subnetz werden als ma"sgeblich
angesehen. Daher wird dem Local Master Browser bei diesen Servern
geglaubt. Rechner, die sich in anderen Subnetzen befinden, und "uber
die der Local Master Browser von anderen Local Master Browsern
informiert wurde, werden als nicht ma"sgeblich angesehen.

An diesem Punkt sieht die Browse Liste folgenderma"sen aus: (dies sind
die Maschinen, die Sie in Ihrer Netzwerkumgebung sehen w"urden, wenn
Sie sie in einem bestimmten Subnetz ansehen)

\vspace{\baselineskip}
\[\begin{tabular}{|c|c|l|}
\hline
Netz & LMB &  Liste \\ \hline \hline
1 & \nbname{N1C} & \nbname{N1A}, \nbname{N1B}, \nbname{N1C}, \nbname{N1D}\\
\hline
2 & \nbname{N2B} & \nbname{N2A}, \nbname{N2B}, \nbname{N2C}, \nbname{N2D}\\
\hline
3 & \nbname{N3D} & \nbname{N3A}, \nbname{N3B}, \nbname{N3C}, \nbname{N3D}\\
\hline
\end{tabular}\]
\vspace{\baselineskip}

An diesem Punkt sind alle Subnetze vollst"andig separat, keine
Maschine wird in anderen Subnetzen gesehen. Die
Microsoft-Dokumentation spricht davon, da"s die Arbeitsgruppen in den
Subnetzen getrennt sind.

Sehen wir uns nun Subnetz 2 an. Sobald \nbname{N2B} der Local Master
Browser geworden ist, sucht er den Domain Master Browser, um mit ihm
die Browse Listen zu synchronisieren. Dies tut er, indem er den WINS
Server (\nbname{N2D}) nach der IP-Adresse fragt, die zum NetBIOS-Namen
\nbname{arbeitsgruppe<1B>} geh"ort. Diesen Namen hat der Domain Master
Browser (\nbname{N1C}) beim WINS Server f"ur sich beim booten
registriert.

\nbname{N2B} kennt nun den Domain Master Browser. Er k"undigt sich als
Local Master Browser f"ur Subnetz 2 bei ihm an. Dann synchronisiert
\nbname{N2B} sich mit \nbname{N2D}, indem er einen
NetServerEnum2-Aufruf abschickt. Der Domain Master Browser schickt
alle Server, die er kennt, zur"uck. Sobald der Domain Master Browser
die Ank"undigung von \nbname{N2B} als Lokaler Master Browser erhalten
hat, wird auch er sich mit dem Local Master Browser
synchronisieren. Nachdem beide Synchronisationen stattgefunden haben,
sehen die Browse Listen so aus:

\vspace{\baselineskip}
\[\begin{tabular}{|c|c|l|}
\hline
Netz & LMB &  Liste \\ \hline \hline
1 & \nbname{N1C} & \nbname{N1A}, \nbname{N1B}, \nbname{N1C}, \nbname{N1D}\\
  & & \nbname{N2A*}, \nbname{N2B*}, \nbname{N2C*}, \nbname{N2D*}\\
\hline
2 & \nbname{N2B} & \nbname{N2A}, \nbname{N2B}, \nbname{N2C}, \nbname{N2D}\\
& & \nbname{N1A*}, \nbname{N1B*}, \nbname{N1C*}, \nbname{N1D*}\\
\hline
3 & \nbname{N3D} & \nbname{N3A}, \nbname{N3B}, \nbname{N3C}, \nbname{N3D}\\
\hline
\end{tabular}\]
\vspace{\baselineskip}

Die mit * bezeichneten Eintr"age werden als nicht ma"sgeblich
angesehen, da sie von anderen Master Browsern erhalten wurden. F"ur
den Client macht dies jedoch keinen Unterschied. Nur der LMB darf
diese Eintr"age selbstverst"andlich beim n"achsten Abgleich nicht an
den DMB als seine eigenen zur"uckmelden.

Zu diesem Zeitpunkt werden Benutzer in den Subnetzen 1 und 2, die die
Netzwerkumgebung ansehen, die Server in beiden Subnetzen sehen,
Benutzer im Subnetz 3 sehen immer noch nur die Server in ihrem eigenen
Subnetz.

Der lokale Master Browser im Subnetz 3 (\nbname{N3D}) macht nun exakt
das gleiche wie \nbname{N2B}. Wenn er die Browse Listen mit dem Domain
Master Browser (\nbname{N1B}) abgeglichen hat, bekommt er sowohl die
Server in Subnetz 1, als auch die im Subnetz 2. Nachdem sich
\nbname{N3D} mit \nbname{N1C} synchronisiert hat und umgekehrt, sehen
die Browse Listen folgenderma"sen aus:

\vspace{\baselineskip}
\[\begin{tabular}{|c|c|l|}
\hline
Netz & LMB &  Liste \\ \hline \hline
1 & \nbname{N1C} & \nbname{N1A}, \nbname{N1B}, \nbname{N1C}, \nbname{N1D}\\
  & & \nbname{N2A*}, \nbname{N2B*}, \nbname{N2C*}, \nbname{N2D*}\\
  & & \nbname{N3A*}, \nbname{N3B*}, \nbname{N3C*}, \nbname{N3D*}\\
\hline
2 & \nbname{N2B} & \nbname{N2A}, \nbname{N2B}, \nbname{N2C}, \nbname{N2D}\\
  & & \nbname{N1A*}, \nbname{N1B*}, \nbname{N1C*}, \nbname{N1D*}\\
\hline
3 & \nbname{N3D} & \nbname{N3A}, \nbname{N3B}, \nbname{N3C}, \nbname{N3D}\\
  & & \nbname{N1A*}, \nbname{N1B*}, \nbname{N1C*}, \nbname{N1D*}\\
  & & \nbname{N2A*}, \nbname{N2B*}, \nbname{N2C*}, \nbname{N2D*}\\
\hline
\end{tabular}\]
\vspace{\baselineskip}

Jetzt sehen Benutzer in den Subnetzen 1 und 3 alle Server in allen
Subnetzen, Benutzer im Subnetz 2 sehen jedoch immer noch nur die
Server von Subnetz 1 und 2, nicht jedoch die im Subnetz 3.

Zum guten Schlu"s wird sich der lokale Master Browser im Subnetz 2
(\nbname{N2B}) erneut mit dem Domain Master Browser abstimmen, und die
fehlenden Servereintr"age bekommen. Endlich sehen die Browse Listen
als stabiler Zustand so aus:

\vspace{\baselineskip}
\[\begin{tabular}{|c|c|l|}
\hline
Netz & LMB &  Liste \\ \hline \hline
1 & \nbname{N1C} & \nbname{N1A}, \nbname{N1B}, \nbname{N1C}, \nbname{N1D}\\
  & & \nbname{N2A*}, \nbname{N2B*}, \nbname{N2C*}, \nbname{N2D*}\\
  & & \nbname{N3A*}, \nbname{N3B*}, \nbname{N3C*}, \nbname{N3D*}\\
\hline
2 & \nbname{N2B} & \nbname{N2A}, \nbname{N2B}, \nbname{N2C}, \nbname{N2D}\\
  & & \nbname{N1A*}, \nbname{N1B*}, \nbname{N1C*}, \nbname{N1D*}\\
  & & \nbname{N3A*}, \nbname{N3B*}, \nbname{N3C*}, \nbname{N3D*}\\
\hline
3 & \nbname{N3D} & \nbname{N3A}, \nbname{N3B}, \nbname{N3C}, \nbname{N3D}\\
  & & \nbname{N1A*}, \nbname{N1B*}, \nbname{N1C*}, \nbname{N1D*}\\
  & & \nbname{N2A*}, \nbname{N2B*}, \nbname{N2C*}, \nbname{N2D*}\\
\hline
\end{tabular}\]
\vspace{\baselineskip}

Synchronisationen zwischen dem Domain Master Browser und den Lokalen
Master Browsern wird weiterhin auftreten, aber dies sollte den
stabilen Zustand nur best"atigen.

Wenn Router R1 oder R2 ausfallen, wird das folgende passieren:

\begin{enumerate}
\item Namen der Computer auf beiden Seiten der nicht mehr erreichbaren
Subnetze werden f"ur 36 Minuten weiter in den Browse Listen gehalten,
so da"s sie in der Netzwerkumgebung weiterhin erscheinen.

\item Versuche, Verbindungen zu diesen Rechnern aufzubauen, werden
scheitern, aber die Namen werden nicht von den Browse Listen entfernt
werden.

\item Wenn ein Subnetz vom WINS Server getrennt wird, wird es nur noch
auf die lokalen Server zugreifen k"onnen, deren Namen mit lokaler
Broadcast NetBIOS-Namensaufl"osung aufgel"ost werden k"onnen. Das ist
vergleichbar mit der Situation, keinen Zugriff auf einen DNS Server
mehr zu haben.
\end{enumerate}

\section{Einfache Freigaben}

Der grunds"atzliche Aufbau der Datei \datei{smb.conf} wurde bereits
auf Seite (\pageref{aufbau-smb.conf}) erw"ahnt. Bis zu diesem Punkt
hat sich s"amtliche Konfiguration im Abschnitt \texttt{[global]}
abgespielt, der globale Servereinstellungen beinhaltet. Wenn der
Sambarechner nicht nur im Netz gesehen werden soll, sondern auch
sinnvolle Dinge tun soll, mu"s man Freigaben zur Verf"ugung stellen.
Dies tut man, indem man einfach einen neuen Abschnitt beginnt, dessen
Name gerade nicht \texttt{[global]} ist. Um eine Freigabe vollst"andig
zu machen, mu"s man mit dem Parameter \texttt{path} angeben, welches
Verzeichnis man freigeben m"ochte. Eine f"ur alle Zugriffe offene
Freigabe des Verzeichnisses \datei{/cdrom} erreicht man mit folgender
\datei{smb.conf}:

\begin{verbatim}
[global]
workgroup = arbeitsgruppe
interfaces = <IP-Adresse>/<Netzmaske>
security = share
encrypt passwords = yes

[cd]
path = /cdrom
guest ok = yes
\end{verbatim}

\noindent
Damit entsteht auf dem Server eine Freigabe namens \texttt{CD}, die
das Verzeichnis \datei{/cdrom} im Netz f"ur alle zum Lesen zur
Verf"ugung stellt.

\textbf{Achtung:} 
Es findet hier \emph{keine} "Uberpr"ufung der Zugriffsrechte statt. Um
diese "Uberpr"ufung zu erm"oglichen, sollte zun"achst einmal der
Aufbau einer Verbindung zu einer Freigabe genauer beleuchtet werden.

\section{SMB-Sitzungen}

Wird am Client eine Verbindung zu einer Freigabe auf einem SMB-Server
aufgebaut, so m"ussen mehrere Schritte durchlaufen werden.

\subsection*{NetBIOS-Namensaufl"osung}

Zu einem Rechnernamen mu"s eine IP-Adresse herausgefunden werden. Dies
wurde in den letzten Abschnitten eingehend behandelt.

\subsection*{TCP-Verbindung}

Wenn die IP-Adresse klar ist, wird eine TCP-Verbindung zu Port 139 des
Servers aufgebaut. Um vorhandene TCP-Verbindungen anzuzeigen, gibt es
sowohl auf Unix- als auch auf Windowsrechnern das Werkzeug
\prog{netstat}.

\subsection*{NetBIOS-Sitzung}

Auf einem Serverrechner arbeiten unter Umst"anden mehrere
Applikationen, die Namen f"ur sich reserviert haben. Diese sind alle
unter der IP-Adresse des Rechners und dem TCP-Protokoll auf Port 139
erreichbar. Anhand des TCP-Verbindungsaufbaus ist nicht klar, welche
Serverapplikation angesprochen werden soll. Die Unterscheidung wird
durch den Servernamen getroffen, der in der TCP-Verbindung als erstes
"ubertragen wird.

Da"s der Servername "ubertragen wird, kann man ganz einfach mit Hilfe
des Programms \prog{smbclient} sehen. Man versucht, sich die Liste der
Freigaben eines realen Windowsrechners geben zu lassen, indem man
folgendes aufruft:

\verb|smbclient -L smallwin|

Damit wird zun"achst eine NetBIOS-Namensanfrage ausgel"ost, und dann
eine Verbindung zum entsprechenden Server ausgel"ost. \prog{smbclient}
hat jedoch die M"oglichkeit, einen Server unter einem anderen Namen
anzusprechen, indem man

\verb|smbclient -L test -I ip-adresse|

\noindent
eingibt. \prog{smbclient} wird zun"achst versuchen, eine Verbindung
zum NetBIOS-Namen \texttt{test} aufzubauen, und zwar ohne da"s eine
NetBIOS-Namensanfrage ausgel"ost wird. Stattdessen wird die angegebene
IP-Adresse auf Port 139 direkt angesprochen, und der Name
\texttt{test} als Servername angegeben. Windows merkt, da"s das nicht
stimmen kann und verweigert den Verbindungsaufbau mit einer
Fehlermeldung. Erst im zweiten Versuch wird es \prog{smbclient}
gelingen, eine Verbindung aufzubauen, da diese Verbindung zum
allgemeinen Namen \texttt{*smbserver}\footnote{Das Protokoll wurde als
Antwort auf das WebNFS von SUN in Common Internet File System umbenannt.
Im Gegensatz zur Firma SUN, die tats"achlich das NFS-Protokoll verbessert
hat, hat sich Microsoft die Arbeit einfacher gemacht. Der Name
\texttt{*SMBSERVER} ist der einzige echte Unterschied, den CIFS von
seinem Urvater SMB unterscheidet. Mit Windows 2000 werden diese
NetBIOS-Namen beim Verbindungsaufbau gar komplett unterschlagen.
Daf"ur ist es aber notwendig, einen weiteren Port zu reservieren, und
zwar Port 445.} aufgebaut wird.

Auch der Clientname wird in der Verbindung "ubergeben. Dies testet man
am besten mit

\verb|smbclient //win/c\$ -n blafasel| 

\noindent und schaut sich
die Verbindungstabelle auf der Windowsmaschine mit \verb|nbtstat -s|
an.

Mit dem "ubergebenen Servernamen kann man sehr nette Tricks anstellen.
Man stelle sich vor, da"s einige Freigaben nur f"ur bestimmte
Clientrechner sichtbar sein sollen. Dies ist mit Bordmitteln von Samba
so nicht m"oglich. Man kann zwar mit dem Parameter \param{browseable}
festlegen, ob bestimmte Freigaben in der Netzwerkumgebung erscheinen.
Dieser Parameter hat aber zwei Nachteile.  Erstens sind die Freigaben nur
unsichtbar geworden, darauf zugreifen kann man immer noch. Zweitens kann man
Freigaben nur f"ur alle Rechner verstecken oder freigeben.

Samba bietet die Option, unter zwei oder mehreren verschiedenen Namen
in der Netzwerkumgebung zu erscheinen. Mit dem Parameter
\param{netbios name} gibt man einen Namen f"ur den Server an.
Zus"atzliche Namen kann man mit \param{netbios aliases} vergeben. Mit

\begin{verbatim}
netbios name = fichte
netbios aliases = birke eiche kiefer buche
\end{verbatim}

\noindent
handelt man sich einen ganzen Wald in der Netzwerkumgebung ein. Klickt
man auf die einzelnen Server, sieht man "uberall die gleichen
Freigaben und Zugriffsrechte. Nun kann man f"ur jeden dieser
virtuellen Rechner eine eigene Konfigurationsdatei anlegen.
Beispielsweise kann man sie \datei{/etc/smb.conf.birke},
\datei{/etc/smb.conf.eiche} und so weiter nennen. Die Datei
\datei{/etc/smb.conf} ist f"ur den Rechner \nbname{fichte} zust"andig
und enth"alt neben den Einstellungen f"ur \nbname{fichte} den
Parameter 

\param{config file = /etc/smb.conf.\%L}

\noindent Dabei steht
\param{\%L} f"ur den Servernamen, unter dem Samba angesprochen wird.
Wenn es eine passende Datei gibt, dann bewirkt der Parameter
\param{config file}, da"s die komplette Konfiguration neu eingelesen
wird. Existiert keine passende Datei, so wird der Parameter einfach
ignoriert. Um nun den Zugriff nur f"ur einzelne Clients zu erlauben,
kann bei den einzelnen virtuellen Servern mit den Parametern
\param{hosts allow} und \param{hosts deny} der Zugriff geregelt
werden.

\subsection*{Negotiate Protocol}

Die NetBIOS-Sitzung ist nun aufgebaut, und es k"onnen Daten
"ubermittelt werden. Innerhalb dieser NetBIOS-Sitzung wird eine
SMB-Sitzung schrittweise aufgebaut. SMB ist ein Protokoll, bei dem im
Prinzip der Client jede Aktion durch eine Anfrage anst"o"st, und der
Server diese beantwortet\footnote{Im Prinzip deshalb, da mit Oplocks
  auch der Server von sich aus aktiv werden kann.}.

SMB (Server Message Block) ist ein gewachsenes Protokoll. Es ist mit
den F"ahigkeiten der Betriebssysteme gewachsen, die damit arbeiten.
Zun"achst ist es entstanden, um die Dateisystemaufrufe der MS-DOS
Systemschnittstelle INT 0x21 auf das Netz zu verlagern. Mit einer
gewissen Weitsicht hat man jedoch vorausgesehen, da"s die Entwicklung
nicht bei MS-DOS stehen bleiben w"urde, sondern sich die
Dateisystemaufrufe "andern w"urden. Man hat im Protokoll also eine
M"oglichkeit vorgesehen, mit der unterschiedliche Protokollvarianten
ausgehandelt werden k"onnen. Die unterschiedlichen Protokolle
orientieren sich immer an den F"ahigkeiten der jeweiligen
Betriebssysteme. Beispielsweise wurde mit dem LAN Manager, der eine
Benutzerverwaltung besitzt, das Konzept des Benutzers im Protokoll
aufgenommen. OS/2 hat ein recht weitgehendes Konzept der
Druckerverwaltung, das entsprechend mit Protokollerweiterungen bedacht
wurde. Sogar f"ur XENIX gibt es einen eigenen Protokolldialekt, der
das Unix-Zugriffsrechtekonzept im SMB-Protokoll abbildet. Diese
Protokollvariante beherrscht nur leider kein moderner Client. Mit
Ausnahme des ausgestorbenen XENIX-Dialektes lassen sich die Protokolle
gut in eine Hierarchie einordnen. Sp"atere Protokolle beherrschen alle
Aspekte der vorherigen Varianten.

Die erste Anfrage, die der Client an den Server schickt, ist ein
\defin{Negotiate Protocol Request}. In dieser Anfrage schickt der
Client an den Server eine Liste der Protokollvarianten, die er
beherrscht. Der Server w"ahlt nun aus dieser Liste der Protokolle eins
aus, und schickt eine entsprechende Antwort zur"uck. Die verschiedenen
Protokolle bauen aufeinander auf. Daher kann man mit dem Parameter
\param{protocol} das h"ochste Protokoll festlegen, mit dem Samba
arbeiten soll.

In der Antwort auf diese erste Anfrage werden zwei weitere
Einstellungen verschickt, die Teile des weiteren Ablaufs festlegen.

Der Server entscheidet, ob er die Zugriffssteuerung auf Benutzer- oder
auf Freigabeebene regeln m"ochte. Damit wird festgelegt, zu welchem
Zeitpunkt der Benutzer ein Pa"swort liefern mu"s. Entweder kann es
beim direkt folgenden \defin{Session Setup} erfolgen, oder erst beim
\defin{Tree Connect} danach.

Der Parameter \param{security} legt fest, welche Art der
Zugriffssteuerung gew"ahlt wurde.  Mit \param{security = share} wird
die Freigabeebene eingestellt, \param{security = user} legt die
Clients auf die Benutzerebene fest.

Sichtbar wird diese Unterscheidung in der Windowswelt nur bei Windows
95 und Windows 98. Diese Betriebssysteme beherrschen zun"achst einmal
nur die Zugriffssteuerung auf Freigabeebene, da sie nicht "uber eine
Benutzerdatenbank verf"ugen.  Es ist nicht m"oglich, einzelnen
Benutzern den Zugriff auf Freigaben zu gew"ahren oder zu
verweigern. Um trotzdem benutzerbasiert Zugriffssteuerung zu
erm"oglichen, mu"s ein Server angegeben werden, der f"ur Windows die
Benutzerdatenbank pflegt. Damit k"onnen Pa"sw"orter benutzerbasiert
"uberpr"uft werden.

Weiterhin gibt der Server dem Client vor, ob Klartextpa"sw"orter
verwendet werden sollen, oder ob die Pa"sw"orter verschl"usselt
werden. Wenn der Server festlegt, da"s verschl"usselte Pa"sw"orter
verwendet werden, wird zus"atzlich die Herausforderung f"ur das
\defin{Challenge Response} Verfahren mitgeschickt.

Die Entscheidung "uber Klartextpa"sw"orter mu"s also getroffen werden,
ohne da"s der Server den Benutzernamen, der sich anmelden will,
kennt. Es ist also nicht m"oglich, f"ur einige Benutzer
Klartextpa"sw"orter und f"ur andere Benutzer verschl"usselte
Pa"sw"orter zu verwenden.

\subsection*{Session Setup}

Nachdem die Protokollversion ausgehandelt ist, wird vom Client ein
\defin{Session Setup} verschickt. In diesem Session Setup schickt der
Client seinen Benutzernamen an den Server. Sofern dieser
\param{security = user} verlangt hat, wird an dieser Stelle das
Pa"swort mitgeschickt. Damit ist der Server in der Lage, die
Identit"at des Benutzers festzustellen. Wenn \param{security = share}
vereinbart wurde, dann ignoriert der Server ein hier eventuell
mitgeschicktes Pa"swort.

\subsection*{Tree Connect}

Als letztes legt der Client fest, welche Freigabe er ansprechen will.
Der entsprechende Aufruf hei"st \defin{Tree Connect}. Sofern
\param{security = share} vereinbart wurde, wird an dieser Stelle das
Pa"swort "uberpr"uft. Der Benutzername kann in diesem Fall nicht zur
Zugriffsregelung verwendet werden. Dieser wurde unter Umst"anden gar
nicht "ubermittelt, da der Client den Session Setup komplett auslassen
darf. Andererseits hat er bei einem durchgef"uhrten Session Setup kein
Pa"swort angeben m"ussen, anhand dessen die Identit"at des Benutzers
zweifelsfrei h"atte festgestellt werden k"onnen.

\section{Zugriffsrechte}

Bei Windows NT kann man mit zwei unterschiedlichen Mechanismen Rechte
vergeben. An einer Freigabe kann man "uber Schreib- und Lesezugriff
entscheiden. Innerhalb des Dateisystems kann man detailiert Rechte
vergeben.

Ist bei Samba \param{security = user} gesetzt, so hat der Server die
M"oglichkeit, anhand des angemeldeten Benutzers Zugriffsrechte zu
vergeben oder zu verweigern. Wenn bez"uglich der Zugriffsrechte bei
einer Freigabe nichts gesagt wird, hat jeder korrekt angemeldete
Benutzer Leserecht. Man kann auch Gastbenutzern Leserecht geben, indem
man \param{guest ok = yes} setzt.

Mit den Optionen zur Rechtevergabe an Freigaben hat man die
M"oglichkeit, einzelnen Benutzern und ganzen Unixgruppen Rechte zu
geben oder zu nehmen. Die M"oglichkeiten sind hier deutlich weitergehend 
als die Semantik, die Unix mit den Rechtemasken f"ur den
Dateibesitzer, die besitzende Gruppe und den Rest der Welt bereit
stellt. Von den m"oglichen Anwendungen sollen hier drei h"aufig
ben"otigte F"alle dargestellt werden.

\begin{itemize}
\item {\bf \emph{Alle} Benutzer haben gleichen Zugriff}

\begin{verbatim}
[projekt]
path = /data/projekt
\end{verbatim}

Bei dieser Freigabe bekommen alle Benutzer, die sich mit Namen und
Pa"swort am Server angemeldet haben, \emph{Leserecht} auf die
Freigabe. Schreibrecht vergibt man, indem man den Parameter
\param{writeable = yes} setzt:

\begin{verbatim}
[projekt]
path = /data/projekt
writeable = yes
\end{verbatim}

\item {\bf \emph{Einige} Benutzer haben gleichen Zugriff}

Will man den Zugriff auf einige Benutzer einschr"anken, erstellt man
eine Liste \param{valid users} auf:

\begin{verbatim}
[projekt]
path = /data/projekt
valid users = mueller, meier
\end{verbatim}

Zu dieser Freigabe haben die Benutzer mueller und meier
Lesezugriff. Sollen diese Benutzer Schreibzugriff bekommen, so ist wie
im vorangegangenen Beispiel der Parameter \param{writeable = yes} zu
setzen:

\begin{verbatim}
[projekt]
path = /data/projekt
valid users = mueller, meier
writeable = yes
\end{verbatim}

F"ur den Parameter \param{valid users} spielt der Benutzer root keine
besondere Rolle. Das hei"st, da"s er auf die Freigabe \param{projekt}
keinen Zugriff hat. Soll er Zugriff bekommen, mu"s man ihn wie jeden
anderen Benutzer in die Liste \param{valid users} mit aufnehmen.

Der Parameter \param{valid users} gibt die M"oglichkeit, ganze
Unixgruppen in den Zugriff mit aufzunehmen. Um dies zu erreichen, mu"s
man das at-Zeichen voranstellen:

\begin{verbatim}
[projekt]
path = /data/projekt
valid users = root, @users
writeable = yes
\end{verbatim}

Mit dieser Einstellung haben alle Benutzer, die in der Unixgruppe
users sind, Schreibzugriff auf die Freigabe. Zus"atzlich kann der
Benutzer root schreiben.

\item {\bf Einige Benutzer haben Leserecht, andere Schreibrecht}

Will man differenziert Rechte vergeben, so mu"s man s"amtliche
Benutzer, die "uberhaupt Zugriff auf die Freigabe bekommen sollen, in
die Liste \param{valid users} aufnehmen, und mit \param{writeable =
no} nur Leserechte vergeben. Die Benutzer, die "uber diese
Standardeinstellung hinaus Schreibrecht bekommen sollen, m"ussen in
die \param{write list} aufgenommen werden.

\begin{verbatim}
[projekt]
path = /data/projekt
valid users = @users, @admins
writeable = no
write list = @admins
\end{verbatim}

Mit diesen Einstellungen haben die Benutzer der Gruppe users
Leserecht, und die Benutzer der Gruppe admins haben Schreibrecht.

\end{itemize}

\section{Unix-Zugriffsrechte}

Unter Windows NT gibt es zwei M"oglichkeiten, Zugriff auf Dateien zu
gew"ahren. "Uber eine Freigabe kann ein Lese- oder ein Schreibrecht
vergeben werden. Im zweiten Schritt k"onnen dann "uber eine
Rechtevergabe im Dateisystem weitere Rechte vergeben werden. Samba
regelt die Zugriffskontrolle ebenfalls in zwei Schritten. Die
freigabebezogenen Rechte werden "uber Parameter wie \param{valid
users} und \param{write ok} geregelt. Die Zugriffsrechte innerhalb des
Dateisystems regelt Samba nicht selbst, sondern verl"a"st sich
hierf"ur auf das darunterliegende Betriebssystem Unix.

Zwischen Unix und DOS bestehen gro"se Unterschiede. DOS und alle seine
Nachfolger sind Einzelbenutzersysteme, Unix ist von Anfang an als
Multiusersystem entworfen worden. Diese Unterschiede werden besonders
deutlich, wenn man die Attribute betrachtet, die auf Dateien vergeben
werden. DOS kennt vier Attribute:

\begin{description}
\item[Read-Only] Der Inhalt dieser Datei kann nur gelesen, aber nicht
geschrieben werden. Die Datei kann nicht gel"oscht werden.
\item[System] Diese Datei ist f"ur spezielle Betriebssystemzwecke
vorgesehen.
\item[Hidden] Diese Datei wird mit dem Kommando 'DIR' nicht angezeigt.
\item[Archiv] Das Archivbit wird bei jedem Schreibzugriff gesetzt.
Backupprogrammen ist es freigestellt, dieses Bit zur"uckzusetzen.
Damit kann eine inkrementelle Sicherung erm"oglicht werden.
\end{description}

Diese Bits k"onnen vom Benutzer frei gesetzt und wieder zur"uckgesetzt
werden. Sie bieten also keinen echten Zugriffsschutz, sondern nur eine
gewisse Sicherung gegen Fehlbedienung.

Unix f"uhrt mit jeder Datei einen Satz von Zugriffsrechten mit. Diese
sind aufgeteilt in 3 Gruppen von Benutzern: Der Dateibesitzer, die
besitzende Gruppe und alle anderen. Jeder Gruppe k"onnen 3
Rechte zugeteilt werden: Lesen, Schreiben und ausf"uhren.

Unter DOS werden Ausf"uhrungsrechte nicht verwendet. Sie stehen f"ur
Samba zur Verf"ugung, um die DOS-Attribute im Unix-Dateisystem
abzubilden. Das Schreibschutzbit unter DOS hat mit dem Schreibrecht
des Dateibesitzers unter Unix eine Entsprechung. Bis auf die Umsetzung
des Schreibschutzbits kann die Umsetzung der Attribute unter Samba mit
den entsprechenden Parametern \param{map <xxx>} gesteuert werden,
wobei das Archivbit ohne Zusatzangabe umgesetzt wird, die anderen
beiden Attribute nicht. Die Attributumsetzung erfolgt anhand der
folgenden Tabelle:

\[ \begin{tabular}{|l|l|c|l|l|}
\hline
DOS-Attribut & Unix-Recht & Maske & Parameter & Standard \\
\hline\hline
Schreibschutz & Schreibrecht Besitzer & 200 & - & immer \\
\hline
Archiv & Ausf"uhrung Besitzer & 100 & \param{map archive} & \param{yes} \\
\hline
System & Ausf"uhrung Gruppe & 010 & \param{map system} & \param{no} \\
\hline
Versteckt & Ausf"uhrung Andere & 001 & \param{map hidden} & \param{no} \\
\hline
\end{tabular} \]

Samba mu"s nun diese beiden Dateiattribute ineinander "uberf"uhren.
Samba mu"s neu erstellten Dateien Unixrechte zuordnen.  Wird eine
Datei neu erstellt, dann gibt der Client dem Server die DOS-Attribute
mit, mit der er die Datei erstellt haben m"ochte. Daraus formt Samba
einen Satz von Unix-Zugriffsrechten. Diese Rechte werden vom Parameter
\param{create mask} eingeschr"ankt. Die Standardvorgabe f"ur die
\param{create mask} ist gleich \param{744}, was der Rechtemaske
\param{rwxr--r--} entspricht. Der Dateieigent"umer hat Schreib- und
Leserecht, alle anderen haben reines Leserecht. Samba schr"ankt die
Rechte ein, indem der gew"unschte Satz an Rechten mit einer logischen
UND-Operation mit der \param{create mask} verkn"upft wird. Nur die
Rechte, die in der \param{create mask} gesetzt sind, k"onnen
m"oglicherweise in der neu erzeugten Datei auftauchen. In einem
weiteren Schritt setzt Samba explizit gew"unschte Zugriffsrechte
anhand des Parameters \param{force create mode}, dessen Standardwert
auf \param{000} steht. Dies geschieht durch eine ODER-Verkn"upfung mit
diesem Wert.

Diese Zusammenh"ange werden an einem Beispiel deutlicher. Es kann
gew"unscht sein, da"s auf neu erstellten Dateien nur der
Dateibesitzer und die Gruppe Leserecht haben sollen. Der Rest der Welt
soll diese Dateien nicht lesen k"onnen. Das wird dadurch erreicht,
da"s man die \param{create mask = 740} setzt, also das Leserecht f"ur
den Rest der Welt ausmaskiert. Es kann dar"uber hinaus gew"unscht
sein, da"s die besitztende Gruppe ein Schreibrecht einger"aumt
bekommt. Das kann man durch \param{force create mode = 020} erreichen.
Tabellarisch dargestellt hei"st dies:

\[ \begin{tabular}{|l|l||c|l|}
\hline
Wunsch & & & \texttt{rw-r-{}-r-{}-} \\
\hline
create mask & 740 & UND & \texttt{rw-r-{}-{}-{}-{}-} \\
\hline
\hline
& & & \texttt{rw-r-{}-{}-{}-{}-} \\
\hline
force create mode & 020 & ODER & \texttt{-{}-{}-{}-w-{}-{}-{}-} \\
\hline
\hline
Ergebnis & & & \texttt{rw-rw-{}-{}-{}-} \\
\hline
\end{tabular} \]

Die Ausf"uhrungsrechte auf Dateien werden unter DOS nicht verwendet,
sie k"onnen also verwendet werden, um DOS-Attribute im
Unix-Dateisystem abzulegen. Ausf"uhrungsrechte auf Dateiverzeichnissen
wirken sich jedoch auf das Verhalten von Samba aus, da durch sie der
Zugriff zu den Verzeichnissen geregelt wird.  Daher kann es
w"unschenswert sein, da"s die Rechtezuweisung auf Dateien und
Verzeichnissen unterschiedlich geregelt wird. Die Parameter
\param{create mask} und \param{force create mode} wirken daher nur auf
neu angelegte Dateien.  F"ur Verzeichnisse sind die Parameter
\param{directory mask} und \param{force directory mode}
verantwortlich. Der Vorgabewert f"ur \param{directory mask} ist
hierbei \param{755}, um den Zutritt f"ur die Gruppe und den Rest der
Welt zu erm"oglichen, die Vorgabe f"ur \param{force directory mode}
besetzt mit dem Wert \param{000} kein zus"atzliches Recht.

\section{Beispiel: Projektverzeichnisse}

Folgendes Problem stellt sich bei der Migration von Novell zu Samba
recht h"aufig. Unter Novell kann man anhand von
Gruppenzugeh"origkeiten den Zugriff auf Verzeichnisse regeln. Dies ist
unter Samba anhand von Unixrechten ebenfalls m"oglich. Was Unix leider
nicht zur Verf"ugung stellt, ist die M"oglichkeit, Verzeichnisse vor
Benutzern zu verstecken. Ein Benutzer sieht grunds"atzlich alle
Verzeichnisse, bekommt aber bei vielen dieser Verzeichnisse die
Meldung, da"s der Zugriff verweigert wurde. Wenn es jetzt anhand der
Gruppenzugeh"origkeit des Benutzers m"oglich w"are, nur die
Verzeichnisse anzuzeigen, auf die er tats"achlich Zugriff hat,
k"onnten die Verzeichnisse deutlich "ubersichtlicher werden.

Die Flexibilit"at von Samba erm"oglicht es, diese von Unix
vorgegeben Beschr"ankung zu umgehen, und zwar unter Benutzung von
Skripten, die vor dem Verbinden mit einer Freigabe ausgef"uhrt werden.

Folgendes Szenario wird vorausgesetzt: Jeder Benutzer ist in mehrere
Gruppen eingeteilt, die jeweils Projekte, Arbeitsgruppen oder
Abteilungen darstellen k"onnen. Jede dieser Gruppen hat unter
\datei{/data/groups} ein eigenes Verzeichnis, auf das sie schreiben
darf. Die einzelnen Verzeichnisse haben das Set Group ID Bit gesetzt,
damit die neu angelegten Dateien den jeweiligen Gruppen angeh"oren.

Als Beispiel gebe es die drei Gruppen \param{edv}, \param{fibu} und
\param{verkauf}. Das Gruppenverzeichnis \datei{/data/groups} sieht
folgenderma"sen aus:

{\small\begin{verbatim}
root@server:/data/groups> ls -l
total 12
drwxrws---   2 root     edv          4096 Jan 31 06:43 edv
drwxrws---   2 root     fibu         4096 Jan 31 06:43 fibu
drwxrws---   2 root     verkauf      4096 Jan 31 06:43 verkauf
root@server:/data/groups>
\end{verbatim}
}

Die korrekten Rechte erreicht man unter Unix durch:

{\small\begin{verbatim}
root@server:/root> mkdir /data/groups/edv
root@server:/root> chgrp edv /data/groups/edv
root@server:/root> chmod 2770 /data/groups/edv
\end{verbatim}
}

Eine Freigabe, die jedem Benutzer anhand seiner Rechte hierauf Zugriff
gew"ahrt, kann folgenderma"sen aussehen:

{\small\begin{verbatim}
[allgroups]
path = /data/groups
writeable = yes
create mode = 740
directory mode = 750
force create mode = 020
force directory mode = 020
\end{verbatim}
}

Zu beachten ist hier, da"s keine zus"atzlichen Einschr"ankungen anhand
von \param{valid users} notwendig sind, da der Zugriff durch die
Unixrechte beschr"ankt ist. Die Parameter \param{create mask} und
\param{directory mask} sind nicht strikt notwendig, da bereits auf der
Ebene \datei{/data/share} die Benutzer abgewiesen werden. Die
Parameter \datei{force create mode} und \param{force directory mode}
sind hingegen notwendig, da ohne sie neu angelegte Dateien nicht die
notwendigen Gruppenschreibrechte erhalten w"urden, die zum gemeinsamen
Zugriff notwendig sind.

Diese Freigabe erf"ullt funktional genau die Anforderungen, da"s
jeder in die Verzeichnisse schreiben darf, f"ur die er die
Gruppenmitgliedschaft hat. Der Nachteil an diesem Verfahren ist, da"s
er alle anderen Verzeichnisse sieht, was bei gro"sen Servern mit
vielen Gruppen recht un"ubersichtlich werden kann.

Die preexec-Skripte von Samba erm"oglichen die "ubersichtliche
Darstellung der Gruppenstruktur. Ein preexec-Skript wird ausgef"uhrt,
bevor der Benutzer tats"achlich mit der Freigabe verbunden wird.

{\small\begin{verbatim}
[gruppen]
path = /data/users/%U
root preexec = /usr/local/bin/mklinks %U
writeable = yes
\end{verbatim}
}

Die Datei \datei{mklinks} hat folgenden Inhalt:

{\small\begin{verbatim}
#!/bin/sh
umask 022
cd /data/users
rm -rf "$1"
mkdir "$1"
cd "$1"
for i in `groups $1`
do
        ln -s /data/groups/$i .
done
\end{verbatim}
}
    
Beim Verbinden an die Freigabe wird das Verzeichnis
\datei{/data/users/username} frisch erstellt, das anhand der
Gruppenzugeh"origkeit des Benutzers eine Liste von symbolischen
Links erstellt, die auf die eigentlichen Gruppenverzeichnisse
verweisen. Damit bekommt er nur die Verzeichnisse im Explorer
angezeigt, auf die er tats"achlich Zugriff hat. Durch die Angabe
\param{path = /data/users/\%U} ist zudem sichergestellt, da"s die
Freigabe f"ur alle Benutzer gleich hei"st, aber f"ur jeden
Benutzer auf ein eigenes Verzeichnis verweist. Das Skript wird in
diesem Beispiel als \param{root preexec} ausgef"uhrt, um den
Verwaltungsaufwand beim Anlegen neuer Benutzer zu minimieren. Mit
einem reinen \param{preexec} ohne Rootrechte w"are es notwendig,
f"ur jeden Benutzer unterhalb von \param{/data/users} ein eigenes
Verzeichnis mit den notwendigen Rechten anzulegen. Alternativ
k"onnte man das Verzeichnis mit der Gruppenliste im
Heimatverzeichnis des Benutzers anlegen, wobei dabei Zweifel
bez"uglich der "Ubersichtlichkeit angebracht sind. Ein weiteres
Argument, das Skript unter Rootrechten auszuf"uhren, ist die
Betriebssicherheit. Ohne dies w"are es dem Benutzer m"oglich, sich
vollst"andig von einem Gruppenverzeichnis auszuschlie"sen indem er
das gesamte Verzeichnis inklusive symbolischem Link l"oscht. Mit
der dargestellten Version geh"ort das Verzeichnis mit den
symbolischen Links dem Benutzer root, und Fehlbedienungen in
dieser Ebene sind ausgschlossen.

Wenn man die Freigabe \param{[allgroups]} auf \param{[browseable =
  no]} setzt, so hat man maximale "Ubersichtlichkeit bei vollem
Zugriff auf s"amtliche Gruppenverzeichnisse durch den Administrator
gegeben.

"Andern sich die Gruppenzugeh"origkeiten eines Benutzers, so kann
er einfach durch ein Neuverbinden an die Freigabe die neue Sicht auf
die Verzeichnisstruktur bekommen. Dieses Neuverbinden kann erzwungen
werden, indem der richtige Serverprozess get"otet wird. Dieser kann
anhand des Programms \prog{smbstatus} leicht herausgefunden werden.

\section{Pa"sw"orter}
\label{passwoerter}

Protokolle der IP-Welt wie telnet, ftp und pop3 "ubertragen die
Pa"sw"orter zur Benutzerauthentifizierung im Klartext. Damit kann
jeder, der den Netzverkehr abh"oren kann, s"amtliche Pa"sw"orter
mitschreiben. Daf"ur existieren fertige Programme, die Benutzernamen
und dazugeh"orige Pa"sw"orter ausgeben. In der Unixwelt wurde dies
zun"achst nicht als problematisch angesehen, da zum Zugriff auf das
Netz Administratorrechte oder physikalischer Zugriff zum Netz
notwendig sind. Beides war historisch oft nicht gegeben, so da"s das
Risiko als relativ gering eingesch"atzt wurde. Mit dem Aufkommen von
DOS und Ethernet hat jeder Benutzer Administratorrechte, kann also den
Netzverkehr mitschneiden.

Benutzerauthentifizierung mu"s vor allem eins leisten: Der Benutzer
mu"s beweisen, da"s er sein Pa"swort kennt. Ein
Authentifizierungsprotokoll kann es dabei erm"oglichen, da"s das
Pa"swort nicht "ubertragen werden mu"s.

Im SMB-Protokoll wird zur Authentifizierung ein Challenge-Response
Verfahren eingesetzt. Der Server verschickt an den Client eine
Zufallszahl, die sogenannte Herausforderung. Der Client kennt das
Benutzerpa"swort, und verschl"usselt die Herausforderung mit dem
Pa"swort als Schl"ussel. Diesen verschl"usselten Wert verschickt der
Client anstelle des Pa"sworts. Der Server kennt das Benutzerpa"swort
ebenfalls, und kann den versch"usselten Wert entschl"usseln. Entsteht
bei der Entschl"usselung wieder die Herausforderung, so hat der
Benutzer die Herausforderung offensichtlich mit dem korrekten Pa"swort
verschl"usselt. Kommt etwas anderes heraus, war das Pa"swort nicht
richtig.

\begin{figure}\[
\begin{pspicture}(11.5,6.5)
%\psgrid[subgriddiv=1,griddots=10]
\psframe(11.5,6.5)
\psline(3,6.5)(3,0)
\psline(7,6.5)(7,0)
\psframe[fillstyle=solid,fillcolor=lightgray](3,0)(7,6.5)
\rput(2,6){{\sffamily\bfseries Client}}
\rput(5,6){{\sffamily\bfseries Zuh"orer}}
\rput(8,6){{\sffamily\bfseries Server}}
\psline(0,5.7)(11.5,5.7)

\psline{->}(2.5,5)(7.5,5)
\rput(5,5.2){Negotiate Protocol}

\rput[lB](8,4.5){H: Herausforderung}
\psline{->}(7.5,4.5)(2.5,4.5)
\rput(5,4.3){{\bfseries H}}

\psline{->}(2.5,3)(7.5,3)
\rput(5,3.2){Session Setup}
\rput(5,2.8){{\bfseries Username, PW(H)}}
\rput[lB](0.3,3.9){Herausforderung}
\rput[lB](0.3,3.5){Username}
\rput[lB](0.3,3.1){Pa"swort}

\rput[lB](8,2.9){Username}
\rput[lB](8.2,2.5){$\Rightarrow$ Pa"swort}
\rput[lB](8.2,2.1){entschl"ussle PW(H)}

\pscurve{->}(5.8,2.7)(8,1.8)(9.5,1.8)(10,2)
\rput[tl](9.8,1.9){$\Rightarrow$ H}

\pscurve{<->}(10.5,1.6)(10.8,1.5)(11.3,2)(11,3)(8.3,4.4)
\rput[t](10.8,1.4){=?}

\psline{->}(7.5,0.8)(2.5,0.8)
\rput(5,0.6){{\bfseries Ok?}}
\end{pspicture}\]
\caption{Challenge-Response Verfahren}
\end{figure}

Ein Zuh"orer verf"ugt
"uber die Herausforderung und den verschl"usselten Wert. Mit
diesen beiden Werten k"onnte er einen Known Plaintext Angriff gegen
die Verschl"usselung starten. Das hei"st, es mu"s ein
Verschl"uselungsalgorithmus gew"ahlt werden, der gegen einen solchen
Angriff immun ist. Er kann keine Replay Attacke starten, da er bei
jedem neuen Verbindungsaubau eine neue Herausforderung bekommt, die er
verschl"ussen mu"s.

Windows NT verh"alt sich diesbez"uglich vern"unftig. Windows 95 denkt
sich jedoch nur alle 15 Minuten eine neue Herausforderung aus. Das
hei"st, da"s jemand nur einen Verbindungsaufbau mitschneiden mu"s, und
sich sofort danach mit der gleichen Benutzerkennung bei der gleichen
Maschine anmelden kann. Man kann sich
fast sicher darauf verlassen, die gleiche Herausforderung zu
bekommen, und mit der mitgeschnittenen Antwort Zugriff zu erhalten.
Dies gilt selbstverst"andlich nur f"ur die Zugriffe, bei denen Windows
95 als Server benutzt wird. Und wer tut das schon?

Dieses Verfahren setzt voraus, da"s der Server "uber das
Benutzerpa"swort im Klartext verf"ugt. Unter Unix tut er das nicht,
sondern der Server kennt nur eine zerhackte Version des Pa"swortes,
den Wert aus der Datei \datei{/etc/shadow}.

Eine Hashfunktion, wie sie unter Unix eingesetzt wird, hat drei
Eigenschaften.

\begin{enumerate}

\item Sie ist leicht zu berechnen. Dies ist notwendig, damit die
Pa"swort"uberpr"ufung nicht zu lange dauert.

\item Sie ist nur sehr schwer umkehrbar. Das hei"st, aus dem zerhackten 
Pa"swort
ist das Klartextpa"swort nicht berechenbar. Als Beispiel f"ur eine
solche Einwegfunktion soll hier die Multiplikation
herhalten. 98453*34761=3422324733 ist relativ einfach zu
berechnen. Da"s die Zahl 3422324733 aus den beiden Ursprungszahlen
entstanden ist, ist schon sehr viel schwieriger herauszufinden. Es
gibt Verfahren, mit denen der R"uckweg ausgeschlossen ist\footnote{Wie
"uberall in der Kryptographie gilt dies auch nur so lange, bis jemand
den R"uckweg gefunden hat.}.

Mit dieser Eigenschaft war es zu rechtfertigen, da"s in den fr"uhen
Tagen von Unix die Hashwerte der Pa"sw"orter f"ur alle Benutzer lesbar
waren, da niemand daraus etwas ableiten konnte. Mit dem "Uberflu"s an
Rechenleistung kann man aber sogenannte crack-Programme verwenden, die
die erste Eigenschaft der Hashfunktion ausnutzen: Sie probieren
einfach tausende von Pa"sw"ortern pro Sekunde aus. Schlechte
Pa"sw"orter k"onnen so sehr schnell gefunden werden. Daher hat man die
Pa"sw"orter in die nicht allgemein lesbare Datei \datei{/etc/shadow}
ausgelagert.

\item Zwei verschiedene Pa"sw"orter f"uhren zu zwei verschiedenen
Hashwerten. Damit kann das Loginprogramm ausreichend sicher sein, da"s
ein korrekter Hashwert aus dem korrekten Pa"swort entstanden ist.

\end{enumerate}

Authentifizierung unter Unix setzt voraus, da"s der Client dem Server
das Klartextpa"swort pr"asentiert. Der Server kann daraus den Hashwert
berechnen, und mit dem gespeicherten Wert vergleichen. Leider verf"ugt
er nicht "uber das Klartextpa"swort des Benutzers, um das
Challenge-Response Verfahren durchf"uhren zu k"onnen. Daher mu"s unter
Samba f"ur die Pa"swortversch"usselung eine zweite Pa"swortdatenbank
gepflegt werden, die Datei \datei{smbpasswd}.

Auch in der Datei \datei{smbpasswd} stehen keine
Klartextpa"sw"orter. Bevor die Herausforderung mit dem Pa"swort
verschl"usselt wird, wird das Pa"swort unter Windows ebenfalls durch
eine Hashfunktion geschickt. Von dieser Hashfunktion gibt es zwei
Varianten, die beide nicht mit den unter Unix verwendeten Funktionen
"ubereinstimmen. Das hei"st, da"s man mit den dort enthaltenen Werten
so direkt nicht mehr anfangen kann als mit den Werten aus der Datei
\datei{/etc/shadow} unter Unix, denn wenn man sie als Pa"swort
eingeben w"urde, w"urde Windows sofort wieder den Hash darauf anwenden,
und einen anderen, also falschen Wert daraus errechnen. Das Programm
\prog{smbclient} mu"s diese Operation ebenfalls durchf"uhren, nur hat
man hierzu den Quellcode und kann die entsprechenden Stellen
auskommentieren. So hat man die M"oglichkeit, sich anhand der Werte in
der \datei{smbpasswd} ohne Einsatz von crack bei einem NT-Rechner
anzumelden.

Alles nicht dramatisch, sagt Microsoft. Das "Aquivalent zur Datei
\datei{smbpasswd} liegt unter NT verschl"usselt vor. Diese
Verschl"usselung mu"s jedoch reversibel sein, um das
Challenge-Response Verfahren durchf"uhren zu k"onnen. Ein Teil der
Sicherheitsargumentation liegt darin, da"s dieses
Verschl"usselungsverfahren nicht offengelegt wurde. Das Verfahren war
solange geheim, bis Jeremy Allison das Programm \prog{pwdump}
ver"offentlicht hat. Dieses Programm extrahiert aus der
Benutzerdatenbank von NT eine Datei, die direkt als \datei{smbpasswd}
verwendet werden kann\footnote{Allerdings nur f"ur Samba 1.9, zu 2.0
  hin wurde das Format ge"andert. Es gibt in Samba 2.0 aber ein
  Konvertierungsskript.}.

Das hei"st, der Administrator unter NT verf"ugt direkt "uber die
Pa"sw"orter aller Benutzer oder zumindest "uber etwas Gleichwertiges.
Damit hat er automatisch die M"oglichkeit, sich bei fremden Systemen
anzumelden, sofern dort das Pa"swort gleich ist. Bei Unix kann sich
der Administrator zwar in die Identit"at jedes Benutzers versetzen.
Dies bleibt aber auf das lokale System beschr"ankt, da er das Pa"swort
des Benutzers nicht kennt.

Sollte ein neugieriger Administrator einmal an den tats"achlichen
Pa"sw"orten seiner Benutzer interessiert sein, dann macht NT es ihm
deutlich einfacher als Unix dies tut. Unix verwendet sogenannte
versalzene Pa"sw"orter. Wenn ein Pa"swort ge"andert wird, dann wird
ein Zufallswert berechnet, dem Pa"swort hinzugef"ugt und dann die
Hashfunktion durchgef"uhrt. Der Zufallswert wird der Datei
\datei{/etc/shadow} im Klartext hinzugef"ugt, damit die "Uberpr"ufung
die gleichen Operationen durchf"uhren kann. So kann man keine Tabelle
von Pa"sw"ortern und den zugeh"origen Hashwerten anlegen. Man kann
auch nicht erkennen, wenn zwei Benutzer das gleiche Pa"swort
verwenden. Windows NT verwendet dieses Verfahren nicht.

Aus Kompatibilit"atsgr"unden mu"s NT auch noch zus"atzlich einen sehr
schlechten Hashwert mitf"uhren. Bei alten Windowsversionen konnte das
Pa"swort bis zu 14 Zeichen lang sein. War es k"urzer, wurde es mit
Leerzeichen aufgef"ullt. Dann wurde mit den ersten 7 Zeichen ein
Hashwert berechnet, und dann mit den zweiten 7 Zeichen. Das hei"st, es
sind sofort alle Pa"sw"orter erkennbar, die weniger als 7 Zeichen
haben, da die zweite H"alfte des Hashwertes immer gleich ist.

\section{Druckfreigaben}

Um Drucker unter Samba zur Verf"ugung zu stellen, m"ussen diese von
Unix aus ansprechbar sein. Unter Linux mit einem BSD-kompatiblen
Drucksystem geschieht dies durch Eintr"age in der Datei
\datei{/etc/printcap}. Alle Drucker, die dort definiert sind, kann man
als Netzwerkdrucker f"ur Windowsclients freigeben.

Unter Linux ist die Frage der Druckertreiber noch nicht
zufriedenstellend gel"ost. Druckertreiber unter Windows w"urde man
unter Linux nicht als solche bezeichnen. In der Linuxwelt sind Treiber
Softwaremodule, die direkt Hardware wie Netzwerkkarten oder den
parallelen Port ansprechen. Druckertreiber im Sinne von Windows sind
unter Linux sogenannte Filter, die Druckdaten in ein f"ur den Drucker
akzeptables Format aufbereiten. Das einheitliche Druckformat unter
Linux ist Postscript, das mit dem Programm Ghostscript in viele
druckereigene Formate umgewandelt werden kann. Druckertreiber unter
Windows gehen vom Windows Metafile-Format aus, und wandeln dies
entsprechend um. Das Windows Metafile-Format enth"alt Aufrufe an die
Graphische Komponente von Windows, das GDI.

Wenn man einen Drucker, der "uber Unix angesprochen wird, von Windows
aus nutzen m"ochte, mu"s man planen, wo die Aufbereitung in das
druckereigene Format geschehen soll. Zwei Wege sind denkbar.

\begin{itemize}
\item Auf den Arbeitspl"atzen wird ein generischer Postscripttreiber
  installiert. Die Clients m"ussen nicht wissen, welches Druckermodell
  sich hinter einer Freigabe verbirgt.  Die Umwandlung findet auf dem
  Druckerserver mittels \prog{ghostscript} statt.
\item Der Druckertreiber reicht die Daten weiter, ohne sie weiter zu
  behandeln. Auf den Arbeitspl"atzen werden f"ur jeden Netzdrucker die
  korrekten Treiber installiert.
\end{itemize}

Beide Wege haben Vor- und Nachteile. Im ersten Fall hat man weniger
Aufwand mit der Administration auf Clientseite. Man mu"s den korrekten
"`Druckertreiber"' nur einmal definieren, am Druckerserver.  Beim
zweiten Weg kann man die bessere Unterst"utzung der Druckerhersteller
f"ur die Windowsplattformen nutzen. Druckertreiber f"ur Windows bieten
in der Regel die M"oglichkeit, Sonderfunktionen wie die Auswahl des
Papierschachtes zu nutzen. Dieser erh"ohte Komfort zieht jedoch nach
sich, da"s auf jedem Client der korrekte Druckertreiber installiert
ist.

Nutzt eine Windows NT Workstation einen Drucker, der von einem Windows
NT Server freigegeben wurde, so gibt es noch die M"oglichkeit, die
Druckaufbereitung komplett vom NT Server vornehmen zu lassen, und
trotzdem s"amtliche Komfortfunktionen auf der Workstation zu nutzen.
Dazu mu"s auf der Workstation kein Druckertreiber installiert sein.
Diese sogenannten EMF-Druckerwarteschlangen kann Samba zur Zeit nicht
exportieren. Samba wird dies voraussichtlich auch nicht so schnell
erm"oglichen, da hierf"ur gro"se Teile von Windows, n"amlich das GDI,
auf Sambaseite implementiert werden m"u"ste.

Eine Druckfreigabe wird genau wie eine Dateifreigabe in einem eigenen
Abschnitt erstellt, wobei f"ur die Druckfunktion drei Optionen
notwendig sind:

\begin{verbatim}
[deskjet]
printable = yes
printer = lp
path = /tmp
\end{verbatim}

Zu einer Druckfreigabe wird die Definition durch die Angabe
\param{printable = yes}.

Mit der Option \param{printer =} wird festgelegt, welche
Druckerwarteschlange unter Unix angesprochen werden soll. Dieser
Drucker mu"s das Format verstehen, das vom Windowsdruckertreiber
geliefert wird. Also sollte hier entweder Postscript angenommen
werden, oder die Daten sollten per sogenannter Raw-Queue direkt ohne
Umwandlung an den Drucker weitergeleitet werden.

Die Option \param{path =} legt einen Spoolbereich fest. Ein Druckjob,
den ein Windowsrechner an Samba schickt, mu"s zun"achst in einer Datei
abgespeichert werden. Wenn diese Datei geschlossen wird, teilt der
Client dem Server mit, da"s diese nun zum Drucker geschickt werden
soll. Samba realisiert dies, indem das Programm \prog{lpr} mit der
Druckdatei als Argument aufgerufen wird. Samba mu"s also f"ur sich die
M"oglichkeit haben, Druckjobs in Dateien zu speichern, bevor sie an
den \prog{lpd} "ubergeben werden. Dies sollte nicht das
Spoolverzeichnis sein, das der \prog{lpd} selbst f"ur den Drucker
vorsieht.

\section{Samba als Logon-Server}

Wenn sich in einem Netz Windows 95/98 Clients befinden, kann es
w"unschenswert sein, da"s sich die Benutzer dieser Arbeitspl"atze nur
mit einem Pa"swort anmelden k"onnen, das zentral auf einem Server
vorgehalten wird. Dazu mu"s der entsprechende Server spezielle Aufrufe
von Clients entgegennehmen und korrekt beantworten. In der reinen
Windowswelt ist dazu ein Windows NT Server notwendig, der als
sogenannter Primary Domain Controller (PDC) installiert ist. Samba ist
ebenfalls in der Lage, dies zu tun. Dazu ist im Abschnitt
\param{[global]} der Parameter \param{domain logons = yes} zu setzen.
Die Implementation, die Microsoft gew"ahlt hat, um Dom"anenanmeldungen
zu erm"oglichen, erzwingt zus"atzlich, da"s der Domain Master Browser
auf dem gleichen Rechner liegt wie der Logon Server. Das hei"st, man
ben"otigt f"ur Dom"anenanmeldungen die folgenden Parameter:

\begin{verbatim}
[global]
workgroup = samba
domain logons = yes
domain master = yes
\end{verbatim}

Hat man diese Parameter gesetzt, kann man in den Eigenschaften des
Clients f"ur Microsoft-Netzwerke einstellen, da"s der Client sich an
der Dom"ane \texttt{samba} anmelden soll. Hat man verschl"usselte
Pa"sw"orter (Siehe Abschnitt \ref{passwoerter}) aktiviert, kann man
vom Client aus sein SMB-Pa"swort "andern, indem man das entsprechende
Kontrollfeld in der Systemsteuerung von Windows benutzt.

\section{Windows NT Dom"anen}

Die Dom"anenanmeldung unter Windows 95/98 ist eine relativ einfache
Sache, da es sich dabei praktisch nur um eine "Uberpr"ufung der
Benutzerpa"sw"orter handelt. So etwas wie Benutzer kennt Windows 95
praktisch nicht, jeder Benutzer hat vollen Zugriff auf das gesamte
System. Erst mit Windows NT hat Microsoft den Schritt hin zu einem
Betriebssystem gemacht, das Benutzerkonten und Zugriffsrechte
verwalten kann. Damit sind sie sehr viel weiter gegangen, als Unix
dies getan hatte. Um das Konzept der Windows NT Dom"ane zu
verdeutlichen, soll hier zun"achst auf das Konzept des Benutzers unter
Windows und unter Unix eingegangen werden.

Unter Unix besteht ein Benutzer im wesentlichen aus einer numerischen
Userid, und nicht mehr. Das Programm \prog{login} mu"s beim Anmelden
des Benutzers anhand seines Namens herausfinden, welche numerische
Userid er hat. Dazu sieht es in der Datei \datei{/etc/passwd} nach.
Mit der Datei \datei{/etc/shadow} pr"uft \prog{login} das Pa"swort.
Ist es korrekt, wird in die gefundene Userid umgeschaltet und die
Loginshell des Benutzers gestartet.  Nach diesem Vorgang ist es Unix
v"ollig egal, wie der Benutzer hei"st, das einzige, was interessiert,
ist der numerische Wert. Damit h"angt an jedem Proze"s eine endeutige
Identifikation der Rechte, die er hat.

Unter Unix ist es so, da"s Userids nur auf dem Rechner gelten, auf dem
sie zugeordnet wurden. Es gibt keine M"oglichkeit, Rechte von einem
Rechner auf den n"achsten zu "ubernehmen oder global Benutzer
zuzuordnen. Die einzige M"oglichkeit, die man zu Vereinheitlichung
hat, ist der Austausch der jeweils auf einem Rechner geltenden
Tabellen "uber verschiedene Rechner hinweg. Genau das tut NIS oder
Yellow Pages. Die Benutzerdatenbank wird verteilt, gilt aber auf jedem
Rechner rein lokal.

Unter NT sieht das sehr "ahnlich aus, nur da"s hier der Benutzer nicht
durch eine kleine Zahl, sondern durch einen Security Identifier SID
repr"asentiert wird. Ein solcher SID ist mehrteilig. Der erste Teil
dieses SID beinhaltet eine Kennung der Benutzerdatenbank, zu der
dieser Benutzer geh"ort. Ein solcher SID ist 96 Bit lang und Microsoft
behauptet, da"s dieser Wert zuf"allig genug gew"ahlt ist, da"s es
keine zwei Benutzerdatenbanken geben kann, die die gleiche SID haben.
Der zweite Teil besteht aus einem sogenannten Relative Identifier RID,
der den Benutzer innerhalb der Dom"ane eindeutig identifiziert. Die
Kennung f"ur die Dom"ane besteht aus 3 32-Bit Zahlen, die zusammen 96
Bit ergeben.

Unter Windows NT hat nun jeder Rechner eine eigene Benutzerdatenbank,
genau wie unter Unix. Da aber jede Benutzerdatenbank eindeutig
identifiziert ist, kann es keine zwei Benutzer mit gleicher Userid
geben. Der Relative Identifier mag gleich sein, der Identifier f"ur
die Benutzerdatenbank unterscheidet sich aber auf jeden Fall.

Microsoft unterscheidet verschiedene Netzwerkmodelle. Das Peer-To-Peer
Netz ist das Modell, das auch Unix zugrunde liegt. Hier hat jeder
beteiligte Rechner eine eigene Benutzerdatenbank, eigene Pa"sw"orter
und eigene Rechtezuordnungen. Das Dom"anenmodell ist das Modell, das
sich signifikant von Unix unterscheidet. Mit dem Dom"anenmodell wird
eine Workstation in die Lage versetzt, mehr als eine Benutzerdatenbank
zu benutzen. Neben der eigenen Benutzerdatenbank, die jede Workstation
hat, kann sie eine Benutzerdatenbank von einem anderen Rechner
importieren. In einer Windows NT Dom"ane gibt es einen Rechner, der
seine eigene Benutzerdatenbank anderen zur Verf"ugung stellt, den
sogenannten Primary Domain Controller. Dieser reserviert f"ur sich
spezielle NetBIOS-Namen, um sich den Workstations als Logonserver
anzubieten.  Eine Workstation befragt den Primary Domain Controller
nach allen relevanten Daten zu den Benutzern, die sich bei ihr
anmelden wollen, und die Rechte auf der Workstation wahrnehmen
k"onnen.

Die Kommunikation zwischen der Workstation und dem Primary Domain
Controller l"auft verschl"usselt ab. Um eine solche Verschl"usselung
zu erm"oglichen, mu"s ein gemeinsamer Schl"ussel vereinbart werden. Um
sich "uber einen Schl"ussel einig zu werden, gibt es spezialisierte
Protokolle, wie beispielsweise der Diffie-Hellmann
Schl"usselaustausch. Um jeglichen Problemen mit Patenten oder
Exportrestriktionen zu umgehen, ist Microsoft einen anderen Weg
gegangen.  Beim Schl"usselaustausch geht es im wesentlichen darum,
sich "uber ein gemeinsames Geheimnis einig zu werden. Um ein
gemeinsames Geheimnis zu wahren und zu pr"ufen, kennt Microsoft
bereits eine Gruppe von Protokollen: Die Protokolle zum Pr"ufen und
Austauschen von Benutzerpa"sw"ortern. Genau diese Protokolle werden
verwendet, um die Kommunikation zwischen PDC und Workstation zu
sichern. Daher mu"s jede Workstation explizit in die Dom"ane
aufgenommen werden.

Bei Samba ist es so, da"s es zu jedem Benutzer, der ein Pa"swort in
der \datei{/etc/smb.conf} hat, einen Benutzer im System geben mu"s.
Der zu einer Workstation geh"orende Benutzer mu"s den NetBIOS-Namen
der Workstation, erg"anzt um ein \$-Zeichen, haben. Man ben"otigt also
zwei Schritte, um eine Workstation in die Dom"ane aufzunehmen. Im
ersten Schritt wird der Unixbenutzer angelegt. Dies geschieht in
vielen Linuxsystemen mit dem Kommando \texttt{useradd -m $<$user$>$}.
Der angelegte Benutzer ben"otigt im Unixsystem weder ein Pa"swort noch
ein Heimatverzeichnis. Er ist notwendig, da die Workstation in der
Dom"ane eine eigene SID bekommt, die aus der Unix userid berechnet
wird. Dann mu"s die Workstation ein Pa"swort in der
\datei{/etc/smbpasswd} bekommen, und zwar mit dem Befehl
\texttt{smbpasswd -a -m name}. Ein Beispiel sieht folgenderma"sen aus:

\begin{verbatim}
root@erde: useradd -m wks\$
root@erde: smbpasswd -a -m wks
\end{verbatim}

Man beachte, da"s beim Befehl \texttt{useradd} ein Dollarzeichen,
maskiert durch den Backslash, hinzugef"ugt wurde. Der Befehl
\prog{smbpasswd} f"ugt diesen bei Verwendung des Parameters \prog{-m}
selbst hinzu.

\section{Samba als Dom"anenmitglied}

Mit dem Parameter \param{security} kann man den Zeitpunkt steuern, zu
dem das Benutzerpa"swort gepr"uft wird. \param{security = share} legt
fest, da"s die Pr"ufung beim Tree Connect stattfindet, das hei"st,
wenn die Freigabe angesprochen wird. Ist \param{security = user}
angegeben, wird das Pa"swort bereits einen Schritt vorher, also beim
Session Setup gepr"uft. Bei \param{security = user} wird also die
Kombination von Benutzer und Pa"swort gepr"uft bei \param{security =
  share} die Kombination Freigabe und Pa"swort.

Der Parameter \param{security} kann noch zwei weitere Werte annehmen:
\param{server} und \param{domain}.  Bei beiden Einstellungen verh"alt
sich Samba gegen"uber dem Client genau wie bei \param{security =
  user}, der Benutzer mu"s sich unter seinem Namen beim Server
authentifizieren. Die Unterschiede liegen in der Art und Weise, wie
das Pa"swort "uberpr"uft wird.

\begin{itemize}
\item \param{security = user}: Die "Uberpr"ufung findet anhand einer
  lokalen Datenbank statt. Werden Klartextpa"sw"orter verwendet
  (\param{encrypt passwords = no}), so wird die lokale
  Unix-Pa"swortdatenbank in \datei{/etc/passwd}, \datei{/etc/shadow}
  oder die entsprechende NIS-Tabelle herangezogen. Bei
  verschl"usselten Pa"sw"ortern mit wird die Samba-eigene
  Pa"swortdatenbank in der Datei \datei{smbpasswd} zur "Uberpr"ufung
  herangezogen.
\item \param{security = server}: Bei dieser Einstellung bekommt der
  Sambaserver vom Client einen Benutzernamen und ein Pa"swort
  pr"asentiert. Er versucht daraufhin, sich mit diesem Pa"swort bei
  einem weiteren Server anzumelden. Funktioniert dies, hat der
  Benutzer sein Pa"swort offensichtlich richtig eingegeben.  Schl"agt
  dies fehl, wird auch dem Client des Sambaservers der Fehler
  mitgeteilt und der Zugriff verweigert. Der Pa"swortserver, der zur
  "Uberpr"ufung herangezogen wird, mu"s mit seinem NetBIOS-Namen im
  Parameter \param{password server} angegeben werden.
\item \param{security = domain}: Auch hierbei wird die "Uberpr"ufung
  einem Pa"swortserver "uberlassen. Dieser mu"s jedoch ein Primary
  Domain Controller sein, der den Sambaserver in die Dom"ane
  aufgenommen hat. Der Hauptvorteil gegen"uber \param{security =
    server} besteht in einer deutlich reduzierten Last auf dem
  Pa"swortserver und einer verschl"usselten Kommunikation zwischen
  Samba und Pa"swortserver.
\end{itemize}

Um einen Windowsrechner dazu zu bringen, f"ur einen Sambaserver die
Pa"swort"uberpr"ufung zu "ubernehmen, mu"s man nur \param{security =
  server} und den \param{password server} passend setzen. Dabei
"ubernimmt der Server ausschlie"slich die "Uberpr"ufung der
Pa"s\-w"orter.  Bei verschl"usselten Pa"sw"ortern k"onnen Benutzer nur
dann in die \datei{smbpasswd} aufgenommen werden, wenn sie in der
Unix-Benutzerdatenbank existieren. Genau so verh"alt es sich bei
\param{security = server}. Benutzer k"onnen auf Samba nur dann
zugreifen, wenn sie als normale Unixbenutzer existieren.

\param{security = server} ist nicht die optimale L"osung f"ur die
"Uberpr"ufung von Pa"sw"ortern durch einen weiteren Rechner.

Um die Vorteile der Dom"anenmitgliedschaft zu nutzen, ist etwas mehr
Aufwand notwendig. Mitglied einer Dom"ane zu sein hei"st, mit dem
Primary Domain Controller "uber einen verschl"usselten Kanal
kommunizieren zu k"onnen. Diese Verschl"usselung wird verwendet, um
Benutzerinformationen verdeckt austauschen zu k"onnen. Als
Verschl"usselungsverfahren kommt ein symmetrisches oder auch secret
key Verfahren zum Einsatz. Um ein symmetrisches Verfahren anwenden zu
k"onnen, m"ussen sich beide Partner "uber ein gemeinsames Geheimnis,
den \emph{secret key} einig sein.  Ein solches gemeinsames Geheimnis
mu"s regelm"a"sig ge"andert werden, um einer gro"sen Klasse von
kryptographischen Angriffen auszuweichen. Eine solche "Anderung darf
selbstverst"andlich nicht abgeh"ort werden k"onnen, da ein Zuh"orer
damit die gesamte Kommunikation abh"oren kann. F"ur die "Anderung
eines Geheimnisses gab es bereits vor der Implementation des
Dom"anenprotokolls ein fertiges Protokoll, das man direkt verwenden
konnte: Die M"oglichkeit, Benutzerpa"sw"orter "uber das Netz zu
"andern, war mir einem gesicherten Protokoll implementiert. Um dieses
Protokoll zur verschl"usselten Kommunikation zwischen einer
Workstation oder einem Mitgliedsserver und dem Dom"anencontroller
nutzen zu k"onnen, mu"s es f"ur jedes Dom"anenmitglied ein
Benutzerkonto geben.  Genau dies wird auf dem Dom"anencontroller
erstellt, wenn man eine Workstation oder einen Server mit dem
Servermanager in die Dom"ane aufnimmt. Betritt man danach mit der
Workstation die Dom"ane, wird als erstes das Pa"swort des
Computerkontos ge"andert.

Um einen Sambaserver in eine Dom"ane aufzunehmen, sind zwei Schritte
notwendig.

\begin{itemize}
\item Auf dem Server mu"s der Sambaserver mit seinem NetBIOS-Namen in
  die Dom"ane aufgenommen werden.
\item Der Sambaserver selbst mu"s dar"uber informiert werden, da"s er
  sich in der Dom"ane befindet, und er mu"s sein Pa"swort "andern.
  Dies geschieht mit dem Befehl

\verb|smbpasswd -j DOM -r PDC|

Dabei steht \texttt{DOM} f"ur die Dom"ane, die betreten wird.  Mit
\texttt{PDC} wird der NetBIOS-Name des Dom"anencontrollers der Dom"ane
benannt.
\end{itemize}

Mit diesem Kommando wird das Maschinenpa"swort auf dem PDC auf einen
neuen, zuf"alligen Wert ge"andert. Dieses neue Maschinenpa"swort f"ur
den Samba Server wird in einer Datei im gleichen Verzeichnis wie die
Datei \texttt{smbpasswd} abgespeichert und hat folgenden Namen:

\verb|<NT DOMAENENNAME>.<Samba Servername>.mac|

Die Endung .mac steht f"ur \emph{Machine ACcount} Pa"swortdatei. Im obigen
Beispiel w"urde die Datei also \texttt{DOM.SERV1.mac} hei"sen.

Diese Datei wird von root erstellt und ist f"ur keinen anderen
Benutzer lesbar. Sie ist der Schl"ussel zu Ihrer Dom"anensicherheit
und sollte genau so vorsichtig behandelt werden wie die Datei
\texttt{/etc/shadow}.

Nach diesen beiden Schritten kann man mit \param{security = domain},
\param{password server = PDC BDC1 BDC2} und \param{encrypt passwords =
  yes} die Pa"swort"uberpr"ufung an einen der Dom"anencontroller
delegieren. Dies sind die Prim"aren und Backup Dom"anencontroller, die
Samba der Reihe nach kontaktieren wird, um Benutzer zu
authentifizieren. Samba wird sie in der aufgef"uhrten Reihenfolge
ansprechen. Sie k"onnen also die Reihenfolge ver"andern, um eine
g"unstigere Lastverteilung zu erreichen. Eine weitere Option ist die
Angabe \param{password server = *}. Damit sucht Samba mit den
Standardmethoden\footnote{Windows NT findet einen Dom"anencontroller,
  indem der NetBIOS-Name \nbname{DOMAIN<1C>} gesucht wird.} von
Windows NT nach einem Dom"anencontroller und befragt die Server, die
es bei dieser Anfrage herausbekommen hat.

Warum ist \param{security = domain} besser als \param{security =
  server}?

Der Vorteil der Dom"anensicherheit ist, da"s Samba die
Authentifizierung "uber einen gesicherten RPC Kanal schickt, genau wie
ein Windows NT Server es tun w"urde. Das hei"st, da"s Samba nun genau
wie ein Windows NT Server an einer Vertrauensstellung teilnehmen kann.
Das hei"st, Sie k"onnen einen Samba Server in eine Resourcendom"ane
aufnehmen, und Sie k"onnen die Authentifizierung via Resourcen PDC vom
PDC der Benutzerdom"ane vornehmen lassen.

Zus"atzlich mu"s in der Einstellung \texttt{security = server} der
Samba D"amon eine Verbindung zum Authentifizierungsserver w"ahrend
seiner gesamten Laufzeit offenhalten. Dies kann die Anzahl der offenen
Verbindungen auf einem Windows NT Server in die H"ohe treiben, so da"s
dieser keine Verbindungen mehr annimmt. Mit \texttt{security = domain}
verbinden sich die Samba D"amonen nur so lange mit dem PDC, wie es
f"ur die Benutzerauthentifizierung notwendig ist. Danach wird die
Verbindung wieder abgebaut, so da"s die Verbindungen wieder
anderweitig verwendbar sind.

Und nicht zuletzt bekommt der Samba Server als Teil der Antwort auf
die Authentifizierungsanforderung Informationen "uber den Security
Identifier, die Gruppenzuordnungen und andere Informationen "uber den
Benutzer. All diese Informationen werden Samba zuk"unftig erlauben, in
einem sogenannten Appliance Modus zu laufen. In diesem Modus wird
kein manuell angelegter Unixbenutzer mehr notwendig sein. Samba wird Unix
Benutzer und Gruppen aus der Authentifizierungsantwort des PDC
erzeugen. Damit wird Samba wirklich ein Plug and Play Mitglied einer
Dom"ane.

Dieser Appliance Modus kann heute schon ann"ahernd erreicht werden,
indem bei Samba der Parameter \param{add user script} angegeben wird.
In diesem Parameter wird ein Unixprogramm angegeben, das dynamisch
einen Unixbenutzer erzeugen mu"s, nachdem ein Pa"swortserver die
Korrektheit eines Pa"sworts best"atigt hat. Ein Beispiel kann sein:

\verb|add user script = /usr/bin/useradd -m %U|

Damit wird einfach ein Benutzer hinzugef"ugt, wenn er noch nicht
existiert, aber der PDC das Pa"swort best"atigt hat.

\end{document}