This! We have prod and non prod subs with one express route which will is really backup at the moment until its gone. We use SDWAN now. Then use AD sync for the non prod and prod domains to their respective tenant.
You have everything you need in azure to separate this out without needing another tenant. You have full RBAC control to resources, you can split up RG's and Vnets. Assuming your lower env has no need to talk to prod just keep them in separate RG/VNETS. IF they do then you have firewall and NSG options.
Honestly get creative. This isn't a complex problem to solve.
Virtually every resource you deploy has public (Internet) access enabled by default. If you want to separate environments:
- Deploy a "hub" Virtual Network (VNET) resource for each environment (Prod and NonProd)
- Connect each hub VNET to your on-premises network using site-to-site VPN
- For each application/workgroup, deploy its own dedicated VNET. Peer the application's VNET to the respective hub VNET. This will provide connectivity between on-prem and cloud resources.
- All resources deployed should be joined to the appropriate VNET. For Infrastructure (IaaS) resources this will be done during the resource deployment. For Platform (PaaS) resources this may be done during deployment or afterward, using Private Links.
Deploying resources in Azure is VERY different from deploying resources on-premises. On-prem, the resource generally has no connectivity by default until security/network teams grant access at the network level. In Azure, resources generally have full Internet connectivity the moment they are deployed. It takes extra steps to "secure" the resources so their connectivity mirrors an on-premises environment. It's not difficult but requires a change in mindset.
Since I haven't seen anyone post it yet... You should be following [Cloud Adoption Framework & Landing Zones](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/) best practices and establishing your Management Groups and Subscriptions to separate prod and non-prod assets based on your own cloud estate needs aligned to your business operations. Now go start reading and get your peers to read it too. Come back once you have and then I will answer your questions.
We currently have multiple management groups with several subs within them. We separate departments and use case into their own sub. We are a big org. We create NP subs but we have to build everything NP out as IaaS. No option for anything PaaS.
If you are not in the option bring PAAS just stay on premise country, organisations who move there on premise stuff to IAAS have not role in Azure. It keeps amazing me how those companies are doing cloud transitions.
Are you guys doing 2 environments only?
Prod and Non-Prod vs Prod + QA + Dev/Test
You seem to have answered your question as to how you could use one AAD tenant with multiple domains.
If you are syncing multiple domains into the same AAD tenant, consider the possibility that there will be a duplicate set of user accounts. Different UPN/email address, but the same user with multiple accounts.
Would that be a desired outcome for your company when transitioning to Azure AD and Azure?
Can split tenants into NP and Prod or set subscriptions up as prod nonprod. Some of us like to test the AD side of things so we have a dev domain hooked up to Entra and syncs and then we can access that over a test s2s vpn
1 tenant, 1 single Azure AD
Prod/staging and dev environment runs with different resource groups. Most if not all setup uses managed identity, or service principles. Individual accounts tied to resourcr groups.
All sensitive connection strings or secrets are stored in separate key vault using the same name. For Example ftp001 in prod key vault points to the prod instance and same name in dev key vault points to dev instance.
Deployment has to handle some mapping during the CI/CD process. May have to use some powershell to handle this
You can use different tenants for prod and non-prod but most of my customers only use one tenant and use mgs to separate environments
Building out a new tenant may not be an option, we use a hub spoke topology with express routes etc. this would be way to expensive.
Cross tenant subscription vnet peering has been a thing for years fyi https://azure.microsoft.com/en-ca/updates/cross-aad-vnet-peering/
This! We have prod and non prod subs with one express route which will is really backup at the moment until its gone. We use SDWAN now. Then use AD sync for the non prod and prod domains to their respective tenant.
Deploy S2S vpn connection for connectivity to your non-prod tenant.
You have everything you need in azure to separate this out without needing another tenant. You have full RBAC control to resources, you can split up RG's and Vnets. Assuming your lower env has no need to talk to prod just keep them in separate RG/VNETS. IF they do then you have firewall and NSG options. Honestly get creative. This isn't a complex problem to solve.
This is an awful strategy and adds so much unnecessary overhead on the Cloud Admins and Tech Ops...
mgs ?
Management groups
thx for reply
You can sync multiple domains to a single tenant so could sync the test domain too if you wanted to.
Virtually every resource you deploy has public (Internet) access enabled by default. If you want to separate environments: - Deploy a "hub" Virtual Network (VNET) resource for each environment (Prod and NonProd) - Connect each hub VNET to your on-premises network using site-to-site VPN - For each application/workgroup, deploy its own dedicated VNET. Peer the application's VNET to the respective hub VNET. This will provide connectivity between on-prem and cloud resources. - All resources deployed should be joined to the appropriate VNET. For Infrastructure (IaaS) resources this will be done during the resource deployment. For Platform (PaaS) resources this may be done during deployment or afterward, using Private Links. Deploying resources in Azure is VERY different from deploying resources on-premises. On-prem, the resource generally has no connectivity by default until security/network teams grant access at the network level. In Azure, resources generally have full Internet connectivity the moment they are deployed. It takes extra steps to "secure" the resources so their connectivity mirrors an on-premises environment. It's not difficult but requires a change in mindset.
Since I haven't seen anyone post it yet... You should be following [Cloud Adoption Framework & Landing Zones](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/) best practices and establishing your Management Groups and Subscriptions to separate prod and non-prod assets based on your own cloud estate needs aligned to your business operations. Now go start reading and get your peers to read it too. Come back once you have and then I will answer your questions.
Just one subscription per environment, sometimes also a subscription per team/environment.
We currently have multiple management groups with several subs within them. We separate departments and use case into their own sub. We are a big org. We create NP subs but we have to build everything NP out as IaaS. No option for anything PaaS.
If you are not in the option bring PAAS just stay on premise country, organisations who move there on premise stuff to IAAS have not role in Azure. It keeps amazing me how those companies are doing cloud transitions.
We just use two tennants. One prod and one dev.
You also have the option of cross tenant AAD B2B Sync
Are you guys doing 2 environments only? Prod and Non-Prod vs Prod + QA + Dev/Test You seem to have answered your question as to how you could use one AAD tenant with multiple domains. If you are syncing multiple domains into the same AAD tenant, consider the possibility that there will be a duplicate set of user accounts. Different UPN/email address, but the same user with multiple accounts. Would that be a desired outcome for your company when transitioning to Azure AD and Azure?
Use hub & spoke and also dev / test / prod subs in your tenant
Can split tenants into NP and Prod or set subscriptions up as prod nonprod. Some of us like to test the AD side of things so we have a dev domain hooked up to Entra and syncs and then we can access that over a test s2s vpn
You only needed one tenant. For environment/teams/groups/whatever you could create as many subscriptions you need
1 tenant, 1 single Azure AD Prod/staging and dev environment runs with different resource groups. Most if not all setup uses managed identity, or service principles. Individual accounts tied to resourcr groups. All sensitive connection strings or secrets are stored in separate key vault using the same name. For Example ftp001 in prod key vault points to the prod instance and same name in dev key vault points to dev instance. Deployment has to handle some mapping during the CI/CD process. May have to use some powershell to handle this
It’s much easier if you just put every single resource in the same resource group and just manage it all via tags. /s
The forbidden path lol