Active Directory: Differences Between On Premise and In the Cloud – Part 2

To my faithful readers – My Apologies. In my previous articles on Active Directory: Differences Between On Premise and In the Cloud, I neglected to include the single biggest (and most obvious) difference between traditional, on-premise Active Directory and Windows Azure Active Directory.

I touched briefly on Authentication and Authorization in the previous article, but I failed to point out that Windows Azure Active Directory is not designed to nor will it handle Authentication of machine and computer accounts for workstations logging on to a Windows network.

One of the ways in which Active Directory integrates the identity of network objects with network security is by managing logon authentication as well as authorization to network resources. Active Directory is designed to be capable of authenticating user identity and authorizing or blocking user access to network resources for users of computers that run not only Windows operating systems but also operating systems other than Windows. The following diagram lays out much of what Active Directory is capable of and responsible for.

 

 

What we have to keep in mind though is that Active Directory started out as an on-premise directory service. Some of the most common things we do with Active Directory are -

Authenticate/Authorize User Accounts

Authenticate/Authorize Computer Accounts

Manage Security Group Memberships

This in turn allows us to apply Group Policy to Computer and User accounts based upon whether they authenticate, what groups they are members of, and what they are authorized to do. THIS is the key difference I failed to call out. Do not expect Windows Azure Active Directory to be a replacement for on-premise Active Directory when it comes to authenticating, authorizing and applying Group Policy.

When a computer is on the local network, connected via RAS/VPN, or even connected via Direct Access, the computer gets information (usually from DHCP) about the location of DNS servers on the local network which in turn provide information about the location of various network services, including the location of Domain Controllers. Of course, Domain Controllers are the masters of the Active Directory implementation and manage the authentication/authorization/group policy for the computers and users that make requests. All of this is built into the clients for how they ask for permission to access resources on the network. Windows client OSes are built to use the local network to query DNS for a DC to provide access and to find out what they can and cannot do. Windows Client OSes also leverage certain protocols like RPC which are not transportable over the open internet without first being packaged or encapsulated. In other words, there would have to be modifications made to the Windows Client OS to specifically point to Windows Azure Active Directory.

Windows Azure Active Directory also performs Authentication and Authorization, but it is not applying Group Policy to computer and user accounts. In my previous article we configure directory synchronization, but noticeably absent is the replication of group policy. WAAD in it’s current state is primarily used to provide users with a more seamless authentication experience as they access Microsoft cloud services while logged on to the corporate network. It is also not a primary end-point for authorizing computer and user account looking to get Group Policy.

WAAD is currently design so application developers can integrate their applications with Windows Azure AD to provide single sign-on functionality for their users. This enables enterprise applications to be hosted in the cloud and to easily authenticate users with corporate credentials. It also enables SaaS providers to provide easier authentication for users in Windows Azure AD organizations when authenticating to their services. In other words, it is at the application layer that we are looking at WAAD for authentication and authorization so we can tell the application what it is allowed to do.

 

I hope this clears up any confusion I may have left from my previous article!

 

There are an excellent set of articles on the MSDN site that go into detail about WAAD protocols, WAAD API’s, and more information on AD integration and SSO.  I have linked those here -

 

Supporting Information:

TechNet Article: Active Directory Concepts

MSDN Articles: Windows Azure Active Directory

MSDN Article: Windows Azure Active Directory Authentication Protocols

 

Cheers!