Über unsMediaKontaktImpressum
Stefan Kania 08. Juni 2014

Tanz' den Samba mit mir - Teil 4

Samba 4 als Domain Controller und Fileserver einrichten

Am 11.12.2012 war es endlich so weit: Samba 4 wurde veröffentlicht - Jahre nach der ersten Ankündigung. Samba sollte von Grund auf neu programmiert werden, und zwar inklusiveder File- and Print-Services. Ein weiterer wesentlicher Schwerpunkt lag auf der Active Directory-Funktionalität: Samba 4 sollte sich in ein Windows AD integrieren lassen oder dieses sogar ablösen können.

Immer wieder wurde spekuliert, wann Samba 4 endlich kommen wird. Die Wiki-Seite des Projekts gab eine klare Auskunft: "Es kommt, wenn es fertig ist."  Die Ankündigung zu einer völlig neuen Samba-Version wurde bereits 2004 von Andrew Tridgell bekannt gegeben.Eine komplette Neu-Entwicklung von Grund auf war beabsichtigt.

Später ließen die Entwickler diesen Gedanken fallen. Mittlerweile war Samba 3 für File- and Print-Services so weit fortgeschritten, dass diese in die neue Version übernommen wurden. Nur die Active Directory-Funktion wurde neu erstellt. Wer einen Samba 3 als File- oder als Printserver einrichten kann, wird daher auch mit Samba 4 keine Schwierigkeiten haben. Doch die Verwaltung der Benutzer und anderer Ressourcen hat sich grundlegend geändert.

Wer früher Samba 3 zusammen mit openLDAP für die Administration der Benutzer und Gruppen einsetzen wollte, musste diese Dienste erst einmal unter einen Hut bringen und einrichten. Sollte gar ein "single-sign-on" bereitgestellt werden, kam als dritter Dienst auch noch Kerberos dazu. Um diese gemeinsam zu installieren, war Zeit, eine Menge Geduld und Wissen erforderlich. Mit der neuen Version fassten die Samba-Entwickler diese Services zusammen: Bei der Installation und Konfiguration von Samba 4 werden neben Samba auch LDAP und Kerberos komplett eingerichtet. Sie stehen anschließend für die Verwaltung der Ressourcen zur Verfügung.

Oft kommt die Frage: "Warum kann ich meinen openLDAP nicht zusammen mit Samba 4 verwenden?" Die Antwort ist: openLDAP ist noch nicht so weit. Denn openLDAP ist (noch) nicht in der Lage, alle Funktionen bereitzustellen, die erforderlich sind, um ein genaues Abbild eines Windows Active Directories zu erstellen.

Samba 4 als Domaincontroller

Mit Samba 4 steht jetzt ein Dienst zur Verfügung, der sowohl ein eigenständiges Active Directory für Windows- und Linux-Clients als auch einen Domaincontroller als Teil einer Windows-Domäne bereitstellen kann. Die Administration des Active Directories kann auch mit den "Remote Server Administration Tools" (RSAT) durchgeführt werden. RSAT können kostenlos bei Microsoft heruntergeladen werden. Voraussetzung für die Tools ist lediglich eine Windows 7 Professional Arbeitsstation, die Mitglied der zu verwaltenden Domäne sein muss.

Dieser Artikel zeigt, wie ein Samba 4 als Domaincontroller auf einem Debian Wheezy einzurichten ist. Sie erfahren, wie Windows- und Linux-Clients in die Domäne aufgenommen werden. Ein weiterer Schwerpunkt soll die Einrichtung eines Fileservers sein. Im Zuge dessen werfen wir noch ein Blick auf das ID-Mapping: Wie werden aus der SID-RID Kombination einer Windows-Domäne die UIDs und GIDs für die Linux-Benutzer und Gruppen. Und worauf muss besonders geachtet werden?

Vorbereitung für den ersten Domaincontroller

In vielen Distributionen ist Samba 4 bereits als Paket in den Repositories enthalten; dabei handelt es sich aber meist um ältere Versionen von Samba 4. Um die aktuellste Version zu nutzen, empfiehlt es sich, auf die Pakete der Firma SerNet zurückzugreifen. Für diese Pakete werden eigene Repositories bereitgestellt, sodass die Version bei einem update des Systems auch immer aktualisiert wird. Die Pakete sind unter https://samba.plus/ verfügbar. Es ist lediglich eine Anmeldung mit einer gültigen Mailadresse erforderlich. Alle Pakete sind und bleiben kostenfrei. Es muss nur die nach der Anmeldung erhaltene ID in die Quelle eingetragen werden. Anschließend ist das benötigte Paket zu installieren.

