Inhaltsverzeichnis
Dieses Kapitel enthält Informationen zu den verschiedenen Server-Typen, die Sie im Samba-Server einstellen können. Ein Microsoft-Netzwerk-Administrator, der zu Samba migrieren bzw. Samba nutzen möchte, ist bestimmt interessiert daran, welche Samba-Konfigurationen er vornehmen muss, verglichen mit den Konfigurationen eines Windows-Servers. Es ist wichtig, die Sicherheitsdefinitionen festzulegen, bevor man den Server selbst konfiguriert.
Dieses Kapitel gibt Ihnen einen Überblick über die Sicherheitsmodi von Samba und zeigt, wie sie sich zu denen von Windows verhalten.
Eine Frage, die häufig gestellt wird, lautet: „Warum will ich Samba nutzen?“ Die meisten Kapitel enthalten einen Abschnitt, die die positiven Merkmale und Vorteile hervorhebt. Wir hoffen, dass diese Informationen Ihnen diese Frage beantworten können. Wir wollen fair und vernünftig bleiben, denken Sie also daran, dass nicht alle Features für Samba sprechen. Der Vorteil könnte auf unserer Seite sein.
Zwei Männer gehen eine staubige Straße entlang, als der eine plötzlich einen kleinen roten Stein lostritt. Der Stein setzt sich in seine Sandale und verletzt den Mann am Zeh. Der Mann nimmt den Stein unter zornigem Fluchen aus der Sandale und ist sehr verärgert. Der andere Mann schaut sich den Stein an und sagt: „Dies ist ein Granat, ich könnte ihn zu Schmuck verarbeiten, und eines Tages wird er einer Prinzessin viel Freude bereiten.“
Und die Moral von dieser Geschichte: Zwei Männer, zwei verschiedene Betrachtungsweisen des gleichen Steins. Mögen oder hassen. Samba ist wie dieser Stein. Behandeln Sie es richtig, so kann es Ihnen einen großen Dienst erweisen, aber wenn Sie gezwungen sind, Samba zu benutzen, ohne seine Geheimnisse zu kennen, kann es eine Quelle des Unbehagens sein.
Samba startete als Projekt, mit dem die Zusammenarbeit von MS Windows 3.x Clients und Unix-Servern gewährleistet werden sollte. Es ist seit den Anfängen stark gewachsen und stellt jetzt Merkmale und Funktionen zur Verfügung, die es für große Aufgaben geeignet macht. Es hat aber auch ein paar Nachteile, die wir in Abschnitten wie diesem besprechen möchten.
Also, was sind die Vorteile und Merkmale, die wir in diesem Kapitel erwähnen?
Samba 3 kann einen MS Windows NT4-Domänencontroller ersetzen.
Samba 3 bietet eine exzellente Kompatibilität mit MS Windows NT4-Domänen und mit nativen Microsoft Active-Directory-Domänen.
Samba 3 erlaubt volle Interdomain Trusts im NT4-Style.
Samba hat Sicherheitsmodi, die eine anpassungsfähigere Benutzer-Authentifikation durchführen können als Windows NT4-Domänencontroller.
Samba 3 unterstützt die parallele Nutzung von verschiedenen Account-Datenbanken.
Die Account- bzw. Passwort-Datenbanken können mit verschiedenen Methoden verteilt und repliziert werden. Dies ermöglicht mit Samba 3 eine größere Flexibilität als mit MS Windows NT4 - und stellt in vielen Fällen auch ein wesentlich besseres Werkzeug als Active-Directory- Domänen unter Windows 200x dar.
Administratoren von Microsoft-Netzwerken beziehen sich oft auf drei verschiedene Server-Arten:
Domänencontroller
Domänen-Mitgliedsserver
Stand-alone-Server
Die Kapitel über Domänencontroller, Backup-Domänencontroller und Domänen-Mitgliedschaft enthalten nützliche Informationen zur Samba-Konfiguration für jede dieser Serverrollen. Wir möchten Sie ermutigen, sich mit diesen Informationen vertraut zu machen.
In diesem Abschnitt werden die Funktionen und Zwecke der Samba-Sicherheitsmodi beschrieben. Es ist wichtig zu verstehen, wie jede der Sicherheitsmöglichkeiten, die Samba bietet, arbeitet und wie die Windows-Clients konfiguriert werden müssen, damit Sicherheit und Funktionstüchtigkeit gewährleistet sind.
In der SMB/CIFS-Netzwerkwelt gibt es nur zwei Arten der Sicherheit: User Level und Share Level. Wir bezeichnen diese beiden Arten kollektiv als Sicherheits- Level. Durch Realisierung dieser beiden Security-Level bietet Samba Flexibilitäten, die nicht in Microsoft NT4/200x-Servern vorgesehen sind. Derzeit unterstützt Samba die Share Level-Sicherheit nur in einer Richtung, dafür aber vier Arten der User Level-Sicherheit. Zusammen gesehen nennen wir die Samba-Sicherheiten Sicherheitsmodi. Sie sind bekannt als: SHARE-, USER-, DOMAIN-, ADS- und SERVER-Modi, und werden in diesem Kapitel behandelt.
Ein SMB-Server sagt dem Client während des Startens, mit welcher Sicherheitsstufe der SMB-Server läuft. Hierbei gibt es zwei Optionen: Share Level und User Level. Diese beiden Optionen beeinflussen die Art, wie der Client sich selbst authentifiziert. Sie beeinflussen nicht direkt die Art, wie der Samba-Server die Sicherheit handhabt. Das klingt ein wenig merkwürdig, aber es passt zu der Weise, wie SMB arbeitet. Bei SMB wird alles vom Client initiiert und kontrolliert, und der Server teilt dem Client nur mit, was verfügbar bzw. erlaubt ist.
Der Einfachheit halber möchten wir zuerst die User Level-Sicherheit erläutern. In dieser Sicherheitsstufe sendet der Client einen Session Setup Request und direkt darauf folgend eine Protokoll-Absprache. Diese Anfrage liefert einen Benutzernamen und ein Passwort. Der Server akzeptiert die Benutzernamen/Passwort-Kombination entweder, oder er verweigert sie. An diesem Punkt hat der Server keine Ahnung, welche Freigabe der Client eventuell aufrufen wollte, es wird nur durch folgende Punkte eine Entscheidung für die Annahme oder die Verweigerung getroffen:
Durch den Benutzernamen/das Passwort
Durch den Namen des Client-PCs
Wenn der Server den Benutzernamen mit dem entsprechenden Passwort akzeptiert, erwartet der Client, Freigaben einzubinden (unter Verwendung einer Baum- Verbindung), ohne ein weiteres Mal das Passwort zu nennen. Der Client geht davon aus, dass alle Zugriffsrechte durch den Benutzernamen/das Passwort aus dem Session Setup geregelt werden.
Es ist ebenfalls möglich, dass ein Client verschiedene Session Setup-Anfragen sendet. Wenn der Server darauf antwortet, vergibt er an den Client eine uid als Authentifizierungsetikett. Der Client kann somit verschiedene Authentifizierungskontexte aufrechterhalten (WinDD, zum Beispiel, ist eine Applikation, die diese Verfahrensweise nutzt).
Bei der Share Level-Sicherheit authentifiziert sich der Client selbst bei jedem Aufruf einer Freigabe mit einem Passwort. Es wird nicht explizit ein Benutzername vom Client zum Server gesendet. Der Client erwartet ein Passwort, das mit jeder Freigabe verbunden wird; somit hat Samba die Aufgabe herauszufinden, welchen Benutzernamen der Client verwenden möchte. Einige kommerzielle SMB-Server wie NT assoziieren Passwörter bei der Share Level-Sicherheit direkt mit Freigaben; Samba arbeitet im Gegensatz dazu mit dem UNIX-Authentifizierungsschema, das ein Benutzer/Passwort- Paar statt eines Share/Passwort-Paars erwartet.
Um die Parallele zum MS-Windows-Netzwerk zu verstehen, sollte man in der Begrifflichkeit von Windows 9x/Me denken, wo jemand einen gemeinsam genutzten Ordner freigeben kann, der Nur-Lese- oder Voll-Zugriff mit oder ohne Passwort gestattet.
Viele Clients senden ein Session Setup auch dann, wenn der Server mit Share Level-Sicherheit läuft. Sie übergeben normalerweise einen gültigen Benutzernamen, den sich Samba in einer Liste der möglichen Benutzernamen merkt. Wenn nun der Client eine Verbindung zu einem Freigabe-Baum herstellt, nimmt der Samba-Server den Namen der Freigabe in seine Liste auf (nützlich für Freigaben des Heimat-Verzeichnisses), und jeder Benutzer des user Parameters in der smb.conf wird mit dem gesendeten Passwort überprüft. Wenn nun eine Übereinstimmung des anfänglich gesendeten Benutzernamens mit dem für das Share gesendeten Passwort gefunden wird, ist der Client berechtigt, auf dieses Share zuzugreifen.
Der smb.conf-Parameter, der die Sicherheitsstufe auf Share Level-Sicherheit setzt, sieht so aus:
| security = share |
Es gibt Berichte, dass neue MS Windows-Clients nicht mit Servern arbeiten möchten, die im Share Level-Sicherheitsmodus laufen. Wir möchten ausdrücklich davor warnen, im Share Level-Modus zu arbeiten.
Wenn Samba im security = domain-Modus betrieben wird, hat der Server einen Trust Account (Maschinen-Account) und reicht alle Authentifizierungsanfragen an die Domänencontroller weiter. Mit anderen Worten: Diese Konfiguration macht den Samba-Server zu einem Domänen-Mitglied.
Samba als Domänen-Mitgliedsserver
Diese Art, den Server zu betreiben, erfordert folgende Parameter in der smb.conf:
| security = domain |
| workgroup = MITTELERDE |
Damit dies funktioniert, müssen folgende Schritte untergenommen werden:
Richten Sie einen Maschinen-Account für den Samba-Server ein. Benutzen Sie dafür den Server Manager.
Auf dem UNIX/Linux-System führen Sie Folgendes aus:
root# net rpc join -U administrator%password
Samba-2.2.4 und spätere Versionen können durch das Ausführen von folgendem Befehl automatisch einer NT4-Domäne beitreten:
root# smbpasswd -j DOMÄNEN-NAMEN -r PDC_NAME \ -U Administrator%password
Samba 3 kann das Gleiche mit folgendem Kommando:
root# net rpc join -U Administrator%password
Mit Samba 3 ist es nicht nötig, den DOMÄNEN-NAMEN oder den PDC_NAME anzugeben, da Samba 3 sich diese Informationen aus der smb.conf holt.
Um diese Art der Authentifikation zu nutzen, benötigt man einen Standard-UNIX-Account, damit für jeden User eine gültige UNIX-UserID existiert, die vom entfernten Windows-Domänencontroller authentifiziert werden kann. Es spricht allerdings nichts dagegen, dass es diesem UNIX-Account verboten wird, sich einzuloggen, was bei MS Windows nicht möglich ist. Um einen solchen UNIX-Account zu blocken, setzen Sie eine nicht login-fähige Shell in der /etc/passwd (z.B. /bin/false als Shell).
Eine Alternative zum Assoziieren von UIDs zu Windows-Usern mit einem Samba-Mitgliedsserver wird in Kapitel Winbind beschrieben.
Für weitere Informationen zur Domänen-Mitgliedschaft lesen Sie bitte das Kapitel Domänen-Mitgliedschaft.
Sowohl Samba 2.2 als auch Samba 3 können einer ADS-Domäne beitreten. Der Betriebsmodus der Domäne ist für Samba dafür nicht relevant. Beachten Sie, dass Samba 2.2 sowie frühe Versionen von Samba 3.0 nicht einer Domäne mit einem unmodifizierten Windows Server-2003-Domänencontroller beitreten können, da dieser in seiner Voreinstellung das SMB-Signing voraussetzt. Seit Samba 3.0.3 wird dies jedoch unterstützt.
Wenn Sie ADS benutzen und mit Samba 3 starten, können Sie der ADS als normales Active-Directory-Mitglied beitreten. Warum Sie das tun sollten? Ihre Sicherheitsrichtlinien könnten die NT-kompatiblen Authentifizierungsprotokolle schlichtweg verweigern. Wenn alle Server in Ihrem Netzwerk Windows 2000 und höher nutzen, würde Samba als NT4-artiges Domänen-Mitglied NT-kompatible Authentifizierungsdaten benötigen. Samba im AD-Mitgliedsmodus allerdings kann auch Kerberos-Tickets auswerten.
| realm = YOUR.KERBEROS.REALM |
| security = ADS |
Für weitere Informationen zu dieser Konfigurationsoption lesen Sie bitte unter Domänen-Mitglied und ADS-Mitglied weiter.
Der Server-Security-Modus ist noch aus den Zeiten übrig geblieben, in denen Samba nicht als Domänen-Mitglied betrieben werden konnte. Sie sollten diesen Modus nicht verwenden, da er viele Nachteile mit sich bringt. Zum Beispiel:
Potenzielle Account-Sperren auf MS Windows NT4/200x Passwort-Servern.
Eine Sicherheitslücke, die dazu führt, dass der Passwortserver, der konfiguriert ist, nicht der ist, den man wirklich nutzen möchte.
Der Modus funktioniert nicht mit Winbind, was nötig ist, um Profile auf entfernten Systemen zu speichern.
Dieser Modus öffnet Verbindungen zum Passwort-Server und hält diese offen.
Die Sicherheit des Samba-Servers bricht aufs Schlimmste zusammen, wenn der Passwort-Server mittendrin abgeschaltet werden sollte.
In diesem Modus gibt es KEINEN Sicherheits-Account in der Domäne, um sicherzustellen, dass der Passwort-Server, der von Samba befragt wird, auch zur Domäne gehört.
Im Server-Sicherheitsmodus gibt der Samba-Server dem Client vor, im User-Level-Sicherheitsmodus zu agieren, und der Client schickt daraufhin ein Session Setup wie zuvor beschrieben. Der Samba-Server nimmt nun den Benutzernamen und das Passwort des Clients und schickt diese Daten exakt so, wie er sie bekommen hat, zum password server weiter. Wenn dieser Passwort-Server mit den Accountdaten einverstanden ist und in User Level-Sicherheit betrieben wird, akzeptiert der Samba-Server die Client-Verbindung. Dies erlaubt dem Samba-Server, einen anderen SMB-Server als password server zu nutzen.
Sie sollten wissen, dass am Anfang all dessen der Server dem Client auch mitteilt, ob eine Verschlüsselung der Daten stattfinden soll. Wenn dies auf dem Samba-Server konfiguriert ist, sendet der Server dem Client einen Krypto-Schlüssel, mit dem dann die Daten vom Client verschlüsselt werden. Samba unterstützt diese Verschlüsselung als Standard.
Der Parameter security = server bedeutet, dass der Samba-Server den Clients mitteilt, dass er im user mode betrieben wird, aber alle Passwort-Anfragen an einen anderen user mode-Server weiterleitet. Hierzu benötigt man einen weiteren Parameter, password server, der auf den echten Authentifizierungsserver verweist. Dieser Passwort-Server kann ein anderer Samba-Server oder ein Windows-NT-Server sein.
Falls Sie Samba im Server-Sicherheitsmodus betreiben, ist es äußerst wichtig, dass Sie den Parameter password server auf den genauen NetBIOS-Maschinen-Namen des Authentifizierungsservers setzen. Samba ist nicht in der Lage, dies über eine NetBIOS-Namens-Auflösung zu ermitteln, da die Auswahl des Authentifizierungsservers beliebig ist und nicht aus einem Domain-Namen ermittelt werden kann. Daraus folgt: Ein Samba-Server im Server Security Mode arbeitet so, wie man es als workgroup mode kennt.
Benutzung von MS Windows NT als Authentifizierungsserver.
Diese Methode betrifft folgende Parameter in der smb.conf-Datei:
| encrypt passwords = Yes |
| security = server |
| password server = "NetBIOS_name_of_a_DC" |
Es gibt zwei Verfahren, um ein Username/Passwort-Paar auf Gültigkeit zu überprüfen. Das eine nutzt die Informationen aus der Antwort, die als Teil der Authentifizierungsnachricht bereitgestellt wird, und das andere Verfahren wertet nur den Fehlercode aus.
Der Nachteil bei dieser Art der Konfiguration ist die Tatsache, dass Samba aus Sicherheitsgründen dem Passwort-Server einen erfundenen Benutzernamen und ein erfundenes Passwort sendet. Falls diese Accountdaten vom Passwort-Server abgelehnt werden, wechselt Samba zu einem alternativen Modus der Identifikation. Sollte das Netzwerk einen Benutzer nach einer gewissen Anzahl von fehlgeschlagenen Logins sperren, wird dies in dieser Konfiguration der Fall sein können. Sollte eine Website die Passwort-Eingabe nach einer gewissen Anzahl von fehlgeschlagenen Logins sperren, werden bei dieser Art der Konfiguration die Benutzer ausgesperrt.
Diese Art der Authentifizierung benötigt einen Standard-UNIX-Account für den User, der allerdings für andere System-Logins blockiert werden darf.
MS Windows-Clients können verschlüsselte Passwörter (bekannt als NTLMv1 und MTLMv2) zur Anmeldung nutzen oder aber auch Klartext-Passwörter für eine einfache passwort-basierende Authentifizierung nutzen. Man sollte sich deutlich machen, dass das SMB-Protokoll nicht vorsieht, dass sowohl Klartext- als auch verschlüsselte Passwörter innerhalb einer Authentifizierungsanfrage über ein Netzwerk verschickt werden.
Wenn verschlüsselte Passwörter verwendet werden, gibt es zwei verschiedene Arten, diese zu verschlüsseln:
Ein MD5-Hash des Passworts (Unicode), besser bekannt als NT-Hash.
Das Passwort wird in Großbuchstaben konvertiert und auf eine Länge von insgesamt 14 Byte gekürzt oder verlängert. Anschließend wird dieser String mit 5 Byte des NULL-Zeichens am Ende erweitert und geteilt, um zwei 56-Bit-DES-Schlüssel zu bilden, die zur Verschlüsselung eines „magischen“ 8-Byte-Wertes verwendet werden. Das Resultat hieraus ist der 16-Byte-LanMan-Hash.
MS Windows 95 vor SP 1 und MS Windows NT in den Versionen 3.x und 4.0 vor SP3 unterstützen beide Arten der Passwort-Authentifizierung. Alle Versionen von MS Windows nach den oben genannten Versionen unterstützen standardmäßig die Verwendung von Klartext-Passwörtern nicht mehr.
MS Windows-Clients haben die Eigenart, Netzwerk-Mappings zu verlieren, wenn diese länger als 10 Minuten nicht mehr verwendet wurden. Wenn der User ein Mapping nach dieser Zeit verwenden will, baut der Client die Verbindung erneut auf und verwendet dabei eine zwischengespeicherte Kopie des Passworts.
Als Microsoft den Standard-Passwort-Modus änderte, wurde die Unterstützung für das Cachen des Klartext-Passworts entfernt. Wenn man bei Windows durch Ändern der Registry-Einträge die Verwendung von Klartext-Passwörtern wieder einschalten würde, entfällt allerdings der oben beschriebene Support zum Zwischenspeichern der Passwörter. Dies hat zur Folge, dass es nicht gelingen wird, eine Verbindung von allein wiederherzustellen, wenn ein Client sie nach dem o.g. Timeout verworfen hat. Es ist also definitiv keine gute Idee, bei diesen Clients Klartext-Passwörter zu verwenden.
Folgende Parameter können als Workaround für Windows 9x/Me-Clients verwendet werden, die die Benutzernamen und Passwörter in Großbuchstaben umwandeln, bevor sie zum SMB- Server verschickt werden (Nur bei Verwendung von Klartext-Passwörtern).
| password level = integer |
| username level = integer |
Samba wird standardmäßig den Benutzernamen in Kleinbuchstaben umwandeln, bevor versucht wird, diesen in der lokalen Benutzerdatenbank zu authentifizieren. Da UNIX-Benutzernamen üblicherweise nur Kleinbuchstaben enthalten, wird der username level-Parameter nur selten verwendet.
UNIX-Systeme machen oftmals Gebrauch von gemischter Groß-/Kleinschreibung im Passwort. Dies hat zur Folge, dass bei Benutzung von Klartext-Passwörtern auf Windows 9x/Me-Systemen der Parameter password level auf die Anzahl an Großbuchstaben gesetzt werden muss, die in einem Passwort maximal vorkommen können. Beachten Sie bitte Folgendes: Bei Verwendung der traditionellen DES-Verschlüsselung der crypt()-Funktion hat eine Konfiguration password level von 8 case-insensitive Passwörter zur Folge, wie sie von Windows-Benutzern gesehen werden. Dies kann lange Login-Zeiten nach sich ziehen, bis ein Passwort angenommen wird bzw. alle Kombinationen fehlgeschlagen sind.
Die beste Lösung ist es, die Unterstützung von verschlüsselten Passwörtern zu aktivieren, wo immer Samba genutzt wird. Die meisten Versuche, die Registrierung von Windows dahingehend zu verändern, dass Klartext-Passwörter verwndet werden können, führen zu Beschwerden und Verärgerung der Anwender.
Wir alle machen Fehler. Es ist okay Fehler zu machen, solange man sie an den richtigen Stellen zum richtigen Zeitpunkt macht. Ein Fehler, der zu einem Produktivitätsausfall führt, wird selten toleriert, wohingegen ein Fehler in einem Entwicklungslabor erwartet wird.
An dieser Stelle werfen wir einen Blick auf häufige Fehler, die Thema in Diskussionen der Samba-Mailing-Liste sind. Viele dieser Fehler sind vermeidbar, wenn Sie Ihre Hausaufgaben vor der Einführung von Samba machen. Einige sind das Ergebnis von Missverständnissen in Bezug auf die englische Sprache. Die englische Sprache hat viele Phrasen, die potenziell vage sind und die jemanden, dessen Muttersprache nicht Englisch ist, sehr verwirren können.
Es wird oftmals angenommen, dass security = server bedeutet, dass Samba als Server agiert. Dies ist nicht so! Diese Einstellung bedeutet, dass Samba versucht, einen anderen SMB-Server für sich selbst als Quelle zur Authentifizierung zu verwenden.
Der smb.conf-Parameter security = domain macht Samba nicht zu einem Domänencontroller, sondern besagt, dass der Samba-Server einer Domäne als Mitglied angehören soll.
Raten Sie! So machen es viele andere. Aber was auch immer Sie tun, glauben Sie nicht, dass security = user Samba zu einem Domänen-Mitglied werden lässt. Lesen Sie hier weiter: ???
„ Warum gibt server_validate() einfach auf, statt die Verbindung zum Passwort-Server wieder aufzubauen? Da ich das SMB-Protokoll nicht so gut kenne, vermute ich, dass der Cluster-Server den Session-Key vom Passwort-Server zu den Client-Workstations weiterreicht, was bedeutet, dass die Passwort-Hashes der Clients nicht in einer folgenden Sitzung funktionieren, deren Session-Key anders wäre, somit muss server_validate() an dieser Stelle abbrechen. “
Genau! Das ist der Grund, warum security = server ein gemeiner Hack ist. Bitte verwenden Sie security = domain; der security = server-Modus ist auch als Pass-through-Authentifizierung bekannt.