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

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

AD Shop Seeding — Plan v0.3

Seed sandbox.local with a versatile, OIM-shop-typical catalog of AD groups

and OUs so the IT-Shop has plenty of orderable entitlements. Groups are

empty containers for demo purposes — no real applications, SSO, or

provisioning logic behind them.

Author: Claude + Codex · Status: v0.6 · AD entitlements seeded; ready for OneIM sync

Review artifact: OIM IT Shop Entitlement AD Group Catalog Proposal

IT Shop structure proposal: ITSHOP-STRUCTURE-PROPOSAL.md

IT Shop structure seed SQL: sql/seed-itshop-structure.sql

AD seeder: scripts/sandbox/seed/Invoke-AdShopSeed.ps1

1. Goals

2. Out of scope (for v1)

3. Scale (target)

BucketCount
Fictional apps15
Per-app groups5
App groups75
Business roles9
System roles10
Distribution lists3
Total groups97
OUs~21

4. OU layout

DC=sandbox,DC=local
└── OU=OIM-Managed
    ├── OU=Resources
    │   ├── OU=Applications
    │   │   ├── OU=APP-ATLAS
    │   │   ├── OU=APP-HELIOS
    │   │   └── … (one OU per app, 15 total)
    │   └── OU=DistributionLists
    └── OU=Roles
        ├── OU=BusinessRoles
        └── OU=SystemRoles

Rationale: Resources = direct orderable/grantable AD entitlements;

Roles = business-role and system-role bundle markers.

Mirrors how OIM Manager UI typically separates "Service Items" from

"Business Roles".

5. Naming conventions

All groups: Global Security, samAccountName uppercase, hyphen-free.

BucketsamAccountNameExample
App entitlementAPP_<CODE>_<TIER>APP_ATLAS_ADMIN
System roleSR_<CODE>SR_ENG_CORE
DistributionDL_<NAME>DL_ALLSTAFF
Business roleBR_<DEPT>BR_FINANCE

Each group's description carries a human-readable label suitable for the

OIM service-item display name (e.g. description="Atlas Office — Admin").

info (notes) carries the application long name + tier rationale so the

OIM-side auto-derivation has rich text to consume.

6. Application catalog (15)

CodeApp nameDomain
ATLASAtlas OfficeProductivity
HELIOSHelios MailProductivity
PULSEPulse ChatCollaboration
FORGEForge IDEEngineering
PIPEPipeline CIEngineering
VAULTVault SecretsEngineering
INSIGHTInsight BIData & Analytics
LUMENLumen Data LakeData & Analytics
TEMPOTempo HRHR
LEDGERLedger FinanceFinance
BEACONBeacon CRMSales
CITADELCitadel VPNInfrastructure
SENTSentinel SIEMSecurity
SPECSpectrum DAMMarketing
VOYAGERVoyager CMSMarketing

7. Per-app entitlement template (5 tiers)

Every application gets the same 5 groups for symmetry; OIM-side

service-category metadata can hide tiers that don't apply (none in v1).

TierGroup suffixDescription suffix
Reader_READER"<App> — Read-only"
User_USER"<App> — Standard user"
Editor_EDITOR"<App> — Content editor"
Admin_ADMIN"<App> — Administrator"
Approver_APPROVER"<App> — Request approver"

Risk, location, and birthright groups are intentionally excluded from this

phase. The live OneIM database already has IT Shop and role-request structures;

this seed focuses on AD entitlements and system-role-related catalog building

blocks.

8. Cross-cutting groups

Business roles (9) — BR_HR, BR_FINANCE, BR_IT, BR_ENGINEERING,

BR_SALES, BR_MARKETING, BR_OPERATIONS, BR_LEGAL, BR_CUSTOMERSUPPORT

System-role-related entitlements (10) — SR_WORKFORCE_BASE,

SR_ENG_CORE, SR_ENG_ADMIN, SR_DATA_ANALYST, SR_FIN_OPERATOR,

SR_HR_OPERATOR, SR_SALES_OPERATOR, SR_MKTG_CREATOR,

SR_SEC_OPERATOR, SR_PRIV_ACCESS

Distribution-list-shaped security groups (3) — DL_ALLSTAFF,

DL_LEADERSHIP, DL_ENGINEERING (mail-enabling deferred; created as

Global Security groups for v1 with [TYPE:DL] in description)

9. Idempotent seeding approach

Single PS1 driven by a project-owned data file (JSON), shape:

