eDirectory-Connector

#DATENFLUSS MIT KONZEPT

Der neue UCS-eDirectory-Connector für Brandenburgs Schulen

In Brandenburg arbeiten zwei große Systeme zusammen, um die Identitäten in Schulen zu verwalten: UCS@school arbeitet auf der Ebene des Landes-IDM (LIDM) sowie auf kommunaler Ebene beim IDM der Dikom (KIDM) und stellt auf diesen beiden Ebenen alle erforderlichen Funktionalitäten für die Verwaltung der Identitäten von Lehrern und Schülern zur Verfügung. An vielen Schulen im Bereich der Dikom läuft jedoch als zweites System die Schulserverlösung paed.ML Novell. Die beiden Systeme sind an einigen Stellen unterschiedlich aufgebaut, sowohl in ihrer Struktur als auch in ihrer Arbeitsweise. Unsere Aufgabe war es, eine Brücke vom KIDM mit ucs@school zu paed.ML Novell zu schlagen, die die Daten sicher und zuverlässig überträgt – ohne Umwege und ohne Datenverluste.

Unser neuer eDirectory-Connector, der aktuell in der Testphase ist, meistert diese Herausforderung. Er sorgt dafür, dass die Identitäten aus dem kommunalen Dikom-IDM automatisiert und reibungslos in die paed.ML Novell-Welt übertragen werden. In diesem Artikel erfahren Sie, wie die beiden Systeme zusammenarbeiten, welche technischen Hürden wir dabei überwinden mussten und wie der Connector Schritt für Schritt den Datenfluss sicherstellt.

Der erste Pfeiler:
Das Landes-IDM

Das Ministerium für Bildung, Jugend und Sport (MBJS) in Brandenburg hat in den letzten Jahren die digitale Schullandschaft komplett neu gestaltet. Eine wichtige Komponente ist das Schulportal, das die digitalen Fachverfahren bündelt und an zentraler Stelle zur Verfügung stellt. Um die Daten der Lehranstalten sowie um die Identitäten des Lehrpersonals und der Schüler*innen kümmert sich das über UCS@school realisierte Identitätsmanagement (IDM). Dabei fließen Daten aus mehreren digitalen Fachverfahren zusammen:

• ZENSOS: Das Zentrale System zur Online-Verwaltung von Schulinformationen sammelt und strukturiert die im Ministerium verwalteten Schuldaten: Dazu gehören Stammdaten der Lehranstalten, Leistungsdaten wie Prüfungsergebnisse und langfristige Entwicklungen, z. B. bei den Schülerzahlen.
• APSIS: Das zentrale System für die automatisierte Personal- und Stellenbewirtschaftung unterstützt das staatlichen Schulamt von Brandenburg bei der Verwaltung des Lehrpersonals.
• weBBschule konzentriert sich auf die Daten der Schüler*innen: Es erfasst die Stammdaten der Schüler*innen, die Klassenzuordnung von Schüler*innen und Lehrkräften, Noten, Fehlzeiten und mehr.

Seit 2022 bildet die zentrale Kommunikationsschnittstelle weBBservice das verbindende Element. Sie nutzt die Kelvin REST API von Univention, um direkt auf den Verzeichnisdienst von UCS@school zuzugreifen und die verschiedenen Fachverfahren – ZENSOS, APSIS und weBBschule – nahtlos in das Landes-IDM zu integrieren.

Der zweite Pfeiler:
DIKOM und paed.ML Novell

Das KIDM der Dikom übernimmt im ersten Schritt die für die jeweilige kommunale Ebene relevanten Identitäten aus dem zentral verwalteten LIDM, das beim zentralen Dienstleister des Landes Brandenburg – dem Zit-BB – gehostet wird. Die Dikom – der Zweckverband Digitale Kommunen Brandenburg – ist ein Zusammenschluss vieler Gemeinden, Ämter, Städte und sonstiger juristischer Personen des öffentlichen Rechts im Land Brandenburg. Die DIKOM bündelt die IT-Dienstleistungen der Kommunen und stellt für die Mitglieder eine zentrale, mandantenfähige Schulserver-Lösung bereit. Im Einsatz ist dabei an vielen Schulen die Schulverwaltungslösung paed.ML Novell des Landesmedienzentrums Baden-Württemberg.

