Architecting Directory and Domain services for Azure Infrastructure

The following is a walkthrough of several options available in architecting directory management and domain services in an Azure infrastructure model.

Dependent on the scenarios, and how Azure is utilized, in my opinion, directory services in Azure can be categorized into these three basic scenarios.

• As a separate directory. Limited to a few users primarily to access the portal and its resources for isolated testing and development.
• As a separate isolated directory and identity management service in Azure for Azure SaaS and other third-party applications with Azure only users.
• As an extension or clone of your current directory system in the cloud with identity management for Azure, other third-party SaaS applications and/or other on-prem applications with the use of the application proxy.

Scenario 1

In this Scenario, Azure would be used as an isolated testing environment or development environment. You could utilize a pay as you go account with all the users designated into .onmicrosoft.com domain.

Any virtual machines built in Azure would be used as a testing environment with local admin accounts, unlaced to any domain, with RBAC used with simple Azure user accounts. This is the simplest form of Azure identity management.

You have the ability to extend the configuration by adding your own custom domain to Azure within Azure active directory or have users created within the domain in Azure, But not place a Domain controller or have a domain controller replicate between your on-prem and Azure sites.

This scenario would allow for isolation of resources, completely disconnected, limiting administrators and dev teams to a minimum. Furthermore, It would allow you to explore options for on-boarding. It would though restrict the ability to test applications or configurations with on-prem conditions or if the application requires an on-prem user-base.

Scenario 2

This scenario would be if an organization would want to have a separate domain for a subgroup of its users/customers/partners that are managed in the cloud, that can be given access to SaaS apps within Azure or apps outside of Azure.

Populating the directory could be dictated in two ways. The first, which is similar to scenario 1 is one in which users are added to Azure AD as Azure only users, The second is where a domain controller on-premise, with external/partner/customers sync with Azure active directory with Azure Ad connect.

These users can utilize Azure application gallery to access Azures SaaS applications and other third-party applications with single sign-on. You also have the option of using Application proxy to access on-prem applications without opening up your on-prem network to external users.

Infrastructure builds in the scenario could be administered by local admins with permissions controlled by RBAC with, or without a domain controller as a VM in Azure.

Scenario 3

This scenario would be either a lift and shift scenario or a hybrid scenario where you extend your on-prem data center to the cloud.

In such a scenario you have the option to:

• Use Azure AD connect and sync up your current directory with Azure AD.
• keep Azure AD separate but configure a Virtual Machine that acts as a domain controller in Azure, that replicates across a site to site VPN connection or express route with your on-prem Domain Controller.

This second option would allow you to have the full functionality of active directory and domain services while keeping Azure AD only for administration.

You would need to consider your management structure in how you would break up resource groups and virtual networks for such a scenario. a hub and spoke design with Vnet peering is one option to utilize when a virtual machine is acting as a domain controller.

The downside to this is, that while you gain control of running your own domain controller and active directory in Azure via a virtual machine, You will have the responsibility of maintaining, updating and securing these virtual machines.

The other option in this scenario is to utilize Azure domain services with Azure active directory syncing with your on-prem directory. This way you of load two key functions of the Azure domain controller VM to Azure.

Azure Domain Services provisions a managed domain and makes it available in the virtual network of your choosing. All user accounts, group memberships, and user credentials available in the respective Azure AD tenant are also available in this newly created domain, and the virtual network its designated too.

Since the domain is managed by Azure AD Domain Services, users/customers do not have domain administrator or enterprise administrator privileges on this domain.

It’s important to note that not all features available in Windows Server AD are currently available in Azure AD Domain Services.

While Azure domain services can only be implemented on to one virtual network, you have the following option of architecting your resources. It’s also important to consider other architectural boundaries such as Azure firewall service in this scenario.

You have the ability to mix and match any of these designs and features available in Azure based on what and how you plan to utilize Azure.