mirror of
https://github.com/samba-team/samba.git
synced 2025-01-14 19:24:43 +03:00
4857 lines
213 KiB
TeX
4857 lines
213 KiB
TeX
\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}
|