© stylephotographs / 123RF.com

Wer im Unternehmen unterschiedliche Verzeichnisdienste nutzt, will sie in der Regel miteinander verbinden. Red Hat IdM und MS Active Directory ermöglichen das über eine eigene Vertrauensstellung.

Die wenigsten Unternehmen kommen ohne zentralen Verzeichnisdienst aus. Warum das so ist, und wie man auf Basis von Red Hat Enterprise Linux schnell einen LDAP-Server an den Start bringt, konnten Sie bereits in der letzten Ausgabe lesen. Der gezeigte Weg fußt auf Red Hats kommerziellem IdM-Produkt. Dessen Kern bildet FreeIPA, das mit einer LDAP-Implementation arbeitet, die unmittelbar Red Hats Feder entspringt.

Red Hat IdM bietet Admins den Vorteil, ein fertiges Produkt, Support und Dienstleistungen aus derselben Hand beziehen zu können. Zudem sprechen die Vorteile von IdM für sich: Wer etwa seine Dienste miteinander SSL sprechen lassen möchte, findet in IdM einen Mechanismus, der Hosts automatisch zum Verzeichnis hinzufügt, SSL-Zertifikate für sie ausstellt und auch die Konfiguration des SSH-Proxys zur Verwaltung der SSL-Schlüssel der Server übernimmt. Für den Admin bringt das die zusätzliche Sicherheit, dass er bemerkt, wenn sich bei einem Server der SSL-Schlüssel des SSH-Servers ändert; das könnte auf einen Angriff hindeuten.

Klar ist aber auch: Viele Unternehmen installieren IdM heute als zusätzliches Produkt auf einer grünen Wiese, obgleich in anderen Abteilungen des Unternehmens womöglich schon ein Verzeichnisdienst existiert – in der Regel Microsofts Active Directory (AD). Und so kategorisch manch gutgläubiger Admin auch ausschließt, dass das neue IdM und das alte Active Directory jemals etwas miteinander zu tun haben werden – früher oder später entsteht unweigerlich das Bedürfnis, die Dienste miteinander zu verbinden.

Eine Quelle der Wahrheit

Aus Compliance-Sicht sind wenige Dinge so sinnlos für ein Unternehmen wie das Führen separater Benutzerverzeichnisse. Ein solches Vorgehen verdoppelt den Aufwand und negiert den Vorteil einer Single Source of Truth, also eines zentralen Verzeichnisses, das alle Benutzerdaten enthält (Abbildung 1). Im schlechtesten Fall zieht das desaströse Folgen nach sich: Wenn Mitarbeiter das Unternehmen verlassen und die Firma vergisst, deren Accounts auf der eigenen Infrastruktur zu deaktivieren, kann das etwa gemäß DSGVO empfindliche Strafen nach sich ziehen.

Abbildung 1: Wer im Unternehmen bereits Active Directory einsetzt, will dessen Nutzer im Sinne einer Single Source of Truth auch auf Linux-Systemen nutzen. Quelle: Microsoft

Firmen arbeiten deshalb zu Recht darauf hin, bestehende Dienste wie AD und IdM sinnvoll miteinander zu integrieren. Auf der Protokollebene ist das vorgesehen; sowohl AD als auch IdM unterstützen das Feature, das etwas sperrig Domain Trust oder Vertrauensstellung zwischen Domänen heißt. Dieser Artikel zeigt, wie Sie das im ersten Teil des Workshops geschaffene Red Hat IdM mit Active Directory mittels Vertrauensstellung integrieren.

Begrifflichkeiten

Vorher steht allerdings ein wenig Theorie auf dem Plan. Im Rahmen der Arbeit mit LDAP oder Active Directory begegnen dem Admin oft weniger geläufige Begriffe. Obendrein haben sich viele Admins mit dem Thema der Vertrauensstellungen zwischen Domänen bislang wenig bis gar nicht befasst. Sie haben dann im Vorfeld keine genaue Vorstellung davon, welche Features eine solche Vertrauensstellung überhaupt verfügbar macht. In manchen Szenarien ist eine solche Vertrauensstellung auch gar nicht die richtige Funktion für einen gewünschten Einsatzzweck – etwa, wenn ein LDAP-Proxy ausreichend wäre.

