Azure AD Identity Protection PDF

Contents
Identity Protection Documentation

Overview
What is Azure AD Identity Protection?
Concepts
Security overview
What are risks?
Identity Protection policies
What is the sign-in experience?
Identity Protection and B2B users
How-to guides
Configure notifications
Policy configuration
Configure the MFA registration policy
Configure risk policies
Simulate risk detections
Investigate and remediate
Investigate risk
Remediate risk detections and unblock
Use the Microsoft Graph API
Provide feedback on risk detections
FAQs
Reference
Glossary
Resources
Azure feedback forum
MSDN forum
Pricing
Service updates
Stack Overflow
Videos
What is Azure Active Directory Identity Protection?
10/24/2019 • 3 minutes to read • Edit Online
Identity Protection is a tool that allows organizations to accomplish three key tasks:
Automate the detection and remediation of identity-based risks.
Investigate risks using data in the portal.
Export risk detection data to third-party utilities for further analysis.
Identity Protection uses the learnings Microsoft has acquired from their position in organizations with Azure AD,
the consumer space with Microsoft Accounts, and in gaming with Xbox to protect your users. Microsoft analyses
6.5 trillion signals per day to identify and protect customers from threats.
The signals generated by and fed to Identity Protection, can be further fed into tools like Conditional Access to
make access decisions, or fed back to a security information and event management (SIEM ) tool for further
investigation based on your organization's enforced policies.
Why is automation important?

In his blog post in October of 2018 Alex Weinert, who leads Microsoft's Identity Security and Protection team,
explains why automation is so important when dealing with the volume of events:
Each day, our machine learning and heuristic systems provide risk scores for 18 billion login attempts for over
800 million distinct accounts, 300 million of which are discernibly done by adversaries (entities like: criminal
actors, hackers).
At Ignite last year, I spoke about the top 3 attacks on our identity systems. Here is the recent volume of these
attacks
Breach replay: 4.6BN attacks detected in May 2018
Password spray: 350k in April 2018
Phishing: This is hard to quantify exactly, but we saw 23M risk events in March 2018, many of which are
phish related
Risk detection and remediation

Identity Protection identifies risks in the following classifications:
RISK DETECTION TYPE DESCRIPTION
Atypical travel Sign in from an atypical location based on the user’s recent
sign-ins.
Anonymous IP address Sign in from an anonymous IP address (for example: Tor

browser, anonymizer VPNs).
Unfamiliar sign-in properties Sign in with properties we‘ve not seen recently for the given
user.
Malware linked IP address Sign in from a malware linked IP address

RISK DETECTION TYPE DESCRIPTION
Leaked Credentials This risk detection indicates that the user's valid credentials
have been leaked
Azure AD threat intelligence Microsoft’s internal and external threat intelligence sources
have identified a known attack pattern
More detail on these risks and how/when they are calculated can be found in the article, What is risk.
The risk signals can trigger remediation efforts such as requiring users to: perform Azure Multi-Factor
Authentication, reset their password using self-service password reset, or blocking until an administrator takes
action.
Risk investigation
Administrators can review detections and take manual action on them if needed. There are three key reports that
administrators use for investigations in Identity Protection:
Risky users
Risky sign-ins
Risk detections
More information can be found in the article, How To: Investigate risk.
Exporting risk data

Data from Identity Protection can be exported to other tools for archive and further investigation and corelation.
The Microsoft Graph based APIs allow organizations to collect this data for further processing in a tool such as
their SIEM. Information about how to access the Identity Protection API can be found in the article, Get started
with Azure Active Directory Identity Protection and Microsoft Graph
Information about integrating Identity Protection information with Azure Sentinel can be found in the article,
Connect data from Azure AD Identity Protection.
Permissions
Identity Protection requires users be a Security Reader, Security Operator, Security Administrator, Global Reader,
or Global Administrator in order to access.
License requirements
Using this feature requires an Azure AD Premium P2 license. To find the right license for your requirements,
see Comparing generally available features of the Free, Basic, and Premium editions.
CAPABILITY DETAILS AZURE AD PREMIUM P2 AZURE AD PREMIUM P1 AZURE AD BASIC/FREE
Risk policies User risk policy (via Yes No No

Identity Protection)
Risk policies Sign-in risk policy (via Yes No No

Identity Protection or
Conditional Access)
Security reports Overview Yes No No

CAPABILITY DETAILS AZURE AD PREMIUM P2 AZURE AD PREMIUM P1 AZURE AD BASIC/FREE
Security reports Risky users Full access Limited Information Limited Information
Security reports Risky sign-ins Full access Limited Information Limited Information
Security reports Risk detections Full access Limited Information No
Notifications Users at risk detected Yes No No

alerts
Notifications Weekly digest Yes No No
MFA registration Yes No No

policy
Next steps
Security overview
What is risk
Policies available to mitigate risks
Azure Active Directory Identity Protection - Security
overview
The Security overview in the Azure portal gives you an insight into your organization’s security posture. It helps
identify potential attacks and understand the effectiveness of your policies.
The ‘Security overview’ is broadly divided into two sections:
Trends, on the left, provide a timeline of risk in your organization.
Tiles, on the right, highlight the key ongoing issues in your organization and suggest how to quickly take action.
Trends
New risky users detected
This chart shows the number of new risky users that were detected over the chosen time period. You can filter the
view of this chart by user risk level (low, medium, high). Hover over the UTC date increments to see the number of
risky users detected for that day. A click on this chart will bring you to the ‘Risky users’ report. To remediate users
that are at risk, consider changing their password.
New risky sign-ins detected
This chart shows the number of risky sign-ins detected over the chosen time period. You can filter the view of this
chart by the sign-in risk type (real-time or aggregate) and the sign-in risk level (low, medium, high). Unprotected
sign-ins are successful real-time risk sign-ins that were not MFA challenged. (Note: Sign-ins that are risky because
of offline detections cannot be protected in real-time by sign-in risk policies). Hover over the UTC date increments
to see the number of sign-ins detected at risk for that day. A click on this chart will bring you to the ‘Risky sign-ins’
report.
Tiles
High risk users
The ‘High risk users’ tile shows the latest count of users with high probability of identity compromise. These
should be a top priority for investigation. A click on the ‘High risk users’ tile will redirect to a filtered view of the
‘Risky users’ report showing only users with a risk level of high. Using this report, you can learn more and
remediate these users with a password reset.
Medium risk users

The ‘Medium risk users’ tile shows the latest count of users with medium probability of identity compromise. A
click on ‘Medium risk users’ tile will redirect to a filtered view of the ‘Risky users’ report showing only users with a
risk level of medium. Using this report, you can further investigate and remediate these users.
Unprotected risky sign-ins
The ‘Unprotected risky sign-ins' tile shows the last week’s count of successful, real-time risky sign-ins that were
not blocked or MFA challenged by a Conditional Access policy, Identity Protection risk policy, or per-user MFA.
These are potentially compromised logins that were successful and not MFA challenged. To protect such sign-ins
in future, apply a sign-in risk policy. A click on ‘Unprotected risky sign-ins' tile will redirect to the sign-in risk policy
configuration blade where you can configure the sign-in risk policy to require MFA on a sign-in with a specified
risk level.
Legacy authentication
The ‘Legacy authentication’ tile shows the last week’s count of legacy authentications in your organization. Legacy
authentication protocols do not support modern security methods such as an MFA. To prevent legacy
authentication, you can apply a Conditional Access policy. A click on ‘Legacy authentication’ tile will redirect you to
the ‘Identity Secure Score’.
Identity Secure Score
The Identity Secure Score measures and compares your security posture to industry patterns. If you click on
‘Identity Secure Score (Preview )’ tile, it will redirect to the ‘Identity Secure Score’ blade where you can learn more
about improving your security posture.
Next steps
What is risk
What is risk?
Risk detections in Azure AD Identity Protection include any identified suspicious actions related to user accounts
in the directory.
Identity Protection provides organizations access to powerful resources to see and respond quickly to these
suspicious actions.
Risk types and detection

There are two types of risk User and Sign-in and two types of detection or calculation Real-time and Offline.
User risk
A user risk represents the probability that a given identity or account is compromised.
These risks are calculated offline using Microsoft’s internal and external threat intelligence sources including
security researchers, law enforcement professionals, security teams at Microsoft, and other trusted sources.
RISK DETECTION DESCRIPTION

RISK DETECTION DESCRIPTION
Leaked credentials This risk detection type indicates that the user’s valid
credentials have been leaked. When cybercriminals
compromise valid passwords of legitimate users, they often
share those credentials. This sharing is typically done by
posting publicly on the dark web, paste sites, or by trading
and selling the credentials on the black market. When the
Microsoft leaked credentials service acquires user credentials
from the dark web, paste sites, or other sources, they are
checked against Azure AD users' current valid credentials to
find valid matches.
Azure AD threat intelligence This risk detection type indicates user activity that is unusual
for the given user or is consistent with known attack patterns
based on Microsoft’s internal and external threat intelligence
sources.
Sign-in risk
A sign-in risk represents the probability that a given authentication request isn’t authorized by the identity owner.
These risks can be calculated in real-time or calculated offline using Microsoft’s internal and external threat
intelligence sources including security researchers, law enforcement professionals, security teams at Microsoft,
and other trusted sources.
RISK DETECTION DETECTION TYPE DESCRIPTION
Anonymous IP address Real-time This risk detection type indicates sign-

ins from an anonymous IP address (for
example, Tor browser or anonymous
VPN). These IP addresses are typically
used by actors who want to hide their
login telemetry (IP address, location,
device, etc.) for potentially malicious
intent.
Atypical travel Offline This risk detection type identifies two

sign-ins originating from geographically
distant locations, where at least one of
the locations may also be atypical for
the user, given past behavior. Among
several other factors, this machine
learning algorithm takes into account
the time between the two sign-ins and
the time it would have taken for the
user to travel from the first location to
the second, indicating that a different
user is using the same credentials.
The algorithm ignores obvious "false

positives" contributing to the
impossible travel conditions, such as
VPNs and locations regularly used by
other users in the organization. The
system has an initial learning period of
the earliest of 14 days or 10 logins,
during which it learns a new user’s
sign-in behavior.
Malware linked IP address Offline This risk detection type indicates sign-
ins from IP addresses infected with
malware that is known to actively
communicate with a bot server. This
detection is determined by correlating
IP addresses of the user’s device
against IP addresses that were in
contact with a bot server while the bot
server was active.
Unfamiliar sign-in properties Real-time This risk detection type considers past
sign-in history (IP, Latitude / Longitude
and ASN) to look for anomalous sign-
ins. The system stores information
about previous locations used by a
user, and considers these “familiar”
locations. The risk detection is triggered
when the sign-in occurs from a location
that's not already in the list of familiar
locations. Newly created users will be in
“learning mode” for a period of time in
which unfamiliar sign-in properties risk
detections will be turned off while our
algorithms learn the user’s behavior.
The learning mode duration is dynamic
and depends on how much time it
takes the algorithm to gather enough
information about the user’s sign-in
patterns. The minimum duration is five
days. A user can go back into learning
mode after a long period of inactivity.
The system also ignores sign-ins from
familiar devices, and locations that are
geographically close to a familiar
location.
We also run this detection for basic

authentication (or legacy protocols).
Because these protocols do not have
modern properties such as client ID,
there is limited telemetry to reduce
false positives. We recommend our
customers to move to modern
authentication.
Admin confirmed user compromised Offline This detection indicates an admin has
selected ‘Confirm user compromised’ in
the Risky users UI or using riskyUsers
API. To see which admin has confirmed
this user compromised, check the user’s
risk history (via UI or API).
Malicious IP address Offline This detection indicates sign-in from a

malicious IP address. An IP address is
considered malicious based on high
failure rates because of invalid
credentials received from the IP address
or other IP reputation sources.
Other risk detections

Additional risk detected Real-time or Offline This detection indicates that one of the
above premium detections was
detected. Since the premium detections
are visible only to Azure AD Premium
P2 customers, they are titled "additional
risk detected" for customers without
Azure AD Premium P2 licenses.
Next steps
Security overview
Identity Protection policies
Azure Active Directory Identity Protection includes three default policies that administrators can choose to enable.
These policies include limited customization but are applicable to most organizations. All of the policies allow for
excluding users such as your emergency access or break-glass administrator accounts.
Azure MFA registration policy

