Virtual Directory Server
Turn LDAP—the protocol your legacy systems already speak—into the universal on-ramp for identity governance. Normalize inbound events, aggregate read models, and serve applications through one secure endpoint—zero source-system changes.
Key advantages
The integration nightmare
"We have 12 systems that manage access. Each one has its own way of granting and revoking privileges. When someone approves a role in SAP GRC, we need that decision to flow through to Active Directory, Azure AD, and our entitlement ledger. Today, that takes 3 custom scripts, 2 middleware servers, and a prayer." — CISO, Fortune 500
Point-to-point integrations
Every new system requires custom development—$50K–$200K per connector, weeks of work.
No single audit trail
Compliance teams can't answer "who approved what" across systems. Days per audit cycle assembling evidence.
Delayed provisioning
Batch processing means hours or days between approval and access. Employees can't work.
Legacy systems can't change
SAP GRC and SAP IDM have no REST APIs. The LDAP interface is the interface.
Manual reconciliation
Staff re-key access decisions between systems—5–10 FTE hours every week.
SAP IDM is retiring
The sole consumer of GRC-approved provisioning requests is end-of-life, with no replacement path.
Why alternatives fall short
How it works
Your legacy system sees a standard LDAP directory. It sends BIND, MODIFY, ADD, DELETE and gets standard result codes back. Behind the scenes, VDS classifies every operation and publishes it as a governance event.
Receive
- →Accept standard LDAP ops from SAP GRC, ServiceNow, HR, or any LDAP-speaking app
- →Each source gets its own partition—isolated auth, write policy, and event routing
- →Adding a new source is a YAML block, not a development project
Classify & normalize
- →5-priority classifier determines semantic meaning of every operation
- →Maps to 12-field NormalizedEvent with UUID5, SHA-256, dedup keys
- →No naive assumptions—every LDAP op classified by semantic meaning
Publish & govern
- →Kafka
acks=all— LDAP success only after broker acknowledgment - →Kafka failure returns LDAP error 52 — source retries automatically
- →Downstream: policy evaluation, provisioning, and audit records
Five-priority object classifier
Every LDAP operation passes through a classification chain that determines its semantic meaning before it becomes a governance event. No guessing—every priority level has explicit fallback behavior.
Protocol bridge, not a proxy
Traditional virtual directories only proxy reads. EmpowerNow VDS captures writes and turns them into classified governance events—an architectural shift from passive aggregation to active identity automation.
Capabilities
Eight core capabilities that turn a legacy protocol into a modern governance pipeline.
Intelligent event classification
5-priority chain · semantic meaning for every operation
Intelligent event classification
Every LDAP operation passes through a five-priority classifier chain before becoming a governance event. No guessing—each level has explicit fallback behavior.
- DIT config override → objectClass → partition schema → branch heuristic → fallback
- Prevents naive assumptions like "every ADD is user onboarding"
- Unresolvable objects return LDAP error 53 — never silently dropped
Multi-partition architecture
Independent auth, schema & routing per source
Multi-partition architecture
One VDS instance serves multiple external systems—each with its own isolated namespace.
- Independent auth, schema, write policy, and Kafka topic per partition
- Add a new source system with a YAML block — not a development project
- Supports both UEAS and RAW normalization modes per partition
Bidirectional reads + writes
Aggregate reads · capture writes as events
Bidirectional reads + writes
Not just a proxy—VDS handles both directions of identity traffic.
- Read: Aggregate AD, Azure AD, Auth0, ServiceNow through a single LDAP search with attribute mapping and merge rules
- Write: Translate LDAP modifications into classified governance events published to Kafka
- Six backend connector types (AD, SCIM, SQL, REST, LDAP, static)
SCIM 2.0 + LDAP dual protocol
Legacy and cloud-native from the same container
SCIM 2.0 + LDAP dual protocol
Full RFC 4511 LDAP on port 2636 and full SCIM 2.0 HTTP API on port 8011 from the same ~100 MB container.
- Legacy apps keep their LDAP connections unchanged
- Cloud-native consumers use SCIM for user/group lifecycle
- SCIM directories hot-reload every second — no restart needed
12-field NormalizedEvent
Deterministic IDs · SHA-256 integrity · template expansion
12-field NormalizedEvent
Every event shares the same 12-field schema regardless of source system—one format for the entire governance pipeline.
- Deterministic event_id (UUID5), correlation_id, dedupe_key (SHA-256)
- Payload integrity hash for tamper detection
- subject_key template expansion and attribute allowlisting — all computed server-side
Epoch-bucket deduplication
60-second windows · exactly-once semantics
Epoch-bucket deduplication
Identical requests within a 60-second epoch window produce the same dedupe_key. Downstream IngestService drops duplicates.
- Combined with Kafka's idempotent producer: exactly-once semantics
- No events lost, no events duplicated — even across restarts
- LDAP success (code 0) returned only after Kafka ISR confirmation
Declarative YAML + hot-reload
7 config files · 70+ env vars · Docker secrets
Declarative YAML + hot-reload
Pure configuration, no UI required. Everything defined in YAML, overridable with environment variables.
- 7 YAML config files covering partitions, backends, Kafka, security, and normalization
- SCIM directories hot-reload every second — no restart, no downtime
- Docker secrets for credential resolution — no plaintext passwords in config
Observability built in
Prometheus · OpenTelemetry · structured JSON logs
Observability built in
Full-stack observability from day one — no instrumentation project.
- 20+ Prometheus metrics exposed for scraping
- OpenTelemetry distributed tracing with correlation IDs on every operation
- Structured JSON logging: bind_dn, partition, event_id, and outcome per entry
Multi-partition isolation
One VDS instance serves multiple external systems. Each source gets its own partition with independent authentication, schema, write policy, and Kafka routing. Adding a new source is a YAML block, not a development project.
Business impact
2–8 weeks custom dev → <1 day YAML config
$20K–$50K/year per connector → near-zero
Hours (batch sync) → real-time events
5–10 FTE hours/week → unified event stream
5-year TCO comparison (3 systems): Traditional integration $500K–$1.2M → VDS: included in platform
Security model
Five layers of protection from transport to data, with fail-closed defaults at every level.
All event fields (source, event_type, correlation_id) are computed server-side from partition config—never from client input. userPassword is always excluded regardless of configuration.
Connects to your stack
Inbound LDAP from any source system. Six backend connector types for read aggregation. Downstream to the full EmpowerNow governance pipeline.
SAP GRC / IDM 
Active Directory 
Entra ID 
ServiceNow 
Workday / SAP HCM How VDS compares
Frequently asked questions
How is VDS different from a traditional virtual directory?
Traditional virtual directories (Oracle, Radiant Logic) only proxy reads—they aggregate backend data into a unified LDAP tree. EmpowerNow VDS captures writes and turns them into classified governance events published to Kafka. It is an architectural shift from passive data aggregation to active identity automation. It also includes SCIM 2.0, ships as a ~100 MB Docker container, and is included in the platform.
What happens if Kafka is unavailable?
VDS returns LDAP error code 52 (unavailable). LDAP clients are designed to retry on temporary errors—standard directory behavior. No events are lost. When Kafka recovers, retries succeed automatically. The idempotent producer and epoch-bucket deduplication ensure no duplicates.
Does VDS replace our directory server?
No. VDS sits alongside your existing directories. Source systems point their LDAP connections at VDS instead of—or in addition to—the target directory. VDS normalizes writes into events and aggregates reads from backends. Your directories remain authoritative.
How long does it take to add a new source system?
The Quick Start guide gets you from zero to events-on-Kafka in 15 minutes for the first system. Additional systems require adding a YAML partition block with auth, write policy, and event routing—typically less than a day including testing. No code changes.
Is LDAP going away?
Not for 5+ years in most enterprises. SAP GRC, Active Directory, and many HR systems will speak LDAP for the foreseeable future. VDS bridges the gap today and also serves SCIM 2.0 for cloud-native consumers—your investment is future-proof regardless of protocol evolution.
Standards & protocols
Protocols
Observability
Compliance-ready
Use cases
Related reading
Ready to see it live?
Book a 15-minute walkthrough with an engineer. We'll map Virtual Directory Server to your architecture, show real event flows, and answer every technical question.