Ein zentraler Begriff im AD- und LDAP-Kontext ist etwa jener des Forests. Als einen solchen Wald bezeichnen hauptsächlich AD-Admins eine Ebene ihres AD-Verzeichnisses. Die oberste Ebene des AD-Verzeichnisses, die auch mehre Domänen umfassen kann, heißt meist einfach Active Directory Forest; allerdings bezeichnen viele Admins auch eine einzelne Domäne schon als Forest.

Falls Sie jetzt den Wald vor lauter Bäumen nicht mehr sehen, besteht dennoch kein Grund zur Panik: Der Begriff Cross-Forest Domain Trust heißt nicht viel mehr, als dass auf der LDAP- und AD-Ebene eine Vertrauensstellung entsteht, die es Ressourcen des einen Forests erlaubt, auf die Ressourcen der jeweils anderen Domäne zuzugreifen.

Eine weitere Rolle spielt die Frage, ob die Vertrauensstellung transitiv eingerichtet wird, ob also das Vertrauen, das eine Domäne einer anderen ausgesprochen hat, auch für deren Subdomänen gilt, falls es solche gibt. Obendrein kann eine Vertrauensstellung uni- oder bidirektional sein: Es wäre also durchaus denkbar, dass Domäne B der Domäne A vertraut, Nutzer der Domäne A aber Ressourcen der Domäne B nicht verwenden dürfen.

Was geht und was nicht

Apropos Zugriff: Vielen Admins ist auch nicht klar, was eine Vertrauensstellung zwischen zwei Domänen überhaupt technisch erreicht. Man sollte wissen, dass ein solcher Trust nicht den eigenen LDAP-Server in eine Art Proxy zu Active Directory verwandelt.

In den meisten Fällen greifen Admins zum Cross-Forest Domain Trust, um den Nutzern der Domänen die Anmeldung am jeweils anderen Verzeichnisdienst zu ermöglichen. Gibt es bereits ein AD-Benutzerverzeichnis, verbinden viele Admins ein neues IdM damit, um den Nutzern aus Windows heraus die Anmeldung an Linux-Diensten zu ermöglichen. Einen Haken hat die Sache allerdings, denn der Client, mit dem man sich an einem LDAP mit AD-Benutzerdaten anmeldet, muss die Angabe der Domäne unterstützen, mit der die Anmeldung erfolgen soll.

Abbildung 2: Eine valide Alternative zu einer Vertrauensstellung zwischen Domänen ist möglicherweise OpenLDAP als Proxy hin zu Active Directory.

Vorbereitungen treffen

Kommt der Administrator zum dem Schluss, dass der Trust zwischen Domänen die passende Lösung für sein Problem darstellt, stehen zunächst einige vorbereitende Schritte auf dem Programm. Es ist sinnvoll, die Vertrauensstellung zu einem späteren Zeitpunkt vom Active Directory Server aus zu initiieren – das klappt, ohne dass der Linux-Admin in seinem IdM irgendwo die Benutzerdaten des Administrator-Users der AD-Domäne angeben muss. Letzteres dürfte in vielen Unternehmen aufgrund geltender Compliance-Regeln eine Herausforderung darstellen oder erst gar nicht möglich sein.

Damit Active Directory einen LDAP-Server aber als Domänencontroller nach eigenem Standard anerkennt, muss sowohl die Konfiguration des lokalen DNS-Servers als auch die Einrichtung der gegebenenfalls vorhandenen Firewalls passen. Das Einrichten der Vertrauensstellung zwischen den Domänen ist im Grunde eine Lappalie, wenn nur die Voraussetzungen stimmen. Genau dafür sollte der Admin sorgen, bevor er sich überhaupt an die Windows-Leute wendet.

Die Firewall aufbohren

Der erste Schritt der Vorbereitungen besteht idealerweise im Einrichten eventuell vorhandener Firewalls. Hier gibt es verschiedene Ebenen und mehrere Eventualitäten; aus Sicht des Admins schadet es daher nicht, gleich alle relevanten Ports freizuschalten, selbst wenn einzelne davon später im spezifischen Setup nicht zum Einsatz kommen. Die Liste der benötigten Ports fällt allerdings umfangreich aus.

Los geht es mit Port 53 TCP und UDP für DNS-Anfragen. Für unverschlüsseltes Kerberos muss Port 88 per TCP und UDP erreichbar sein. Port 123 UDP muss offenstehen, um die Funktion des Windows-Time-Diensts zu ermöglichen. RPC benötigt Port 135 in TCP und UDP, NetBIOS Port 139 per TCP. Die Ports 389 und 636, jeweils in TCP und UDP, ermöglichen den Zugriff auf LDAP und LDAPS.

