Lesezeit ca. 13 Min.
arrow_back

Zwei Welten vereint


Logo von IT Administrator
IT Administrator - epaper ⋅ Ausgabe 8/2022 vom 29.07.2022

Active Directory und Red Hat IdM per Vertrauensstellung verbinden

Artikelbild für den Artikel "Zwei Welten vereint" aus der Ausgabe 8/2022 von IT Administrator. Dieses epaper sofort kaufen oder online lesen mit der Zeitschriften-Flatrate United Kiosk NEWS.

Bildquelle: IT Administrator, Ausgabe 8/2022

D er Umgang mit Verzeichnisdiensten wie dem Active Directory (AD) oder LDAP gehört zum Handwerkszeug jeden Admins. Zwar verursachen die Dienste selbst einigen Verwaltungsaufwand, doch die Mühe zahlt sich aus: Kein anderer Weg erlaubt es, so schnell und effizient Benutzer überall in der Umgebung zu deaktivieren oder allen vorhandenen Usern Ressourcen zur Verfügung zu stellen. Wer es schon einmal mit Infrastrukturen zu tun hatte, in denen ausschließlich lokale Benutzer existieren, kennt das Problem: Nicht nur ist es sehr mühsam, hier zentrale Änderungen an der Benutzerverwaltung so durchzuführen, dass sie augenblicklich überall gelten – gerade in stressigen Situationen besteht obendrein die Gefahr, einzelne Systeme zu vergessen und verwundbar zu hinterlassen. Über den Sinn oder Unsinn der Einführung von LDAP oder AD ist deshalb ...

Weiterlesen
epaper-Einzelheft 10,99€
NEWS Jetzt gratis testen
Bereits gekauft?Anmelden & Lesen
Leseprobe: Abdruck mit freundlicher Genehmigung von IT Administrator. Alle Rechte vorbehalten.
Lesen Sie jetzt diesen Artikel und viele weitere spannende Reportagen, Interviews, Hintergrundberichte, Kommentare und mehr aus über 1050 Magazinen und Zeitungen. Mit der Zeitschriften-Flatrate NEWS von United Kiosk können Sie nicht nur in den aktuellen Ausgaben, sondern auch in Sonderheften und im umfassenden Archiv der Titel stöbern und nach Ihren Themen und Interessensgebieten suchen. Neben der großen Auswahl und dem einfachen Zugriff auf das aktuelle Wissen der Welt profitieren Sie unter anderem von diesen fünf Vorteilen:

  • Schwerpunkt auf deutschsprachige Magazine
  • Papier sparen & Umwelt schonen
  • Nur bei uns: Leselisten (wie Playlists)
  • Zertifizierte Sicherheit
  • Freundlicher Service
Erfahren Sie hier mehr über United Kiosk NEWS.

Mehr aus dieser Ausgabe

Titelbild der Ausgabe 8/2022 von Raus aus dem Teufelskreis. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Raus aus dem Teufelskreis
Titelbild der Ausgabe 8/2022 von Malvertising einmal anders. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Malvertising einmal anders
Titelbild der Ausgabe 8/2022 von Follina für Angriffe genutzt. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Follina für Angriffe genutzt
Titelbild der Ausgabe 8/2022 von Bessere Sicht. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Bessere Sicht
Mehr Lesetipps
Blättern im Magazin
Tipps, Tricks und Tools
Vorheriger Artikel
Tipps, Tricks und Tools
Türöffner
Nächster Artikel
Türöffner
Mehr Lesetipps

... eigentlich keine Diskussion mehr nötig.

Allerdings gibt es auch das Gegenteil, quasi "zu viel" zentrale Benutzerverwaltung, und zwar in jenen Fällen, in denen es mehrere zentrale Benutzerverzeichnisse gibt. So ein Szenario entsteht schneller, als manchem Administrator lieb ist. Kauft eine Firma eine andere, kommt es regelmäßig vor, dass die zentralen Verzeichnisse beider Firmen aufeinander prallen und mühsam abzugleichen sind. Ein Szenario mit mehreren Benutzerverzeichnissen kann zudem durchaus gewollt sein, etwa wenn das Windows-Team ein AD pflegt, das Linux-Team ein LDAP und das Ziel die berüchtigte "Separation of Concern" ist, also die strikte Trennung.

