azure active directory

Source: Microsoft Azure

Microsoft Azure Active Directory is described as “Microsoft’s multi-tenant cloud based directory and identity management service”.  It’s probably a fair assumption that you believe this service to be equivalent to an on premise domain (Windows Server Active Directory).

Unfortunately, while both services have similar names, they provide different services.  This difference can impact your Azure network design.

The differences

Windows Server Active Directory manages the local (on premise) identities and resources through Active Directory Domain Services (AD DS). AD DS provides access control to applications, files, printers etc. AD DS was not designed with internet based resources in mind but it has been modified over time to handle more and more of that functionality. That functionality, however, is limited and is unlikely to achieve native status.

Azure Active Directory provides identity management, securing access to cloud applications like Office365, Salesforce, Dropbox etc.  Additionally, it can be configured to connect (integrate) with an existing Windows Server AD to give organisations single sign on capability.

Azure AD is essentially an extension of the Windows Server AD.  Azure AD manages the identities in the public cloud whereas Windows Server AD manages the local (on premise) identities (and resources).

Why differentiate?

The difference between Windows Server AD and Azure AD is important but may not surface if you’re just authenticating against web based services or integrating your on premise network with Azure. It will surface if you’re trying to setup an Azure network with Virtual Machines (VMs) and expecting Azure AD to act like Windows Server AD.

As we’ve discovered, Azure AD does not provide the same services as Windows Server AD so an alternative strategy is needed. To my knowledge, there are 3 options:

  • create an Azure VM dedicated to providing Windows Server AD services to an Azure virtual network
  • create a site-to-site VPN and install a replica AD Domain Controller on an Azure VM (extending the internal network)
  • install an AD Domain Controller on every Azure VM. This assumes the VM will be standalone, e.g. a self-contained development server

In the interest of brevity, I’m going to skip over the site-to-site VPN as this requires a more detailed discussion.

As you’ve come to expect, every choice in IT comes with pros and cons. The following lists some of the considerations:

Dedicated AD DS Virtual Machine

  1. Increased running costs as the VM needs to be running when the other Azure network VMs are running. This could potentially be 24/7.
  2. Increased overhead of managing the running state of the VM in conjunction with the other network VMs.
  3. Increased overhead of managing a dedicated AD DS.

AD DS on every VM

  1. AD DS needs to be installed every time a VM is created.
  2. Faster disks, therefore higher running costs, may be required if there are multiple applications running on the server, e.g. Microsoft SQL Server. (N.B. Microsoft SQL Server installed on a Domain Controller is not supported; however this may be not be an issue for a development environment.)
  3. Need to configure AD and users for every VM. (This can be overcome with PowerShell scripts.)
  4. Lower running costs as the VM can be shut down at any time. This includes manually or scheduled.

Design decision

Before deciding on which option to choose, it’s important to consider the longer term needs of the environment being created. If you have global users that access the Azure VMs at any time, then it makes sense to have a dedicated AD Domain Controller.  However, if you have users in one time zone using the VMs then there are multiple options depending on the level of automation (scheduled start/stop of multiple VMs including the DC) and running costs.