Samba und SMB

Samba und SMB

Inhalt

1. Die Geschichte von Samba

2. Der Sinn und Zweck von Samba

3. Das Server-Message-Block Protokoll (SMB)

3.1 Das SMB-Sicherheitskonzept

3.2 Namensauflösung unter NetBIOS

3.3 Browser-Dienste

3.4 Das Domänenkonzept von Windows

4. Linux als Client in SMB Netzen

4.1 Auf Dateien zugreifen

4.2 Auf Drucker zugreifen

5. Linux als Server in SMB Netzen

5.1 Möglichkeiten und Einschränkungen

5.2 Grundlegende Unterschiede zwischen Unix und Windows

5.3 Anlegen einer Benutzerdatenbank

5.4 Berechtigungen für Freigaben

5.5 Domänenintegration

5.6 Benutzerprofile für Windows Clients

1. Die von Geschichte Samba

Wie viele andere (Unix-) Software auch, entstand Samba durch die Hand eines Programmierers, der ein Problem hatte und dieses löste, indem er einfach mal schnell ein

Programm schrieb In diesem Fall war der Programmierer ein Australier namens Andrew Tridgell, dessen Problem darin bestand, dass er mit seinem DOS Rechner auf den Plattenplatz seines Unix-Servers zugreifen wollte. Das allein wäre nicht das Problem gewesen, vielmehr die Tatsache, dass er ein Programm nutzen wollte, das die NetBIOS Schnittstelle verlangte. Also untersuchte er mit einem (natürlich selbstgeschriebenen) Packet-Sniffer das von Microsoft verwendete SMB-Protokoll und implementierte dieses unter Unix. Er erschuf damit ein Programm, dass es ermöglichte, via NetBIOS Schnittstelle von DOS aus auf freigegebene Verzeichnisse des Unix-Servers zuzugreifen. In 1992 veröffentlichte er den Quelltext des Programms erstmals, kümmerte sich dann jedoch nicht mehr sonderlich um das Projekt, bis er 2 Jahre später erstaunt feststellte, dass es sogar möglich war, den Windows-PC seiner Frau mit seinem Linux-System zu verbinden. Als er den Code weiter verbessern wollte (Andrew hatte inzwischen festgestellt, dass das Protokoll sogar dokumentiert war), bekam er jedoch Rechtsschwierigkeiten wegen des Namens, den er für seine Software gewählt hatte und war gezwungen sich einen neuen auszudenken. Also suchte er einfach in einer Rechtschreibprüfung nach allen Wörtern, in denen die Buchstaben SMB vorkommen und wurde schließlich mit Samba fündig. Heute ist Samba eine in der Unix-Welt sehr bekannte Kollektion von Programmen, die dazu dienen, zwischen Windows und Unix zu vermitteln. Der Funktionsumfang wächst ständig an, so dass Samba mittlerweile sogar erheblich mehr kann, als nur Verzeichnisse und Drucker freizugeben bzw. anzusprechen, doch dazu später mehr. Das Samba Projekt wird, wie viele Open-Source Projekte, von Leuten in der ganzen Welt mitentwickelt, die einfach nur Spaß daran haben, Software zu schreiben, die gut und stabil läuft und frei verfügbar ist. Samba ist mittlerweile so bekannt, dass Firmen wie z.B. SilliconGraphics ihre professionellen Produkte mit Samba bündeln. Einer der besten Hinweise auf Sambas Erfolg ist wohl die Tatsache, dass Samba in Microsofts 'Halloween Documents " Erwähnung fand, einigen internen Memos, bei denen die Gefahr von Open-Source Software (besonders Linux) für die kommerziellen Microsoftprodukte festgestellt wurde.

2. Der Sinn und Zweck von Samba

Sambas Aufgaben und Fähigkeiten sind im Einzelnen:

Bereitstellung von und Zugriff auf Datei- und Druckdienste

Authentifizierung und Autorisation

Namensauflösung