{
  "rootOu": "OU=OIM-Managed,DC=sandbox,DC=local",
  "applications": [
    { "code": "ATLAS", "name": "Atlas Office", "domain": "Productivity" },
    …
  ],
  "tiers": [
    { "suffix": "READER",   "label": "Read-only" },
    …
  ],
  "businessRoles": [ "HR", "FINANCE", … ],
  "systemRoles": [
    {
      "code": "ENG_CORE",
      "name": "Engineering Core",
      "includes": [ "APP_FORGE_USER", "APP_PIPE_USER", "APP_VAULT_READER" ]
    }
  ],
  "distributionLists": [ "ALLSTAFF", "LEADERSHIP", "ENGINEERING" ]
}

Source-of-truth location:

Script behavior:

Execution path (depends on resolution of WinRM blocker):

10. OneIM DB observations

Queried live on 2026-04-26 against OneIM:

AreaObservation
IT Shop nodesITShopOrg has 22 rows. Root is Identity & Access Lifecycle.
AD group shop structureExisting shelf/bucket: Identity & Access Lifecycle\Active Directory Groups; group lifecycle bucket also exists.
Role request structureExisting products include Role membership, Role entitlement assignment, and System role entitlement assignment.
Service itemsAccProduct has 20 rows, including predefined AD group and system-role request products.
AD groupsADSGroup has 287 rows; all currently IsForITShop = 0, IsITShopOnly = 0.
System rolesESet has 0 rows; ESetHasEntitlement has 0 rows. The schema exists but is unused in this sandbox.
System role typesESetType has Common and RessourceSet.

Implication: AD seeding should create AD groups now. OIM Phase 2 can then

sync them into ADSGroup, publish app groups as service items, and optionally

create ESet system roles that bundle selected ADSGroup entitlements via

ESetHasEntitlement.

11. OIM-side wiring (Phase 2 — separate plan, sketched here)

After AD sync lands the groups in ADSGroup:

1. Sync project: confirm the existing ADS sync project picks up the new OU subtree (OU=OIM-Managed).

2. Service items: enable the supported ADSGroup publication path (QER\ITShop\AutoPublish\ADSGroup in this sandbox) through Designer/configuration tooling and compile the database if the preprocessor-relevant parameter changes.

3. Service categories: use the already seeded coarse AccProductGroup categories: Sandbox Applications, Sandbox Business Roles, Sandbox System Role Bundles, and Sandbox Distribution Lists.

4. Shop assignment: use the already seeded Identity & Access Lifecycle\Sandbox Applications, Sandbox Business Roles, Sandbox System Role Bundles, and Sandbox Distribution Lists shelves for product placement. Keep them as shallow BO shelves; application/domain grouping belongs in AccProduct metadata/categories or portal filtering.

5. System roles: create OIM ESet objects for each SR_* catalog entry and link included ADSGroup objects through ESetHasEntitlement.

6. Role request products: use the existing System role entitlement assignment / Role entitlement assignment IT Shop structure for role-related request demos.

7. Ownership: each app's _ADMIN group can later become the OIM owner candidate for app-category service items.

Implemented on 2026-04-27:

12. Codex critique decisions

1. OU split — keep the Resources vs Roles split. It is worth the slightly deeper LDAP filter because it cleanly separates requestable entitlements from modeling groups and maps better to OIM shop concepts. Sync can target OU=OIM-Managed recursively.

2. Group scope — keep Global Security for v1. This is a single-domain sandbox and Global groups are the expected source entitlement shape for AD resource assignment. Revisit Universal only if the sandbox gets a multi-domain forest or cross-domain mail/distribution scenarios.

3. Risk, location, birthright — removed from v1 per Viktor direction.

4. Distribution lists — keep DL_* as Global Security groups in v1 with [TYPE:DL] in the description. Do not mail-enable yet. They are useful demo objects without adding Exchange/mail dependency.

5. Pre-seeded users — no users in v1. Keep this project entitlement-shaped. Add a separate "demo identities and memberships" phase later, probably sourced from HRSystem, so AD users, Person records, and memberships stay coherent.

6. Execution channel — WinRM-first after TrustedHosts is fixed. It uses the domain host's AD module and avoids LDAP write edge cases. Add direct AD LDAPS as fallback only; do not use OpenDJ credentials for AD seeding.

7. Naming — keep uppercase prefixes and underscores. They are readable in ADUC and stable for OIM filters. Keep app codes at 7 characters or fewer so APP_<CODE>_APPROVER stays inside the 20-character sAMAccountName limit; add a preflight length/duplicate check.

8. Catalog stability — project data belongs under projects/identity-management/ad-shop-seeding/data/; executable helpers belong under scripts/sandbox/seed/. This keeps research/project intent separate from reusable automation.

Additional Codex recommendations:

13. What I'd like back from Codex

Resolved in §11. Next step: reconcile to v1 and implement the JSON catalog plus scripts/sandbox/seed/Invoke-AdShopSeed.ps1.

Cross-references