Wie man Samba als Domänencontroller konfiguriert

© srapulsar38, 123RF

Samba senkt Verwaltungskosten

Eine der wichtigsten Funktionen von Samba ist die eines Domänencontrollers. Gegenüber einer reinen Windows-Lösung spart Samba Lizenzkosten und hat den Nebeneffekt, dass die Benutzer sich auch von Linux- oder OS X-Clients aus anmelden können. Wie eine solche Installation funktioniert, erklärt dieser Beitrag.
Seit Jahren erwartet, ist endlich Version 4 des Samba-Servers erschienen, der nun als vollwertige Alternative zu Microsofts Active Directory dienen kann. In der ... (mehr)

Sehr oft kommt Samba als Domänencontroller in einer heterogenen Umgebung zum Einsatz, wo es die Benutzer und Gruppen einer Domäne zentral verwaltet. Dabei können dem Samba-Server verschiedene Rollen übertragen werden, über die man sich zuallererst klar werden sollte: Er lässt sich als Primärer Domänencontroller (PDC), als Backup Domänencontroller (BDC) oder als Fileserver konfigurieren.

Für die Planung einer Samba-Umgebung ist zweitens das Passdb-Backend entscheidend. Dabei geht es um verschiedene Datenbanken, die die Benutzerinformationen speichern. Für sie gibt es drei Möglichkeiten:

1. »smbpasswd« : Bei dem Smbpasswd-Backend handelt es sich um eine ASCII-Textdatei, die alle Benutzerinformationen aufnimmt. Dieses Backend sollte man heute nicht mehr benutzen, denn es hat verschiedene Nachteile – so sind zum Beispiel immer nur schreibende Zugriffe gleichzeitig möglich.

2. »tdbsam« : Das Tdbsam-Backend ist das Standard-Backend nach der Samba-Installation und ist auf jeden Fall ausreichend, wenn nur ein PDC einzurichten ist und nicht mehr als 250 Benutzer zu verwalten sind. Da die Replikation auf einen anderen Server aber nicht so einfach ist, ist die Einrichtung eines BDCs kompliziert und auch recht unsicher.

3. »ldapsam« : Das Ldapsam-Backend unterliegt keiner Größenbeschränkung und es lassen sich beliebig viele BDCs eingerichten. Allerdings braucht man dafür auf jeden Fall eine LDAP-Infrastruktur. Dafür ist das Backend dann aber auch so flexibel, dass selbst Linux- und OS-X-Clients die Authentifizierung zentral abwickeln können.

Der vorliegende Artikel beschränkt sich auf das Tdbsam-Backend und erklärt nur am Ende, welche Änderungen vorzunehmen sind, um einen PDC und einen BDC zusammen mit einem LDAP-Server zu betreiben.

PDC-Einstellungen

Die gesamte Konfiguration des Samba-Servers landet immer in der Datei »/etc/samba/smb.conf« . Um den Samba-Server als PDC zu konfigurieren, bedarf es dort der Einstellungen aus Listing 1. Neben diesen Parametern kann man auch gleich die ersten Freigaben eintragen.

Listing 1

PDC-Einstellungen

 

Ein wichtiger Parameter ist der NetBios-Name der Windows-Domäne, den der Parameter »workgroup = ADMINDOM« definiert. Der Parameter »server string = \%h Samba Admin-Magazin« erzeugt einen Kommentar in der Netzwerkumgebung der Windows-Clients. Die Variable »%h« übernimmt den NetBios-Name des PDCs, den der Eintrag »netbios name = Admin-Magazin« festlegt. Ist dieser Parameter nicht gesetzt, wird der Hostname des Linux-Systems als NetBios-Name verwendet.

Der Parameter »domain master = yes« sorgt dafür, dass der Samba-Server als PDC fungiert. Setzt der Admin diesen Wert auf »no« , arbeitet der Samba-Server als BDC. Der Parameter »domain logons = yes« erlaubt das Anmelden von Benutzern. Er muss sowohl beim PDC als auch beim BDC auf »yes« gesetzt sein. Der Parameter »os level = 99« legt fest, wie viele Punkte der Samba-Server bei der Wahl des Master-Browsers in der Domäne hat. Mit einem Wert von »99« gewinnt der Samba-Server die Wahl immer und fungiert so immer als Master-Browser. Hat man die Einträge in der »smb.conf« vorgenommen, sollte man die Datei auf jeden Fall auf Syntaxfehler prüfen. Das klappt mit dem Kommando »testparm« – wie, demonstriert Listing 2.