Port 445 in TCP erlaubt das Samba-SMB-Protokoll, Port 464 (TCP und UDP) dient dem Kerberos-Change-Service. Obendrein muss der Port-Bereich von 1024 bis 65535 per TCP offen sein, da RPC sich aus dieser Range beliebige Ports für die Kommunikation von Client und Server herauspickt. Die UDP-Ports 3268 und 3269 gewährleisten schließlich, dass der LDAP Global Catalog von AD funktioniert.

Konkrete Technik

Haben Sie Red Hat IdM wie in Teil 1 des Workshops auf einem System mit Red Hat Enterprise Linux 8.3 installiert, findet sich darauf ab Werk eine laufende Instanz von Firewalld. Da sie Verbindungsversuche von Active Directory ablehnen würde, müssen Sie sie im ersten Schritt aufbohren. Praktisch: AD fasst die zuvor genannten Ports zu einem Firewalld-Profil namens »freeipa-trust« zusammen, das es zu aktivieren gilt. Ein Neustart oder Reload von Firewalld aktiviert danach die Einstellung. Wichtig: Um einen bidirektionalen Trust zu erstellen, müssen Sie eine gegebenenfalls vorhandene Firewall des AD-Servers ebenfalls öffnen.

Außerdem gilt es, gegebenenfalls im Netzwerkpfad von IdM zu Active Directory liegende Firewalls zu öffnen. Unternehmen verstecken ihre AD-Instanzen als zentrale Komponente von neuralgischer Bedeutung oft hinter mehreren Firewalls. Soll LDAP mit AD sprechen können, muss der Netzwerkpfad aber zwingend frei sein. Abhängig von der Frage, in welche Richtungen der Trust funktionieren soll, müssen Sie die jeweiligen Ports hier also ebenfalls öffnen.

DNS muss passen

Nach Abschluss der Firewall-Konfiguration steht als Nächstes das Thema DNS auf der To-do-Liste. Wie bereits im ersten Teil des Workshops erwähnt, suchen Clients in Domänen verschiedene Dienste anhand der »SRV«-Einträge im DNS. Im ersten Teil haben Sie zwar ein paar dieser Einträge bereits angelegt, die aber vorrangig für die Linux-Server gelten, die sich mit Kerberos verbinden. Mit Active Directory hat das wenig zu tun, das benötigt eigene Einträge.

Davon kommt eine ganze Reihe zusammen, wie die Liste aus der Tabelle “Notwendige DNS-»SRV«-Einträge” zeigt. Bei allen dort genannten Einträgen handelt es sich um »SRV«-Einträge, die jeweils direkt auf den Hostnamen der IdM-Instanz zeigen müssen. Für das Beispiel nimmt der Artikel wie bereits in Teil 1 an, dass die IdM-Instanz auf dem Server »idm.production.internal« läuft und der »REALM« der Domäne »production.local« lautet.

Obendrein muss der Admin noch einen DNS-Eintrag des Typs »TXT« ergänzen, und zwar »_kerberos.mgmt.production.internal« mit dem Wert »PRODUCTION.INTERNAL«. Haben Sie alle Einträge im DNS-Server hinterlegt, sollten Sie sie noch einmal überprüfen und gegebenenfalls korrigieren: Solange DNS nicht funktioniert, verweigert AD jedwede Kooperation mit IdM. Steht die DNS-Konfiguration einmal, geht es ans Einrichten der Vertrauensstellung. Das erfordert zunächst einige Vorarbeiten auf der IdM-Seite.

Red Hat IdM vorbereiten

Auf dem System mit Red Hat IdM installieren Sie im ersten Schritt mittels Dnf die benötigten Server-Dienste in Form der Pakete ipa-server, ipa-server-trust-ad und samba-client. Für das Verständnis der nun folgenden Schritte sollten Sie sich stets vor Augen halten, dass IdM die Vertrauensstellung zu AD nicht ohne die Schützenhilfe von Samba herstellen kann. Active Directory setzt verschiedene Protokolle wie Netlogon voraus, die IdM selbst nicht spricht. IdM kommt daher mit einem Setup-Assistenten, der Ihnen den größten Teil der Arbeit für das Aufsetzen weiterer Dienste abnimmt.

