{"id":49565,"date":"2016-11-02T00:00:00","date_gmt":"2016-11-02T00:00:00","guid":{"rendered":"https:\/\/www.techopedia.com\/what-microsoft-azure-can-and-cant-do-to-help-your-on-premise-active-directory\/"},"modified":"2021-07-12T19:16:08","modified_gmt":"2021-07-12T19:16:08","slug":"what-microsoft-azure-can-and-cant-do-to-help-your-on-premise-active-directory","status":"publish","type":"post","link":"https:\/\/www.techopedia.com\/2\/31980\/trends\/what-microsoft-azure-can-and-cant-do-to-help-your-on-premise-active-directory","title":{"rendered":"What Microsoft Azure Can and Can’t Do to Help Your On-Premise Active Directory"},"content":{"rendered":"
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<\/a> Active Directory<\/a>. They had been recently assigned a team of SMEs<\/a> 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.<\/p>\n 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<\/a> 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<\/a>.)<\/p>\n 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.<\/p>\n 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<\/a> 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<\/a> using LDAP<\/a> and access physical resources using Kerberos<\/a> tickets. Applications are birthed from ISO files and Group Policy<\/a> locks down desktops and settings for users.<\/p>\n And then there is Azure. Azure was constructed for the cloud<\/a>, which means it is designed specifically to support web services<\/a>.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<\/a> as managed and controlled as possible, Azure AD is about making the user experience as fluid as possible.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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<\/a> protocols such as LDAP and Kerberos, but instead relies on web authentication protocols such as SAML<\/a>, WS, Graph API and OAuth<\/a> 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<\/a>.)<\/p>\n 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<\/a> at the end of every year, making them ideal candidates for Azure.<\/p>\n 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<\/a> should a device become compromised. Furthermore, Intune can be integrated with Microsoft SCCM<\/a> to provide more granular device management.<\/p>\n 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<\/a> wasn’t an issue when Server AD was conceived, but is a critical element for today’s organizations.<\/p>\n Users within just about any organization today utilize numerous cloud applications<\/a> such as Office 365<\/a>, Facebook<\/a>, Saleforce.com, Dropbox<\/a>, 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.<\/p>\n Then came Federated Services<\/a> which offered single sign-on<\/a> 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.<\/p>\nThe Different Environments of Azure AD and Server AD<\/span><\/h2>\n
The Commonalities Between Azure AD and Server AD<\/span><\/h2>\n
\n
How They’re Different<\/span><\/h2>\n
Azure AD Makes Life Easier for All Users Through IDaaS<\/span><\/h2>\n