Duell der Datenbanken: In einem Shootout messen sich MySQL und PostgreSQL. Der Schwerpunkt vom ADMIN 06/2011 überprüft, wer schneller ist und gibt einen ... (mehr)

Den 389 DS installieren

Im Web zirkulieren einige sehr gute Artikel über die Konfiguration des 389 Directory Server, aber der beste Startpunkt ist die Dokumentation des Red Hat Director Servers [2] . Tatsächlich ist nämlich der 389 DS die Code-Basis für dieses Produkt. Wer keine Zeit hat, sich durch den umfangreichen Admin-Guide zu graben, der ungefähr den Umfang des Telefonbuchs von Manhatten hat, der findet einige nützliche How-tos in der Fedora-Dokumentation [3] .

Als Voraussetzung für die Installation muss entweder das Open JDK 1.6.0 oder Sun JDK 1.6.0 aufgespielt sein. An das Open JDK gelangt man einfach via »yum install jsvs-2.6.0-openjdk« . Benutzt man mehr als eine JDK-Version, muss man zuvor via »alternatives --config java« eine passende einstellen. Danach installiert man ebenfalls mit »yum« das Paket »389-ds« nebst allen Paketen, von denen es abhängt. Wenn dieses Paket kein Bestandteil der gerade verwendeten Linux-Distribution sein sollte, dasnn hilft zuverlässig das Yum-Repositiory EPEL weiter (Extra Packages for Enterprise Linux). Wer das benötigt, installiert zunächst »epel-release-5.3.noarch.rpm« .

Ist der Directory-Server installiert, lässt man abschließend das Skript »setup-ds-admin.pl« laufen, das ihn konfiguriert. Dabei kann eine Warnmeldung wegen der Anzahl verfügbarer Filedeskriptoren auftauchen oder eine Empfehlung, die TCP-Keepalive-Zeit zu verringern. Diese Warnungen kann man aber zumindest in einer Testumgebung ignorieren, ohne dass das irgendwelche Folgen hätte. Muss man diese Parameter aber doch anpassen, findet man Näheres dazu in [5] .

Das Skript »setup-ds-admin.pl« stellt einige Fragen, aber in den meisten Fällen kann man die Default-Antwort bestätigen. Als Minimum sollte man den Root-Suffix einstellen, im Beispiel ist es »dc=example, dc=local« .

Nach der Konfiguration laufen zwei Services: ein Directory Server (der LDAP-Server) und ein Administrationsserver, der sich der Systemeinstellungen annimmt und eine Reihe Web-Applikationen bereitstellt, darunter ein Organigramm und ein Telefonbuch. An diesem Punkt sollte dafür gesorgt werden, dass diese administrativen Dienste beim Booten starten:

chkconfig dirsrv on
chkconfig dirsrv-admin on

Für die Verwaltung des neuen LDAP-Servers gibt es eine Java-GUI, die sich mit dem Kommando »389-console« starten lässt. Dieser Client ist auch unter Windows installierbar.

Chaining konfigurieren

Nachdem nun der Directory Server läuft, muss er dafür konfiguriert werden, LDAP-Anfragen für »dc=foo, dc=example, dc=local« beziehungsweise »dc=bar, dc=example, dc=local« an den jeweils richtigen AD-Domänen-Controller weiterzuleiten (Chaining). Dazu öffnet man einen der frisch installierten 389-Clients (der auf dem LDAP-Server aber auch auf einer anderen Maschine laufen kann) und verbindet sich mit dem Benutzernamen »cn = Directory Manager« auf Port 9830 wie in Abbildung 4 . Danach sollte sich die Management Konsole öffnen.

Abbildung 4: Einloggen beim 389 Directory Server als Directory Manager.