Die paed.ML Novell ist mehrschulfähig und bringt ein eigenes Mobile-Device-Management-System zum Verwalten von mobilen Endgeräten mit. Der Schulserver bietet Klassenraum-Funktionen für Lehrkräfte, etwa die Steuerung von Schülergeräten, Bildschirmübertragungen oder das Sperren von Internetzugängen. Außerdem erleichtert paed.ML zentrale Aufgaben wie das Verteilen von Software, das Einrichten von Jugendschutzmaßnahmen und das sichere Speichern von Dateien. Die paed.ML Novell basiert auf dem Verzeichnisdienst NetIQ eDirectory und nutzt eine schulspezifisch angepasste Struktur für die Benutzerverwaltung.

Die Brücke:
Der eDirectory-Connector

Bis vor Kurzem gab es ein großes Problem: Eine direkte Verbindung zwischen dem KIDM und der paed.ML Novell fehlte. Identitäten ließen sich zwar über verschiedene Umwege ins eDirectory bringen, aber nur mit aufwändiger und unzuverlässiger Handarbeit. Kurz gesagt: Eine wirklich funktionierende Schnittstelle hat gefehlt.

Mit dem eDirectory-Connector haben wir diese Lücke geschlossen. Jetzt stehen die Identitäten aus dem Landes-IDM auch in der paed.ML bereit – sicher, vollständig und ohne manuelles Nacharbeiten.

Das Ganze läuft in mehreren Schritten ab:

• weBBschule verwaltet die Identitäten der Schüler*innen und Lehrkräfte. Änderungen an den Identitäten – etwa neue Klassen, ein Schulwechsel oder geänderte Namen – werden von dort an das Landes-IDM übergeben.
• Diese Daten landen im Landes-IDM, das auf UCS@school basiert. Von hier geht es per Kelvin REST API weiter in das IDM der DIKOM, ebenfalls ein UCS@school-System. Wichtig: Dort wird nichts manuell geändert – alle Daten kommen aus den vorgelagerten Systemen.
• Jetzt kommt der neue Connector ins Spiel. Er sorgt dafür, dass die Daten ins eDirectory der paed.ML übertragen werden. Und zwar genau dahin, wo sie hingehören – in die schulspezifischen Strukturen. Dazu nutzt der eDirectory-Connector EduSync, eine von der Firma BERGT-Consulting neu entwickelte REST-Schnittstelle für eDirectory.

Die Herausforderung:
Eine knifflige Ingenieursaufgabe

Unsere erste Idee war, die Verbindung mit Hilfe der App AD Connector von Univention zu errichten. Die App führt ein bestehendes Active Directory (AD) mit einer von UCS@school verwalteten Domäne zusammen. Da eDirectory sich so verhalten kann, dass es wie ein AD aussieht, und ähnliche Schnittstellen und Protokolle bereitstellt, lag dieser Ansatz nahe. Allerdings hatte die Sache einen Haken: Besonders komplexe Szenarien, wie z. B. die Synchronisation von Passwörtern, funktionieren oft nicht zuverlässig, weil eDirectory eben keinen vollständigen Domain Controller implementiert – wie es bei einem echten AD der Fall ist. „Dazu kam, dass wir zusätzliche Mechanismen entwickeln mussten, um die unterschiedliche Baumstruktur in UCS@school und eDirectory Rechnung zu berücksichtigen.

Nach einiger Abwägung haben wir gemeinsam mit dem Kunden und Univention den Entschluss gefasst, für dieses Problem einen eigenen Connector zu bauen. Dieser prüft, ob es Änderungen im UCS-Verzeichnisdienst gibt und welche Schulen betroffen sind; danach überträgt er genau diese Daten ins eDirectory. Auf eDirectory-Seite sorgt die speziell entwickelte EduSync REST-Schnittstelle dafür, dass die Daten sauber eingespielt werden. Zunächst haben unsere Entwickler genau definiert, welche Daten der eDirectory-Connector übertragen soll – und musste dabei einige Stolpersteine aus dem Weg räumen.

Umgang mit Namensräumen

