Administrative Accounts und normale Benutzerkonten im selben System zu betreiben, ist in vielen Umgebungen üblich – eine Trennung kann die Sicherheit jedoch deutlich verbessern. Mit Delegativer Administration und Just-in-Time-Authentication trennt UCS Rollen und Identitäten sauber und nachvollziehbar. Weniger ACL-Komplexität, mehr Struktur: Zwei neue UCS-Features denken die Administration neu.
In vielen Umgebungen ist das Alltag: Domain-Administrator*innen sind gleichzeitig ganz normale Benutzer*innen. Genau wie alle anderen lesen sie E-Mails, melden sich an Fachanwendungen oder freigeschalteten Diensten an – und verwalten nebenbei die komplette Infrastruktur mit umfassenden Rechten im Verzeichnisdienst.
Praktisch? Ja. Unproblematisch? Eher nicht. Wird ein solcher Account kompromittiert, betrifft das nicht „nur einen Nutzer“, sondern potenziell das gesamte System. Der BSI IT-Grundschutz fordert deshalb eine klare Trennung von administrativen und fachlichen Accounts. In der Theorie klingt das selbstverständlich. In der Praxis stellt sich schnell die Frage: Wie setzt man das sauber um?
Das im Dezember 2025 erschienene UCS 5.2-4 führt dafür zwei neue Funktionen für Nubus ein: die Delegative Administration und die Just-in-Time-Authentication. Beide Features befinden sich aktuell im Preview-Status; dieser Artikel gibt einen Überblick.
Inhaltsverzeichnis
Delegative Administration in UCS: Rollen statt komplexer LDAP-ACLs
Wer administrative Rechte im Verzeichnisdienst nicht nur global, sondern strukturiert und nachvollziehbar delegieren möchte, landet früher oder später bei LDAP Access Control Lists (ACLs). Technisch gesehen funktionieren diese gut. Man kann sehr genau definieren, wer welche Objekte sehen, ändern oder löschen darf. Eine neue Abteilung wird dann zu einer eigenen Organizational Unit (OU), ein Helpdesk-Team kann anschließend Passwörter zurücksetzen, oder ein externer Dienstleister erhält temporären Zugriff auf einen bestimmten Bereich.
All das lässt sich mit ACLs abbilden, aber selten elegant. Mit jeder zusätzlichen Ausnahme wächst die Komplexität. Wer später nachvollziehen möchte, warum ein bestimmter Zugriff erlaubt oder verweigert wird, muss sich durch verschachtelte Konfigurationslogik arbeiten. Delegation wird möglich – aber nicht unbedingt transparent.
Die Delegative Administration von Nubus ist ein neues Konzept für die Autorisierung im Verzeichnisdienst über den Univention Directory Manager (UDM). Das Ziel: Administrator*innen sollen genau definieren können, wer unter welchen Bedingungen was im Verzeichnisdienst ändern darf. Die Dokumentation weist ausdrücklich darauf hin, dass es sich um ein Feature im frühen Entwicklungsstadium handelt, das noch nicht für den produktiven Einsatz vorgesehen ist. Konfiguration und Setup können sich in kommenden Versionen noch ändern.
Zu den Einschränkungen der Preview gehört: Delegative Administration entscheidet noch nicht darüber, welche Module in der UMC sichtbar sind. Diese Steuerung erfolgt weiterhin über die bestehenden Autorisierungs-Mechanismen, über UCS-Policies. Delegative Administration greift eine Ebene tiefer: Auf UDM-Ebene wird geprüft, ob eine konkrete Aktion im Verzeichnisdienst erlaubt ist.
Rollenbasierte Autorisierung im Univention Directory Manager (UDM)
Statt Berechtigungen indirekt über ACLs abzuleiten, werden explizit Rollen definiert. Eine Rolle beschreibt konkret,
- welche Objekttypen sie betrifft (z. B. Benutzer oder Gruppen),
- für welchen Bereich im Verzeichnis sie gilt (etwa eine bestimmte OU),
- welche Aktionen erlaubt sind (lesen, ändern, löschen, anlegen)
- und welche Attribute bearbeitet werden dürfen.
Diese Rollen werden Benutzer- oder Gruppenobjekten zugewiesen. Gruppenmitglieder erben die entsprechenden Rollen automatisch. Die Autorisierungsprüfung erfolgt in der UDM-Bibliothek – LDAP-ACLs bleiben unangetastet.
Ein einfaches Beispiel zeigt, wie klar das Konzept ist:
access by role="myRole"
to objecttype="users/user" position.subtree="cn=users,{ldap/base}"
grant actions="search,read"
grant properties="*" permission="read"
Hier wird definiert, dass die Rolle myRole ausschließlich lesenden Zugriff auf Benutzerobjekte vom Typ users/user innerhalb eines bestimmten Teilbaums unterhalb von cn=users erhält. Statt impliziter Regelketten entsteht eine explizite, nachvollziehbare Rollendefinition. Innerhalb dieser Bedingungen kann festgelegt werden, welche Aktionen erlaubt sind, beispielsweise search und read; alternativ könnte man auch create oder delete definieren. Zusätzlich kann der Zugriff auf Attribute geregelt werden – im Beispiel dürfen alle Attribute gelesen, aber nicht geschrieben werden.
Delegation in der Praxis: Administration einer Organisationseinheit (OU)
In der Praxis wird das besonders anschaulich: Ein Benutzer namens ou1-admin erhält eine Rolle, die ihm administrativen Zugriff ausschließlich auf die Organisationseinheit OU1 gewährt. Nach der Anmeldung sieht er im LDAP-Baum nur diesen Bereich. Auch im Benutzermodul erscheinen ausschließlich Konten unterhalb dieser Organisationseinheit. Dort liegende Attribute wie etwa die Beschreibung darf ou1-admin ändern – versucht er jedoch, Rollen zu vergeben oder außerhalb seines Bereichs zu arbeiten, erhält er eine klare „Permission denied“-Meldung.
Wird diesem Benutzer eine weitere Admin-Rolle, etwa für OU2, zugewiesen, erweitert sich sein administrativer Bereich dynamisch. Nach erneuter Anmeldung erscheinen beide Organisationseinheiten im Verzeichnisbaum. Rechte werden also nicht implizit „irgendwie“ erweitert, sondern nachvollziehbar über zusätzliche Rollen.
Damit entsteht eine rollenbasierte Steuerung administrativer Rechte, die delegierbar, transparent konfigurierbar und deutlich besser nachvollziehbar ist als komplexe ACL-Strukturen. Delegative Administration ersetzt LDAP-ACLs nicht, sondern ergänzt sie aber um eine klar strukturierte Autorisierungs-Ebene im Univention Directory Manager.
Rollen sauber zu definieren ist jedoch nur der erste Schritt. Denn selbst ein perfekt konfigurierter OU-Administrator bleibt problematisch, wenn sein Account im selben Verzeichnis liegt wie alle anderen Benutzerkonten. Genau hier setzt die Just-in-Time-Authentication an.
Just-in-Time-Authentication in Nubus: Administrative Accounts sauber trennen
Das zweite neue Feature, die Just-in-Time-Authentication, ist eine Art Add-on zur Delegativen Administration; sie entfaltet ihren Nutzen erst in Kombination mit den zuvor definierten Rollen. Das Ziel ist, administrative Accounts und gemanagte Accounts (Benutzerkonten) in unterschiedlichen Systemen zu betreiben. So entsteht eine klare Trennung:
- In einem Verzeichnisdienst liegen die zu verwaltenden Accounts.
- In einem zweiten Verzeichnisdienst (z. B. Nubus oder Active Directory) liegen die administrativen Accounts.
Diese Accounts aus dem zweiten Verzeichnisdienst sollen administrativen Zugriff auf den ersten Verzeichnisdienst enthalten. Das entspricht nicht nur sicherheitstechnischen Best Practices, sondern auch den bereits erwähnten Anforderungen aus dem BSI IT-Grundschutz: Administrative Identitäten sollen getrennt geführt und besonders abgesichert werden.
Wie Just-in-Time-Authentication technisch funktioniert
Die technische Grundlage ist OpenID Connect (OIDC): Die Anmeldung an der Univention Management Console (UMC) erfolgt per OIDC über den Nubus-Identity-Provider Keycloak. Für die Just-in-Time-Authentication wird eine Föderation zwischen Keycloak und dem Identity Provider der externen Management Domain eingerichtet:
- Die Anmeldung an der UMC führt zunächst zu Keycloak.
- Keycloak leitet die Anmeldung an den Identity Provider der Management Domain weiter.
- Der Benutzer authentifiziert sich dort – also gegenüber dem externen Verzeichnis.
- Der externe Identity Provider liefert ein OIDC-Token zurück. Dieses enthält unter anderem:
- nubus_id: eine eindeutige Kennung der Management Domain
- nubus_roles_from_groups: die Rollen für die Autorisierung des Accounts
- Nubus Keycloak reicht diese Informationen an die UMC weiter.
Die UMC erkennt, dass der Account nicht im lokalen LDAP existiert. Und genau hier passiert das Entscheidende: Es wird kein lokaler Admin-Account angelegt, es wird nichts repliziert, und es wird auch kein Shadow-Account erzeugt. Stattdessen werden die im Token enthaltenen Rollen (nubus_roles_from_groups) nur für diese Session übernommen.
Sie können sich das wie eine Art Besucherausweis vorstellen: Die Identität bleibt im externen System. Für die Dauer der Sitzung werden temporär genau die Berechtigungen aktiviert, die im Token definiert sind. Nach dem Logout existieren diese Berechtigungen nicht mehr.
Übrigens: Wird der administrative Account im externen System gesperrt, endet damit automatisch auch der Zugriff auf die UMC. Da keine lokale Kopie im Nubus-Verzeichnisdienst existiert, wirkt der Sperrstatus unmittelbar über den Authentifizierungsprozess. Eine zusätzliche Status-Synchronisierung ist nicht erforderlich.
Delegative Administration und Just-in-Time-Authentication als gemeinsames Konzept
Erst in Kombination der beiden neuen Funktionen entsteht ein konsistentes Sicherheitsmodell:
- Delegative Administration regelt, was ein Account im Verzeichnis tun darf.
- Just-in-Time-Authentication regelt, woher dieser Account kommt.
Werden lediglich Rollen definiert, während sich administrative Accounts im selben Verzeichnisdienst befinden wie die verwalteten Benutzerkonten, bleibt ein strukturelles Risiko bestehen. Der Admin-Account existiert dauerhaft im System, ist technisch Teil desselben Verzeichnisdienstes und muss dort besonders abgesichert werden. Die Trennung zwischen fachlicher und administrativer Identität ist dann organisatorisch gewollt, aber nicht architektonisch umgesetzt.
Mit Just-in-Time-Authentication ändert sich das grundlegend. Administrative Identitäten verbleiben in einer eigenen Management Domain – etwa in einem Active Directory oder in einem separaten Nubus-System. Im Zielsystem existieren sie nicht als lokale Objekte. Sie werden nicht repliziert, nicht synchronisiert und nicht dauerhaft angelegt. Erst bei der Anmeldung über OpenID Connect werden die erforderlichen Rollen temporär übernommen.
Zusammen ermöglichen beide Funktionen eine nachvollziehbare, delegierbare und architektonisch saubere Umsetzung administrativer Zugriffe – ohne zusätzliche LDAP-ACL-Komplexität und ohne parallele Accountverwaltung.
Beide Funktionen befinden sich aktuell noch im Preview-Status und stehen mit Nubus für UCS bereits zur Verfügung. Wenn Sie einen produktiven Einsatz planen, sprechen Sie uns gerne an.
