Im Januar erschien die Version 5.2 des Univention Corporate Servers. Geändert hat sich weit mehr als die letzte Ziffer der Versionsnummer: UCS basiert nun auf Debian GNU/Linux 12, nutzt Keycloak als zentralen Identity Provider und prüft die Syntax der Einträge in seiner Config Registry.
Der Name des Bremer Unternehmens Univention [1] ist in der deutschsprachigen Open-Source-Szene weithin geläufig. Das liegt einerseits daran, dass vor allem Univention-CEO Peter Ganten unermüdlich Werbung für freie Software macht und etwa dem Bundestag und seinen Ausschüssen bereits mehrere Male Rede und Antwort zu Open-Source-Themen stand. Andererseits handelt es sich beim Univention Corporate Server [2], kurz UCS, zweifelsohne um eines der bekanntesten Open-Source-Produkte im deutschsprachigen Raum. Was nicht zuletzt daher rührt, dass UCS einige der lästigen Themen aus dem Weg räumt, die ansonsten Admins gerade in kleineren und mittelgroßen Unternehmen lange beschäftigen: Zum Beispiel Identity & Access Management, kurz IAM, für eine Vielzahl von Produkten, ergänzt um die Möglichkeit, sie auch gleich in Form von Containern aus einem App-Store (Abbildung 1) herunterzuladen und auszuführen.

