Bei Schwäbisch Hall denken die meisten Leute wohl an die gleichnamige Bausparkasse oder an eine malerische Altstadt (welche übrigens wirklich einen Besuch wert ist). Letztere zu erhalten, ist nur eine der zahlreichen Aufgaben der Stadtverwaltung. Und auch in dieser gehen die Zeiten von Bleistift und Papierakte langsam vorbei. Eine moderne IT sorgt dafür, dass die über 900 Mitarbeitenden zu jeder Zeit und an jedem Ort auf ihre Mails, Termine, Kontakte und Dateien zugreifen können.

Das Rathaus von Schwäbisch Hall (Foto Credits: Niko Kurth)


Die Sache mit der Vergangenheit

Für alle Mitarbeitenden und für alle eingesetzten Systeme müssen Identitäten und Zugriffsrechte verwaltet werden. Das dafür eingesetzte System hat lange Zeit sehr gut funktioniert. Leider wurde dieses System extern betreut und der hausinterne Wissenstransfer in diesem Bereich war nicht vorhanden, womit eigenes Knowhow zur Pflege und Weiterentwicklung des Systems in der IT nicht aufgebaut werden konnte. Nun nützt Open Source (und besagtes System fällt durchaus in diese Kategorie) wenig, wenn niemand den Source-Code pflegen kann oder will. Die personellen Ressourcen in der IT, noch dazu im öffentlichen Dienst in einer eher kleineren Kommune, sind arg beschränkt. Erschwerend kam hinzu, dass mittlerweile diverse weitere Programme hinzugekommen sind, die aus den genannten Gründen vom alten System überhaupt nicht verwaltet wurden.

Die Suche

Identity-Management ist nicht schwer, entsprechende Systeme gibt es zuhauf. So dachten wir und machten uns auf die Suche. Schwäbisch Hall ist eine Open-Source-Kommune, der Wunsch nach einem ebenso offenen IDM lag nahe. Zur Bedingung für die Suche wollten wir es nicht machen, der Wettkampf sollte allen eine Chance bieten. Einzig die no-spy-Klausel des BMI sollte erfüllt sein. Es war schon etwas überraschend zu sehen, dass Univention der einzige Anbieter war, der überhaupt positiv auf die Anfrage antwortete. Genau genommen überraschte mich persönlich der Fakt, dass offenbar alle anderen Hersteller von IDM-Systemen Schwierigkeiten mit eben dieser no-spy-Klausel haben. Und noch mehr überrascht es mich, dass es offenkundig genug Kunden gibt, die solche Systeme dann auch noch einsetzen.

Auf jeden Fall vereinfachte die Sachlage die Auswahl maximal. Wenn auch, so muss man rückblickend zugeben, im ersten Moment nicht ganz ohne Bauchschmerzen: damals hätten wir doch gerne etwas mehr Auswahl gehabt. Allerdings wussten wir da auch noch nicht, wie die Migration dann verlaufen würde. Nun war also klar, dass die Reise Richtung Univention Corporate Server von Univention gehen wird. Dieser ist Open Source, andererseits bringt er als Kernkomponente ein starkes Identitätsmanagement mit, an das sich über das eigene App Center oder Schnittstellen Dienste recht einfach integrieren und zentral administrieren und über ein Portal bereitstellen lassen.

Die Anforderungen

Uns war es wichtig, dass auch weiterhin Informationen zu Benutzern wie z. B. Gruppenmitgliedschaften, Passwortänderungen, Benutzerdetails etc. an zentraler Stelle erfolgen. Unser bisheriges selbst entwickeltes Verwaltungssystem replizierte bereits alle Änderungen in die jeweiligen angebundenen Dienste. Unser Ziel war es nun, unser System zukunftsfähig zu machen und die Verwaltung der Benutzer mit einem standardisierten Verfahren in einem von einem Hersteller kontinuierlich gepflegten und supporteten Produkt zu organisieren.


Die Vorbereitungen

Die Migration begann genau genommen schon lange vor der Migration: nach Vertragsabschluss gab es die ersten Gespräche mit den Technikern von Univention. Wir hatten einen direkten Ansprechpartner, der sich als ungemein kompetent entpuppte und so schnell einen guten Draht zu unseren Systemadministratoren aufbauen konnte. Schnell erkannten alle Beteiligten, dass die technische Basis unseres System gar nicht so weit von der von UCS entfernt war. Basierend auf der Erkenntnis konnte recht zügig ein Plan für die Migration erstellt werden.

