© Eugenio Marongiu / 123RF.com

Ohne Verzeichnisdienste wie Red Hats IdM wären große, verteile Umgebungen heute undenkbar. Unser zweiteiliges How-to zeigt, wie Sie IdM aufsetzen und mit einem bestehenden Active Directory verbinden, sodass Nutzer eines Verzeichnisses Zugriff auf das jeweils andere erhalten.

Vielen Admins rollen sich die Zehennägel hoch, wenn sie Begriffe wie LDAP oder Kerberos auch nur hören – nicht ganz zu unrecht, haftet doch beiden Protokollen sowie den Diensten, die sie implementieren, der Ruf hoher Komplexität an. Das liegt allerdings bei einem Verzeichnisdienst in der Natur der Sache. Nutzer, Geräte, Berechtigungen, Gruppen und praktisch jedes andere Asset eines Unternehmens in einem zentralen Ordner zu verwalten, erfordert entsprechend viele Parameter pro Eintragsart.

Verzeichnisdienste lassen sich in den heutigen großen, skalierbaren Setups jedoch schlicht nicht vermeiden. Wer einen Maschinenpark aus Dutzenden oder Hunderten Servern zu verwalten hat, kann nicht beim Ausscheiden eines Kollegen aus dem Unternehmen jede Maschine einzeln abgrasen und die dortigen Zugänge deaktiveren. Zudem lassen sich per LDAP oder Kerberos auch Details wie öffentliche SSH-Schlüssel und die bevorzugte Shell eines Anwenders verwalten und bei seinem Ausscheiden aus dem Unternehmen zeitnah entfernen. Die DSGVO lässt grüßen: Je weniger Daten mit Bezug zur Person auf den einzelnen Systemen vor sich hin gammeln, desto geringer ist die Gefahr, bei einer Datenschutzüberprüfung auf der Nase zu landen.

Langer Rede kurzer Sinn: LDAP, Active Directory oder ein anderes Werkzeug für den alltäglichen Einsatz in großen Setups ist unumgänglich. Hinsichtlich der konkreten technischen Implementierung scheiden sich allerdings die Geister. Als Königsweg in der Open-Source-Community galt lange OpenLDAP. Red Hat schert mittlerweile aus und bringt in seiner eigenen Enterprise-Distribution das Identity Management (IdM) zum Einsatz, die kommerzielle Version von FreeIPA (Abbildung 1). Die Lösung basiert im Kern auf dem 389 Directory Server, einem Red-Hat-Eigengewächs.

Abbildung 1: FreeIPA, der Kern von Red Hats IdM, spricht LDAP. Es ersetzt das bisher genutzte OpenLDAP in RHEL 8 vollständig.

Wer eher aus der Windows-Ecke kommt, schwört freilich Stein und Bein auf Active Directory (AD). Es lässt sich aus heutiger Sicht relativ komfortabel verwalten und steuern; zudem verfügt es über den Umweg Azure Active Directory auch über eine Cloud-Anbindung. Wer sich mit der Materie noch gar nicht befasst hat, steht allerdings wie der sprichwörtliche Ochse vor dem Berg und bekommt schnell Ohrensausen, wenn er versucht, aus den Upstream-Dokumentationen die passenden Informationen zu destillieren.

Genau hier springt der vorliegende Artikel in die Bresche. Als Zweiteiler konzipiert, begleitet er Sie zunächst beim Setup eines LDAP-Servers auf einem Linux-System, beim Erstellen der initialen Konfiguration sowie beim Eingliedern von Servern in die Verwaltung des Verzeichnisses. Im zweiten Teil geht es dann an das Anbinden des Verzeichnisses an ein bestehendes Verzeichnis auf Basis von Active Directory.

Zum Einsatz kommt IdM auf Red Hat Enterprise Linux (RHEL). Wo nötig, gehen beide Teile des Artikels auf spezifische Herausforderungen ein wie etwa die Themen DNS und SSL. Beide stellen aus verschiedenen Gründen in zentralen Verzeichnissen üblicherweise eine große Herausforderung dar. Das gilt noch mehr, falls man ein neu zu erstellendes Zentralverzeichnis in vorhandene Infrastruktur integrieren muss.

Red Hats LDAP-Wirren

