AD-to-AD Cross-Domain

Plan and track cross-domain directory work with explicit project state, source/target pairs, safety checks, and audit evidence.

The interactive demo walks through this flow with mock data. It does not call live NOBA APIs or touch customer directories.

Project Model

AD-to-AD work is organized as projects. Project types cover ongoing sync, phased migration, and acquisition/merge scenarios. Each project can define source and target directory pairs, priorities, and status transitions from planning through reconciliation, pre-flight, approval, execution, completion, and archive.

Approval has separation-of-duties protection: the project creator cannot approve their own project.

Workflow

1. Create project — Define whether the work is sync, migration, or acquisition.
2. Add pairs — Select source and target directories already configured in AD Sync.
3. Reconcile — Discover schema, group, OU, user, UPN, password-policy, and group-scope differences.
4. Pre-flight — Verify connectivity and prerequisites before write-side operations.
5. Health dashboard — Track health, drift, velocity, UX metrics, deadlines, and rollback decision signals.
6. Machine safety — Discover source-domain computers and back up LAPS passwords and BitLocker recovery keys into the vault.
7. Password status — Track pending, captured, set-on-target, policy-violation, forced-reset, passwordless, and SSPR-reset states.
8. Compliance and cleanup — Generate NIS2/SOC2-oriented evidence summaries and track the post-migration cleanup checklist.

Directory Targets

Directory connectors support LDAP / Active Directory and Azure AD / Microsoft Entra ID. LDAP machine operations require an LDAP source directory. Azure AD write operations use Microsoft Graph permissions configured for the target directory.

Safety Controls

• Project and pair operations are tenant-scoped.
• Reconciliation and pre-flight triggers are rate-limited per project.
• Reconciliation items are explicitly resolved as mapped, default, skip, transform, create, merge, or pending.
• LAPS and BitLocker backups are stored in the encrypted vault before machine cutover work.
• Rollback checks evaluate migration health signals before recommending continue, pause, or rollback decisions.
• Project creation, status changes, pair creation, reconciliation, pre-flight, machine discovery, LAPS backup, BitLocker backup, and rollback checks are audit-logged.

What to Validate During Beta

For design partners, the most useful validation is real-world directory shape: hybrid AD/Entra layouts, Samba or LDAP edge cases, OU structure differences, group-scope conflicts, password policy mismatches, LAPS/BitLocker coverage, and compliance-evidence expectations. See the validation topology for what has already been exercised in our own remote lab. NOBA should be tested with a dry run and explicit rollback plan before production cutover.