Bekanntmachung von Diensten (Verwaltung von Browselisten)

Die ersten beiden Aufgaben werden von dem Programm smbd erledigt, die letzten zwei vom Programm nmbd.

Bereitstellung von Datei- und Druckdiensten

Samba stellt auf dem Unix Server, auf dem es läuft, Plattenplatz und Drucker in Form von Freigaben (Shares) bereit, die dann z.B. Windows Clients nutzen können. Samba dient somit als File- und Printserver. Auf der anderen Seite ist es mit Samba möglich, auf freigegebene Ressourcen im Netz zuzugreifen und somit z.B. den Drucker eines Windows-Rechners anzusprechen.

Authentifizierung und Autorisation

Beim Bereitstellen von Shares sind zusätzlich verschiedene Konzepte der Zugriffsberechtigungen möglich: Zur Authentifizierung und Autorisation gibt es insgesamt vier verschiedene Sicherheitsmodi.

Namensauflösung und Bekanntmachung von Diensten

Namensauflösung und Bekanntmachung von Diensten dienen beide der Verwaltung (Erstellung und Aktualisierung) und der Verteilung von NetBIOS Namen und Ressourcen in einem LAN. Samba enthält Funktionen, die es erlauben, die Aufgabe eines Primären Domänen Controllers (PDC) zu übernehmen. Damit ist es möglich, dass sich Windows Clients am Samba Server anmelden, da eine zentralisierte Benutzerdatenbank und Homeverzeichnisse für wandernde Profile (Roaming Profiles) zur Verfügung stehen.

3. Das Server-Message-Block Protokoll (SMB)

SMB (Server Message Block) ist ein Protokoll, das es erlaubt Festplattenplatz, Drucker und serielle Ports zwischen mehreren Computern zu teilen.

Das Protokoll wurde 1985 von IBM entworfen, um als Netzwerkprotokoll für kleinere lokale Netze zu dienen. 1987 griffen Microsoft, Intel und andere Firmen das Protokoll erneut auf und entwickelten es ständig weiter, weshalb heute eine Vielzahl an unterschiedlichen Varianten des SMB-Protokolls existiert.

Zunächst basierte SMB auf dem von IBM entwickelten NetBIOS (Network Basic Input and Output System), eine Softwareschnittstelle, die auf Netzwerktransportprotokollen (wie z.B. IPX) aufsetzt.

NetBIOS unterscheidet die Namen der einzelnen Clients und ihrer Applikationen durch einen 16 Byte langen Namen. Microsoft erweiterte sein Betriebssystem MS-DOS bald so, dass es möglich wurde, Dateizugriffe an das NetBIOS Interface weiterzuleiten, was es ermöglichte Plattenplatz über das Netzwerk zu nutzen.

Das hierbei benutzte Protokoll wurde als SMB bezeichnet.

Das NetBIOS API wurde von immer mehr Applikationen genutzt und auf immer mehr Netzwerkprotokollen (IPX, NetBEUI, DECnet und TCP/IP) implementiert.

Das NetBEUI (NetBIOS Enhanced User Interface) Protokoll ist lediglich eine einfache Kapselung der NetBIOS Frames, das die einzelnen Pakete mit Hilfe der MACAdresse der Netzwerkkarten adressiert, und somit nicht routingfähig ist. Damit die auf NetBIOS basierenden, bestehenden Applikationen auch in gerouteten Netzwerken genutzt werden können, entwickelte man eine Implementation für TCP/IP, genannt Net-BIOS über TCP/IP (bei Microsoft auch gelegentlich NBT oder NetBT, aber auch RFCNB).

Dieser Mechanismus, der eine Übersetzung der NetBIOS Namen in IP-Nummern leisten muss, wird, ebenso wie weitere Details zu NetBIOS, in den RFCs 1001 und 1002 beschrieben, weitere Informationen zu NetBIOS in Bezug auf Samba finden sich in der Samba Dokumentation.

