feat(datagen): add GroupIdentity with built-in AD groups and membership

[Dylan-M]

Proposed Change

Adds GroupIdentity with a built-in AD group catalog and membership semantics.

Part of PIPE-927 common data generation package stack. Foundation for PIPE-785, PIPE-928, PIPE-943, and the rest of the simulator stack.

Checklist

• Changes are tested
• CI has passed

[Dylan-M]

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

• refactor(generators): replace embedded data pools with datagen imports across apache_combined, apache_error, nginx, paloalto, winevt #156
• docs(datagen): add documentation for identity hierarchy and seed configuration #155
• feat(datagen): add Windows process, registry, and task path pools #154
• feat(datagen): add HTTP method, path, protocol, and status code pools #153
• feat(datagen): add Environment orchestration with GenerateEnvironment #152
• feat(datagen): add ApplicationIdentity with per-role app allocation #151
• feat(datagen): add ServiceIdentity with per-role service allocation #150
• feat(datagen): add GroupIdentity with built-in AD groups and membership #149 👈 (View in Graphite)
• feat(datagen): add name pools and UserIdentity generation #148
• feat(datagen): add SystemIdentity with OS/arch/role types and version pools #147
• feat(datagen): add DomainIdentity and CertAuthority generation #146
• feat(datagen): add NetworkIdentity and IP/port/MAC generation utilities #145
• feat(datagen): add mythology hostname pools and generation functions #144
• feat(datagen): add SeedConfig with per-type seed resolution #143
• feat(datagen): add Pool[T] generic type with random selection helpers #142
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[eKuG]

I guess, GenerateGroups does not honor count when count is smaller than the built-in catalog. It always appends all built-in groups first, so GenerateGroups(seed, 5, ...) still returns 9 groups. The test even codifies this with “at least 10 groups"

[Dylan-M]

Renamed the parameter to targetTotal and rewrote the docstring: built-in AD groups (n=9) are always included; department groups append until total reaches targetTotal or the catalog is exhausted (cap at 18). Built-ins shouldn't be truncated since an AD environment without Domain Admins / Domain Users would be incoherent. Test added that exercises targetTotal < 9.

[eKuG]

Can the Domain Admins assignment pick the same user more than once because it samples with replacement? With adminCount = 2, the same SID can be appended twice to domainAdmins.MemberSIDs, and that same group SID can be appended twice to users[idx].GroupSIDs. Correct me if I'm wrong

[Dylan-M]

adminCount is now a parameter and the picker uses a Fisher-Yates partial shuffle so duplicate user SIDs can't enter MemberSIDs and a single user can't appear twice in GroupSIDs. The previous "1 if users≤10, else 2" heuristic was unrealistic — Microsoft's published guidance is qualitative ("minimize Domain Admins membership") rather than a sizing table; the new step function (2/3/5/8/15/25/35 across user-count buckets up to 10000+) tracks what audited environments commonly observe rather than best-practice. Exposed via EnvironmentOpts.DomainAdminsCount (zero = use heuristic).