Diffizile Vertrauensstellung

Im Lauf der Zeit stellt sich in solchen Fällen allerdings regelmäßig heraus, dass die strikte Trennung so strikt dann doch nicht sein soll, und dass etwa Benutzerzugänge aus der Linux-Welt Zugriff auf Ressourcen in Active Directory bekommen sollen.

Für eben diese Fälle sehen AD und LDAP Möglichkeiten vor, Benutzern den Zugriff zu ermöglichen – das Zauberwort heißt "Cross-Forest Domain Trust". Diese Vertrauensstellung entpuppt sich als hilfreich, weil sie die Administratoren auf beiden Seiten von der Notwendigkeit befreit, dieselben Benutzerzugänge hüben wie drüben anzulegen und zu pflegen und somit den wesentlichen Vorteil der zentralen Benutzerverwaltung, die "Single Source of Truth", ad absurdum zu führen.

Einen solchen Forest einzurichten, ist aber nicht ganz einfach. Bevor er funktioniert, stehen einige Arbeitsschritte auf dem Programm. Diese bestehen im Wesentlichen darin, notwendige Bedingungen zu überprüfen und die nötigen Features zu konfigurieren, falls diese noch nicht gegeben sind. Das eigentliche Einrichten der Vertrauensstellung später ist einigermaßen trivial, wenn alle Vorbereitungen sinnvoll getroffen sind. Wichtig ist dabei vor allem, dass die Administratoren beider Dienste eng zusammenarbeiten müssen – interne Ränkespiele funktionieren nicht, wenn AD und IdM miteinander reden sollen.

Unser Workshop-Beispiel geht im Folgenden von einem Aufbau aus, der einerseits Microsofts AD in einer aktuellen Version verwendet und andererseits Red Hats IdM als Verzeichnisdienst für Linux.

IdM ist als kommerzielle Distribution von FreeIPA und Add-on Bestandteil jeder Subskription von Red Hat Enterprise Linux (RHEL) und lässt sich ohne zusätzliche Kosten aufsetzen.

Es schadet nicht, wenn IdM auf der Linux-Seite entlang der Anleitungen des Herstellers mittels Ansible automatisiert aufgesetzt ist, denn dann lassen sich sämtliche IdM-eigenen Werkzeuge unmittelbar benutzen. Im Herzen von IdM werkelt der freie LDAP-Server "389 Directory Server", der in IdM OpenLDAP ersetzt hat. Ein vergleichbares Setup wäre auf OpenLDAP-Basis ebenso möglich, allerdings haben sich sowohl Red Hat als auch SUSE von OpenLDAP verabschiedet, weshalb sich unsere Anleitung auf den Nachfolger fokussiert.

Domänen richtig aufsetzen

Von elementarer Bedeutung ist zunächst, dass die Konfiguration der Domänen auf beiden Seiten stimmt. Und "stimmt" impliziert hier einiges: Damit LDAP und AD einander Zugriff auf die jeweils eigene Domäne ermöglichen können, müssen sie unterschiedliche Domänen nutzen. Das nachfolgend beschriebene Beispiel funktioniert etwa nicht, wenn IdM eine Subdomäne der eigentlichen AD-Domäne nutzt, etwa "linux.example", während die Hauptdomäne "example" im Active Directory Verwendung findet.

Das Active Directory würde nach eigener Logik die Linux-Domäne dann als sein eigenes Herrschaftsgebiet betrachten, was nicht grundsätzlich ein Problem ist, solange Linux- und Windows-Setups strikt voneinander getrennt sind – sollen sie jedoch per Vertrauensstellung verbunden werden, ginge das im besagten Fall nicht.

Der Einfachheit halber geht unser Workshop deshalb davon aus, dass IdM auf der Linux-Seite die Domäne namens "linux.example" nutzt und das Active Directory "ad.example".

DNS und SSL im Griff

