14.3. Samba-Servertypen und die smb.conf-Datei
Die Samba-Konfiguration ist relativ eindeutig. Alle Modifizierungen erfolgen in der /etc/samba/smb.conf-Konfigurationsdatei. Obwohl die standardmäßige smb.conf-Datei gut dokumentiert ist, werden komplexere Themen wie z.B. LDAP, Active Directory und die zahlreichen Domänencontroller-Implementationen nicht angesprochen.
Die folgenden Abschnitte beschreiben die verschiedenen Arten, auf die ein Samba-Server konfiguriert werden kann. Behalten Sie dabei Ihre Anforderungen und die erforderlichen Änderungen der smb.conf-Datei im Auge, um eine erfolgreiche Konfiguration durchführen zu können.
14.3.1. Einzel-Server (Stand-Alone)
Ein frei stehender, eigenständiger Server kann ein Arbeitsgruppenserver oder ein Mitglied einer Arbeitsgruppenumgebung sein. Ein Stand-Alone-Server kontrolliert keine Domäne und übernimmt keine Rolle in einer Domäne. Die folgenden Beispiele zeigen einige anonyme Zugangskonfigurationen auf Share-Ebene und eine Benutzterzugangskonfiguration auf. Für weitere Informationen über Share-Level und User-Level Sicherheitsverfahren siehe Abschnitt 14.4.
14.3.1.1. Anonyme Leseberechtigung
Die folgende smb.conf-Datei zeigt eine Beispiel-Konfiguration, die zur Implementierung anonymer Leseberechtigung für gemeinsamen Dateizugriff benötigt wird. Der security = share-Parameter macht einen Share anonym. Beachten Sie dabei, dass Sicherheits-Levels für einen einzelnen Samba-Server nicht kombiniert verwenden können. Die security-Anweisung ist ein globaler Samba-Parameter, befindlich im [global] Konfigurationsabschnitt der smb.conf-Datei.
[global] workgroup = DOCS netbios name = DOCS_SRV security = share [data] comment = Documentation Samba Server path = /export read only = Yes guest only = Yes |
14.3.1.2. Anonyme Lese-/Schreibberechtigung
Die folgende smb.conf-Datei zeigt eine Beispiel-Konfiguration, die zur Implementierung anonymer Lese-/Schreibberechtigung für gemeinsamen Dateizugriff benötigt wird. Um anonymen Lese-/Schreibzugriff zu aktivieren, setzen Sie den Wert der read only-Anweisung auf no. Die force user und force group-Anweisungen werden ebenso hinzugefügt, um die Eigentumsrechte jeglicher neu plazierter Dateien gemäß der gemeinsamen Nutzung festzulegen.
 | Anmerkung |
|---|---|
Obwohl die Möglichkeit eines anonymen Lese-/Schreib-Servers gegeben ist, wird die Durchführung eines solchen jedoch nicht empfohlen. Jegliche Dateien, die für die gemeinsame Nutzung im Share platziert werden, ungeachtet des Benutzers, sind der Benutzer/Gruppen-Kombination zugeordnet, wie durch einen gewöhnlichen Benutzer (force user) und Gruppe (force group) in der smb.conf-Datei festgelegt. |
[global] workgroup = DOCS netbios name = DOCS_SRV security = share [data] comment = Data path = /export force user = docsbot force group = users read only = No guest ok = Yes |
14.3.1.3. Anonymer Druck-Server
Die folgende smb.conf-Datei zeigt eine Beispiel-Konfiguration, die zur Implementierung eines anonymen Druck-Servers benötigt wird. Indem (wie hier gezeigt) browsable auf no gesetzt wird, wird der Drucker nicht in Windows Network Neighborhood gelistet. Der Drucker scheint zwar in der Druckerliste nicht auf, kann aber trotzdem bei expliziter Angabe konfiguriert werden. Durch die Verbindung zu DOCS_SRV mittels NetBIOS kann der Client Zugang zum Drucker erlangen, sofern der Client Teil der DOCS-Arbeitsgruppe ist. Es wird angenommen, dass der Client den dafür korrekten lokalen Druckertreiber installiert hat, während die use client driver-Anweisung auf den Wert Yes gesetzt ist. In diesem Fall muss der Samba-Server die Drucker-Treiber mit dem Client gemeinsam benutzen.
[global] workgroup = DOCS netbios name = DOCS_SRV security = share printcap name = cups disable spools= Yes show add printer wizard = No printing = cups [printers] comment = All Printers path = /var/spool/samba guest ok = Yes printable = Yes use client driver = Yes browseable = Yes |
14.3.1.4. Sichere Lese-/Schreib-Datei und Druck-Server
Die folgende smb.conf-Datei zeigt eine Beispiel-Konfiguration an, die zur Implementierung eines sicheren Lese-/Schreib-Druck-Servers benötigt wird. Indem die security-Anweisung auf user gesetzt wird, wird Samba zur Authenfifizierung der Client-Verbindungen gezwungen. Beachten Sie dabei, dass [homes]-Share keine force user- oder force group-Anweisung besitzt; im Gegensatz zu [public]-Share. [homes]-Share benutzt die authentifizierten Benutzer-Details für sämtliche erstellten Dateien im Gegensatz zu force user und force group in [public].
[global] workgroup = DOCS netbios name = DOCS_SRV security = user printcap name = cups disable spools = Yes show add printer wizard = No printing = cups [homes] comment = Home Directories valid users = %S read only = No browseable = No [public] comment = Data path = /export force user = docsbot force group = users guest ok = Yes [printers] comment = All Printers path = /var/spool/samba printer admin = john, ed, @admins create mask = 0600 guest ok = Yes printable = Yes use client driver = Yes browseable = Yes |
14.3.2. Domänenmitglieder-Server
Ein Domänenmitglied, obwohl ähnlich einem Stand-Alone-Server, ist in einen Domänencontroller eingelogged (entweder Windows oder Samba) und unterliegt den Sicherheitsbestimmungen der Domäne. Ein Beispiel eines Domänenmitglieder-Servers wäre ein Abteilungs- oder Fachbereichsserver, auf welchem Samba läuft und welcher ein Maschinenkonto auf dem Primary Domain Controller (PDC) besitzt. Alle Clients der Abteilung authentifizieren noch immer mit PDC, sämtliche Desktop-Profile und alle Netzwerk-Policen miteingeschlossen. Der Unterschied ist, dass der Abteilungsserver die Fähigkeit besitzt, Drucker- und Netzwerk-Shares zu kontrollieren.
14.3.2.1. Active Directory Domänenmitglieder-Server
Die folgende smb.conf-Datei zeigt eine Beispiel-Konfiguration, die zur Implementierung eines Active Directory Domänenmitglieder-Servers benötigt wird. In diesem Beispiel authentifiziert Samba Benutzer für lokale Dienste und ist gleichzeitig auch ein Client des Active Directory. Stellen Sie sicher, dass ihr Kerberos realm-Parameter in allen Caps aufgezeigt wird (zum Beispiel realm = EXAMPLE.COM). Da Windows 2000/2003 Kerberos zur Active Directory-Authentifikation benötigt, ist die realm-Anweisung erforderlich. Wenn Active Directory und Kerberos auf verschiedenen Servern laufen, so kann die password server-Anweisung erforderlich sein, um bei der Unterscheidung zu helfen.
[global] realm = EXAMPLE.COM security = ADS encrypt passwords = yes # Optional. Use only if Samba cannot determine the Kerberos server automatically. password server = kerberos.example.com |
Um einen Mitglieder-Server mit einer Active Directory Domäne zu verbinden, müssen folgende Schritte unternommen werden:
Konfiguration der smb.conf-Datei auf dem Mitglieder-Server
Konfiguration von Kerberos, einschließlich der /etc/krb5.conf-Datei auf dem Mitglieder-Server
Erstellung eines Maschinen-Accounts auf dem Active Directory Domänen-Server
Verbindung des Mitglieder-Servers mit der Active Directory Domäne
Um den Maschinen-Account zu erzeugen und diesen mit Windows 2000/2003 Active Directory zu verbinden, muss Kerberos zuerst für den Mitgliederserver initialisiert werden. Um ein administratives Kerberos-Ticket zu erzeugen, geben Sie folgenden Befehl als root auf dem Mitglieder-Server ein:
root# kinit administrator@EXAMPLE.COM |
Der kinit-Befehl ist ein Kerberos-Initialisierungsscript, das auf den Active Directory Administrator-Account und Kerberos-Bereich verweist. Da Active Directory Kerberos-Tickets benötigt, bezieht und cached kinit Kerberos Zugangsberechtigungs-Tickets zur Client/Server-Authentifikation. Für weitere Infos über Kerberos, die /etc/krb5.conf-Datei und den kinit-Befehl siehe Kapitel 19.
Um sich mit einem Active Directory Server zu verbinden (z.B. windows1.example.com), müssen sie Folgendes als root eingeben:
root# net ads join -S windows1.example.com -U administrator%password |
Während die Maschine windows1 bereits automatisch im korrespondierenden Kerberos-Bereich gefunden wurde (der kinit-Befehl war erfolgreich), stellt der net-Befehl die Verbindung zum Active Directory Server mittels dem erforderlichen Admin-Account und Passwort her. Dadurch wird das richtige Maschinenkonto auf dem Active Directory erstellt und erlaubt dem Samba Domänen-Server sich der Domäne anzuschliessen.
| Anmerkung |
|---|---|
Da security = ads und nicht security = user benutzt wird, wird ein lokales Passwort-Backend wie z.B. smbpasswd nicht benötigt. Ältere Clients, die security = ads nicht unterstützen, werden authentifiziert als ob security = domain gesetzt ist. Diese Änderung beinträchtigt nicht die Funktionalität und erlaubt lokale Benutzer, die zuvor nicht in der Domäne waren. |
14.3.2.2. Windows NT4-basierter Domänenmitglieder-Server
Die folgende smb.conf-Datei zeigt eine Beispielkonfiguration, die dazu benötigt wird einen Windows NT4-basierten Domänenmitgieder-Server zu implementieren. Der Vorgang, ein Mitgliederserver einer NT4-basierten Domäne zu werden, ist ähnlich der Verbindung zu Active Directory. Der Hauptunterschied ist der, dass NT4-basierte Domänen Kerberos nicht für deren Authentifizierungsmethode verwenden, was die smb.conf-Datei einfacher gestaltet. In diesem Beispiel dient der Samba-Mitgliederserver als eine Art "Durchreiche" zum NT4-basierten Domänen-Server.
[global] workgroup = DOCS netbios name = DOCS_SRV security = domain [homes] comment = Home Directories valid users = %S read only = No browseable = No [public] comment = Data path = /export force user = docsbot force group = users guest ok = Yes |
Samba als Domänenmitglieder-Server zu besitzen, kann in vielen Situationen sehr nützlich sein. Manchmal hat der Samba-Server auch eine andere Verwendung nebst Datei- und Drucker-Sharing. Es kann von Vorteil sein, Samba zu einem Domänenmitglieder-Server zu machen, wenn reine Linux-Applikationen für die Nutzung in dieser Domänenumgebung erforderlich sind. Administratoren bevorzugen den Überblick über alle Maschinen in der Domäne zu behalten; auch wenn nicht Windows-basiert. Im Falle, dass die Windows-basierte Server-Hardware abgelehnt wird, ist es relativ einfach die smb.conf-Datei zu modifizieren, um den Server zu einem Samba-basierten PDC zu konvertieren. Wenn Windows NT-basierte Server auf Windows 2000/2003 umgestellt werden, so ist die smb.conf-Datei einfach modifizierbar, um die Infrastrukturveränderung falls notwendig in Active Directory einfliessen zu lassen.
 | Wichtig | |
|---|---|---|
Nachdem die smb.conf-Datei konfiguriert wurde, verbinden Sie sich mit der Domäne bevor Samba gestartet wird, indem Sie folgenden Befehl als root eingeben:
|
Beachten Sie dabei, dass die -S-Option, welche den Domänen-Server Hostname spezifiziert, nicht im Befehl net rpc join vorkommen muss. Samba benutzt stattdessen den Hostnamen, der durch die workgroup-Anweisung in der smb.conf-Datei festgelegt wird.
14.3.3. Domänencontroller
Ein Domänencontroller in Windows NT ähnelt funktionell gesehen einem Network Information Service (NIS) Server in einer Linux-Umgebung. Domänencontroller und NIS-Server hosten beide Benutzer/Gruppen-Informationsdatenbanken sowie dazugehörige Dienste. Domänencontrollers werden hauptsächlich zu Sicherheitszwecken verwendet, was die Authentifizierung von Benutzern, die auf Domänen-Ressourcen zugreifen, miteinschließt. Der Dienst, der für die Benutzer/Gruppen-Datenbank zuständig ist, wird Security Account Manager (SAM) genannt. Die SAM-Datenbank wird unterschiedlich in Samba-basierten Windows- und Linux-Systemen gespeichert. Daher kann keine SAM Replikation erzielt werden und Plattformen können in einer PDC/BDC-Umgebung nicht kombiniert werden.
In einer Samba-Umgebung kann es nur einen PDC und null oder mehr BDCs geben.
| Wichtig |
|---|---|
Samba kann nicht in einer gemischten Samba/Windows Domänencontroller-Umgebung existieren (Samba kann kein BDC eines Windows PDC sein oder umgekehrt). Alternativ dazu kann es eine Coexistenz von Samba PDCs und BDCs geben. |
14.3.3.1. Primary Domain Controller (PDC) unter Verwendung von tdbsam
Die einfachste und gebräuchlichste Implementierung eines Samba PDC benutzt das tdbsam Passwort Datenbank Backend. Als Ersatz für das alternde smbpasswd Backend geplant, besitzt tdbsam zahlreiche Verbesserungen, welche in größerem Detail nachfolgend beschrieben werden unter Abschnitt 14.5. Die passdb backend-Anweisung kontrolliert welches Backend für den PDC benutzt werden muss.
[global] workgroup = DOCS netbios name = DOCS_SRV passdb backend = tdbsam security = user add user script = /usr/sbin/useradd -m %u delete user script = /usr/sbin/userdel -r %u add group script = /usr/sbin/groupadd %g delete group script = /usr/sbin/groupdel %g add user to group script = /usr/sbin/usermod -G %g %u add machine script = \ /usr/sbin/useradd -s /bin/false -d /dev/null \ -g machines %u # The following specifies the default logon script # Per user logon scripts can be specified in the user # account using pdbedit logon script = logon.bat # This sets the default profile path. # Set per user paths with pdbedit logon path = \\%L\Profiles\%U logon drive = H: logon home = \\%L\%U domain logons = Yes os level = 35 preferred master = Yes domain master = Yes idmap uid = 15000-20000 idmap gid = 15000-20000 [homes] comment = Home Directories valid users = %S read only = No browseable = No writable = Yes [public] comment = Data path = /export force user = docsbot force group = users guest ok = Yes [netlogon] comment = Network Logon Service path = /var/lib/samba/netlogon/scripts admin users = ed, john, sam guest ok = No browseable = No writable = No # For profiles to work, create a user directory under the # path shown. mkdir -p /var/lib/samba/profiles/john [Profiles] comment = Roaming Profile Share path = /var/lib/samba/profiles read only = No browseable = No guest ok = Yes profile acls = Yes # Other resource shares ... ... |
| Anmerkung |
|---|---|
Wenn Sie mehr als einen Domänencontroller benötigen oder auch mehr als 250 Benutzer haben, dann benutzen Sie nicht ein tdbsam Backend zur Authentifizierung. LDAP wird in diesen Fällen empfohlen. |
14.3.3.2. Primary Domain Controller (PDC) unter Verwendung von LDAP
Die leistungsfähigste und vielseitigste Implementation eines Samba-PDC ist dessen Möglichkeit eines LDAP Passwort Backend. LDAP ist höchst anpassbar. LDAP-Datenbankserver können bei Redundanz zur Ausfallsicherung verwendet werden, indem Serverinhalte zu einem Samba-Server repliziert werden. Gruppen von LDAP PDCs und BDCs dienen als Lastenausgleichsgruppen und sind ideal für den Unternehmensbereich. Andererseits sind LDAP-Konfigurationen von Natur aus sehr komplex aufzusetzen und zu verwalten. Wenn zudem SSL mit LDAP verbunden werden muss, erhöht dies die Komplexität um ein Vielfaches. Selbst dann stellt LDAP bei sorgfältiger und präziser Planung die ideale Lösung im Unternehmensbereich dar.
Beachten Sie die passdb backend-Anweisung genauso wie spezifische LDAP Suffix-Spezifikationen. Obwohl die Samba-Konfiguration für LDAP sehr überschaubar ist, so ist die Installation von OpenLDAP nicht gerade einfach. LDAP sollte vor jeder Samba-Konfiguration installiert und konfiguriert werden. Beachten Sie dabei auch, dass Samba und LDAP sich nicht auf dem selben Server befinden müssen, um einwandfrei zu funktionieren. Es wird sogar angeraten, dass diese beiden in einer Umgebung im Unternehmensbereich getrennt werden.
[global] workgroup = DOCS netbios name = DOCS_SRV passdb backend = ldapsam:ldap://ldap.example.com username map = /etc/samba/smbusers security = user add user script = /usr/sbin/useradd -m %u delete user script = /usr/sbin/userdel -r %u add group script = /usr/sbin/groupadd %g delete group script = /usr/sbin/groupdel %g add user to group script = /usr/sbin/usermod -G %g %u add machine script = \ /usr/sbin/useradd -s /bin/false -d /dev/null \ -g machines %u # The following specifies the default logon script # Per user logon scripts can be specified in the # user account using pdbedit logon script = scripts\logon.bat # This sets the default profile path. # Set per user paths with pdbedit logon path = \\%L\Profiles\%U logon drive = H: logon home = \\%L\%U domain logons = Yes os level = 35 preferred master = Yes domain master = Yes ldap suffix = dc=example,dc=com ldap machine suffix = ou=People ldap user suffix = ou=People ldap group suffix = ou=Group ldap idmap suffix = ou=People ldap admin dn = cn=Manager ldap ssl = no ldap passwd sync = yes idmap uid = 15000-20000 idmap gid = 15000-20000 ... # Other resource shares ... ... |
| Anmerkung |
|---|---|
Die LDAP-Implementierung in dieser smb.conf-Datei setzt voraus, dass ein funktionierender LDAP-Server erfolgreich auf ldap.example.com installiert worden ist. |
14.3.3.3. Backup Domain Controller (BDC) unter Verwendung von LDAP
Ein BDC ist ein wesentlicher Bestandteil jeder Samba/LDAP-Lösung im Unternehmensbereich. Die smb.conf-Dateien zwischen dem PDC und BDC sind praktisch identisch bis auf die domain master-Anweisung. Gehen Sie sicher, dass der PDC auf den Wert Yes und der BDC auf den Wert No gesetzt ist. Wenn Sie mehrere BDCs für einen PDC besitzen, so ist die os level-Anweisung nützlich beim Setzen der BDC Wahlpriorität. Umso höher der Wert, umso höher die Serverpriorität, um Clients zu verbinden.
| Anmerkung |
|---|---|
Ein BDC kann entweder die LDAP-Datenbank des PDC benutzen oder auch seine eingene LDAP-Datenbank besitzen. Dieses Beispiel benutzt die LDAP-Datenbank des PDC wie in derpassdb backend-Anweisung. |
[global] workgroup = DOCS netbios name = DOCS_SRV2 passdb backend = ldapsam:ldap://ldap.example.com username map = /etc/samba/smbusers security = user add user script = /usr/sbin/useradd -m %u delete user script = /usr/sbin/userdel -r %u add group script = /usr/sbin/groupadd %g delete group script = /usr/sbin/groupdel %g add user to group script = /usr/sbin/usermod -G %g %u add machine script = \ /usr/sbin/useradd -s /bin/false -d /dev/null \ -g machines %u # The following specifies the default logon script # Per user logon scripts can be specified in the # user account using pdbedit logon script = scripts\logon.bat # This sets the default profile path. # Set per user paths with pdbedit logon path = \\%L\Profiles\%U logon drive = H: logon home = \\%L\%U domain logons = Yes os level = 35 preferred master = Yes domain master = No ldap suffix = dc=example,dc=com ldap machine suffix = ou=People ldap user suffix = ou=People ldap group suffix = ou=Group ldap idmap suffix = ou=People ldap admin dn = cn=Manager ldap ssl = no ldap passwd sync = yes idmap uid = 15000-20000 idmap gid = 15000-20000 ... # Other resource shares ... ... |