Um einen Samba 4 Domaincontroller auf einem Debian Wheezy zu installieren, wird lediglich eine Debian-Maschine in der Grundinstallation ohne grafische Oberfläche benötigt. Die grafische Administration wird später über die "Remote Server Administration Tools" (RSAT) von einem Windows Client aus der Domäne durchgeführt.

Die folgenden Informationen müssen anschließend für die Konfiguration des Domaincontrollers zusammengestellt werden:

  • REALM: Der REALM wird für den Kerberos-Server benötigt. Der REALM wird bei der Einrichtung des DNS-Servers auch als DNS-Domainname verwendet.
  • NetBIOS-Domainname: Der NetBIOS-Domainname ist die Adresse, über die der Server per NetBIOS-Protokoll erreichbar ist. Der NetBIOS-Name sollte immer der erste Teil des REALMs sein.
  • Funktion des Servers: Die Rolle des Domaincontrollers ist anzugeben, da es sich um den ersten Server handelt.
  • DNS-Server: Samba 4 bringt einen eigenen DNS-Server mit. Dieser kann später auch über die RSAT verwaltet werden. Soll nicht der Samba 4 interne DNS verwendet werden, sondern ein bestehender "bind9" Nameserver, ist es erforderlich, dass dieser mindestens in der Version 9.8.x vorliegt, da sonst die dynamischen Updates des DNS nicht funktionieren. Für den Fall, dass ein externer DNS-Server Verwendung finden soll, werden während der Konfiguration des Domaincontrollers die benötigten Zonen-Dateien für den "bind9" generiert.
  • Die IP-Adresse eines eventuell benötigten DNS-Forwarders: An diese IP-Adresse werden alle DNS-Anfragen weitergeleitet, die nicht zur eigenen Zone gehören. Ohne einen Forward ist die Namensauflösung der Namen im Internet nicht möglich.

Anschließend kann das "Provisioning" durchgeführt werden. Dieser Vorgang entspricht dem "dcpromo" auf einem Windows-Domaincontroller. Listing 1 zeigt diesen Vorgang. Hier wird der interne DNS-Server verwendet.

Listing 1: Provisioning

root@samba4-1:~# samba-tool domain provision
Realm [EXAMPLE.NET]: 
 Domain [EXAMPLE]: 
 Server Role (dc, member, standalone) [dc]: 
 DNS backend (SAMBA_INTERNAL, BIND9_FLATFILE, BIND9_DLZ, NONE) [SAMBA_INTERNAL]: 
 DNS forwarder IP address (write 'none' to disable forwarding) [192.168.123.102]: 
Administrator password: 
Retype password: 
Looking up IPv4 addresses
Looking up IPv6 addresses
More than one IPv6 address found. Using 2003:5c:ad00:ea01:a00:27ff:fe36:66a1
Setting up share.ldb
Setting up secrets.ldb
Setting up the registry
Setting up the privileges database
Setting up idmap db
Setting up SAM db
Setting up sam.ldb partitions and settings
Setting up sam.ldb rootDSE
Pre-loading the Samba 4 and AD schema
Adding DomainDN: DC=example,DC=net
Adding configuration container
Setting up sam.ldb schema
Setting up sam.ldb configuration data
Setting up display specifiers
Modifying display specifiers
Adding users container
Modifying users container
Adding computers container
Modifying computers container
Setting up sam.ldb data
Setting up well known security principals
Setting up sam.ldb users and groups
Setting up self join
Adding DNS accounts
Creating CN=MicrosoftDNS,CN=System,DC=example,DC=net
Creating DomainDnsZones and ForestDnsZones partitions
Populating DomainDnsZones and ForestDnsZones partitions
Setting up sam.ldb rootDSE marking as synchronized
Fixing provision GUIDs
A Kerberos configuration suitable for Samba 4 has been generated at\\
 /var/lib/samba/private/krb5.conf
Once the above files are installed, your Samba4 server will be ready to use
Server Role: active directory domain controller
Hostname: samba4-1
NetBIOS Domain: EXAMPLE
DNS Domain: example.net
DOMAIN SID: S-1-5-21-1304111860-2806216092-3514381476