Abbildung 1: Wie bisher bietet Univention ein App Center, aus dem sich zusätzliche Software installieren lässt.
Wer beispielsweise ein ordentlich konfiguriertes Samba mit Active-Directory-Anbindung benötigt, findet am Markt kaum eine zweite Option, um derart flott ans Ziel zu kommen wie mit UCS. Darüber hinaus fällt es sehr leicht, eigene Anwendungen mit UCS zu verbinden und so die IAM-Fähigkeiten der Bremer Lösung in diese zu integrieren. Andere Standarddienste lassen sich mit UCS ebenfalls einfach umsetzen, etwa Virtualisierung oder der Betrieb praktisch jeder Serverart, seien es Nameserver für DNS, Mailserver oder die private Cloud auf Grundlage von Nextcloud [3] oder Owncloud [4].
Zwar hört man manch arrivierten Admin mitunter nörgeln, wenn es um Lösungen wie UCS geht, weil jede Form von GUI und jede Form von Abstraktion am Ende mit weniger Konfigurationsmöglichkeiten einhergehen. Doch der Erfolg gibt Univention Recht, und vielerorts hat sich UCS zu einer zentralen Komponente der IT-Landschaft im Unternehmen entwickelt.
Wahr ist aber auch: UCS 5.0 in seinen diversen Versionen zog in jüngerer Vergangenheit häufig den Unmut seiner Anwender auf sich. Vor allem, weil die Bezeichnung “gut abgehangen” für das Produkt zuletzt ein schierer Euphemismus war. Dazu muss man wissen: UCS basiert auf Debian GNU/Linux [5]. Univention nutzt es als Grundlage, reichert es um unterschiedliche Komponenten an und vermarktet das Produkt letztlich als Corporate Server. Dumm nur: Die bis Januar aktuelle UCS-Version 5.0 basierte noch auf Debian GNU/Linux 10 “Buster”. Dessen Veröffentlichung datiert aus dem Jahr 2019.
Nun eilt Debian GNU/Linux nicht gerade der Ruf voraus, stets die aktuellste Software zu liefern – Spötter sprechen regelmäßig von Debian Stale (abgestandenes Debian) anstelle von Debian Stable, wie die stabile Release von Debian GNU/Linux offiziell heißt. Aber selbst das Debian-Projekt hat seit 2019 zwei neue Releases veröffentlicht, nämlich Debian GNU/Linux 11 “Bullseye” und Debian GNU/Linux 12 “Bookworm”. Und sogar dessen Erscheinen liegt schon wieder fast zwei Jahre zurück. Debian 13 “Trixie” wird – im Einklang mit dem zweijährigen Release-Zyklus des Projekts – für den Sommer 2025 erwartet. Wer den UCS 5.0 einsetzte, hing hingegen auf Debian 10 fest und kämpfte mit allen sich daraus ergebenden Nachteilen.
Und die sind durchaus vielfältig: Der in Buster enthaltene Kernel lässt sich aus heutiger Sicht als prähistorisch bezeichnen und wusste mit zahlreichen neueren Hardwarekomponenten schlicht nichts anzufangen. Zentrale Tools und Werkzeuge galten ebenfalls als hoffnungslos veraltet. Univention mühte sich zwar, das Problem zu lindern, zum Beispiel mit verschiedenen rückportierten Paketen aus aktuelleren Debian-Distribution, Kernel-Patches und diversen anderen Maßnahmen. Im Kern jedoch hatte man es trotzdem mit einem fast sechs Jahre alten System zu tun, einem lahmen Gaul, aus dem nicht einmal die besten Tricks ein Rennpferd machen konnten.
Runderneuertes System
Nun haben die Bremer in den vergangenen Jahren freilich nicht Däumchen gedreht, im Gegenteil: In jüngster Vergangenheit hat Univention vor allem mit Aktivitäten im thematischen Umfeld der digitalen Souveränität für Furore gesorgt. Ein großer Teil der IAM-Funktionen aus dem UCS sind echte Eigenentwicklungen des Herstellers. Dazu gehören unter anderem die GUI zur Benutzerverwaltung oder das Selbstbedienungsportal, mit dem UCS-Nutzer ihre Stammdaten aktualisieren oder ihr Passwort ändern. Im Rahmen des OpenDesk-Projekts des ZenDiS [6] hat Univention diese Komponenten aus dem UCS ausgekoppelt und in Form von Nubus [7] als eigenständiges Produkt mit Kubernetes-Unterstützung auf den Markt gebracht.
Zur Wahrheit gehört außerdem, dass der größte Teil eben dieser UCS-spezifischen Änderungen auch die bestehenden UCS-5-Kunden über Updates erreicht hat. Für die Pflege des UCS-Grundsystems indes blieb vor diesem Hintergrund offensichtlich nicht allzu viel Zeit übrig. Zwar gibt das Unternehmen an, Pläne für ein zwischenzeitliches Update auf Debian 11 gehabt zu haben. Die hat man 2023 allerdings verworfen, weil Debian 12 bereits am Horizont erschien und man ansonsten eine UCS-Major-Version in die Regale gebracht hätte, die schon am Veröffentlichungstag wieder veraltet gewesen wäre. Dieses Problem hat sich nun erst einmal erledigt.
Entsprechend darf als Hauptneuerung von UCS 5.2 freilich der runderneuerte Unterbau auf Basis von Debian 12 gelten. Der bringt zahlreiche Updates querbeet mit sich: Der Kernel 6.1 ist immerhin nicht mehr ganz so prähistorisch und Werkzeuge wie Samba (4.21.1), PostgreSQL (15) oder Docker (4.18) liegen in halbwegs aktuellen Versionen bereit.
Bemerkenswert: Debian GNU/Linux selbst unterstützt anders als etwa Ubuntu bei seinen LTS-Versionen bis heute keine Sprungupdates. Ein Update von Debian GNU/Linux 10 auf 12 ohne den Zwischenschritt mit der Version 11 ist damit ebenso ausgeschlossen wie ein direktes Update von UCS 5.0 auf UCS 5.2. Für diesen Zweck hat Univention zusammen mit UCS 5.2 eigens einen UCS 5.1 herausgebracht. Dessen einzige Aufgabe besteht darin, den Update-Pfad zur Version 5.2 zu ebnen. Als eigenständiges Produkt will Univention den UCS 5.1 dementsprechend nicht eingesetzt sehen. Technisch funktioniert das schon gar nicht – denn eine UCS 5.1-Installation aktualisiert sich automatisch und ohne Zutun des Administrators auf UCS 5.2.
Neuer Identitätsprovider
Die zweite große Neuerung in UCS 5.2 heißt Keycloak [8], das künftig als alleiniger Identitätsprovider eine zentrale Rolle im UCS-Universum spielt. Identity Provider (IdP) stellen üblicherweise Funktionen wie die Föderierung über mehrere Benutzerverzeichnisse hinweg sowie Single-Sign-On (SSO) zur Verfügung. UCS verfolgte hier bisher einen anderen Ansatz: SimpleSAML.php und Kopano Konnect ließen sich als IdP nutzen. In UCS 5.2 hat man sich von ihnen verabschiedet.
Betroffenen Administratoren hat der Anbieter aber immerhin eine bequeme Rutsche gebaut: Schon für UCS 5.0 gibt es Keycloak nämlich als eigene Anwendung im UCS-App-Store. In einem technischen Dokument erläutert der Hersteller, wie eine Migration von der bestehenden Lösungen hin zu Keycloak gelingt. Wer die Keycloak-Migration bereits vor dem Update auf UCS 5.2 ausführt, kann das also in kontrollierter Art und Weise tun und nimmt diesen Faktor als mögliche Ursache für Probleme beim späteren Update aus der Gleichung. Univention weist darüber hinaus darauf hin, dass Keycloak – das übrigens auch in der F/LOSS-Szene als Standardlösung für IdP gilt – einen größeren Funktionsumfang besitzt, als die vorherige Mehrkomponentenlösung. Nach der Umstellung auf Keycloak können Administratoren also auf deutlich mehr Funktionen zurückgreifen.
Das Ergebnis kann sich durchaus sehen lassen: Single-Sign-On zählt eher noch zu den leichteren Übungen, die Keycloak beherrscht. Zusätzlich lässt Keycloak sich redundant auf mehreren Systemen betreiben, sodass implizit kein Single-Point-of-Failure (SPOF) entsteht. Um 2-Faktor-Authentifizierung (2FA) müssen UCS-Administratoren sich dank Keycloak künftig ebenfalls keine Gedanken mehr machen. Was in UCS 5.0 noch einiges an händischer Konfigurationsarbeit voraussetzte, klappt in UCS 5.2 nämlich dank Keycloak-eigener Funktionalität nahtlos. Keycloak beherrscht seit Jahren ab Werk mehrere Mechanismen, um einen zweiten Faktor bei der Authentifizierung anzugeben. All diese Funktionen erbt UCS.
Föderiert
Ein zentrales Thema im heutigen IdP-Zirkus ist das Thema Föderierung. Gemeint ist damit, dass Admins mehrere IdP zusammmenschalten, um allen Clients den Login für sämtliche Dienste aller verbundener Systeme zu ermöglichen. Dabei werden im Regelfall im Hintergrund nicht die Zugangsdaten der Benutzer selbst ausgetauscht. Stattdessen erkennt Instanz A die Instanz B als Autorität an und akzeptiert mit einer gültigen Signatur der jeweils anderen Instanz versehene Zugangsschlüssel (Token). Vorteilhafterweise bringt Keycloak eine Funktion für Föderierung mit. Dementsprechend lässt sich jeder Dienst föderieren, der sich an Keycloak ankoppeln lässt. Das kann andere interne Keycloak-Instanzen ebenso umfassen wie externe Dienste, die über eine mit Keycloak kompatible Schnittstelle verfügen.
Einige weitere Funktionen verleihen Keycloak aus Sicht eines UCS-Admins ausgesprochene Attraktivität. Beispielsweise erlaubt es, die integrierte 2FA-Funktion mit Kerberos [9] zu koppeln. Damit bietet sich für UCS-Admins die Möglichkeit, in Umgebungen, in denen Samba als Domänen-Controller zum Einsatz kommt, 2FA-Authentifizierung zu verwenden. So lassen sich die Laptops von Kolleginnen und Kollegen zusätzlich gegen unbefugten Zugriff beim Login absichern.
Besonders praktisch für jene Unternehmen, die Wert auf Corporate ID und Corporate Branding legen: Keycloaks Aussehen lässt sich mittels Themes anpassen. Im Kern nimmt Keycloak dann für Dienste im internen Netz oder Internet dieselbe Funktion wahr, die auch die Login-Fenster von Diensten wie Google oder Microsoft haben. Durch ein entsprechendes Theme lässt sich das Fenster von Keycloak optisch jedoch perfekt anpassen.
Schließlich spielt bei UCS das schon erwähnte Thema Selbstbedienung seit langem eine große Rolle. Bis heute sind in den IT-Abteilungen oft mehrere Mitarbeitende damit beschäftigt, einfache Nutzeranfragen wie jene zum Zurücksetzen des Passworts abzuarbeiten. Das bindet Zeit und Personal, das andernorts sinnvoller eingesetzt wäre. Univention hatte schon in UCS 5.0 verschiedene GUIs und Schnittstellen in seinem Portal integriert, die es Anwendern gestatten, diese Schritte selbst auszuführen. In UCS 5.2 sind sie an Keycloak angepasst und versprechen noch mehr Funktionen.
Alte Zöpfe
Darüber hinaus informiert der Hersteller darüber, dass er im Rahmen des Updates auf UCS 5.2 viele alte Zöpfe endgültig abschneidet. So war es etwa mit der Version 5.0 möglich, gemischte Setups zu betreiben, in denen gleichzeitig der ältere UCS 4 lief. Er basierte in seiner letzten Version 4.3 auf Debian GNU/Linux 9 und ist mithin schon länger ein Fall für das Museum. Folglich sieht UCS 5.2 einen Mischbetrieb mit dieser antiquierten Version nicht mehr vor. Die Kombination aus UCS 5.0 und 5.2 für verschiedene Cluster-Dienste bleibt vorerst aber möglich, was sich insbesondere im Rahmen von Updates als nützlich erweisen dürfte.
Vorsicht ist zudem für jene Administratoren geboten, die Python-Skripte für Python 2.7 nutzen. In der Open-Source-Welt hat Python 2.7 mittlerweile so etwas wie den Rang eines Running Gags erreicht: Selbst große Distributionen wie RHEL oder Ubuntu haben wegen der schieren Menge an Python-Lösungen, die mit Python 3 nicht funktionierten, eine kleine Ewigkeit gebraucht, bis sie die hoffnungslos veraltete Version der Skriptsprache endlich loswurden. Noch immer taucht Python-2.7-Software gelegentlich wie eine Art Zombie auf.
Gut möglich, dass solche tickenden Zeitbomben auf dem einen oder anderen UCS-5.0-System vergraben sind. Denn dem dortigen Grundsystem lag Python 2.7 seitens des Herstellers noch bei. UCS 5.2 setzt dem jetzt ein Ende – schon weil sogar Debian sich der Altlast mittlerweile erfolgreich entledigt hat. Wer seinen UCS um eigene Software erweitert hat, muss also damit rechnen, dass sie ein Update auf UCS 5.2 nicht überlebt, sofern sie auf Python 2.7 setzt. Wer seinen UCS dahingehend modifiziert hat, sollte das vor einem Upgrade gründlich überprüfen – auch wenn Python 2.7 schon in Debian 10 und mithin in UCS 5.0 als “deprecated”, also veraltet, gekennzeichnet war und zwischenzeitlich genug Gelegenheit zum Ausräumen technischer Schuld gewesen wäre.
Registry mit Syntax-Check
Wer einen UCS schon einmal in den Fingern hatte, wird dabei zwangsläufig die Univention Config Registry bemerkt haben, kurz UCR. Vorrangig Administratoren mit Windows-Erfahrung werden beim Gedanken an eine zentrale Registry, die Konfigurationseinträge enthält, aus leidvoller Erfahrung die Augen verdrehen. Doch in UCS gibt es für die Komponente durchaus eine Daseinsberechtigung: Sie fungiert als eine Art Konsensalgorithmus hinter den Kulissen und erlaubt es so, zentrale Konfigurationseinstellungen über alle Systeme einer UCS-Installation hinweg synchron zu halten.
Bisher hatte die UCR allerdings den Nachteil, dass sie keinerlei Syntaxcheck für hinterlegte Werte bot. Wer also “Ratzupaltuff” dort eintrug, wo ein sinnvoller Wert hätte stehen sollen, erhielt anstelle einer Fehlermeldung von der UCR später eine Fehlermeldung vom fehlkonfigurierten Dienst.
Dieses Problems hat sich Univention in UCS 5.2 angenommen: Neuerdings verfügt UCR über eine umfassende Überprüfung der eingegebenen Werte für die UCR, die sowohl die Syntax als auch den Inhalt einer Kontrolle unterzieht. Gibt der Administrator einen ungültigen Wert ein, beschwert sich UCR künftig, statt ihn kommentarlos zu übernehmen und damit eine Fehlermeldung später beim betroffenen Dienst auszulösen.
Das Update meistern
Bei einer solch mächtigen Lösung wie UCS liegt aus Sicht des Administrators bei Erscheinen einer neuen Version freilich die Frage nach der Komplexität des Updates nahe. Aus guten Gründen: Die Aktualisierung eines Systems ist immer ein heikler Moment. Potenziell kann dabei viel schiefgehen. Und wer noch aus eigener Erfahrung Erinnerungen an die frühen Jahre von Corporate Linux hat, weiß: Bei Updates von einer Major-Version auf eine andere laufen gern einige Dinge aus dem Ruder.
Univention behandelt das Update jedoch vorbildlich und bereitet den Administrator so gut wie möglich vor. Dazu teilt der Hersteller das Update gedanklich in mehrere Schritte auf. Interessant ist hier vor allem, wie verwoben eine bestehende UCS-Installation im Hinblick auf das Thema IAM ist. Ein zentrales Verkaufsargument von UCS lautet immerhin, dass sich mit dem Produkt eine Hierarchie von Verzeichnisdiensten betreiben lässt, wobei es stets eine primäre Instanz gibt und beliebig viele Instanzen, die für Abfragen zur Verfügung stehen, aber ihre Updates von der primären Instanz erhalten.
Wer “nur” einen UCS mit lokalem LDAP betreibt, braucht zumindest im Hinblick auf diesen Aspekt nur wenig beachten. Hier ist es im Vorfeld lediglich notwendig, Keycloak per App-Center auszurollen und die bestehende Funktionalität wie zuvor beschrieben zu ersetzen.
Unterhält man verschachtelte LDAP-Server, gestaltet sich das Update in Summe etwas komplizierter. Univention schreibt in den Release Notes zu UCS 5.2 explizit, dass sich im LDAP-Schema des genutzten OpenLDAP einige Änderungen zwischen den Versionen 5.0 und 5.2 ergeben. Installierte der Administrator das frische UCS also zunächst auf einem bestehenden sekundären LDAP-Server, wäre dessen LDAP-Schema im Anschluss inkompatibel mit jenem der primären Installation. Auch wenn es den meisten Administratoren kaum schmecken dürfte, müssen sie den primären UCS-Server in der Installation zuerst aktualisieren. Er reicht dann das aktualisierte Schema an seine sekundären Instanzen durch, sodass sie sich im Anschluss problemlos aktualisieren lassen.
Außerdem sollte man sich vor paar weiteren Fallstricken in Acht nehmen. Immerhin listet Univention sämtliche nötigen Schritte für das Update in der eigenen Dokumentation penibel auf. Zum Beispiel ändert sich bei OpenLDAP die Datenbank im Hintergrund. Wer noch das HDB-Backend verwendet, das auf Berkeley DB basiert, muss jetzt auf das MDB-Backend umsteigen, das auf Lightning Memory-Mapped Database (LMDB) aufbaut. Der Support für die Berkeley DB entfällt in UCS 5.2 in OpenLDAP vollständig, nachdem auch die Upstream-Autoren von OpenLDAP dieser Datenbankschnittstelle den Garaus gemacht haben.
Hier steht also, falls noch eine Berkeley-Installation mit OpenLDAP lokal vorhanden ist, ebenfalls eine händische Migration an, bevor das eigentliche Update stattfinden kann. Ferner weist Univention darauf hin, dass die Standardversion von Python in UCS 5.2 die Version 3.11 ist. Das Gros der für frühere Python-Versionen entwickelten Skripte funktioniert zwar auch mit Python 3.11, doch wie üblich ist bei kritischen Systemen die Vorsicht die Mutter der Porzellankiste.
Auch beim in UCS integrierten Active-Directory-Connector (AD Connector) schlagen Änderungen zu. Schon länger lassen sich mit einer UCS-Instanz mehrere AD-Distanzen verknüpfen. Das ist beispielsweise dort hilfreich, wo in einem Unternehmen in verschiedenen Teams oder verschiedenen Tochterfirmen eigene AD-Instanzen existieren, die allesamt Bestandteil einer zentralen Directory-Struktur sein sollen.
Geändert hat sich in UCS 5.2 nun aber die Mapping-Funktion, die aus Benutzern, Gruppen und Ressourcen in AD entsprechende Gegenstücke in UCS anlegt. Wer also mehrere ADs in einen UCS spiegelt, muss die Mapping-Konfiguration entsprechend adaptieren und obendrein sicherstellen, dass etwaige bei der Synchronisation zum Einsatz kommende Python-Werkzeuge reibungslos mit dem neuen Python 3.11 funktionieren.
Frischer Wind beim GUI
Weiterhin lockt Univention damit, dass man dem hauseigenen Web-Interface für die Steuerung der verschiedenen UCS-Funktionen eine optisches Auffrischung angedeihen hat lassen. Ohnehin war das einer der Kritikpunkte, die im Hinblick auf UCS 5.0 regelmäßig zu hören waren: Zwar funktioniere das Webinterface in Summe ganz gut, wirke aber altbacken und genüge den Grundsätzen moderner Benutzerschnittstellen längst nicht mehr.
Selbstverständlich unterliegt die Erscheinung von Programmen einem stetigen Wandel und richtet sich nach dem allgemeinen Geschmack. Trotzdem gibt es durchaus geschmacksunabhängige Faktoren, die über die Benutzer(un)freundlichkeit einer grafischen Oberfläche entscheiden; darüber also, ob ein UI intuitiv, ergonomisch und generell gut gebaut ist.
Der wenig zufriedenstellenden User Experience der vergangenen Versionen hilft der Anbieter jedenfalls ab sofort ab: Überarbeitet hat Univention dabei sowohl die Struktur der Menüs von UCS als auch die optische Erscheinung (Abbildung 2) der Lösung. Ein Dark Mode steht dabei ebenso zur Verfügung wie ein neues Design für Knöpfe und Buttons (Abbildung 3). Insgesamt wirkt das UCS-GUI deutlich besser strukturiert, moderner und zugleich weniger überfrachtet als zuvor. Die optischen Neuerungen beschränken sich dabei übrigens nicht nur auf den Teil, den der Admin zur Konfiguration nutzt, sondern auch auf die – ohnehin im Rahmen der Keycloak-Umstellung – neu gebauten Seiten für das Zurücksetzen der Passwörter von Nutzern und die weiteren Selbstbedienungsbereiche.

