Our last blog post on On-boarding to the Cloud discussed extending your on-premises directory into the cloud with Microsoft Azure Active Directory (Azure AD). Today we’ll talk about some of the additional benefits you and your users can benefit from by using Azure AD, along with Azure AD Premium.
For Microsoft, the cloud is not a second-class citizen or an afterthought. Microsoft technologies, products, and services are being designed to handle cloud-based scenarios and hybrid scenarios (where some of the information is in the cloud and some is located on‑premises) right from the get-go. This is especially true in Identity and Access Management using Microsoft Azure Active Directory.
Azure AD is a complete Identity repository, directory, and authentication mechanism made in the cloud for the cloud. For a general overview of Azure AD, check out the general Azure AD page.
To recap, some of the broad benefits of Azure AD include:
To explore more of the technical specifications of these features, start at the TechNet landing page for IT pros and the Azure AD Library for Developers on MSDN.
The power of Azure AD is available to all Azure tenants as a free Azure service, but there are enhancements that bring even more flexibility to your organization when you upgrade to the paid service, Azure AD Premium. You can compare the free and premium editions here.
The advanced features of Azure AD Premium include:
We will look at each of these four items in turn later in this blog. Other benefits that you should also be aware of are:
Earlier, we introduced Azure MFA. At the risk of repeating ourselves, MFA is such an important piece of identity that it warrants further discussion.
Azure MFA can help reduce organizational risk and increase regulatory compliance by providing an extra level of authentication in addition to a user’s account credentials to secure access. Azure MFA can be used for both cloud and on‑premises applications. You can activate MFA in Azure AD or Azure AD Premium to protect whatever you have protected with Azure AD authentication—Microsoft cloud apps like Microsoft Office 365, OneDrive for Business, and Windows Intune; custom applications that use Azure AD; and the hundreds of integrated SaaS applications available through the gallery (discussed later). You can also link MFA directly into your own applications with the MFA software development kit for granular application-based control.
Traditionally, MFA is characterized by requiring more than one of:
This combination of factors results in a layered approach that makes it significantly more difficult for an attack to succeed. It’s not enough for an attacker to guess or divine your password if they must also physically take your phone.
In the strictly on‑premises world, smart cards have been one form of MFA that’s been available for many years. Although smart cards have their place, they don’t always work so well with mobile devices or phones, tablets, and even generic Web access. Azure MFA opens up the possibilities of using Authentication Apps (also called authenticators), automated telephone calls, or SMS text messaging.
It’s important to note that this is the sort of MFA now being accepted—even expected—by users. User are becoming quite comfortable with the idea that a high-value transaction or access request will require confirmation with a code sent by SMS text, whereas most users no longer view smart cards in the same light. Paradoxically, many users are less likely to loan out their mobile phone (and its password or PIN) than they would be prepared to pass a smart card to a colleague.
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. You can learn specifics about Azure MFA here or see the overview of MFA options here. The step-by-step instructions for trying this out can be found here.
But wait! There’s more. You can now use Azure MFA to protect high-value resources in your on‑premises networks, as well. This is done by using the Azure MFA Authentication Server to connect on-premises applications to the MFA service. Visit here to get the steps and details on that.
Users expect to be able to change their own password or to easily reset a lost or forgotten password. In a typical, classic AD DS environment, this usually results in a help desk call. For cloud applications and websites, a great deal of effort has gone into custom coding solutions to allow password resets to be performed easily. But this can be difficult to get right. Make it too easy, and you might be front-page news for a security breach. Make it too difficult, and your support costs skyrocket and users leave.
Azure AD Premium uses the Azure MFA platform and user registration to allow for self-service resets and gives you control over how often users must verify their information as well as which challenges must be passed before a reset is performed. You can get started with self-service password reset here.
Continuing with the theme of self-service, with Azure AD premium, users can manage their own membership in groups, or they can be delegated the ability to control groups of other users. This means that the decision making of who should be in a particular security group (and therefore have access to particular resources) can remain a business function, performed by those in the organization who have the appropriate business knowledge and management authority, not an IT function.
For self-service management, groups can be configured to be open, where the user simply joins or leaves the group, or controlled by an administrator or delegate. In that case, the user requests the membership change, and it is submitted for approval. Learn how to enable self-service group membership here.
Hundreds of cloud applications are now on offer from many different providers. Managing individual credentials for each SaaS cloud app can be a nightmare, and when those credentials represent not only the user but also your organization’s reputation in the online world, it’s doubly important that they be managed, protected, and controlled.
Microsoft has worked with the publishers of the most popular cloud applications—no matter which platform hosts them—and set up all of the required infrastructure and settings so that Azure AD can automatically integrate or federate with each of them. By visiting the application gallery, you can see all of these preintegrated apps and choose those that your enterprise uses. Then, it is simple to configure SSO for each app.
Another advantage of using SSO and the Application Gallery is that you can allow specific corporate users to sign on to accounts that represent your company without knowing the underlying password for the SaaS application account instead using only their corporate credentials. Not only is this highly convenient, but it also helps protect your company account from unauthorized access, terminated employees, or leaked passwords.
The Application Gallery contains more than 1,400 apps at the moment, including those from Microsoft and other publishers—Office 365, Windows Intune, Salesforce.com, Box, Google Mail, and Concur, with more being added all the time. You can see the Application Gallery and all of the available apps here.
If you develop your own cloud apps, either for corporate use or for public consumption, you can configure them to be compatible with Azure AD SSO (for more information, go here). In the case of public apps, request that they be included in the Application Gallery (see http://msdn.microsoft.com/en-us/library/dn151789.aspx and http://azure.microsoft.com/en-us/gallery/active-directory).
We have talked a bit about SaaS integration with Azure AD, but it’s worth mentioning here that administrators can provide and revoke application access to users based on the groups to which they belong; you don’t need to configure each user individually. When you combine this with the self-service group membership requests and the delegation of approval, you have a powerful and efficient way to manage access to SaaS applications with minimal administrative effort. Read more here.
To close out this look at Hybrid Identity and Azure AD, we would like to touch on the reporting capabilities. Reporting is an example of where Azure AD is not just “AD DS in the cloud” but something that goes beyond the traditional expectations into new, exciting benefits for you as an administrator. Azure AD includes general usage reports and reports that highlight potential security issues. Azure AD Premium offers more reports than the free edition.
The free edition can report on sign-ins happening from new, previously unknown devices; highlight successful sign-ins that happen after multiple failures; and sign-ins that occur from different geographic areas in too short a time period. (This “impossible travel” scenario usually indicates either unauthorized password sharing or that an attacker has gotten hold of a password. There are occasions, such as remote access sessions or odd Internet service provider routing, that are not in themselves a threat, but as an administrator you have the tools to look into it.) The free edition can also provide you with sign-in activity history for a user.
Azure AD premium adds reports showing devices that a user employs, specific application usage (including Application Gallery SaaS apps through SSO), users with suspicious sign-in activity, devices suspected (or confirmed) to have been infected with malware, or sign-ins coming from IP addresses that have already shown suspicious activity.
The best part of these reports is that you don’t have to invest the time to configure them! They just work and give you tools to manage your network. Get started with Azure AD reports here.
Another form of discovery and reporting that is just being introduced is Cloud App Discovery. Cloud App Discover does require a bit of preconfiguration, but then provides IT and business managers with a great overview of all the cloud-based applications users in the organization are accessing.
Cloud App Discovery consists of three broad steps:
Take a look at Cloud App Discovery here.
NEXT BLOG POST IN THIS SERIES: All about Mobile Device Management (May 27th)
Comments in this blog are open and monitored for each post for a period of two weeks after the posting date. If you have a specific question about a blog post that is older than two weeks, please submit your question via our Twitter handle @MSCloud