Damit der Server nutzbar ist, müssen Sie in der Datei "/etc/default/sernet-samba" noch den Modus "ad" aktivieren. Dann kann der Samba 4 mit dem Kommando "service sernet-samba-ad start" gestartet werden.

Testen der Umgebung

An dieser Stelle sollten Sie unbedingt testen, ob alle Dienste - Kerberos, DNS, LDAP und die Dateisystemdienste - auch korrekt funktionieren. Dazu gibt es verschiedene Möglichkeiten. Listing 2 zeigt den Test, ob alle Dienste von Samba 4 erreichbar sind.

Listing 2: Test der Samba-Dienste

root@samba4-1:~# netstat -tlp | grep samba
tcp 0 0 *:domain *:* LISTEN 3999/samba 
tcp 0 0 *:kerberos *:* LISTEN 3993/samba 
tcp 0 0 *:ldaps *:* LISTEN 3991/samba 
tcp 0 0 *:1024 *:* LISTEN 3987/samba 
tcp 0 0 *:3268 *:* LISTEN 3991/samba 
tcp 0 0 *:3269 *:* LISTEN 3991/samba 
tcp 0 0 *:ldap *:* LISTEN 3991/samba 
tcp 0 0 *:loc-srv *:* LISTEN 3987/samba 
tcp 0 0 *:kpasswd *:* LISTEN 3993/samba 
tcp6 0 0 [::]:domain [::]:* LISTEN 3999/samba 
tcp6 0 0 [::]:kerberos [::]:* LISTEN 3993/samba 
tcp6 0 0 [::]:ldaps [::]:* LISTEN 3991/samba 
tcp6 0 0 [::]:1024 [::]:* LISTEN 3987/samba 
tcp6 0 0 [::]:3268 [::]:* LISTEN 3991/samba 
tcp6 0 0 [::]:3269 [::]:* LISTEN 3991/samba 
tcp6 0 0 [::]:ldap [::]:* LISTEN 3991/samba 
tcp6 0 0 [::]:loc-srv [::]:* LISTEN 3987/samba 
tcp6 0 0 [::]:kpasswd [::]:* LISTEN 3993/samba

DNS dient unter Samba 4 nicht nur dazu, die Hostnamen aufzulösen. Vielmehr ist er so konfiguriert, dass auch die Dienste des Domaincontrollers über DNS bekanntgegeben werden. In Listing 3 erfolgt der Test des DNS.

Listing 3: Test der DNS

root@samba4-1:~# host samba4-1
samba4-1.example.net has address 192.168.123.200
samba4-1.example.net has IPv6 address 2003:5c:ad02:3c01:a00:27ff:fee7:e8d6

root@samba4-1:~# host -t SRV _kerberos._tcp.example.net
_kerberos._tcp.example.net has SRV record 0 100 88 samba4-1.example.net.

root@samba4-1:~# host -t SRV _ldap._tcp.example.net
_ldap._tcp.example.net has SRV record 0 100 389 samba4-1.example.net.

Um den Verbindungsaufbau zu den Freigaben zu testen, kann das Kommando "smbclient" verwendet werden. Dabei fällt auf, dass der Server schon die ersten Freigaben bereitstellt. Es handelt sich hierbei um die Freigabe "sysvol" in der später die Gruppenrichtlinien abgelegt werden und die Freigabe "netlogon" für die Logonskripte der Domäne. Listing 4 zeigt den Verbindungsaufbau.

Listing 4: Verbindung zu den Freigaben prüfen

root@samba4-1:~# smbclient -L localhost -U administrator
Domain=[EXAMPLE] OS=[Unix] Server=[Samba 4.1.2-SerNet-Debian-7.wheezy]

 Sharename Type Comment
 --------- ---- -------
 netlogon Disk 
 sysvol Disk 
 IPC\$ IPC IPC Service (Samba 4.1.2-SerNet-Debian-7.wheezy)
Domain=[EXAMPLE] OS=[Unix] Server=[Samba 4.1.2-SerNet-Debian-7.wheezy]

 Server Comment
 --------- -------

 Workgroup Master
 --------- -------

Um den Kerberos zu testen, muss das Paket "heimdal-clients" installiert werden, da sich in diesem Paket die entsprechenden Kommandos befinden. Anschließend muss die Datei "/var/lib/samba/private/krb5.conf" noch in das Verzeichnis "/etc" kopiert werden. Dann kann der Test wie in Listing 5 stattfinden.

Listing 5: Kerberos testen

root@samba4-1:~# kinit administrator
administrator@EXAMPLE.NET's Password: 