Wenn man SMB unter TCP/IP nutzt (eine Vorraussetzung für den Betrieb von Samba), wird also in Wirklichkeit NetBIOS über TCP/IP benutzt.

SMB ist, wie z.B. http auch, ein client-server, request-response Protokoll. Wenn die Clients sich über ein Netzwerkprotokoll wie z.B. TCP/IP mit dem Server verbunden haben, können sie Kommandos zum Server schicken, die es ihnen erlauben, auf Freigaben zuzugreifen, und diese wie ein eigenes Dateisystem (das auch geschützt sein kann) zu behandeln.

3.1 Das SMB Sicherheitskonzept

Im SMB-Protokoll sind grundsätzlich zwei verschiedene Sicherheitsmodi definiert, sharelevel und user-level. In Samba gibt es zusätzlich noch zwei weitere Modi, die eine Erweiterung des user-level Modus darstellen. Im Folgenden die Erklärung der verschiedenen Modi, die in dieser Weise (security = Modus) auch als Parameter in der Samba-Konfigurationsdatei zu finden sind.

share: share mode bedeutet, dass jede Freigabe nur durch ein Passwort geschützt ist, also für jeden nutzbar, der das Passwort kennt.

user: user mode bedeutet, dass der Server den Client bei der Anmeldung (beim ersten Zugriff auf irgendeine Ressource) nach einem Namen und Passwort fragt, und daran feststellt, ob ein solches Konto existiert und das zugehörige Passwort stimmt (Authentifizierung). Ist der Benutzer einmal authentifiziert, erhält er eine UID (User ID) und hat nun prinzipiell die Möglichkeit, auf alle Ressourcen zuzugreifen, was in der Praxis jedoch durch die Berechtigungen für die einzelnen Shares verhindert werden kann (Autorisation). Dieser Modus ist dem einfacheren share mode vorzuziehen, wenn man unterschiedliche Rechte für unterschiedliche Benutzer festlegen will.

server: server mode gleicht dem user mode, mit der Ausnahme, dass Samba Namen und Passwort an einen anderen Server weiterreicht, der dann den Benutzer authentifiziert. Kann Samba sich erfolgreich am Passwort Server anmelden, lässt es auch die Anmeldung des Clients zu. Dies kann dazu dienen, mehrere SMB-Server mit nur einer Benutzerdatenbank zu betreiben.

domain: domain mode gleicht ebenfalls dem user mode, mit der Ausnahme, dass die Authentifizierung an einem Domänencontroller stattfindet, weshalb hier auch der Rechnername überprüft wird (es muss ein Computerkonto für diesen Rechner in der Domäne existieren).

3.2 Namensauflösung unter NetBIOS

Es gibt zwei Arten von Namensauösung.

Broadcast

NBNS

Broadcast

Die ursprüngliche Methode für einen Client einen Rechnernamen im LAN zu finden ist, dass er einen Broadcast mit der Anfrage ins Netz schickt, und der entsprechende Rechner sich dann mit seiner MAC- bzw. IP-Adresse meldet.

NBNS

Die zweite Methode ist die Nutzung eines NetBios Name Service Servers (NBNS), bei Microsoft WINS (Windows Internet Name Service) genannt. Hierbei senden die Clients ihren Namen und ihre Adresse an diesen Server bzw. werden diese fest in einer Datenbank eingetragen. Dann können sich die einzelnen Clients bei Namensanfragen an diesen Server wenden, um von ihm die Adressen ihrer Partner erfragen.

Vorteile von NBNS:

Funktioniert über Subnetze hinweg

Reduziert die Netzbelastung durch Einsparung von Broadcasts

Somit ähnelt das NBNS/WINS Konzept dem des DNS.

Es ist allerdings mehr auf eine dynamische Verwaltung ausgerichtet, was Konflikte nach sich ziehen kann, da jeder Rechner über einen Cache verfügt, der diese Zuordnungen eine Zeit lang speichert und außerdem jeder Rechner dem WINS Server Angaben machen kann.