Diesen Assistenten starten Sie als Root mittels »ipa-adtrust-install« auf der Kommandozeile des IdM-Systems. Er verkündet zunächst, dass er die vorhandene Standard-»smb.conf« von Samba überschreiben möchte, was Sie per »yes« erlauben. Das Plugin »slapi-nis«, nach dem der Assistent im nächsten Schritt fragt, sollten Sie ebenfalls aktivieren, zumindest, wenn auch ältere Linux-Systeme den Trust in IdM nutzen sollen.

Die Frage nach dem NetBIOS-Domänennamen ist kritisch: Über ihn referenzieren Sie später aus AD heraus die IdM-Domäne. Für das Beispiel nutzen wir hier die Domäne »PRODUCTION«. Bejahen Sie die Frage, ob der Dienst »ipa-sidgen« laufen soll. Ein abschließender Neustart von FreeIPA mittels »ipactl restart« beendet die Konfiguration und bringt die lokale Domäne für die Kopplung mit Active Directory an den Start. Der Befehl »smbclient -L production.internal -k« sollte nun auf jeden Fall einen IPC-Share zutage fördern und so signalisieren, dass das Zusammenspiel zwischen Samba und FreeIPA funktioniert.

Der nächste Arbeitsschritt besteht bereits darin, die sogenannte Vertrauensstellung in Gang zu bringen. Einen Teil dieser Arbeit gilt es allerdings auf der Active-Directory-Seite zu erledigen.

DNS-Routing beachten

Im Folgenden geht dieser Artikel von der Prämisse aus, dass es im Unternehmen nur eine zentrale DNS-Hierarchie gibt, die von denselben Servern verwaltet wird. In vielen Unternehmen stammen jedoch die DNS-Einträge für bestehende Ressourcen und die aus der neuen Umgebung aus unterschiedlichen Quellen. In diesem Fall müssen Sie in Active Directory das Domain Routing für die neue Domäne konfigurieren. Wie Sie für bestimmte Teile des DNS-Baums separate Nameserver in AD festlegen, beschreibt etwa ein Citrix-Tutorial [1]. Auch auf der IdM-Seite fällt dieser Schritt an. Für die AD-Domäne »ad.internal« erledigt der Befehl aus Listing 1 das Nötige.

# ipa dnsforwardzone-add ad.internal --forwarder=192.168.0.1 --forward-policy=only

Vertrauensstellung in AD

Praktisch besteht die Konfiguration der Vertrauensstellung in Active Directory aus mehreren Teilen. Zunächst konfigurieren Sie den Trust in IdM, danach legen Sie das Gegenstück auf der AD-Seite an, und schließlich konfigurieren Sie auf der IdM-Seite das Passwort für den Trust. Spätestens jetzt sollten Sie sich darüber im Klaren sein, ob Sie einen transitiven Trust benötigen und ob die Vertrauensstellung uni- oder bidirektional sein soll. Das folgende Beispiel legt einen transitiven Trust an, der in beide Richtungen gilt. Nutzer aus Active Directory haben danach also die Möglichkeit, sich an IdM anzumelden und umgekehrt.

In Active Directory begeben Sie sich zunächst zur Übersicht der Domänen. Nach der Auswahl der Domäne, mit der die IdM-Vertrauensstellung entstehen soll, öffnen Sie deren Eigenschaften und wählen das Fenster Trusts aus. Ein Klick auf New Trust holt einen Assistenten auf den Schirm (Abbildung 3). Der will zunächst den Namen der Domäne wissen, im Beispiel »production.internal«.

Abbildung 3: Ist die Domäne auf der IdM-Seite richtig eingerichtet, erkennt Active Directory sie als Windows-Domäne, nachdem der Admin dem Domänennamen angegeben hat.

Passt die Konfiguration der DNS-Einträge, schlägt Active Directory danach bereits von sich aus vor, eine Vertrauensstellung (Forest Trust) zwischen den beiden Domänen herzustellen. Bei den einzelnen Fragen wählen Sie aus, dass die Vertrauensstellung transitiv und in beide Richtungen gültig sein soll (Abbildung 4). Dann legen Sie das Passwort für den Trust fest, bevor Sie ihn (oder eigentlich beide, denn AD legt für jede Richtung eine eigene Vertrauensstellung an) mit Ihrem AD-Admin-Zugang verifizieren. Das Passwort für den Trust benötigen Sie im nächsten Schritt für die IdM-Instanz, um auch dort den Trust einzurichten.

Abbildung 4: Eine bidirektionale Vertrauensstellung ermöglicht den Nutzern einer Domäne Zugriff auf die Ressourcen der anderen Domäne.