DNS spielt im Kontext zentraler Verzeichnisdienste eine wichtige Rolle. Denn Clients finden etwa über SRV-Einträge in den Zonendateien heraus, wo sie den zuständigen Verzeichnisdienst überhaupt finden. Das gilt durchaus auch für die Kommunikation, die später zwischen AD und IdM stattfinden soll. Ausschlaggebend ist hier vor allem das Kerberos-Protokoll mit seinen Eigenheiten. Anders als LDAP, bei dem der Admin in der Konfiguration des jeweiligen Diensts den LDAP-Server unmittelbar einträgt, erledigt Kerberos den größten Teil seiner Diensterkennung per DNS. Damit das Active Directory IdM später als potenziellen Domänenpartner überhaupt anerkennt, muss DNS also entsprechend eingerichtet sein. Wichtig ist hier vor allem, dass die Admins von AD und IdM unmittelbaren Zugriff auf die relevanten lokalen DNS-Einträge haben.

Übrigens: Damit ein LDAP-Server und das Active Directory miteinander kom-

munizieren können, sind im Hintergrund mehr Dienste notwendig, als es im ersten Moment den Anschein hat. IdM als Bestandteil von RHEL rollt für Cross-Domain-Szenarien beispielsweise zusätzlich zum LDAP-Server gleich noch einen Samba-Server aus, der das AD-Protokoll spricht und dem AD quasi als Sparring-Partner auf der Linux-Seite dient.

Samba ist es folglich auch, bei dem die meisten Anfragen des Active Directory später landen und das seinerseits über eine eigene Verbindung zum LDAP-Server die Abwicklung der Benutzerauthentifizierung vollführt. Einige der nötigen DNS-Einträge, die dieser Artikel später noch ausführlich auflistet, zeigen insofern gar nicht auf LDAP, sondern auf Samba.

Bevor es in medias res geht, darf das Thema SSL nicht fehlen. So wie es heute im Netz zum guten Ton gehört, Benutzerdaten nur über verschlüsselte Verbindungen auszutauschen, tut es das bei einem zentralen Dienst wie Active Directory oder LDAP selbstverständlich ebenfalls. Grundsätzlich sollte sowohl die Kommunikation einzelner Clients mit ihren jeweiligen Verzeichnisdiensten als auch die Kommunikation der Verzeichnisdienste untereinander komplett verschlüsselt sein. Was offensichtlich klingt, sorgt in der Praxis allerdings gelegentlich für Probleme. Sinnvoll ist es, ein gegebenenfalls ohnehin vorhandenes Zertifikatsregime zu nutzen, etwa eine lokale CA, die das Unternehmen selbst verwaltet.

Weil sowohl das Active Directory als auch LDAP für "ihre" Clients eigene Zertifikate ausstellen wollen, ist es zwingend nötig, dass alle involvierten Dienste allen ausgestellten Zertifikaten vertrauen. In der Praxis läuft das darauf hinaus, beispielsweise IdM mit einer eigenen Sub-CA zu versorgen, die allerdings von der Haupt-CA des Unternehmens signiert ist. Ist jene Haupt-CA auch im Active Directory als vertrauenswürdig hinterlegt, klappt die Kommunikation später problemlos und AD und IdM vertrauen sich gegenseitig.

Unser Beispiel geht deshalb im Folgenden davon aus, dass sowohl das Active Directory als auch IdM SSL-Zertifikate derselben lokalen SSL-CA verwenden, der alle Systeme uneingeschränkt vertrauen.

Noch mehr Voraussetzungen

Konstruktionen, die verschiedene Verzeichnisdomänen miteinander verbinden, sind naturgemäß komplex. Damit sich eine Anleitung wie diese nachvollziehen lässt, ist es notwendig, die im Workshop benutzten Prämissen zu klären und eventuell variable Parameter in Sachen Konfiguration zumindest einmal explizit zu erwähnen. Zwei Voraussetzungen für das reibungslose Funktionieren dieses Workshops fanden bereits Erwähnung, eine zentrale DNS-Konfiguration einerseits (die zumindest die DNS-Einträge für die beiden Domänen an die jeweiligen Domänencontroller delegiert – dazu später mehr) sowie eine durchgängig implemen-tierte SSL-Umgebung. Allerdings gibt es besonders auf der IdM-Seite noch ein paar weitere Parameter, die klar sein müssen.