3.3 Browser-Dienste

Die sogenannten Browselisten dienen dazu, dass sich der Benutzer einen Überblick darüber verschaffen kann, welcher Rechner welche shares im Netz zur Verfügung stellt, also die

Liste, die man in Windows unter 'Netzwerkumgebung " finden kann.

Die Erstellung und Verwaltung dieser Browselisten übernimmt in einem LAN ein sogenannter Lokaler Master Browser (LMB), der zuvor durch eine Abstimmung aller Clients bestimmt wird.

Zusätzlich zu den LMBs gibt es noch Domänen Master Browser (DMB), die die Browselisten einer ganzen Domäne (also auch über Subnetze hinweg) verwalten.

Die LMBs und die DMBs tauschen ihre gesammelten Daten aus, zusätzlich werden diese Listen nochmals an alle Clients im Netz verteilt, was dazu führt, dass es bis zu einer Stunde dauern kann, bis sich Aktualisierungen herumgesprochen haben.

3.4 Das Domänenkonzept von Windows

Der Hauptgrund für den Einsatz von Windows-Servern in Netzwerken, ist der Wunsch eine zentrale Benutzer- und Clientverwaltung für Windows-Rechner zu haben.

Microsoft hat dazu das sogenannte Domänen Konzept eingeführt.

Der Unterschied zu der bis dahin existierenden Arbeitsgruppe besteht darin, dass eine Arbeitsgruppe mehrere Computer zusammenfasst, die alle ihre jeweiligen Sicherheitsinformationen selbst verwalten, während bei einer Domäne hingegen die Sicherheitsinformationen zentralisiert auf den sogenannten Domänen Controllern festgehalten und verwaltet werden.

Es gibt immer genau einen Primären Domänencontroller (PDC) und kann einen oder mehrere Backup Domänencontroller (BDC) geben.

Die Daten werden normalerweise am PDC verwaltet und dann automatisch auf die BDCs repliziert, die ebenfalls Anmeldewünsche entgegennehmen und so die Last aufteilen.

Weitere Vorteile dieses Konzeptes sind, dass es bei Ausfalles eines Servers keinen Totalausfall des Netzes gibt, da ein BDC bei Ausfall eines PDCs auch zum PDC heraufgestuft werden kann, so dass trotzdem immer eine zentrale Datenbank besteht.

Die Sicherheitsinformationen in der Datenbank enthalten unter anderem die Computerkonten, die Benutzereinträge, die verschlüsselten Passwörter, die erlaubten Anmeldezeiten, die Gruppeninformationen und die Rechte, die die einzelnen Benutzer bzw.

Gruppen haben.

4. Linux als Client in SMB-Netzen

Auch wenn Windows als Desktop-Betriebssystem eine höhere Verbreitung besitzt, gibt es auch Netzwerke mit Linux Clients. Sind heterogene Netze von Windows dominiert, basieren also auf SMB, muss es für Linux Möglichkeiten geben, auf SMB-shares zuzugreifen.

Im Folgenden will ich jedoch nur kurz die Möglichkeiten hierfür aufgreifen und jeweils auf weitere Quellen verweisen, da sich dieses Dokument mehr mit der Verwendung von Samba als Server für Windows beschäftigen will als umgekehrt.

Unter Linux lässt sich im Kernel unter 'Filesystems " SMB aktivieren.

Das Paket smbfs dient zum mounten von shares, wodurch der Zugriff auf Dateien so einfach wird, wie auf lokale Dateien.

Die Programme des Pakets nutzen jedoch nicht die Funktionalität, die Samba bietet. Sie generieren z.B. keine Browselisten, was zur Folge hat, dass man den Namen des shares, auf das man zugreifen will, immer genau wissen muss.

Abhilfe schafft die Nutzung des im Samba Paket enthaltenen Programms smbclient. Dieses Tool bietet zunächst eine FTP-ähnliche Schnittstelle, mit deren Hilfe man auf die Dateien im Netz zugreifen kann und erlaubt außerdem auch die Nutzung eines freigegeben Druckers an einem Windows Rechner.

