© FP interactive

Einen Open-LDAP-Server aufsetzen und sinnvoll strukturiert mit Daten füllen – das macht Arbeit. Die aber ist gut investiert, denn die User zentral verwalten, erspart dem Admin später ein Vielfaches an Zeit und Nerven. Los geht’s mit der Integration gängiger Groupwareprodukte.

Schon bei 50 Mitarbeitern ist die Benutzerverwaltung zeitraubend. Mehr noch als neue oder weggehende Kollegen sind es geänderte Zuständigkeiten, die Admins zwingen Zugänge und Rechte Einzelner neu zu regeln. Zugeschaltete Clouddienste, in denen alle Mitarbeiter abzubilden sind, tun ein Übriges. Auf der Suche nach Automatisierung stößt der Linux-Admin sofort auf LDAP. Wegen der seit Jahren steigenden Zahl an Servern und Diensten lohnt der Betrieb eines Open-LDAP-Directory schon bei einer zweistelligen Benutzerzahl.

Dieser Schwerpunkt zeigt anhand ausgewählter Services, wie Admins durch konsequentes Einbinden eines zentralen LDAP-Servers die laufende Benutzerverwaltung vereinfachen. Zugleich verhindern sie, dass überholte Zugangsrechte in einzelnen Diensten schlummern und einerseits im Nachklapp zu Benutzersupport und andererseits zu Sicherheits- und Compliance-Problemen führt.

Moderne Groupwaresuites, mit denen dieser Schwerpunkt startet, setzt ganz selbstverständlich auf LDAP für Benutzerverwaltung und mehr. Mail, Kalender, Adressbuch, Chat, Dokumentablage – Groupware vereint viele Dienste unter einem Dach, was mehr ist als die Summe seiner Teile. Durch eine hochgradige Integration entsteht nicht nur für den Anwender ein homogenes Ganzes mit Single-Sign-on. Auch die Verwaltung, darunter die der Benutzer, erfolgt zentral.

LDAP im Zentrum

Die Groupwarelösungen können diese Aufgabe zwar mit ihrer nativen Benutzerverwaltung bewältigen, dann müsste der Admin jedoch alle firmeninternen Kontakte, also die User, doppelt pflegen. LDAP lässt sich bei Integrationsbemühungen (auch) für die Groupware in die übrige IT-Landschaft als De-facto-Standard für zentrale Benutzerverwaltung und Authentifikation ansehen.

Alle hier betrachteten Open-Source-Produkte – Open-Xchange [1], Tine 2.0 [2], Zarafa [3], Kolab [4], Egroupware [5], Scalix [6] und Zimbra [7] – unterstützen die gängigen LDAP-Dienste Open LDAP und Microsoft Active Directory (siehe Tabelle 1). Damit ist der Weg frei für eine netzweite zentrale Useradministration, die Systemgrenzen überwindet.

In den anhand von LDAP umgesetzten Möglichkeiten unterscheiden sich die einzelnen Systeme sichtlich. Der kleinste gemeinsame Nenner ist die Authentifikation übers Verzeichnis, darüber hinaus erstreckt sich die Bandbreite von der Synchronisation der LDAP-Daten in die Groupware-Userdatenbank über Adressdaten und Verteilerlisten bis hin zu individuellen Konfigurationen.

¹ kostenpflichtige Lizenz erforderlich

Installation ziemlich simpel

Der rein technische Aspekt des Anbindens der jeweiligen Groupwaresuite an einen externen LDAP-Verzeichnisdienst stellt keinen Administrator vor nennenswerte Herausforderungen, fast alle gängigen Systeme haben alles Nötige an Bord und bedürfen nur der passenden Konfiguration. Einzig bei Open-Xchange muss der Admin das Plugin-Paket »open-xchange-authentication-ldap« eigens installieren, es ersetzt »open-xchange-authentication-database« . Das Konfigurieren der LDAP-Anmeldung erfolgt über die Datei »/opt/open-xchange/etc/groupware/ldap.properties« .

