In my previous blog post Field Notes: Azure AD Identity Protection we looked at the administrator perspective on Identity Protection. The focus was how to protect your corporate accounts.
In this blog the focus is the end-user (employee and IT staff) experiences.

The experiences I want to share are:

• Suspicious Activity
• User with a high-risk classification
• Behavior observed with Azure AD Password-less sign-in.

Employee experience

Suspicious Activity

When an employee uses a browser or modern authentication, this dialog will appear, when the conditions of a risky sign-in have been detected:

Risky sign-ins are medium-risk events. Example triggers for events are:

• Signing-in from two separate locations in the world with an impossible travel time. However, this can also be detected, when a corporate VPN is used and it forces all internet traffic through the tunnel. Another false positive might be detected when using remote systems in datacenters located in another location. Please note that 'location' in Identity Protection-speak is usually in the scale of a small country or US state.
  For example: 10:10 am sign-in from Amsterdam and on 10:15am a sign-in from Redmond, WA in the USA.
• Using a VPN connection, proxy or browser to anonymize your real IP location. NordVPN and the Tor browser are great examples and we use them to demo Identity Protection detections effectively.
• Connecting from a public IP address with a bad reputation, due to infected machines at that location. For example, connections from internet cafes and public hotspots.

Employee with a high-risk classification

When an employee meets the threshold of medium events or the situation score calculation algorithm generates a high score, the user will be blocked from access, by default.

The user feedback I received, is that the authenticator app gives an error message, and tells the end-user to contact the systems administrator. Microsoft Office Outlook will not connect on your machine.

The only way to know what is going on is to use a browser to sign into the Office 365 environment, for example.

Depending on your tenant's Identity Protection configuration, an employee can validate and reset the password to his or her account or be blocked until an administrator forces a password reset for the affected user account.

Note: Microsoft has added the ability to do a self-service password reset via the Authenticator app. This paves the way for resolving high-risk events from within the Microsoft Authenticator app, if the policy allows end-user reset in a high risk situation.

Azure AD Password-less sign-in

If you have configured Password-less sign-in with Azure AD, the user experience is different, when it comes to risky sign-in sessions. The end-user will not be shown a prompt that the sign-in session is calculated to be risky. A mere alert will be generated in Azure AD Identity Protection and depending on the configuration, sent to the IT staff for notification. The event itself will be automatically closed, because multi-factor authentication is performed.

IT Staff experience

Out-of-the box alert

In all three cases above, Azure AD Identity Protection will generate an alert e-mail that a risky event has occurred. This alert is sent to the configured mail recipients. The message itself does not contain the actual account information or threat level. In order to consume this information, you need to sign-in the Azure AD Identity Protection portal.

The message the IT staff receive is shown below:

Graph API

If the security teams wants faster insights, they should leverage the Graph API and create an automation option to retrieve the Azure AD Identity Protection data. This option is documented here. An example output is shown below, using the PowerShell code provided in the Microsoft documentation:

Using the Graph APU enables the IT/security staff to retrieve detailed information on security events, directly from the tenant. This enables  automation and faster insights into what is going on. An automation example is a query is formatted to a readable event for the organization's SIEM solution or Log Analytics.

Processing a risk event

Azure AD Identity Protection has three levels of administrator access.

The minimum level IT staff personnel need to process the security events and give back control to the end users, is to be assigned the Security Administrator role to gain access to Azure AD Identity Protection. Additionally, they need the User Administrator or Password Administrator role to reset passwords for affected users for them to regain access to the company resources.

In a event of a blocked user, the IT admin has two choices after reviewing the security events first for the affected user.

1. When the events are legitimate, they can force a reset of the user password and provide the end-user with the new temporary password.
2. When event are false positives, they can mark them as such in the web portal, so Azure AD machine learning can learn from it and lower the security score of the end-user in the process.

A better approach

The information that Microsoft supplies in case of a high risk event is minimal for an end-user. He or she is not properly informed on what is going on and what steps to take.

From a service desk/IT staff perspective, the information alert mail doesn’t contain direct information. It is not directly useful to prioritize the event. To gather the actual information, the IT admin needs to login and lookup the event. This takes time. Depending on the workload, it may not always be visible straight away.

The combination of the above two experiences is that when an employee contacts the service desk, time is lost with troubleshooting, because the error is not properly shown from the end-user interface, unless when using a browser.

A solution here, would be an automation script that runs in the background and registers an incident in the ticket system and an event for SIEM, based on the employee information and give it a high priority. In addition to that, a separate e-mail can be sent to the security staff with more detail. Also a brief e-mail can be sent to the service desk to be informed that a user is blocked.

This way, service desk personnel can be properly informed and can even pro-actively contact the effected employees and guide them through the process.

Concluding

Don't waste valuable time troubleshooting risky sign-ins and high-risk events that block employee sign-ins. Get the pro-active edge.

I'm managing several Azure AD tenants with a wide variety of licenses and settings. I've had a focus on Azure AD Identity Protection for the last weeks, so I'm sharing my field notes with you.

What is Azure AD Identity Protection?

Let's start with a little introduction.

Microsoft has a lot of experience with identities in the cloud. These identities are used for public cloud features like onedrive.com and outlook.com, but also for the organizational cloud identities within Azure Active Directory.