Listing 2

Syntaxcheck

 

Das Verfahren nach Listing 2 zeigt alle Parameter und auch etwaige Syntaxfehler an. Die Meldung zu »rlimit_max: ...« ist lediglich ein Hinweis, dass der Wert mit »1024« zu gering ist und nach oben korrigiert wurde. Diese Meldung kann der Tester einfach ignorieren. Wer sie dauerhaft loswerden will, findet Hinweise in [1].

Die Ausgaben von »testparm« zeigen auch, dass der Samba-Server jetzt die Rolle des PDCs übernimmt. Damit ist die Grundkonfiguration des PDCs abgeschlossen. Im nächsten Schritt geht es darum, die Voraussetzungen für den Betrieb als Domänencontroller herzustellen.

Neben der Möglichkeit, die Parameter mit einem Editor direkt in die Datei »smb.conf« zu schreiben, bringt Samba das webbasierte Tool SWAT mit. Mithilfe dieses Tools kann die gesamte Konfiguration auch grafisch durchgeführt werden. Ist zusätzlich zum SWAT auch noch das Paket »samba-doc« installiert, ist zu jedem Parameter auch eine Hilfe verfügbar. Der SWAT bringt einen eigenen Web-Server mit, der aber nicht selbstständig gestartet werden kann. Der SWAT benötigt immer den »xinetd« für den Start und der wiederum braucht eine passende Konfigurationsdatei. Die muss dann in dem Verzeichnis »/etc/xinetd.d« abgelegt werden. Listing 3 zeigt diese Konfigurationsdatei.

Listing 3

SWAT-Konfiguration

 

Der Parameter »only_from« muss an die eigene Umgebung angepasst oder ganz aus der Konfiguration entfernt werden. Dieser Parameter regelt den Zugriff auf den SWAT. Nach dem Neustart des »xinetd« lässt sich SWAT über »http://IP-des-Samba-Servers:901« erreichen. In Abbildung 1 wird der »global« -Bereich der »smb.conf« dargestellt.

Abbildung 1: Darstellung der globalen Parameter im SWAT.

Einrichten von Gruppen

In der Windows-Welt gibt es bestimmte Gruppen, die auf jeden Fall benötigt werden, um eine Domäne zu verwalten. Die Tabelle 1 zeigt eine Übersicht aller vorkommenden Gruppen.

Tabelle 1

Gruppen

Gruppenname

RID

benötigt

englische Bezeichnung

Domänenadmins

512

 Ja

Domainadmins

Domänenbenutzer

513

 Ja

Domainusers

Domänengäste

514

 Ja

Domainguests

Domänencomputer

515

 Nein

Domain Computers

Domänencontroller

516

 Nein

Domain Controllers

Domänen-Certificate-Administratoren

517

 Nein

Domain Certificate Admins

Domänen-Schema-Administratoren

518

 Nein

Domain Schema Admins

Domänen-Enterprise-Administratoren

519

 Nein

Domain Enterprise Admins

Domänen-Policy-Administratoren

520

 Nein

Domain Policy Admins

Builtin-Administratoren

544

 Nein

Administrators

Builtin-Benutzer

545

 Nein

Users

Builtin-Gäste

546

 Nein

Guests

Builtin-Hauptbenutzer

547

 Nein

Power Users

Builtin-Zugriffsoperator

548

 Nein

Account Operators

Builtin-System-Operator

549

 Nein

Server Operators

Builtin-Drucker-Operator

550

 Nein

Print Operators

Builtin-Backup-Operator

551

 Nein

Backup Operators

Builtin-Replikator

552

 Nein

Replicator

Builtin-RAS-Server

553

 Nein

RAS Servers