Die Anbindung muss der Groupware-Verantwortliche bei allen Systemen explizit aktivieren und konfigurieren. Für Zarafa beispielsweise erledigt er dies in »/etc/zarafa/server.cfg« mit den Zeilen:

user_plugin = ldap
user_plugin_config = /etc/zarafa/ldap.cfg

Die LDAP-Konfiguration nimmt er danach in »/etc/zarafa/ldap.cfg« vor.

Jede Groupware verlangt die Angabe der LDAP-URL(s), eines LDAP-Admin-Users sowie einer Base-DN als Einstiegspunkt im Directorybaum. Ist ein Active Directory im Spiel, kommt noch der Name der Windows-Domain hinzu. Sowohl bei Egroupware als auch bei dem davon geforkten Tine 2.0 konfiguriert der Admin den LDAP-Zugriff, wie in Abbildung 1 zu sehen ist, bequem im Webbackend.

Wer alle Anmeldevorgänge in seiner IT über LDAP abwickelt, für den gerät der LDAP-Server zur kritischen Komponente. Damit wird es fast zwingend, ein redundantes Directory-Setup mit einer Master-Slave-Architektur zu betreiben. Viele Groupwaresuites unterstützen das explizit. Abbildung 2 zeigt ein Beispiel für Redundanz mit Zarafa.

Abbildung 1: Das UCS-LDAP-GUI ermöglicht es, LDAP sowie Zarafa-User in einer einheitlichen Umgebung zu verwalten.

Abbildung 2: Sinnvoll: Um Hochverfügbarkeit zu gewährleisten, lassen sich LDAP-Server im Cluster betrieben – Groupware wie Zarafa unterstützen das explizit.

Die Intelligenz steckt im Schema

Weiter mit den Vorarbeiten: Administratoren, die es nicht mit Egroupware oder Tine 2.0 zu tun haben, müssen nun das Schema ihres LDAP erweitern, damit das Directory über die reinen Anmeldedaten hinaus weitere Informationen aufnehmen kann, nach denen die Groupware verlangt, etwa Adressfelder und spezielle Konfigurationen für Kalender oder Gruppen.

Systeme wie Zarafa und Scalix bringen dafür eine entsprechende Schema-Definition mit, die sich das LDAP leicht einverleiben kann. Für Zarafa und Open LDAP reichen zwei einfache Schritte:

cp /usr/share/doc/zarafa/zarafa.schema /etc/openldap/schema/zarafa.schema
include /etc/openldap/schema/zarafa.schema

Der besseren Performance wegen fügen manche Systeme einer Reihe von Attributen einen Index hinzu. Den Index muss der Admin gegebenenfalls individuell erweitern – die Logfiles des Open-LDAP-Servers geben ihm Hinweise auf das Ob und Wie.

Zimbra installiert die umfangreichen eigenen Schemata vollautomatisch, sobald für eine Zimbra-Domain eine externe LDAP-Anbindung aktiviert ist (Abbildung 3). Eigene Attribute fügen Administratoren vorab an die Datei »/opt/zimbra/conf/attrs/zimbra-attrs.xml« an.

Abbildung 3: Bei Zimbra kümmert sich ein grafischer Assistent um die Anbindung an ein externes Directory.

Authentisierung via LDAP

Alle frisch installierten Groupwarepakete hinterlegen die Benutzer samt deren Daten wie Adressen und Konfigurationen in einer Datenbank. Kolab nutzt dafür bereits von Hause aus LDAP in Gestalt des 389 Directory Server [8], Zimbra setzt auf Open LDAP.

Wer seine Groupware – wie dieser Artikel propagiert – an ein LDAP anbindet, delegiert auch die Authentisierung der Benutzer an das Directory. Für die Anwender ist das ein transparenter Vorgang, meist können sie ihre Mailadresse beim Groupware-Login verwenden. Sofern es sich um ein extern angebundenes LDAP-Directory handelt, gelingt das Ändern von Passwörtern fortan aber nur noch über das Directory. Für Zimbra [9] und Zarafa gibt es Plugins, die dieses nicht-intuitive Verhalten beheben.

