Running administrative accounts and regular user accounts in the same directory is common in many environments – but separating them can significantly improve security. With Delegative Administration and Just-in-Time Authentication, UCS cleanly separates roles from identities. The result: less ACL complexity, clearer structures, and a more modern approach to administration.
In many IT environments, this is still common practice: domain administrators are also regular users. The same account that reads email, logs into business applications, and accesses internal services may also hold full administrative privileges in the directory.
Convenient? Absolutely. Risk-free? Not quite. If such an account is compromised, the impact goes far beyond a single user. A compromised admin account can potentially expose the entire infrastructure. That is why the German BSI IT-Grundschutz framework recommends clearly separating administrative accounts from regular user identities. In theory, that sounds pretty straightforward. In practice, the real question is: how do you actually implement that separation?
With UCS 5.2-4, released in December 2025, Univention introduces two new Nubus features designed to address exactly this challenge: Delegative Administration and Just-in-Time Authentication. Both features are currently available in preview. This article explains how they work and why they matter.
Table of Contents
Delegative Administration in UCS: Rollen statt komplexer LDAP-ACLs
Anyone who wants to delegate administrative permissions in a directory service in a structured and transparent way sooner or later ends up dealing with LDAP Access Control Lists (ACLs). From a technical standpoint, they are extremely powerful. ACLs allow administrators to define very precisely who can read, modify, or delete specific objects. A new department can be placed in its own organizational unit (OU). A help desk team might receive permission to reset passwords. An external service provider could be granted temporary access to a specific part of the directory.
All of this is possible with ACLs. But things tend to get messy quickly. With every additional rule or exception, the configuration becomes harder to understand. And at some point, figuring out why a certain access is allowed or denied means digging through increasingly complex rule logic. Delegation is possible, but transparency often suffers.
Delegative Administration in Nubus introduces a new approach to authorization in the directory service through the Univention Directory Manager (UDM). The idea is simple: administrators should be able to define clearly who is allowed to do what in the directory service, and under which conditions. Right now, the feature is still in preview. According to the documentation, Delegative Administration is not yet intended for production use. Configuration and setup details may still change in upcoming releases.
One important limitation of the current preview is that Delegative Administration doesn‘t control which modules are visible in the Univention Management Console (UMC). Module visibility continues to be handled by the existing authorization mechanisms, primarily UCS policies. Delegative Administration operates at a different level. It evaluates authorization directly within UDM, checking whether a specific action in the directory service is allowed.
Role-Based Authorization in the Univention Directory Manager (UDM)
Instead of deriving permissions indirectly from ACL rules, Delegative Administration uses explicit roles. A role specifies
- which object types it applies to (e.g., users or groups),
- which part of the directory it covers (such as a specific OU),
- which actions are allowed (read, modify, create, delete),
- and which attributes can be accessed or modified.
Roles can be assigned directly to users or groups. When a role is assigned to a group, all members automatically inherit it. Authorization checks happen inside the UDM layer, where each requested operation is evaluated against the role definitions. The underlying LDAP ACLs stay exactly as they are.
This example shows how straightforward this works:
access by role="myRole" to objecttype="users/user" position.subtree="cn=users,{ldap/base}" grant actions="search,read" grant properties="*" permission="read"
This definition grants the role myRole read-only access to user objects of type users/user within a specific subtree below cn=users. Within that scope, the allowed actions are defined explicitly—in this case search and read. Other actions such as create or delete could be added as needed. Attribute access can also be controlled. In this example, all attributes may be read, but none can be modified.
How Delegative Administration Works for an Organizational Unit
The concept becomes easier to understand with a simple example. Imagine a user account called ou1-admin. This account is assigned a role that grants administrative permissions only for the organizational unit OU1. After logging in, the administrator only sees that part of the LDAP tree. The same applies to the user management module: it lists only the accounts located within that organizational unit.
Within this scope, the administrator can modify certain attributes, for example, the description field of a user object. But the boundaries are strict. If the user tries to assign roles or work outside OU1, the system returns a clear “Permission denied” message.
Now imagine assigning an additional administrative role for OU2 to the same account. After the next login, both organizational units appear in the directory tree. The administrative scope expands accordingly. Permissions are not extended implicitly or through hidden rule interactions. Instead, they grow in a transparent and predictable way through additional roles.
The result is a role-based model for administrative permissions that is easier to delegate, easier to configure, and far easier to understand than complex ACL structures. Please note, that Delegative Administration doesn’t replace LDAP ACLs. Instead, it adds a clearly structured authorization layer inside the Univention Directory Manager.
Defining roles, however, is only the first step. Even a perfectly configured OU administrator can become a risk if the administrative account lives in the same directory as all regular user accounts. This is exactly where Just-in-Time Authentication comes into play.
Just-in-Time Authentication in Nubus: Separating Administrative Accounts
The second feature is Just-in-Time Authentication. It works together with Delegative Administration and addresses another important question: where should administrative accounts actually live? The basic idea is simple: administrative accounts and regular user accounts should not be stored in the same directory. Instead, the two are separated:
- One directory service stores the managed accounts.
- A second directory service (e.g., Nubus or Active Directory) contains the administrative identities.
Administrators sign in with accounts from that external directory, but they still manage objects in the Nubus directory where the users actually reside. This creates a clear separation between managed identities and administrative identities. It follows established security best practices and aligns with the requirements defined in the BSI IT-Grundschutz, which recommend keeping administrative accounts separate.
How Just-in-Time Authentication Works with Keycloak and OIDC
Technically, this mechanism is based on OpenID Connect (OIDC). When someone signs in to the Univention Management Console (UMC), authentication happens through the Nubus identity provider, Keycloak. For Just-in-Time Authentication, Keycloak is configured to trust the identity provider of the external management domain. This establishes a federation between the two systems:
- Signing in to the UMC first redirects the request to Keycloak.
- Keycloak forwards the login request to the identity provider of the management domain.
- The user authenticates there, against the external directory.
- The external identity provider returns an OIDC token, which includes information such as:
- nubus_id: a unique identifier for the management domain
- nubus_roles_from_groups: the roles used to authorize the account
- Nubus Keycloak passes this information on to the UMC.
At that point, the UMC detects that the account doesn’t exist in the local LDAP directory. And this is where the key idea of Just-in-Time Authentication becomes visible. No local admin account is created. Nothing is synchronized or replicated. There is no shadow account in the directory. Instead, the roles contained in the token nubus_roles_from_groups are applied only for the duration of that session.
Think of it as a visitor badge. The identity remains in the external system. During the session, the permissions defined in the token are activated temporarily. Once the user logs out, those permissions disappear again.
If the administrative account is disabled in the external system, access to the UMC stops immediately as well. Because no local copy of the account exists in the Nubus directory, the account status takes effect directly through the authentication flow. No additional status synchronization is required.
Delegative Administration and Just-in-Time Authentication: Two Pieces of the Same Model
The real strength of these features becomes clear when you look at them together.
- Delegative Administration defines what an account is allowed to do in the directory.
- Just-in-Time-Authentication defines where that account comes from.
If roles are defined but administrative accounts still live in the same directory as the managed user accounts, a structural risk remains. The admin account exists permanently inside the system. It’s technically part of the same directory and has to be protected there with additional safeguards. In that situation, the separation between administrative and regular identities may exist as a policy—but not as part of the architecture.
Just-in-Time Authentication changes that. Administrative identities remain in a separate management domain, such as an Active Directory or another Nubus system. They don’t exist as local objects in the target directory. They are not replicated, synchronized, or stored there permanently. Only when an administrator signs in through OpenID Connect are the required roles applied temporarily for that session.
Together, these two features make it possible to manage administrative access in a way that is structured, transparent, and easy to control—without adding more LDAP ACL complexity and without maintaining duplicate accounts.
