Im Artikel "Linux als Windows-Server mit Samba 3" haben wir ausgeführt, wie sich ein Linux-Rechner mit Samba 3 als Fileserver in Windows-Netzwerke integrieren lässt. So konfiguriert kann der beschriebene SuSE Linux-9.0-Samba-Server allerdings nicht mehr als ein normaler Windows-Client: Er stellt Verzeichnisse zur Verfügung, für deren Nutzung sich die User direkt bei ihm anmelden müssen.
Viel praktischer wäre es jedoch, wenn nur noch ein einziger Login für alle Rechner im Netz gelten würde. Kurz: eine Windows-Domäne mit zentralem Login-Server soll emuliert werden. Auch das kann Samba 3 leisten, indem es die Rolle eines primären Domänen-Controllers (PDC) im Windows-Netz übernimmt. Der vorliegende Workshop beschreibt die dazu notwendigen Konfigurationsarbeiten.
Erweiterung der Konfiguration
Um Samba 3 als PDC einzusetzen, müssen Sie als erstes einige Erweiterungen der bisherigen Konfiguration vornehmen und einige zusätzliche Shares freigeben. Beginnen wir mit der Konfigurationsdatei. Hier fügen Sie im Block [global] folgende Zeilen ein:
os level = 33
preferred master = yes
domain master = yes
local master = yes
security = user
domain logons = yes
wins support = yes
logon path = \\\\%N\\profiles\\%u
logon drive = X:
logon script = logon.cmd
logon home = \\\\%N\\%U\\profiles
Was bedeuten nun diese Befehle? Zunächst teilen sie dem Samba-Server mit, dass er als bevorzugter Master-Browser für alle Clients im Netz agiert (preferred master = yes). Das sorgt dafür, dass die Rechner im LAN diesen Samba-Server über Informationen zu Geräten und Anwendern befragen. Zusätzlich legen sie fest, dass der Samba-Server sowohl für die Domain (domain master = yes) wie auch für das lokale Subnetz (local master = yes) die Rolle des zentralen Informationsdienstes übernehmen soll.
Verwirrung schafft oft die Einstellung security = user. Viele Anwender glauben, dass über security = domain Samba zum Domain-Server aufsteigt. Genau das Gegenteil ist der Fall: Die "domain"-Variante weist Samba an, die Benutzerinformationen von einem anderen Server im Netz zu beziehen, also als reiner Server zu arbeiten.
Die Schlüsselwörter logon path, logon drive und logon script legen für die Login-Prozedur der Clients wichtige Parameter fest. Dazu zählt unter anderem, in welchem Verzeichnis die Profile zu finden sind. Die Einstellung für logon home gilt ausschließlich für Rechner unter Windows 9x/Me. Diese verwenden zum Auffinden ihrer Profile ein etwas anderes Verfahren als Windows NT, 2000, XP und 2003, weshalb der gesonderte Parameter notwendig ist. Dies gilt natürlich nur, falls in Ihrem Netz noch Rechner mit den Microsoft-Betriebssystemen der 9x-Generation vorhanden sind.
Zusätzliche Ressourcen
Zusätzlich benötigen Sie noch zwei weitere Ressourcen, deren Verzeichnisse bereits bei der Installation von SuSE Linux 9.0 angelegt wurden:
[netlogon]
path = /var/lib/samba/netlogon
read only = yes
write list = ntadmin
[profiles]
path = /var/lib/samba/profiles
read only = no
create mask = 0600
directory mask = 0700
Die beiden Ressourcen netlogon und profiles werden von der Login-Prozedur benötigt. In der Ressource netlogon suchen die Clients nach einem eventuell vorhandenen Startup-Skript, dessen Name die Option logon script festlegt. Zusätzlich können Sie hier Systemrichtlinien ablegen, die dann auf den angeschlossenen Clients implementiert werden.
Wichtig ist dabei, dass die Benutzer zumindest beim ersten Login, also dem Beitritt zur Domäne, Schreibrechte auf das Verzeichnis mit den Profilen erhalten. Nur so können die notwendigen Informationen dort hinterlegt werden. Um dies zu gewährleisten, ändern Sie die Zugriffsrechte einfach passend ab:
chmod 777 /var/lib/samba/profiles
Dafür dass trotz der so eingestellten Schreibrechte für jeden Benutzer die Sicherheit und Privatsphäre gewahrt bleiben, sorgen die beiden Parameter create mask und directory mask in der Ressourcen-Definition. So wie angegeben bewirken sie, dass nur der Benutzer in dem für ihn erstellten Verzeichnis Lese- und Schreibrechte erhält. Dies gilt für alle darin erstellten Dateien. Nicht einmal Mitglieder derselben Gruppe können Änderungen an den Daten vornehmen. Besonders unter SuSE Linux 9.0 ist das wichtig, da es jeden neuen Account automatisch der Einheitsgruppe users zuordnet.
Erzeugen der Maschinen-Accounts
Ein erster Versuch, nun der Domain MEINNETZ beizutreten, schlägt allerdings fehl. Ursache ist, dass für jeden Rechner in der Domäne eine eigene Vertrauensstellung bestehen muss. Mit anderen Worten: nicht nur der Benutzer, sondern auch der Rechner benötigt einen eigenen Account - und zwar bevor eine Aufnahme in die Domäne erfolgt. Am besten ist es, Sie richten eine eigene Benutzergruppe für die Rechner ein und nehmen den Client in dieser auf:
groupadd -g 300 clientpc
useradd -g clientpc -d /dev/null -s /bin/false TEST$
passwd -l TEST$
Mit diesen Befehlen erzeugen Sie eine Vertrauensstellung zwischen dem Samba-Server und dem Rechner, der zu der Domäne hinzugefügt werden soll. Bis dies nun geschieht, besteht potenziell die Möglichkeit für einen Angreifer, die eingerichtete Vertrauensstellung auszunutzen. Daher ist es besser, den Account für den Rechner von Samba quasi automatisch erzeugen zu lassen. Hierzu dient ein weiterer Eintrag in der Sektion [global] der Konfigurationsdatei /etc/init.d/smb.conf:
add machine script = /usr/sbin/useradd -d /dev/null -g clientpc -s /bin/false %u
Beachten Sie, dass Sie die Gruppe zur Aufnahme der Rechner-Accounts trotzdem von Hand anlegen müssen.
Domain-Funktionen testen
Um die Domain-Funktionen zu testen, integrieren Sie nun probehalber einen Windows-Rechner in die Domäne. Rufen Sie dazu die Eigenschaften des Icons "System" in der Systemsteuerung ab, wählen dort den Reiter "Computername" und klicken auf die Schaltfläche "Ändern". In der Rubrik "Mitglied von" der folgenden Maske aktivieren Sie den Radio-Button "Domäne" und geben als Wert "MEINNETZ" - oder entsprechend den von Ihnen in der Samba-Konfiguration gewählten Wert für das Schlüsselwort workgroup - in das Eingabefeld ein.
Nach einer kurzen Wartezeit fragt das System nach einer Kennung mit Administratorrechten in der Domäne. Geben Sie hier als Benutzernamen "root" an, nicht wie sonst von Windows gewohnt "Administrator". Als Passwort verwenden Sie dasselbe, das dem Root-Benutzer auf dem Linux-Rechner zugeteilt wurde.
Back to the
Es folgt wiederum eine kurze Bedenkzeit, während der auf dem Samba-Rechner die Accounts eingerichtet und die notwendigen Änderungen an den Benutzerdatenbanken vorgenommen werden. Schließlich erscheint ein kleines Fenster, das den Erfolg der Aktion signalisiert.
Nun ist ein Neustart des Windows-Rechners erforderlich. Unter Windows XP erhalten Sie schon beim Hochfahren eine optische Rückmeldung über den neuen Status des Rechners als Domänenmitglied: Der normale Anmeldebildschirm ist der von Windows NT und 2000 bekannten Maske mit der Aufforderung gewichen, den berühmten Affengriff (Strg+Alt+Entf) zum Aufruf der Anmeldung durchzuführen.
Fehlanzeige: Windows XP Home
Wer nur Rechner unter Windows XP Home sein eigen nennt, wird allerdings keinen Erfolg haben, diese in eine Domäne zu integrieren. Die Fähigkeit, als Mitglied an einer Domäne teilzunehmen, zählt zu den Features, die Microsoft nur den Profi-Betriebssystemen mit auf den Weg gibt - und dazu zählt Windows XP Home nun einmal nicht.
Zwar kursieren im Internet diverse Anleitungen, wie sich doch eine Domain-Mitgliedschaft unter Windows XP Home erreichen lässt. Doch diese Beschreibungen sind in aller Regel fehlerhaft oder beinhalten das Austauschen diverser XP-Home-DLLs mit denen von Windows XP Professional. Ob letzteres Vorgehen legal ist, ist zu bezweifeln.
Server-Tuning
Für viele Anwender ist es wichtig, dass sich der Samba-Server im Netz tatsächlich wie ein echter Windows-Server verhält. Dazu gehört unter anderem auch, dass sich der Administrator mit dem gleichnamigen Benutzerkonto und nicht als Root anmeldet. Um dies zu erreichen, müssen Sie auf dem Samba-Server die Datei /etc/samba/smbusers editieren. Dabei handelt es sich um eine einfache Textdatei, mit der sich Beziehungen zwischen lokalen Linux-Accounts und vom Anwender angegebenen Benutzernamen herstellen lassen.
Um etwa die Windows-typischen Benutzernamen Administrator, Admin und NTAdmin auf den Root-Anwender zu mappen, verwenden Sie folgende Zeile:
root = Administrator Admin NTAdmin
Als chronische Problemquelle erweist sich, dass viele Windows-Anwender nicht daran gewohnt sind, auf Groß- und Kleinschreibung beim Benutzernamen achten zu müssen. Linux und damit auch Samba legen hier wesentlich strenger Maßstäbe an, was gerne zur Häufung von Support-Anfragen führt.
Dem können Sie aus dem Weg gehen, indem Sie den Samba-Server anweisen, bei der Prüfung der Benutzernamen (und eventuell auch der Passworte) etwas legerer vorzugehen. Tragen Sie dazu die beiden folgenden Befehle in der Sektion [global] der Samba-Konfigurationsdatei ein:
password level = 3
username level = 16
Diese beiden Kommandos bewirken, dass Samba beim Anmeldevorgang neben dem eigentlich eingegebenen Usernamen und Passwort auch andere Kombinationen prüft. Dazu verändert es für maximal die hinter dem jeweiligen Schlüsselwort angegebene Anzahl von Zeichen deren Schreibweise. So würde etwa für das angegebene Passwort "geheim" zusätzlich geprüft, ob mit den Kombinationen "Geheim", "GEheim", "GEHeim", "gEheim", und so weiter ein erfolgreicher Login möglich ist. Gleiches gilt für den User-Namen, nur dass hier bis zu 16 aufeinander folgende Zeichen in ihrer Schreibweise geändert werden.
Beachten Sie, dass dies nicht nur immens Rechenzeit kosten kann, sondern auch gewaltig auf die Sicherheit Ihres Netzwerks drückt. Gerade beim Schlüsselwort password level sollten Sie daher genau überlegen, ob Sie es wirklich einsetzen wollen.
Alternative User-Datenbank
Bislang verwaltet der vorgestellte Samba-Server alle Benutzerdaten in reinen Textdateien. Für kleinere Netze taugt dies als eine übersichtliche und auch leidlich effektive Vorgehensweise. In großen Netzen mit einer Vielzahl von Anwendern werden die Textdateien jedoch schnell zum Flaschenhals. Als Ausweg bietet Samba die Speicherung der Daten in verschiedenen Datenbankformaten an. Dazu gehört neben MySQL und LDAP auch das Format der Berkeley-Datenbank, die mit so gut wie jeder Distribution ausgeliefert wird.
Um auf dieses Datenbankformat umzustellen, ist lediglich ein zusätzliches Schlüsselwort in der Sektion [global] der Konfigurationsdatei des Samba-Servers erforderlich:
passdb backend = tdbsam
Nach einem Neustart des Sambaservers per /etc/init.d/smb restart ist die neue Account-Verwaltung auf Datenbank-Basis aktiv. Allerdings werden die bereits in der Datei /etc/samba/smbpasswd vorhandenen Benutzerkonten bei dieser Aktion nicht übernommen. Sie müssen die existierenden Accounts manuell mithilfe des Befehls smbpasswd -a [account] in die neue Datenbank übernehmen. Als Lohn der Mühe winkt eine deutlich schnellere Benutzerauthentifizierung, die sich schon bei kleineren Netzen bemerkbar macht.
Access Control Lists
Ein Feature, das viele Anwender beim Umstieg vom Windows- auf den Samba-Server vermissen, ist die Möglichkeit, auch den Zugriff auf einzelne Dateien zu beschränken. Von Haus aus bietet Samba ja nur die Option, Zugang zu den Daten abhängig von Benutzerkennung oder Gruppenzugehörigkeit zu regeln. Für die wesentlich feiner granulierte Rechtevergabe unter Windows zeichnen die so genannten Access Control Lists (ACL) verantwortlich. Dabei handelt es sich im Prinzip um Tabellen, in denen für jede Datei und jedes Verzeichnis hinterlegt ist, welche Benutzer welche Zugriffsmöglichkeiten besitzen.
Auch für Linux existiert ein entsprechendes, wenngleich weitgehend unbekanntes System: die Posix-ACLs. Mit ihrer Hilfe kann auch ein Samba-Server die unter Windows verfügbaren Rechte auf Dateien bieten. Voraussetzung dafür ist jedoch, dass die Posix-ACLs beim Erstellen des Kernels aktiviert wurden und das verwendete Dateisystem Posix-ACLs unterstützt. Während der Standard-Kernel von SuSE Linux 9.0 Posix-ACLs unterstützt, hat SuSE bei der Wahl des bevorzugten Dateisystems einen echten Bock geschossen: Das im Normalfall als Vorgabe verwendete ReiserFS ist nicht in der Lage, mit Posix-ACLs zu arbeiten.
Wer also einen Samba-Server unter SuSE Linux 9.0 aufsetzen möchte, der sollte gleich bei der Installation darauf achten, das verwendete Dateisystem von ReiserFS auf Ext3 umzustellen. Letzteres bietet sowohl Support für Posix-ACLs wie auch ein Transaktions-Log, um bei einem Systemabsturz den ursprünglichen Zustand des Dateisystems wieder herstellen zu können.
ACL-Support aktivieren
Es genügt jedoch nicht, einen Bereich der Festplatte mit dem Dateisystem Ext3 zu formatieren, um automatisch Access Control Lists verwenden zu können. Sie müssen die ACL-Unterstützung explizit aktivieren. Um dies beispielsweise für die unter /share gemountete Partition mit den Freigaben zu erreichen, dient folgender Befehl:
mount -o remount,acl,defaults /share
Den Erfolg des Kommandos überprüfen Sie durch einen Aufruf von mount ohne jedweden Parameter. Hinter dem Eintrag des Mount-Punkts /share sollte sich nun der Bezeichner (rw,acl) statt des üblichen (rw) finden.
Damit Sie diese Operation nicht jedes Mal auf der Kommandozeile vornehmen müssen, empfiehlt es sich, den Parameter acl gleich in die Datei /etc/fstab zu übernehmen. Die entsprechende Zeile sieht für den Mount-Punkt /share so aus:
/dev/hdb1 /share ext3 acl,defaults 0 0
Je nachdem, welcher Partition auf welcher Festplatte /share bei Ihnen entspricht, sieht der erste Parameter anders aus. Wichtig ist nur, dass Sie das Schlüsselwort acl vor dem Bezeichner defaults einfügen. Richten Sie dies für alle Mount-Punkte ein, für die Sie ACLs zur Verfügung stellen wollen. Starten Sie anschließend den Samba-Server neu.
Zugriffsrechte festlegen
Wenn Sie jetzt auf einem Windows-Rechner per Klick mit der rechten Maustaste die Eigenschaften eines Verzeichnisses oder einer Datei auf einer Freigabe abrufen, können Sie dort über den Reiter "Sicherheit" erweiterte Zugriffsrechte festlegen.
Klicken Sie dazu die Schaltfläche "Erweitert". Sie gelangen zu einem Dialog, über den Sie weitere Berechtigungen hinzufügen sowie bestehende ändern oder auch löschen können.
Heimtückisch ist, dass Ihnen diese Dialoge auch dann zur Verfügung stehen, wenn der Samba-Server ACLs nicht unterstützt! Feststellen können Sie dies nur dadurch, dass Sie nach jeder Änderung kontrollieren, ob diese auch tatsächlich übernommen wurde. Das sollte auch Ihre erste Maßnahme bei der Fehlersuche im Zusammenhang mit ACLs sein: Feststellen, ob das entsprechende Verzeichnis - oder besser: die Partition auf der sich dieses befindet - überhaupt ACLs unterstützt und ob deren Einsatz auch aktiviert wurde.
Verteilte Dateisysteme einrichten
Gerade in größeren Netzen ist es ratsam, den zentralen Domänen-Controller zwar als Anmelde-Server zu verwenden, ihn aber nicht zusätzlich auch noch mit der Aufgabe des Fileservers zu belasten. In Windows-Netzen lässt sich dies mithilfe der Funktion des Distributed File Systems (DFS) erreichen. Dabei bietet der Server lediglich virtuelle Links zu einzelnen Ressourcen an, über welche die Clients auf die eigentlichen Fileserver und die dort freigegebenen Verzeichnisse zugreifen. Dieses Verfahren lässt sich auch mit einem Samba-Server einsetzen.
Dazu fügen Sie in der Sektion [global] der zentralen Konfigurationsdatei ein weiteres Schlüsselwort ein und definieren zusätzlich eine neue Ressource:
host msdfs = yes
[dfsroot]
path = /var/lib/samba/exports/dfsroot
msdfs root = yes
valid users = +users
Über diese Einstellungen weisen Sie Samba an, als Host für ein verteiltes Dateisystem nach Microsoft-Standard zu fungieren. Gleichzeitig definieren Sie eine für diese Aufgabe notwendige Ressource. Der in deren Definition enthaltene Befehl msdfs root = yes weist Samba an, den Inhalt des über das Schlüsselwort spezifizierten Verzeichnisses auf besondere Weise zu interpretieren. Diese Inhalte sowie das Verzeichnis selbst müssen Sie allerdings zunächst manuell anlegen:
mkdir -p /var/lib/samba/exports/dfsroot
cd /var/lib/samba/exports
chmod 755 dfsroot
cd dfsroot
ln -s msdfs:server1\\ \\ressource1 link1
ln -s msdfs:server2\\ \\ressource2 link2
ln -s msdfs:server3\\ \\ressource3,server4\\ \\ressource4 link3
Die letzten drei Befehle erzeugen symbolische Links, die auf andere Server in der Domäne verweisen.
Für den Client sieht die Freigabe dfsroot zunächst wie ein normales Verzeichnis aus. Beim Zugriff auf die (für den Anwender als Unterverzeichnisse dargestellten) Links wird der Client aber auf die jeweils angegebenen Server weitergeleitet und bezieht seine Daten von dort. Voraussetzung dafür ist natürlich, dass er über die passenden Zugriffsrechte verfügt und die Zielserver die Authentifizierung über den PDC, also den Samba-Server, vornehmen.
Fazit
Wie Sie sehen, lässt sich mit Samba 3 nahezu der komplette Funktionsumfang eines Windows-Servers abdecken. Selbst anspruchsvolle Funktionen wie die Arbeit als Domänen-Controller oder das Bereitstellen von verteilten Dateisystemen bereitet dem Open-Source-System keine Probleme.
Einzig die Erstinstallation erweist sich als etwas aufwändig: Es sind zugegebenermaßen einige Stolperschwellen zu überwinden. Mit den Informationen aus diesem Workshop sind Sie aber gut gerüstet, ein funktionsfähiges Windows-Netz mithilfe von Samba auf die Beine zu stellen. Viel Spaß damit! (jlu)