Diese Einstellung beeinflusst, wie Clients mit dem Sambas kommunizieren. Diese Einstellung ist eine der wichtigsten in der /etc/samba/smb.conf-Datei überhaupt. Man sollte genau verstehen, wie das Security-Modell von Samba funktioniert.
Dies ist eine der wichtigsten Einstellungen innerhalb der /etc/samba/smb.conf-Datei, denn sie legt fest, wie das sogenannte security mode bit gesetzt wird. Diese Option kann nur global festgelegt werden, da jeder Server nur eine Art der Sicherheit kennt. Sehen wir uns zunächst an, welche Arten von Security eingestellt werden. Grundsätzlich gibt es drei verschiedene Einstellungsmöglichkeiten:
Ist der Server auf diesen Security-Level eingestellt, so braucht sich ein Client nicht mit seinem Namen und Password beim Server anzumelden, um sich mit einer Ressource des Servers zu verbinden. Ein Client, der eine bestimmte share-Ressource oder einen share-Dienst nutzen möchte, meldet sich für jede dieser Anfragen mit einem Password an. Um einen Server mit share level security nutzen zu können, muss der User, der sich beim Server anmeldet, beim Server bekannt sein, es muss also ein Account für ihn auf der Unix-Maschine existieren. Der nachfragende Client wird nur nicht nach diesem Namen gefragt, da der smbd-Daemon anhand eines Password-Vergleichs herauszufinden versucht, ob das übergebene Password mit einem auf der Unix-Maschine registrierten User korreliert.
Modernere Windows-Betriebssysteme übergeben bei einer Anfrage an den Server in jedem Fall einen User-Namen, auch dann, wenn der Client selbst nicht aufgefordert wird, einen solchen anzugeben. Samba verwendet die folgenden Strategien, um im share level security mode herauszufinden, wie der anfragende Client mit den nachgefragten Ressourcen verbunden werden kann.
Falls der Parameter guest only nicht gesetzt ist, wird der Inhalt dieser Liste mit dem übergebenen Password verglichen. Der erste Client, dessen Password mit dem Vergleich übereinstimmt, wird als Unix-Account akzeptiert.
Falls der Parameter guest only gesetzt ist oder kein anderer User-Name gefunden werden kann, so wird dieser Gast-User als Unix-User zugelassen. Dies gilt aber nur, wenn die betreffende Share als verfügbar für den guest account markiert ist.
Dies ist die Voreinstellung des Security-Levels für die
Samba-Version 2.0.x. Für diese Einstellung gilt: Ein Client muss
sich zuerst mit einer gültigen User-Name/Password-Kombination beim Server
anmelden. Dabei kann der User-Name auch aus der username
map-Abbildung (siehe Seite ![[*]](file:/usr/share/latex2html/icons/crossref.png){kind=icon}
) gewonnen
werden. Es können auch verschlüsselte Passwords verwendet werden,
wenn dieser Dienst eingeschaltet ist. Jetzt werden die Parameter
user und guest only analysiert, und dann, wenn
diese Parameter entsprechend mit User-Namen belegt sind (siehe auch
Seite ), kann der
Unix-Account die gewünschte Verbindung mit dem Share des Servers
herstellen. Aber dieser Client muss sich entsprechend autorisieren.
Der Name der angeforderten Share (oder des Dienstes) wird dem Server nicht übermittelt, bevor der Client sich nicht ordnungsgemäß authentifiziert hat. Das ist der Grund, warum guest-Shares in diesem Security-Level nicht funktionieren können, ohne ein automatisches Mapping von unbekannten Clients auf die Menge der guest account-Clients.
In diesem Security-Mode versucht der Samba-Server, die Validierung des User-Name/Password-Paares an einen anderen Server im Netz zu delegieren. Wenn das nicht funktioniert, weil beispielsweise keine NT-Maschine oder andere Samba-Maschine im Netz gefunden werden kann, die diese Aufgabe übernehmen kann, so stellt sich der Samba-Server automatisch auf den Security-Level security = user ein. Wenn verschlüsselte Passwords verwendet wurden, so muss eine gültige smbpasswd-Datei existieren, da Samba nicht in der Lage ist, wieder die Unix-Password-Datei zur Validierung eines Users zu verwenden.
Vom Standpunkt des Clients besteht zwischen der Einstellung security=server und security=user keinerlei Unterschied. Der Unterschied zeigt sich nur auf der Server-Seite, und zwar darin, wie der Server die Authentifizierung behandelt.
Dieser Parameter funktioniert nur dann korrekt, wenn das Kommando net verwendet wurde, um die Maschine in an einer Windows NT-Domain anzumelden. Dieser Security-Level erwartet verschlüsselte Passwords, daher muss der Parameter encrypted passwords mit dem Wert true belegt werden. In dieser Einstellung wird Samba die User-Name/Password-Validierung an einen Windows NT-PDC oder Windows NT-BDC übergeben (siehe Glossar BDCbdc und PDCpdc). Die Validierung wird dann von einem der Controller durchgeführt, wobei die Übergabe der User-Name/Password-Kombination völlig intransparent für den Windows NT-Domain-Controller geschieht. Das bedeutet, dieser Controller kann nicht feststellen, ob ein Samba-Server diese Validierungsanfrage gestellt hat.
Anders als in einer echten Windows NT-Domain, muss es auf der lokalen Maschine und auf dem Primary Domain Controller einen echten Account geben, damit Samba diesen auf den User-Namen der Domain abbilden kann.
Vom Standpunkt des Clients besteht zwischen der Einstellung security=DOMAIN und security=USER keinerlei Unterschied. Der Unterschied zeigt sich nur auf der Server-Seite, und zwar darin, wie der Server die Authentifizierung behandelt.
Der Name der angeforderten Ressource wird solange nicht an den Server geschickt, bis das der Client sich erfolgreich auf dem Server authentifiziert hat. Das ist der Grund dafür, warum, Gastzugänge im USER-Level auf Shares nicht funktionieren, ohne dass der Server den unbekannte Accounts automatisch auf einen konfigurierten guest-Account abbildet (siehe item:maptoguest).
Dieser Parameter funktioniert nur dann korrekt, wenn die Password-Datei smbpasswd verwendet wurde, um diese Maschine in eine Windows NT-Domain einzufügen. Dieser Security-Level erwartet verschlüsselte Passwords, daher muss der Parameter encrypted passwords mit dem Wert true belegt werden. In dieser Einstellung wird Samba die User-Name/Password-Validierung an einen Windows NT-PDC oder Windows NT-BDC übergeben (siehe Glossar BDCbdc und PDCpdc). Die Validierung wird dann von einem der Controller durchgeführt, wobei die Übergabe der User-Name/Password-Kombination völlig intransparent für den Windows NT-Domain-Controller geschieht. Das bedeutet, dieser Controller kann nicht feststellen, ob ein Samba-Server diese Validierungsanfrage gestellt hat.
Hier zeigt sich der Effekt der Schnittstelle zwischen Unix-artigen und Windows-Betriebssystemen. Da auf der Samba-[share]-sectionr-Seite die Modes der Client-Dateien auf die Rechte von Unix-Dateien abgebildet werden müssen, muss für einen Client, der sich über einen Samba-Server auf einem Windows NT-Domain-Controller validieren lässt, ein gültiger Account auf der Unix-Workstation existieren. Natürlich muss ebenfalls ein Account auf dem (B)(P)DC-Controller existieren. Diese Dualität der einzelnen Accounts und der damit verknüpften Login-Daten ist eine Eigenschaft, die uns durch den Kontext des ganzen Buches beschäftigen wird.
Vom Standpunkt des Clients besteht zwischen der Einstellung security=server und security=user keinerlei Unterschied. Der Unterschied zeigt sich nur auf der Server-Seite, und zwar darin, wie der Server die Authentifizierung behandelt.
In diesem Modus funktioniert Samba als Domain-Mitglied in einer ADS-Umgegbung. Um in diesem Modus arbeiten zu können, muss Samba mit der Option Kerberos installiert sein und selbstverständlich muss das Kerberos-Paket auch auf dem Betriebssystem installiert sein. Außerdem muss die Samba-Maschine mit dem Command net in die Domain eingefügt worden sein.
In diesem Mode arbeitet die Samba-Maschine nicht als Active Directory Domain Controller (siehe Abschnitt sec:waskannsamba3).
Voreinstellung:
security = USER
Beispiel:
security = DOMAIN
Siehe auch item:realm und item:encryptpasswords.
Wenn man noch eine ältere Samba-Version installiert hat (
), so ist die Voreinstellung dieses Parameters auf
share gesetzt. Der Security-Level share war lange
Zeit der einzig mögliche Wert, mit dem dieser Parameter initialisiert
werden konnte. Erst seit der Version 2.0.x hat sich das geändert, denn
diese Version unterstützt alle Security-Level des
SMB-Protokolls, und so ist ab dieser Version 2.0.x die Voreinstellung
user.
Diese Option setzt das security mode bit beim Aushandeln des Protokolls (was in einer Windows NT-Domain traditionell automatisch geschieht). Die einzelnen Clients entscheiden in Abhängigkeit dieses Bits, ob und wie sie die User-Name/Password-Kombination an den Server schicken sollen.
Die Voreinstellung ist security=user, das ist die Standardeinstellung, um am besten mit den normalerweise in einem Netz vorhandenen Windows NT- und Windows 98-Clients zu kommunizieren.
Mögliche Alternativen sind:
Im Betriebssystem Windows for Workgroups gibt es einen Bug, der sich fatal auf diese Einstellungen auswirkt. Wenn sich der [share]-sectionr im Security Mode user oder server befindet, so wird ein Windows for Workgroups-Client das Password ignorieren, welches man eingeben muss, um sich mit einem Laufwerk zu verbinden (connect drive-Fenster auf der Windows for Workgroups-Seite). Das macht es schwierig bis unmöglich, sich mit dem [share]-sectionr zu verbinden.
Wenn man auf dem eigenen PC dieselben User-Namen verwendet wie auf der
Unix-Workstation, dann ist es besser, man verwenden als Security Mode die
Einstellung security = user. Verwendet man jedoch Namen, die
auf der Unix-Seite nicht existieren, dann sollte man als
Security Mode die Einstellung security = share benutzen.
Diese Einstellung sollte auch dann verwendet werden, wenn das eigene Netz
hauptsächlich Shares definiert hat, für die kein Password notwendig ist
(guest shares). Der Parameter map to guest (siehe
Seite ) macht das Einrichten von
guest shares zu einem Geduldspiel, wenn der Security Mode auf
security=user eingestellt ist.
Voreinstellung:
security = USER
Beispiel:
security = DOMAIN