I'm the only IT person for a company of about 15 employees. Production users and roughly 25 development or lab VMs currently share the same Active Directory domain and Entra ID tenant. Two domain controllers provide identity, DNS, DHCP, GPOs, certificate services, and Entra Connect synchronization across several VLANs.
We want to reduce the production blast radius by moving regular users toward Entra ID while running development in a separate environment: possibly one Windows Server 2025 domain controller, with DHCP and perhaps DNS on Linux. The difficult part is that the same employees still need to sign in to the development machines.
Has anyone implemented something similar in a small organization? What is the practical way to let Entra-based users access computers joined to a separate development domain? Would a separate AD domain or Entra tenant be worthwhile, or would it create too much administrative overhead? I'm especially interested in what tends to go wrong with GPO, DNS, DHCP, certificate testing, synchronization, and recovery. Backups would be our main safety net.
3 Answers
A completely separate production and development domain is possible, but it adds a lot of identity and administration work for a one-person IT team. You would need to decide whether development accounts are synchronized to the same Entra tenant, synchronized to a separate tenant, or kept entirely separate. Users would not automatically be able to use their cloud credentials on machines in an unrelated AD domain without some integration, such as separate accounts, a trust, or a purpose-built identity bridge.
A more manageable approach may be to keep the existing domain and create clearly separated development OUs, accounts, groups, and administrative roles. Scope development GPOs only to those OUs, block inheritance where appropriate, and use security filtering and change controls so experiments cannot affect production. Development objects can also be excluded from Entra Connect if they do not need to appear in the cloud directory. This is less isolated than a second domain, but probably a better fit for a small team.
The main reason I’m considering a split is that we test GPO, DNS, DHCP, and certificate changes on the same domain controllers that production relies on. If we stay in one domain, I’d want development OUs excluded from synchronization and protected with strict GPO scoping rather than relying only on backups.
If strong isolation is the goal, use a separate development domain such as dev.example.com and keep production as the primary domain. A separate Entra tenant can provide even more separation, but it also means duplicating users, licenses, policies, security settings, and operational processes. For a 15-person organization, a separate domain in the same tenant—or a carefully controlled OU-based lab—may provide most of the benefit without creating two full environments to maintain.
Do not treat backups as the only protection. Test restores, keep a known-good domain controller or recovery plan, separate administrative accounts, and make sure the lab has independent DNS and DHCP behavior before experimenting with production services.
First clarify whether users need to sign in to the development computers themselves or only access development applications. Application access may be easier through SAML or another identity provider, while interactive Windows logon to a separate AD domain generally requires accounts in that domain, a trust, synchronization, or an agent that supports cloud authentication. Entra ID credentials do not automatically authenticate against an unrelated on-premises AD domain.
Some small companies use a completely separate domain name and even a separate cloud tenant for development because it makes testing identity, policies, and configuration changes safer. It works well, but duplicating settings and maintaining two environments is a significant ongoing responsibility.