Identity Protection can help organizations roll out Azure Multi-Factor Authentication (MFA) using a Conditional
Access policy requiring registration at sign-in. Enabling this policy is a great way to ensure new users in your
organization have registered for MFA on their first day. Multi-factor authentication is one of the self-remediation
methods for risk events within Identity Protection. Self-remediation allows your users to take action on their own
to reduce helpdesk call volume.
More information about Azure Multi-Factor Authentication can be found in the article, How it works: Azure Multi-
Factor Authentication.
Sign-in risk policy

Identity Protection analyzes signals from each sign-in, both real-time and offline, and calculates a risk score based
on the probability that the sign-in wasn't performed by the user. Administrators can make a decision based on this
risk score signal to enforce organizational requirements. Administrators can choose to block access, allow access,
or allow access but require multi-factor authentication.
If risk is detected, users can perform multi-factor authentication to self-remediate and close the risky sign-in event
to prevent unnecessary noise for administrators.
NOTE
Users must have previously registered for Azure Multi-Factor Authentication before triggering the sign-in risk policy.
Custom Conditional Access policy
Administrators can also choose to create a custom Conditional Access policy including sign-in risk as an
assignment condition. More information about Conditional Access can be found in the article, What is Conditional
Access?
User risk policy

Identity Protection can calculate what it believes is normal for a user's behavior and use that to base decisions for
their risk. User risk is a calculation of probability that an identity has been compromised. Administrators can make
a decision based on this risk score signal to enforce organizational requirements. Administrators can choose to
block access, allow access, or allow access but require a password change using Azure AD self-service password
reset.
If risk is detected, users can perform self-service password reset to self-remediate and close the user risk event to
prevent unnecessary noise for administrators.
NOTE
Users must have previously registered for self-service password reset before triggering the user risk policy.
Next steps
Enable Azure AD self-service password reset
Enable Azure Multi-Factor Authentication
Enable Azure Multi-Factor Authentication registration policy
Enable sign-in and user risk policies
User experiences with Azure AD Identity Protection
With Azure Active Directory Identity Protection, you can:

Require users to register for Azure Multi-Factor Authentication (MFA)
Automate remediation of risky sign-ins and compromised users
All of the Identity Protection policies have an impact on the sign in experience for users. Allowing users to register
for and use tools like Azure MFA and self-service password reset can lessen the impact. These tools along with the
appropriate policy choices gives users a self-remediation option when they need it.
Multi-factor authentication registration

Enabling the Identity Protection policy requiring multi-factor authentication registration and targeting all of your
users, will make sure that they have the ability to use Azure MFA to self-remediate in the future. Configuring this
policy gives your users a 14-day period where they can choose to register and at the end are forced to register. The
experience for users is outlined below. More information can be found in the end-user documentation in the article,
Overview for two-factor verification and your work or school account.
Registration interrupt
1. At sign-in to any Azure AD -integrated application, the user gets a notification about the requirement to set
up the account for multi-factor authentication. This policy is also triggered in the Windows 10 Out of Box
Experience for new users with a new device.
2. Complete the guided steps to register for Azure Multi-Factor Authentication and complete your sign-in.
Risky sign-in remediation
When an administrator has configured a policy for sign-in risks, the affected users are notified when they try to
sign in and trigger the policies risk level.
Risky sign-in self-remediation
1. The user is informed that something unusual was detected about their sign-in, such as signing in from a
new location, device, or app.
2. The user is required to prove their identity by completing Azure MFA with one of their previously registered
methods.
Risky sign-in administrator unblock
Administrators can choose to block users upon sign-in depending on their risk level. To get unblocked, end users
must contact their IT staff, or they can try signing in from a familiar location or device. Self-remediation by
performing multi-factor authentication is not an option in this case.
IT staff can follow the instructions in the section Unblocking users to allow users to sign back in.
Risky user remediation

When a user risk policy has been configured, users who meet the user risk level probability of compromise must
go through the user compromise recovery flow before they can sign in.
Risky user self-remediation
1. The user is informed that their account security is at risk because of suspicious activity or leaked credentials.
2. The user is required to prove their identity by completing Azure MFA with one of their previously registered
methods.
3. Finally, the user is forced to change their password using self-service password reset since someone else
may have had access to their account.
Risky sign-in administrator unblock

Administrators can choose to block users upon sign-in depending on their risk level. To get unblocked, end users
must contact their IT staff. Self-remediation by performing multi-factor authentication and self-service password
reset is not an option in this case.
IT staff can follow the instructions in the section Unblocking users to allow users to sign back in.
See also
Remediate risks and unblock users
Azure Active Directory Identity Protection
Identity Protection and B2B users
With Azure AD B2B collaboration, organizations can enforce risk-based policies for B2B users using Identity
Protection. These policies be configured in two ways:
Administrators can configure the built-in Identity Protection risk-based policies, that apply to all apps, that
include guest users.
Administrators can configure their Conditional Access policies, using sign-in risk as a condition, that includes
guest users.
How is risk evaluated for B2B collaboration users

The user risk for B2B collaboration users is evaluated at their home directory. The real-time sign-in risk for these
users is evaluated at the resource directory when they try to access the resource.
Limitations of Identity Protection for B2B collaboration users

There are limitations in the implementation of Identity Protection for B2B collaboration users in a resource
directory due to their identity existing in their home directory. The main limitations are as follows:
If a guest user triggers the Identity Protection user risk policy to force password reset, they will be blocked.
This block is due to the inability to reset passwords in the resource directory.
Guest users do not appear in the risky users report. This loss of visibility is due to the risk evaluation
occurring in the B2B user's home directory.
Administrators cannot dismiss or remediate a risky B2B collaboration user in their resource directory. This
loss of functionality is due to administrators in the resource directory not having access to the B2B user's home
directory.
Why can't I remediate risky B2B collaboration users in my directory?
The risk evaluation and remediation for B2B users occurs in their home directory. Due to this fact, the guest users
do not appear in the risky users report in the resource directory and admins in the resource directory cannot force
a secure password reset for these users.
What do I do if a B2B collaboration user was blocked due to a risk-based policy in my organization?
If a risky B2B user in your directory is blocked by your risk-based policy, the user will need to remediate that risk in
their home directory. Users can remediate their risk by performing a secure password reset in their home directory.
If they do not have self-service password reset enabled in their home directory, they will need to contact their own
organization's IT Staff to have an administrator manually dismiss their risk or reset their password.
How do I prevent B2B collaboration users from being impacted by risk-based policies?
Excluding B2B users from your organization's risk-based Conditional Access policies will prevent B2B users from
being impacted or blocked by their risk evaluation. To exclude these B2B users, create a group in Azure AD that
contains all of your organization's guest users. Then, add this group as an exclusion for your built-in Identity
Protection user risk and sign-in risk policies, as well as any Conditional Access policies that use sign-in risk as a
condition.
Next steps
See the following articles on Azure AD B2B collaboration:
What is Azure AD B2B collaboration?
notifications
Azure AD Identity Protection sends two types of automated notification emails to help you manage user risk and
risk detections:
Users at risk detected email
Weekly digest email
This article provides you with an overview of both notification emails.
Users at risk detected email

In response to a detected account at risk, Azure AD Identity Protection generates an email alert with Users at risk
detected as subject. The email includes a link to the Users flagged for risk report. As a best practice, you should
immediately investigate the users at risk.
The configuration for this alert allows you to specify at what user risk level you want the alert to be generated. The
email will be generated when the user's risk level reaches what you have specified; however, you will not receive
new users at risk detected email alerts for this user after they move to this user risk level. For example, if you set
the policy to alert on medium user risk and your user John moves to medium risk, you will receive the users at risk
detected email for John. However, you will not receive a second user at risk detected alert if John then moves to
high risk or has additional risk detections.
Configure users at risk detected alerts

As an administrator, you can set:
The user risk level that triggers the generation of this email - By default, the risk level is set to “High” risk.
The recipients of this email - By default, recipients include all Global Admins. Global Admins can also add
other Global Admins, Security Admins, Security Readers as recipients.
Optionally you can Add additional emails to receive alert notifications this feature is a preview and
users defined must have the appropriate permissions to view the linked reports in the Azure portal.
Configure the users at risk email in the Azure portal under Azure Active Directory > Security > Identity
Protection > Users at risk detected alerts.
Weekly digest email

The weekly digest email contains a summary of new risk detections.
It includes:
Users at risk
Suspicious activities
Detected vulnerabilities
Links to the related reports in Identity Protection
By default, recipients include all Global Admins. Global Admins can also add other Global Admins, Security
Admins, Security Readers as recipients.
Configure weekly digest email
As an administrator, you can switch sending a weekly digest email on or off and choose the users assigned to
receive the email.
Configure the weekly digest email in the Azure portal under Azure Active Directory > Security > Identity
Protection > Weekly digest.
See also
How To: Configure the Azure Multi-Factor
Authentication registration policy
Azure AD Identity Protection helps you manage the roll-out of Azure Multi-Factor Authentication (MFA)
registration by configuring a Conditional Access policy to require MFA registration no matter what modern
authentication app you are signing in to.
What is the Azure Multi-Factor Authentication registration policy?

Azure Multi-Factor Authentication provides a means to verify who you are using more than just a username and
password. It provides a second layer of security to user sign-ins. In order for users to be able to respond to MFA
prompts, they must first register for Azure Multi-Factor Authentication.
We recommend that you require Azure Multi-Factor Authentication for user sign-ins because it:
Delivers strong authentication through a range of verification options.
Plays a key role in preparing your organization to self-remediate from risk detections in Identity Protection.
For more information on Azure Multi-Factor Authentication, see What is Azure Multi-Factor Authentication?
Policy configuration
1. Navigate to the Azure portal.
2. Browse to Azure Active Directory > Security > Identity Protection > MFA registration policy.
a. Under Assignments
a. Users - Choose All users or Select individuals and groups if limiting your rollout.
a. Optionally you can choose to exclude users from the policy.
b. Under Controls
a. Ensure the checkbox Require Azure MFA registration is checked and choose Select.
c. Enforce Policy - On
d. Save
User experience
Azure Active Directory Identity Protection will prompt your users to register the next time they sign in interactively
and they will have 14 days to complete registration. During this 14-day period, they can bypass registration but at
the end of the period they will be required to register before they can complete the sign-in process.
For an overview of the related user experience, see:
Sign-in experiences with Azure AD Identity Protection.
Next steps
Enable Azure AD self-service password reset
Enable Azure Multi-Factor Authentication
How To: Configure and enable risk policies
As we learned in the previous article, Identity Protection policies we have two risk policies that we can enable in
our directory.
Sign-in risk policy
User risk policy
Both policies work to automate the response to risk detections in your environment and allow users to self-
remediate when risk is detected.
Prerequisites
If your organization wants to allow users to self-remediate when risks are detected, users must be registered for
both self-service password reset and Azure Multi-Factor Authentication. We recommend enabling the combined
security information registration experience for the best experience. Allowing users to self-remediate gets them
back to a productive state more quickly without requiring administrator intervention. Administrators can still see
these events and investigate them after the fact.
Choosing acceptable risk levels