With the presence of one or more Azure AD Premium 2 license(s) in the tenant, an organization can benefit from additional security options and automated actions to secure their organizational identities within that tenant. The global administrator account that is going to be used to activate the feature, should be enabled with a Azure AD Premium P2 license.

Azure AD Identity Protection Features

With the activation of Azure AD Identity protection, organizations benefit from the following features:

Detection

• Evaluates every sign-in sessions to existing sign-in behavior of the employee
• Evaluates the User Risk on the overall behavior and detection points
• Provides custom recommendations to improve overall security posture by highlighting vulnerabilities
• Integrates with Password protection within Azure AD
  Microsoft obtains from several recourses passwords that are known on the Internet. With this information, Password Protection checks the existing password if the are known on the internet. If so, the user risk becomes high risk within Azure AD Identity protection. Depending on your policies, actions need to be taken before a employee can start working again.

Investigation

• Provides investigation capabilities
• Provides an overview of all risk events and/or user accounts.
• Alerts the security team(s) of events
• Offers workflow capabilities so admins can
  – Initiate immediate password reset
  – Report false positive events

Risk-based (Conditional Access) policies

• Provides the capability to request additional user conformation, in sense of a multi-factor authentication or even block access, if a sign-in session is been found risky
• Provides the capability to request a password reset or even block access, if the user account has been marked to be at risk
• Integrates with Conditional Access as conditions
• Enforces MFA registration

Differences in Azure AD Identity Protection functionality between licenses

All the editions of Azure AD provide information on Risk Events and Risky Users. Depending on the edition, more features, information and controls become available.

• Azure Active Directory Free merely offers a list of users flagged for risk and a overview of risk events.
• Azure Active Directory Premium (P1) offers more access to the underlying risk events that have been detected for each report.
• Azure Active Directory Premium P2 offers the most detailed information about all underlying risk events and it also enables organizations to configure security policies that automatically respond to configured risk levels. To enable these policies and response mechanisms, admins need to configure Azure AD Identity Protection.

Note: Azure AD Premium 2 is part of the EMS E5 and Microsoft 365 E5 bundles, but can also be bought separately.

Screenshots of  a Azure AD Free edition risk event and Risky user panel:

Screenshots of a Azure AD Identity Protection risk event and Risky User details panel:

Azure AD Identity Protection Configuration Options (P2-only)

This section shows the configuration options that are available for Azure AD Identity protection:

MFA registration

The first configuration item I want to explain is the ability to manage the MFA registration for the user accounts in use within the organization. This ensures that user accounts that are used to sign in to the Azure AD environment need to have the Azure MFA settings in place in order to continue:

The settings are stored in the strongauthenticationdetails attribute. These attributes can be reported upon.

User risk

The second configuration item controls what to do if Azure AD Identity Protection calculates that the user risk reaches the Medium or High thresholds. This risk is of the user object itself.

In the example below, the configuration is shown for the situation in which the user risk is High; the affected person need to change the password for his or her account, before he or she can continue working with it.

Note: When the identities are synchronized for an on-premises environment, it is my advice to enable the self service password reset (SSPR) feature for the Azure AD tenant.

Sign-in risk

The third configuration item governs the action based on the risk level of an actual sign-in session of a user account.

In the example below, the configuration shows that when a sign-in session is calculated to be Medium and above, an additional multi-factor authentication needs to be performed to validate the sign-in attempt:

Azure AD Identity Protection Alerts (P2-only)

When policies are in place, an administrator also should configure the notification e-mails to the intended department, when a risk level of a user account is calculated to be Medium or higher for example:

Here's an example of a notification e-mail and a weekly digest:

User experience

Let's look at the result of the configured policies from an end-user perspective, but also with the admin perspective following through.

Risky sign-in

In this example, my test user logs in via a Tor browser and provides his username and password. After clicking Next the sign-in is processed by Azure AD, Conditional Access and Azure AD Identity Protection. Due to a Tor browser being used, the session is marked suspicious and Azure AD asks me to perform an additional MFA challenge, to verify the sign-in attempt:

After a successful MFA challenge, my test user can continue to use the Office 365 portal:

Azure AD Identity protection will report this session to the configured recipients in the alert page. And also the event is visible in the report, but marked Closed (resolved) due to the MFA challenge resolution in the policy:

User Risk sign-in

When a user account hits a risk level of High, the policy states that he or she should change the password for the account before he or she can continue. I recreated the High user risk level by using the Tor browser again to sign-in several times, starting the MFA challenge, but not completing it on all occasions.

In Azure AD Identity Protection the user account is now listed with a High risk level and the password needs to be changed. The configured alert recipients receive another e-mail with the notification that a user is at risk.

And if the person now tries to login in to the web portal under normal circumstances the following happens:

1. The person who signs in needs to perform an MFA challenge:
   
2. The person needs to update the password for his or her account:
   
3. After a successful change, the person now has access to his or her Office 365 portal:
   

Concluding

Microsoft provides organizations the ability to see if cloud identities are at risk independent of licenses. As an admin, use this to your advantage and take this into account for the health/assessment processes of your environment; include this in your security reports. Additionally, if your tenant is equipped with Azure AD Premium P1 or Premium P2 licenses, ensure you use password protection.

When your Azure AD tenant is using Azure AD Premium P2 licenses, expand your identity defenses with Azure AD Identity Protection. Make use of Microsoft's knowledge and resources to minimize security breaches.