root@samba4-1:~# klist
Credentials cache: FILE:/tmp/krb5cc_0
 Principal: administrator@EXAMPLE.NET

 Issued Expires Principal

Nov 23 15:52:37 2013 Nov 24 01:52:31 2013 krbtgt/EXAMPLE.NET@EXAMPLE.NET

Einrichtung eines Zeitservers

Im Active Directory wird für die Replikation der Objekte auf jeden Fall ein Zeitserver benötigt, der in der Lage ist Signierungen durchzuführen. Dazu muss ein "ntp" in der Version 4.2.6 oder höher installiert werden. Um den Zeitserver zu konfigurieren, müssen Sie eine komplett neue Konfigurationsdatei "/etc/ntp.conf" wie in Listing 6 erstellen.

Listing 6: Konfiguration der /etc/ntp.conf

server 127.127.1.0
fudge 127.127.1.0 stratum 10
server 0.pool.ntp.org iburst prefer
server 1.pool.ntp.org iburst prefer
driftfile /var/lib/ntp/ntp.drift
logfile /var/log/ntp
ntpsigndsocket /var/lib/samba/ntp_signd/
restrict default kod nomodify notrap nopeer mssntp
restrict 127.0.0.1
restrict 0.pool.ntp.org mask 255.255.255.255 nomodify notrap nopeer noquery
restrict 1.pool.ntp.org mask 255.255.255.255 nomodify notrap nopeer noquery

Vor dem Neustart des Dienstes müssen Sie noch die Zugriffsrechte mittels "chgrp ntp /var/lib/samba/ntp_signd/" anpassen. Dann kann der Zeitserver neu gestartet werden.
 

Erste Schritte im AD

Nachdem Sie die Konfiguration des Domaincontrollers abgeschlossen haben, können Sie die ersten Ressourcen in der Domäne verwalten. Die Administration der Benutzer, Gruppen und Gruppenrichtlinien können Sie mit dem Kommandozeilen-tool "samba-tool" durchführen. Um eine Übersicht über die Möglichkeiten zu bekommen, die "samba-tool" bietet, können Sie das Kommando ohne Parameter eingeben. So werden alle Optionen angezeigt. Diese Hilfe können Sie für alle weiteren Unterkommandos auf dem selben Weg abfragen.

Es macht auf jeden Fall Sinn, die RSAT zu installieren, da die Administration mittels "samba-tool" recht schnell an ihre Grenzen stößt. Die RSAT stehen auf der Webseite von Microsoft hier zum kostenlosen Download zur Verfügung.

Da die Domäne an dieser Stelle vollständig konfiguriert ist, kann der erste Windows-Client wie gewohnt in die Domäne aufgenommen werden. Sie sollten darauf achten, dass in den Netzwerkeinstellungen des Clients auch der neue Domaincontroller als DNS-Server eingetragen ist, sonst kann der Client die Domäne und alle Dienste in der Domäne nicht finden. Nachdem der Client in die Domäne aufgenommen wurde und die RSAT installiert sind, kann die Domäne administriert werden.

In der Abbildung 1 ist die Übersicht über das Active Directory zu sehen. Die Benutzer, die hier zusätzlich zu den Standardbenutzern zu sehen sind, wurden über die Kommandozeilen mit dem Kommando "samba-tool" angelegt.

Alle weiteren Windows-Clients können jetzt in die Domäne aufgenommen werden. Benutzer, die in der Domäne existieren, können sich bereits anmelden. Aber noch fehlt den Benutzern ein Home-Directory und ein Speicherort für servergespeicherte Profile.

Auf dem Domaincontroller sollten grundsätzlich keine Daten gespeichert werden. Die Home-Directories und Profilverzeichnisse der Benutzer sowie alle Daten sollten Sie immer auf zusätzlichen Fileservern ablegen. Vor allen Dingen, wenn neben den Windows-Clients auch noch Linux-Clients in der Domäne vorhanden sind, sollten die Daten immer auf Fileservern liegen, da das ID-Mapping auf Domaincontrollern sich von dem ID-Mapping auf allen Linux-Clients und Samba-Servern unterscheidet.

Auf den Domaincontrollern übernimmt Samba 4 das ID-Mapping und vergibt IDs ab 3.000.000 für alle Objekte. Auf den Linux-Clients und Samba-Servern wird das ID-Mapping über den "winbind" realisiert. Dadurch kommt es zu unterschiedlichen IDs auf den Domaincontrollern und allen anderen Linux-Maschinen. Auf den Linux-Maschinen wird später die ID der Benutzer und Gruppen über den RID der Windows-Objekte erstellt. Sie ist dadurch auf allen Linux-Maschinen in der Domäne gleich.