Organizations must decide the level of risk they are willing to accept balancing user experience and security
posture.
Microsoft's recommendation is to set the user risk policy threshold to High and the sign-in risk policy to
Medium and above.
Choosing a High threshold reduces the number of times a policy is triggered and minimizes the impact to users.
However, it excludes Low and Medium risk detections from the policy, which may not block an attacker from
exploiting a compromised identity. Selecting a Low threshold introduces additional user interrupts, but increased
security posture.
Exclusions
All of the policies allow for excluding users such as your emergency access or break-glass administrator accounts.
Organizations may determine they need to exclude other accounts from specific policies based on the way the
accounts are used. All exclusions should be reviewed regularly to see if they are still applicable.
Enable policies
To enable the user risk and sign-in risk policies complete the following steps.
2. Browse to Azure Active Directory > Security > Identity Protection > Overview.
3. Select Configure user risk policy.
b. Conditions - User risk Microsoft's recommendation is to set this option to High.
b. Under Controls
a. Access - Microsoft's recommendation is to Allow access and Require password change.
d. Save - This action will return you to the Overview page.
4. Select Configure sign-in risk policy.
b. Conditions - Sign-in risk Microsoft's recommendation is to set this option to Medium and
above.
b. Under Controls
a. Access - Microsoft's recommendation is to Allow access and Require multi-factor
authentication.
d. Save
Next steps
Enable Azure Multi-Factor Authentication registration policy
What is risk
Investigate risk detections
Simulate risk detections
Simulating risk detections in Identity Protection
Administrators may want to simulate risk in their environment in order to accomplish the following items:
Populate data in the Identity Protection environment by simulating risk detections and vulnerabilities.
Set up risk-based Conditional Access policies and test the impact of these policies.
This article provides you with steps for simulating the following risk detection types:
Anonymous IP address (easy)
Unfamiliar sign-in properties (moderate)
Atypical travel (difficult)
Other risk detections cannot be simulated in a secure manner.
More information about each risk detection can be found in the article, What is risk.
Anonymous IP address
Completing the following procedure requires you to use:
The Tor Browser to simulate anonymous IP addresses. You might need to use a virtual machine if your
organization restricts using the Tor browser.
A test account that is not yet registered for Azure Multi-Factor Authentication.
To simulate a sign-in from an anonymous IP, perform the following steps:
1. Using the Tor Browser, navigate to https://myapps.microsoft.com.
2. Enter the credentials of the account you want to appear in the Sign-ins from anonymous IP addresses
report.
The sign-in shows up on the Identity Protection dashboard within 10 - 15 minutes.
Unfamiliar sign-in properties

To simulate unfamiliar locations, you have to sign in from a location and device your test account has not signed in
from before.
The procedure below uses a newly created:
VPN connection, to simulate new location.
Virtual machine, to simulate a new device.
Completing the following procedure requires you to use a user account that has:
At least a 30-day sign-in history.
Azure Multi-Factor Authentication enabled.
To simulate a sign-in from an unfamiliar location, perform the following steps:
1. When signing in with your test account, fail the multi-factor authentication (MFA) challenge by not passing the
MFA challenge.
2. Using your new VPN, navigate to https://myapps.microsoft.com and enter the credentials of your test account.
The sign-in shows up on the Identity Protection dashboard within 10 - 15 minutes.
Atypical travel
Simulating the atypical travel condition is difficult because the algorithm uses machine learning to weed out false-
positives such as atypical travel from familiar devices, or sign-ins from VPNs that are used by other users in the
directory. Additionally, the algorithm requires a sign-in history of 14 days and 10 logins of the user before it
begins generating risk detections. Because of the complex machine learning models and above rules, there is a
chance that the following steps will not lead to a risk detection. You might want to replicate these steps for multiple
Azure AD accounts to simulate this detection.
To simulate an atypical travel risk detection, perform the following steps:
1. Using your standard browser, navigate to https://myapps.microsoft.com.
2. Enter the credentials of the account you want to generate an atypical travel risk detection for.
3. Change your user agent. You can change user agent in Microsoft Edge from Developer Tools (F12).
4. Change your IP address. You can change your IP address by using a VPN, a Tor add-on, or creating a new
virtual machine in Azure in a different data center.
5. Sign-in to https://myapps.microsoft.com using the same credentials as before and within a few minutes after
the previous sign-in.
The sign-in shows up in the Identity Protection dashboard within 2-4 hours.
Testing risk policies

This section provides you with steps for testing the user and the sign-in risk policies created in the article, How To:
Configure and enable risk policies.
User risk policy
To test a user risk security policy, perform the following steps:
2. Browse to Azure Active Directory > Security > Overview.
3. Select Configure user risk policy.
b. Conditions - User risk Microsoft's recommendation is to set this option to High.
b. Under Controls
a. Access - Microsoft's recommendation is to Allow access and Require password change.
c. Enforce Policy - Off
4. Elevate the user risk of a test account by, for example, simulating one of the risk detections a few times.
5. Wait a few minutes, and then verify that risk has elevated for your user. If not, simulate more risk detections for
the user.
6. Return to your risk policy and set Enforce Policy to On and Save your policy change.
7. You can now test user risk-based Conditional Access by signing in using a user with an elevated risk level.
Sign-in risk security policy
To test a sign in risk policy, perform the following steps:
2. Browse to Azure Active Directory > Security > Overview.
3. Select Configure sign-in risk policy.
b. Conditions - Sign-in risk Microsoft's recommendation is to set this option to Medium and
above.
b. Under Controls
a. Access - Microsoft's recommendation is to Allow access and Require multi-factor
authentication.
4. You can now test Sign-in Risk-based Conditional Access by signing in using a risky session (for example, by
using the Tor browser).
Next steps
What is risk?
How To: Configure and enable risk policies
How To: Investigate risk
Identity Protection provides organizations with three reports they can use to investigate identity risks in their
environment. These reports are the risky users, risky sign-ins, and risk detections. Investigation of events is key
to better understanding and identifying any weak points in your security strategy.
All three reports allow for downloading of events in .CSV format for further analysis outside of the Azure portal.
The risky users and risky sign-ins reports allow for downloading the most recent 2500 entries, while the risk
detections report allows for downloading the most recent 5000 records.
Organizations can take advantage of the Microsoft Graph API integrations to aggregate data with other sources
they may have access to as an organization.
The three reports are found in the Azure portal > Azure Active Directory > Security.
Navigating the reports

Each report launches with a list of all detections for the period shown at the top of the report. Each report allows
for the addition or removal of columns based on administrator preference. Administrators can choose to
download the data in .CSV format. Reports can be filtered using the filters across the top of the report.
Selecting individual entries may enable additional entries at the top of the report such as the ability to confirm a
sign-in as compromised or safe, confirm a user as compromised, or dismiss user risk.
Selecting individual entries expands a details window below the detections. The details view allows administrators
to investigate and perform actions on each detection.
Risky users
With the information provided by the risky users report, administrators can find:
Which users are at risk, have had risk remediated, or have had risk dismissed?
Details about detections
History of risky sign-ins
Risk history
Administrators can then choose to take action on these events. Administrators can choose to:
Reset the user password
Confirm user compromise
Dismiss user risk
Block user from signing in
Investigate further using Azure ATP
Risky sign-ins
The risky sign-ins report contains filterable data for up to the past 30 days (1 month).
With the information provided by the risky sign-ins report, administrators can find:
Which sign-ins are classified as at risk, confirmed compromised, confirmed safe, dismissed, or remediated.
Real-time and aggregate risk levels associated with sign-in attempts.
Detection types triggered
Conditional Access policies applied
MFA details
Device information
Application information
Location information
Administrators can then choose to take action on these events. Administrators can choose to:
Confirm sign-in compromise
Confirm sign-in safe
Risk detections
The risk detections report contains filterable data for up to the past 90 days (3 months).
With the information provided by the risk detections report, administrators can find:
Information about each risk detection including type.
Other risks triggered at the same time
Sign-in attempt location
Link out to more detail from Microsoft Cloud App Security (MCAS ).
Administrators can then choose to return to the user's risk or sign-ins report to take actions based on information
gathered.
Next steps
Remediate risks and unblock users
After completing your investigation, you will want to take action to remediate the risk or unblock users.
Organizations also have the option to enable automated remediation using their risk policies. Organizations
should try to close all risk detections that they are presented with in a time period your organization is comfortable
with. Microsoft recommends closing events as soon as possible because time matters when working with risk.
Remediation
All active risk detections contribute to the calculation of a value called user risk level. The user risk level is an
indicator (low, medium, high) for the probability that an account has been compromised. As an administrator, you
want to get all risk detections closed, so that the affected users are no longer at risk.
Some risks detections may be marked by Identity Protection as "Closed (system)" because the events were no
longer determined to be risky.
Administrators have the following options to remediate:
Self-remediation with risk policy
Manual password reset
Dismiss user risk
Close individual risk detections manually
Self-remediation with risk policy
If you allow users to self-remediate, with Azure Multi-Factor Authentication (MFA) and self-service password reset
(SSPR ) in your risk policies, they can unblock themselves when risk is detected. These detections are then
considered closed. Users must have previously registered for Azure MFA and SSPR in order to use when risk is
detected.
Some detections may not raise risk to the level where a user self-remediation would be required but
administrators should still evaluate these detections. Administrators may determine that additional measures are
necessary like blocking access from locations or lowering the acceptable risk in their policies.
Manual password reset
If requiring a password reset using a user risk policy is not an option, administrators can close all risk detections
for a user with a manual password reset.
Administrators are given two options when resetting a password for their users:
Generate a temporary password - By generating a temporary password, you can immediately bring an
identity back into a safe state. This method requires contacting the affected users because they need to
know what the temporary password is. Because the password is temporary, the user is prompted to change
the password to something new during the next sign-in.
Require the user to reset password - Requiring the users to reset passwords enables self-recovery
without contacting help desk or an administrator. This method only applies to users that are registered for
Azure MFA and SSPR. For users that have not been registered, this option isn't available.
Dismiss user risk
If a password reset is not an option for you, because for example the user has been deleted, you can choose to
dismiss user risk detections.
When you click Dismiss user risk, all events are closed and the affected user is no longer at risk. However,
because this method doesn't have an impact on the existing password, it doesn't bring the related identity back into
a safe state.
Close individual risk detections manually
You can close individual risk detections manually. By closing risk detections manually, you can lower the user risk
level. Typically, risk detections are closed manually in response to a related investigation. For example, when
talking to a user reveals that an active risk detection is not required anymore.
When closing risk detections manually, you can choose to take any of the following actions to change the status of
a risk detection:
Confirm user compromised
Dismiss user risk
Confirm sign-in safe
Confirm sign-in compromised
Unblocking users
An administrator may choose to block a sign-in based on their risk policy or investigations. A block may occur
based on either sign-in or user risk.
Unblocking based on user risk
To unblock an account blocked due to user risk, administrators have the following options:
1. Reset password - You can reset the user's password.
2. Dismiss user risk - The user risk policy blocks a user if the configured user risk level for blocking access has
been reached. You can reduce a user's risk level by dismissing user risk or manually closing reported risk
detections.
3. Exclude the user from policy - If you think that the current configuration of your sign-in policy is causing
issues for specific users, you can exclude the users from it. For more information, see the section Exclusions in
the article How To: Configure and enable risk policies.
4. Disable policy - If you think that your policy configuration is causing issues for all your users, you can disable
the policy. For more information, see the article How To: Configure and enable risk policies.
Unblocking based on sign-in risk
To unblock an account based on sign-in risk, administrators have the following options:
1. Sign in from a familiar location or device - A common reason for blocked suspicious sign-ins are sign-in
attempts from unfamiliar locations or devices. Your users can quickly determine whether this reason is the
blocking reason by trying to sign-in from a familiar location or device.
2. Exclude the user from policy - If you think that the current configuration of your sign-in policy is causing
issues for specific users, you can exclude the users from it. For more information, see the section Exclusions in
the article How To: Configure and enable risk policies.
3. Disable policy - If you think that your policy configuration is causing issues for all your users, you can disable
the policy. For more information, see the article How To: Configure and enable risk policies.
Next steps
To get an overview of Azure AD Identity Protection, see the Azure AD Identity Protection overview.
Get started with Azure Active Directory Identity
Protection and Microsoft Graph
Microsoft Graph is the Microsoft unified API endpoint and the home of Azure Active Directory Identity Protection
APIs. There are four APIs that expose information about risky users and sign-ins. The first API, riskDetection,
allows you to query Microsoft Graph for a list of both user and sign-in linked risk detections and associated
information about the detection. The second API, riskyUsers, allows you to query Microsoft Graph for information
about users Identity Protection detected as risk. The third API, signIn, allows you to query Microsoft Graph for
information on Azure AD sign-ins with specific properties related to risk state, detail, and level. The fourth API,
identityRiskEvents, allows you to query Microsoft Graph for a list of risk detections and associated information.
The identityRiskEvents API will be deprecated on January 10, 2020; we suggest you use the riskDetections API
instead. This article gets you started with connecting to the Microsoft Graph and querying these APIs. For an in-
depth introduction, full documentation, and access to the Graph Explorer, see the Microsoft Graph site or the
specific reference documentation for these APIs:
riskDetection API
riskyUsers API
signIn API
identityRiskEvents API Will be deprecated January 10, 2020
Connect to Microsoft graph

