Source: projects/identity-management/ldap-shop-seeding/README.md

> Source: projects/identity-management/ldap-shop-seeding/README.md

LDAP Shop Seeding - Plan v0.1

Goal

Create a small fictional LDAP entitlement catalog in the sandbox OpenDJ directory so One Identity Manager can be used to test:

• LDAP group synchronization into LDAPGroup
• LDAP account-to-group assignments through LDAPAccountInLDAPGroup
• requestable LDAP group products in the IT Shop
• product-node generation through BaseTreeHasLDAPGroup / ITShopOrgHasLDAPGroup
• behavior differences between direct LDAP assignment and IT Shop-originated assignment

No LDAP or OneIM mutation is part of this plan. Implementation should be a separate, locked sandbox change.

Current Sandbox Evidence

Live OneIM v10 DB checks on 2026-04-27 confirm these LDAP tables exist:

LDAPGroup has the IT Shop publication columns needed for the same basic pattern used for AD groups:

• UID_AccProduct
• IsForITShop
• IsITShopOnly

Current OpenDJ/OIM inventory, checked read-only on 2026-04-27:

Design decision from this inventory: keep the seed in a new ou=oim-managed,dc=ldap,dc=com subtree instead of adding to the existing ou=People / ou=Groups containers. This avoids collisions and makes cleanup/reset unambiguous.

No LDAP-specific PWODecisionMethod was found by name. For v1, prefer a generic approval policy over reusing an AD-named policy.

Recommended v1 approval policy:

No LDAP-specific policy was found by name. Avoid reusing the AD-named policy for LDAP products.

If sandbox manager/product-owner routing is incomplete, use a simpler temporary test policy only for cart-flow validation.

LDAP DIT Structure

Discovery result from 2026-04-27:

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

Use dc=ldap,dc=com below for the discovered writable suffix.

Proposed project-owned subtree:

ou=oim-managed,dc=ldap,dc=com
  ou=people
    ou=employees
    ou=service-accounts
    ou=anchors
  ou=groups
    ou=applications
      ou=docsuite
      ou=codeforge
      ou=packagehub
      ou=observatory
      ou=learnlab
    ou=platform
    ou=business-roles
    ou=access-bundles
    ou=distribution

Design choices:

• Keep LDAP separate from the existing AD OU=OIM-Managed tree so connector behavior is easy to compare.
• Use a flat group CN naming scheme inside typed containers; do not encode every app as a deep tree unless the LDAP sync mapping benefits from it.
• Add a stable marker to description: [OIM-SANDBOX-SEED:ldap-shop-seeding:v1].
• Prefer static groups in v1. Do not create a separate edge-case OU in v1; it adds structure without helping the first membership and IT Shop tests.
• Access OpenDJ locally on the VM through localhost:1389. From the workstation, im.sandbox.local:389/636 is Active Directory, while im.sandbox.local:1389 timed out during research.

LDAP Entry Model

Recommended group object class for v1:

objectClass: top
objectClass: groupOfNames
cn: ldap_app_docsuite_reader
description: [OIM-SANDBOX-SEED:ldap-shop-seeding:v1] ...

Why groupOfNames:

• Existing sandbox OpenDJ groups already use groupOfNames under ou=Groups,dc=ldap,dc=com.
• Common LDAP group pattern.
• Membership is DN-based through member, but v1 does not seed members because LDAP accounts are provisioned by OneIM account definitions.
• The current OneIM synchronization maps groupOfNames.member to the LDAP-group virtual membership property.
• OpenDJ schema in this sandbox has member as MAY, not MUST; empty groupOfNames entries are valid.

LDAP account model:

LDAP accounts are not created by this seed. They should be provisioned from OneIM by assigning or ordering the related LDAP account definition. The ou=people subtree remains as a target area for account-definition provisioning tests.

LDAP Account Provisioning

Do not seed LDAP accounts directly in OpenDJ for this project. Use OneIM account definitions so later sync evidence distinguishes:

• LDAP entitlements seeded externally in OpenDJ.
• LDAP accounts provisioned by OneIM.
• Group assignments added by assignment/order workflows instead of unmanaged seed data.

Fictional LDAP Entitlement Catalog

Total v1 groups: 41.

Application Groups - 20

Five fictional LDAP-backed applications with four tiers each:

Platform Groups - 6

Business-Role Marker Groups - 6

These are LDAP marker groups, not native OneIM business roles:

Access Bundle Groups - 5

These can later become native ESet system roles, but v1 keeps them as LDAP groups for connector testing:

Distribution-List-Shaped Groups - 4

These are LDAP static groups only, not mail-enabled distribution lists:

Initial Memberships

Do not seed initial memberships in v1. Keep all 41 LDAP groups empty until OneIM has synced them and account-definition provisioning is in place.

Expected tests:

• Provision an LDAP account from OneIM by account definition.
• Request a published LDAP group in IT Shop and verify the assignment path.
• If direct LDAP membership import still needs proof, add and remove a temporary membership only after a OneIM-provisioned account exists.
• Test nested group sync only after direct static memberships are understood.

IT Shop Structure

Create these service categories in AccProductGroup:

Create matching BO shelves directly below Identity & Access Lifecycle:

Identity & Access Lifecycle
  Sandbox LDAP Applications        (BO)
  Sandbox LDAP Platform Access     (BO)
  Sandbox LDAP Business Roles      (BO)
  Sandbox LDAP Access Bundles      (BO)
  Sandbox LDAP Distribution Lists  (BO)

Do not create nested BO shelves. The existing IT Shop learning showed BO below BO is rejected by trigger logic.

IT Shop Publication Mapping

After LDAP sync creates LDAPGroup rows:

1. Create one AccProduct per publishable LDAPGroup.

2. Set AccProduct.UID_AccProductGroup to the matching sandbox LDAP service category.

3. Set AccProduct.UID_PWODecisionMethod to the selected generic approval policy.

4. Update LDAPGroup.UID_AccProduct.

5. Set LDAPGroup.IsForITShop = 1.

6. Keep LDAPGroup.IsITShopOnly = 0 in v1, so direct LDAP assignment testing remains possible.

7. Insert the shelf relation through BaseTreeHasLDAPGroup.

8. Let product-node processing create ITShopOrg PR nodes.

Expected assignment table:

Implementation Phases

Phase 0 - Discovery

• Confirm OpenDJ local access path and credentials before mutation.
• OpenDJ suffix is dc=ldap,dc=com; target ou=oim-managed,dc=ldap,dc=com.
• Current OIM sync metadata indicates whole-suffix synchronization: system connection im.sandbox.local:1389, initial start info Synchronize dc=ldap,dc=com, and no DPRSystemScopeFilter rows found.
• Capture live counts for LDAPContainer, LDAPGroup, LDAPAccount, LDAPAccountInLDAPGroup.
• Confirm object-key format for ITShopOrgHasLDAPGroup by inspecting view metadata and any existing rows.
• Before membership tests, provision at least one LDAP account through OneIM account definitions. Do not seed test accounts directly in OpenDJ.

Phase 1 - LDAP Seed

• Add a JSON catalog under projects/identity-management/ldap-shop-seeding/data/ldap-shop-catalog.json.
• Add an idempotent PowerShell seeder under scripts/sandbox/seed/Invoke-LdapShopSeed.ps1.
• Seeder should support -WhatIf and -Json.
• Seeder should never delete; only create missing entries and converge agent-owned attributes.
• Mutations must use Invoke-WithSandboxLock.

Status 2026-04-27:

• Completed on OpenDJ via scripts/sandbox/seed/Invoke-LdapShopSeed.ps1.
• Created ou=oim-managed,dc=ldap,dc=com plus the planned project-owned subtree.
• Created 41 empty groupOfNames entitlement groups.
• Removed the earlier six project-created inetOrgPerson test accounts and removed all seeded group member values.
• Verification below ou=oim-managed,dc=ldap,dc=com: 57 total entries, 16 containers, 0 project-created accounts, 41 groups, 0 member values.
• Next handoff: run OneIM LDAP sync for dc=ldap,dc=com, then publish the synced LDAPGroup rows into IT Shop.

Phase 2 - OIM Sync Verification

• Run or trigger the LDAP synchronization project.
• Verify expected entries in:
• LDAPContainer
• LDAPAccount
• LDAPGroup
• LDAPAccountInLDAPGroup
• Record before/after snapshots under projects/identity-management/oim-kb-update/sandbox-db/.

Phase 3 - IT Shop Publication

• Create service categories and BO shelves.
• Publish the 41 planned LDAP groups as IT Shop products after sync verification.
• Use a generated SQL script only after schema validation, following the same safety model used for the AD publication.
• Verify:
• LDAPGroup.IsForITShop = 1
• LDAPGroup.IsITShopOnly = 0
• LDAPGroup.UID_AccProduct populated
• BaseTreeHasLDAPGroup shelf assignments present
• generated ITShopOrg PR nodes exist

Status 2026-04-27:

• Completed after Viktor confirmed LDAP sync.
• Sync verification before publication: 16 project LDAPContainer rows, 41 project LDAPGroup rows, 0 project LDAPAccount rows, 0 LDAP membership rows.
• Created 5 project-owned LDAP service categories in AccProductGroup.
• Created 5 project-owned LDAP BO shelves under Identity & Access Lifecycle:
• Sandbox LDAP Applications - 20 groups
• Sandbox LDAP Platform Access - 6 groups
• Sandbox LDAP Business Roles - 6 groups
• Sandbox LDAP Access Bundles - 5 groups
• Sandbox LDAP Distribution Lists - 4 groups
• Published all 41 synced LDAPGroup rows with:
• IsForITShop = 1
• IsITShopOnly = 0
• linked UID_AccProduct
• approval policy Recipient's manager and product owner (with peer group analysis)
• BaseTreeHasLDAPGroup BO shelf placement
• DB-side downstream result: 41 AccProduct rows, 41 generated ITShopOrg PR product nodes, 41 BO placement links, and 41 PR placement links.

Phase 4 - Assignment Tests

• Direct LDAP membership add/remove test.
• IT Shop cart/order test for one low-risk LDAP application group.
• Compare assignment origins and DBQueue/job behavior.
• Test nested/dynamic/long-description edge behavior later as a separate lab, not in the v1 entitlement seed.

Researched Open Questions

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

Remaining risk:

• Membership import should be proven only after OneIM has provisioned at least one LDAP account by account definition.