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