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