Abbildung 2: Das Univention-GUI hier in der Ansicht für Administratoren ist der zentrale Dreh- und Angelpunkt der Lösung und kommt in der Version 5.2 deutlich verbessert daher.

Abbildung 3: Sowohl die Dialoge zum Ändern von Benutzerparametern als auch jene für Selbstbedienung haben die Univention-Entwickler in der neuen Version 5.2 aufgefrischt, neu strukturiert und vereinfacht.
Die optischen Änderungen betreffen in Teilen auch die Installationsroutine von UCS selbst. Unter der Haube werkelt der Debian-Standardassistent (Abbildung 4), obgleich mit Univention-Branding. Wirklich ausspielen kann UCS seine Stärken bei der initialen Einrichtung, also gerade dann, wenn man mit UCS das erste Mal in einer Umgebung arbeitet. Hier tritt viel Liebe zum Detail zutage. Beispielsweise bietet der UCS-Assistent eine virtuelle Bildschirmtastatur, mit der sich die wichtigsten Sonderzeichen tippen lassen.

Abbildung 4: Hinter den Kulissen fußt die Installationsroutine von UCS 5.2 auf dem Debian-Installer von Debian GNU/Linux 12 alias Bookworm, wenngleich mit Univention Branding.
Wer schon mal ein System aus der Ferne per VNC etwa von einem Windows- oder Mac-System aus installieren wollte und sich über die nicht übereinstimmenden Keyboard-Layouts geärgert hat, die das Tippen eines Klammeraffen (»@«) schlechterdings unmöglich machen, lernt solche wohldurchdachten Kleinigkeiten zu schätzen (Abbildung 5). Eine leichte Trübung erfuhr die Freude lediglich dadurch, dass während der Erstinstallation ein paar Konfigurationsdialoge kurz klemmten. Beim Einrichten des Hostnamens war beispielsweise eine Eingabe in das vorhandene Feld zunächst nicht möglich. Ein Klick auf Zurück, gefolgt von einem weiteren Klick auf Weiter, führte wieder zum selben Dialog, dieses Mal aber mit funktionierender Eingabe.