Soviel gleich vorweg: Im Hinblick auf die Qualität des LDAP-Protokolls ergibt sich zwischen den verschiedenen Lösungen auf dem Markt praktisch kein Unterschied. Auf der Linux-Seite konkurrieren vorrangig OpenLDAP auf Ubuntu, Debian GNU/Linux oder Suse Linux Enterprise Server einerseits und Red Hat Identity Management auf Basis von FreeIPA andererseits um die Gunst der Nutzer. Mit der Einführung von Red Hat IdM haben die roten Hüte OpenLDAP aus ihrer Distribution verbannt. Was einerseits wie typisches “not invented here” wirkt, ergibt andererseits Sinn: Red Hat kann kaum Interesse daran haben, zwei konkurrierende LDAP-Implementierungen parallel zu warten, noch dazu, wenn es der Upstream einer der beiden Lösungen ist.

Für diesen Artikel fiel die Wahl aus mehreren Gründen auf die Kombination aus RHEL und IdM. Zunächst finden sich auch hierzulande viele Unternehmen, die auf Red Hat oder einen Klon davon setzen. Wer bereits RHEL nutzt, der wird seinen Verzeichnisdienst nicht auf eine andere Distribution aufpropfen. Darüber hinaus lässt IdM sich verhältnismäßig leicht aufsetzen, denn Red Hat liefert entsprechende Setup-Werkzeuge gleich mit. OpenLDAP hingegen hat in den vergangenen Jahren viele Kritiker auf den Plan gerufen, weil sein neues Konfigurationsformat selbst in LDIF-Form nicht alle Anwender glücklich macht.

Dass die Wahl schließlich auf ein echtes Red Hat Enterprise Linux und nicht auf eines seiner Derivate fiel, lässt sich leicht erklären: Ein Verzeichnisdienst ist eine absolut kritische Komponente in einer IT-Umgebung. CentOS hat als stabile Distribution in diesem Umfeld keine Zukunft, und die CentOS-Nachfolge klärt sich gerade erst. Demgegenüber bekommt der Admin IdM als Dreingabe zu jeder RHEL-Lizenz ohne Aufpreis. Die Planungssicherheit der Kombination RHEL/IdM rechtfertigt deren finanziellen Aufwand insofern durchaus.

Folglich geht dieser Artikel in beiden Teilen davon aus, dass die Installation des Verzeichnisses in einer Instanz von RHEL 8.3 geschieht. Die kann auf echtem Blech laufen oder virtualisiert sein – daraus ergeben sich praktisch keine Unterschiede.

Das leidige Thema SSL

Bevor es zur Sache geht, stehen noch Hausaufgaben zu zwei Themen auf dem Programm: SSL und DNS. Fängt der Admin auf der grünen Wiese mit der Implementierung eines Verzeichnisdiensts an, kann er in den meisten Fällen nach Belieben schalten und walten. Das alltägliche Szenario ist das allerdings nicht. Selbst wenn ein Admin ein neues Setup in einem bestehenden Unternehmen erstellt und ein neu zu schaffender Verzeichnisdienst nur diesem dienen soll, gibt es womöglich an anderer Stelle bereits ein Active Directory oder andere bestehende Infrastruktur.

Nach Erfahrung des Autors kommt in den meisten Fällen früher oder später das Bedürfnis auf, bestehende Dienste mit neuen zu verbinden. Hat der Admin dann im Vorfeld nicht gut nachgedacht, wie er das anstellt, hat er sich schlechtestenfalls die einfachsten Wege – oder sogar alle – schon verbaut. Das gilt es zu verhindern.

Das Thema SSL liefert hierfür ein gutes Beispiel. In den meisten Unternehmen gibt es ein internes Zertifikatsregime, also eine zentrale Stelle, die lokale SSL-Zertifikate ausstellt, trackt und bei Bedarf widerruft. Das kollidiert mit dem Anspruch eines Verzeichnisdiensts, sich um Themen wie SSL zu kümmern. Kein Admin würde allerdings auf die Idee kommen, die Verantwortung für die eigene, unternehmensinterne SSL-CA ausschließlich einem Dienst wie IdM zu übergeben. Hier ist deshalb die Vermittlung zwischen den Welten notwendig. Auf der Ebene von IdM bedeutet das konkret, dessen Sub-CA-Funktionalität zu nutzen.

Die funktioniert so: IdM stellt sich während des eigenen Setup-Vorgangs ein intermediäres SSL-Root-Zertifikat aus, über das es die alleinige Hoheit hat – vorausgesetzt, der Administrator hinterlegt die passenden Einstellungen. Dieses CA-Zertifikat lässt der Admin von der CA des Unternehmens signieren oder signiert es selbst, falls er auch die Hoheit über die Unternehmens-CA hat. Danach erkennen alle Systeme, die die Root-CA der Firma akzeptieren, das für IdM erstellte intermediäre CA-Zertifikat an, weil es von der Haupt-CA signiert ist, und in der Folge auch solche Zertifikate, die die intermediäre CA signiert hat.