Linux-Clients in der Domäne

Samba 4 kann als Domaincontroller auch für Linux-Clients als Authentifizierungsquelle dienen. Die Linux-Clients können dann die Authentifizierung über Kerberos durchführen und somit ist es auch für die Linux-Clients möglich ein "single-sign-on" zu realisieren. Für die Aufnahme in die Domäne ist es nicht relevant, ob die Linux-Maschine später ein echter Client mit grafischer Oberfläche werden soll oder ein Fileserver. Der Domänenbeitritt ist für beide identisch.

Für den Beitritt müssen auf dem Client wieder SerNet-Pakete installiert werden - jetzt aber nur die Pakete "sernet-samba-winbind", "sernet-samba" und "libpam-heimdal". Nach der Installation der Pakte muss die Datei "/etc/krb5.conf" vom Domaincontroller auf den Client kopiert und die Konfigurationsdatei "/etc/samba/smb.conf" muss neu mit dem Inhalt wie in Listing 7 angelegt werden.

Listing 7: smb.conf

[global]
 workgroup = example
 realm = EXAMPLE.NET
 security = ADS
 winbind enum users = yes
 winbind enum groups = yes
 winbind use default domain = yes
 winbind refresh tickets = Yes
 template shell = /bin/bash
 idmap config * : range = 1000000 - 1999999
 idmap config EXAMPLE : backend = rid
 idmap config EXAMPLE : range = 1000000 - 1999999

Die Parameter in der Datei haben die folgende Bedeutung:

workgroup = example
Hier wird der NetBIOS-Name der Domäne angegeben. Auch als Mitglied im AD heißt der Parameter "workgroup"

realm = EXAMPLE.NET
Bei dem realm handelt es sich um die Information für die Kerberos-Domäne. Für diesen realm wird sich der Samba-Server einen KDC suchen.

security = ADS
Damit wird festgelegt, dass der Server ein Mitglied in einer AD-Domäne ist.

winbind enum users = yes
Ohne diesen Parameter würden die Benutzer auf dem lokalen Linux-System nicht angezeigt und wären nicht nutzbar, um Rechte im Dateisystem vergeben zu können.

winbind enum groups = yes
Auch hier sorgt der Parameter dafür, dass die Gruppen im Linux-System sichtbar und für Berechtigungen verwendbar sind.

winbind use default domain = yes
Bei nur einer Domäne, kann mit diesem Parameter dafür gesorgt werden, dass nur der Benutzername von winbind übergeben wird, ohne die Domäne vor den Namen zu stellen.

winbind refresh tickets = yes
Mit diesem Parameter werden Kerberos-Tickets automatisch erneuert, wenn der Benutzer angemeldet ist und das Ticket abläuft.

template shell = /bin/bash
Dieser Parameter darf auf gar keinen Fall vergessen werden. Ohne diesen Parameter kann sich ein Benutzer aus dem AD zwar anmelden. Aber er wird sofort wieder abgemeldet, da der Benutzer im AD keine Shell zugewiesen bekommt, diese aber für eine erfolgreiche Anmeldung benötigt wird.

idmap config * : range = 1000000 - 1999999
Neben den Gruppen und Benutzern, die der Administrator angelegt hat, gibt es noch die "Build-in-Groups". Diese Gruppen haben einen eigenen verkürzten SID. Für diese Gruppen muss auch das ID-Mapping konfiguriert werden. Die Konfiguration der "Build-in-Groups" wird über den Stern in "idmap config * : range = 1000000 - 1999999" konfiguriert. Eigentlich müsste auch noch der Parameter "idmap config * : backend = tdb" in der Konfiguration eingetragen werden, aber dieser Parameter wird vom Samba 4 automatisch gesetzt.

