A screenshot of the Conditional Access Policy Details summary

Hot on the heels of the MyApps portal updates last week, a number of Conditional Access updates have made their way into Azure AD. Those of you who follow this blog will know I have an unhealthy fascination with all things #Identity, so I thought I’d take the time to dive into each and explain what they mean to you…

Three features were announced in a blog post yesterday by Alex Simons. Whilst each is minor in isolation, collectively they address a number of things which have been requested for some time… specifically around visibility and reporting. The announcements are as follows:

  • Report-only mode is now generally available
  • A new “Policy Details” blade is now in preview
  • The Insights & Reporting workbook is now generally available

Conditional Access Report-Only Mode

I touched on report-only mode for Conditional Access in one of my Ignite blog posts last November. At the time it was just entering preview and was wholeheartedly welcomed (at least by me!)… There are lots of things that send shivers down the spines of AD administrators. Cloud or otherwise. Changes that result in people being wrongly locked out of accounts is right up there! Report-only mode mitigates this risk, providing visibility on the impact of potential changes before they are made live.

When enabled, report-only mode records the success or failure outcome that would have been associated with a logon attempt. I’ve used this on a number of provisional policies I’ve been testing with and it works well. An additional tab appears in the sign-in logs that records two key things:

  • The controls that would be associated with the policy being applied
  • The applicability and outcome of the policy on that authentication attempt

This is immeasurably helpful when implementing new policies; sparing blushes(!), and providing insight into the results of those slightly less “standard” policies we sometimes find ourselves deploying. This announcement see’s this feature exit preview, and become fully fledged. It’s also now the default setting for any newly created policies. I’d encourage you to use it… set aside your impatience and let it run it’s course for a day or two before enabling anything new.

All New Policy Details Blade

I’ll mention this second, as opposed to at the end in line with Alex’s release announcement. For me, this flows quite logically on from report-only mode - providing visibility and insight into the behaviour of Conditional Access policies in a way which we haven’t had access to before.

You’ve done the right thing. You’ve deployed a policy in report-only mode, tested it thoroughly, and now you’ve deployed it to live. A number of your users are having issues though, why? In the “old” world, your visibility of applied Conditional Access policies was limited to Success, Failure, or Not Applied… Why did the policy fail? Why did the user fall within scope? What’s going on?! It has always been difficult to tell.

Policy Details seeks to address this by providing additional insight into applied policies. Where a policy results in behaviour we wouldn’t expect, we can now discover why. Not just “Failure” to apply, but “Failure because”. Against each Conditional Access policy within the sign-in log we can now expand the view to show us which criteria were satisfied (or not).

Take the following simple example, I have a policy which blocks legacy authentication in my tenant (don’t we all?!). It’s not been applied to a recent sign-in attempt where perhaps I expected it to be. Using the Policy Details view I can determine that whilst the resulting action would have been a block had the conditions been met, in this case my browser (unsurprisingly) doesn’t match the Client app defined in the policy:

A screenshot that shows a logon attempt didn't satisfy the conditions within a Conditional Access policy.

This is a super-nice bit of visibility to have when troubleshooting… It’s currently in preview, but should be visible in your tenants already. Give it a go!

Insights & Reporting Workbook

The final part of the announcement (albeit not in quite the right order!) relates to the general availability of Insights & Reporting for Conditional Access. “Insights” terminology is used throughout the Azure portal to monitor, identify trends, and generally get a view as to the health of various resources deployed. This has been lacking when it comes to Conditional Access, with only limited reporting available - unless you are familiar enough with KQL and Log Analytics to construct your own queries.

The new Insights & Reporting blade for Conditional Access addresses this direct link here. Leveraging diagnostic logs from Azure AD, it provides you with some visual analysis of your policies, and the authentication traffic flowing through them:

A view of the new Insights & Reporting blade within the Conditional Access section of the Azure AD portal

You can filter by policy to see where, to what, and to whom your policies are applying. You can also search against users or response types to gather additional detail on the effectiveness of the policies you have defined.

It’s worth noting that this view is an extension of the regular “Workbooks” that are available in Azure AD (once you’ve configured forwarding to Log Analytics). These are incredibly useful when it comes to analysing authentication traffic in your environment, or when looking for specific types of activity (such as legacy authentication requests). You can access these in the regular Azure AD blade here. Naturally you can also delve deeper within Log Analytics should you choose.

An example of an Azure AD workbook, visible after configuring Diagnostic Log forwarding

There are some preliminary steps you need to run through to gain access to these views if you haven’t already:

  • Ensure you have an active Azure subscription
  • Create a Log Analytics workspace (if one does not exist)
  • Enable diagnostic log forwarding from Azure AD (audit logs, and sign-in logs)

These are detailed more fully in this Microsoft Docs article, but once enabled you’re good to go.


Summary

Unsurprisingly, these are welcome additions from my perspective. Some we were expecting… report-only mode has been a while coming… for others though (notably Policy details) these changes represent a positive improvement in administrative controls which aid visibility, and the ease with which changes can be implemented.

Azure AD remains one of the most underrated parts of the Microsoft Cloud stack for many of the organisations I speak to. Particularly premium variants. Security controls, like Conditional Access, and the ease with which they can be used to better secure not just Microsoft workloads, but a whole host of SaaS applications make it an absolute no-brainer for many organisations to embrace far more fully than they do. I’ll continue to bang the drum… and I hope Microsoft continue to innovate and add value to the product in the way that they have to date. It’s a brave new world!

If you haven’t already, please, please look at some of what you can do with Azure AD. If you have questions… please ask away!