Das leidige Thema DNS

Etwas umständlicher verhält es sich mit dem Thema DNS. Sowohl in Active-Directory- als auch in LDAP-basierten Umgebungen spielt die DNS-basierte Diensterkennung eine herausgehobene Rolle. Clients finden etwa Kerberos- oder LDAP-Server, indem sie bestimmte Hostnamen auflösen und deren SRV-Einträge im DNS durchsuchen. Konsequenterweise müssen die DNS-Einträge passen, damit die Namensauflösung in Verzeichnissen aus Active Directory oder LDAP heraus funktioniert. Wichtig ist DNS obendrein, wenn – wie in unserem Beispiel – geplant ist, eine Domäne aus AD und eine aus IdM später zu verbinden: Active Directory erkennt etwa einen (in diesem Konstrukt zwingend nötigen) Samba-Server nur als AD-Controller, wenn unter den passenden DNS-Einträgen auch die richtigen Dienste lauschen.

Das führt zunächst dazu, dass sowohl AD als auch IdM die Hoheit über DNS am liebsten gleich selbst ausüben würden (integrated DNS). Nicht wenige Admins bekommen bei dieser Vorstellung allerdings Schnappatmung – je nach Sichtweise durchaus zu Recht. Zwar kommen sowohl AD als auch IdM mit eigenen Nameservern daher und lassen sich sowohl als Reverse DNS als auch als autoritative DNS-Server betreiben. Das bedingt aber auch, dass der Administrator die Werkzeuge nutzt, die Red Hat respektive Microsoft hierfür vorgeben.

Obendrein ist man in diesem Konstrukt zwangsweise auf die DNS-Server festgenagelt, die der Anbieter ausliefert. Wer für die eigene Firma allerdings bereits ein ausgewachsenes PowerDNS-Setup betreibt, rümpft zu Recht die Nase, wenn IdM mit seinem Uralt-BIND daherkommt. Wer IdM die Hoheit über die eigene DNS-Infrastruktur überlässt, bekommt für frisch hinzugefügte Systeme zwar automatische DNS-Einträge, verbaut sich aber beim grundsätzlichen Management von DNS-Zonen viele Möglichkeiten.

Vielen Admins ist dieser Tausch nicht recht, und viele Unternehmen lassen ihn aus Compliance-Gründen auch gar nicht zu. IdM bietet deshalb auch die Option, die DNS-Verwaltung extern auszulagern. Das geht im Vergleich mit dem direkt in IdM integrierten DNS-Dienst mit erheblichem Mehraufwand einher: Für jede Maschine, die der Admin in IdM integriert, muss er die jeweiligen DNS-Einträge (und zwar sowohl die A- als auch die PTR-Einträge) händisch anlegen. Weil dieses Szenario in vielen Firmen das realitätsnähere sein dürfte, gehen die beiden Teile dieses Artikels aber von eben dieser Option aus und entreißen IdM das Thema DNS vollständig.

Das leidige Thema Hochverfügbarkeit

Nicht zu kurz kommen darf zudem das Thema Hochverfügbarkeit. Wer eine kritische Komponente wie einen zentralen Verzeichnisdienst im Setup hat, will diese unbedingt redundant betreiben. Bei IdM gibt es hier mehrere Optionen.

Die Option “ab Werk” fußt auf der Idee, Replica-Instanzen von IdM zu betreiben. Das ist implizit redundant, für viele Setups aber vermutlich zu umständlich und auf der IdM-Ebene auch nicht trivial. Die Variante B besteht darin, IdM als Dienst per Cluster-Manager redundant zu betreiben. Das Linux-Magazin hat das Pacemaker-Setup mit virtuellen Instanzen bereits mehrere Male beschrieben [1]. Zum Einsatz kommt in so einem Fall eine Replikationslösung wie DRBD, die den gesamten Datensatz der VM stets auf mehr als einem Server verfügbar hält. Pacemaker startet bei Bedarf dann die virtuelle Maschine dort, wo der Datensatz vorhanden ist.