There are four steps to accessing Identity Protection data through Microsoft Graph:
1. Retrieve your domain name.
2. Create a new app registration.
3. Use this secret and a few other pieces of information to authenticate to Microsoft Graph, where you receive an
authentication token.
4. Use this token to make requests to the API endpoint and get Identity Protection data back.
Before you get started, you’ll need:
Administrator privileges to create the application in Azure AD
The name of your tenant's domain (for example, contoso.onmicrosoft.com)
Retrieve your domain name

1. Sign in to your Azure portal as an administrator.
2. On the left navigation pane, click Active Directory.
3. In the Manage section, click Properties.
4. Copy your domain name.
Create a new app registration

1. On the Active Directory page, in the Manage section, click App registrations.
2. In the menu on the top, click New application registration.
3. On the Create page, perform the following steps:

a. In the Name textbox, type a name for your application (for example: Azure AD Risk Detection API
Application).
b. As Type, select Web Application And / Or Web API.
c. In the Sign-on URL textbox, type http://localhost .
d. Click Create.
4. To open the Settings page, in the applications list, click your newly created app registration.
5. Copy the Application ID.
Grant your application permission to use the API

1. On the Settings page, click Required permissions.
2. On the Required permissions page, in the toolbar on the top, click Add.
3. On the Add API access page, click Select an API.
4. On the Select an API page, select Microsoft Graph, and then click Select.
5. On the Add API access page, click Select permissions.
6. On the Enable Access page, click Read all identity risk information, and then click Select.
7. On the Add API access page, click Done.

8. On the Required Permissions page, click Grant Permissions, and then click Yes.
Get an access key

1. On the Settings page, click Keys.
2. On the Keys page, perform the following steps:
a. In the Key description textbox, type a description (for example, Azure AD Risk Detection).
b. As Duration, select In 1 year.
c. Click Save.
d. Copy the key value, and then paste it into a safe location.
NOTE
If you lose this key, you will have to return to this section and create a new key. Keep this key a secret: anyone who
has it can access your data.
Authenticate to Microsoft Graph and query the Identity Risk

Detections API
At this point, you should have:
The name of your tenant's domain
The client ID
The key
To authenticate, send a post request to https://login.microsoft.com with the following parameters in the body:
grant_type: “client_credentials”
resource: https://graph.microsoft.com
client_id: <your client ID>
client_secret: <your key>
If successful, this returns an authentication token.
To call the API, create a header with the following parameter:
`Authorization`="<token_type> <access_token>"
When authenticating, you can find the token type and access token in the returned token.
Send this header as a request to the following API URL: https://graph.microsoft.com/beta/identityRiskEvents
The response, if successful, is a collection of identity risk detections and associated data in the OData JSON format,
which can be parsed and handled as you see fit.
Here’s sample code for authenticating and calling the API using PowerShell.
Just add your client ID, the secret key, and the tenant domain.
$ClientID = "<your client ID here>" # Should be a ~36 hex character string; insert your info
here
$ClientSecret = "<your client secret here>" # Should be a ~44 character string; insert your info here
$tenantdomain = "<your tenant domain here>" # For example, contoso.onmicrosoft.com
$loginURL = "https://login.microsoft.com"
$resource = "https://graph.microsoft.com"
$body =
@{grant_type="client_credentials";resource=$resource;client_id=$ClientID;client_secret=$ClientSecret}
$oauth = Invoke-RestMethod -Method Post -Uri $loginURL/$tenantdomain/oauth2/token?api-version=1.0 -
Body $body
Write-Output $oauth
if ($oauth.access_token -ne $null) {

$headerParams = @{'Authorization'="$($oauth.token_type) $($oauth.access_token)"}
$url = "https://graph.microsoft.com/beta/identityRiskEvents"
Write-Output $url
$myReport = (Invoke-WebRequest -UseBasicParsing -Headers $headerParams -Uri $url)
foreach ($event in ($myReport.Content | ConvertFrom-Json).value) {

Write-Output $event
}
} else {
Write-Host "ERROR: No Access Token"
}
Query the APIs

These three APIs provide a multitude of opportunities to retrieve information about risky users and sign-ins in
your organization. Below are some common use cases for these APIs and the associated sample requests. You can
run these queries using the sample code above or by using Graph Explorer.
Get all of the offline risk detections (riskDetection API )
With Identity Protection sign-in risk policies, you can apply conditions when risk is detected in real time. But what
about detections that are discovered offline? To understand what detections occurred offline, and thus would not
have triggered the sign-in risk policy, you can query the riskDetection API.
GET https://graph.microsoft.com/beta/riskDetections?$filter=detectionTimingType eq 'offline'
Get all of the users who successfully passed an MFA challenge triggered by risky sign-ins policy (riskyUsers API )
To understand the impact Identity Protection risk-based policies have on your organization, you can query all of
the users who successfully passed an MFA challenge triggered by a risky sign-ins policy. This information can help
you understand which users Identity Protection may have falsely detected at as risk and which of your legitimate
users may be performing actions that the AI deems risky.
GET https://graph.microsoft.com/beta/riskyUsers?$filter=riskDetail eq 'userPassedMFADrivenByRiskBasedPolicy'
Get all the risky sign-ins for a specific user (signIn API )
When you believe a user may have been compromised, you can better understand the state of their risk by
retrieving all of their risky sign-ins.
https://graph.microsoft.com/beta/identityRiskEvents?`$filter=userID eq '<userID>' and riskState eq 'atRisk'
Next steps
Congratulations, you just made your first call to Microsoft Graph!
Now you can query identity risk detections and use the data however you see fit.
To learn more about Microsoft Graph and how to build applications using the Graph API, check out the
documentation and much more on the Microsoft Graph site.
For related information, see:
Types of risk detections detected by Azure Active Directory Identity Protection
Microsoft Graph
Overview of Microsoft Graph
Azure AD Identity Protection Service Root
How To: Give risk feedback in Azure AD Identity
Protection
Azure AD Identity Protection allows you to give feedback on its risk assessment. The following document lists the
scenarios where you would like to give feedback on Azure AD Identity Protection’s risk assessment and how we
incorporate it.
What is a detection?
An Identity Protection detection is an indicator of suspicious activity from an identity risk perspective. These
suspicious activities are called risk detections. These identity-based detections can be based on heuristics, machine
learning or can come from partner products. These detections are used to determine sign-in risk and user risk,
User risk represents the probability an identity is compromised.
Sign-in risk represents the probability a sign-in is compromised (for example, the sign-in is not authorized by
the identity owner).
Why should I give risk feedback to Azure AD’s risk assessments?

There are several reasons why you should give Azure AD risk feedback:
You found Azure AD’s user or sign-in risk assessment incorrect. For example, a sign-in shown in ‘Risky
sign-ins’ report was benign and all the detections on that sign-in were false positives.
You validated that Azure AD’s user or sign-in risk assessment was correct. For example, a sign-in shown
in ‘Risky sign-ins’ report was indeed malicious and you want Azure AD to know that all the detections on that
sign-in were true positives.
You remediated the risk on that user outside of Azure AD Identity Protection and you want the user’s
risk level to be updated.
How does Azure AD use my risk feedback?

Azure AD uses your feedback to update the risk of the underlying user and/or sign-in and the accuracy of these
events. This feedback helps secure the end user. For example, once you confirm a sign-in is compromised, Azure
AD immediately increases the user’s risk and sign-in’s aggregate risk (not real-time risk) to High. If this user is
included in your user risk policy to force High risk users to securely reset their passwords, the user will
automatically remediate itself the next time they sign-in.
How should I give risk feedback and what happens under the hood?
Here are the scenarios and mechanisms to give risk feedback to Azure AD.
WHAT HAPPENS UNDER THE
SCENARIO HOW TO GIVE FEEDBACK ? HOOD? NOTES
Sign-in not compromised Select the sign-in and click Azure AD will move the sign- Currently, the ‘Confirm sign-
(False positive) on ‘Confirm sign-in safe’. in’s aggregate risk to none in safe’ option is only
‘Risky sign-ins’ report shows [Risk state = Confirmed safe; available in ‘Risky sign-ins’
an at-risk sign-in [Risk state Risk level (Aggregate) = -] report.
= At risk] but that sign-in and will reverse its impact on
was not compromised. the user risk.
Sign-in compromised Select the sign-in and click Azure AD will move the sign- Currently, the ‘Confirm sign-
(True positive) on ‘Confirm sign-in in’s aggregate risk and the in compromised’ option is
‘Risky sign-ins’ report shows compromised’. user risk to High [Risk state only available in ‘Risky sign-
an at-risk sign-in [Risk state = Confirmed compromised; ins’ report.
= At risk] with low risk [Risk Risk level = High].
level (Aggregate) = Low] and
that sign-in was indeed
compromised.
User compromised (True Select the user and click on Azure AD will move the user Currently, the ‘Confirm user
positive) ‘Confirm user compromised’. risk to High [Risk state = compromised’ option is only
‘Risky users’ report shows an Confirmed compromised; available in ‘Risky users’
at-risk user [Risk state = At Risk level = High] and will report.
risk] with low risk [Risk level add a new detection ‘Admin The detection ‘Admin
= Low] and that user was confirmed user confirmed user
indeed compromised. compromised’. compromised’ is shown in
the tab ‘Risk detections not
linked to a sign-in’ in the
‘Risky users’ report.
User remediated outside 1. Select the user and click Azure AD moves the user Clicking ‘Dismiss user risk’
of Azure AD Identity ‘Confirm user compromised’. risk to none [Risk state = will close all risk on the user
Protection (True positive (This process confirms to Dismissed; Risk level = -] and and past sign-ins. This action
+ Remediated) Azure AD that the user was closes the risk on all existing cannot be undone.
‘Risky users’ report shows an indeed compromised.) sign-ins having active risk.
at-risk user and I have 2. Wait for the user’s ‘Risk
subsequently remediated level’ to go to High. (This
the user outside of Azure AD time gives Azure AD the
Identity Protection. needed time to take the
above feedback to the risk
engine.)
3. Select the user and click
‘Dismiss user risk’. (This
process confirms to Azure
AD that the user is no
longer compromised.)
User not compromised Select the user and click Azure AD moves the user Clicking ‘Dismiss user risk’
(False positive) ‘Dismiss user risk’. (This risk to none [Risk state = will close all risk on the user
‘Risky users’ report shows at process confirms to Azure Dismissed; Risk level = -]. and past sign-ins. This action
at-risk user but the user is AD that the user is not cannot be undone.
not compromised. compromised.)
WHAT HAPPENS UNDER THE
SCENARIO HOW TO GIVE FEEDBACK ? HOOD? NOTES
I want to close the user risk Select the user and click Azure AD moves the user Clicking ‘Dismiss user risk’
but I am not sure whether ‘Dismiss user risk’. (This risk to none [Risk state = will close all risk on the user
the user is compromised / process confirms to Azure Dismissed; Risk level = -]. and past sign-ins. This action
safe. AD that the user is no cannot be undone. We
longer compromised.) recommend you remediate
the user by clicking on ‘Reset
password’ or request the
user to securely
reset/change their
credentials.
Feedback on user risk detections in Identity Protection is processed offline and may take some time to update. The
risk processing state column will provide the current state of feedback processing.
Next steps
Azure Active Directory Identity Protection risk detections reference
Frequently asked questions Identity Protection in
Azure Active Directory
Dismiss user risk known issues

Dismiss user risk in classic Identity Protection sets the actor in the user’s risk history in Identity Protection to
Azure AD.
Dismiss user risk in Identity Protection sets the actor in the user’s risk history in Identity Protection to <Admin’s
name with a hyperlink pointing to user’s blade>.
There is a current known issue causing latency in the user risk dismissal flow. If you have a "User risk policy", this
policy will stop applying to dismissed users within minutes of clicking on "Dismiss user risk". However, there are
known delays with the UX refreshing the "Risk state" of dismissed users. As a workaround, refresh the page on the
browser level to see the latest user "Risk state".
Risky users report known issues