Abbildung 5: Mit Liebe zum Detail hat Univention die grafische Oberfläche von UCS neu gestaltet, hier im Dark Mode. Details fallen ins Auge, etwa die eingebaute Bildschirmtastatur, falls man eine Installation remote ausführt.
Fazit
Univention Corporate Server 5.2 ist die von unzähligen UCS-Nutzern sehnlich erwartete Evolution des Produkts, doch keine Revolution. Die war in Bremen jedoch gar nicht das Ziel. Zurecht, denn das Feedback aus der Community zu UCS fiel in Summe trotz der ziemlich veralteten Software in Version 5.0 bisher stets sehr gut aus. Wer UCS verwendet, sucht einen stabilen Domänencontroller mit Zusatzfunktionen und einwandfrei laufender Nutzerverwaltung, kein blendendes Feature-Feuerwerk.
Diesem Anspruch an sich selbst bleibt UCS in der Version 5.2 durchaus treu. Begrüßenswert sind freilich das runderneuerte Grundsystem, die aufgefrischten UI-Seiten sowie die Umstellung auf Keycloak, was vorherige Bastellösungen überflüssig macht. Positiv zu erwähnen ist obendrein der valide Update-Pfad von älteren Versionen, den Univention hervorragend dokumentiert hat. Bisherigen UCS-Kunden sei das Update auf UCS 5.2 angesichts dessen nahegelegt. Wer auf der Suche nach einer gut funktionierenden, lokalen Lösung für einen Domänencontroller abseits der Hyperscaler und abseits von Microsoft Active Directory ist, der sollte UCS ebenso in Erwägung ziehen. (jcb)
Infos
- Univention: https://www.univention.de
- UCS 5.2: https://www.univention.com/blog-en/2025/02/univention-corporate-server-5-2
- Nextcloud: https://nextcloud.com
- Owncloud: https://owncloud.com
- Debian: https://www.debian.org
- ZenDiS OpenDesk: Markus Feilner, Martin Gerhard Loschwitz, “Souveräne Verwaltung statt Rockzipfel”, LM 02/2025, S. 16, https://www.lm-online.de/51373
- Univention Nubus: https://www.univention.de/produkte/nubus/
- Keycloak: https://www.keycloak.org
- Kerberos-RFC: https://datatracker.ietf.org/doc/html/rfc4120