Die beiden Teile dieses Artikels beschäftigen sich im Detail nicht weiter mit dem Themenkomplex Hochverfügbarkeit. Wir gehen davon aus, dass der Administrator die gesamte IdM-Instanz in redundant betreibt (Abbildung 2). Das muss übrigens nicht zwangsläufig auf RHEL passieren, sondern kann etwa auch auf einem CentOS-Cluster geschehen oder auf einem Cluster von CentOS-Nachfolgern. Wer zu RHEL greift, benötigt für einen Zwei-Knoten-Cluster die HA-Erweiterung nebst zweier RHEL-Lizenzen, für die Red Hat nochmals separat zur Kasse bittet.

Abbildung 2: IdM lässt sich redundant betreiben, wahlweise im Cluster-Modus oder mit Pacemaker im Hintergrund, wie in diesem Beispiel.

Erste Schritte

Nach viel Theorie geht es nun ans praktische Deployment von IdM. Dafür sollten Sie mehrere Dinge parat halten. Da ist zunächst der Name der Domäne, die IdM verwalten soll. Das Beispiel geht im Folgenden ganz banal von »production.internal« aus. In der Konfiguration des lokal genutzten DNS-Servers muss es entsprechend möglich sein, DNS-Einträge für »production.internal« zu vergeben. Der künftige IdM-Server selbst sollte obendrein einen Hostnamen innerhalb der »production.internal«-Domäne haben, etwa »idm.production.internal«.

Der Name der zu nutzenden Domäne und der einer eventuell später zu integrierenden Active-Directory-Domäne dürfen einander nicht ins Gehege kommen; insbesondere darf der eine Eintrag keine Subdomäne des anderen sein. Wenn Sie also in AD schon »directory.internal« als Domäne nutzen, sollten Sie die IdM-Domäne »linux.internal« nennen, keinesfalls aber »linux.directory.internal«, denn sonst klappt später die DNS-Auflösung nicht, und die beiden Domänen können keine Vertrauensstellung zueinander aufbauen. Obendrein sollten Sie das CA-Zertifikat der bestehenden SSL-CA zur Hand haben, die später als Root-CA in IdM zum Einsatz kommt.

Weiter geht es dann ganz bodenständig: Im ersten Schritt installieren Sie RHEL 8 in der jeweils aktuellsten Version. Dabei gilt es, ein paar Details zu beachten. Zunächst kommt für Kerberos- und LDAP-Anfragen als Teil des jeweiligen Requests ein Zeitstempel vor. Divergiert der von der Zeit des bearbeitenden Servers, dann verwirft der Server schon deshalb den gesamten Request. Es ist deshalb von größter Bedeutung, die Hosts innerhalb eines Systems im Hinblick auf ihre Systemzeit zu synchronisieren.

Läuft im lokalen Setup bereits irgendwo eine NTP-Zeitquelle, sollten Sie Chronyd unbedingt so einrichten, dass es die Systemzeit mit jener NTP-Quelle abgleicht. Dabei hilft es, wenn die SRV-Einträge für »_ntp._udp.production.internal« auf die NTP-Server des Unternehmens zeigen, denn dann konfiguriert IdM NTP lokal automatisch. Zudem müssen Sie den Hostnamen des frisch installierten Systems wie beschrieben konfigurieren, im Beispiel also »idm.production.internal«. Obendrein sollte der Hostname des Systems nicht auf »127.0.0.1« auflösen, sondern auf die tatsächliche IP-Adresse. Ändern Sie also einen eventuell vorhandenen Eintrag in »/etc/hosts« entsprechend.

Vorarbeiten

RHEL 8 kommt ab Werk mit aktiviertem Firewalld. Damit Dienste später mit der LDAP(S)-Instanz auf dem IdM-Server sprechen können, müssen Sie zunächst die Firewall des Hosts entsprechend aufbohren. Das erledigen die beiden ersten Befehle aus Listing 1.

# firewall-cmd --permanent --add-service={freeipa-ldap,freeipa-ldaps}
# firewall-cmd --reload
# subscription-manager register
# subscription-manager attach
# subscription-manager repos --enable=rhel-8-for-x86_64-baseos-rpms
# subscription-manager repos --enable=rhel-8-for-x86_64-appstream-rpms
# subscription-manager repos --enable ansible-2.8-for-rhel-8-x86_64-rpms
# yum install ansible ansible-freeipa