Queries on the username field are case-sensitive, while queries on the Name field are case-agnostic.
Toggling Show dates as hides the RISK LAST UPDATED column. To readd the column click Columns at the top
of the Risky Users blade.
Dismiss all events in classic Identity Protection sets the status of the risk detections to Closed (resolved).
Risky sign-ins report known issues

Resolve on a risk detection sets the status to Users passed MFA driven by risk-based policy.
Frequently asked questions

Why can’t I set my own risk levels for each risk detection?
Risk levels in Identity Protection are based on the precision of the detection and powered by our supervised
machine learning. To customize what experience users are presented, administrator can include/exclude certain
users/groups from the User Risk and Sign-In Risk Policies.
Why does the location of a sign-in not match where the user truly signed in from?
IP geolocation mapping is an industry-wide challenge. If you feel that the location listed in the sign-ins report does
not match the actual location, reach out to Microsoft support.
How do the feedback mechanisms in Identity Protection work?
Confirm compromised (on a sign-in) – Informs Azure AD Identity Protection that the sign-in was not performed
by the identity owner and indicates a compromise.
Upon receiving this feedback, we move the sign-in and user risk state to Confirmed compromised and
risk level to High.
In addition, we provide the information to our machine learning systems for future improvements in risk
assessment.
NOTE
If the user is already remediated, don't click Confirm compromised because it moves the sign-in and user risk state
to Confirmed compromised and risk level to High.
Confirm safe (on a sign-in) – Informs Azure AD Identity Protection that the sign-in was performed by the identity
owner and does not indicate a compromise.
Upon receiving this feedback, we move the sign-in (not the user) risk state to Confirmed safe and the risk
level to -.
In addition, we provide the information to our machine learning systems for future improvements in risk
assessment.
NOTE
If you believe the user is not compromised, use Dismiss user risk on the user level instead of using Confirmed safe
on the sign-in level. A Dismiss user risk on the user level closes the user risk and all past risky sign-ins and risk
detections.
Why am I seeing a user with a low (or above ) risk score, even if no risky sign-ins or risk detections are shown in
Identity Protection?
Given the user risk is cumulative in nature and does not expire, a user may have a user risk of low or above even if
there are no recent risky sign-ins or risk detections shown in Identity Protection. This situation could happen if the
only malicious activity on a user took place beyond the timeframe for which we store the details of risky sign-ins
and risk detections. We do not expire user risk because bad actors have been known to stay in customers'
environment over 140 days behind a compromised identity before ramping up their attack. Customers can review
the user's risk timeline to understand why a user is at risk by going to:
Azure Portal > Azure Active Directory > Risky users’ report > Click on an at-risk user > Details’ drawer > Risk
history tab
Why does a sign-in have a “sign-in risk (aggregate )” score of High when the detections associated with it are of
low or medium risk?
The high aggregate risk score could be based on other features of the sign-in, or the fact that more than one
detection fired for that sign-in. And conversely, a sign-in may have a sign-in risk (aggregate) of Medium even if the
detections associated with the sign-in are of High risk.
Azure Active Directory Identity Protection Glossary
At risk (User)
A user with one or more active risk detections.
Atypical sign-in location
A sign-in from a geographic location that is not typical for the specific user, similar users, or the tenant.
Azure AD Identity Protection
A security module of Azure Active Directory that provides a consolidated view into risk detections and potential
vulnerabilities affecting an organization’s identities.
Conditional Access
A policy for securing access to resources. Conditional Access rules are stored in the Azure Active Directory and are
evaluated by Azure AD before granting access to the resource. Example rules include restricting access based on
user location, device health, or user authentication method.
Credentials
Information that includes identification and proof of identification that is used to gain access to local and network
resources. Examples of credentials are user names and passwords, smart cards, and certificates.
Event
A record of an activity in Azure Active Directory.
False -positive (risk detection)
A risk detection status set manually by an Identity Protection user, indicating that the risk detection was
investigated and was incorrectly flagged as a risk detection.
Identity
A person or entity that must be verified by means of authentication, based on criteria such as password or a
certificate.
Identity risk detection
Azure AD event that was flagged as anomalous by Identity Protection, and may indicate that an identity has been
compromised.
Ignored (risk detection)
A risk detection status set manually by an Identity Protection user, indicating that the risk detection is closed
without taking a remediation action.
Impossible travel from atypical locations
A risk detection triggered when two sign-ins for the same user are detected, where at least one of them is from an
atypical sign-in location, and where the time between the sign-ins is shorter than the minimum time it would take
to physically travel between these locations.
Investigation
The process of reviewing the activities, logs, and other relevant information related to a risk detection to decide
whether remediation or mitigation steps are necessary, understand if and how the identity was compromised, and
understand how the compromised identity was used.
Leaked credentials
A risk detection triggered when current user credentials (user name and password) are found posted publicly in the
Dark web by our researchers.
Mitigation
An action to limit or eliminate the ability of an attacker to exploit a compromised identity or device without
restoring the identity or device to a safe state. A mitigation does not resolve previous risk detections associated
with the identity or device.
Multi-factor authentication
An authentication method that requires two or more authentication methods, which may include something the
user has, such a certificate; something the user knows, such as user names, passwords, or pass phrases; physical
attributes, such as a thumbprint; and personal attributes, such as a personal signature.
Offline detection
The detection of anomalies and evaluation of the risk of an event such as sign-in attempt after the fact, for an event
that has already happened.
Policy condition
A part of a security policy, which defines the entities (groups, users, apps, device platforms, Device states, IP ranges,
client types) included in the policy or excluded from it.
Policy rule
The part of a security policy that describes the circumstances that would trigger the policy, and the actions taken
when the policy is triggered.
Prevention
An action to prevent damage to the organization through abuse of an identity or device suspected or know to be
compromised. A prevention action does not secure the device or identity, and does not resolve previous risk
detections.
Privileged (user)
A user that at the time of a risk detection, had permanent or temporary admin permissions to one or more
resources in Azure Active Directory, such as a Global Administrator, Billing Administrator, Service Administrator,
User administrator, and Password Administrator.
Real-time
See Real-time detection.
Real-time detection
The detection of anomalies and evaluation of the risk of an event such as sign-in attempt before the event is
allowed to proceed.
Remediated (risk detection)
A risk detection status set automatically by Identity Protection, indicating that the risk detection was remediated
using the standard remediation action for this type of risk detection. For example, when the user password is reset,
many risk detections that indicate that the previous password was compromised are automatically remediated.
Remediation
An action to secure an identity or a device that were previously suspected or known to be compromised. A
remediation action restores the identity or device to a safe state, and resolves previous risk detections associated
with the identity or device.
Resolved (risk detection)
A risk detection status set manually by an Identity Protection user, indicating that the user took an appropriate
remediation action outside Identity Protection, and that the risk detection should be considered closed.
Risk detection status
A property of a risk detection, indicating whether the event is active, and if closed, the reason for closing it.
Risk detection type
A category for the risk detection, indicating the type of anomaly that caused the event to be considered risky.
Risk level (risk detection)
An indication (High, Medium, or Low ) of the severity of the risk detection to help Identity Protection users prioritize
the actions they take to reduce the risk to their organization.
Risk level (sign-in)
An indication (High, Medium, or Low ) of the likelihood that for a specific sign-in, someone else is attempting to use
the user’s identity.
Risk level (user compromise )
An indication (High, Medium, or Low ) of the likelihood that an identity has been compromised.
Risk level (vulnerability)
An indication (High, Medium, or Low ) of the severity of the vulnerability to help Identity Protection users prioritize
the actions they take to reduce the risk to their organization.
Secure (identity)
Take remediation action such as a password change or machine reimaging to restore a potentially compromised
identity to an uncompromised state.
Security policy
A collection of policy rules and condition. A policy can be applied to entities such as users, groups, apps, devices,
device platforms, device states, IP ranges, and Auth2.0 client types. When a policy is enabled, it is evaluated
whenever an entity included in the policy is issued a token for a resource.
Sign in (v)
To authenticate to an identity in Azure Active Directory.
Sign-in (n)
The process or action of authenticating an identity in Azure Active Directory, and the event that captures this
operation.
Sign in from anonymous IP address
A risk detection triggered after a successful sign-in from IP address that has been identified as an anonymous
proxy IP address.
Sign in from infected device
A risk detection triggered when a sign-in originates from an IP address, which is known to be used by one or more
compromised devices, which are actively attempting to communicate with a bot server.
Sign in from IP address with suspicious activity
A risk detection triggered after a successful sign-in from an IP address with a high number of failed login attempts
across multiple user accounts over a short period of time.
Sign in from unfamiliar location
A risk detection triggered when a user successfully signs in from a new location (IP, Latitude/Longitude, and ASN ).
Sign-in risk
See Risk level (sign-in)
Sign-in risk policy
A Conditional Access policy that evaluates the risk to a specific sign-in and applies mitigations based on predefined
conditions and rules.
User compromise risk
See Risk level (user compromise)
User risk
See Risk level (user compromise).
User risk policy
A Conditional Access policy that considers the sign-in and applies mitigations based on predefined conditions and
rules.
Users flagged for risk
Users that have risk detections, which are either active or remediated
Vulnerability
A configuration or condition in Azure Active Directory, which makes the directory susceptible to exploits or threats.
See also
What's new in Azure Active Directory?
Get notified about when to revisit this page for updates by copying and pasting this URL:
https://docs.microsoft.com/api/search/rss?search=%22release+notes+for+azure+AD%22&locale=en-us into your
feed reader.
Azure AD receives improvements on an ongoing basis. To stay up-to-date with the most recent developments, this
article provides you with information about:
The latest releases
Known issues
Bug fixes
Deprecated functionality
Plans for changes
This page is updated monthly, so revisit it regularly. If you're looking for items that are older than six months, you
can find them in the Archive for What's new in Azure Active Directory.
October 2019
Deprecation of the identityRiskEvent API for Azure AD Identity Protection risk detections
Type: Plan for change
Service category: Identity Protection
Product capability: Identity Security & Protection
In response to developer feedback, Azure AD Premium P2 subscribers can now perform complex queries on Azure
AD Identity Protection’s risk detection data by using the new riskDetection API for Microsoft Graph. The existing
identityRiskEvent API beta version will stop returning data around January 10, 2020. If your organization is using
the identityRiskEvent API, you should transition to the new riskDetection API.
For more information about the new riskDetection API, see the Risk detection API reference documentation.
Application Proxy support for the SameSite Attribute and Chrome 80

Service category: App Proxy
Product capability: Access Control
A couple of weeks prior to the Chrome 80 browser release, we plan to update how Application Proxy cookies treat
the SameSite attribute. With the release of Chrome 80, any cookie that doesn't specify the SameSite attribute will
be treated as though it was set to SameSite=Lax .
To help avoid potentially negative impacts due to this change, we're updating Application Proxy access and session
cookies by:
Setting the default value for the Use Secure Cookie setting to Yes.
Setting the default value for the SameSite attribute to None.
NOTE
Application Proxy access cookies have always been transmitted exclusively over secure channels. These changes only
apply to session cookies.
For more information about the Application Proxy cookie settings, see Cookie settings for accessing on-premises
applications in Azure Active Directory.
App registrations (legacy) and converged app management from the Application Registration Portal
(apps.dev.microsoft.com) will no longer be available
Service category: N/A
Product capability: Developer Experience
In the near future, users with Azure AD accounts will no longer be able to register and manage converged
applications using the Application Registration Portal (apps.dev.microsoft.com), or register and manage
applications in the App registrations (legacy) experience in the Azure portal.
To learn more about the new App registrations experience, see the App registrations in the Azure portal training
guide.
Users are no longer required to re -register during migration from per-user MFA to Conditional Access-based
MFA
Type: Fixed
Service category: MFA
We've fixed a known issue whereby when users were required to re-register if they were disabled for per-user
Multi-Factor Authentication (MFA) and then enabled for MFA through a Conditional Access policy.
To require users to re-register, you can select the Required re-register MFA option from the user's authentication
methods in the Azure AD portal. For more information about migrating users from per-user MFA to Conditional
Access-based MFA, see Convert users from per-user MFA to Conditional Access based MFA.
New capabilities to transform and send claims in your SAML token

