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