On-boarding to the Cloud

[MicrosoftSecurityandComplianceTeam]

First published on CloudBlogs on May, 20 2014

In our last blog post on Consistent Identity in the Data Center , we discussed having a consistent directory service within your own infrastructure. Today, we’ll discuss how to extend that directory into the cloud.

When you look at managing identity in the cloud, you need to make some initial decisions. Of course, you can always change your approach and expand to add new pieces after the initial setup, but we all know it’s much easier to have an idea of where we want to end up before we start out on a journey.

One of the first things to consider is whether you will be leveraging an on‑premises directory, particularly Active Directory Domain Services (AD DS), or working in a cloud-only environment. For a cloud-only environment, choose Microsoft Azure Active Directory (Azure AD). We’ve already touched on the power of Azure AD, and we will go into more detail later about Azure AD Premium. For now, just keep in mind that Azure AD provides the core identity functions that you need for a cloud-based scenario. You can learn more about how Azure AD and AD DS are similar in the Microsoft TechNet article: Similarities between Active Directory and Azure AD .

Many of you, though, will have to work with cloud-based resources and on‑premises resources that users are accessing inside your LAN perimeter and from the Internet. This means that you will either want to synchronize data between the cloud and on‑premises systems or use federation to allow authentication to happen transparently.

There are a lot of benefits to this latter approach. First and foremost, users can employ one set of credentials, which gives them one less thing to worry about and increases your security. They can use the same name and password to access on‑premises resources as, say, Microsoft Office 365, and you only need to integrate once! After you’ve configured it, all of the cloud services you have subscribed to in Azure AD—and any that you may add in the future—are provisioned. In other words, you only need to set up Directory Integration once, and every service can use it.

But deciding whether to synchronize, federate, or both is not always clear-cut. In a synchronization scenario, user information is updated automatically in one system when it is changed in another. In a federation scenario, the authentication request received at one place is forwarded to another to be handled.

Other considerations in choosing synchronization, federation, or both include whether the “other place” that holds user data is able to synchronize or federate (that might dictate a choice); the agreements and constraints about sharing data between entities or departments; or the desire to use new, advanced features available only with federation. (Federation is usually more complex to set up and manage than synchronization.)

For help determining which kind of scenario will work best for you, keep reading this blog series, and also read this Microsoft TechNet article: Determine which directory integration scenario to use .

Cloud identity

In some cases, you may have the luxury of starting fresh and building a new identity framework completely from the ground up. This may be the case if you work for a startup or new organization or even in the case of large, established enterprises if you are building a public-facing project when all of your users are external. More and more, in these cases, the new identities are created, managed, used, and eventually retired, all in the cloud.

You can easily create a new identity store in the cloud using Azure AD. Even with just the free edition of Azure AD, you can create and manage user accounts and get single sign-on (SSO) across Azure and Office 365. We’ll talk a bit later about using Azure AD in federation or sync scenarios and when you might want to look at Azure AD Premium for more advanced functionality. To start with a solid, functional, robust, cloud-based user identity and authentication system, investigate Azure AD .

Sync scenarios

The simplest sync scenario is usually that of synchronizing an on‑premises AD DS installation with an Azure AD installation. This can be done with a tool known as a synchronization engine. The classic example was a tool called DirSync that Microsoft provided for several years. DirSync was limited, though, in that it could sync only one AD DS domain with Azure AD and didn’t support some cloud-first scenarios.

Microsoft now offers a tool that brings all the goodness of DirSync and more into the modern cloud-based computer arena: Azure Active Directory Sync. Azure AD Sync can obviously still handle the simple one-to-one model of DirSync but can also take care of complex scenarios like multiple domains and forests and, as we’ll see in a bit, other identity stores.

Typically, if you are going to sync your AD DS directories, you will implement full password synchronization. This means that when a corporate user (from AD DS) authenticates against Azure AD, the authentication is handled directly by Azure AD. For more details, see Implement Password Synchronization .

By implementing Directory Sync, users can use the same credentials (name and password) for cloud services like Office 365 as for accessing Windows-based resources on‑premises. This is not quite full SSO, as the user must enter their credentials when connecting to the cloud and again when logging on locally, but they will be able to use the same credentials. For full SSO, federation is needed; we will get to that in just a bit.