Um Zugriff auf die Paketverzeichnisse zu bekommen, die sowohl die Installation von IdM als auch jene von Ansible erlauben, registrieren Sie das System im nächsten Schritt bei Red Hat (Zeile 3). Dazu benötigen Sie das Login und das Passwort, die bei Red Hat mit der jeweiligen Subskription verbunden sind. Danach weisen Sie das System der jeweiligen Subskription zu (Zeile 4). Falls mehr als ein Subskriptions-Pool in dem jeweiligen Account hinterlegt ist, fragt das Tool gegebenenfalls nach. Anschließend aktivieren Sie mit den Kommandos aus den Zeilen 5 bis 7 noch die im folgenden Schritt benötigten RPM-Verzeichnisse (Abbildung 3).

Abbildung 3: Um IdM per Ansible auf RHEL 8 zu installieren, benötigen Sie neben den Base-Repositories noch das vom Anbieter bereitgestellte Ansible-Repo.

Um wie im Beispiel ein lokales, externes SSL-CA-Zertifikat zu nutzen, hinterlegen Sie es in »/etc/pki/ca-trust/source/anchors/« und rufen anschließend den Befehl »update-ca-trust« auf. IdM würde während des eigenen Setups andernfalls später die Signatur des CA-Zertifikats nicht akzeptieren.

Ansible zur Hilfe

Ist das System wie beschrieben grundkonfiguriert, geht es mit der Einrichtung von IdM weiter. Hier erweist sich Ansible als hilfreich. Zum einen liefert Red Hat als Upstream von IdM und Ansible eine Ansible-Rolle, mit der sich sowohl der Server als auch Clients ausrollen lassen. Zum anderen erspart der Umweg über Ansible viel Handarbeit, was den Installationsvorgang in Summe deutlich weniger fehleranfällig macht. Das Kommando aus der letzten Zeile von Listing 1 holt sowohl die benötigte Rolle als auch Ansible selbst auf das System.

Danach legen Sie ein Ansible-Inventar an, wie es Listing 2 beispielhaft darstellt. Der Eintrag unter »ipaclient« bezieht sich auf einen beispielhaften Host, der später an IdM angekoppelt wird, und lautet in realen Setups anders. Die Einträge unter »ipaadmin_password« sowie »ipadm_password« stellen Sie tunlichst auf eigene Werte ein. Der erste bezieht sich auf das Password des IdM-Nutzers admin; der zweite legt den IdM-Masterkey fest, der keinem bestimmten Benutzernamen zugeordnet ist. Möchten Sie das Setup in Produktion übernehmen und Ihre Ansible-Dateien gebührend in Git hosten, nutzen Sie besser Ansible Vault.

[ipaserver] idm.production.internal
[ipaserver:vars]
ipaserver_domain=production.internal
ipaserver_realm=PRODUCTION.INTERNAL
ipaserver_setup_dns=no
ipaadmin_password=SehrGeheimesPasswort
ipadm_password=NochGeheimeresPasswort
[ipaclient]
vm01.production.internal
[ipaclient:vars]
ipaclient_servers=idm.production.internal

Nun geht es mit dem Setup des eigentlich IdM-Servers weiter. Das Playbook, das Red Hat beilegt, geht davon aus, dass Ansible sich um die SSL-CA selbst zu kümmern hat. Weil das im konkreten Fall anders ist, legen Sie für den ersten und den letzten Schritt des Ansible-Deployments zwei Playbooks an, die die Zusatzarbeiten erledigen (Listing 3 und Listing 4).

- name: Playbook to configure IPA server Step 1
  hosts: ipaserver
  become: true
  vars_files:
  - playbook_sensitive_data.yml
  vars:
    ipaserver_external_ca: yes
  roles:
  - role: ipaserver
    state: present
  post_tasks:
  - name: Copy CSR /root/ipa.csr from node to "{{ groups.ipaserver[0] + '-ipa.csr' }}"
    fetch:
      src: /root/ipa.csr
      dest: "{{ groups.ipaserver[0] + '-ipa.csr' }}"
      flat: yes

- name: Playbook to configure IPA server Step -1
  hosts: ipaserver
  become: true
  vars_files:
  - playbook_sensitive_data.yml
  vars:
    ipaserver_external_cert_files: "/root/chain.crt"
  pre_tasks:
  - name: Copy "{{ groups.ipaserver[0] + '-chain.crt' }}" to /root/chain.crt on node
    copy:
      src: "{{ groups.ipaserver[0] + '-chain.crt' }}"
      dest: "/root/chain.crt"
      force: yes
  roles:
  - role: ipaserver
    state: present

Ansible konfigurieren

