The similarities and differences between Microsoft Azure and Server AD are discussed in this article, as well as how Azure AD can expand the functionalities of your on-premise AD in the age of the cloud and its variety of service options.
The other day, I was speaking with the technology director of a public school system of a respectable size, and he expressed his displeasure with Microsoft Azure Active Directory.
They had recently been given a team of subject-matter experts (SMEs) to assist them in implementing Azure AD.
The director ended his collaboration with the "experts" after numerous conference calls when he realized they didn't really know much more than he did already. He chuckled, "I can read the TechNet articles just as readily as they do."
This should not come as a huge surprise given the widespread misunderstanding surrounding the combination of Azure AD with on-premise AD in a hybrid cloud context.
Typically, the initial assumption is that Azure AD is just a cloud-based duplicate of the conventional Server AD. This explains why the subject of assumptions is so overused.
(See The Four Major Cloud Players: Pros and Cons for a comparison of cloud services.)
The Various Azure AD and Server AD Environments.
In actuality, there are almost as many variances between these two forms of AD as there are similarities. That's because they were each designed for a particular setting.
When IT experts talk about AD, they mean the conventional AD that exists on the physical plane and to which we have all been accustomed over time. Server AD is designed with structure, management, and policy as its guiding principles.
We take our domain and divide it into more manageable organizational segments, each of which houses users and computers with similar characteristics.
Your AD may be organized into sections based on geographical areas or job functions.
When users log on to domain controllers using LDAP and access physical resources using Kerberos tickets, both the users' computers and those computers participate in the authorization process.
Applications are created from ISO files, and Group Policy restricts user access to desktops and settings.
There is also Azure. Azure was created for the cloud, therefore it was built from the ground up to support web services.
Elasticity, agility, and constant change are key characteristics of the cloud. Azure has a flat organizational structure devoid of Group Policy objects and organizational units, where location is unimportant. In reality, Azure is a vast ocean of stuff gathered inside a mammoth vessel.
Applications there serve as services and are seen as extensions of the users themselves. In this system, applications are merely assigned rather than installed.
The goal of Azure AD is to make the user experience as fluid as possible, whereas traditional AD is notorious for making the user experience as managed and regulated as possible.
The Similarities Between Server AD and Azure AD
Therefore, Azure AD is not meant to be Server AD in the cloud. It was designed to supplement it because the world of web-based internet services was never supported by conventional AD. Therefore, let's start with their parallels.
Users and groups are hosted by Azure AD, just like its predecessor. AD administrators can establish users in their local on-premise AD in a hybrid cloud environment and have them synced to Azure using an intermediary application called Azure AD Connect, which has some fantastic extra features.
Password Synchronization – Users can log in both on-premises and in the cloud because passwords are synchronized between the two thanks to the synchronization of users and groups to Azure AD.
Azure AD also makes use of the local password policy because on-premise has been recognized as the authority.
Password Writeback – Password changes made by users can be written back to on-premise systems through Azure AD. This is a great feature for a company like a school system where the passwords for the instructors and staff expire during the summer.
They can reset their password in Azure AD from home at any time, preventing them from being locked out of their email and internet access until they can get back to work.
Filter Synchronization – This gives administrators complete control over which objects are and are not synchronized to the cloud.
How They’re Different
Users and groups can coexist simultaneously in Azure AD and Server AD, but computer accounts cannot. The "domain join" feature to which we have grown used is not available in Azure.
This is because Azure is focused on the web, an environment devoid of conventional authentication protocols like LDAP and Kerberos and dependent instead on web authentication protocols like SAML, WS, Graph API, and OAuth 2.0. Azure is accessed by computers.
This means that accounts for computers can only be stored locally or in the cloud—not both. (See The Top Five Active Directory Management Pain Points for information on some of the most significant issues with Active Directory management.)
However, given that many firms now really have two sorts of computer fleets, such as desktops and mobile devices, this isn't as big of a concern as it might first appear to be.
In this case, mobile devices might be hosted by Azure while PCs are located locally. Because hundreds of laptops are reimaged at the end of every year, K–12 educational institutions that provide pupils with one–to–one laptop provisioning are also a suitable fit for Azure.
However, Azure devices can be managed by Microsoft Intune, which includes services like update management and remote wipe should a device become compromised. As was previously mentioned, Azure AD lacks Group Policy functionality.
Additionally, Intune and Microsoft SCCM can be combined to offer more precise device management.
Azure AD Simplifies Life for All Users With IDaaS
The basic line is that although Azure AD, which has some directory service capabilities, is an identity solution, Server AD is primarily a directory service solution.
When Server AD was established, identity management was not a concern, but it is now a crucial component for enterprises.
Today, users in almost every company use a variety of cloud programs, including Office 365, Facebook, Saleforce.com, Dropbox, etc. Users had to authenticate into each and every cloud application when they first started to be developed.
This proved to be very inefficient and introduced security vulnerabilities because users had to manage multiple passwords in some cases because different password policies were enforced by cloud application vendors.
After that, Federated Services introduced SSO or single sign-on. Initially, this meant that a configured federated server would authenticate the user using their local AD credentials by redirecting the authentication process back to the user's on-premise AD.
The user experience was improved, but the IT teams had to perform a lot of manual configuration because a federated relationship had to be formed with each and every application provider.
Then Identity as a Service (IDaaS), which is the core of Azure AD, appeared. Users using Azure AD can smoothly switch between applications almost as easily as they would between desktop applications since Azure AD manages the federation for hundreds of applications on its own. Azure AD functions something like a federation hub.
Additionally, Azure AD gives businesses the option to host a virtual domain controller in the cloud, providing customers with mobile authentication and redundancy in the event of a complete failure of the on-premises system.
Yes, Server AD and Azure AD complement each other's services rather than duplicating them, giving users the best of both worlds today.
No comments:
Post a Comment