Der in UCS verwendete Notifier-Listener-Mechanismus würde von nun an die Replikationen der Benutzerdaten in die einzelnen Dienste übernehmen. Im Gegensatz zu bisher sollten die zentralen Dienste wie LDAP, DNS, DHCP, aber auch die Samba basierten Active Directory Windows-Dienste redundant ausgestaltet werden, um Ausfallsicherheit zu gewährleisten. Das bot sich an, da das UCS-Domänenkonzept, das auf einem Multiserveransatz basiert, von vorneherein die technische Basis für verteilte Dienste und redundante Dienste mitbringt.

Einer der Dienste, den wir weiterhin nutzen wollten, war die OX App Suite. Sie lief bisher auf einem Dovecot Server und sollte auf UCS umgezogen werden, auch weil die Notifier-/Listener- basierte Benutzerverwaltung, z. B. das Umbenennen oder Löschen von Mailboxen, damit funktioniert. Die vorhandene OX App Suite sollte von nun an über den UCS OX Connector provisioniert werden. Dieser ermöglicht es, auch eine nicht auf einem UCS-System laufende OX App Suite zu nutzen und Benutzer und Gruppen zwischen beiden Diensten zu synchronisieren.

Eine direkte Migration aller Funktionen wäre doch sehr komplex geworden. Daher haben wir uns gemeinsam mit Univention dafür entschieden, die Informationen über Nutzer, Gruppen und Computer aus dem existierenden Samba AD in UCS zu übernehmen und dafür den Active Directory Takeover von UCS zu verwenden. Der wurde eigentlich dafür gebaut, ein auf Windows basierendes System zu migrieren, war aber für unsere Anforderungen mit kleineren Anpassungen geeignet. Vorteil des Takeovers: Alle bestehenden 500 Client-Computer, in unserem Fall sind das Linux Clients, funktionieren ohne weitere Änderungen auch mit dem neuen System. Eine Voraussetzung, um die Migration in der geplanten kurzen Zeit schaffen zu können. Und ein weiterer positiver Nebeneffekt: Die Benutzer würden von der Umstellung kaum etwas mitbekommen und sich nach erfolgreichem Abschluss einfach mit ihrem bisherigen Benutzernamen und Kennwort anmelden und alle angebundenen Dienste weiter nutzen können.

Um die Migration vorab zu üben, wurde eine komplette Testinstallation erstellt, in welcher sowohl ein digitaler Zwilling unseres aktuellen Systems als auch ein UCS installiert wurde. So konnten wir gemeinsam mit Univention die Migration vorab durchspielen. Hier zeigte sich wieder einmal der inzwischen altbekannte Vorteil virtualisierter Umgebungen: nicht nur konnte schnell die Testumgebung aufgesetzt werden, dann Snapshots und Clones konnte sie auch jederzeit einfach kopiert bzw. in alte Zustände zurückgesetzt werden. Für die Jüngeren unter uns klingt das sicher alltäglich, wer sich wie ich noch an die Zeiten vor der Virtualisierung erinnert, wird meine immer noch vorhandene Begeisterung sicher gut nachvollziehen können.

Durch die diversen Tests konnten wir unseren Datenbestand bereinigen (was sich als Hauptquelle von Fehlern bei den Test-Migrationen herausstellte) und Univention bereitete entsprechende Skripte vor, um die eigentliche Migration später möglichst stark zu automatisieren. Zuvor hatten wir in dem alten Verwaltungssystem gespeicherte Daten identifiziert und beschlossen, welche Informationen noch benötigt werden und in welcher Form sie in das neue System migriert werden sollten.

Ein Beispiel dafür: In unserem alten System gab es für einen Anmeldeprozess eine 2-Faktor-Authentifzierung, bei der über eine SMS-Nachricht ein Anmeldetoken versendet wurde. Die dafür im System gespeicherten Mobilnummern sollten auch weiterhin zur Verfügung stehen und konnten über die UCS-Standardfunktion „extended Attributes“ problemlos in das neue System übertragen werden. So können wir bewährte individuelle Dienste und dafür benötigte Daten auf das neue Standardsystem übertragen.

Mit diesen Vorbereitungen und den Erfahrungen aus den Test-Migrationen konnten wir nun einen Zeitplan für die echte Migration ableiten: knapp zwei Tage würden wir brauchen. Da IT-Projekte ab einer gewissen Komplexität stets anders als geplant laufen, haben wir noch einen Puffer dazu gepackt und den Start für Freitagmittag angesetzt. Die Anwender wurden lange vorher informiert und regelmäßig erinnert – während der Migration ist keine Anmeldung am System, also praktisch kein Arbeiten, möglich.

