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

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

OIM IT Shop Entitlement AD Group Catalog Proposal

Status: ready for Viktor review

Target: sandbox.local on im.sandbox.local

Catalog source: data/ad-shop-catalog.json

Catalog version: 1.1.0

Implementation update 2026-04-27: the catalog has been seeded in AD under

OU=OIM-Managed,DC=sandbox,DC=local using

scripts/sandbox/seed/Invoke-AdShopSeed.ps1.

Created/verified objects: 22 OUs and 97 empty Global Security groups.

Purpose

Seed the OIM sandbox Active Directory with fictional but realistic AD

entitlement groups that can later be synchronized into One Identity Manager as

ADSGroup objects and published into the IT Shop.

This phase creates empty AD OUs and groups only. It does not create users,

memberships, OIM service items, OIM system roles, approval workflows, owners,

locations, birthright groups, or risk policy data.

Live OneIM Findings

Queried live against OneIM on 2026-04-26:

Area	Finding
IT Shop structure	`ITShopOrg` has 22 rows. Root shelf is `Identity & Access Lifecycle`.
Existing AD shop nodes	Existing nodes include `Identity & Access Lifecycle\Active Directory Groups` and `Group Lifecycle`.
Existing role request nodes	Existing products include `Role membership`, `Role entitlement assignment`, and `System role entitlement assignment`.
Service items/products	`AccProduct` has 20 rows, including predefined AD group and system-role request products.
AD groups	`ADSGroup` has 287 rows. All are currently `IsForITShop = 0` and `IsITShopOnly = 0`.
System roles	`ESet` has 0 rows and `ESetHasEntitlement` has 0 rows. The schema exists but is unused.
System role types	`ESetType` contains `Common` and `RessourceSet`.

Design implication: seed AD groups now; use Phase 2 to sync them into

ADSGroup, publish orderable groups through AccProduct/ITShopOrg, and

optionally create OIM ESet system roles that bundle selected ADSGroup

entitlements through ESetHasEntitlement.

Proposed Scope

Object type	Count	Notes
Fictional applications	15	Business-realistic invented applications
Entitlement tiers per app	5	Reader, User, Editor, Admin, Approver
Application entitlement groups	75	`APP_<CODE>_<TIER>`
Business role groups	9	`BR_*`
System-role-related groups	10	`SR_*` bundle markers for later OIM `ESet` modeling
Distribution-list-shaped groups	3	`DL_*`, not mail-enabled in v1
Total AD groups	97	All Global Security groups
OUs	About 21	Root, buckets, and one OU per application

Explicitly excluded from this proposal:

Risk groups and risk tags.
Location groups.
Birthright groups.
Users and group memberships.

OU Layout

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

Resources holds direct requestable/grantable entitlements. Roles holds

business-role and system-role bundle markers. System-role-related groups live

under Roles\SystemRoles because they model future role bundles rather than

standalone application permissions.

Naming Rules

All groups are Global Security groups with uppercase sAMAccountName values

and underscores.

Bucket	Pattern	Example
Application entitlement	`APP_<CODE>_<TIER>`	`APP_ATLAS_ADMIN`
Business role	`BR_<DEPT>`	`BR_FINANCE`
System-role-related	`SR_<CODE>`	`SR_ENG_CORE`
Distribution-list-shaped	`DL_<NAME>`	`DL_ALLSTAFF`

The catalog validates against AD's 20-character legacy sAMAccountName limit:

97 generated names, no duplicates, maximum length 20.

Application Catalog

Code	Application	Domain
ATLAS	Atlas Office	Productivity
HELIOS	Helios Mail	Productivity
PULSE	Pulse Chat	Collaboration
FORGE	Forge IDE	Engineering
PIPE	Pipeline CI	Engineering
VAULT	Vault Secrets	Engineering
INSIGHT	Insight BI	Data & Analytics
LUMEN	Lumen Data Lake	Data & Analytics
TEMPO	Tempo HR	HR
LEDGER	Ledger Finance	Finance
BEACON	Beacon CRM	Sales
CITADEL	Citadel VPN	Infrastructure
SENT	Sentinel SIEM	Security
SPEC	Spectrum DAM	Marketing
VOYAGER	Voyager CMS	Marketing

Shortened codes PIPE, SENT, and SPEC are intentional so

APP_<CODE>_APPROVER remains within 20 characters.

Per-App Entitlement Tiers

Every application gets the same five tiers for v1:

Tier	Group suffix	Example
Reader	`READER`	`APP_ATLAS_READER`
User	`USER`	`APP_ATLAS_USER`
Editor	`EDITOR`	`APP_ATLAS_EDITOR`
Admin	`ADMIN`	`APP_ATLAS_ADMIN`
Approver	`APPROVER`	`APP_ATLAS_APPROVER`

System-Role-Related Entitlements

The SR_* groups are AD-side bundle markers for later OIM system role (ESet)

modeling. They are not OIM system roles yet. Phase 2 can create matching

ESet rows and link included AD group entitlements through

ESetHasEntitlement.

Group	Label	Intended included entitlements
`SR_WORKFORCE_BASE`	Workforce Base Access	`APP_ATLAS_USER`, `APP_HELIOS_USER`, `APP_PULSE_USER`
`SR_ENG_CORE`	Engineering Core	`APP_FORGE_USER`, `APP_PIPE_USER`, `APP_VAULT_READER`
`SR_ENG_ADMIN`	Engineering Admin	`APP_FORGE_ADMIN`, `APP_PIPE_ADMIN`, `APP_VAULT_ADMIN`
`SR_DATA_ANALYST`	Data Analyst	`APP_INSIGHT_USER`, `APP_LUMEN_READER`
`SR_FIN_OPERATOR`	Finance Operator	`APP_LEDGER_USER`, `APP_INSIGHT_READER`
`SR_HR_OPERATOR`	HR Operator	`APP_TEMPO_USER`, `APP_ATLAS_USER`
`SR_SALES_OPERATOR`	Sales Operator	`APP_BEACON_USER`, `APP_PULSE_USER`
`SR_MKTG_CREATOR`	Marketing Creator	`APP_SPEC_EDITOR`, `APP_VOYAGER_EDITOR`
`SR_SEC_OPERATOR`	Security Operator	`APP_SENT_USER`, `APP_CITADEL_USER`, `APP_VAULT_READER`
`SR_PRIV_ACCESS`	Privileged Access	`APP_CITADEL_ADMIN`, `APP_VAULT_ADMIN`, `APP_SENT_ADMIN`

Cross-Cutting Groups

Business role groups:

BR_HR
BR_FINANCE
BR_IT
BR_ENGINEERING
BR_SALES
BR_MARKETING
BR_OPERATIONS
BR_LEGAL
BR_CUSTOMERSUPPORT

Distribution-list-shaped groups:

DL_ALLSTAFF
DL_LEADERSHIP
DL_ENGINEERING

Group Metadata

Each created group should use:

description: human-readable label plus optional type tag such as [TYPE:DL]

or [TYPE:SYSTEMROLE].

info: richer notes, including the catalog marker and intended system-role

includes where relevant.

Recommended marker:

[OIM-SANDBOX-SEED:ad-shop-seeding:v1]

Seeder Implementation Proposal

Implementation path:

scripts/sandbox/seed/Invoke-AdShopSeed.ps1

Catalog path:

projects/identity-management/ad-shop-seeding/data/ad-shop-catalog.json

Behavior:

Idempotent: create missing OUs/groups, leave existing objects in place.
Non-destructive: no delete/reset behavior in v1.
Convergent only for owned fields: update description and info when they

drift from catalog values.

Dry-run support: -WhatIf.
Machine-readable output: -Json with _v, catalogVersion, summary, and

object-level results.

One lock per run via Invoke-WithSandboxLock.
One audit record per run in coordination/sandbox-audit.log.

Preflight validations:

Duplicate sAMAccountName values.
sAMAccountName length over 20.
Invalid AD name characters.
System role includes references that do not exist in generated app groups.
Missing parent OU references.
Missing AdAdmin credential.
WinRM reachability to im.sandbox.local.

Execution channel:

1. Preferred: WinRM Invoke-Command to im.sandbox.local with AdAdmin.

2. Fallback: direct AD LDAPS with System.DirectoryServices.Protocols.

3. Manual fallback: Viktor runs the seeder on the host.

Current workstation state: TrustedHosts is fixed and Get-OimHealth can read

remote services from im.sandbox.local.

OIM Phase 2

After AD sync imports these groups into ADSGroup, a separate OIM-side plan

should cover:

1. Confirm ADS sync includes OU=OIM-Managed.

2. Publish application groups as service items through the supported ADSGroup

publication path (QER\ITShop\AutoPublish\ADSGroup in this sandbox,

including database compile if the preprocessor-relevant parameter changes)

and assign them to the existing shallow sandbox shelves.

3. Use the four coarse service categories already seeded for applications,

business-role markers, system-role bundles, and distribution-list-shaped

groups. Add per-app subcategories only after portal behavior is tested.

4. Create OIM ESet rows for the SR_* catalog entries.

5. Link each system role to its intended ADSGroup entitlements through

ESetHasEntitlement.

6. Use existing predefined products for Role entitlement assignment and

System role entitlement assignment request demos.

Review Decisions Requested

Please review and approve or adjust:

1. Excluding risk, location, and birthright groups from v1.

2. Keeping business role marker groups.

3. Adding 10 SR_* system-role-related AD groups.

4. Treating SR_* groups as AD-side bundle markers for future OIM ESet

objects, not as OIM system roles yet.

5. Keeping five application entitlement tiers for every app.

6. Using the existing IT Shop/role structures in Phase 2 rather than creating

new OneIM objects in this AD-seeding phase.

Recommendation

Approve this proposal for AD seeding v1. It gives the sandbox a clean AD group

catalog for application entitlements and future system-role demos, while

respecting the current OneIM database state: IT Shop structure exists, AD

groups are not yet shop-published, and system roles are currently empty.