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