4.1 Auf Dateien zugreifen

smbclient kennt eine Reihe von Parametern, darunter auch:

-L <servername>: Gibt die share-Liste eines Servers aus

//<servername>/<sharename>: Verbindet mit einem share. Mit dem zusätzlichen Argument -U <benutzername> kann man sich unter einem anderen Benutzernamen verbinden.

Ist man angemeldet, stehen Kommandos wie get, put und dir zur Verfügung. Eine Liste aller Befehle kann mit der Eingabe von h ausgegeben werden.

4.2 Auf Drucker zugreifen

Um einen an einen Windows-PC angeschlossenen Drucker unter Linux nutzen zu können, muss dieser einen Eintrag in der Datei /etc/printcap sowie eine Gerätedatei haben und die dazugehörigen Spool- und Loggverzeichnisse.

Ein Filterskript wird im Sambaarchiv unter examples/printing/smbprint mitgeliefert.

5. Linux als Server

Im diesem Kapitel wird beschrieben, wie man Samba als Fileserver einsetzt und eine Domäne aufbaut, an der sich Windows-Clients anmelden können.

5.1 Möglichkeiten und Einschränkungen

Samba bietet viele Features, die es erlauben es nicht nur als File- und Printserver, sondern auch als Anmeldeserver einzusetzen. Dabei kann man sogar so weit gehen, Samba als PDC zu nutzen, an dem sich ein Windows-Client anmelden, und ein benutzerspezifisches Profil herunterladen kann.

Wegen der prinzipiellen Unvereinbarkeit von Windows und Unix gibt es allerdings noch eine Menge Funktionen, die in Samba noch nicht oder nur teilweise implementiert sind. So gibt es z.B. bei den folgenden Punkten noch Schwierigkeiten bzw. Einschränkungen:

Die Verwaltung von Samba über die Windows-Werkzeuge: Da etliche Remote Procedure Calls (RPCs) noch nicht implementiert sind, lässt sich der Sambaserver weder mit dem Benutzermanager für Domänen (Benutzerverwaltung), noch mit dem Server Manager (Computerkonten), noch mit dem Explorer (Berechtigungen für Dateien und Freigaben) verwalten.

Replikation für BDCs: Man kann keine Server (Windows oder Samba) als BDCs einrichten, da die Replikationsmechanismen hierfür fehlen.

Benutzerlisten für bestimmte Freigaben: In Samba gibt es noch keine Möglichkeit, sich Benutzerlisten für bestimmte Ressourcen anzeigen zu lassen und diese gezielt zu manipulieren. Dies lässt sich nur indirekt über die smb.conf realisieren.

Des weiteren gilt es beim Einsatz von Samba als PDC zu beachten, dass man viele Verwaltungsprogramme für Domänen, die für den Windows-Server existieren, nicht nutzen kann, wie z.B. den Systems Management Server (SMS).

Meiner Meinung nach ist Samba eine sinnvolle Alternative, wenn es entweder um kleine Netze geht, die eine zentrale Benutzerverwaltung und Roaming Profiles haben sollen oder um Unixnetze, in denen auch Windows Clients mit eben diesen Möglichkeiten genutzt werden sollen.

Ansonsten macht Samba lediglich als reiner File- und Printserver Sinn, da man mit Linux ein günstiges, Hardwaresparendes und gut skalierbares System erhält, dass sich in Punkto Leistung in jedem Fall mit dem Windows-Server messen kann und in Punkto Stabilität und Administrationsmöglichkeiten diesen sogar übertreffen kann.

Soll Samba als Fileserver dienen, so stellen sich für den Rechner auf dem es läuft keine besonders hohen Hardwareanforderungen (jedenfalls solange er nur als Fileserver dient), es ist jedoch sinnvoll den Rechner aufgrund der guten Erweiterbarkeit und Performance (Beschleunigung durch Parallelzugriffe und im allgemeinen geringfügig schnellere Platten) als SCSI System aufzubauen.

