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