Die Gegenseite: IdM

Dazu loggen Sie sich auf auf dem IdM-Server als Root ein und rufen den Befehl aus der ersten Zeile von Listing 2 auf. Ipa fragt dann nach dem Passwort für die Vertrauensstellung und richtet diese ein. Die Befehle aus den beiden folgenden Zeilen rufen dann eine Liste der Domänen des AD-Verzeichnisses ab.

Anschließend sollte das Kommando aus der letzten Zeile, für das Sie das Passwort des Accounts Benutzer benötigen, die Anmeldung via Trust auf dem jeweiligen System ermöglichen. Zeigt zudem der Befehl »kinit list« ein gültiges Kerberos-Ticket für den Benutzerzugang aus Active Directory an, ist damit der Aufbau der Vertrauensstellung abgeschlossen.

# ipa trust-add --type=ad ad.internal --trust-secret --two-way=true
# ipa trust-fetch-domains "ad.internal"
# ipa trustdomain-find "ad.internal"
# kinit <I>Benutzer<I>@ad.internal

Wie Linux profitiert

Ist ein System dafür konfiguriert, seine Benutzer aus IdM zu beziehen, funktioniert darauf ab sofort auch der Login mittels der Credentials aus Active Directory. Wenn ein Nutzer sich via IdM mit seinen gültigen Zugangsdaten an IdM anmeldet, wickelt dieses im Hintergrund mit Active Directory die Authentifizierung ab und stellt ein gültiges Kerberos-Token aus.

Das klappt allerdings nur, wenn das System, an dem der Nutzer sich anmeldet, tatsächlich auch selbst an IdM angekoppelt ist. Der letzte Schritt in diesem Artikel befasst sich deshalb mit der Frage, wie man Server mit IdM möglichst automatisiert integriert. Die gute Nachricht: Red Hat stellt dazu ein Ansible-Playbook zur Verfügung, mit dem sich Hosts spielend leicht in IdM einloggen lassen.

Die folgenden Arbeitsschritte gehen davon aus, dass Sie Ihre Ansible-Umgebung aus dem ersten Teil des Workshops auf dem IdM-System noch zur Verfügung haben. In die »hosts«-Datei tragen Sie dann die Server als separate Gruppe »ipaclients« ein. Die im Inventar festgelegten Parameter für die Gruppe »ipaserver« übernehmen Sie für die Clients.

Zusätzlich fügen Sie den Parameter »ipaclient_mkhomedir« mit dem Wert »yes« hinzu. Danach folgt bereits der Ansible-Aufruf mittels »ansible-playbook -i hosts install-client.yml« (Abbildung 5). Ansible fügt nun alle Hosts der Gruppe »ipaclients« automatisch in die Verwaltung von IdM ein, und die Accounts aus Active Directory werden auf den Systemen verfügbar.

Abbildung 5: FreeIPA kommt mit einem Ansible-Playbook für Clients daher, sodass diese sich schnell in den Verzeichnisdienst integrieren lassen.

Fazit

Auch wenn das Setup von IdM alias FreeIPA phasenweise etwas holprig anmutet und die Integration von Active Directory und IdM nicht ganz trivial ist: Haben Sie das Gespann einmal eingerichtet, verrichtet es zuverlässig seine Arbeit.

Mancher Admin mag zwar die Nase rümpfen, weil er auf der Linux-Seite eigentlich die Arbeit mit OpenLDAP gewohnt ist, das unter RHEL gar nicht erst zur Verfügung steht. OpenLDAP als reiner LDAP-Server wäre jedoch nicht ausreichend, um eine Vertrauensstellung mit Active Directory herzustellen: Eine Vertrauensstellung zwischen Domänen erfordert zwei echte Kerberos-Realms. Genau hier spielt das Boxed-Produkt von Red Hat seine Stärken voll aus, weil es nicht nur LDAP konfiguriert, sondern passend dazu auch Samba, was die Verbindung zu Active Directory erst ermöglicht.

Der Admin freut sich letztlich über eine für den Produktiveinsatz taugliche Integration von Active Directory und LDAP, die Red Hat mittels umfassender Ansible-Integration und schlauer Werkzeuge möglich macht. Wer Active Directory und LDAP unter einen Hut bringen möchte, ist mit IdM und dessen Kern FreeIPA aktuell zweifelsohne am besten bedient. (jcb/jlu)