[Kapitel 6] 6.3 Authentifizierung, Security

6.3 Authentifizierung, Security

An dieser Stelle sollten wir besprechen, wie Samba User authentifiziert. Jeder User, der versucht sich mit einer Share zu verbinden, die keinen Gastzugang gestattet, muss ein Passwort liefern, um eine erfolgreiche Verbindung zu tätigen. Was Samba mit diesem Passwort tut - und die Strategie wird Samba demzufolge benützen, um sich mit der User-Authentifizierung zu befassen - ist die Bühne der Konfigurations-Option security. Es gibt derzeit vier Security-Level, die Samba in seinem Netzwerk unterstützt: share, user, server, und domain.

Share-level security: Jede Share in der Arbeitsgruppe hat ein oder mehr Passwörter, die mit ihr assoziiert sind. Jeder, der ein gültiges Passwort für die Share kennt, kann darauf zugreifen.
User-level security: Jede Share in der Arbeitsgruppe ist für den erlaubten Zugriff von bestimmten Usern eingerichtet. Am Anfang jeder Baum-Verbindung verifiziert der Sambaserver die User und ihre Passwörter, um ihnen Zugang zur Share zu gestatten.
Server-level security: Das ist dasselbe wie die User-Level Security, außer dass der Sambaserver einen eigenen SMB-Server verwendet, um User und ihre Passwörter zu bestätigen, bevor er Zugriff zur Share gewährt.
Domain-level security: Samba wird ein Mitglied einer Windows-Domäne und verwendet den Primary Domain Controller (PDC) der Domäne, um die Authentifikation durchzuführen. Einmal bestätigt, erhält der User ein spezielles Zeichen, das ihm oder ihr erlaubt, auf jede Share mit passenden Zugangsrechten zuzugreifen. Angesichts dieses Zeichens braucht der PDC das Passwort des Users nicht jedes Mal wieder zu bestätigen, wenn er oder sie versucht, auf eine andere Share in der Domäne zuzugreifen.

Jedes dieser Sicherheits-Verfahren kann mit der globalen Option security durchgeführt werden, siehe Tabelle 6.3.

Tabelle 6.3: Option Security
Option	Parameter	Funktion	Vorgabe	Bereich
`security`	`domain`, `server`, `share`, oder `user`	Bezeichnet den Security-Typ, den der Sambaserver verwenden wird.	`user` (Samba 2.0) oder `share` (Samba 1.9)	Global

6.3.1 Share-level Security

Bei der Share-level Security hat jede Share ein oder mehr Passwörter, die mit ihr assoziiert sind. Das unterscheidet sich von den anderen Security-Modi darin, dass es hier keine Beschränkungen gibt, wie etwa wer auf eine Share Zugang hat, solange die Person das korrekte Passwort kennt. Shares haben oft mehrere Passwörter. Zum Beispiel könnte ein Passwort Read-Only-Zugang gewähren, während ein anderes Schreib/Lese-Zugriff gestatten könnte und so weiter. Die Sicherheit bleibt aufrecht, solange unbefugte User nicht das Passwort für eine Share entdecken, zu der sie keinen Zugriff haben sollten.

OS/2 und Windows 95/98 unterstützen beide Share-level Security in ihren Ressourcen. Du kannst die Share-level Security mit Windows 95/98 einrichten, indem du zuerst in der Netzwerkumgebung die Eigenschaften und hier das Register Zugriffssteuerung wählst. Dann wähle den Radiobutton Zugriffssteuerung auf Freigabeebene (der den Radiobutton Zugriffssteuerung auf Benutzerebene ausschaltet), siehe Figur 6.1, und drücke OK.

Figur 6.1: Share-level Security auf einer Windows-Maschine wählen

Als Nächstes klick rechts auf eine Ressource - wie eine Festplatte oder eine CD-ROM - und wähl das Eigenschaften-Menü! Es erscheint die Eigenschaften-Dialogbox. Wähl den Punkt Freigabe... und dann den Tab Freigabe oben in der Dialogbox und kennzeichne die Ressource als "Freigegeben als". Hier kannst du konfigurieren, wie die freigegebene Ressource einzelnen Usern erscheinen wird, sowie festlegen, ob die Ressource Read-Only, Read-Write oder gemischt erscheint, abhängig vom unterstützten Passwort.

Du magst denken, dass dieses Sicherheitsmodell für Samba nicht gut geeignet ist - und du würdest recht haben. Tatsächlich, wenn du in der Samba-Konfigurationsdatei die Option security = share einstellst, wird Samba nach wie vor die Username/Passwort-Kombinationen in den System-Passwortdateien wieder verwenden, um den Zugriff zu authentifizieren. Genauer gesagt, wird Samba die folgenden Schritte unternehmen, wenn ein Client unter der Verwendung der Share-level-Security eine Verbindung verlangt:

Wenn eine Verbindung verlangt wird, akzeptiert Samba das Passwort und (wenn er gesendet wird) den Usernamen des Clients.
Wenn die Share guest only ist, wird dem User sofort Zugang zur Share gewährt, mit den Rechten für den User, die vom Parameter des guest account festgelegt wurden, eine Passwort-Prüfung wird nicht durchgeführt.
Für andere Shares fügt Samba den Usernamen an eine Userliste, die auf die Share zugreifen darf. Dann versucht es, das Passwort zu bestätigen, welches in Zusammenhang mit diesem Usernamen übergeben wurde. Bei Erfolg gewährt Samba dem User Zugang zur Share mit den Rechten dieses Users. Der User braucht sich nicht wieder zu authentifizieren, außer wenn eine Option revalidate = yes innerhalb der Share gesetzt wurde.
Ist die Authentifikation erfolglos, versucht Samba das Passwort gegenüber der Userliste zu bestätigen, die es vorher während der Verbindungsversuche kompilierte sowie irgendeines unter der Share in der Konfigurationsdatei festlegte. Wenn das Passwort mit keinen Usernamen übereinstimmt (wie in der System-Passwortdatei, üblicherweise /etc/passwd, eingetragen), erhält der User unter diesem Usernamen keinen Zugang zur Share.
Wenn aber die Share eine Option guest ok oder public eingerichtet hat, ist dem User vorgegeben, mit den Rechten des von der Option guest account beschriebenen Users zuzugreifen.

Du kannst in der Konfigurationsdatei hinweisen, welche User von Beginn an auf der Share-level-Security Userliste stehen, indem du die Konfigurationsoption username verwendest, wie hier gezeigt wird:

[global]
	security = share
[accounting1]
	path = /home/samba/accounting1
	guest ok = no
	writable = yes
	username = davecb, pkelly, andyo

Wenn hier ein User einen Verbindungsversuch zu einer Share unternimmt, verifiziert Samba das Passwort, das direkt an jeden User in der Liste gesendet wurde, zusätzlich zu dem Passwörtern der User davecb, pkelly, und andyo. Wenn eines der Passwörter passt, wird die Verbindung bestätigt, und der User wird zugelassen. Andernfalls schlägt die Verbindung zu der bestimmten Share fehl.

6.3.1.1 Share Level Security Optionen

Tabelle 6.4 zeigt die Optionen, die typischerweise mit der Share-level-Security in Zusammenhang stehen.

Tabelle 6.4: Share-Level Zugriffs-Optionen
Option	Parameter	Funktion	Vorgabe	Bereich
`only user`	boolean	Zeigt, ob Usernamen, von der Option `username` festgelegt, als einzige zugelassen sind.	`no`	Share
`username`(einer oder mehrere)	string (Liste mit Usernamen)	Bezeichnet eine Userliste, der gegenüber das Passwort eines Clients geprüft wird.	Keine	Share

6.3.1.2 only user

