On 22 March Microsoft published the newest Cloud App Security (MCAS) releases, number 170 & 171. All of these are great additions to MCAS detection capabilities.

Worth to mention is MCAS capabilities to monitor activity and suspicious activity in AWS with multiple scenarios (read an earlier post from here). The current corona pandemic has an effect also on Teams usage, which has had exponential growth in the user base, new activity policy templates available for Teams. And lastly, Azure AD Identity Protection integration which is covered in this blog.


When integration is enabled leaked credentials and risky sign-in alerts are feed to Cloud App Security. As stated in the release notes:

  • You can now control the severity of Azure AD Identity Protection alerts that are ingested into Cloud App Security.
  • Additionally, if you haven’t already enabled the Azure AD Risky sign-in detection, the detection will be automatically enabled to ingest high severity alerts

Configuration – MCAS

At the time of writing, it seems that the feature is currently rolling out to the tenants and my tenant is in the fast lane 🙂

Navigate to the Cloud App Security settings blade:

  • Select Azure AD Identity Protection
  • Enable the integration
    • The Identity Protection feature is enabled by default.
      • However, if the feature was disabled, you need to turn it on


When integration is enabled the MCAS instance will have two (2) policies out of the box:

  • Leaked credentials
    • Severity: low – receive all alerts
  • Risky sign-in
    • Severity: high – receive only high severity alerts

These are based on Identity Protection detection policies and the policies can be fine-tuned to your organization’s needs using the severity slider. The sensitivity slider allows you to control which alerts are ingested. In this way, you can adapt the detection according to your coverage needs and your (SNR) targets.

Note: In my demo environment I’m not able to modify policies at all, not even the severity slider.

Configuration – Identity Protection

I have three Azure AD Identity Protection policies configured in my environment:

User Risk policy

  • Scope: All users included, the break-glass accounts excluded
  • Conditions: User risk medium or above
  • Controls: Allow access – require password change

Risk policy

  • Scope: All users included, the break-glass accounts excluded
  • Conditions: User risk high
  • Controls: Allow access – require MFA

MFA registration policy

  • Scope: All users included, the break-glass accounts excluded
  • Access: Require MFA registration

Simulate Alert

Leaked credentials policy is a bit hard to test, so I selected the latter one, “Risky sign-in”. I simulated test by trying login to portal.office.com & myapps.microsoft.com portals through Edge (successful) and Tor browser (failed). With Tor, I changed identity multiple times.

Alert In MCAS

Activities I performed generated alerts based on two (2) policies:

  • Risky sign-in – Azure AD Identity Protection as a source
  • Activity from anonymous IP addresses – MCAS built-in policy

Let’s take a closer look for the risky sign-in alert. IP is categorized as risky by MCAS & IPC because of association to the Tor network.

Because of the Tor network, the exact location is unknown and geo-mapping is not available.

Conclusion – Benefits From The Integration

Microsoft Cloud App Security has wide range of integrations available and with the newest additions it’s getting better and better.

I encourage you to enable Azure AD Identity Protection integration to get even more visibility to MCAS, in terms of “single pane of glass”. I’m repeating myself in these MCAS related blogs, but in my opinion, it’s the best tool for monitoring internal users’ suspicious activity in the Microsoft cloud ecosystem.


AAD Identity Protection Integration with MCAS

Control cloud apps with MCAS policies

Configure Azure AD Identity Protection risk policies

Stay home & stay safe!