Im ersten Moment überrascht, dass jedes System trotz LDAP-Authentisierung auf (s)eine lokale Benutzerdatenbank angewiesen bleibt, die für jeden Benutzer weiterhin ein Konto führt. Egroupware und Tine 2.0 lassen dabei die Wahl zwischen reiner Passwortprüfung beim zentralen Login einerseits und dem Beziehen aller benutzerbezogenen Daten aus dem LDAP andererseits.

Je nach Konfiguration erstellt der Admin die Benutzerprofile entweder komplett manuell oder die Groupware erzeugt sie anhand von Vorgaben im LDAP automatisch, wie Abbildung 4 beispielhaft zeigt. Im besten Fall loggt sich ein Besucher ein und die Groupware legt ein lokales Konto an oder aktualisiert es.

Abbildung 4: Die LDAP-Konfiguration kann in Tine 2.0 über das Admin-GUI erledigt werden.

Die Synchronisation vom LDAP nach Hause

Die übrigen Kandidaten wie Open-Xchange, Zarafa, Zimbra und Scalix setzen auf Synchronisationsroutinen, die einerseits die relevanten Benutzer- und Gruppen- sowie Konfigurations-Daten aus dem Directory in die Groupwaredatenbank schaufeln und andererseits in diesem Zusammenhang nötige Arbeiten erledigen, etwa Mailboxen für neue User anlegen (Abbildung 5). Generell greifen die Synchronisationsroutinen auf das Directory nur lesend zu.

Bei Scalix und Open-Xchange ruft der Admin diese Routine auf der Kommandozeile auf. In Scalix ist vor dem erstmaligen Gebrauch ein so genanntes Sync Agreement anzufertigen, das die Vertrauensstellung zwischen dem Directory und dem Groupwareserver ausweist. Anschließend genügt ein »omldapsync -u Agreementname« , um geänderte Daten vom Directory in den Groupwareserver zu kopieren.

Zarafa setzt gewöhnlich auf eine Just-in-Time-Synchronisation, bei der es im LDAP neu angelegte Benutzer automatisch in seine lokale Datenbank übernimmt oder gelöschte User entfernt. Bei sehr großen Nutzerzahlen kann der Admin diese Automatik deaktivieren und den Sync zeitgesteuert per »zarafa-admin –sync« -Kommando laufen lassen.

Auch Zimbra überträgt Userdaten aus dem externen LDAP automatisch, nennt den Mechanismus Autoprovisioning und implementiert zwei Betriebsmodi: Im Lazy Mode erfolgt die Übertragung immer erst, wenn sich der betreffende User einloggt. Im Eager Mode passiert dies in einem festzulegenden Intervall.

Bei Open-Xchange müssen die Admins zunächst das Tool OX LDAP Sync installieren und den LDAP-Bind sowie das Kopierverhalten in der Datei »/opt/oxldapsync/etc/ldapsync.conf« konfigurieren, damit sich Open-Xchange mit Open LDAP synchronisieren kann. Der eigentliche Aufruf erfolgt dann mit:

./oxldapsync.pl -c 1 -A oxadmin -P Adminpasswort -v -s

Bei Active Directory empfiehlt es sich, Groupware-User einem eigenen Branch zuzuordnen und nur diesen zu synchronisieren, damit keine AD-System-Useraccounts wie »Administrator« oder »Gast« auf den Groupwareserver gelangen.

Abbildung 5: Der zentrale LDAP-Server stellt für die jeweilige Groupware die relevanten Userdaten zur Verfügung und authentisiert die Logins.

Besonderheiten mit Active Directory

Für die Anbindung einer Groupware an Microsofts Active Directory (AD) für die zentrale Nutzerverwaltung und Single-Sign-on sind vorbereitend zumeist drei Schritte erforderlich:

1. Schema erweitern.

2. AD GUI erweitern.

3. Optional Kerberos konfigurieren.

Administratoren von Scalix und Zarafa erledigen die Schritte 1 und 2 einfach mit den mitgelieferten Windows-Installationsprogrammen (Abbildung 6).

