"Active Directory und Linux? Das geht?!" fragte mich der Auszubildende im sechsten Lehrjahr mit großen Augen, deren Ausdruck irgendwo zwischen Unglaube und Hund mit Schlafmangel anzusiedeln war.

"Natürlich!" erwiderte ich, bevor ich mit erwartender Miene fortsetzte "Und jetzt raus aus meinem Keller!".

Worum?

Heute sprechen wir über die Einbindung von wundervollen Linux-Maschinen, die sich in einer gemeinen, höchstwahrscheinlich Windows-dominierten Umgebung zurechtfinden müssen, in zentrale Active-Directory-Dienste. Dabei bedienen wir uns an Werkzeugen wie SSSD und RealmD.

Warum?

Sehr viele Umgebungen sind heutzutage mit irgendeiner Version von Active-Directory ausgestattet​, über die zentrale Verzeichnisdienste bereitgestellt werden.

Um nun also Linux-Maschinen mit zentralen Verzeichnisdiensten zu beglücken, hat der moderne Linux-Administrator von heute in einer Firma mittlerer bis erweiterter Größe in der Regel zwei Optionen:

Option A:

Unser Linux-Administrator, nennen wir ihn mal Bob, erkundigt sich, ob in der näheren Erreichbarkeit der Linux-Maschinen zentrale Verzeichnisdienste existieren. Bob erfährt, dass es ein uraltes Active-Directory gibt, das ein ehemaliger Azubi als Abschlussprojekt aufgebaut, mittelprächtig dokumentiert und nach seiner Übernahme nie wieder gepflegt, geschweige denn aktualisiert hat.

Bob findet heraus, dass er mit dem System Security Services Daemon (kurz: SSSD) und dem dazu passenden Frontend RealmD (kurz: RealmD) diese Verzeichnisdienste auch unter Linux für seine Zwecke nutzen kann.

Bob beschließt, das Active-Directory mit RealmD und SSSD zu benutzen.

Option B:

Bob sucht nach einem Weg, zentrale Verzeichnisdienste unter Linux zu etablieren. Da Bob nichts von Microsoft-Produkten hält, schlägt er vor, eine Linux-basierte Alternative wie OpenLDAP oder FreeIPA zu nutzen.

Bob erfährt, dass es einen uraltes Active-Directory gibt, das ein ehemaliger Azubi als Abschlussprojekt aufgebaut, mittelprächtig dokumentiert und nach seiner Übernahme nie wieder gepflegt, geschweige denn aktualisiert hat.

Bob findet heraus, dass er mit dem System Security Services Daemon (kurz: SSSD) und dem dazu passenden Frontend RealmD (kurz: RealmD) diese Verzeichnisdienste auch unter Linux für seine Zwecke nutzen kann.

Bob wird angewiesen, das Active-Directory mit RealmD und SSSD zu benutzen.

Wie?

Gut, dass du fragst! Unsere Vorgehensweise enthält folgende Schritte:

  1. DNS-Konfiguration.
  2. Installation der notwendigen Pakete.
  3. Eintritt in die Domäne.
  4. Zehn Minuten weinen.
  5. Anpassung der SSSD-Konfiguration.
  6. Einrichten von SUDO-Profilen.
  7. OPTIONAL: Einrichtung von GSSAPI-Authentifizierung.

Das Ganze tun wir heute mit einer Linux-Maschine auf Basis von CentOS 7. Um nicht mehr allzu viel Zeit zu verschwenden, steigen wir direkt ein!

DNS-Konfiguration

Bevor wir eine Linux-Maschine zur AD-Domäne hinzufügen, prüfen wir die DNS-Konfiguration auf dem Betriebssystem.

Wichtig ist es, einen /etc/hosts-Eintrag für das eigene System zu pflegen. Vorzugsweise mit den IPs des Loopback-Interfaces und des Netzwerks, in dem sich unsere Linux-Maschine herumtreibt.

Zusätzlich bietet es sich an, Hosts-Einträge für unsere Domänen-Controller zu pflegen, falls der von uns auserkorene, zentrale DNS-Service irgendwann mal nicht mit uns oder dem System sprechen möchte.

Hierzu springen wir zuerst, mit dem Editor unserer Wahl1, in die Datei:

vi /etc/hosts:

127.0.0.1       localhost localhost.localdomain localhost4 localhost4.localdomain4
127.0.1.1             <HOSTNAME>.fu-solutions.dom <HOSTNAME>
<IP>            <HOSTNAME>.fu-solutions.dom <HOSTNAME>
<IP>            <DC1>.fu-solutions.dom <DC1> fu-solutions.dom
<IP>            <DC2>.fu-solutions.dom <DC2> fu-solutions.dom

Danach passen wir der Vollständigkeit halber in der /etc/sysconfig/network-scripts/ifcfg-ens192 die Suchdomäne für unsere Namensauflösung auf der Linux-Maschine an:

DOMAIN=fu-solutions.dom

Und starten das Interface neu:

sudo ifdown ens192; sudo ifup ens192

Paketinstallation

Jetzt ist unserer System bereit, mit den notwendigen Paketen beschenkt zu werden! Also laufen wir los und sagen dem guten alten Yellowdog Update Manager (kurz: YUM), dass erfolgende Pakete installieren soll:

sudo yum install sssd realmd oddjob oddjob-mkhomedir adcli samba-common-tools

Die zusätzlichen Pakete abseits von sssd und realmd würden per realm discover fu-solutions.dom als required ausgegeben. Um YUM nicht mehrfach loslaufen zu lassen, installieren wir diese also gleich mit.