With the free edition of Azure AD, changes are made in AD DS, and then synchronized “up” to the cloud. With a subscription to Azure AD Premium, Azure AD Sync also performs a write-back of information from Azure AD “back” to the on‑premises directory. If many of your users are mobile or tend to access services primarily through the cloud, this approach gives you more flexibility and responsiveness.

By using Azure AD Sync, you can also get some new benefits. One of these is Multi-Factor Authentication (MFA). You can configure MFA on Azure AD, and it will then be used, even for users who have been synchronized from on‑premises AD DS. Azure MFA can also protect high-value resources in your on‑premises networks. We will get into that a bit later.

Our colleagues, Alex Simmons and Bhavini Soneji, have put together a great overview blog on getting started with Azure MFA on the Active Directory Team Blog .

You can also learn specifics about Azure Multi-Factor Authentication or see the overview of MFA options . The step-by-step instructions for trying this out are located here .

What else? Oh yes. Recall that problem of user information being scattered around different databases or identity providers? How does a cloud solution address that problem? For a strictly on‑premises solution, Identity Manager is the answer. And for many organizations, using Identity Manager to consolidate the user information into AD DS, and then using Azure AD Sync or Azure MFA to synchronize to the cloud works well.

But what if those databases are external to your on‑premises infrastructure? What if they are already hosted in the cloud or managed by another partner. Federation (yes, I know we haven’t gotten there, yet) may be an option, but federation may not be available for technical, political, or contractual reasons. Even if your organization has direct control of all of the databases involved, you may be looking for a more direct solution.

Azure AD Sync can synchronize identity information and attributes not only from AD DS but also from SQL databases (any instance accessible via ODBC), LDAP v3 directories, Web services (using SOAP, Java, or Representational State Transfer), and even from any repository that supports Windows PowerShell directly into the Azure AD store. This is wickedly cool. You can read more about this functionality here .

Now, that brings us to federation.

Identity Federation

Identity Federation is all about who controls the authentication process (which organization or entity) and where the authentication is done. Federation also allows for true SSO, where a user is only challenged once for their credentials, no matter which federated resource the user is accessing. With federation, you can also introduce new services that allow more forms of remote access while keeping the data protected.

If a user tries to authenticate against Azure AD and Azure AD has been configured for synchronization with passwords, Azure AD has all of the information needed to authenticate the user (including, perhaps, MFA). However, if Azure AD is configured instead to use federation, Azure AD sends the authentication request to another server. Most commonly, that “other server” ends up being part of AD DS or an authentication server operated by a partner.

Azure AD can’t directly “proxy” or request the authentication. Instead, a security token service (STS) is used to pass, well, security tokens between the servers involved. Microsoft’s STS is called Active Directory Federation Services (AD FS). One of the most powerful things about using federation, though, is that it can support non-Windows or non–AD FS partners, including Shibboleth Identity Provider and other non-Microsoft, standards-compliant identity providers.

From a user’s point of view, the advantage is that once signed on to the corporate network, they can then access cloud resources without having to enter their password again. From an administrator’s point of view, advantages include being able to use one set of account policies, implement more robust access control, use strong authentication (two factor) or MFA, and reduced support calls. This scenario is described in detail, with steps to follow here .

Usually, you will still synchronize user information between Azure AD and AD DS, but the password or credentials will not be synchronized. This means that every authentication attempt is performed using the security token-passing methods of AD FS against the on‑premises domain controllers. AD FS supports things like granular control of MFA requirements on a per-application basis, device registration with Workplace Join, and conditional access.

Another benefit to federation is the ability to support partner applications. For example, your organization may use an outsourced provider for travel services. As long as they can participate with a compatible STS, such as AD FS, users will not need a separate logon for the provider’s site. This might be a “more traditional” use of business-to-business federation, but it is still relevant and useful.

One caveat, though: federation does provide a single, federated identity with one set of credentials, but it works best in medium-sized and large organizations that need the benefits of federation and have the resources to manage it. Smaller organizations or those that have simpler requirements may well find all that they need through Azure AD Sync and Azure MFA.

NEXT BLOG POST IN THIS SERIES: Identity and Access Management for the Cloud