Known limitations
This page lists limits that matter when planning a rollout. Status: September 2026.
Operation
- A single instance. Nova runs as exactly one instance, because the scheduler and running jobs live in its process. Several instances side by side – for load balancing or active-active high availability – are not supported; Nova scales through threads. See Requirements.
- Time zone of schedules. Jobs run according to the Europe/Berlin time zone; no other time zone can be set for them.
- Transferring configuration. The configuration export contains, among other things, target systems, roles, business roles and approval workflows; currently only the SoD rules can be imported. It therefore covers the move from a test to a production environment only in part. See Updates and backup.
- Validity periods. Only SAP stores the start and end of an assignment itself. In the other target systems, Nova applies the dates through background jobs; they take effect there only with the next run. The start is pushed by the daily job “Activate Pending Assignments”. The end is handled by “Cleanup Expired Assignments”: this job is not created during installation and only passes the removal on when “Auto-provision backend systems” is switched on. See Monitoring and jobs.
SAP
Nova connects over RFC and needs the SAP NetWeaver RFC SDK for this. The SDK is SAP software, is not part of the standard image and has to be provided by the customer. Without the SDK, neither SAP target systems nor SAP organisational data as a source system nor the SAP add-ons can be used. See SAP.
Active Directory and LDAP
- Locking. Except in Active Directory, Nova locks accounts through the password policy's lock attribute (
pwdAccountLockedTime). This only takes effect if the directory enforces a password policy and the account Nova works with may write this attribute. - Nested groups. Nova only writes groups within groups for DN-based groups; the OpenLDAP profile with
posixGroupdoes not support nesting. Generic directories additionally need thememberOfattribute in the schema, with write permission.
See Active Directory and LDAP.
Microsoft Entra ID
In dynamic groups, membership results from rules; in groups synchronised from an on-premises Active Directory, it results from the synchronisation. Microsoft Graph does not allow changes to these memberships, so Nova cannot provision such groups. Security groups with assigned members that are managed in Entra ID itself are suitable as entitlements. See Microsoft Entra ID.
SCIM
SCIM applications implement the standard differently. Nova expects the endpoints under ‹base URL›/scim/v2, looks up accounts and groups with filters on userName and displayName, changes accounts and memberships with PATCH and reads groups page by page. For authentication, Nova supports basic authentication and bearer tokens. Whether an application fits has to be checked per provider. See SCIM.
Last sign-in
Nova can only read when an account was last used if the target system provides it:
| Target system | Source |
|---|---|
| SAP | user master record (USR02) |
| Active Directory | lastLogonTimestamp or lastLogon |
| OpenLDAP | authTimestamp, if the directory maintains it |
| generic LDAP | no default source |
| Entra ID | sign-in activity from Microsoft Graph; requires the AuditLog.Read.All permission |
| Keycloak | the realm's stored login events; if the realm stores none, only active sessions |
| SCIM | no standard attribute; the attribute entered under “Last-logon attribute (SCIM)”, or lastLogin or lastLogon |
Status of acceptance testing
The connectors are tested against a fixed acceptance catalogue with real target systems. Status September 2026:
- SAP (ABAP) and generic LDAP (tested with ApacheDS) have passed the catalogue in two complete rounds; individual sub-requirements were explicitly excluded.
- Microsoft Entra ID: acceptance has not been completed yet.
- Active Directory, Keycloak and SCIM have not yet been run through the catalogue.