Mid-market organizations with a hybrid Active Directory and Entra ID environment sit in an awkward spot in the IGA vendor landscape. Enterprise platforms like SailPoint assume you have a year and a dedicated implementation team. Lightweight tools assume you live entirely in the cloud. If your environment syncs on-prem AD up to Entra — but not back down — and your source of truth for user identities lives in a custom HR or contract management database rather than Workday or BambooHR, most vendor demos are not going to address your actual situation.

The Reddit thread this draws from describes that scenario precisely: a ~2,000-user European public sector organization, hybrid AD/Entra with one-way sync, custom code already pulling contract data into a database, and a need to replace an end-of-life Broadcom CA Identity Suite installation. Here is what the evaluation actually looks like for environments like this.

Why Your Source of Truth Setup Changes the Evaluation

Most IGA platforms are designed to ingest identity data from one of a handful of standard HR systems — Workday, BambooHR, UKG, SAP SuccessFactors. When your authoritative identity data lives in a custom database built around a regional or proprietary contract management system, you need to verify early in any evaluation that the platform can actually connect to it.

The approaches that work:

API ingestion. If your existing code that extracts contract data exposes an API or can push data on a schedule, an IGA platform with a flexible API connector can consume that data directly. The platform polls or receives the data, maps fields to its identity model, and uses contract events — new hire, role change, contract end — to trigger lifecycle workflows.

File-based ingestion. Automated CSV or structured file drops to a secure location (SFTP, S3) work for platforms that support scheduled imports. Less elegant than real-time API triggers, but reliable for environments where the contract system cannot push events in real time.

Custom SDK or middleware. Some platforms allow you to build a thin integration layer that translates your database schema into their identity model. This works but adds something your team owns and maintains — worth knowing upfront whether that sits with you or the vendor.

The question to ask in any demo: can you show me how this platform ingests identity data from a custom database or non-standard source, and what triggers a provisioning event when a new contract record is created?

Hybrid AD and Entra ID: The One-Way Sync Constraint

Your architecture — on-prem AD syncing up to Entra, no down-sync — is more common than vendors tend to acknowledge in their standard demos. The constraint it creates: any IGA platform needs to be able to write directly to on-prem AD, not just to Entra, because Entra cannot push changes back down to AD in this configuration.

The mechanism that handles this is an on-prem directory agent — a lightweight service deployed inside your network that maintains a secure, outbound-only connection to the IGA platform. Zluri's Directory Agent runs as a Docker container and communicates over LDAPS, meaning no inbound firewall rules are required. When a new contract event triggers a provisioning workflow, the agent receives the instruction and executes it directly in on-prem AD: creates the account, sets the password, assigns the user to the appropriate OUs and groups. Your existing AD-to-Entra sync then carries those changes up to the cloud layer automatically, keeping your architecture intact.

The things to verify in this specific setup:

• Can the agent write to AD directly, or does it only read? Read-only agents are useful for discovery but cannot execute provisioning actions.
• Does configuring LDAPS require changes to your AD certificate infrastructure, and does the vendor walk you through that?
• What happens if the agent loses connectivity — does provisioning queue and retry, or does it fail silently?

Managing Employees and Contractors as Distinct Identity Types

At ~2,000 employees plus an undefined contractor population, the governance requirements for the two groups are different enough to warrant explicit handling rather than treating everyone as the same user type.

Contractors typically need time-limited access rather than indefinite provisioning, stricter scoping to the specific applications relevant to their engagement, and offboarding tied to contract end dates rather than HR termination events. If your contract database distinguishes employees from contractors — which it likely does — the IGA platform should be able to consume that distinction and apply different lifecycle rules to each group automatically.

The pattern that works: identity categorization rules built on fields from your source database. If a record has a contract type of "external" or belongs to a specific contractor domain, it gets classified as a contractor identity and the appropriate playbook applies. No manual tagging, no separate provisioning process — the classification happens at ingestion and the right rules follow automatically.

This is also where the "protecting service accounts" problem surfaces. Service accounts created for automated processes or integrations look inactive in any usage-based review because they do not have human login patterns. Explicit categorization — flagging them as service accounts during discovery — keeps them out of automated revocation policies that would otherwise treat them as dormant user accounts.

JML Lifecycle in a Hybrid Environment: What Full Coverage Actually Means

JML automation in a hybrid environment is only as complete as the slowest step in the chain. For each lifecycle event, the questions to answer:

Joiners. When a new contract record is created, how quickly does the provisioning trigger fire? Is it real-time, scheduled, or manual? Does the platform provision to on-prem AD and Entra in sequence, or in parallel? What is the fallback if the AD agent is temporarily unavailable?