Als Domäne nutzt das Active Directory wie schon erwähnt "ad.example" und IdM "linux.example". Beide Dienste bestehen allerdings darauf, dass ein "Realm" für Kerberos konfiguriert ist. Aus Gründen der Einfachheit ist dieses im Beispiel mit den Domänen identisch, also "ad.example" und "linux.example". Obendrein müssen NetBIOS-Namen für beide Seiten definiert sein, im Beispiel "AD" für Active Directory und "LINUX" für IdM. Obendrein geht der Workshop davon aus, dass es auf beiden Seiten des Forests ein funktionales Benutzermanagement gibt, dass also Administratorenzugänge vorhanden sind, auf die wahlweise dieselben Personen Zugriff haben – oder Personen, die zum Zweck des Aufbaus des Cross-Domain Forests zusammenarbeiten.

Den Netzwerkpfad herstellen

Damit AD und IdM miteinander sprechen können, brauchen sie einen Netzwerkpfad zueinander. Physisch dürfte das in den meisten Unternehmen kein Problem sein, logisch sieht die Sache allerdings anders aus. Denn das AD oder IdM sind absolut kritische Punkte in jeder Infrastruktur und in aller Regel durch etliche Firewalls und weitere Maßnahmen bestmöglich vor Angriffen geschützt. Das ist für unser Vorhaben eher hinderlich, denn damit AD und IdM miteinander kommunizieren können, müssen diverse Dienste über eine Vielzahl von Ports miteinander kommunizieren können. Eine Firewall, die zwischen eventuell eingerichteten Netzwerksegmenten steht und Traffic filtert, ist im konkreten Fall also mit einiger Wahrscheinlichkeit kontraproduktiv. Der erste praktische Schritt beim Aufbau einer Querverbindung zwischen den Diensten besteht deshalb darin, die Firewalls entsprechend durchlässig zu machen.

Im Beispiel handelt es sich um eine bidirektionale, transitive Vertrauensstellung.

Das bedeutet, dass eventuell vorhandene Subdomänen in AD und IdM ebenfalls Zugriff auf die Dienste des jeweils anderen Diensts erhalten – und zwar in beide Richtungen. Dadurch ist auf eventuell existierenden Firewalls zwischen den Diensten dieselbe Konfiguration in beide Kommunikationsrichtungen herzustellen.

Geöffnet sein muss zunächst Port 53 per TCP und UDP für DNS-Anfragen. Verschlüsseltes Kerberos bedingt den Port 88, ebenfalls per TCP und UDP. Port 123 muss per UDP in beide Richtungen frei sein, damit der Zeitdienst von Windows funktioniert. RPC wiederum setzt Kommunikation auf Port 135 per TCP und UDP voraus, NetBIOS auf Port 139, allerdings nur per TCP. Die Ports 389 und 636 müssen für TCP und UDP in beide Richtungen freigeschaltet sein, weil sie den Zugriff auf LDAP und LDAPS erlauben. Windows-spezifisch wird es wieder bei den Ports 445 und 646 (jeweils per TCP und UDP) für Samba und Kerberos.

Weil Clients zudem beliebige Ports für ihre Kommunikation mit dem Server nach dem initialen Handshake verwenden, sind die Ports 49.152 bis 65.535 ebenfalls für TCP freizuschalten. Die letzten Ports sind schließlich 3268 und 3269 für den LDAP Global Catalog von Active Directory.

Stimmen diese Freigaben nicht, verbringen Sie im schlechtesten Fall Tage und Nächte damit, LDAP-AD-Probleme zu debuggen, die sich letztlich doch als eine Fehleinstellung der Firewall herausstellen.

Dabei hilft nicht unbedingt, dass AD-Fehlermeldungen kryptisch sind und meist gar keinen Hinweis auf das eigentliche Problem enthalten. Dann hilft oft nur noch, einem Problem mit "tcpdump" zu Leibe zu rücken. Administratoren tun deshalb gut daran, ihre Firewalleinstellungen sorgfältig vorzunehmen und anschließend mittels passender Werkzeuge die freigeschalteten Ports zu prüfen. So ist zumindest die Wahrscheinlichkeit recht hoch, dass eventuell auftretende Probleme ihre Quelle nicht im Netzwerk haben.

DNS einrichten

