It seems like a simple question: 

does Azure Active Directory (AAD) replace Windows server Active Directory ?  

1. Azure Active Directory (AAD) as the successor to Active Directory (AD)
2. Authentication and Authorization
   1. Active Directory and Computer Authentication
   2. Azure Active Directory and Computer Authentication
3. AAD Advantages over AD
4. Mobile Device Management (MDM) and Group Policy
5. AAD as the AD Replacement
   1. A Cloud Based AD Equivalent
6. Azure Virtual Private Network (VPN) Gateway

Azure Active Directory (AAD) as the Successor to Active Directory

An Azure-based replacement for an internally based active directory would seem to be logical progression.  Microsoft product effort continues to focus on supporting and cultivating a cloud hosted IT infrastructure.  Consider the movement of capabilities away from the enterprise hosted datacenter.

The Windows server operating system offers a comprehensive IT ecosystem.  Active Directory provides the entry way for authentication and authorization.  It provides the way to determine who received access to the endpoints and server resources with a single sign-in.  It provides a means to determine what you can do, if anything, in the server-based applications like the file server, an IIS-based website, terminal server and other server hosted applications.  It provides the access tokens that determines what you can do in non-server applications like Exchange and SharePoint.  Back in the day everything your organization did ran on one of your servers.  Sure, users made occasional jaunts to the Internet for information, but there wasn’t a lot of processing happening out there.

What happened next was equivalent to the implosion of downtown shopping that occurred starting in the 1970’s.  Vibrant urban areas that had been the hub for shoppers for decades steadily vacated for malls on the edges of cities.  The malls were much more convenient.  Parking was easy.  You had lots of shops in close vicinity of each other.  Weather, once you got inside from the parking lot, wasn’t an issue.  For the merchants, the buildings were new and had lower maintenance cost.  

Like so many inner city merchants, key applications began to migrate to servers outside the organization.  Those servers were maintained by staff that could provide a service level that was difficult for internal staff to match.  And could usually do it for less.  They were doing the service at a scale most companies could not match.

The internal websites hosted in IIS were the first to pack up and leave.  Email that wasn’t Exchange usually was not far behind.  Office 365 (now Microsoft 365) sped the departure of Exchange and SharePoint as well.  Dropbox, One Drive and SharePoint (over a One Drive infrastructure) undercut file serving. With inclusion of Windows Virtual Device in the Microsoft 365 Business subscriptions, terminal server is teetering as a viable internally hosted application.

With so much of what Windows Server did moving to external servers, it would follow that the authentication and authorization function would be moving out.  Azure Active Directory, by it’s name alone, suggests that it would be the destination.

Not quite.  Or at least not quite yet.  If Active Directory could talk, it would say, like Mark Twain, ”the reports of my death are greatly exaggerated.  What AD does that AAD doesn’t do  comes down to the primary function of both active directory offerings:  authentication and authorization.  This is most clearly experienced with computers as endpoints.

Authentication and Authorization

Authorization reduces to granting access to resources.  The three elements are:

1. What you know (like a user ID and password)
2. What you have (like a smart card or phone with an app that provides authenticator tokens or receives texts with PINs)
3. Who you are (like a fingerprint or retina scan)

AD and AAD centrally manage ‘what you know’ well.  The endpoints must connect to AD and/or AAD to perform authentication.  Here’s where the divergence occurs.  

Active Directory and Computer Authentication

For AD, the endpoint is a computer with a Windows or Mac desktop operating system .  (noted:  Linux can be joined with varying impact on subsequent authorization).  Prior to adding a computer to AD, the computer has access to the network using DHCP to determine the DNS server and the gateway.  To use other internal server-based resources (think file server, for example), you need to be authenticated before access is authorized. 

A user must be authenticated to access the endpoint itself before authorization to access server resources occurs.  The endpoint can be setup with a local user profile.  The local user profile (or profiles) reside only on the endpoint.  You can’t go to another computer in the organization and use the login.  That is, you can’t unless the exact same profile has been setup on the other computer.  If it hasn’t, then the other computer knows nothing of the local profile.  To change a password on the local endpoint, you have to do that on the local machine.  No central management.  Unless the profile on the local computer was added to whatever authorizes access to the resource you want, the local only user cannot access the resource. 

AD solves this when you join the computer to the domain.  When you join the domain, the joined computer can query all the users configured in active directory for authentication at login.  Any user in the domain can use their user name and password to login to the computer.  in fact, any user can login to any computer connected to the domain.  Changes to passwords made on the server now work for authorization to use the local endpoint.  Having used the AD profile to access the endpoint, the user authentication now enables authorization to use the resource.

For those unfamiliar with joining a computer to a domain:  

1. Use a local profile with administrator privileges
2. Connect the computer to the network where the AD server resides
3. Using the ‘To rename this computer or change its domain or workgroup’ option under the Settings> About>(Related settings) Rename this PC (advanced), enter the domain
4. Authenticate with a domain administrator user ID and password
5. Reboot

After the reboot, the domain credentials for the user can be used.  A new domain computer will be created.

After joining the domain and logging in with a domain profile, AD applies group policies (GP) that configure how the computer will operate.  Group policies can:

• determine login behavior. 
• configure applications like the Windows Firewall. 
• perform limited application installation. 
• enforce custom behavior across workstations.

AAD does not directly provide a group policy equivalent.  A mobile device management (MDM) system such as InTune, can provide some similar capacity.

Azure Active Directory and Computer Authentication

AAD does enable devices to join the AAD domain, but the device is not its own entity.  What is different is that AAD creates an association between the user and the computer.  Like AD, AAD can provide, after login on a computer, authorization for the user associated with the device.  What it does not do is affect the login to the device.  