Diese Boolean-Option zeigt, ob Samba Verbindungen zu einer Share zulässt, die Share-level-Security verwendet, einzig für Personen, die in der Option username genannt sind, anstatt für die User, die auf Sambas interner Liste kompiliert sind. Der vorgegebene Wert für diese Option ist no. Du kannst ihn pro Share abändern wie folgt:

[global]
    security = share
[data]
    username = andy, peter, valerie
    only user = yes

6.3.1.3 username

Diese Option übergibt eine Liste von Usern, gegenüber denen Samba ein Verbindungs-Passwort prüft, um den Zugriff zu erlauben. Sie wird typischerweise bei Clients mit Share-level-Security verwendet, um Verbindungen zu einem bestimmten, allein auf einem geeigneten Passwort beruhenden Dienst zu erlauben - in diesem Fall einer, der einem Passwort entspricht, das für einen bestimmten User eingerichtet wurde:

[global]
    security = share
[data]
     username = andy, peter, terry

Wir plädieren gegen eine Verwendung dieser Option, außer du richtest einen Sambaserver mit Share-level-Security ein.

6.3.2 User-level Security

Der bevorzugte Modus bei Security mit Samba ist user-level security. Bei dieser Methode wird jede Share bestimmten Usern zugewiesen, die auf sie zugreifen können. Wenn ein User Verbindung zu einer Share verlangt, authentifiziert ihn Samba durch Bestätigung des eingegebenen Usernamens samt Passwort mit den berechtigten Usern in der Konfigurationsdatei und den Passwörtern in der Passwort-Datenbank auf dem Sambaserver. Wie in dem Kapitel früher erwähnt, gibt es eine Möglichkeit, zu unterscheiden, welche User berechtigten Zugang zu einer bestimmten Share erhalten, indem die Option valid users für jede Share verwendet wird:

[global]
	security = user
[accounting1]
	writable = yes
	valid users = bob, joe, sandy

Jeder der angeführten User darf sich mit der Share verbinden, wenn das eingegebene Passwort mit dem in der System-Passwort-Datenbank auf dem Server gespeicherten Passwort übereinstimmt. Sobald die Authentifikation zu Beginn gelingt, muss der User ein Passwort nicht wieder eingeben, um Zugang zu dieser Share zu erhalten, außer die Option revalidate = yes wurde gesetzt.

Passwörter können entweder in verschlüsselter Form oder unverschlüsselt an den Sambaserver gesendet werden. Wenn du beide Typen von Systemen in deinem Netzwerk hast, solltest du dafür sorgen, dass die von jedem User vertretenen Passwörter in einer traditionellen Zugangs-Datenbank und in Sambas Datenbank für verschlüsselte Passwörter gespeichert werden. Auf diese Weise können sich berechtigte User von jedem Clienttyp aus Zugang zu ihren Shares verschaffen.[1] Nun, wir empfehlen, dass du dein System auf verschlüsselte Passwörter umstellst und unverschlüsselte Passwörter aufgibst, wenn Sicherheit gefragt ist. Der Abschnitt 6.4 dieses Kapitels erklärt, wie verschlüsselte sowie unverschlüsselte Passwörter verwendet werden.

[1] Der Besitz von verschlüsselten und unverschlüsselten Passwort-Clients auf deinem Netzwerk ist ein anderer Grund, warum Samba dir erlaubt, verschiedene Optionen in die Samba Konfigurationsdatei aufzunehmen (oder nicht aufzunehmen), gestützt auf das Client-Betriebssystem oder Maschinennamen-Variablen.

6.3.3 Server-level Security

