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