Bevor es losgehen kann, steht nur noch die Konfiguration von Ansible selbst auf dem Programm. Das möchte auf dem Zielsystem freilich mit Root-Rechten agieren. Die einfachste Option besteht darin, für root einen SSH-Schlüssel zu hinterlegen und zu nutzen. Alternativ lässt sich in Ansible auch ein Nutzer angeben, der per Sudo und Passwort zu root werden kann.

Die restlichen Schritte folgen nun Schema F. Zunächst rufen Sie das angelegte Playbook aus Listing 3 mit der zuvor erstellten Inventardatei auf, um IdM grundsätzlich auszurollen. Das Kommando aus der ersten Zeile von Listing 5 setzt den Prozess in Gang, der je nach Umgebung eine Weile beanspruchen kann (Abbildung 4).

Abbildung 4: Der Mühe Lohn: Wenn alle Voraussetzungen geschaffen sind, steht dem Deployment des IdM-Servers nichts mehr im Wege.

# ansible-playbook -v -i hosts install-server-general.yml
# ansible-playbook -v -i hosts install-server-last.yml

Ist IdM erfolgreich konfiguriert, finden Sie in »/root/idm.production.internal-ipa.csr« den SSL Certificate Signing Request (CSR) für die Root Certificate Authority (Abbildung 5). Falls Sie für die SSL-CA nicht selbst verantwortlich sind, schicken Sie den CSR an die zuständige Stelle und lassen ihn dort signieren, wobei das Sub-CA-Zertifikat für IdM entsteht. Sobald es vorliegt, hinterlegen Sie es in »/root/chain.crt« und rufen den zweiten Teil des modifizierten Playbooks auf (Listing 5, zweite Zeile). Anschließend ist IdM konfiguriert und einsatzbereit.

Abbildung 5: Wer wie im Beispiel auf eine externe SSL-CA setzt, erhält am Ende des ersten Ansible-Aufrufs einen CSR zur Weiterleitung an die Haupt-CA.

Ob IdM ordnungsgemäß funktioniert, testen Sie, indem Sie sich per »kinit admin« ein Kerberos-Token ausstellen lassen. Als Passwort verwenden Sie dasjenige, das Sie zuvor in »hosts« bei »ipaadmin_password« hinterlegt haben. Erscheint keine Fehlermeldung und ist der Rückgabewert des Befehls nach Eingabe des Passworts 0, hat das Ausstellen des Tokens funktioniert.

Danach stehen alle IPA-Befehle zur Verfügung. So können Sie in IdM beispielsweise neue Benutzer anlegen (Listing 6, erste Zeile), Gruppen hinzufügen (Zeile 2) und diesen User zuordnen (Zeile 3).

# ipa user-add --shell=/bin/bash <I>User<I> --cn="<I>Beschreibung<I> --first="<I>Vorname<I>" --last="<I>Nachname<I>" --password"
# ipa group-add <I>Gruppe<I> --descr="<I>Beschreibung<I>"
# ipa group-add-member --users=<I>User<I> <I>Gruppe<I>

Fazit und Ausblick

Die hier vorgestellten Schritte liefern bereits ein funktionierendes IdM-Verzeichnis mit Zeitsynchronisation und der Option, Gruppen und Nutzer anzulegen. Gegen dieses lassen sich auch schon Hosts konfigurieren, um deren Benutzerverwaltung direkt im zentralen Verzeichnis zu realisieren. Obendrein ist es bei diesem Stand des Setups bereits möglich, Hosts in IdM zu verwalten, was etwa dabei hilft, eine zentrale Datenbank vertrauter SSL-Schlüssel zu pflegen.

So tief geht die IdM-Integration tatsächlich: Wer auf einem Host, den IdM unter seinen Fittichen hat, SSH verwendet, der ruft im ersten Schritt einen Wrapper auf. Der checkt, ob ein von einem entfernten SSH-Server geschickter Host-Schlüssel mit jenem übereinstimmt, der für die jeweilige Maschine in IdM vorliegt. Ist das nicht der Fall, bricht der Wrapper den Verbindungsaufbau mit einer Fehlermeldung ab.

Der zweite Teil der Anleitung befasst sich in der nächsten Ausgabe mit der Frage, wie sich eine parallel bestehende Active-Directory-Domäne und der frisch ausgerollte IdM sinnvoll unter einen Hut bringen lassen. Obendrein liefert er ein paar Tipps und Ratschläge im Hinblick auf die effiziente Verwaltung einer IdM-Installation sowie für die nötigsten Kommandos. (jcb/jlu)