Das Active Directory wickelt fast die gesamte Diensterkennung für IdM mittels DNS ab, sodass die passenden DNS-Einträge auch in jenem DNS-Server angelegt sein müssen, den das AD nutzt. Hier ergeben sich mehrere Optionen. Die sinnvollste besteht darin, für die IdM-Domäne einen eigenen DNS-Server zu betreiben und im Ac-tive Directory eine DNS-Delegation für die IdM-Domäne ("linux.example") auf eben jenen DNS zu hinterlegen. Wer so vorgeht, stellt sicher, dass die IdM-Zone im DNS zumindest die in der gleichnamigen Tabelle erwähnten Einträge enthält.

Der Wert "idm.linux.example" ist dabei durch den Hostnamen des Servers zu ersetzen, auf dem die IdM-Dienste laufen (und nicht etwa durch dessen Domänennamen oder dessen Realm). Obendrein ist sicherzustellen, dass "idm.linux.example" tatsächlich auf die passende IP-Adresse auflöst, also jene des IdM-Servers. Wer mit dem Zahlenchaos nicht viel anfangen kann, sei beruhigt: Die SRV-Einträge könnten theoretisch mehrere Zielhosts umfassen; die Zahlenkolonnen vor den Host-Einträgen legen ähnlich wie bei MX-Einträgen für den Mailversand die Rangfolge fest, die der Client – im Beispiel also später das AD – beim Abarbeiten nutzt. Hinzu kommt noch ein durch den Admin anzulegender TXT-Eintrag für "LINUX.EXAMPLE" mit "_kerberos.linux.example" als Wert.

IdM richtig vorkonfigurieren

Weiter geht es mit der Konfiguration von IdM. Installieren Sie auf dem IdM-System, sofern noch nicht gegeben, die Pakete "ipa-server", "ipa-server-trust-ad" und "samba-client", um die nötige Software zu erhalten. Starten Sie danach den Assistenten für das Setup des AD-Trusts mittels ipa-adtrust-install. Erlauben Sie IdM, die Datei "smb.conf " zu bearbeiten – das ist kritisch, weil ohne funktionierendes Samba das Active Directory nicht mit IdM sprechen kann.

Geben Sie bei der Frage nach dem Net-BIOS-Namen für Samba "LINUX" ein und bestätigen Sie, dass "ipa-sidgen" laufen soll. Starten Sie danach alle zu IdM gehörenden Dienste auf dem IdM-System neu. Der Befehl smbclient -L linux.example -k sollte anschließend einen IPC-Share anzeigen, nämlich jenen des nun lokal laufenden Sambas. Das ist ein sicheres Anzeichen dafür, dass Samba passend konfiguriert und bereit für die Verbindung mit dem AD ist.

Nun lässt sich zudem ein Konfigurationsschritt nachholen, der noch fehlt: Wie das Active Directory ist auch IdM unter Linux darauf angewiesen, die Hostnamen des AD sinnvoll aufzulösen. Weil das AD seine DNS-Einträge als Nameserver in der Regel selbst verwaltet und diese deshalb im "Haupt-DNS" fehlen, braucht auch IdM die Info, dass die Subdomäne "ad. example" delegiert ist. Wenn der Ziel-DNS-Server etwa die IP-Adresse 10.42.0.1 hat, lautet das passende Kommando

ipa dnsforward zone-add ad.example --forwarder=10.42.0.1 --forward-policy=only

Nun sollten sowohl das AD als auch IdM in der Lage sein, die DNS-Einträge der jeweiligen Gegenseite gut aufzulösen.

Die ersten Schritte im AD

Weiter geht es nun im Active Directory mit dem Anlegen der Vertrauensstellung.

Dazu begeben Sie sich in die Domänenkonfiguration des AD und wählen zunächst die Domäne aus, die das Ziel für die Vertrauensstellung ist, also "ad.example". Öffnen Sie die Eigenschaften dieser Domäne und klicken Sie auf "Trusts". Ein Klick auf "New Trust" fördert einen Assistenten zutage, der Sie durch die weitere Konfiguration begleitet.

Zunächst geben Sie den Namen der anderen Domäne ein, also "linux.example".