Ein zentraler Aspekt bei der Synchronisation zwischen dem Landes-IDM, der DIKOM und der paed.ML Novell ist der Umgang mit Namensräumen. Jede Identität muss eindeutig definiert und korrekt verarbeitet werden, sonst drohen Fehler bei der Übertragung. Das eDirectory stellt klare Anforderungen an Benutzernamen: Diese dürfen keine Punkte enthalten. Das UCS@school Landes-IDM verwendet aber eine Kombination aus Vor- und Nachnamen, häufig ergänzt durch einen Punkt, z. B. „a.mustermann“.

Das bedeutet: Es reicht nicht aus, dass ein vor- oder nachgelagertes System „flexibler“ mit Namenskonventionen umgehen kann. Die Einhaltung der Konvention muss über alle Systeme hinweg gewährleistet sein, da sonst Konflikte entstehen, die den gesamten Synchronisationsprozess stören könnten.

Die eindeutige Zuordnung von Identitäten erfolgt daher über die Record UID. Diese wird zentral vergeben und kommt aus ZENSOS bzw. weBBschule. Das eDirectory nutzt diese Record UID, um sicherzustellen, dass eine Identität korrekt zugeordnet wird. Wenn der Connector dem eDirectory beispielsweise die Anweisung gibt, eine Identität mit einer bestimmten Record UID zu erstellen, prüft das eDirectory zuerst, ob diese UID bereits vorhanden ist. Falls ja, wird die bestehende Identität genutzt und aktualisiert, anstatt eine neue anzulegen.

Die Sache mit der „Parkschule“

Es kann sein, dass eine Lehrkraft kurzzeitig keiner Schule zugeordnet ist. Das passiert zum Beispiel, wenn der Arbeitsvertrag zu den Sommerferien endet oder der Wechsel zu einer anderen Schule ansteht. Solche Identitäten verschwinden vorübergehend aus dem kommunalen IDM der DIKOM – ein Verhalten, das durch die Kelvin REST API des UCS-Mechanismus gesteuert wird. Doch was passiert mit den Daten dieser Identitäten in der paed.ML? Löschen wir sie sofort? Oder bewahren wir sie irgendwie auf? Der eDirectory-Connector muss diese Logik berücksichtigen, um Datenverluste zu vermeiden.

Hier kommt das Konzept der „Parkschule“ ins Spiel: Wenn das UCS-System eine Identität als „zu löschen“ markiert, wird das Benutzerobjekt nicht sofort entfernt. Stattdessen werden solche Identitäten in einer speziellen Organisationseinheit (OU) namens „Parkschule“ geparkt. Der Connector erkennt den Parkvorgang und übergibt die DELETE-Anweisung an das eDirectory, wo die Identität in einen entsprechenden Parkbereich geschoben wird. Wird die Identität später wieder angelegt, prüft das eDirectory, ob sie in der „Parkschule“ existiert. Wenn ja, wird sie direkt von dort in die richtige Schule zurückgeführt – mitsamt ihrer Freigaben, Ordner und anderen zugehörigen Daten.

Fundament und Feinarbeit: Die Technik hinter dem Connector

Hinter dem eDirectory-Connector steckt eine clevere technische Architektur, die perfekt auf die Anforderungen der Synchronisation zwischen UCS@school und eDirectory abgestimmt ist. Auf UCS-Seite gliedert sich der Connector in drei Hauptbestandteile:

• Listener-Modul (edirectory_connector_listener): Dieses Modul klinkt sich in den Univention Directory Listener ein und lauscht auf Änderungen im LDAP-Verzeichnisdienst. Relevante Ereignisse – wie neue oder geänderte Benutzerobjekte – werden gefiltert und als JSON-Dateien im Dateisystem abgelegt.
• Systemdienst (edirectory-connector.service): Der zentrale Dienst liest die JSON-Dateien des Listener-Moduls, verarbeitet die Änderungen und kommuniziert über die UDM-REST-Schnittstelle mit UCS@school sowie über die REST-API mit EduSync. Dabei sorgt er für die Synchronisation zwischen UCS@school und eDirectory.
• Kommandozeilentool (edirectory-connector-cli): Dieses Werkzeug interagiert über einen Unix-Socket mit dem Systemdienst und bietet zusätzliche Steuerungsmöglichkeiten. So können Administrierende unter anderem manuelle Synchronisationen starten, z. B. so:
  edirectory-connector-cli sync-school-teachers-to-edirectory