Wobei ein bisschen Auslauf ja ganz gesund für Hunde sein soll. Allerdings weiß ich nicht, ob das auch für gelbe Hunde gilt. Wo kommen eigentlich gelbe Hunde her? Haben gelbe Hunde auch gelbe Frauchen und/oder Herrchen? Tragen die Hüte? Wenn ja, sind die auch gelb? Oder vielleicht doch eher rot? Warum liefern sie überhaupt Pakete an Pinguine? Fragen über Fragen...

Wo war ich? ... Achja!

Eintritt in die Active-Directory-Domäne

Nun führen wir den Befehl realm join aus, um mit der Linux-Maschine über einen Administrator-Account der Domäne beizutreten.

sudo realm join--user=<ADMIN-ACCOUNT> fu-solutions.dom

Jetzt haben erstmal alle Benutzer Zugriff auf die Linux-Maschine. Und weil wir das doof finden Und weil das aus sicherheitsperspektive unklug ist, verweigern wir im nächsten Schritt pauschal allen Active-Directory-Benutzern den Zutritt:

sudo realm deny --all

Anschließend erlauben wir nur noch Mitgliedern sorgfältig ausgewählter Active-Directory-Gruppen den Zutritt zu unserer Linux-Maschine:

sudo realm permit -g lx_users@fu-solutions.dom
sudo realm permit -g lx_admins@fu-solutions.dom

Das war schon der schlimmste Teil! Und so schlimm war das doch nicht oder? Oder? Ja ich weiß...

SSSD-Konfiguration

Jetzt haben wir also eine Linux-Maschine, an der sich bestimmte User per Active-Directory anmelden können. Leider geht das aktuell aber nur über den vollqualifizierten Benutzernamen (<BENUTZER>@<DOMÄNE>) und es wird ein Home-Verzeichnis unter /home/<BENUTZER>@<DOMÄNE>/ angelegt.

Nun hat aber nicht jeder Lust, immer seinen vollqualifizierten Benutzernamen einzugeben, um sich einzuloggen. Und der Pfad des Home-Verzeichnisses auch scheiße ist auch nicht gerade hübsch.

Um das also anzupassen, stoppen wir den SSSD händisch:

sudo systemctl stop sssd

Danach passen wir in der /etc/sssd/sssd.conf einmal die Einstellung use_fully_qualified_names an, um die Anmeldung mit dem bloßen Benutzernamen zu ermöglichen.

Außerdem ändern wir noch das fallback_homedir damit wir die entstehenden Home-Verzeichnisse schöner sortiert haben. Hierbei bietet sich zum Beispiel das Format /home/%d/%u also /home/<DOMÄNE>/<BENUTZER> an, um all unsere Home-Verzeichnisse unserer Domäne separat an einem Ort zu sammeln. Das erleichtert später auch ein auslagern via autofs in einem zentralen NFS-Mount oder ähnliches.

use_fully_qualified_names = False
fallback_homedir = /home/%d/%u

Jetzt starten wir den SSSD wieder:

sudo systemctl start sssd

Löppt hart, Digga!

SUDO-Profile

Schön! Jetzt können ausgewählte Active-Directory-Benutzer die Verbindung zu unserer Linux-Maschine aufbauen. Schauen wir noch einmal was Bob macht!

Bob hat, euphorisch über seinen kleinen "Erfolg", seine Session zum lokalen Administrator-Account auf der Linux-Maschine beendet und meldet sich mit seinem Active-Directory-Benutzer an. Mit Erfolg!

Jetzt will Bob das Paket sl installieren. Doch was ist das? Bobs Active-Directory-Benutzer hat ja gar keine Berechtigungen zur Installation von Paketen! Also zurück ans Reißbrett.

Um nun der AD-Gruppe lx_admins@fu-solutions.dom SUDO-Berechtigungen zu verschaffen, legen wir ein sogenanntes "SUDO-Profil" an. Randnotiz: Wir gehen an dieser Stelle mal davon aus, das alle Linuxadministratoren in einer AD-Gruppe eingepfrecht sind.

Dabei handelt es sich um eine Datei unter /etc/sudoers.d/, die wir in diesem Fall einfach frei nach der enthaltenen Active-Directory-Gruppe benennen.

Jetzt legen wir also über einen lokalen Account mit SUDO-Berechtigungen die Datei /etc/sudoers.d/10-lx_admins an und füllen diese mit nachfolgendem Inhalt:

%lx_admins   ALL=(ALL)       LOG_INPUT: LOG_OUTPUT: ALL

Jetzt hat unsere Active-Directory-Gruppe lx_admins@fu-solutions.dom die Berechtigung, Befehle im SUDO-Kontext auszuführen. Außerdem wird der In- und Output jeder Session im SUDO-Kontext inklusive der User-ID protokolliert und somit nachvollzieh- und auditierbar.

Jetzt können wir uns mit unserem Active-Directory-Benutzer an unserer Linux-Maschine anmelden und allerlei Schabernack treiben. Zum Beispiel sl installieren und stundenlang ausführen.

Klingt gut? Für die unter euch, die sich mit ihrer Workstation ebenfalls in der besagten Active-Directory-Domäne befinden, wie unsere Linux-Maschine und zu faul sind, bei jeder SSH-Anmeldung ein Passwort eingeben zu wollen wird das Ganze noch besser! Fortsetzung folgt...

  1. Es gibt nur einen Editor unter Linux und das ist vi. Jeder der was anderes sagt, lügt, hat keine Lust oder lügt.↩