Sollten alle DNS-Einträge korrekt hinterlegt sein und die DNS-Kommunikation zwischen den Domänen funktionieren, schlägt das Active Directory im nächsten Schritt bereits von sich aus eine bidirektionale, transitive Vertrauensstellung vor. Geben Sie danach das Passwort eines Active-Directory-Administrators ein, damit das AD die Konfiguration dauerhaft abspeichert.

Wichtig: Der Assistent auf der Active-Directory-Seite fragt im Laufe des Vorgangs nach einem Passwort zur Einrichtung der Domänen. Dieses geben Sie später auch auf dem Linux-System ein, um die Berechtigung zur Herstellung des Trusts zu validieren. Merken Sie sich das hier eingegebene Passwort also gut, denn ohne ist das Einrichten der Vertrauensstellung nicht möglich.

Trust in IdM einrichten

Wenn Sie bis hierhin gekommen sind, haben Sie den größten Teil der Arbeit hinter sich. Im letzten Schritt geht es darum, die im Active Directory schon bestehende Vertrauensstellung auch in IdM einzurichten. Das bedingt auf der Linux-Seite einige Befehle auf der Kommandozeile, die aber schnell von der Hand gehen. Zunächst legen Sie mittels

ipa trust-add --type=ad ad.example --trust-secret --two-ways=true

einen Trust mit den passenden Grundparametern an. Es startet auch hier ein Assistent für die Einrichtung der Vertrauensstellung, der allerdings lediglich jenes Passwort wissen will, das Sie im AD zuvor festgelegt haben. Die Stellung ist damit bereits eingerichtet, Sie können ihr Funktionieren allerdings mit den folgenden Befehlen noch verifizieren. Das Kommando ipa trust-fetch-domains "ad.example"

holt eine Liste der vorhandenen Domänen aus dem Active Directory ab und zeigt gegebenenfalls auch Subdomänen an. Der Befehl

ipa trustdomain-find "ad.example"

bringt Details über die Hauptdomäne aus dem AD auf den Bildschirm. Ein

kinit Benutzer@ad.example

schließlich stellt auf dem Linux-System eine Kerberos-Sitzung mit einem Benutzer her, der aus AD kommt. Wenn Sie im Anschluss an den Befehl das Passwort des Benutzers eingeben und kein Fehler erscheint, hat das Anlegen der Vertrauensstellung funktioniert. Es empfiehlt sich, auf der Windows-Seite vergleichbare Tests durchzuführen. Hier sollte nun zumindest der IPC-Share für das NetBIOS des Samba-Servers sichtbar sein, und ein Login unter Angabe der Domäne "linux.example" an Diensten, die gegen das Active Directory authentifizieren, sollte ebenfalls funktionieren.

Wege zum Troubleshooting

Sollte der beschriebene kinit-Befehl auf Linux-Seite nicht das gewünschte Ergebnis liefern oder das Active Directory partout die Linux-Domäne nicht identifizieren können, wird es etwas ungemütlich. Denn weder das AD noch Samba oder der 389 Directory Server unter Linux geben sich besonders auskunftsfreudig, was Logdateien und klare Fehlermeldungen angeht. Hier hilft sich der Administrator am besten selbst, indem er sich dem Problem schichtweise systematisch annähert. Denn die möglichen Gründe dafür, dass die Vertrauensstellung nicht funktioniert, sind zahllos.

Wie üblich gilt, sich zunächst die tiefhängenden Früchte anzuschauen. Stimmt das beim Einrichten der Domäne unter Linux angegebene Passwort für das Active Directory mit jenem überein, das Sie dort während des Setups eingegeben haben?

Hier gilt es zwischen dem Passwort zu unterscheiden, das der AD-Admin eingibt, um sich selbst für das Anlegen der Domäne zu autorisieren, und dem für die Domäne festgelegten Passwort. Letzteres ist beim IdM-Setup auf der Linux-Seite einzugeben, Ersteres ganz sicher nicht.

Es empfiehlt sich gegebenenfalls, die Vertrauensstellung auf der Seite von IdM nochmals zu löschen und neu anzulegen, falls Grund zur Annahme besteht, dass das Passwort falsch ist.

