Microsoft Azure Active Directory: Getting Started with Identity Management in the Cloud, Part 1

Muditha Chathuranga is a Senior Technical Consultant at Infront Consulting and a Microsoft MVP in Office Apps and Services. His personal blog, The Cloud Journal, covers Azure, Exchange, O365, Security, and much more. You can follow him on Twitter at @MudithaC .

Microsoft Azure Active Directory is an IDaaS (Identity as a Service) offering that helps you manage corporate identities in the cloud. The solution itself is a cloud service that is hosted in Microsoft Azure datacenters globally. You can provision your tenant in a datacenter closest to where your organization is located. From here onward on this article, I will refer to Microsoft Azure Active Directory as AAD since that’s how it’s known among many.

Since AAD is a cloud offering it of course requires a paid subscription to use many of its features. But there’s a free tier for those who want to explore and are just getting started with the service. The following table shows the pricing of each tier.

Tier Price (per user per month) Free N/A Office 365 Apps Price depends on the SKUs you have subscribed under Office 365 Basic $1 USD Premium P1 $6 USD Premium P2 $9 USD

Additional pricing and feature comparison can be viewed here.

This two part article is not a deep dive how-to guide. Rather, this is an effort to talk about a few major features available with AAD that you can use to get started with managing identities in the cloud. Depending on your AAD SKU, you may, or you may not have some of the features that are being discussed.
 

Connect

Connect is the sync engine that connects on-premise directory services with AAD. This enables organizations to adopt a hybrid identity model and synchronize objects from the on-premise directory to the AAD. This allows users to use same identities used in on-premises with cloud services as well.

There are two major authentication mechanisms available when you synchronize identities from the on-premise directory.

Same sign-on

When same sign-on is used in an organization, it synchronizes password hashes along with other attributes of user IDs to AAD. Then when a user is trying to authenticate to Microsoft Online Services, credentials will be authenticated in the cloud, eliminating the need to verify them against the on-premises directory. This is the simplest method of implementing synchronized identities.

Single sign-on

When single sign-on is used in an organization, the AAD needs to be federated with a federation service that the organization has implemented. Whenever a user tries to authenticate to Microsoft Online Services, the user will be re-directed to the federation services to authenticate against the on-premise directory. This is a more complex scenario than same sign-on and it requires you to deploy additional infrastructure on a high available mode, if you don’t have them implemented already.
 

Single Sign-on

Single sign-on, a.k.a. SSO, is the concept that enables an end user to sign in to multiple applications or services without needing to enter credentials manually if already logged in to the identity provider (IdP). Leveraging this concept, organizations can federate their enterprise applications with AAD and leverage SSO.

While there are many SSO mechanisms available to implement, the most widely used is SAML based SSO, which AAD supports fully. Once your applications are federated with AAD as the IdP for authentication, users of the organization can seamlessly sign in to the federated applications without needing to enter credentials. The SSO mechanism is described below.

Figure 1: Protocol Diagram for SSO Sequence. (Image Courtesy: https://docs.microsoft.com)

Multi-factor Authentication

Multi-factor authentication (MFA) is not something new in today’s world. MFA has been around for some time now and used in many online services without some of us even noticing.

A few years back, the best practice to protect passwords from breaching was to enforce password complexity and expiration policies. The mandatory password expiry is no longer the recommended approach1.

These policies defined how complex a password should be (length, special, upper/lower case, numerical character requirement) and the length of time a password is valid before it is mandatory for the user to change it to a new one. While it seemed to be a secure practice at the time, some user activities brought the protection to its knees. Due to these policies, users had to change their complex passwords every now and then and keep them memorized.

While some users managed to generate complex passwords and keep them memorized, majority of users couldn’t, instead writing down their passwords in notebooks and post-it notes. Even if the users were not using simple passwords that were prone to breaches, they were inadvertently breaking security protocol.

The answer to these challenges was to establish the identity by using a second or third factor to verify the identity of the user. The concept of MFA is “something you know” + “something you have”. The “something you know” is your username and the password. The “something you have”, can be anything that you can verify your identity. i.e. your mobile phone, email, authenticator app, biometrics such as finger print or facial recognition.

The AAD supports MFA configuration, so that whenever you sign in to a cloud application that is federated with AAD it can verify your actual identity. Here are the ways you can verify your identity with MFA in AAD:

• SMS
• Phone call
• Verification code from Authenticator app
• Push notifications on the Authenticator app

In the second part of this series, I will take a look at additional AAD features including password reset, ID protection, privileged ID management, and more.