Type: New feature
Service category: Enterprise Apps
Product capability: SSO
We've added additional capabilities to help you to customize and send claims in your SAML token. These new
capabilities include:
Additional claims transformation functions, helping you to modify the value you send in the claim.
Ability to apply multiple transformations to a single claim.
Ability to specify the claim source, based on the user type and the group to which the user belongs.
For detailed information about these new capabilities, including how to use them, see Customize claims issued in
the SAML token for enterprise applications.
New My Sign-ins page for end users in Azure AD

Type: New feature
Service category: Authentications (Logins)
Product capability: Monitoring & Reporting
We've added a new My Sign-ins page (https://mysignins.microsoft.com) to let your organization's users view their
recent sign-in history to check for any unusual activity. This new page allows your users to see:
If anyone is attempting to guess their password.
If an attacker successfully signed in to their account and from what location.
What apps the attacker tried to access.
For more information, see the Users can now check their sign-in history for unusual activity blog.
Migration of Azure AD Domain Services (Azure AD DS ) from classic to Azure Resource Manager virtual
networks
Type: New feature
Service category: Azure AD Domain Services
Product capability: Azure AD Domain Services
To our customers who have been stuck on classic virtual networks -- we have great news for you! You can now
perform a one-time migration from a classic virtual network to an existing Resource Manager virtual network.
After moving to the Resource Manager virtual network, you'll be able to take advantage of the additional and
upgraded features such as, fine-grained password policies, email notifications, and audit logs.
For more information, see Preview - Migrate Azure AD Domain Services from the Classic virtual network model to
Resource Manager.
Updates to the Azure AD B2C page contract layout

Type: New feature
Service category: B2C - Consumer Identity Management
Product capability: B2B/B2C
We've introduced some new changes to version 1.2.0 of the page contract for Azure AD B2C. In this updated
version, you can now control the load order for your elements, which can also help to stop the flicker that happens
when the style sheet (CSS ) is loaded.
For a full list of the changes made to the page contract, see the Version change log.
Update to the My Apps page along with new Workspaces (Public preview)
Type: New feature
Service category: My Apps
You can now customize the way your organization's users view and access the brand-new My Apps experience,
including using the new Workspaces feature to make it easier for them to find apps. The new Workspaces
functionality acts as a filter for the apps your organization's users already have access to.
For more information on rolling out the new My Apps experience and creating Workspaces, see Create workspaces
on the My Apps (preview ) portal.
Support for the monthly active user-based billing model (General availability)
Type: New feature
Service category: B2C - Consumer Identity Management
Azure AD B2C now supports monthly active users (MAU ) billing. MAU billing is based on the number of unique
users with authentication activity during a calendar month. Existing customers can switch to this new billing
method at any time.
Starting on November 1, 2019, all new customers will automatically be billed using this method. This billing
method benefits customers through cost benefits and the ability to plan ahead.
For more information, see Upgrade to monthly active users billing model.
Consolidated Security menu item in the Azure AD portal

Type: Changed feature
You can now access all of the available Azure AD security features from the new Security menu item, and from the
Search bar, in the Azure portal. Additionally, the new Security landing page, called Security - Getting started,
will provide links to our public documentation, security guidance, and deployment guides.
The new Security menu includes:
Conditional Access
Identity Protection
Security Center
Identity Secure Score
Authentication methods
MFA
Risk reports - Risky users, Risky sign-ins, Risk detections
And more...
For more information, see Security - Getting started.
Office 365 groups expiration policy enhanced with autorenewal

Service category: Group Management
Product capability: Identity Lifecycle Management
The Office 365 groups expiration policy has been enhanced to automatically renew groups that are actively in use
by its members. Groups will be autorenewed based on user activity across all the Office 365 apps, including
Outlook, SharePoint, and Teams.
This enhancement helps to reduce your group expiration notifications and helps to make sure that active groups
continue to be available. If you already have an active expiration policy for your Office 365 groups, you don't need
to do anything to turn on this new functionality.
For more information, see Configure the expiration policy for Office 365 groups.
Updated Azure AD Domain Services (Azure AD DS ) creation experience

We've updated Azure AD Domain Services (Azure AD DS ) to include a new and improved creation experience,
helping you to create a managed domain in just three clicks! In addition, you can now upload and deploy Azure AD
DS from a template.
For more information, see Tutorial: Create and configure an Azure Active Directory Domain Services instance.
September 2019
Plan for change: Deprecation of the Power BI content packs
Service category: Reporting
Starting on October 1, 2019, Power BI will begin to deprecate all content packs, including the Azure AD Power BI
content pack. As an alternative to this content pack, you can use Azure AD Workbooks to gain insights into your
Azure AD -related services. Additional workbooks are coming, including workbooks about Conditional Access
policies in report-only mode, app consent-based insights, and more.
For more information about the workbooks, see How to use Azure Monitor workbooks for Azure Active Directory
reports. For more information about the deprecation of the content packs, see the Announcing Power BI template
apps general availability blog post.
My Profile is renaming and integrating with the Microsoft Office account page
Service category: My Profile/Account
Product capability: Collaboration
Starting in October, the My Profile experience will become My Account. As part of that change, everywhere that
currently says, My Profile will change to My Account. On top of the naming change and some design
improvements, the updated experience will offer additional integration with the Microsoft Office account page.
Specifically, you'll be able to access Office installations and subscriptions from the Overview Account page, along
with Office-related contact preferences from the Privacy page.
For more information about the My Profile (preview ) experience, see My Profile (preview ) portal overview .
Bulk manage groups and members using CSV files in the Azure AD portal (Public Preview)
Type: New feature
We're pleased to announce public preview availability of the bulk group management experiences in the Azure AD
portal. You can now use a CSV file and the Azure AD portal to manage groups and member lists, including:
Adding or removing members from a group.
Downloading the list of groups from the directory.
Downloading the list of group members for a specific group.
For more information, see Bulk add members, Bulk remove members, Bulk download members list, and Bulk
download groups list.
Dynamic consent is now supported through a new admin consent endpoint

Type: New feature
Product capability: User Authentication
We've created a new admin consent endpoint to support dynamic consent, which is helpful for apps that want to
use the dynamic consent model on the Microsoft Identity platform.
For more information about how to use this new endpoint, see Using the admin consent endpoint.
New Azure AD Global Reader role

Type: New feature
Service category: RBAC
Starting on September 24, 2019, we're going to start rolling out a new Azure Active Directory (AD ) role called
Global Reader. This rollout will start with production and Global cloud customers (GCC ), finishing up worldwide in
October.
The Global Reader role is the read-only counterpart to Global Administrator. Users in this role can read settings
and administrative information across Microsoft 365 services, but can't take management actions. We’ve created
the Global Reader role to help reduce the number of Global Administrators in your organization. Because Global
Administrator accounts are powerful and vulnerable to attack, we recommend that you have fewer than five Global
Administrators. We recommend using the Global Reader role for planning, audits, or investigations. We also
recommend using the Global Reader role in combination with other limited administrator roles, like Exchange
Administrator, to help get work done without requiring the Global Administrator role.
The Global Reader role works with the new Microsoft 365 Admin Center, Exchange Admin Center, Teams Admin
Center, Security Center, Compliance Center, Azure AD Admin Center, and the Device Management Admin Center.
NOTE
At the start of public preview, the Global Reader role won't work with: SharePoint, Privileged Access Management, Customer
Lockbox, sensitivity labels, Teams Lifecycle, Teams Reporting & Call Analytics, Teams IP Phone Device Management, and
Teams App Catalog. All of these services are intended to work with the role in the future.
For more information, see Administrator role permissions in Azure Active Directory.
Access an on-premises Report Server from your Power BI Mobile app using Azure Active Directory Application
Proxy
Type: New feature
New integration between the Power BI mobile app and Azure AD Application Proxy allows you to securely sign in
to the Power BI mobile app and view any of your organization's reports hosted on the on-premises Power BI
Report Server.
For information about the Power BI Mobile app, including where to download the app, see the Power BI site. For
more information about how to set up the Power BI mobile app with Azure AD Application Proxy, see Enable
remote access to Power BI Mobile with Azure AD Application Proxy.
New version of the AzureADPreview PowerShell module is available

Service category: Other
Product capability: Directory
New cmdlets were added to the AzureADPreview module, to help define and assign custom roles in Azure AD,
including:
Add-AzureADMSFeatureRolloutPolicyDirectoryObject
Get-AzureADMSFeatureRolloutPolicy
New-AzureADMSFeatureRolloutPolicy
Remove-AzureADMSFeatureRolloutPolicy
Remove-AzureADMSFeatureRolloutPolicyDirectoryObject
Set-AzureADMSFeatureRolloutPolicy
New version of Azure AD Connect

We've released an updated version of Azure AD Connect for auto-upgrade customers. This new version includes
several new features, improvements, and bug fixes. For more information about this new version, see Azure AD
Connect: Version release history.
Azure Multi-Factor Authentication (MFA ) Server, version 8.0.2 is now available

Type: Fixed
If you're an existing customer, who activated MFA Server prior to July 1, 2019, you can now download the latest
version of MFA Server (version 8.0.2). In this new version, we:
Fixed an issue so when Azure AD sync changes a user from Disabled to Enabled, an email is sent to the user.
Fixed an issue so customers can successfully upgrade, while continuing to use the Tags functionality.
Added the Kosovo (+383) country code.
Added one-time bypass audit logging to the MultiFactorAuthSvc.log.
Improved performance for the Web Service SDK.
Fixed other minor bugs.
Starting July 1, 2019, Microsoft stopped offering MFA Server for new deployments. New customers who require
multi-factor authentication should use cloud-based Azure Multi-Factor Authentication. For more information, see
Planning a cloud-based Azure Multi-Factor Authentication deployment.
August 2019
Enhanced search, filtering, and sorting for groups is available in the Azure AD portal (Public Preview)
Type: New feature
We're pleased to announce public preview availability of the enhanced groups-related experiences in the Azure AD
portal. These enhancements help you better manage groups and member lists, by providing:
Advanced search capabilities, such as substring search on groups lists.
Advanced filtering and sorting options on member and owner lists.
New search capabilities for member and owner lists.
More accurate group counts for large groups.
For more information, see Manage groups in the Azure portal.
New custom roles are available for app registration management (Public Preview)
Type: New feature
Service category: RBAC
Custom roles (available with an Azure AD P1 or P2 subscription) can now help provide you with fine-grained
access, by letting you create role definitions with specific permissions and then to assign those roles to specific
resources. Currently, you create custom roles by using permissions for managing app registrations and then
assigning the role to a specific app. For more information about custom roles, see Custom administrator roles in
Azure Active Directory (preview ).
If you need additional permissions or resources supported, which you don’t currently see, you can send feedback
to our Azure feedback site and we’ll add your request to our update road map.
New provisioning logs can help you monitor and troubleshoot your app provisioning deployment (Public
Preview)
Type: New feature
Service category: App Provisioning
New provisioning logs are available to help you monitor and troubleshoot the user and group provisioning
deployment. These new log files include information about:
What groups were successfully created in ServiceNow
What roles were imported from Amazon Web Services (AWS )
What employees weren't imported from Workday
For more information, see Provisioning reports in the Azure Active Directory portal (preview ) .
New security reports for all Azure AD administrators (General Availability)

Type: New feature
By default, all Azure AD administrators will soon be able to access modern security reports within Azure AD. Until
the end of September, you will be able to use the banner at the top of the modern security reports to return to the
old reports.
The modern security reports will provide additional capabilities from the older versions, including:
Advanced filtering and sorting
Bulk actions, such as dismissing user risk
Confirmation of compromised or safe entities
Risk state, covering: At risk, Dismissed, Remediated, and Confirmed compromised
New risk-related detections (available to Azure AD Premium subscribers)
For more information, see Risky users, Risky sign-ins, and Risk detections.
User-assigned managed identity is available for Virtual Machines and Virtual Machine Scale Sets (General
Availability)
Type: New feature
Service category: Managed identities for Azure resources
User-assigned managed identities are now generally available for Virtual Machines and Virtual Machine Scale
Sets. As part of this, Azure can create an identity in the Azure AD tenant that's trusted by the subscription in use,
and can be assigned to one or more Azure service instances. For more information about user-assigned managed
identities, see What is managed identities for Azure resources?.
Users can reset their passwords using a mobile app or hardware token (General Availability)
Service category: Self Service Password Reset
Users who have registered a mobile app with your organization can now reset their own password by approving a
notification from the Microsoft Authenticator app or by entering a code from their mobile app or hardware token.
For more information, see How it works: Azure AD self-service password reset. For more information about the
user experience, see Reset your own work or school password overview.
ADAL.NET ignores the MSAL.NET shared cache for on-behalf-of scenarios