Dann selektiert man den Directory Server im linken Panel wie in Abbildung 5 zu sehen und klickt auf »Open« . Nach einem Rechtsklick auf den Root-Suffix »dc=example, dc=local« wählt man unterhalb des Tab »Configuration« anschließend »New Root Sub-Suffix« aus. In dem Dialog der daraufhin erscheint, deselektiert man die Checkbox und erzeugt einen Suffix mit demselben Distinguished Name wie die AD-Domäne ( Abbildung 6 ).

Abbildung 6: Einen neuen Root-Sub-Suffix erzeugen.
Abbildung 5: So verbindet man sich mit dem aktuellen Verzeichnis als Benutzer Directory Manager.

Danach klappt man den neuen Suffix durch einen weiteren Rechtsklick auf und wählt »New Database Link« . Der Datenbank-Link braucht einen Namen und die IP-Adresse des entfernten Windows-Controllers. Das Active Directory erlaubt anonymen Benutzern normalerweise keinen Lesezugriff, weswegen für jeden Benutzer, der das Recht zum Suchen haben soll, Benutzername und Passwort einzugeben sind. In einer Produktivumgebung sollte man unbedingt TLS verwenden, um diese Eingaben zu schützen. Aus Umfangsgründen verzichten wir auf eine Darstellung der TLS-Option, sodass Abbildung 7 die Simple-Bind-Option in einer Testumgebung zeigt.

Abbildung 7: Einen Datenbank-Link ins Active Directory anlegen.

Im nächsten Schritt müssen ein paar Konfigurationsparameter angepasst werden, damit das Chaining funktioniert. Dazu öffnet man das Directory-Tab, klappt die Items »config« , »plugins« und »chaining-database« auf und doppelklickt dann auf den Namen der mit dem AD verbundenen Datenbank.

Darauf kann man die Option »nsProxiedAuthorization« in »off« ändern. Damit weiß der 389 DS, dass er die Autorisierung via Proxy abschalten soll und alle Binds für die Verkettung so ausführen soll, wie auf den vorangegangenen Screens konfiguriert.

Nun stoppt man den 389 DS mit »service dirsrv stop« . Jetzt lässt sich die Datei »/etc/dirsrv/slapd-*dse.ldif« editieren. In ihr sucht man nach einer Sektion, die mit der folgenden Zeile beginnt:

dn: cn=chaining database, cn=plugins,cn=config

In dieser Sektion löscht man alle Zeilen, die »nstransmittedcontrols« enthalten. Das schaltet ein paar potenziell problematische Controls ab. Danach sichert man das File und startet den Directory Server neu: »service dirsrv start« . An diesem Punkt sollte man den lokalen 389 DS nach Usern im AD fragen können, beispielsweise so:

ldapsearch -x -b dc=example,dc=local "(uid=alexd)"

Damit auch die Benutzer in das Resultat der Anfrage eingeschlossen werden, die im zweiten Domain Controller gespeichert sind, wiederholt man einfach den Prozess und kreiert einen weiteren Sub-Suffix und einen neuen Datenbank-Link. Dabei muss man daran denken, dass auch der zweite Domain Controller über einen Account verfügen muss, zu dem man sich verbinden kann, und dass auch dort das Management für Unix installiert sein muss.

Ein Problem kann beim Zusammenfügen der beiden AD-Domänen in ein virtuelles Directory auftauchen: Unix-Attribute wie etwa UIDs können in Konflikt geraten. Das kann man verhindern, indem man verschiedenen AD-Domänen verschiedene Bereiche von UIDs zuweist, was sich erzwingen lässt.

Ein anderes mögliches Problem ist, dass das Active Directory Resultate in Form von Seiten zu je 1000 Objekten zurückgibt, wogegen das Chaining-Plugin des 389 DS das Seitenkonzept nicht kennt. Das heißt: Sobald es mehr als 1000 User mit Unix-Attributen im Active Directory gibt, erhält man auf Suchanfragen nur noch Teilergebnisse zurück. Dieses Problem lässt sich beheben, indem man die »MaxPageSize« im Active Directory heraufsetzt, wie das in der Microsoft Knowledge Base beschrieben ist [7] .

comments powered by Disqus
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023