The idea behind this blog series came after something I noticed Microsoft does not have from an artifact perspective. Microsoft talks a lot about infrastructure as code by using ARM Templates. ARM Templates make cloud deployments declarative, idempotent, and add increased agility related to the speed of provisioning resources in Azure. Declarative deployments scale significantly better, versus leaning on manual configurations or running a series of scripts. Microsoft maintains an Azure Quickstarts Repo on GitHub that provides a lot of starter ARM Template code to familiarize yourself with how these configuration files are structured. Additionally, Microsoft authored World Class ARM Templates, provides a best practices guide, plus an ARM Template reference. Within the Quickstarts Repo, there are a few templates that surround Active Directory Domain Services (ADDS), however they focus on building brand new forests and domains vs. customers attempting to extend their existing ADDS environment into Azure.
Before we get too ahead of ourselves, let us take a quick step back and set the stage. As cloud adoption grows, many enterprises are faced with embarking upon a digital transformation journey that may feel a bit uncomfortable and overwhelming as many decisions need to be made. Microsoft now provides a Cloud Adoption Framework that equips customers with a set of tools, guidance, and best practices that will prove helpful in ensuring continued success as more workloads adopt a cloud first mindset.
Some of the first design considerations that need to be solved for surround hybrid connectivity and identity. For hybrid network connectivity, customers can either choose to deploy a Site-to-Site VPN or procure and set up an ExpressRoute connection. For purposes of this blog series, I will encourage readers to explore the topic of hybrid network connectivity separately, as the rest of these posts will surround extending ADDS into Azure.
Historically, companies have spent a great deal of time and effort, both in building and maintaining traditional ADDS environments on-premises. With customers I have worked with previously, the topic of identity tends to become a trickier conversation when first brought up. There are several design considerations companies made many years ago using various iterations of Microsoft best practices regarding topics like the domain to forest ratio, resource forests, which forests trusted one another, the type of trusts for best security, etc., etc. Extending the domain space into Azure usually is not an easy conversation for companies that may have multiple forests, multiple one-way trusts, and identities split in between a few different domains, which tends to happen during something like merger and acquisition activities.
Determined to build something that someone could plug and play into their environment quickly vs. manually configuring domain controllers in Azure using the Azure Resource Manager (ARM) portal, I set off to create an ARM Template that deploys the following architecture:
We will be unpacking the replica domain controller build in this series over the next handful of weeks. Due to the deployment complexity, breaking this up into manageable chunks seemed like the most viable option for full understanding. So, tune in next time as I identify all pre-requisites that need to be met prior to deployment.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.