idmap config EXAMPLE : backend = rid
Die IDs der Benutzer müssen aus den SIDs der AD-Benutzer generiert werden. Dazu gibt es verschiedene Möglichkeiten. Die Standardeinstellungen für den Winbind ist die Verwendung von tdb-Dateien. Dabei werden zufällige UIDs generiert, den Benutzern zugewiesen und in der tdb-Datei gespeichert. Der Nachteil dieses Verfahrens ist, dass so jeder Benutzer auf jedem Linux-System eine andere UID erhält. Durch den Wechsel auf das Backend "idmap_rid" wird immer der RID des Benutzers aus der AD-Domäne gewählt. Da dieser eindeutig ist, ist die ID der Benutzer und Gruppen auf dem Linux-System auch eindeutig. Der Benutzer hat dadurch auf allen Linux-Systemen in der gesamten Domäne immer die selbe UID. Ein Problem bekommt man so aber nicht in den Griff: Und zwar werden auf  den DCs der Domäne die UIDs immer im AD verwaltet und somit immer anders als auf den anderen Systemen in der Domäne. Die einfachste Möglichkeit dieses Problem zu umgehen ist, die Domain-Controller nicht als File-Server zu verwenden und alle Dateien immer auf anderen Samba-Servern in der Domäne abzulegen.

idmap config EXAMPLE : = 1000000 - 1999999
Hier wird der Bereich festgelegt, in dem sich die UIDs der Benutzer befinden sollen.

Nachdem die Konfiguration über die "smb.conf" abgeschlossen wurde, kann jetzt der Client mit dem Kommando "net rpc join EXAMPLE -Uadministrator" in die Domäne aufgenommen werden. Bevor sich die Dienste starten lassen, muss in der Datei
"/etc/default/sernet-samba" noch der "classic"-Modus eingestellt werden. Dann können die Dienste "smbd", "nmbd" und "winbind" gestartet werden.

Fehlt noch die Authentifizierung. Durch die Installation des Paketes "libpam-heimdal" sind die PAM-Einstellungen für die Authentifizierung bereits alle vorgenommen worden. Wichtig ist, dass die Datei "/etc/krb5.conf" auf jedem Client existiert
und in der gesamten Domäne identisch ist. Um die Authentifizierung zu testen, muss das Paket "heimdal-clients" installiert werden. Nach einer lokalen Anmeldung am Client oder einer Anmeldung über "ssh" kann dann mit "klist" das Kerberos-Ticket
überprüft werden. Damit ist die Konfiguration des Clients abgeschlossen.

Samba 4 als Fileserver

Um einen Linux-Client zu einem Fileserver zu machen, fehlen nur die Freigaben. Am Beispiel der Home-Directories, der Profilverzeichnisse und einer Datenfreigabe soll der Aufbau eines Fileservers beschrieben werden.

Um Freigaben auf einem Samba-Server einzurichten, gibt es zwei verschiedene Möglichkeiten: Zum einen können die Freigaben in die "smb.conf" eingetragen werden und zum anderen besteht die Möglichkeit die Freigaben in die Registry einzutragen.
Gerade wenn sehr viele Clients in der Domäne auf den Samba-Server zugreifen, ist es sinnvoll, die Freigaben ausschließlich über die Registry zu verwalten. Die Verwaltung der Freigaben in der Registry hat den Vorteil, dass nicht mehr jeder smbd-Prozess im System die Datei smb.conf neu lesen muss, wenn eine neue Freigabe erstellt wurde. Denn bei jeder Änderung der smb.conf muss jeder smbd-Prozess die Datei neu lesen. Da für jeden angemeldeten Benutzer in der Domäne je ein smbd-Prozess gestartet wird, kann die Auslastung des Systems dann sehr hoch werden.

Die Freigaben in der Registry werden über das Kommando "net conf" verwaltet. In Listing 8 wird das Anlegen einer Datenfreigabe mit zusätzlichen Parametern dargestellt.

Listing 8: Anlegen einer Freigabe
root@fileserver:~# net conf addshare reg-freigabe /daten/reg-freigabe writeable=y guest_ok=n "Eine Freigabe in der Registry"

root@fileserver:~# net conf setparm reg-freigabe "hide unreadable" "yes"

root@fileserver:~# net conf setparm reg-freigabe "browsable" "no"
Damit der Samba-Server auch die Freigaben aus der Registry ausließt und bereitstellt, muss die "[global]"-Section in der "smb.conf um die Zeile "registry shares = yes" erweitert werden. Sobald diese Zeile gesetzt ist, sind die Freigaben verfügbar. Der Samba-Dienst muss dafür nicht neu gestartet werden. Die Freigabe kann dann mittels "smbclient" - wie in Listing 9 zu sehen - angezeigt werden.
Listing 9: Freigabe anzeigen mit smbclient
root@filserver:~# smbclient -L localhost -Uadministrator
Enter administrator's password:
Domain=[EXAMPLE] OS=[Unix] Server=[Samba 4.1.2-SerNet-Debian-7.wheezy]