Die Migration – Zeitspiel

Bis Samstagmittag lief alles nach Plan. Für den Abend sollte es in Schwäbisch Hall ein großes Sommerfest geben, es sah alles danach aus, dass wir dort den erfolgreichen Abschluss des Projektes feiern können. Und dann kamen die ersten Probleme: wir hatten einfach einige sehr spezielle Anwendungsfälle übersehen. Hier rächte es sich, dass unser IT-Team sehr jung (an Dienstjahren) ist, zum Zeitpunkt der Migration waren alle Beteiligten weniger als 1 Jahr bei uns. Das Problem war aber schon viel älter, daher hatte es (noch) niemand gesehen.

Als Glücksfall erwies sich, dass der Univention-Techniker, mit dem wir im Vorfeld schon alles geplant hatten, während der Migration bei uns vor Ort war. Darauf hatten wir bestanden. Vermutlich hätte alles auch remote funktioniert, aber so war es doch einfacher. Letztlich verloren wir Dank seines Fachwissens nicht einmal eine Stunde, bis wir die Lösung hatten. Kurz kam noch der Gedanke an ein Rollback auf (diese Hintertür hatten wir so lange wie möglich offen gelassen), mit der Lösung vor Augen waren wir uns aber alle einig, weiter machen zu wollen. Das war dann praktisch der legendäre Point-of-no-return: aber jetzt hätten wir nicht mehr genug Zeit für ein Rollback gehabt.

Die Umsetzung der gefundenen Lösung erwies sich dann als sehr zeitraubend: mangels Vorbereitung konnten wir hier nicht automatisieren, sondern mussten einige Anpassungen an vielen dutzend Stellen manuell nachziehen. Gegen Abend war allen Beteiligten anzumerken, dass die Konzentration nachließ. Weiterarbeiten machte so keinen Sinn, also entschieden wir (was den Leser jetzt eventuell überraschen wird) – auf das Sommerfest zu gehen. Eine gute Entscheidung, der Stress fiel merklich ab. Natürlich war der Abend nicht wirklich lang, tat aber gut und am Sonntagmorgen standen alle wieder ausgeschlafen und motiviert auf der Matte. Knapp zwei Stunden später war klar, dass wir gut durchkommen würden, gegen Mittag war alles erledigt und der Nachmittag verging in schon deutlich entspannter Stimmung mit dem Testen der erledigten und dem Aufschreiben der offenen Punkte (jeder, der ein Projekt dieser Größenordnung schon einmal durchgeführt hat, weiß, dass man nie bei 100 Prozent landet).

Klassenzimmer mit moderner Medientechnik


Ernstfall

Auch wenn wir uns sicher waren, gute Arbeit geleistet zu haben, denke ich, richtig gut hat in der Sonntagnacht niemand von uns geschlafen. Die Situation kennt jeder: wir haben alles Mögliche getestet, aber ob es wirklich funktioniert hat, wird erst der harte Alltag zeigen. Am Montag waren alle früh im Büro. Wir wollten auf jeden Fall bereit sein, auch für die Frühaufsteher unter den Mitarbeitenden. Natürlich gab es tatsächlich die eine oder andere kleine Hakelei, in Summe war es ein entspannter Montag. Dem, jedenfalls soweit es das UCS angeht, noch viele entspannte Arbeitstage bis heute folgten. Bisher hat bei uns noch niemand die Entscheidung für diese Umstellung bereut.

Auf unserem YouTube-Kanal finden Sie bei Interesse den ganzen Vortrag von Mathias Waack auf dem Univention Summit 2023.

UCS Core Edition jetzt kostenfrei einsetzen!

Zum Downloadbereich
Mathias Waack

Mathias Waack ist seit 2020 Leiter des Fachbereichs Organisation & IT der Stadt Schwäbisch Hall und verantwortet dort den nachhaltigen Aufbau des Fachbereichs sowie die Neuausrichtung der IT-Infrastruktur.

Was ist Ihre Meinung? Hinterlassen Sie einen Kommentar!

Kommentare

  1. Würde es doch noch mehr solch aufgeschlossene Mitarbeiter in den Stadtverwaltungen geben!!!

    Weiter so!

    Antworten

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert