Domain Consolidation Plan

Purpose: Document the current state of Cirius Group's Active Directory landscape — multiple forests all sharing the NetBIOS/DNS name ciriusgroup.com — the target consolidated state, the migration path, and the explicit exceptions. Tracks ADAUD-012.

Owner: Rory (Security Officer / Architect) Audience: Security Officer, DR admins (Kevin, Greg), auditors Scope: On-prem legacy AD, Azure PROD forest, Azure DDE forest (if applicable), and three iMacros PCs with vendor-activation dependency Target completion: H2 2026 Last reviewed: April 2026

1. Current state

Cirius Group currently operates multiple distinct AD forests that happen to share the ciriusgroup.com name:

Forest	Hosting	DNS name	NetBIOS	Purpose	Trust with others?
A — On-prem legacy	Physical / legacy VM	ciriusgroup.com	CIRIUS	Legacy workloads, file services, 3× iMacros PCs	None. Historical naming collision only.
B — Azure PROD	Azure VMs ACTDIRAZP01 / ACTDIRAZP02	ciriusgroup.com	CIRIUS	Production domain for Azure PROD subscription	None (isolated forest)
C — Azure DDE	Azure VMs (DDE DC pair)	ciriusdde.com	CIRIUSDDE	Customer-facing AVD / Medicare published app	None (isolated tenant)

Key observation: Forests A and B both resolve ciriusgroup.com but have no Kerberos trust, no replication, no shared schema. Any overlap in user/computer names is coincidental and creates operational ambiguity (support tickets routed to the wrong domain, documentation that is ambiguous about which domain is meant, identity confusion at login).

Forest C (DDE) is intentionally separate by design — customer-facing, tenant isolation per hipaa-administrative-procedures.md §4.1.

Risks created by the current state

Name ambiguity — A login to user@ciriusgroup.com could hit either forest depending on DNS path
Audit ambiguity — "Access to ciriusgroup.com AD" in a log line does not disambiguate forest A vs B
Operational overhead — Two GPO sets, two SYSVOLs, two password policies, two KRBTGT rotation schedules
Legacy forest exposure — Forest A runs workloads that are no longer strategically needed except for three iMacros PCs

2. Target state

One authoritative forest for internal Cirius Group operations: Forest B (Azure PROD ciriusgroup.com). Forest C (DDE) remains separate for customer/tenant isolation. Forest A (legacy on-prem) is decommissioned except for the three iMacros PCs, which remain on an isolated segment.

Target attributes

Single source of truth for user and computer identity for internal operations
Single KRBTGT rotation schedule per forest (2 forests total: B + C)
DDE tenant remains independent; no trust proposed
Legacy on-prem forest reduced to the minimum surface required for the iMacros exception

3. Migration path

Phase 1 — Scope assessment (month 1)

[ ] Inventory every user, computer, group, GPO, and service account in Forest A
[ ] Identify which workloads still depend on Forest A (expected: 3 iMacros PCs + 1 vendor activation server)
[ ] Identify applications that authenticate against Forest A — list and rate migration complexity
[ ] Document which shares, print queues, and legacy services still live there
[ ] Produce a "keep / migrate / retire" decision per object

Phase 2 — Trust establishment (month 2)

[ ] Rename Forest A's NetBIOS to CIRIUSLEGACY and DNS name to legacy.ciriusgroup.internal via rendom.exe forest rename procedure. Test in lab before production.
[ ] Establish a one-way forest trust: Forest B trusts Forest A (so migrated objects in B can be authenticated by Forest A during transition)
[ ] Verify cross-forest authentication works for a pilot user and a pilot computer

Phase 3 — Object migration (months 3–5)

[ ] Use ADMT (Active Directory Migration Tool) or equivalent to migrate users from Forest A to Forest B, preserving SID history for file-permission continuity
[ ] Migrate computers group by group, confirming application connectivity after each batch
[ ] Migrate groups and GPOs; re-link GPOs at the OU structure in Forest B
[ ] Reconcile service accounts — prefer gMSA in Forest B where feasible
[ ] Each migrated computer/user tracked on a SecOps story for rollback

Phase 4 — Decommission (month 6)

[ ] Remove the one-way trust
[ ] Shut down Forest A DCs (but keep VMs/images for 90-day rollback window)
[ ] Confirm no applications still authenticate against Forest A
[ ] Reclaim Forest A's resource footprint; update security/cmdb-guide.md
[ ] Update this plan with completion date and write a closure note

4. Exception — iMacros PCs

Three PCs run iMacros automation against a vendor website. The vendor's activation mechanism is offline / LAN-only and points at a vendor activation server that cannot move to Azure PROD. These PCs:

Remain on Forest A indefinitely (beyond the general decommission date)
Are isolated on a dedicated VLAN with strict egress (no ePHI routes)
Have Cortex XDR agents + Arctic Wolf coverage
Are reviewed quarterly to determine whether the vendor has released an activation mechanism that would allow migration (documented as a recurring check in runbooks/admin-account-hygiene.md)
Are NOT migrated as part of this plan

Risk acceptance: The vendor-activation dependency creates a forever-legacy pocket. Accepted because:

Workload is non-PHI (iMacros output lives in a non-PHI SharePoint location)
Network isolation limits blast radius
Scheduled decommission target: when the vendor offers a modern activation path OR when iMacros automation itself is retired

5. Risks and mitigations

Risk	Likelihood	Impact	Mitigation
Forest rename (rendom) fails in production	LOW	HIGH	Lab rehearsal, full backup before change, rollback within 1 business day
Trust establishment breaks existing auth	LOW	MEDIUM	Trust is one-way and additive; existing auth paths remain intact
SID history migration loses file ACLs	LOW	MEDIUM	ADMT preserves SID history when configured correctly; pilot migration validates
iMacros PCs become unmanaged after Forest A retirement	MEDIUM	MEDIUM	Explicit exception documented here; quarterly review
Credential rotation during migration drops sessions	MEDIUM	LOW	Schedule migration batches outside business hours

6. Timeline

Month	Milestone
July 2026	Phase 1 complete — scope assessment
August 2026	Phase 2 complete — trust established
September–November 2026	Phase 3 — object migration in batches
December 2026	Phase 4 — Forest A decommissioned (except iMacros PCs)
January 2027	Post-migration audit; `security/cmdb-guide.md` + this plan updated

7. Cross-references

security/cmdb-guide.md — asset inventory affected by this migration
security/lpriv-baseline.md — least-privilege baseline will need re-verification after migration
runbooks/admin-account-hygiene.md — quarterly check includes iMacros PC exception review
compliance/hipaa-administrative-procedures.md §4.1 — tenant isolation for DDE
compliance/compliance-scorecard.md row 41 — tenant isolation control

Document history

Date	Change	Author
April 2026	Initial consolidation plan with iMacros PC exception	Kobe

Domain Consolidation Plan ​

1. Current state ​

Risks created by the current state ​

2. Target state ​

Target attributes ​

3. Migration path ​

Phase 1 — Scope assessment (month 1) ​

Phase 2 — Trust establishment (month 2) ​

Phase 3 — Object migration (months 3–5) ​

Phase 4 — Decommission (month 6) ​

4. Exception — iMacros PCs ​

5. Risks and mitigations ​

6. Timeline ​

7. Cross-references ​

Document history ​