Azure AD Identity Protection has been generating a TON of customer interest, especially with recent news about hackers selling huge lists of leaked user credentials. So today I’m excited to let you know that Azure AD Identity Protection has just turned on support for federated identities. This means that our largest customers, most of who use Active Directory Federation Server with Azure AD, can now get the benefit of this powerful security service.
To give you a quick walk through of how to get this set up and working, I’ve asked Salah Ahmed one of the PMs in our Identity Security and Protection team to write up a blog post. You’ll find it below.
I hope you’ll try out it today. Azure AD Identity Protection is undoubtedly the fastest and easiest way available to substantially improve your company’s security posture. If your company is using Azure AD, you’d have to be crazy to not give it a try!
And as always, we’d love to receive any feedback or suggestions you have.
Alex Simons (Twitter: @Alex_A_Simons)
Director of Program Management
Microsoft Identity Division
My name is Salah Ahmed and I am a Program Manager in the Identity Security and Protection team in Microsoft’s Identity Division. Today we are pleased to announce an update to the public preview of Azure Active Directory Identity Protection that extends risk-based conditional access to federated identities. For the benefit of those who missed the original public preview announcement, you can think of Identity Protection as a gatekeeper to the cloud, analyzing and securing sign-ins to all of the applications Azure AD manages, 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.
Identity Protection detects risk events involving identities in an Azure Active Directory that indicate that the identities may have been compromised. For details on risk detection, see Types of risk events detected by Azure Active Directory Identity Protection.
What’s new: Starting today, all of Identity Protection’s risk event types will be covered for federated identities! Now you can tell if botnet infections, TOR networks, or location anomalies are present in your federated sign-ins. [Note that leaked credentials detection requires that you have enabled password hash sync in your federated tenant.]
Risk based Conditional Access
Identity Protection allows admins to respond to risky sign-ins by
- Enforcing multi factor authentication (MFA)
- Blocking them completely
The great thing about Identity Protection sign-in risk policy is that it interrupts only bad sessions. As a result, if a bad actor is trying to sign-in to an account, only the bad actor would be interrupted, without the actual user being impacted in any way.
What’s new: Starting today, blocking or enforcing MFA on risky sessions is available for federated identities. What this means is that your federated identities have an extra layer of protection when they try to access cloud services such as Office 365, Azure, or *any* apps configured for Single Sign-On with Azure Active Directory!
If the administrator has configured a policy to enforce MFA on sign-in risks, the next time a risky sign-in is detected, the user is informed that something unusual was detected about their sign-in.
The user is then required to prove their identity by solving a security challenge.
Alternatively, if the administrator has configured a policy to block risky sign-ins, the next time a risky sign-in is detected, it is blocked. Self-recovering by solving multi-factor authentication is not an option in this case.
Note on Multifactor authentication:
For federated tenants, multi-factor authentication (MFA) may be performed by Azure Active Directory or by the on-premises AD FS server.
By default, MFA will occur at a page hosted by Azure Active Directory. In order to configure MFA on-premises, the –SupportsMFA property must be set to true in Azure Active Directory, by using the Azure AD module for Windows PowerShell.
The following example shows how to enable on-premises MFA by using the Set-MsolDomainFederationSettings cmdlet on the contoso.com tenant:
Set–MsolDomainFederationSettings –DomainName contoso.com –SupportsMFA $true
In addition to setting this flag, the federated tenant AD FS instance must be configured to perform multi-factor authentication. You can revisit the instructions for deploying Azure Multi-Factor Authentication on-premises.
Note: Only Sign-in risk policy is included in this announcement. User risk policy is currently not supported for federated domains. It is coming soon though!
Try it out!
So what are you waiting for? Identity Protection’s capabilities are a must-have in today’s world of persistent bad actors and frequent security breaches. Setting up Identity Protection takes less than a minute! You need an Azure AD Premium license to try out the full capabilities in this public preview.
If you would like to see Identity Protection’s detection capabilities in action and would like to test its detection, mitigation and remediation capabilities, check out our Playbook for step-by-step instructions.
I hope you’ll find this new capability useful!
Microsoft Identity Division