Type: Fixed
Starting with Azure AD authentication library (ADAL.NET) version 5.0.0-preview, app developers must serialize
one cache per account for web apps and web APIs. Otherwise, some scenarios using the on-behalf-of flow, along
with some specific use cases of UserAssertion , may result in an elevation of privilege. To avoid this vulnerability,
ADAL.NET now ignores the Microsoft authentication library for dotnet (MSAL.NET) shared cache for on-behalf-of
scenarios.
For more information about this issue, see Azure Active Directory Authentication Library Elevation of Privilege
Vulnerability.
New Federated Apps available in Azure AD App gallery - August 2019

Type: New feature
Product capability: 3rd Party Integration
In August 2019, we've added these 26 new apps with Federation support to the app gallery:
Civic Platform, Amazon Business, ProNovos Ops Manager, Cognidox, Viareport's Inativ Portal (Europe), Azure
Databricks, Robin, Academy Attendance, Priority Matrix, Cousto MySpace, Uploadcare, Carbonite Endpoint
Backup, CPQSync by Cincom, Chargebee, deliver.media™ Portal, Frontline Education, F5, stashcat AD connect,
Blink, Vocoli, ProNovos Analytics, Sigstr, Darwinbox, Watch by Colors, Harness, EAB Navigate Strategic Care
For more information about the apps, see SaaS application integration with Azure Active Directory. For more
information about listing your application in the Azure AD app gallery, see List your application in the Azure Active
Directory application gallery.
New versions of the AzureAD PowerShell and AzureADPreview PowerShell modules are available
New updates to the AzureAD and AzureAD Preview PowerShell modules are available:
A new -Filter parameter was added to the Get-AzureADDirectoryRole parameter in the AzureAD module.
This parameter helps you filter on the directory roles returned by the cmdlet.
New cmdlets were added to the AzureADPreview module, to help define and assign custom roles in Azure
AD, including:
Get-AzureADMSRoleAssignment
Get-AzureADMSRoleDefinition
New-AzureADMSRoleAssignment
New-AzureADMSRoleDefinition
Remove-AzureADMSRoleAssignment
Remove-AzureADMSRoleDefinition
Set-AzureADMSRoleDefinition
Improvements to the UI of the dynamic group rule builder in the Azure portal
We've made some UI improvements to the dynamic group rule builder, available in the Azure portal, to help you
more easily set up a new rule, or change existing rules. This design improvement allows you to create rules with up
to five expressions, instead of just one. We've also updated the device property list to remove deprecated device
properties.
For more information, see Manage dynamic membership rules.
New Microsoft Graph app permission available for use with access reviews
Service category: Access Reviews
Product capability: Identity Governance
We've introduced a new Microsoft Graph app permission, AccessReview.ReadWrite.Membership , which allows apps
to automatically create and retrieve access reviews for group memberships and app assignments. This permission
can be used by your scheduled jobs or as part of your automation, without requiring a logged-in user context.
For more information, see the Example how to create Azure AD access reviews using Microsoft Graph app
permissions with PowerShell blog.
Azure AD activity logs are now available for government cloud instances in Azure Monitor
We're excited to announce that Azure AD activity logs are now available for government cloud instances in Azure
Monitor. You can now send Azure AD logs to your storage account or to an event hub to integrate with your SIEM
tools, like Sumologic, Splunk, and ArcSight.
For more information about setting up Azure Monitor, see Azure AD activity logs in Azure Monitor.
Update your users to the new, enhanced security info experience

On September 25, 2019, we'll be turning off the old, non-enhanced security info experience for registering and
managing user security info and only turning on the new, enhanced version. This means that your users will no
longer be able to use the old experience.
For more information about the enhanced security info experience, see our admin documentationandour user
documentation.
To turn on this new experience, you must:
1. Sign in to the Azure portal as a Global Administrator or User Administrator.
2. Go toAzure Active Directory>User settings>Manage settings for access panel preview features.
3. In the Users can use preview features for registering and managing security info - enhanced area,
select Selected, and then either choose a group of users or choose All to turn this feature on for all users in
the tenant.
4. In the Users can use preview features for registering and managing security info area, select None.
5. Save your settings.
After you save your settings you'll no longer have access to the old security info experience.
IMPORTANT
If you don't complete these steps before September 25, 2019, your Azure Active Directory tenant will be automatically
enabled for the enhanced experience. If you have questions, please contact us at registrationpreview@microsoft.com.
Authentication requests using POST logins will be more strictly validated