Zimbra hält für den gleichen Zweck den Authentication Configuration Wizard in seinem Admin-GUI vor. Hier gibt der Admin bloß die AD-Domain sowie die Zugangsdaten zum MS AD zusammen mit einem User an, der die Zugangsberechtigungen zum Active Directory besitzt. Den Rest übernimmt der Wizard. Als vorteilhaft erweist sich, dass man die Authentisierungsmethode pro (Zimbra-)Domain separat einstellen kann.

Um in den Groupwaresystemen Kerberos in Betrieb zu setzen, sind lediglich die in den Admin-Guides beschriebenen Schritte auszuführen.

Abbildung 6: Scalix erweitert im Active Directory die Verwaltung um eigene Elemente.

Adressbücher und Kontakte zentral im LDAP

Scalix, Zarafa, Open-Xchange, Zimbra sowie Kolab können über Benutzer-, Gruppen- und Firmen-Daten hinaus weitere Objekttypen im LDAP verwalten und die damit hinterlegten Informationen abrufen und den Groupware-Nutzern verfügbar machen:

• Die Global Address List (GAL): Anwender können in diese Liste nach Adressen suchen, die Groupware delegiert den Suchvorgang an das LDAP. Über LDAP-Filter lassen sich (dynamische) Untergruppen bilden.
• Kontaktdaten: Das sind im LDAP gespeicherte Adressen von Personen, die keine User der Groupware sind (Abbildung 7).
• Verteilerlisten für den Mailversand an Gruppen von Adressen.
• Dynamische Benutzergruppen, die zumeist auf (definierbaren) LDAP-Filtern basieren. Mit ihnen lassen sich zum Beispiel Groupware-User von solchen LDAP-Usern (virtuell) trennen, die nichts mit der Groupware zu tun haben. Zarafa rät allerdings bei angebundenem Microsoft AD von übermäßigem Gebrauch solcher Filter ab, da sie zu langen Antwortzeiten führen würden.

Bevor Open-Xchange-Benutzer Zugriff auf die oben genannten Kontaktdaten bekommen, muss sie die Groupware erst übernehmen. Der Systemverantwortliche installiert dazu das Plugin »open-xchange-contact-storage-ldap« und passt die Konfiguration an die lokalen Gegebenheiten an, beispielsweise das Mapping der Kontaktattribute.

Abbildung 7: Zarafa-Kontakte liegen hier im Active Directory, die Groupware synchronisiert sie.

Meist wächst Vorhandenes zusammen

Es gehört zu den sehr seltenen (und zugleich glücklichen) Momenten in einem Administratorleben, wenn er ein LDAP und eine Groupware auf der grünen Wiese und gleichzeitig aufsetzen darf. Ungleich häufiger und deutlich herausfordernder ist die Situation, dass der Verzeichnisdienst schon länger existiert, nach und nach an lokale Besonderheiten und nachfragende Applikationen angepasst und mit vielerlei Daten gut gefüllt ist. Hier das Zusammenführen mit einem (eventuell auch schon länger in Betrieb befindlichen) Groupwaresystem hinzubekommen, macht eine Analyse der Attribute beider Partner nötig.

So speichert Tine-2.0 die IDs seiner User im LDAP-Attribut »entryUUID« , lokal jedoch im Datenbankfeld »account_id« . Ist nun eine existierende Tine-2.0-Userdatenbank nach LDAP zu migrieren, muss der Admin alle Tine-2.0-IDs auf die »entryUUID« umstellen.

Ähnlich sieht es bei Scalix-Installationen aus: Deren Global-Unique-ID muss der Admin auf die »objectGUID« des Active Directory matchen. Mit einem »omldapsearch« -Kommando kann er die betreffenden Userdaten im LDIF-Format auslesen und mit einem Skript passend modifizieren.

Auch der umgekehrte Fall führt zu manueller Arbeit – wenn ein existierender AD-Server mit Usern und Gruppen mit Scalix zu verbinden ist. Damit Scalix sie importieren kann, sind mehrere Attribute vorab im AD mit Daten zu befüllen: »scalixMailboxClass« , »scalixMailnode« und »scalixScalixObject« . Im Scalix-Wiki findet sich ein Skript, das diesen Vorgang zu automatisieren hilft [10].

