First published on CloudBlogs on Aug, 22 2016
Those of you who read the blog will recall that in June we
some enhancements to the public preview of Azure Active Directory Identity Protection that extended risk-based conditional access to federated identities for risky sign-ins. Today we're announcing two more updates:
We've turned on support for our "Users at risk" for customers using federation for user authentication
Azure AD Identity Protection in now available and fully supported in Europe!
To give you the run down on these two improvements, I've asked Salah Ahmed from our Identity Protection team to write up a short blog post. You'll find it below.
I hope you'll find these new capabilities useful in securing your enterprise cloud!
And as always, we would love to receive any suggestions or feedback you have.
Alex Simons (Twitter:
Director of Program Management
Microsoft Identity Division
My name is Salah Ahmed and I am a Program Manager on the Identity Security and Protection team in Microsoft's Identity Division. Today I have the privilege of letting you know that:
We've turned on support for our "Users at risk" policy for customers using federation for user authentication
Azure AD Identity Protection is now available and fully supported in Europe
Remediation of Compromised Federated Accounts
To explain what we're announcing today, it will probably help to do a quick refresher on Azure AD Identity Protection. Those of you who follow the blog already know that Identity Protection is our gatekeeper service to the cloud. It analyzes and secures sign-ins to all of the applications that are integrated with Azure AD, including Office 365 and Azure, third-party applications like ServiceNow, Salesforce.com, Google Apps, and DropBox, and on-premises apps connected using the Azure AD App Proxy.
What you may not know is that Azure AD Identity Protection has two different methods for detecting and mitigating cyber-attacks.
The first is one you are probably familiar, our real-time Sign-In policy. This policy evaluates each login based on over 100 different contextual data points related to that specific login attempt and creates a risk score that can be used with our conditional access policies to allow, challenge or block a login attempt.
The second method, User Risk Policy, is a background process which collects data over time that helps us identify accounts at risk of being taken or that may have recently been taken over. Whenever a user logs in, our User Risk Policy comes into play and evaluates the user's risk score based on this accumulated data. For example, if the service detected that a username and password was leaked on the web, or the pattern of user logins indicates the user's credentials are compromised then their risk score would be set to high.
Similar to our real-time risk scores, admins can enable Identity Protection's built-in User Risk Conditional Access Policy to block logins outright, or help users protect themselves by performing a password change secured by multifactor authentication. These policies not only ensure accounts are protected as soon as anomalies are detected, but also makes it convenient for users to recover their account without losing productivity or incurring help desk costs.
Configuring a User Risk Policy
What's new today:
User Risk Policies are available for organization using federated authentication
(i.e. Something like an Active Directory Federation Server or Ping Federate). If the admin has configured a User Risk Policy, the next time a sign-in to Azure AD is detected from a user whose account might be compromised, the user is informed that their account is at risk.
The user is then required to prove their identity by solving a multi-factor authentication challenge.
And then the user is forced to change their password.
The following is required for this scenario to work for federated identities:
must be enabled for the federated domain, so that password change in the cloud can be written back on-premises.
An Azure AD Premium license must be assigned to the end-user.
In addition to self-remediation, federated users at risk of compromise can also be remediated by an admin manually resetting the user's password in Identity Protection (this again requires that password writeback is enabled, and an Azure AD Premium license is assigned to the specific end-user).
If a federated tenant does not have password write back enabled, but admins still want to leverage Identity Protection's risk detection and workflow capabilities, they can reset the compromised user's password on-premises and mark the user as secured in Identity Protection by selecting "Dismiss all events" on the user's blade. The user will no longer show as being at risk of compromise in Identity Protection.
Azure AD Identity Protection in Europe
Our second big piece of news today is that Azure AD Identity Protection is also available and fully supported in Europe! We would like to thank our European customers for patiently waiting for this update.
Setting up Identity Protection in the Europe Geo only takes a couple of minutes. An Azure AD Premium license is required to use the full functionality of Identity Protection. To get started:
Navigate to the
and search for "Azure AD Identity Protection". Click on the Identity Protection tile and click "Create"
You will be navigated to the Identity Protection onboarding blade. Click "Create" and sit back and relax while your Identity Protection service is set up. You are all done!
Note for Europe Geo customers who were already using Identity Protection:
The service for the Europe Geo was not officially supported before today. European customers who were already using Identity Protection will have to
onboard again to the service
their previous data will be dropped
. We apologize for the inconvenience.
If you read this far, thanks! I really appreciate you spending the time to learn more about the work we're doing here.
I hope you'll find it useful in helping your enterprise use the cloud securely!