Sharename Type Comment
--------- ---- -------
IPC\$ IPC IPC Service \\
(Samba 4.1.2-SerNet-Debian-7.wheezy)
sysvol Disk
netlogon Disk
reg-freigabe Disk Eine Freigabe in der Registry
Domain=[EXAMPLE] OS=[Unix] Server=[Samba 4.1.2-SerNet-Debian-7.wheezy]

Server Comment
--------- -------

Workgroup Master
--------- -------

Sichern der Registry

Wenn die Freigaben in der Registry verwaltet werden, sollten diese auch regelmäßig gesichert werden. Das Sichern und Wiederherstellen der Registry wird über das Kommando "net registry" durchgeführt. Listing 10 zeigt das Auflisten, Sichern und Wiederherstellen der Freigaben aus der Registry.
Listing 10: Sichern und Wiederherstellen der Registry
root@fileserver:~# net registry export hklm\\software\\samba /dev/stdout
Windows Registry Editor Version 5.00

[hklm\\software\\samba]

[hklm\\software\\samba\\smbconf]

[hklm\\software\\samba\\smbconf\\reg-freigabe]
"path"="/daten/reg-freigabe"
"comment"="Eine Freigabe in der Registry"
"guest ok"="no"
"browsable"="no"
"hide unreadable"="yes"

[hklm\\software\\samba\\Group Policy]
;Local Variables:
;coding: UTF-8
;End:

root@fileserver:~# net registry export hklm\\software\\samba freigaben.reg

root@filserver:~# net registry import freigaben.regelmäßig

Die Freigabe der Home-Directories

Die Home-Directories der Benutzer sollen später beim Anlegen eines neuen Benutzers über RSAT automatisch auf dem Fileserver erstellt werden. Dazu ist es zwingend erforderlich, dass der Name der Freigabe "users" lautet. Die Home-Directories werden in der Standardeinstellung im Verzeichnis "/home/<DOMÄNE>/" verwaltet. Dieses Verzeichnis muss angelegt und mit den entsprechenden Rechten versehen werden. Anschließend können Sie die Freigabe erzeugen und danach den Benutzern über die RSAT ein Home-Directory zuweisen. Listing 11 zeigt alle Schritte für die Erstellung der Freigabe.
Listing 11: Freigabe der Home-Directories

root@fileserver:~# mkdir -m 775 /home/EXAMPLE

root@fileserver:~# chgrp 'Domain Admins' /home/EXAMPLE

root@fileserver:~# net conf addshare users /home/EXAMPLE writeable=y guest_ok=n "Home-Dirs"

root@fileserver:~# net conf setparm users "browsable" "no"

root@fileserver:~# net conf setparm users "create mask" "700"

root@fileserver:~# net conf setparm users "directory mask" "700"

Die Freigabe der Profilverzeichnisse

Jetzt fehlt noch die Freigabe für die Profile der Benutzer. Bei dieser Freigabe ist der Parameter "profile acls = yes" ein wichtiger Eintrag, der auf keinen Fall vergessen werden darf. Listing 12 zeigt alle Schritte für die Erstellung der Freigabe.
Listing 12: Freigabe der Profilverzeichnisse
root@fileserver:~# mkdir -m 1770 /profile

root@fileserver:~# chgrp 'Domain Users' /profile

root@fileserver:~# net conf addshare profile /profile writeable=y guest_ok=n "User Profile"

root@fileserver:~# net conf setparm profile "browsable" "no"

root@fileserver:~# net conf setparm profile "profile acls" "yes"

Wenn dann den Benutzern ein servergespeichertes Profil über die RSAT zugewiesen wird, dann wird bei der ersten Anmeldung eines Benutzers ein neues Verzeichnis in der Freigabe angelegt. Bei Windows 7 heißt das Verzeichnis dann "<username>.V2" bei einer Anmeldung von einer Windows XP Arbeitsstation heißt das Verzeichnis nur "<username>", dadurch können sich die verschiedenen Profilversionen nicht gegenseitig stören.

Zuweisung der Verzeichnisse auf einem Windows-Client

