When you buy through affiliate links in our content, we may earn a commission at no extra cost to you. Learn 
I was talking with the technology director of a fairly good size public school system the other day who was conveying his frustration over Microsoft Azure Active Directory. They had been recently assigned a team of SMEs on the subject to help guide them through an Azure AD implementation. After several conference calls, the director abandoned the partnership with the “experts” as he figured out they didn’t know much more than he did already. “I can read the TechNet articles just as easily as they can,” he quipped.
This is not that surprising as there is a lot of confusion concerning the integration of Azure AD and on-premise AD within a hybrid cloud environment. Usually the initial assumption is that Azure AD is simply a replica version of the traditional Server AD that simply resides in the cloud. This is why there are so many clichés about assuming things. (For a comparison of cloud services, see The Four Major Cloud Players: Pros and Cons.)
The Different Environments of Azure AD and Server AD
The fact is that these two versions of AD have almost as many differences as they do similarities. That’s because they are each built around a different environment.
When IT professionals refer to AD, they are referring to the traditional AD we have all grown accustomed to over the years that resides on the physical plane. Server AD is built around the principles of organization, manageability and policy. We take our domain and segregate it into smaller, more manageable organizational units where users and computers that share commonality reside. Perhaps your AD is divided up by physical locations or by job function. Both users and their respective computers take part in the authorization process as they log on to domain controllers using LDAP and access physical resources using Kerberos tickets. Applications are birthed from ISO files and Group Policy locks down desktops and settings for users.
And then there is Azure. Azure was constructed for the cloud, which means it is designed specifically to support web services.The cloud is about elasticity, agility and perpetual alteration. Azure is a flat structure void of organizational units and Group Policy objects, a structure in which location is irrelevant. In fact, Azure is a vast ocean of objects all congregated into one humongous container. It’s a place in which applications are services, extensions of the users themselves. Applications in this environment are simply assigned rather than installed. While traditional AD is known for making the user experience as managed and controlled as possible, Azure AD is about making the user experience as fluid as possible.
The Commonalities Between Azure AD and Server AD
So, Azure AD is not intended to be the cloud version of Server AD. It was constructed to augment it as traditional AD was never built to support the world of web-based internet services. So let’s start with the similarities between the two.
Like its predecessor, Azure AD hosts users and groups. In a hybrid cloud environment, AD admins can create users within their local on-premise AD and have them synchronized to Azure by an intermediary tool called Azure AD Connect which offers some great added features.
- Password Synchronization – Since users and groups are synchronized to Azure AD, users can log on both on-premise and in the cloud, as passwords are synchronized between the two. Since on-premise is designated as the authority, Azure AD utilizes the local password policy as well.
- Password Writeback – Users can change their passwords within Azure AD and have them written back to on-premise. This is a fantastic feature for an organization such as a school system where teachers and staff passwords expire over the summer. Rather than being locked out of their email and internet access until they can return to work to change their password at their desk, they can do it from home in Azure AD at any time.
- Filter Synchronization – This allows admins to choose exactly which objects are synchronized to the cloud and which ones aren’t.
How They’re Different
While users and groups can coexist within Azure AD and Server AD simultaneously, that is not the case for computer accounts. Azure does not offer the “domain join” feature that we have grown accustomed to. That is because Azure is about the web, an environment void of the traditional authentication protocols such as LDAP and Kerberos, but instead relies on web authentication protocols such as SAML, WS, Graph API and OAuth 2.0. Computers are connected to Azure. What this means is that computer accounts can either reside on-premise or in the cloud, but not both. (To learn about some of the biggest problems in managing Active Directory, see The Top Five Active Directory Management Pain Points.)
This isn’t as big a deal as it seems, however, as many organizations today actually have two types of computer fleets such as desktops and mobile devices. In this scenario, mobile devices could reside within Azure while desktops reside on-premise. K–12 educational institutions that offer one-to-one laptop provisioning for students are a good fit as well for Azure, as thousands of laptops are reimaged at the end of every year, making them ideal candidates for Azure.
As mentioned, Azure AD has no Group Policy functionality, however, Azure devices can be managed by Microsoft Intune, which offers features such as update management and remote wipe should a device become compromised. Furthermore, Intune can be integrated with Microsoft SCCM to provide more granular device management.
Azure AD Makes Life Easier for All Users Through IDaaS
The bottom line is this: Server AD is first and foremost a directory service solution while Azure AD, which has some directory service capabilities, is an identity solution. Identity management wasn’t an issue when Server AD was conceived, but is a critical element for today’s organizations.
Users within just about any organization today utilize numerous cloud applications such as Office 365, Facebook, Saleforce.com, Dropbox, etc. When cloud applications first came to fruition, users had to authenticate into each and every application, which proved very inefficient and introduced security vulnerabilities as users had to manage multiple passwords in some cases, as cloud application vendors enforced different password policies.
Then came Federated Services which offered single sign-on or SSO. Initially this meant that the cloud application would divert the authentication process back to the user’s on-premise AD where a configured federated server would authenticate the user according to their local AD credentials. This made it easier for the user, but required a great deal of manual configuration for the IT teams, as a federated relationship had to be established for each and every application vendor.
And then came Identity as a Service (IDaaS) which is what Azure AD is all about. Azure AD handles the federation for hundreds of applications itself, allowing Azure AD users the ability to seamlessly jump from application to application almost as easily as traversing applications on their desktop. In a sense, Azure AD is a federation hub.
In addition, Azure AD offers organizations the ability to host a virtual domain controller in the cloud, offering users mobile authentication as well as redundancy in the instance of a total on-premise failure. Yes, Azure AD and Server AD do not replicate each other’s services, instead, they complement them, offering the best of both worlds to users today.
