Active Directory: Differences Between On Premise and In the Cloud
Two days ago, I wrote up a post called - Getting Started with Windows Azure Active Directory – Setting up the Windows Azure AD Tenant – In that post, I walk through how to configure the Windows Azure Active Directory tenant, but I don’t spend any significant time on why you would want to do this.
It is important to understand the difference between Active Directory Domain Services that you run on a Domain Controller on-premise, and Windows Azure Active Directory running in the Azure cloud. Even though we connect them, and share information between the two, they serve different purposes and possibly even different users. This post intends to clarify this.
Active Directory Domain Services
The current name of “Active Directory” is called Active Directory Domain Services, but I am going to use Active Directory and AD for this article. Active Directory has been the Microsoft directory service used in your on-premise infrastructure since the release of Windows 2000 Server. We use AD as a means of organizing objects in a hierarchical format that makes it easier for administrators to perform tasks. We should all be familiar with the basic AD structure at the point. From the top down we have -
Forests
Trees
Domain
Organizational Units
Groups
Resources & Security Principals
For the most part, any object higher in the hierarchy can contain objects lower in hierarchy. We use these object to define our network both geographically and logically. Active Directory allows us to group related objects together for management and/or to apply security permissions to. There is more that can and is done, but on a day-to-day basis, this is what most admins spend their time doing.
Active Directory on-premise is the means by which we authenticate and authorize users when the logon to a workstation, when they attempt to run an application, when the attempt to access a local web based portal, and even when they attempt to connect to a mail server to send/receive email. Active Directory contains objects that define the user, any groups they are a member of, and what rights and permissions they have as a user or members or a groups or groups.
One of the primary benefits of Active Directory is Single Sign-On. Because of the centralized administration and the organization of all AD objects with a single forest (and through the use of trust relationships), a user can logon to their workstation once at the beginning of a work day, and never be presented with additional userID and password prompts. This makes for a more seemless experience for end-users while unifying the security contexts and control for administrators.
The key thing to understand here is that Active Directory Domain Services was developed for and is primarily used for managing on premise resources. These are resources and objects that are typically 100% under the control of company administrators. As the industry continues to shift to a more cloud based model, we need to extend Active Directory into the cloud.
Windows Azure Active Directory
With the recent announcement of the general availability of Windows Azure Infrastructure Services, we will see more businesses putting classic infrastructure components in the cloud. In fact, It is entirely possible for a new startup to be born in the cloud and live in the cloud while having no on-premise infrastructure (they may not even have premise to be on”!).
For more established companies, they will already have a significant investment in on-premise hardware and the infrastructure services used to make it all work. These companies will be looking at Windows Azure as a means of reducing future capital investment in hardware and other physical infrastructure or to simply existing infrastructure. One of the components of Windows Azure that should be looked at is Windows Azure Active Directory (WAAD). It is important to understand the difference between WAAD and Active Directory Domain Services running on a Domain Controller.
First, WAAD is not a stand-alone Active Directory service. in it’s current form, you will not be creating forests, domains, etc in WAAD. WAAD is an extension of your existing on-premise AD structure. In fact, the article I wrote 2 days ago - Getting Started with Windows Azure Active Directory – Setting up the Windows Azure AD Tenant – we prepare, configure and establish replications from your on-premise AD environment to WAAD. If you walk through this process, you will see a couple of notifications that once replication is established, you will still be using your on premise tools like Active Directory Users and Computers (ADUC) as the primary management tools to manage objects in Active Directory. Right now, the only objects you can manipulate are Users created in the WAAD portal and specifically only those created as WAAD User types (more on this below).
Let’s breakaway for a moment to see what we can do with users -
Add new User to WAAD
Once you have established replication between on premise AD and Windows Azure AD, select the Users tab and you will see a list of users. Pay close attention to the Sourced From column as it will tell you where the object actually lives. In my example below, some of the objects are Microsoft Accounts (@live.com, @outlook.com, etc based addresses), Local Active Directory (your on-premise AD), and Windows Azure Active Directory accounts.
Let’s add a new user in WAAD and see what happens. At the bottom of the admin portal, select Add User. On the first page of the wizard, we are prompted for the basics -
Type of User -
New user in your organization – this type of user account will be managed within your directory.
User with an existing Microsoft account – select this type if the user needs to collaborate on Windows Azure resources with a co-administrator who accesses Windows Azure with a Microsoft account.
User name – Provide a user name and then the drop down will be populated with any Windows Azure AD domains you have configured.
On the next page, we have the User Profile for which everything is self-explanatory except -
Role -
User – Basic users that will be accessing services
Global Administrator – The all powerful admin. Global Administrators can do anything they want, including delete all Windows Azure services.
(More on User Roles here - Assigning administrator roles)
The final screen has us set a temporary password and optionally send it in email -
Once we are finished, the new user will be listed in the User tab of the Windows Azure admin portal. Since this user was created in the WAAD admin portal, and we did not specify it as having an existing Windows Account, it is listed in the Sourced From column as a Windows Azure Active Directory account type.
The only accounts you can actually “manage” or delete through the WAAD portal are those that are designated as Windows Azure Active Directory Type. The only “management” you can do with these types of accounts is to change passwords, modify the options you specified during the Add User Wizard, and add some data to the Work Info tab.
You will notice though that there is no info for Domains, Organization Units or other logical groups that we are familiar with from ADDS in on-premise AD.
The REAL difference between WAAD and ADDS
As I mentioned before, WAAD is an extension of the on-premise Active Directory that we have used for years. I also mentioned that as business start to put more and more services and applications into the cloud, we have to have a way of connecting the two realms. Windows Azure Active Directory allows us to replicate user accounts from on-premise AD which also extends Single Sign-On capabilities to cloud based applications. Now, as users logon to their workstations, we can offer cloud based services that have access to use information in WAAD that allow user to connect without being prompted for additional information. This provides seamless access to the end-user and administrators don’t have to maintain separate user account databases. Administrators can also use the same set of on-premise tools to make changes to user accounts in both places to maintain centralized administration. But, we allow for some new user account types that may have special use, or don’t have an on-premise equivalent. This provides flexibility for Administrators and Developers while maintaining centralized control.
I hope this sheds some light on Windows Azure Active Directory, it’s differences, and how it compliments what you are already running!
Cheers!
hfhfhfh