Nach dem Anlegen der Freigaben fehlt nur noch die Zuweisung. Damit die Benutzer ihre Home-Directories und die Profilverzeichnisse auch bei jeder Anmeldung nutzen können, müssen über die RSAT die Verzeichnisse jedem Benutzer zugewiesen werden. Abbildung 2 zeigt die Zuweisung des Home-Directories und des Profilverzeichnisses.
Um die Zuweisung der Freigaben einfacher zu gestalten, kann für die Benutzer eine Kopiervorlage erstellt werden. In dieser kann anstelle des Namens des Benutzers die Variable "%username%" verwendet werden. Beim Kopieren der Vorlage wird die
Variable dann durch den Anmeldenamen des Benutzers ersetzt.

Das Datenverzeichnis können Sie über ein Logon Script oder eine Gruppenrichtlinie zuweisen lassen. Logonskripte sind Windows-Batchdateien, die an das Profil des Benutzers gebunden sind. Die Logonskripte müssen in der Freigabe "netlogon" liegen. Im Profil wird lediglich der Name des Skripts angegeben, da Logonskripte immer relativ zu der Freigabe gesucht werden. Logonskripte sollten immer unter Windows erstellt werden - oder unter Linux mit einem Editor, der in der Lage ist eine Zeile, wie unter Windows üblich, mit einem "CR+LF" zu beenden, da sonst die Kommandos unter Windows nicht ausgeführt werden.

Zuweisung der Verzeichnisse auf einem Linux-Client

Auch unter Linux können die Freigaben des Samba-Fileservers genutzt werden. Dazu wird das Dateisystem "cifs" verwendet. Der Vorteil ist, dass Samba 4 die Grundfunktionen der "smb"-Protokollversion 3 unterstützt und somit eine verschlüsselte Datenübertragung möglich ist. Auch muss bei der Verwendung von "cifs" kein zusätzlicher Dienst wie "NFS" für die Linux-Clients eingerichtet werden. Da der Linux-Client bereits Mitglied der Domäne ist, können Sie hier auch die Kerberos-Authentifizierung verwenden.

Am einfachsten lassen sich die Samba-Freigaben mittels "pam_mount" bereitstellen. Dazu ist zunächst das Paket "libpam-mount" zu installieren. Nach der Installation des Paketes wird "pam_mount" über die Datei "/etc/security/pam_mount.conf.xml" konfiguriert. Listing 13 zeigt zwei Beispiele: Eines für die Heimatverzeichnisse der Benutzer und ein weiteres für Datenverzeichnisse.
Listing 13: Samba-Freigaben mit pam_mount erstellen
<volume
fstype="cifs"
server="fileserver.example.net"
path="users\\\%(DOMAIN_USER)"
mountpoint="/home/EXAMPLE/\%(DOMAIN_USER)"
options="sec=krb5,workgroup=EXAMPLE" />

<volume
user="\%(DOMAIN_USER)"
fstype="cifs"
server="fileserver.example.net"
path="alle"
mountpoint="/alle"
option="sec=krb5,workgroup=EXAMPLE" />
Damit werden die Freigaben bei der Anmeldung eines Benutzer automatisch gemountet. Dabei wird der Mountpoint automatisch erzeugt und bei der Abmeldung des Benutzers auch wieder gelöscht. So können jetzt die Daten des Samba-Servers
betriebssystemunabhängig bereitgestellt werden.

Fazit

Samba 4 bietet eine Menge an neuen Möglichkeiten, die sich nicht alle in einem Artikel erklären lassen. Neben den hier aufgeführten Funktionen kann Samba 4 auch mit allen Gruppenrichtlinen umgehen, die ein Windows Server 2008 R2 bereitstellen
kann. Auch kann Samba 4 sehr gut als Printserver in einer Domäne fungieren, der auch die "point-n-print" Funktion der Druckertreiberverteilung unterstützt. Durch den Einsatz mehrerer Domaincontroller wird auch die Ausfallsicherheit des
Anmeldedienstes erhöht. In der Zukunft werden noch weitere Funktionen der Windows-Domaincontroller implementiert werden. Einer der wichtigsten Punkte ist dabei die "Filesystemreplication" um die Freigabe "sysvol" wie auf Windows-Domaincontrollern replizieren zu können. Aber auch so ist Samba 4 eine echte alternative für die zentrale Verwaltung der Benutzer und Gruppen in heterogenen Netzen.

Autor

Stefan Kania

Stefan Kania ist Autor des Buches "Samba 4" und Mitautor der Bücher "Linux-Server" und "Shell-Programmierung" aus dem Galileo-Press Verlag.
>> Weiterlesen
Kommentare (0)

Neuen Kommentar schreiben