Überhaupt sind die meisten Groupwares dafür ausgelegt, die Mappings von vorgefundenen LDAP-Attributen wie Gruppenzugehörigkeit oder einzelne Adressendaten auf die ebenfalls fest vorgegebenen lokalen Felder flexibel anzupassen. Bei Zarafa beispielsweise lassen sich Basis-Mappings direkt in der »ldap.cfg« vornehmen, Listing 1 zeigt ein entsprechendes Beispiel.

Weitergehende Mappings, für individuelle Adressfelder vielleicht, erledigt der Administrator in der Datei »/etc/zarafa/ldap.propmap.cfg« . Zimbra-Administratoren konfigurieren Mappings entweder über das GUI oder benutzen das Zmprov-CLI [11], um beispielsweise GAL-Mappings über das Attribut »zimbraGalLdapAttrMap« zu bearbeiten.

01 ldap_user_search_filter = (zarafaAccount=1)
02 ldap_user_unique_attribute = uidNumber
03 ldap_user_unique_attribute_type = text
04 ldap_fullname_attribute = cn
05 ldap_loginname_attribute = uid
06 ldap_emailaddress_attribute = mail
07 ldap_emailaliases_attribute = zarafaAliases
08 ldap_password_attribute = userPassword

Vereint und doch getrennt

In der Hauptsache pflegt der Groupware-Admin die Userbasis mit normalen LDAP-Tools. Manche Produkte helfen aber mit; so erlauben es Scalix-Extensions, Mailboxen im Active Directory hinzuzufügen oder zu entfernen. Gleiches gilt für die Verwaltung von Gruppen (Mailnodes) und Domains, Zuteilung von Administratorrechten, das Umstellen von Sprachen oder Setzen von Quotas.

Solche erweiterten Befugnisse in der Groupware ändern aber nichts daran, dass der Admin mit zwei GUIs arbeiten muss – eines für die Groupware, eines für das LDAP. Löbliche Ausnahmen bilden Kolab und das Gespann aus Univention Corporate Server (UCS) und Zarafa. Das Integrations-Kit Zarafa4ucs kümmert sich um das Einbinden der Groupware in das Managementsystem des UCS [12]. Die LDAP-Anbindung besteht im Wesentlichen aus dem Erstellen eines erweiterten Schemas im UCS. Anschließend verwaltet der UCS-Administrator Zarafa-Benutzer und -Konfiguration in seinem GUI mit.

Fazit

Dass alle hier betrachteten Groupwarelösungen LDAP unterstützen, hat nicht nur mit der schieren Menge an Usern zu tun, mit der manche konkrete Installation klarkommen muss, sondern auch mit dem Umstand, dass selbst eine überschaubare Userbase mit der steigenden Menge im Unternehmen angebotener Dienste zum Auseinanderdriften neigt. Technisch betrachtet gelingt die Integration in ein zentrales Directory recht leicht, robust ist sie zudem. Das beweisen nicht zuletzt Kolab und Zimbra, die von Hause aus nativ auf LDAP setzen und dort neben Usern auch umfassende Konfigurationsdaten ablegen.

Doch sollten geneigte Sysadmins mit einiger Arbeit bei Planung und Zusammenführung der Systeme rechnen, bis die Datenstrukturen und Attribute inhaltlich-logisch zusammenpassen. Gewöhnen müssen sie sich auch daran, dass die Datenverschmelzung im LDAP-Dienst bei den allermeisten hier betrachteten Systemen nicht automatisch zu einer Zentralisierung der Administrationswerkzeuge führt. Kolab sowie Zarafa Huckepack auf UCS beweisen aber, dass All-in-one-Admin-GUIs möglich sind.

Der Autor

Andrej Radonic arbeitet – vor allem rund um die Themen Virtualisierung, Cloud und Groupware – als freier Journalist, Fachbuchautor und Vorstand der Intersales AG.