Auditing Conditional Access events and changes is crucial regarding your hygiene in Azure AD for your modern workplace. With the goal that we receive appropriate notifications and alerts if special events occur. Thanks to Azure Log Analytics (also referred to as Azure Monitor) we can easily filter and create alerts based on events. This post starts where most of the others end - giving you practical examples of KUSTO queries to search your Azure AD Audit logs with Log Analytics.
Default log retention in AAD # A point which get’s raised often is the default log retention in Azure Active Directory (AAD). Azure Active Directory stores all activity reports depending on your license for 7 or 30 days:
Azure AD Free and Basic: 7 days Azure AD Premium P1 and P2: 30 days Source, more Information.
To retain and further process Azure Active Directory Audit Logs for a longer time period (because a 30 day audit trail is likely too short for most organizations) we can:
Stream to an Azure Event Hub Archive to Blob Storage Forward them to Azure Log Analytics With Log Analytics the KUSTO query language can be used to query the forwarded log entries and we can create alert rules based on custom queries.
Nowadays where cloud services are available from all over the world we cannot (only) rely on trusted networks and on identities protected by usernames and passwords. Conditional access allows you to define granular controls whether an identity can access cloud applications. Based on the positive feedback for my “5 Ways to Screw up your Intune Tenant” post I felt empowered to get conditional access covered as well.
Chose your platform wisely # If you intend to use the device platform filter make sure that you cover all platforms including unknown platforms. Otherwise your might have a lack in your battleship. Also note that platform detection is based on best effort and can be exploited.
Long live legacy # Mind the client apps configuration to ensure that your conditional access policies also apply to non-modern authentication clients. If you have created your conditional access policies in the early days of the product you didn’t have this option available.
Something that has created some confusion is that conditional access policies don’t include legacy authentication clients by default, this means that if you have a conditional access policy enforcing MFA for all users and all cloud apps, it doesn’t block legacy authentication clients (or “Other clients”, as the CA UI refers to them) - Sue Bohn, Microsoft
Recently I read a great article from the Microsoft IAM Director Sue Bohn concerning a Conditional Access Q&A. One question was about the device platform feature - which let’s you apply a policy only to a specific device platform like iOS, Android or Windows 10.
The detection of the device platform relies on the user agent string sent by the application or web browser. Because this one can be spoofed easily better configure your Conditional Access policies wisely.
The problem # As soon as you enable the device platform selection there’s the chance that a user doesn’t catch any Conditional Access policy.
As a result, you should not rely on the User Agent String to be present or to be accurate. Most browsers have a function to set an arbitrary User Agent String for testing purposes. (Microsoft)
Bypass example # To give you an example, here’s a little walk-through:
Conditional Access Policy configured for all cloud apps Windows 10 selected as device platform Access control: Block If we now try to access the azure portal with a Windows 10 app or browser we get the following result: