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.

AnmerkungAnmerkung
 

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.

AnmerkungAnmerkung
 

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.

WichtigWichtig
 

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:

root# net rpc join -U administrator%password

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.

WichtigWichtig
 

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
...
...

AnmerkungAnmerkung
 

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
...
...

AnmerkungAnmerkung
 

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.

AnmerkungAnmerkung
 

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
...
...

14.3.3.4. Primary Domain Controller (PDC) mit Active Directory

Obwohl es für Samba möglich ist ein Mitglied eines Active Directory zu sein, ist es Samba nicht möglich als ein Active Directory Domänencontroller zu agieren.