Source: projects/identity-management/oim-kb-update/sandbox-host/2026-04-27-opendj-ldap-shop-open-questions.md

> Source: projects/identity-management/oim-kb-update/sandbox-host/2026-04-27-opendj-ldap-shop-open-questions.md

OpenDJ LDAP Shop Open Questions - Sandbox Evidence

Evidence Sources

• Sandbox host, WinRM read-only checks.
• OpenDJ local ldapsearch on the VM:
• C:\OpenDJ\bat\ldapsearch.bat --hostname localhost --port 1389 ...
• OneIM DB read-only checks through scripts/sandbox/Invoke-SandboxSql.ps1.

No LDAP or OneIM mutations were made.

Endpoint Correction

External workstation probes against im.sandbox.local:389/636 reach Active Directory (lsass.exe), not OpenDJ.

VM-local port ownership:

OpenDJ is running as Windows service OpenDJ Server from C:\OpenDJ.

From the workstation, TCP 1389 timed out, so OpenDJ should be accessed locally on the VM or through a deliberately opened firewall/routing path.

Writable Suffix

OpenDJ RootDSE via local ldapsearch:

dn:
namingContexts: dc=ldap,dc=com
supportedLDAPVersion: 2
supportedLDAPVersion: 3
vendorName: Open Identity Platform Community
vendorVersion: OpenDJ Server 5.1.0

Answer: use dc=ldap,dc=com as the writable suffix for the LDAP shop seed.

Recommended project subtree:

ou=oim-managed,dc=ldap,dc=com

Existing LDAP Content

OneIM DB snapshot:

Existing containers:

Existing groups are under ou=Groups,dc=ldap,dc=com and use groupOfNames.

At least one existing group, cn=Team Development Sweden,ou=Groups,dc=ldap,dc=com, has no member attribute, so this OpenDJ schema/configuration permits an empty groupOfNames group.

Conflict Check for LDAP Shop Seed

Read-only comparison against the v1 plan showed no naming or DN conflicts:

Design consequence: use a separate ou=oim-managed,dc=ldap,dc=com subtree for v1. Do not mix the fictional test catalog into existing ou=People / ou=Groups.

The earlier ou=edge-cases proposal has low value for v1. It would add another shelf/category and container without helping the baseline questions: LDAP sync, direct membership import, and IT Shop request behavior. Edge tests should be a later lab after baseline membership import is proven.

Current OIM LDAP Sync Scope

OneIM has one LDAP domain:

Synchronization metadata:

Answer: the current project appears to synchronize the whole dc=ldap,dc=com suffix, not just ou=People or ou=Groups.

Therefore ou=oim-managed,dc=ldap,dc=com should be in scope after it is created, assuming the sync workflow remains unchanged.

LDAP Object Classes Mapped to OneIM

OneIM synchronization maps these external schema classes to LDAPGroup:

It maps inetOrgPerson to LDAPAccount_inetOrgPerson.

Membership mapping rule evidence:

Planning implication: groupOfNames is the safest v1 choice because it is already present in the sandbox and mapped by the sync project.

groupOfUniqueNames is available, but it should be a secondary compatibility test rather than the default seed shape.

Empty Group Requirement

OpenDJ schema evidence:

objectClasses: ( 2.5.6.17 NAME 'groupOfUniqueNames' SUP top STRUCTURAL MUST cn MAY ( uniqueMember ... ) )
objectClasses: ( 2.5.6.9 NAME 'groupOfNames' SUP top STRUCTURAL MUST cn MAY ( member ... ) )

Answer: in this OpenDJ installation, groupOfUniqueNames does not require a non-empty uniqueMember; only cn is mandatory.

Likewise, groupOfNames only requires cn, and the live empty Team Development Sweden group confirms empty groupOfNames works.

Planning implication: an anchor member is optional, not required. Keep the anchor account only if a test explicitly needs a stable placeholder.

Membership Import Caution

OpenDJ currently has groupOfNames entries with member values, but OneIM currently shows:

LDAPAccountInLDAPGroup = 0
LDAPGroupInLDAPGroup   = 0

This means the current synchronized data does not yet prove LDAP membership assignment import is working end to end.

Before creating many test entitlements, run a focused sync test with one direct LDAP membership and verify LDAPAccountInLDAPGroup.

Approval Policy Recommendation

No LDAP-specific PWODecisionMethod was found by name.

Recommended v1 policy:

Rationale:

• Avoids reusing the AD-named policy for LDAP products.
• Better represents a generic entitlement request than product-owner-only approval.
• Still requires owner/manager data to be meaningful; if the sandbox identities lack manager/product-owner routing, use a simpler temporary test policy for cart-flow validation only.

Do not clone a custom LDAP-specific policy for v1. First prove LDAP membership import and IT Shop assignment behavior with a standard policy.

Bundle Modeling Recommendation

Keep ldap_bundle_* as direct LDAP groups in v1.

Rationale:

• The immediate goal is LDAP group assignment testing.
• Direct LDAP bundle groups exercise the same LDAPGroup -> AccProduct -> BaseTreeHasLDAPGroup path.
• Native ESet system roles should be phase 2, after baseline LDAP group and membership flows are confirmed.

Phase 2 can model selected bundles as ESet system roles with LDAP-group entitlements, mirroring the AD recommendation.