9.1. Betrieb einer Samba-Domäne auf Basis von Active Directory#
9.1.1. Installation#
Samba als AD-Domänencontroller kann auf allen UCS Directory Nodes mit der Applikation Active Directory-kompatibler Domänencontroller aus dem Univention App Center installiert werden. Alternativ kann das Softwarepaket univention-samba4 installiert werden. Auf den Systemrollen Primary Directory Node und Backup Directory Node muss zusätzlich univention-s4-connector installiert werden. Anschließend muss der Befehl univention-run-join-scripts aufgerufen werden. Weitere Informationen finden sich in Installation weiterer Software.
Ein Datei- und Druckserver kann auf UCS Managed Nodes mit der Applikation Windows-kompatibler Fileserver aus dem Univention App Center installiert werden. Alternativ kann das Softwarepakete univention-samba installiert werden. Anschließend muss der Befehl univention-run-join-scripts aufgerufen werden. Weitere Informationen finden sich in Installation weiterer Software.
Samba unterstützt auch den Betrieb als read-only domain controller. Die Einrichtung ist in Extended Windows integration documentation [7] dokumentiert.
9.1.2. Dienste einer Samba-Domäne#
9.1.2.1. Authentifizierungsdienst#
Benutzeranmeldungen können nur auf Microsoft Windows-Systemen erfolgen, die der Samba-Domäne beigetreten sind. Der Domänenbeitritt ist in Windows-Domänenbeitritt dokumentiert.
Benutzer, die sich an einem Windows-System anmelden, erhalten bei der Anmeldung ein Kerberos-Ticket, mit dem die weitere Authentifizierung durchgeführt wird. Mit diesem Ticket wird dann auf die Ressourcen der Domäne zugegriffen.
Häufige Fehlerquellen bei fehlschlagenden Anmeldungen sind:
Für eine funktionierende Kerberos-Authentifizierung ist eine Synchronisation der Systemzeiten zwischen Windows-Client und Domänencontroller zwingend erforderlich. In der Grundeinstellung wird beim Systemstart die Systemzeit über NTP aktualisiert. Dies kann mit dem Befehl w32tm /resync auch manuell erfolgen.
Während der Anmeldung müssen DNS-Service-Records aufgelöst werden. Der Windows-Client sollte daher als DNS-Nameserver die IP-Adresse des Domänencontrollers verwenden.
9.1.2.2. Dateidienste#
Ein Dateiserver stellt zentral benötigte Dateien über das Netz bereit und ermöglicht es unter anderem Benutzerdaten auf einem zentralen Server zu bündeln.
Die in UCS integrierten Dateidienste unterstützen eine Bereitstellung von Freigaben auf Basis von CIFS/SMB (siehe Verwaltung von Freigaben). Sofern das unterliegende Dateisystem Access Control Lists (ACLs) unterstützt (verwendbar bei ext4 und XFS) sind ACLs auch von Windows-Clients verwendbar.
Dateidienste können auch von Samba Active Directory-Domänencontrollern, d.h. auf UCS Directory Nodes bereitgestellt werden. Generell wird in Samba-Umgebungen - analog zu den Microsoft-Empfehlungen für Active Directory - empfohlen Domänencontroller- und Datei/Druckdienste zu trennen, d.h. UCS Directory Nodes für die Anmeldung und Managed Nodes für Datei-/Druckdienste zu verwenden. Dies stellt sicher, dass hohe Last auf einem Fileserver nicht zu Störungen im Anmeldedienst führen. Für kleine Umgebungen, in denen keine Möglichkeit für den Betrieb zweier Server gegeben ist, können Datei- und Druckdienste auch mit auf einem Domänencontroller betrieben werden.
Samba unterstützt das CIFS-Protokoll und den Nachfolger SMB2. Verwendet man einen Client, der SMB2 unterstützt (ab Windows Vista, also auch Windows 7/8), verbessert sich die Performance und die Skalierbarkeit.
Das Protokoll kann über die Univention Configuration Registry-Variable samba/max/protocol konfiguriert werden. Sie muss auf allen Samba-Servern gesetzt und anschließend der/die Samba-Server neu gestartet werden.
NT1konfiguriert CIFS (unterstützt von allen Windows-Versionen)SMB2konfiguriert SMB2 (unterstützt ab Windows Vista/Windows 7)SMB3konfiguriert SMB3 (unterstützt ab Windows 8)
9.1.2.3. Druckdienste#
Samba bietet die Möglichkeit, unter Linux eingerichtete Drucker als Netzwerkdrucker für Windows-Clients freizugeben. Die Verwaltung der Druckerfreigaben und die Integration der Druckertreiber ist in Druckdienste beschrieben.
Druckdienste können auch mit Samba AD-Domänencontrollern bereitgestellt werden. Hierbei sind die in Dateidienste beschriebenen Einschränkungen zu beachten.
9.1.2.4. Univention S4 Connector#
Samba stellt einen separaten LDAP-Verzeichnisdienst bereit. Die Synchronisation zwischen dem UCS-LDAP und dem Samba-LDAP erfolgt durch einen internen Systemdienst, den Univention S4 Connector. Der Connector ist standardmäßig auf dem Primary Directory Node aktiviert und benötigt normalerweise keine weitere Konfiguration.
Hinweise zum Status der Synchronisation finden sich in der Logdatei /var/log/univention/connector-s4.log. Weitere Informationen zur Fehleranalyse von eventuellen Connectorproblemen finden sich in KB 32 - Samba 4 Troubleshooting.
Mit dem Befehl univention-s4search kann im Samba-Verzeichnisdienst gesucht werden. Wird es als Benutzer root aufgerufen, werden automatisch die nötigen Credentials des Maschinenkontos verwendet:
$ root@primary:~# univention-s4search sAMAccountName=Administrator
# record 1
dn: CN=Administrator,CN=Users,DC=example,DC=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: Administrator
instanceType: 4
(..)
9.1.2.5. DRS-Replikation der Verzeichnisdaten#
Samba/AD-Domänen verwenden das Directory Replication System (DRS) zur Replikation der Verzeichnisdaten. DRS erlaubt Multimasterreplikation, d.h. die schreibenden Änderungen mehrerer Samba/AD-Domänencontroller werden auf Protokollebene synchronisiert. Die Verwendung von Snapshots in Virtualisierungslösungen sollte daher beim Einsatz von Samba/AD vermieden und Samba/AD auf einem Server betrieben werden, der durchgehend eingeschaltet bleibt.
Mit jedem weiteren Samba/AD-Domänencontroller steigt die Komplexität der Multimasterreplikation. Es sollte daher geprüft werden, ob weitere Samba/AD-Domänencontroller auf Basis von UCS Directory Nodes nötig sind oder für neue Server nicht ein UCS Managed Node die bessere Wahl ist.
Hinweise zur Analyse von DRS-Replikationsproblemen finden sich in KB 32 - Samba 4 Troubleshooting.
9.1.3. Konfiguration und Management von Windows-Desktops#
9.1.3.1. Gruppenrichtlinien#
Gruppenrichtlinien sind eine Active Directory-Funktion, die die zentrale Konfiguration von Vorgaben für Rechner und Benutzer erlaubt. Gruppenrichtlinien werden auch von Samba/AD-Domänen unterstützt. Die Richtlinien greifen nur auf Windows-Clients; Linux- oder Mac OS-Systeme werten die Richtlinien nicht aus.
Gruppenrichtlinien werden ausgehend von der englischen Bezeichnung Group policy objects auch oft als GPOs bezeichnet. Genauer gesagt kann ein Gruppenrichtlinienobjekt eine Reihe von Richtlinien beinhalten. Trotz ihres Namens lassen sich Gruppenrichtlinienobjekte nicht direkt bestimmten Benutzergruppen zuweisen, sondern sie werden vielmehr mit bestimmten AD-Verwaltungseinheiten (Domänen, Sites oder Organisationseinheiten) im Samba-Verzeichnisdienst (Samba AD/DS) verknüpft und beziehen sich dadurch auf untergeordnete Objekte. Eine gruppen- oder benutzerspezifische Auswertung ist nur indirekt über die Sicherheitseinstellungen eines Gruppenrichtlinienobjekts möglich, in denen sich das Recht Gruppenrichtlinie übernehmen gezielt auf bestimmte Gruppen, Benutzer oder Computer einschränken lässt.
Grundsätzlich sind die Gruppenrichtlinien (Group Policies (GPO)) von den sehr ähnlich benannten Gruppenrichtlinieneinstellungen (Group Policy Preferences (GPP)) zu unterscheiden:
Die über Gruppenrichtlinien (GPOs) getroffenen Vorgaben sind bindend, während sich über Gruppenrichtlinieneinstellungen (GPPs) nur Präferenzen in die Registry von Windows-Clients eintragen lassen, die aber unter Umständen am Client überschrieben werden können.
Die über Gruppenrichtlinien (GPOs) getroffenen Vorgaben werden zudem dynamisch auf die Zielobjekte angewendet, wo hingegen die über Gruppenrichtlinieneinstellungen (GPPs) getroffenen Einstellungen statisch in die Registry von Windows-Clients eintragen werden (man spricht hier auch von Tattooing).
Aus diesen Gründen sind Gruppenrichtlinien (GPOs) in den meisten Fällen den Gruppenrichtlinieneinstellungen (GPPs) vorzuziehen. Dieses Kapitel bezieht sich im weiteren ausschließlich auf Gruppenrichtlinien (GPOs).
Gruppenrichtlinien werden im Gegensatz zu den UCS-Richtlinien (siehe Richtlinien) nicht über UMC-Module, sondern mit einem separaten Editor konfiguriert, mit der Gruppenrichtlinienverwaltung, die Teil der Remote Server Administration Tools (RSAT) ist. Die Einrichtung ist in Installation der Gruppenrichtlinienverwaltung dokumentiert.
Es existieren zwei Arten von Richtlinien:
- Benutzerrichtlinien
Benutzerrichtlinien konfigurieren die Einstellungen eines Benutzers, z.B. die Vorkonfiguration des Desktops. Auch Anwendungen können über Gruppenrichtlinien konfiguriert werden (z.B. die Startseite des Browsers oder Einstellungen in LibreOffice).
- Computer-Richtlinien
Computer-Richtlinien definieren die Einstellungen von Windows-Clients.
Computerrichtlinien werden erstmals beim Systemstart ausgewertet, Benutzerrichtlinien bei der Anmeldung. Die Richtlinien werden auch für angemeldete Benutzer/laufende Systeme fortlaufend ausgewertet und aktualisiert (in der Grundeinstellung alle 90-120 Minuten, der Zeitraum wird zur Vermeidung von Lastspitzen nach dem Zufallsprinzip variiert).
Die Auswertung der Gruppenrichtlinien kann durch Aufruf des Befehls gpupdate /force auch gezielt gestartet werden.
Einige Richtlinien - z.B. zur Installation von Software oder für Anmeldeskripte - werden nur bei der Anmeldung (Benutzerrichtlinien) oder beim Systemstart (Rechnerrichtlinien) ausgewertet.
Die meisten Gruppenrichtlinien setzen nur einen Wert in der Windows-Registry, der dann von Windows oder einer Applikation ausgewertet wird. Da Standardbenutzer keine Einstellungen in dem entsprechenden Teil der Windows Registry editieren können, können so auch eingeschränkte Benutzer-Desktops konfiguriert werden, in denen z.B. Benutzer den Windows Task Manager nicht aufrufen dürfen.
Die Gruppenrichtlinien werden in der SYSVOL-Freigabe gespeichert, siehe Synchronisation der SYSVOL-Freigabe. Sie werden mit Benutzer- und Rechnerkonten im Samba-Verzeichnisdienst verknüpft.
Installation der Gruppenrichtlinienverwaltung#
Die Gruppenrichtlinienverwaltung kann als Teil der Remote Server Administration Tools auf Windows Clients installiert werden. Sie können für Windows 10 unter Remote Server Administration Tools (RSAT) for Windows 10 bezogen werden.
Abb. 9.1 Aktivierung der Gruppenrichtlinienverwaltung#
Nach der Installation muss die Gruppenrichtlinienverwaltung in der Windows-Systemsteuerung noch aktiviert werden, in dem unter die Option Tools für die Gruppenrichtlinienverwaltung aktiviert wird.
Nach der Aktivierung kann die Gruppenrichtlinienverwaltung unter aufgerufen werden.
Konfiguration von Richtlinien mit der Gruppenrichtlinienverwaltung#
Gruppenrichtlinien können nur von Benutzern konfiguriert werden, die Mitglied der Gruppe Domain Admins sind (z.B. der Administrator). Bei der Anmeldung muss beachtet werden, dass keine Anmeldung mit dem lokalen Administrator-Konto erfolgt, sondern mit dem Administrator-Konto der Domäne. Die Gruppenrichtlinienverwaltung kann auf einem beliebigen System der Domäne aufgerufen werden.
Wenn mehr als ein Samba-Domänencontroller eingesetzt wird, muss die Replikation der GPO-Daten berücksichtigt werden, siehe Konfiguration von Gruppenrichtlinien in Umgebungen mit mehr als einem Samba-Domänencontroller.
Es gibt zwei prinzipielle Möglichkeiten GPOs zu erstellen:
Sie können im Gruppenrichtlinienobjekte-Order angelegt und dann mit verschiedenen Positionen im LDAP verknüpft werden. Dies ist sinnvoll, wenn eine Richtlinie mit mehreren Positionen im LDAP verknüpft werden soll.
Die GPO kann ad hoc an einer LDAP-Position erstellt und dabei direkt verknüpft werden. Für kleine und mittlere Domänen ist das der einfachere Weg. Auch ad hoc erstellte Domänen werden im Gruppenrichtlinienobjekte-Ordner angezeigt.
Eine Richtlinie kann drei Zustände annehmen; sie kann aktiviert, deaktiviert oder nicht gesetzt sein. Die Auswirkung bezieht sich immer auf die Formulierung der Richtlinie. Wenn diese beispielsweise Deaktiviere Feature xy heißt, muss die Richtlinie aktiviert werden um das Feature abzuschalten. Einige Richtlinien haben zusätzliche Optionen, z.B. könnte die Richtlinie Aktiviere Mail-Quota eine zusätzliche Option mitbringen um die Speichermenge zu verwalten.
Abb. 9.2 Bearbeiten einer Richtlinie#
Zwei Standard-Richtlinienobjekte sind vordefiniert:
- Default Domain Policy
Das Default Domain Policy Objekt kann verwendet werden, um globale Richtlinien für alle Benutzer und Rechner der gesamten Domäne zu konfigurieren.
- Default Domain Controllers Policy
Das Default Domain Controllers Policy Objekt hat in einer Samba-Domäne keine Verwendung (in einer Microsoft AD-Domäne würden die Richtlinien für Microsoft-Domänencontroller über dieses Objekt erfolgen). Die Konfiguration der Samba-Domänencontroller erfolgt in UCS weitgehend über Univention Configuration Registry.
AD-Domänen können in Sites strukturiert werden. Dies kann z.B. verwendet werden um Standorte in einer Domäne zu gruppieren. Im Hauptmenü der Gruppenrichtlinienverwaltung werden alle Sites aufgeführt. Dort findet sich auch eine Liste von Domänen. Die aktuellen Samba-Versionen unterstützen keine Forest-Domänen, so dass hier immer nur eine Domäne angezeigt wird.
Eine Domäne kann in verschiedene Organisationseinheiten (OUs) strukturiert werden. Dies kann z.B. verwendet werden, um die Mitarbeiter der Buchhaltung und die Benutzer der Verwaltung in unterschiedlichen LDAP-Positionen zu speichern.
Gruppenrichtlinien können sich gegenseitig überlagern. Es gilt das Prinzip der Vererbung, d.h. höherliegende Richtlinien überschreiben die untergeordneten. Die effektiven Richtlinien für einen Benutzer können sowohl mit dem Modellierungsassistenten der Gruppenrichtlinienverwaltung als auch an der Windows-Kommandozeile mit dem Befehl gpresult /user BENUTZERNAME /v auf dem Windows-Client angezeigt werden.
Abb. 9.3 Auswertung der GPO für den Benutzer user01#
Die Richtlinien werden in folgender Reihenfolge ausgewertet:
Richtlinien der Default Domain Policy gelten als Grundeinstellung für alle Benutzer und Rechner der gesamten Domäne.
Mit einer OU verknüpfte Richtlinien überschreiben Richtlinien aus der Default Domain Policy. Sind OUs weiter verschachtelt, greifen im Konfliktfall die jeweils „untersten“ Richtlinien, d.h. die, die näher am Zielobjekt verknüpft sind. Es gilt folgende Auswertungsreihenfolge:
Zuweisung einer Richtlinie zu einem Active Directory Standort
Vorgaben der Default Domain Policy
Zuweisung einer Richtlinie zu einer Organisationseinheit / OU (jede unterliegende OU überstimmt wiederum Richtlinien aus übergeordneten OUs).
Ein Beispiel: Eine Firma verbietet allgemein den Zugriff auf den Windows Task Manager. Dazu wird im Default Domain Policy-Objekt die Richtlinie Zugriff auf Task Manager unterbinden aktiviert. Für einige technisch versierte Benutzer soll der Task Manager dennoch verfügbar sein. Diese Benutzer sind in der OU Technik abgelegt. Nun wird ein zusätzliches Gruppenrichtlinienobjekt angelegt, in dem Richtlinie Zugriff auf Task Manager unterbinden auf deaktiviert gesetzt wird. Dieses neue GPO wird mit der OU Technik verbunden.
Konfiguration von Gruppenrichtlinien in Umgebungen mit mehr als einem Samba-Domänencontroller#
Eine Gruppenrichtlinie besteht technisch aus zwei Teilen: Zum einen gibt es ein Verzeichnis im Dateisystem der Domänencontroller, das die eigentlichen Richtlinien-Dateien enthält, die auf dem Windows-System umgesetzt werden sollen (gespeichert in der SYSVOL-Freigabe (siehe Synchronisation der SYSVOL-Freigabe)). Zum anderen gibt es ein gleichnamiges Objekt im LDAP-Baum des Samba-Verzeichnisdienstes (Samba AD/DS), das üblicherweise unter einem LDAP-Container namens Group Policy Objects abgelegt ist.
Während die LDAP-Replikation zwischen Domänencontrollern innerhalb weniger Sekunden umgesetzt ist, werden die Dateien in der SYSVOL-Freigabe in der Grundeinstellung nur alle fünf Minuten repliziert. Es ist zu beachten, dass die Anwendung von neu konfigurierten Gruppenrichtlinien in diesem Zeitraum fehlschlagen kann, falls ein Client zufällig einen Domänencontroller konsultiert, der noch nicht die aktuellen Dateien zu sich repliziert hat.
Administrative Vorlagen (ADMX/ADM)#
Die in der Gruppenrichtlinienverwaltung angezeigten Richtlinien können durch sogenannte Administrative Vorlagen erweitert werden. In einer solchen Vorlage wird definiert, unter welchem Namen die Richtlinie in der Gruppenrichtlinienverwaltung erscheinen soll und welcher Wert dadurch in der Windows-Registry gesetzt wird. Administrative Vorlagen werden in sogenannten ADMX-Dateien (früher ADM-Dateien) gespeichert, siehe Group Policy ADMX Syntax Reference Guide [8].
ADMX-Dateien bieten unter anderem den Vorteil, dass sie zentral über mehrere Domänencontroller bereitgestellt werden können, damit die Gruppenrichtlinienverwaltung an allen Windows-Clients die gleichen Konfigurationsmöglichkeiten zeigt, siehe How to Implement the Central Store for Group Policy Admin Templates, Completely (Hint: Remove Those .ADM files!) [9].
Das folgende Beispiel für eine ADM-Datei definiert eine Rechner-Richtlinie, in der ein Registry-Key des (fiktiven) Univention RDP-Client konfiguriert wird. ADM-Dateien können über Drittwerkzeuge in das neuere ADMX-Format umgewandelt werden. Die administrativen Vorlagen müssen die Dateiendung .adm verwenden:
CLASS MACHINE
CATEGORY "Univention"
POLICY "RDP-Client"
KEYNAME "Univention\RDP\StorageRedirect"
EXPLAIN "Ist diese Option aktiviert, wird Soundausgabe im RDP-Client aktiviert"
VALUENAME "Sound-Weiterleitung"
VALUEON "Aktiviert"
VALUEOFF "Deaktiviert"
END POLICY
END CATEGORY
Abb. 9.4 Die eingebundene administrative Vorlage#
Die ADM-Datei kann anschließend in das ADMX-Format umgewandelt oder aber direkt über die Gruppenrichtlinienverwaltung importiert werden. Dazu wird im Kontextmenü aufgerufen. Mit Hinzufügen kann dann eine ADM-Datei importiert werden. Die administrativen Vorlagen werden ebenfalls in der SYSVOL-Freigabe gespeichert und repliziert, wodurch die Gruppenrichtlinienverwaltung von den Windows-Clients aus auf sie zugreifen kann.
Anwendung von Richtlinien auf Basis von Rechnereigenschaften (WMI-Filter)#
Richtlinien können auch auf Basis von Systemeigenschaften konfiguriert werden. Diese Eigenschaften werden über die Windows Management Instrumentation-Schnittstelle (WMI) bereitgestellt. Der darauf aufbauende Mechanismus wird als WMI-Filterung bezeichnet. Damit ist es beispielsweise möglich, eine Richtlinie nur auf PCs mit einer 64 Bit-Prozessor-Architektur oder mit mindestens 8 GB RAM anzuwenden. Ändert sich eine Eigenschaft eines Systems (z.B. weil mehr Speicher eingebaut wurde), wird der jeweilige Filter automatisch vom Client neu ausgewertet.
Die WMI-Filter werden in der Domänenstruktur im Container WMI-Filter angezeigt. Mit Neu kann ein weiterer Filter definiert werden. Unter Abfragen werden die Filterregeln definiert. Die Regeln werden in einer SQL-ähnlichen Syntax definiert. Regel-Beispiele finden sich in Microsoft [10] und Heitbrink [11].
9.1.3.3. Konfiguration des Servers, auf dem das Heimatverzeichnis abgelegt wird#
Das Heimatverzeichnis wird benutzerbezogen im UMC-Modul Benutzer definiert, siehe Verwaltung von Benutzern über Univention Management Console Modul. Dies erfolgt mit der Einstellung Windows-Heimatverzeichnis, z.B. \ucs-file-servermeier.
Für das Zuweisen des Heimatverzeichnis-Servers an mehrere Benutzer auf einmal kann der Mehrfachbearbeitungsmodus von UMC-Modulen verwendet werden, siehe Bearbeiten von Objekten.
9.1.3.4. Servergespeicherte Profile#
Samba unterstützt servergespeicherte Profile, d.h. Einstellungen der Benutzer werden auf einem Server gespeichert. In diesem Verzeichnis werden auch die Dateien gespeichert, die der Benutzer im Ordner Eigene Dateien speichert. Sie werden zwischenzeitlich lokal auf dem Windows-Rechner vorgehalten und erst bei der Abmeldung auf den Samba-Server synchronisiert.
In Samba-Domänen mit Active Directory-Support werden in der Voreinstellung keine serverseitigen Profile verwendet.
Das Profilverzeichnis kann über eine Gruppenrichtlinie konfiguriert werden, die unter zu finden ist. Wenn hier z.B. der UNC-Pfad %LOGONSERVER%\%USERNAME%\windows-profiles\default eingetragen wird, dann werden die Verzeichnisse windows-profiles\default.V? im Heimatverzeichnis des Benutzers auf dem jeweils gewählten Logonserver verwendet.
Alternativ kann das Profilverzeichnis individuell für einzelne Benutzerkonten definiert werden. Das ist im UMC-Modul Benutzer unter dem Reiter Konto des Benutzerkontos über das Feld Profilverzeichnis möglich. Der entsprechende UDM-Attributname heißt profilepath. Mit OpenLDAP als Backend wird dies im LDAP-Attribut sambaProfilePath gespeichert.
Wird der Profilpfad geändert, wird ein neues Profilverzeichnis angelegt. Die Daten aus dem alten Profilverzeichnis bleiben dabei erhalten und können manuell in das neue Profilverzeichnis kopiert beziehungsweise verschoben werden. Abschließend kann das alte Profilverzeichnis gelöscht werden.
Bemerkung
Der Administrator-Benutzer greift standardmäßig mit root-Berechtigungen auf Freigaben zu. Wenn dadurch das Profilverzeichnis mit root als Benutzer angelegt wird, sollte es manuell mit dem Befehl chown an den Administrator vergeben werden.