Movers. When a role or department changes in the source database, does the platform automatically revoke the previous role's access before provisioning the new role's access? Or does it only add? The add-only pattern is how privilege creep accumulates — each role change adds access without removing anything, and over years the gap between what someone has and what they need becomes significant.

Leavers. When a contract ends, does offboarding cover both AD account deactivation and revocation across connected SaaS applications? SSO-federated apps deprovision cleanly when the AD account is disabled. Non-SSO applications — tools employees adopted outside IT's purview, apps that do not connect to the identity provider — require explicit offboarding actions. The platform needs to reach both categories, or orphaned accounts accumulate in the disconnected apps.

For a public sector organization, the audit trail for each of these events is not optional. Every provisioning and deprovisioning action should be logged with the event that triggered it, the workflow that ran, and the timestamp — so when an auditor asks who had access to a system during a specific period, the answer is retrievable without manual reconstruction.

RBAC at This Scale: What Granularity You Actually Need

Role-Based Access Control at ~2,000 users in a public sector environment typically means mapping job functions to access bundles — the set of AD group memberships and application access that each role requires — and ensuring those bundles are provisioned consistently and reviewed periodically.

The practical requirements:

Role definition that connects to your org structure. Roles should map to the department and job function fields in your source database, so that provisioning is driven by identity attributes rather than manual assignment. If a new employee joins the finance department, they should receive finance-role access automatically based on that attribute, not because someone looked up the right group and manually assigned it.

Access reviews tied to roles. Periodic certification campaigns that ask managers or application owners to confirm whether users' access is still appropriate. In a public sector environment, these are typically required by policy and need to be documented.

Separation of administrative roles within the IGA platform itself. Who can modify lifecycle workflows? Who can approve access requests? Who can run access reviews? Granular administrative role control within the platform prevents a configuration change from being made by someone without appropriate authority.

The European and Open Source Options Worth Knowing About

The Reddit thread surfaced two options that came up repeatedly and are worth naming directly for European public sector contexts.

midPoint (Evolveum, Slovak Republic) is open source and has a substantial connector library covering AD/LDAP, Microsoft Graph, Exchange, and a range of enterprise systems. REWE Group uses it in production. The honest assessment from the thread: it handles the technical requirements well, the open source community activity could be more active, and implementation requires more internal technical investment than a SaaS platform. For organizations with in-house identity engineering capability and a preference for not depending on US vendor support — a consideration the thread raised directly — it is a legitimate option.

Omada (Danish, headquartered in Copenhagen) is a purpose-built IGA platform with a strong European customer base and a focus specifically on IGA without add-on complexity. Multiple practitioners in the thread recommended it highly. It is a commercial SaaS product, not open source, but it does not carry the enterprise overhead of SailPoint or Saviynt.

One Identity Manager has a German engineering base and is noted in the thread as particularly popular in European markets. It supports on-prem, cloud, and SaaS deployment with the same feature set across delivery modes.

For organizations replacing an end-of-life platform like Broadcom CA Identity Suite, the evaluation framework from the thread is sound: go through your top requirements before evaluating products, run RFP demos against two or three specific requirements rather than generic capability tours, and think in terms of total cost of ownership over a decade rather than just licensing cost.

FAQ

What IGA solution works best for a hybrid Active Directory and Entra ID environment?

Platforms that deploy a lightweight on-prem directory agent for AD write-back — without requiring inbound firewall rules — work best in one-way sync environments where Entra cannot push changes back to AD. The agent handles on-prem provisioning while the platform manages Entra ID and connected SaaS applications through native cloud integrations.

Can an IGA platform use a custom database as the identity source of truth?

Yes, through API ingestion, scheduled file-based imports, or custom SDK integrations. The platform maps fields from your database to its identity model and triggers lifecycle workflows based on events in that data — new contract records, role changes, contract end dates. The verification question in any evaluation is whether the platform can demonstrate this with a non-standard source.

How do you manage contractors differently from employees in an IGA system?

Identity categorization rules applied at ingestion classify contractors based on fields in the source data — contract type, domain, AD group membership. Separate lifecycle playbooks then apply to each category: time-limited access for contractors, contract-end-triggered offboarding rather than HR termination events, and stricter application scoping. This is configured once and runs automatically as new contractor identities are created.

What should a public sector organization look for in an IGA solution?

Complete audit trails for all provisioning and deprovisioning actions, access certification capabilities for periodic access reviews, support for hybrid on-prem and cloud environments, and data sovereignty considerations if US vendor dependency is a concern. European vendors like Omada, midPoint, and One Identity Manager are commonly used in European public sector contexts.