14.3. Samba-Servertypen und die smb.conf-Datei

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.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 [email protected]

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

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.