Like AD, AAD provides the means to authorize use of services after AAD authentication.  You can add non-Microsoft apps such as Dropbox or Amazon Web Services.  You add an Enterprise App using New Application under Enterprise Apps in the Azure AD portal.  By completing the configuration of the link, you provide single-sign on (SSO) access to the other application.  Once the user has authenticated to Azure, Azure enables the authorization to use the application.  The other application must provide a login page to which Azure AD can connect.  This extends the reach of AAD authentication beyond the limited intra-domain authorization provided in AD.

AD can extend its reach working in conjunction with AAD.  Azure Connect can enable the local AD instance to sync to AAD.  Once synced, the cloud-based services can be added to AAD. With the sync created by Azure Connect, the user names, passwords and enabling/disabling now occurs in AD. 

A user must still authenticate to AAD.  If the user has logged into their computer and it is joined to AAD, the authentication is done.  The user can enjoy the authorizations granted after authentication.

AAD Advantages over AD

Notice the use of ‘device’ for AAD rather than ‘computer’ for AD.  AAD will enable phones and tablets to join, along with a user, the AAD.  For AD, the device is a computer.

There are two methods for adding a user and device to an AAD.  The first is to associate the user and device with AAD.  The second method is to join.  After the device, and the user who is associated with the device, is added to AAD, the device can be recorded in a mobile device management (MDM) system such as InTune.  The method (association or joining) by which the device was added determines how the MDM interacts with the device.

Returning to the authentication task, AAD provides a means for multifactor authentication.  When joining an AAD controlled resource from a new device, the login can be supplemented with an additional authentication step.  Examples are sending a text to the pre-defined phone, or accepting a PIN from an authenticator app. AD, on its own, cannot provide this layer of authentication protection.

Mobile Device Management (MDM) and Group Policy

Associated devices are generally bring your own device (BYOD) and are owned by the user.  Joined devices are usually company owned.  The MDM for a BYOD device may review the device for compliance with corporate security standards before granting authorizing access to company resources.  For a joined device, it may enforce the standard.  For a BYOD device, the company data may be wiped from the device.  For joined devices, the entire device may be wiped.

Like group policy in AD, the MDM may enforce configuration of the joined devices.  The MDM goes further than GP by enabling the wiping and restoring of a device.  

AAD as the AD Replacement

So what are the roles for AD and AAD in an organization?  

AD provides organizational profiles and logins for company owned computers.  A computer joined to AD can be configured using group policy.  AD provides authorization to domain resources.  If configured using Azure Connect, AD can work in conjunction with AAD to provide authorization for cloud resources.

AAD provides authorization for joined devices.  The devices can be company or personally owned computers, tablets and phones.  AAD does NOT provide computer login requirements and authentication for access to a computer or any other device.  Using an MDM system, the MDM can provide group policy-like capabilities.  The MDM has features that AD and group policy do not, like the ability to wipe or reset the device.  

And to the original question, with a modification:  is Azure AD (with an MDM system) the death of active directory?  As long as an organization:

1. has company owned computers as endpoints
2. on which company control of the login credentials matter,

the answer is ‘no’.  What does a ‘yes’ answer look like?

1. All the endpoints are BYOD computers,
2. There are no computers – just tablets and phones
3. Having centralized password and/or profile control on the computer endpoint does not matter.  For example, the computer connects to a Windows Virtual Device in Azure.  The connection is all the computer does.  As long as the endpoint meets the password requirements for the local profile, that is enough.

A Cloud Based Active Directory Equivalent

There are non-Microsoft alternatives to create a domain-less environment.  The solutions are cloud-based directory services.  In that sense, the domain controller is moved to the cloud.  The cloud-based directory alternatives solve the computer login issue.  A provider who has a whitepaper that addresses the issues and solution is Jump Cloud.

Azure Virtual Private Network (VPN) Gateway

One other possibility I hear is to connect to Azure using Azure VPN Gateway, and run an AD server there for local workstations.  DHCP and DNS is handled by another device.  Rules in the VPN connection allow the polling for an AD server.  Would this work?

The cost may be prohibitive.  In Azure, to construct the site-to-site connection, you need:

• An AD server.  Best practices require at least a single backup server
• An Azure VPN Gateway, which consists of two virtual machines to handle the Internet protocol security (IPSec) and Internet key exchange (IKE).  Two virtual machines are required.

You would be charged for four virtual machines.  Azure charges for the traffic out of the virtual network for the AD server and Azure gateway.

The benefits of the configuration are:

1. You don’t have to manage the hardware and configuration in a local location
2. You can connect from locations other than your primary site using a point-to-site connection and enjoy the AD benefits that you would only when on site. 

The concerns are:

1. latency in polling the server.  The polling traffic is insignificant enough to not be an issue.
2. loss of connectivity.  This is an issue if you have internal services.  if, however, everything is cloud based, you’ll be unable to access anything when connectivity is interrupted.

It comes down to cost.  Preparing the configuration in the Azure cost calculator is the start.  The configuration used in the cost calculator can then be used in the Azure Total Cost of Ownership (TCO) calculator.

Two instances are good examples.

In example one, the primary site had two aging servers.  All applications had been moved to Azure or used other cloud services.  The decision was that the light duty required to use the servers for DHCP, DNS and AD would enable the servers to continue until their current OS was no longer supported.  At that point the replace or buy decision would be made.

In example two, the primary site did not have AD.  DHCP and DNS were provided by the router.  The TCO analysis showed that connecting used the Azure VPN gateway was less than purchasing two servers (even used ones) and outfitting them with operating systems and user CALs.  

Links

Roadmap to the Domainless Enterprise – JumpCloud

Moving Off-Prem in the Domainless Enterprise – JumpCloud

How JumpCloud integrates to Azure Active Directory