Der Connector arbeitet ereignisgesteuert: Sobald sich in einem der beiden Verzeichnisdienste etwas ändert, erfasst er diese Änderung und gibt sie an die Gegenstelle weiter. Eine zentrale Rolle spielt dabei das Attribut ucsschoolRecordUID – eine eindeutige ID, die sicherstellt, dass Objekte über alle Systeme hinweg korrekt zugeordnet werden können.

Um Schulen gezielt zur Synchronisation freizugeben, gibt es eine LDAP-Schema-Erweiterung mit einem speziellen UDM-Attribut. Dieses Attribut zeigt auf LDAP-Ebene an, welche Schulen als paed.ML-Schulen synchronisiert werden sollen. So bleibt das System flexibel und anpassbar.

Abgleich mit Strategie: Der Bauplan für die Datenintegration

Eine der größten technischen Herausforderungen bei der Synchronisation zwischen UCS@school und eDirectory ist die grundlegend unterschiedliche Struktur beider Systeme: UCS@school legt Benutzerobjekte direkt auf der Ebene der Schul-OU an. Klassen und Gruppen existieren als separate Objekte, die lediglich Verweise auf die Benutzer enthalten. Dadurch ist es möglich, dass ein Benutzer keinem Klassenverband angehört oder gleichzeitig Mitglied in mehreren Klassen ist.

paed.ML Novell hingegen organisiert Schüler*innen direkt unterhalb der Klassen. Diese Klassen sind wiederum unterhalb der Schule angesiedelt. Jede Schüler*innen-Identität muss also zwingend einer Klasse angehören. Lehrkräfte haben hingegen keine spezifische Klassenzugehörigkeit, sondern werden in einem separaten Container unterhalb der Schule verwaltet.

Um diese strukturellen Unterschiede zu überbrücken, muss der eDirectory-Connector mehrere Regeln implementieren:

• Schüler*innen, die nicht Teil eines Klassenverbandes sind, werden nicht ins eDirectory synchronisiert.
• Schüler*innen werden nur zur ersten Klasse der primären Schule synchronisiert, weitere Klassen- /Schulzugehörigkeiten werden ignoriert.
• Lehrkräfte werden auch synchronisiert, wenn sie keiner Klasse zugeordnet sind. Klassenzugehörigkeiten von Lehrkräften werden generell nicht berücksichtigt.

Ein weiterer Unterschied zeigt sich in der Namensgebung von Klassen: Auf UCS@school-Seite setzt sich der CN (Canonical Name) einer Klasse aus dem Namen der Schul-OU und einer sechsstelligen Nummer zusammen. Für die Synchronisation ins eDirectory wird jedoch das description-Attribut der Klasse verwendet. Hieraus ergeben sich folgende Einschränkungen:

• Gibt es zwei Klassen mit derselben Beschreibung, werden die Mitglieder dieser Klassen im eDirectory in eine einzige Klasse synchronisiert.
• Klassen ohne Beschreibung werden nicht ins eDirectory übertragen, da das Attribut optional ist.
• Leere Klassen – also Klassen ohne Mitglieder – werden ebenfalls nicht synchronisiert.

Eine Brücke, die hält.

Der eDirectory-Connector verbindet das Landes-IDM (LIDM) über das kommunale IDM (KIDM) mit paed.ML Novell und bringt Identitäten sicher ans Ziel. Mit klarer Architektur und durchdachter Technik überwindet er die strukturellen Unterschiede zwischen den Systemen und sorgt für einen stabilen Datenfluss – von der ersten Änderung in weBBschule, ZENSOS und Co. bis ins eDirectory.

Namensräume, temporäre Zuordnungen und spezielle Anforderungen wie die „Parkschule“ meistert der Connector mit präzisen Regeln. Datenverluste? Fehlanzeige. Freigaben und Dateien bleiben erhalten, selbst wenn Identitäten vorübergehend verschoben werden. Das Ergebnis: Schulen in Brandenburg können künftig nahtlos mit allen digitalen Lösungen arbeiten, die ihre Verwaltung einfacher und sicherer machen.