5.2 Grundlegende Unterschiede zwischen Unix und Windows

Bei der Entwicklung von Samba gilt es, mehrere grundlegende Unterschiede zwischen Windows und Unix zu bedenken, die eigentlich für eine Unvereinbarkeit der beiden Betriebssystemwelten sprechen.

Einer der wichtigsten Unterschiede sind die Zugriffsrechte auf Dateiebene. Während unter Unix hierfür die Dateiattribute, die für die Benutzer bzw. die Gruppen gelten, zuständig sind, existieren unter Windows sogenannte Access Control Lists (ACL) die separat gemanagt werden (z.B. über den Explorer bzw. den Benutzermanager).

Neben den Dateiattributen sind auch die Dateinamen und der Zeitstempel in DOS/Windows und Unix unterschiedlich, weshalb man Samba dementsprechend konfigurieren muss

Windows und DOS wurden nicht für lange Dateinamen konzipiert, Windows verwaltet nach wie vor zwei Namen, einen langen nach außen und einen achtstelligen nach innen.

Unix kann von Haus aus Dateien mit langen Namen und gemischter Groß- und Kleinschreibung verwalten, daher muss eine Konvertierung stattfinden.

Samba ist von Haus aus so eingestellt, dass es mit den Eigenheiten der Systeme umgehen kann und z.B. nicht zwischen Groß- und Kleinschreibung unterscheidet. Deshalb muss Samba dann immer eine Suche nach passenden Namen durchführen, falls ein Windows Client z.B. eine Datei namens 'hallo " anfordert, die aber in Wirklichkeit 'Hallo " heißt.

Ein weiterer Unterschied besteht in der Art Passwörter zu verschlüsseln. Windows und Unix arbeiten zwar beide nach dem Prinzip der 'Einweg-Verschlüsselung ", dennoch ist der Verschlüsselungsalgorithmus unterschiedlich, und das bedeutet, dass Samba ein Windows-Passwort nicht mit einem Unix-Passwort abgleichen kann.

Will man die verschlüsselte Passwortübertragung verwenden, macht dies eine eigene Datenbank für Samba Accounts erforderlich.

5.3 Anlegen einer Benutzerdatenbank

Will ein Windows Benutzer einen eigenen Zugang haben, muss er zunächst auch als Linuxbenutzer einen Eintrag in der datei /etc/passwd haben.

Soll sich der Benutzer nur per SMB-Client am Samba Rechner anmelden können und nicht unter Linux, genügt es, seine Shell auf '/bin/false " zu setzen, zusätzlich kann man ihm die Eingabe eines gültigen Passworts durch Setzen dieses auf z.B.  "-1' unmöglich machen.

Die Benutzerzuordnung findet entweder über den Benutzernamen statt oder über eine Zuordnungsdatei, welche einen oder mehrere Windows Benutzer auf einen Unix Account mappt. Kann man auf eigene Profile bzw. Passwörter für einzelne Benutzer verzichten, so trägt man in einer Datei, deren Name und Pfad in der smb.conf durch den Parameter 'username map " festgelegt wird, z.B. Folgendes ein:

root = administrator

pitti = 'Peter Schmidt'

schueler= alexander, carsten, sabrina, mario

Nun kann man ihm mit dem Programm smbpasswd einen Samba Account erzeugen bzw. dessen Passwort ändern.

Passwörter können verschlüsselt werden, jedoch zur Authentifizierung nicht entschlüsselt. Stattdessen wird das Passwort bei der Eingabe auch verschlüsselt und das Chiffrat mit dem abgespeicherten Passwortchiffrat (Fingerprint) verglichen.

5.4 Berechtigungen für Freigaben

