Azure Active Directory (Azure AD) Premium licenses unlock additional functionality for cloud identity and security capabilities. For many organizations, it is not possible to implement and manage Office 365 to the level of security necessary without Azure AD Premium. In addition to Office 365, Azure AD Premium functionality is also immensely useful for 3rd party software-as-a-service (SaaS) applications.
Azure AD Premium is available in two versions: “P1” and “P2”. Most of the features in Azure AD are included in P1. You can license Azure AD Premium P1 individually, or you can get it as part of a bundle such as Enterprise Mobility + Security (EMS) E3 or Microsoft 365 E3. The P2 licenses adds more features. This license is also available individually, or as part of EMS E5 or Microsoft 365 E5. Unless otherwise noted, you can assume that any features we discuss in this article require P1.
It is not possible to effectively deploy and consume the capabilities of Azure AD Premium (or most other cloud services, for that matter) all at once. Instead, a phased deployment approach focusing on delivering value quickly and building momentum is usually a recipe for success. As you build wins from deploying new capabilities, you can in turn invest in more complex deployments that take longer to complete.
Self-Service Password Reset
Forgotten passwords is an age-old IT problem. While Microsoft makes a huge investment in passwordless technology, the reality is that most organizations will continue to rely on passwords for some time. End-user calls to the service desk to reset their password are enormously expensive. There is a cost for the service desk agent’s time, as well as the end-user’s lost productivity.
Azure AD Premium includes self-service password reset (SSPR). With SSPR, users can reset their password, or unlock their account without IT intervention. Users can use SSPR through a “Can’t access your account?” link on the Azure AD sign-in screen, or through a link added to the Windows logon screen. SSPR is not just for cloud passwords either. With Azure AD Connect, SSPR leverages a feature called password writeback. Password writeback allows Azure AD to securely send a password change, reset, or account unlock to the on-premises Active Directory (AD) forest without opening any inbound ports on the firewall. Since the password change or reset goes to AD, your on-premises AD password policy is also honored even though the password change/reset is performed in the cloud.
For an SSPR implementation to be successful, you must ensure that users register for SSPR in advance. You can configure SSPR to use a variety of different authentication methods including the Microsoft Authenticator app, voice call, text message, alternate email address, and/or security questions, as shown in Figure 1. Except for alternate email address and security questions, these are the same authentication methods supported by the multi-factor authentication (MFA) service in Azure AD. This means that if your users are registered for MFA, they are also registered for SSPR. You will simply need to enable SSPR, configure how many authentication gates the user must complete (one or two), and ensure password writeback is enabled in Azure AD Connect.
Figure 1: Configuring SSPR to use a variety of different authentication methods
Application Federation and Provisioning
In addition to first-party workloads like Office 365, Azure AD integrates with thousands of SaaS applications and even in-house developed applications. You can extend the same identity management and security controls in Azure AD Premium used with Office 365 to third parties. For many organizations, a strategy of integrating all new applications with Azure AD results in simplification for end-users and IT alike.
Azure AD has a gallery of thousands of pre-integrated applications. Hundreds of these applications use federated identity protocols like Security Assertion Markup Language (SAML) or Open ID Connect. Pre-integrated applications are ready for an administrator to follow Microsoft documentation to complete the integration. Once complete, end-users can access the application through single sign-on (SSO) with Azure AD. Even if your application is not in the gallery, you can add a custom application if it supports standards-based authentication protocols like SAML, OAuth, Open ID Connect, or WS-Federation.
Managing the sprawl of identities in SaaS applications is an ever-growing problem as the number of SaaS applications increase. Traditional identity management processes such as account provisioning and deprovisioning, role management, and access certifications must be extended to SaaS applications. Newer problems like license management also present themselves when you must pay for each active user. Transforming and extending identity management systems to keep up with new SaaS applications can be a challenging problem to solve.
Fortunately, Azure AD Premium includes outbound provisioning capabilities for select SaaS applications. You can use outbound provisioning to map traditional AD groups (or Azure AD groups) to SaaS application access and roles. When Azure AD detects a change to a user in a group, or to the group membership itself, it will create or update the user’s account in the SaaS application as well as manage group or role membership in the app. You can use Access Reviews in Azure AD Premium P2 to perform access certifications for group memberships that manage SaaS application access.
Conditional Access
Undoubtedly one of the most powerful and exciting features in Azure AD Premium is conditional access. CA lets you define granular policies that control the who, what, when, and how of access to individual applications and Office 365 workloads. Using CA policies, you can pivot from the traditional network perimeter of “in front of” or “behind” the firewall to a modern zero-trust architecture that factors in a multitude of inputs and signals about the user accessing the application.
In addition to traditional policy inputs such as who the user is (or maybe whether they’re a member of a group), and the IP address or network location they’re coming from, you can also use information about the device the user is using, the application they’re using, and a dynamic risk score for the user and their session as factors for allowing or blocking access. For example, you might have an application or SharePoint site with sensitive data in it that you only want to permit access to from a corporate device. This is trivial to do with CA. If you also use Microsoft Endpoint Manager (MEM, formerly Microsoft Intune), you can also use CA to check if the device is compliant with your MEM policies.
You can also take actions before granting access. The most common action to take is whether to require MFA. For most organizations, the first step on the MFA journey is requiring MFA any time a user accesses an application from outside the internal network, as shown in Figure 2. This often leads to far too many MFA prompts, though. To evolve this MFA strategy, you might decide to combine knowledge about the device and its health with the MFA decision. For example, if the user is coming from a compliant, Hybrid Azure AD joined device, MFA is not required for external access. Of course, you might create an exception to this rule for high-risk or sensitive information, based on a sensitivity label and always require MFA. This scenario is easy to model and enforce with just a few CA policies in your tenant.
Figure 2: Require MFA any time a user accesses an application from outside the internal network
Practically every organization will find a need for CA if they use Office 365 or integrate other applications with Azure AD. It is possible to model some, but not all, of the capabilities of CA with a third-party identity provider but ultimately there will be situations where only a CA policy can meet a full set of requirements.
Identity Protection
Azure AD Premium P2 brings a significant level of insight with identity protection. For every sign-in from a user in your tenant (or even a guest user), Microsoft assigns a risk score to that sign-in based on various risk detections. Through the vast trove of data collected through billions of sign-ins a day, Microsoft trains a complex machine learning model that computes the sign-in risk score on the fly. You can use the sign-in risk events as an input to your security operations to identify users that require further investigation, or you can use it in a CA policy to make access decisions based on sign-in risk score.
Patterns that require further investigation include situations where a user is coming from an anonymized IP address (e.g. a Tor browser) or the user’s past sessions appear to come from geographies that imply an impossible travel situation. Impossible travel is calculated based on the assumed location of an IP address. For example, if you sign-in from an IP address in Chicago at 9AM, and then sign-in from an IP address in London at 11AM, it is simply not possible for you to have been in both locations in a two-hour window. This might imply a compromised account.
Microsoft also calculates risk scores for individual users through behind-the-scenes processes. One of the most common situations where a user can receive a high-risk score is if they match a leaked credential. To perform leaked credential testing, you must have password hash synchronization enabled in your tenant (even if you use federated identity to sign-in). Once password hash synchronization is enabled, Azure AD tests password hashes against leaked/stolen credential lists that are posted on the Internet or dark web. If a match is found, Azure AD creates a risk event in your tenant to trigger action by IT, or an automated action such as a forced password reset with SSPR. You can query the identity protection Graph APIs to programmatically receive information about user and sign-in risk.
Get Value from Your Investment
One of the most important steps to purchasing a cloud service is devising a plan to derive value from the deal. Azure AD Premium is a large and sometimes complex set of capabilities and features that can offer tremendous value, but it is impossible to implement all of the features at once. Instead, you should identify features that present the most value to your organization in the shortest amount of time and begin with them. SSPR, application SSO, conditional access, provisioning and access management, and identity protection are just a few examples of features that I find are often the most attractive to organizations of all sizes. They can be deployed in a manageable amount of time, and they often set the stage for bigger and more complex initiatives in the future.
Thank you! This is a great insight comparing the Azure AD P1 vs P2 options.