Es gibt drei Gruppen, die unbedingt angelegt werden müssen. Eigentlich wäre dabei die Gruppe »Domänencomputer« nicht unbedingt erforderlich, es ist aber dennoch sinnvoll sie anzulegen, da später auch die Computerkonten im Samba verwaltet werden sollen. Wichtig bei den Gruppen ist nicht der Name, sondern der RID (relative identifier). Der RID macht die Gruppe in der Domäne eindeutig und wird bei jedem Objekt immer an den SID der Domäne angehängt. Der SID einer Domäne kann mit dem Kommando »net getlocalsid« anzeigt werden. Die Gruppen »Domänenadmins« und »Domänenbenutzer« sind besonders wichtig, da diese später beim Hinzufügen eines Clients in die Domäne in die entsprechenden lokalen Gruppen auf dem Client eingefügt werden. Diese Zuordnung realisiert der RID.

Im ersten Teil der Tabelle 1 befinden sich alle Gruppen die für die Domäne benötigt werden. Im zweiten Teil befinden sich die Builtin-Gruppen. Bei diesen Gruppen handelt es sich im Windows-System immer um lokale Gruppen, die nur auf dem jeweiligen System gültig sind. Diese Gruppen müssen immer dann angelegt werden, wenn der Samba-Server Mitglied einer Windows-Domäne oder Mitglied im Active Directory wird. Damit sich diese Gruppen anlegen lassen, muss unbedingt »winbind« konfiguriert und gestartet sein.

Bei den Domänengruppen handelt es sich immer um Group Mappings. Ein Group Mapping verweist immer auf eine existierende Linux-Gruppe, es stellt eine Verbindung zwischen der Linux-Welt und der Windows-Welt her. Das Anlegen eines Group Mappings besteht daher aus zwei Schritten. Im ersten Schritt wird die Linux-Gruppe erzeugt und im zweiten Schritt das Mapping. Listing 4 zeigt das Anlegen des Group Mappings für die Gruppe der Domänenadmins:

Listing 4

Group Mappings

 

Im ersten Schritt wurde nur eine Linux-Gruppe erzeugt. Die dabei vergebene GID ist nicht relevant. Im zweiten Schritt kommt dann das Group Mapping hinzu. Hier kann man sehen, dass der RID »512« angegeben wurde, um die Gruppe auch im Windows-System eindeutig als die der Domänenadministratoren zu kennzeichnen. Schließlich kann die Liste aller Group Mappings mit »groupmap list verbose« angezeigt werden. Hier ist zu sehen, dass der Gruppen-SID sich aus dem Domänen-SID und dem RID zusammensetzt.

So müssen jetzt alle weiteren benötigten Gruppen angelegt werden, auf jeden Fall aber die Gruppen Domänenbenutzer, Domänengäste und Domänencomputer mit den entsprechenden RIDs (das Ergebnis zeigt Listing 5). Erst danach kann es mit der Einrichtung der Domäne weitergehen. Später kann der Admin weitere Group Mappings – zum Beispiel globale Gruppen für die Vergabe von Rechten auf Windows-Systemen – einrichten, die er benötigt. Dabei braucht man keine RIDs anzugeben, die ermittelt das System dann selbstständig.

Listing 5

Erforderliche Mappings

 

comments powered by Disqus

Artikel der Woche

Loadtests ohne Server

Für Loadtests der eigenen Server bietet sich die Cloud an, denn kurz getaktet lassen sich dort viele Rechnerinstanzen starten, die das eigene Budget nur wenig belasten. Noch flexibler, günstiger und besser skalierbar sind Tests mit einer Serverless-Infrastruktur wie AWS Lambda. Wir führen vor, wie Sie dort mit Serverless Artillery eigene Loadtests starten. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Container

Wie setzen Sie Container ein?

  • Gar nicht
  • Docker standalone
  • Docker mit Kubernetes
  • Docker mit Swarm
  • Docker mit anderem Management
  • LXC/LXD
  • Rocket
  • CRI-O auf Kubernetes
  • Container auf vSphere
  • Andere (siehe Kommentare auf der Ergebnisseite)

Google+

Ausgabe /2018

Microsite