Wie bei Windows kann man für den Zugriff auf Freigaben bestimmte Benutzer mit unterschiedlichen Rechten ausstatten. Allerdings müssen hierfür sowohl die Unix- als auch die Sambaberechtigungen aus der smb.conf stimmen. Unter Samba sind hierfür folgende Parameter zuständig:

writeable - yes/write ok - yes/read only - no: Hier hat man die Wahl zwischen drei Parametern, die alle die gleiche (bei read only invertierte) Bedeutung haben. Der Parameter bestimmt, ob ein Verzeichnis generell zum Schreiben (Erzeugen und ändern von Dateien/Verzeichnissen) freigegeben ist oder nicht. Wird das share auf schreibgeschützt gesetzt, kann es mit der write list für bestimmte Benutzer wieder zum Schreiben freigegeben werden. Die Voreinstellung lautet 'writeable -no ".

valid users/invalid users: Hiermit kann man eine Liste der Benutzer angeben, die überhaupt Zugriff auf das share haben, bzw. keinen Zugriff haben. Gruppen lassen sich mit einem vorangestellten '@' kennzeichnen ('valid users - @schueler "). Der Standardwert ist jeweils eine leere Liste, was zur Folge hat, dass jeder zugreifen kann.

read list: Mit der read list lässt sich angeben, wer Dateien/Verzeichnisse eines shares lesen kann. Gruppen können ebenfalls angegeben werden. Der Standardwert ist eine leere Liste, jeder kann lesen.

write list: Hiermit kann ein share nur für bestimmte Benutzer schreibbar gemacht werden. Ist ein Benutzer auch in der read list, erhält er hierdurch trotzdem Schreibrechte. Gruppen lassen sich ebenfalls angeben. Der Standardwert ist auch hier eine leere Liste, also jeder kann schreiben. Durch Kombination dieser Parameter lassen sich relativ genau bestimmte Benutzer/Gruppen festlegen bzw. gezielt ausschließen.

Beim Erstellen von Dateien und Verzeichnissen muss festgelegt sein, welche Berechtigungen diese haben.

Dazu dienen die Parameter 'create mask " und 'force create mode " für Dateien, und 'directory mask " und 'force directory mode " für Verzeichnisse. Ebenso lassen sich die Besitzverhältnisse der Dateien mit den Parametern 'force group " und 'force user " festlegen.

Auf einem Fileserver wird man in der Regel drei Arten von shares haben:

Homeverzeichnisse

Teamverzeichnisse

Öffentliche Verzeichnisse

Für alle Freigaben gilt, dass die Unixrechte der Freigaben (und der darüber liegenden Verzeichnisse) den Einträgen in der smb.conf entsprechen müssen, was normalerweise bedeutet, dass die Rechte mit denen Werten von 'create mask " und 'directory mask " übereinstimmen müssen, und alle Verzeichnisse darüber das Ausführbit (wechseln) für alle gesetzt haben.

5.5 Domänenintegration

Will man eine windowskompatible Domäne aufbauen, kommt man wegen des Sicherheitskonzeptes (SID, Security Identifier, eine eindeutige Benutzerkennung, die sowohl der Server als auch jeder Client besitzt) nicht umhin, ein Computerkonto für jeden PC anzulegen. Dieses entspricht, bis auf kleine Abweichungen, einem normalen Benutzerkonto. Zunächst ist es nötig, in der Datei /etc/passwd einen Benutzer mit dem Namen der Workstation und einem angehängten $ Zeichen zu erstellen. Dies ist nur nötig, um eine UID zu erhalten, deshalb sollten diese auch nicht mehrfach verwendet werden. Die Shell und das Homeverzeichnis können disabled werden:

BART$:801:800:NT Workstation:/dev/null:/bin/false

MAGGIE$:802:800:NT Workstation:/dev/null:/bin/false

Nun werden die Sambakonten angelegt. Standardmäßig hat der Computer ein Passwort, das seinem NetBIOS-Namen in Kleinschreibung entspricht. Dieses ändert er, wenn er der Domäne beitritt, indem er auf Basis des alten Keys und eines Zufallswertes ein neues Passwort erstellt. Deshalb muss man, will man den PC neu in die Domäne aufnehmen, das Passwort der Maschine am Server reseten, z.B. durch Löschen und Neuaufnehmen des Accounts in die smbpasswd. Falls noch nicht geschehen, muss man nun in der smb.conf die Option 'domain logons - yes " setzen, und als 'workgroup " den Namen der Domäne eintragen.

Beim nächsten Starten des smbd wird dann eine Datei namens MACHINE.SID erzeugt, die gut aufbewahrt werden sollte, wenn man abgeneigt ist alle Computer neu in die Domäne aufzunehmen.

Nun muss man an der Windows Maschine in den Netzwerkeigenschaften als Domäne den Namen der Domäne eintragen und wird dann hoffentlich in dieser Willkommen geheißen.

Nach einem Neustart kann man sich dann an der Domäne anmelden, natürlich nur mit einem gültigen Domänenmitgliedsaccount (Samba Benutzer). Durch die Aufnahme in die Domäne sind auf dem lokalen PC zwei weitere Benutzergruppen hinzugefügt wurden, die Domänenadmins " und die 'Domänenbenutzer ". Welche Unix Benutzer/Gruppen diesen Gruppen angehören, regeln die Parameter 'domain admin group " bzw. 'domain admin user " und 'domain group ".

Natürlich kann ein Samba Server auch einer bereits existierenden Domäne beitreten, er braucht dann lediglich ein Konto auf dem PDC (Samba oder Windows) und dann kann auf Wunsch auch die Passwortvalidierung an Windows-Server weiterreichen. Das Kommando hierzu lautet smbpasswd -j Domänenname und bedingt folgende Einstellungen in der smb.conf:

security = domain

workgroup = 'GCL-Schule'

# Liste der Domänencontroller (PDC und BDCs)

password server = NTPDC, NTBDC1, NTBDC2

5.6 Benutzerprofile für Windows Clients

Benutzerprofile sind sowohl Einstellungen eines Benutzers (z.B. Hintergrundbild) als auch seine persönlichen Ordner (z.B. das Startmenü) und Dateien (Eigene Dateien, Desktopsysmbole).

Bei der Verwendung von wandernden Profilen erhält jeder User an jedem PC, an dem er sich anmeldet, das gleiche Profil, das beim Abmelden auf den Server zurückgespeichert wird. Die Profile liegen auf einem share namens 'Profiles ", das wiederum im netlogon Pfad liegt. Mit dem Parameter 'logon path " gibt man den Pfad zum Profiles share an, das man ebenfalls in der smb.conf definiert hat.

Wegen eines Problems mit Windows ist es nicht sehr ratsam das Profil im Homeverzeichnis eines Benutzers abzulegen.

Es empfiehlt sich deshalb, ein separates share 'Profiles " anzulegen. Dieses share muss sowohl browseable als auch writeable für alle Benutzer sein, solange neue Benutzerprofile dazukommen sollen. In der Beispielkonfiguration unten ist auch ein Beispiel für das Profiles share zu finden. Wenn sich der Benutzer zum ersten Mal anmeldet, wird sein Profilverzeichnis erzeugt, das durch den 'logon path " angegeben wurde. Für Windows-Clients ist der Parameter 'logon drive " sinnvoll, besonders in Verbindung mit dem Parameter 'logon home ". Folgende Einstellungen bewirken, dass der Benutzer beim Anmelden sein Unix-Homeverzeichnis als Laufwerk p: gemountet bekommt:

logon drive = p:

logon home =  " "%L "%U

Bestehende Profile lassen sich von Windows aus über die Systemeigenschaften (Reiter Benutzerprofile) auch nachträglich in servergespeicherte Benutzerprofile umwandeln, was z.B. die Umstellung von Arbeitsgruppen auf Domänen unter Beibehaltung der Profile möglich macht.