Server-level Security ist User-level Security ähnlich. Nun, bei Server-level-Security delegiert Samba die Passwort-Authentifikation an einen anderen SMB-Passwort-Server, typischerweise ein anderer sambaserver oder ein Windows NT-Server, der als PDC im Netzwerk agiert. Beachte, dass Samba noch sein Verzeichnis für Shares und deren Konfiguration in seiner smb.conf-Datei beibehält. Wenn ein Client eine Verbindung zu einer einzelnen Share versucht, bestätigt Samba, dass der User wirklich berechtigt ist, die Share zu kontaktieren. Samba versucht dann, das Passwort mittels einer Kontaktaufnahme beim SMB-Passwortserver zu bestätigen. Das geschieht durch ein bekanntes Protokoll und durch Vorlage des Usernamens und des Passworts beim SMB-Passwortserver. Wenn das Passwort akzeptiert wird, wird eine Sitzung mit dem Client eingerichtet. Siehe Figur 6.2 zur Illustration dieses Setups.

Figur 6.2: Ein typisches System-Setup unter der Server-level Security

Du kannst Samba so konfigurieren, dass es einen eigenen Passwortserver unter Server-level-Security mit der Verwendung der globalen Konfigurationsoption password server benützt, wie folgt:

[global]
	security = server
	password server = PHOENIX120 HYDRA134

Beachte, dass du mehr als eine Maschine als Angabe zu password server festlegen kannst; Samba sieht im Verzeichnis der Server in dem Fall nach, wenn seine erste Wahl unerreichbar ist. Die von der Option password server identifizierten Server sind unter den NetBIOS-Namen bekannt, nicht unter ihren DNS-Namen oder den äquivalenten IP-Adressen. Wenn außerdem einer der Server das eingegebene Passwort ablehnt, schlägt die Verbindung automatisch fehl - Samba wird keinen anderen Server versuchen.

One caveat: Wenn du diese Option verwendest, wirst du noch einen Account brauchen, der diesen User auf dem regulären Sambaserver vertritt. Das deswegen, weil das Unix Betriebssystem einen Usernamen zur Durchführung verschiedener I/O-Operationen braucht. Die vorzuziehende Methode dies durchzuführen, ist, dem User einen Account auf dem Sambaserver zu geben, aber das Passwort des Accounts auszuschalten, indem es in der System-Passwortdatei (z.B. /etc/passwd ) durch einen Asteriskus (*) ersetzt wird.

6.3.4 Domain-level Security

Domain-level Security ist Server-level Security ähnlich. Nun, bei Domain-level Security agiert der Sambaserver als ein Mitglied einer Windows-Domäne. Erinnere dich an Kapitel 1, dass jede Domain einen Domain-Controller besitzt, der gewöhnlich ein Windows NT-Server ist und die Passwort-Authentifikation anbietet. Einschließlich dieser Controller versorgt er die Arbeitsgruppe mit einem definitiven Passwort-Server. Die Domain-Controller bewahren die Spur der User und Passwörter in ihrem eigenen Security Authentication Modul (SAM) auf und authentifizieren jeden User, wenn er oder sie zum ersten Mal einloggt und auf die Share einer anderen Maschine zuzugreifen wünscht.

Wie früher in diesem Kapitel bemerkt, hat Samba eine ähnliche Fähigkeit, User-level-Saecurity anzubieten, aber diese Option ist Unix-zentral und setzt voraus, dass die Authentifikation via Unix-Passwortdateien geschieht. Wenn die Unix-Maschine Teil einer NIS oder NIS+ Domain ist, authentifiziert Samba die User transparent gegenüber einer freigegebenen Passwortdatei in typischer Unix-Fasson. Samba verschafft dann Zugang zur NIS oder NIS+ Domäne durch Windows. Es besteht natürlich keine Beziehung zwischen dem NIS-Konzept einer Domäne und dem Windows-Konzept einer Domäne.

Mit der Domain-level Security haben wir nun die Option für die Benützung des nativen NT-Mechanismus. Das hat eine Menge Vorteile:

