I'm a one-person IT team supporting about 15 employees. Production users and roughly 25 lab or development VMs currently share the same Active Directory domain and Entra ID tenant. We have two domain controllers, Entra Connect, and separate servers handling services such as certificate authority, DHCP, and DNS across several VLANs. The development machines rely on AD for DNS, DHCP, Group Policy, and user accounts.
I'd like to reduce the risk of experimenting in the environment that production depends on. The idea is to move production users toward Entra ID while running the development environment from a single Windows Server 2025 domain controller, with DHCP and possibly DNS hosted on Linux. However, the same employees still need to sign in to the development machines.
For a small organization, what is the practical way to let cloud-based users access computers in a separate development domain? Would a second domain or tenant be worthwhile, or would it be better to keep one domain and isolate development with separate OUs, suffixes, and policies? I'm especially interested in what tends to go wrong with GPO, DNS, DHCP, certificate testing, and Entra Connect. Backups would be available as a recovery measure.
2 Answers
If you do decide to split things, use a clearly separate namespace such as dev.example.com or another dedicated domain, rather than making production and development look interchangeable. Keep the production identity platform as the authoritative environment and treat development as disposable. You can synchronize only the accounts that need access, but remember that synchronization alone does not automatically make cloud identities valid logons in an unrelated AD domain. You may need separate AD accounts, a trust, a federation or SAML bridge, or a device-management design that supports the intended sign-in method.
A separate development domain and possibly a separate Entra tenant can work, but it adds a lot of administration for a one-person IT team. You’d need to solve identity synchronization, trust or account mapping, device enrollment, licensing, certificates, and support for two environments.
A more manageable option is to keep the existing domain and create clearly separated development OUs and accounts, using a dedicated development UPN suffix if useful. Scope development GPOs only to those OUs, block inheritance where appropriate, and use security filtering so test policies cannot apply to production computers. You can also exclude development accounts or OUs from Entra Connect if they do not need cloud access. This gives you isolation without immediately doubling the identity infrastructure.
A separate domain and tenant can be useful when you need realistic end-to-end testing, but duplicating every identity and service setting is a major burden. For a small team, strong OU boundaries, separate admin accounts, and tested backups may provide most of the benefit with much less overhead.
A second tenant with matching settings can make testing safer, but it also means maintaining two sets of policies, applications, licenses, certificates, and recovery procedures. It is usually justified for a larger team or a formal testing requirement, not just because development changes are occasionally risky.