Hilft auch dies nicht weiter, müssen Sie als Administrator notgedrungen hinunter in den Maschinenraum steigen. Die Wahrscheinlichkeit, dass es ein Problem mit der Benutzerverwaltung hüben oder drüben gibt, ist relativ gering – zumindest dann, wenn das DAD und IdM unabhängig von der Vertrauensstellung ihre lokalen Clients weiterhin normal bedienen.

Viel wahrscheinlicher ist, dass es Schwierigkeiten bei der Kommunikation von AD und Samba gibt, die den größten Teil des Cross-Domain-Traffics ausmacht.

Die Krux: Ab Werk sehen Sie hier erstmal gar nichts, denn für Samba ist in RHEL 8 ab Werk das Logging deaktiviert. Die passende Konfigurationsdatei "/etc/samba/ smb.conf " enthält des Rätsels Lösung: Die Zeile "log level = 5" sorgt dafür, dass Samba praktisch jede Kommunikation mit Active Directory loggt. Unter "/var/log" finden sich anschließend die Logdateien zwischen AD und dem lokalen Samba-Server. Aber Vorsicht: Es gibt mehrere einzelne Logs für unterschiedliche Samba-Dienste, die involviert sind. Ein Teil der relevanten Details findet sich mithin in den Logdateien für einzelne Clients, die die IP-Adresse oder den NetBIOS-Namen eines Clients im Dateinamen haben. Andere Meldungen müssen Sie mühsam aus "log.smbd" und "log.nmbd" pulen.

Und als ob die Sache noch nicht schlimm genug wäre, stellen sich die Fehlermeldungen in vielen Fällen auch noch als äußerst kryptisch dar. Hieran trägt Samba allerdings nur bedingt Schuld. Denn die Fehlermeldungen, die es bei der Kommunikation mit dem AD von diesem empfängt, schreibt es 1-zu-1 in seine eigenen Logs.

Wenn das Active Directory in deutscher Sprache konfiguriert ist, kann es also durchaus sein, dass in den Logs eines eigentlich englischsprachigen Systems plötzlich deutsche Meldungen auftauchen. Entnervten Admins sei an dieser Stelle dringend geraten, Kollegen aus der Windows-Abteilung ins Boot zu holen. Denn diese haben die eine oder andere Meldung im Idealfall schon einmal gesehen und wissen hoffentlich schnell Rat. Sind alle Probleme beseitigt, tun Admins zudem gut daran, das Logging in Samba wieder herunterzudrehen, ganz abzuschalten oder Logrotation für den Dienst einzurichten. Denn andernfalls läuft die Platte des IdM-Servers irgendwann mit Logmüll voll.

Fazit

Beim Aufbau einer Vertrauensstellung zwischen Windows und Linux gilt: Gut vorbereitet ist halb erledigt. Wenn die DNSund SSL-Settings stimmen, ist zum Herstellen einer Vertrauensstellung kaum mehr nötig als ein bisschen Klickerei auf der Windows-Seite und etwas Kommandozeilenarithmetik unter Linux. Der Mühe Lohn sind Benutzer, die sich auf beiden Seiten der Installation an Ressourcen anmelden können, die der dortige Verzeichnisdienst verwaltet – vorausgesetzt, sie geben beim Login-Versuch die passende Domäne an.

Einmal mehr zeigt sich hier, wie leistungsfähig Open-Source-Software mittlerweile ist. Denn Samba dient dem AD als fast vollständig kompatibler Partner auf Augenhöhe, bis hin zu dem Punkt, an dem das Active Directory ein ebensolches auf der Gegenseite erkannt zu haben glaubt.

Wohlbemerkt: Eine Cross-Forest-Vertrauensstellung wie im Beispiel ist nicht die perfekte Lösung für alle Herausforderungen. Wollen Firmen eigentlich nur, dass Nutzer aus dem AD sich auch auf Linux-Systemen anmelden können, ist ein LDAP-Proxy möglicherweise die bessere Option – und deutlich einfacher zu warten. Vertrauensstellungen zwischen Domänen ergeben vom Aufwand her nur in jenen Umgebungen Sinn, in denen beide Domänen dauerhaft erhalten bleiben sollen. Dafür ist die gezeigte Lösung ein guter technischer Kompromiss. (ln)

Link-Codes

[1] Vertrauensstellungen zwischen IdM and AD einrichten m8zc1