Product capability: Standards
Starting on September 2, 2019, authentication requests using the POST method will be more strictly validated
against the HTTP standards. Specifically, spaces and double-quotes (") will no longer be removed from request
form values. These changes aren't expected to break any existing clients, and will help to make sure that requests
sent to Azure AD are reliably handled every time.
For more information, see the Azure AD breaking changes notices.
July 2019
Plan for change: Application Proxy service update to support only TLS 1.2
To help provide you with our strongest encryption, we're going to begin limiting Application Proxy service access
to only TLS 1.2 protocols. This limitation will initially be rolled out to customers who are already using TLS 1.2
protocols, so you won't see the impact. Complete deprecation of the TLS 1.0 and TLS 1.1 protocols will be
complete on August 31, 2019. Customers still using TLS 1.0 and TLS 1.1 will receive advanced notice to prepare
for this change.
To maintain the connection to the Application Proxy service throughout this change, we recommend that you make
sure your client-server and browser-server combinations are updated to use TLS 1.2. We also recommend that you
make sure to include any client systems used by your employees to access apps published through the Application
Proxy service.
For more information, see Add an on-premises application for remote access through Application Proxy in Azure
Active Directory.
Plan for change: Design updates are coming for the Application Gallery
Product capability: SSO
New user interface changes are coming to the design of the Add from the gallery area of the Add an
application blade. These changes will help you more easily find your apps that support automatic provisioning,
OpenID Connect, Security Assertion Markup Language (SAML ), and Password single sign-on (SSO ).
Plan for change: Removal of the MFA server IP address from the Office 365 IP address
We're removing the MFA server IP address from the Office 365 IP Address and URL Web service. If you currently
rely on these pages to update your firewall settings, you must make sure you're also including the list of IP
addresses documented in the Azure Multi-Factor Authentication Server firewall requirements section of the
Getting started with the Azure Multi-Factor Authentication Server article.
App-only tokens now require the client app to exist in the resource tenant
Type: Fixed
On July 26, 2019, we changed how we provide app-only tokens through the client credentials grant. Previously,
apps could get tokens to call other apps, regardless of whether the client app was in the tenant. We've updated this
behavior so single-tenant resources, sometimes called Web APIs, can only be called by client apps that exist in the
resource tenant.
If your app isn't located in the resource tenant, you'll get an error message that says,
The service principal named <app_name> was not found in the tenant named <tenant_name>. This can happen if the
application has not been installed by the administrator of the tenant.
To fix this problem, you must create the client app service principal in the tenant, using either the admin consent
endpoint or through PowerShell, which ensures your tenant has given the app permission to operate within the
tenant.
For more information, see What's new for authentication?.
NOTE
Existing consent between the client and the API continues to not be required. Apps should still be doing their own
authorization checks.
New passwordless sign-in to Azure AD using FIDO2 security keys

Type: New feature
Azure AD customers can now set policies to manage FIDO2 security keys for their organization's users and groups.
End-users can also self-register their security keys, use the keys to sign in to their Microsoft accounts on web sites
while on FIDO -capable devices, as well as sign in to their Azure AD -joined Windows 10 devices.
For more information, see Enable passwordless sign in for Azure AD (preview ) for administrator-related
information, and Set up security info to use a security key (Preview ) for end-user-related information.
New Federated Apps available in Azure AD App gallery - July 2019

Type: New feature
In July 2019, we've added these 18 new apps with Federation support to the app gallery:
Ungerboeck Software, Bright Pattern Omnichannel Contact Center, Clever Nelly, AcquireIO, Looop, productboard,
MS Azure SSO Access for Ethidex Compliance Office™, Hype, Abstract, Ascentis, Flipsnack, Wandera, TwineSocial,
Kallidus, HyperAnna, PharmID WasteWitness, i2B Connect, JFrog Artifactory
Automate user account provisioning for these newly supported SaaS apps
Type: New feature
You can now automate creating, updating, and deleting user accounts for these newly integrated apps:
Dialpad
Federated Directory
Figma
Leapsome
Peakon
Smartsheet
For more information about how to better secure your organization by using automated user account provisioning,
see Automate user provisioning to SaaS applications with Azure AD
New Azure AD Domain Services service tag for Network Security Group
Type: New feature
If you're tired of managing long lists of IP addresses and ranges, you can use the new
AzureActiveDirectoryDomainServices network service tag in your Azure network security group to help secure
inbound traffic to your Azure AD Domain Services virtual network subnet.
For more information about this new service tag, see Network Security Groups for Azure AD Domain Services.
New Security Audits for Azure AD Domain Services (Public Preview)

Type: New feature
We're pleased to announce the release of Azure AD Domain Service Security Auditing to public preview. Security
auditing helps provide you with critical insight into your authentication services by streaming security audit events
to targeted resources, including Azure Storage, Azure Log Analytics workspaces, and Azure Event Hub, using the
Azure AD Domain Service portal.
For more information, see Enable Security Audits for Azure AD Domain Services (Preview ).
New Authentication methods usage & insights (Public Preview)

Type: New feature
Service category: Self Service Password Reset
The new Authentication methods usage & insights reports can help you to understand how features like Azure
Multi-Factor Authentication and self-service password reset are being registered and used in your organization,
including the number of registered users for each feature, how often self-service password reset is used to reset
passwords, and by which method the reset happens.
For more information, see Authentication methods usage & insights (preview ).
New security reports are available for all Azure AD administrators (Public Preview)
Type: New feature
All Azure AD administrators can now select the banner at the top of existing security reports, such as the Users
flagged for risk report, to start using the new security experience as shown in the Risky users and the Risky
sign-ins reports. Over time, all of the security reports will move from the older versions to the new versions, with
the new reports providing you the following additional capabilities:
Advanced filtering and sorting
Bulk actions, such as dismissing user risk
Confirmation of compromised or safe entities
Risk state, covering: At risk, Dismissed, Remediated, and Confirmed compromised
For more information, see Risky users report and Risky sign-ins report.
New Security Audits for Azure AD Domain Services (Public Preview)

Type: New feature
We're pleased to announce the release of Azure AD Domain Service Security Auditing to public preview. Security
auditing helps provide you with critical insight into your authentication services by streaming security audit events
to targeted resources, including Azure Storage, Azure Log Analytics workspaces, and Azure Event Hub, using the
Azure AD Domain Service portal.
For more information, see Enable Security Audits for Azure AD Domain Services (Preview ).
New B2B direct federation using SAML/WS -Fed (Public Preview)

Type: New feature
Service category: B2B
Direct federation helps to make it easier for you to work with partners whose IT-managed identity solution is not
Azure AD, by working with identity systems that support the SAML or WS -Fed standards. After you set up a direct
federation relationship with a partner, any new guest user you invite from that domain can collaborate with you
using their existing organizational account, making the user experience for your guests more seamless.
For more information, see Direct federation with AD FS and third-party providers for guest users (preview ) .
Type: New feature
Dialpad
Federated Directory
Figma
Leapsome
Peakon
Smartsheet
see Automate user provisioning to SaaS applications with Azure AD.
New check for duplicate group names in the Azure AD portal

Type: New feature
Now, when you create or update a group name from the Azure AD portal, we'll perform a check to see if you are
duplicating an existing group name in your resource. If we determine that the name is already in use by another
group, you'll be asked to modify your name.
For more information, see Manage groups in the Azure AD portal.
Azure AD now supports static query parameters in reply (redirect) URIs

Type: New feature
Azure AD apps can now register and use reply (redirect) URIs with static query parameters (for example,
https://contoso.com/oauth2?idp=microsoft ) for OAuth 2.0 requests. The static query parameter is subject to string
matching for reply URIs, just like any other part of the reply URI. If there's no registered string that matches the
URL -decoded redirect-uri, the request is rejected. If the reply URI is found, the entire string is used to redirect the
user, including the static query parameter.
Dynamic reply URIs are still forbidden because they represent a security risk and can't be used to retain state
information across an authentication request. For this purpose, use the state parameter.
Currently, the app registration screens of the Azure portal still block query parameters. However, you can manually
edit the app manifest to add and test query parameters in your app. For more information, see What's new for
authentication?.
Activity logs (MS Graph APIs) for Azure AD are now available through PowerShell Cmdlets
Type: New feature
We're excited to announce that Azure AD activity logs (Audit and Sign-ins reports) are now available through the
Azure AD PowerShell module. Previously, you could create your own scripts using MS Graph API endpoints, and
now we've extended that capability to PowerShell cmdlets.
For more information about how to use these cmdlets, see Azure AD PowerShell cmdlets for reporting.
Updated filter controls for Audit and Sign-in logs in Azure AD

We've updated the Audit and Sign-in log reports so you can now apply various filters without having to add them
as columns on the report screens. Additionally, you can now decide how many filters you want to show on the
screen. These updates all work together to make your reports easier to read and more scoped to your needs.
For more information about these updates, see Filter audit logs and Filter sign-in activities.
June 2019
New riskDetections API for Microsoft Graph (Public preview)
Type: New feature
We're pleased to announce the new riskDetections API for Microsoft Graph is now in public preview. You can use
this new API to view a list of your organization's Identity Protection-related user and sign-in risk detections. You
can also use this API to more efficiently query your risk detections, including details about the detection type,
status, level, and more.
For more information, see the Risk detection API reference documentation.
New Federated Apps available in Azure AD app gallery - June 2019

Type: New feature
In June 2019, we've added these 22 new apps with Federation support to the app gallery:
Azure AD SAML Toolkit, Otsuka Shokai (大塚商会), ANAQUA, Azure VPN Client, ExpenseIn, Helper Helper,
Costpoint, GlobalOne, Mercedes-Benz In-Car Office, Skore, Oracle Cloud Infrastructure Console, CyberArk SAML
Authentication, Scrible Edu, PandaDoc, Perceptyx, Proptimise OS, Vtiger CRM (SAML ), Oracle Access Manager for
Oracle Retail Merchandising, Oracle Access Manager for Oracle E -Business Suite, Oracle IDCS for E -Business
Suite, Oracle IDCS for PeopleSoft, Oracle IDCS for JD Edwards
Type: New feature
Zoom
Envoy
Proxyclick
4me
see Automate user provisioning to SaaS applications with Azure AD
View the real-time progress of the Azure AD provisioning service

Service category: App Provisioning
We've updated the Azure AD provisioning experience to include a new progress bar that shows you how far you
are in the user provisioning process. This updated experience also provides information about the number of users
provisioned during the current cycle, as well as how many users have been provisioned to date.
For more information, see Check the status of user provisioning.
Company branding now appears on sign out and error screens

We've updated Azure AD so that your company branding now appears on the sign out and error screens, as well as
the sign-in page. You don't have to do anything to turn on this feature, Azure AD simply uses the assets you've
already set up in the Company branding area of the Azure portal.
For more information about setting up your company branding, see Add branding to your organization's Azure
Active Directory pages.
Azure Multi-Factor Authentication (MFA ) Server is no longer available for new deployments
Type: Deprecated
As of July 1, 2019, Microsoft will no longer offer MFA Server for new deployments. New customers who want to
require multi-factor authentication in their organization must now use cloud-based Azure Multi-Factor
Authentication. Customers who activated MFA Server prior to July 1 won't see a change. You'll still be able to
download the latest version, get future updates, and generate activation credentials.
For more information, see Getting started with the Azure Multi-Factor Authentication Server. For more
information about cloud-based Azure Multi-Factor Authentication, see Planning a cloud-based Azure Multi-Factor
Authentication deployment.
May 2019
Service change: Future support for only TLS 1.2 protocols on the Application Proxy service
To help provide best-in-class encryption for our customers, we're limiting access to only TLS 1.2 protocols on the
Application Proxy service. This change is gradually being rolled out to customers who are already only using TLS
1.2 protocols, so you shouldn't see any changes.
Deprecation of TLS 1.0 and TLS 1.1 happens on August 31, 2019, but we'll provide additional advanced notice, so
you'll have time to prepare for this change. To prepare for this change make sure your client-server and browser-
server combinations, including any clients your users use to access apps published through Application Proxy, are
updated to use the TLS 1.2 protocol to maintain the connection to the Application Proxy service. For more
information, see Add an on-premises application for remote access through Application Proxy in Azure Active
Directory.
Use the usage and insights report to view your app-related sign-in data
Type: New feature
You can now use the usage and insights report, located in the Enterprise applications area of the Azure portal, to
get an application-centric view of your sign-in data, including info about:
Top used apps for your organization
Apps with the most failed sign-ins
Top sign-in errors for each app
For more information about this feature, see Usage and insights report in the Azure Active Directory portal
Automate your user provisioning to cloud apps using Azure AD

Type: New feature
Follow these new tutorials to use the Azure AD Provisioning Service to automate the creation, deletion, and
updating of user accounts for the following cloud-based apps:
Comeet
DynamicSignal
KeeperSecurity
You can also follow this new Dropbox tutorial, which provides info about how to provision group objects.
For more information about how to better secure your organization through automated user account provisioning,
see Automate user provisioning to SaaS applications with Azure AD.
Identity secure score is now available in Azure AD (General availability)

Type: New feature
Service category: N/A
You can now monitor and improve your identity security posture by using the identity secure score feature in Azure
AD. The identity secure score feature uses a single dashboard to help you:
Objectively measure your identity security posture, based on a score between 1 and 223.
Plan for your identity security improvements
Review the success of your security improvements
For more information about the identity security score feature, see What is the identity secure score in Azure Active
Directory?.
New App registrations experience is now available (General availability)

Type: New feature
The new App registrations experience is now in general availability. This new experience includes all the key
features you’re familiar with from the Azure portal and the Application Registration portal and improves upon
them through:
Better app management. Instead of seeing your apps across different portals, you can now see all your
apps in one location.
Simplified app registration. From the improved navigation experience to the revamped permission
selection experience, it’s now easier to register and manage your apps.
More detailed information. You can find more details about your app, including quickstart guides and
more.
For more information, see Microsoft identity platform and the App registrations experience is now generally
available! blog announcement.
New capabilities available in the Risky Users API for Identity Protection
Type: New feature
We're pleased to announce that you can now use the Risky Users API to retrieve users' risk history, dismiss risky
users, and to confirm users as compromised. This change helps you to more efficiently update the risk status of
your users and understand their risk history.
For more information, see the Risky Users API reference documentation.
New Federated Apps available in Azure AD app gallery - May 2019

Type: New feature
In May 2019, we've added these 21 new apps with Federation support to the app gallery:
Freedcamp, Real Links, Kianda, Simple Sign, Braze, Displayr, Templafy, Marketo Sales Engage, ACLP, OutSystems,
Meta4 Global HR, Quantum Workplace, Cobalt, webMethods API Cloud, RedFlag, Whatfix, Control, JOBHUB,
NEOGOV, Foodee, MyVR
Improved groups creation and management experiences in the Azure AD portal
Type: New feature
We've made improvements to the groups-related experiences in the Azure AD portal. These improvements allow
administrators to better manage groups lists, members lists, and to provide additional creation options.
Improvements include:
Basic filtering by membership type and group type.
Addition of new columns, such as Source and Email address.
Ability to multi-select groups, members, and owner lists for easy deletion.
Ability to choose an email address and add owners during group creation.
For more information, see Create a basic group and add members using Azure Active Directory.
Configure a naming policy for Office 365 groups in Azure AD portal (General availability)
Administrators can now configure a naming policy for Office 365 groups, using the Azure AD portal. This change
helps to enforce consistent naming conventions for Office 365 groups created or edited by users in your
organization.
You can configure naming policy for Office 365 groups in two different ways:
Define prefixes or suffixes, which are automatically added to a group name.
Upload a customized set of blocked words for your organization, which are not allowed in group names (for
example, “CEO, Payroll, HR”).
For more information, see Enforce a Naming Policy for Office 365 groups.
Microsoft Graph API endpoints are now available for Azure AD activity logs (General availability)
We're happy to announce general availability of Microsoft Graph API endpoints support for Azure AD activity logs.
With this release, you can now use Version 1.0 of both the Azure AD audit logs, as well as the sign-in logs APIs.
For more information, see Azure AD audit log API overview.
Administrators can now use Conditional Access for the combined registration process (Public preview)
Type: New feature
Service category: Conditional Access
Administrators can now create Conditional Access policies for use by the combined registration page. This includes
applying policies to allow registration if:
Users are on a trusted network.
Users are a low sign-in risk.
Users are on a managed device.
Users agree to the organization’s terms of use (TOU ).
For more information about Conditional Access and password reset, you can see the Conditional Access for the
Azure AD combined MFA and password reset registration experience blog post. For more information about
Conditional Access policies for the combined registration process, see Conditional Access policies for combined
registration. For more information about the Azure AD terms of use feature, see Azure Active Directory terms of
use feature.

Azure AD Identity Protection PDF

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Azure AD Identity Protection PDF

Загружено:

Авторское право:

Доступные форматы

Contents

Identity Protection Documentation

Why is automation important?

Risk detection and remediation

RISK DETECTION TYPE DESCRIPTION

Anonymous IP address Sign in from an anonymous IP address (for example: Tor

Malware linked IP address Sign in from a malware linked IP address

Exporting risk data

CAPABILITY DETAILS AZURE AD PREMIUM P2 AZURE AD PREMIUM P1 AZURE AD BASIC/FREE

Risk policies User risk policy (via Yes No No

Risk policies Sign-in risk policy (via Yes No No

Security reports Overview Yes No No

Security reports Risk detections Full access Limited Information No

Notifications Users at risk detected Yes No No

Notifications Weekly digest Yes No No

MFA registration Yes No No

Medium risk users

Risk types and detection

RISK DETECTION DESCRIPTION

RISK DETECTION DETECTION TYPE DESCRIPTION

Anonymous IP address Real-time This risk detection type indicates sign-

Atypical travel Offline This risk detection type identifies two

The algorithm ignores obvious "false

We also run this detection for basic

Malicious IP address Offline This detection indicates sign-in from a

Other risk detections

Azure MFA registration policy

Sign-in risk policy

User risk policy

With Azure Active Directory Identity Protection, you can:

Multi-factor authentication registration

Risky user remediation

Risky sign-in administrator unblock

How is risk evaluated for B2B collaboration users

Limitations of Identity Protection for B2B collaboration users

Users at risk detected email

Configure users at risk detected alerts

Weekly digest email

What is the Azure Multi-Factor Authentication registration policy?

Choosing acceptable risk levels

Unfamiliar sign-in properties

Testing risk policies

Navigating the reports

Connect to Microsoft graph

Retrieve your domain name

4. Copy your domain name.

Create a new app registration

2. In the menu on the top, click New application registration.

3. On the Create page, perform the following steps:

Grant your application permission to use the API

3. On the Add API access page, click Select an API.

7. On the Add API access page, click Done.

Get an access key

2. On the Keys page, perform the following steps:

Authenticate to Microsoft Graph and query the Identity Risk

if ($oauth.access_token -ne $null) {

$myReport = (Invoke-WebRequest -UseBasicParsing -Headers $headerParams -Uri $url)

foreach ($event in ($myReport.Content | ConvertFrom-Json).value) {

Query the APIs

GET https://graph.microsoft.com/beta/riskDetections?$filter=detectionTimingType eq 'offline'

GET https://graph.microsoft.com/beta/riskyUsers?$filter=riskDetail eq 'userPassedMFADrivenByRiskBasedPolicy'

Why should I give risk feedback to Azure AD’s risk assessments?

How does Azure AD use my risk feedback?