Es bietet weit bessere Integration bei NT: es gibt weniger "kludges" in den smb.conf-Optionen, die mit Domains arbeiten, als mit den meisten Windows-Features. Das erlaubt einen umfangreicheren Gebrauch der NT-Management-Tools, wie der User Manager für Domains, der PCs erlaubt, Einzelne zu unterstützen, Sambaserver als große NT-Maschinen zu betrachten.
Mit der besseren Integration gehen Protokoll- und Code-Säuberungen einher, die dem Sambateam erlauben, die Entwicklung der NT-Ausführung zu verfolgen. Das NT-Service-Pack 4 verbessert einige Probleme im Protokoll, und Sambas bessere Integration macht es leichter, diese Änderungen aufzuspüren und einzubauen.
Es entstehen weniger Unkosten auf dem PDC, weil eine weniger permanente Netzwerkverbindung zwischen ihm und dem Sambaserver besteht. Im Gegensatz zum Protokoll, das von der Option security = server verwendet wird, kann der Sambaserver einen Remote Procedure Call (RPC) aufrufen, nur wenn er eine Information zur Authentifikation braucht. Er kann eine Verbindung nicht dauernd nur dafür aufrechterhalten.
Schließlich retourniert das NT-Domain Authentifikations-Schema den vollen Satz der User-Attribute, nicht nur Erfolg oder Fehler. Die Attribute enthalten eine längere, mehr Netzwerk-orientierte Version der Unix-UID, NT-Gruppen und anderer Information. Das umfasst:
- Username
- Voller Name
- Beschreibung
- Sicherheits-Erkennungszeichen (eine domain-weite Erweiterung der Unix-UID)
- NT Gruppen-Mitgliedschaften
- Einlog-Zeiten, und ob der User sofort ausloggen muss
- Arbeitsstationen, die der User verwenden darf
- Verfallsdatum des Accounts
- Home-Verzeichnis
- Login script
- Profil
- Account-Typ
Die Samba-Entwickler benützten die Domain-level Security in der Sambaversion 2.0.4, um Domain-User auf den Sambaservern halbautomatisch hinzuzufügen und zu löschen. Außerdem fügt sie Platz für andere NT-artige Zusätze hinzu, wie Unterstützung der Zugriffskontroll-Verzeichnisse und Änderung der Dateirechte vom Client.

Der Vorteil dieses Ansatzes ist weniger Administration; es muss nur eine Authentifizierungs-Datenbank synchronisiert werden. Die nur auf dem Sambaserver erforderliche lokale Administration wird Verzeichnisse für User erzeugen, die darin arbeiten, und /etc/passwd-Einträge, um ihre UIDs und Gruppen darin aufzubewahren.

6.3.4.1 Einen Sambaserver in eine Windows NT-Domäne integrieren

Wenn du schon eine Windows NT-Domäne hast, kannst du leicht einen Sambaserver hinzufügen. Zuerst musst du die Samba-Dämonen stoppen. Dann fügst du den Sambaserver zur NT-Domäne auf dem PDC hinzu, indem du das Tool "Windows NT Server Manager for Domains" verwendest. Sobald er um den Computertyp bittet, wähle "Windows NT Workstation or Server" und gib ihm den NetBIOS-Namen des Sambaservers. Das erzeugt den Maschinen-Account auf dem NT-Server.

Als Nächstes generierst du ein Maschinen-Passwort im Microsoft-Format mit dem smbpasswd-Tool, welches im nächsten Abschnitt genauer erklärt wird. Wenn z.B. unsere Domäne SIMPLE heißt und der Windows NT-PDC beowulf, könnten wir den folgenden Befehl auf dem Sambaserver verwenden, um das zu bewältigen:


smbpasswd -j SIMPLE -r beowulf

Schließlich fügst du die folgenden Optionen im der Sektion [global] deiner smb.conf hinzu und startest die Samba-Dämonen neu.

[global]
	security = domain
	domain logins = yes
	workgroup = SIMPLE
	password server = beowulf

Samba sollte nun für die Domain-level Security konfiguriert sein. Die Option domain logins wird in diesem Kapitel später genauer erklärt.

Using Samba