Azure AD Conditional Access is one of the most named features which customer implement to protect their environments. But as with many cloud features at first glance it looks really simple to implement but then the complexity comes visible during rollout. Many customers activating it without thinking what the impact can be or without checking if the configurations is really closing the doors. This blog should give a few insights about what you should think about when activating it.
Conditional Access is a very complex topic because of:
- Assignment: With various filters you can define the scope where the access controls should apply. The crucial part is to cover all sign-ins which should be targeted and exclude only the one which shouldn’t be targeted.
- Access controls: Combination of targeted operating systems, identities and applications has to be compatible with the requested access controls.
- Reports/Analysis: Before activating a new rule it’s important to analyze the impact to ensure business continuity. But finding this information is despite of all available reports not simple to accomplish.
- Don't forget that when no rule applies to a sign-in, then only username and password is requested.
- Continuously monitor requests not covered by Conditional Access and improve your rules!
- Keep it as simple as possible!
Assignments
When assigning rules the goal is not to leave some specific access unprotected and therefore, it would be the best option to target all users when accessing any application in all conditions.
Why is targeting "All cloud apps" a bad idea?
The problem with that is, that there are applications which don’t support Conditional Access because they just not supporting it or are running in background. But wait, we can exclude them. Then we can still use All cloud apps and if new apps are used they are already protected? NO, because Conditional Access does only provide some of your applications in the include and exclude list, especially Microsoft trusted or core federated apps are not shown. This is the most annoying part of conditional access, because Microsoft is limiting the capabilities. I would wish, that conditional access allows to specify every application which can be accessed from your tenant, at least by GUID which can be retrieved from the sign-in log.
Here are two examples:
The agent is authenticating with the available tokens in background to the cloud services. If a an access control like MFA or Compliant Device is requested, then this can not be fulfilled, because this background task doesn’t has access to this information. Therefore, the application is no longer operational. This is just one example of an application which does not support the usage of Conditional Access.
Especially when using high sensitive information it could be beneficial to protect the access to the systems. But this system does not create a guest account in Azure AD when granting permission to an external person like when you invite a person to Teams or SharePoint.
The main Azure AD attribute used to identify the selected users and groups is the Azure AD ProxyAddresses attribute, which stores all the email addresses for a user or group. However, if a user account doesn’t have any values in the AD ProxyAddresses attribute, the user’s UserPrincipalName value is used instead.
From https://docs.microsoft.com/en-us/azure/information-protection/how-does-it-work
This works great and helps to reduce guest accounts in the own directory, but as soon you enforce for example MFA for guest accounts this leads to the problem, that when the external recipient tries to access the content Azure RMS service is authenticating the user enforcing MFA for the user, but the user does not exist in the senders Azure AD. Therefore the process fails because the user is unable to do the MFA registration in the tenant with error code AADSTS90072:
PassThroughUserMfaError – The external account that the user signs in with doesn’t exist on the tenant that they signed into; so the user can’t satisfy the MFA requirements for the tenant. The account must be added as an external user in the tenant first. Sign out and sign in with a different Azure AD user account.
I could also see this behavior in another case. If MFA is not enforced for guests via conditional access, but the user is not deselecting “Allow my organization to manage my device” or not choosing “This app only”.
Then MFA could be triggered for the guest account as well because of the Device registration configuration in the senders tenant requires a MFA. To mitigate this risk, the above screen can be disabled on your company devices by setting:
HKLM:\SOFTWARE\Policies\Microsoft\Windows\WorkplaceJoin: “BlockAADWorkplaceJoin”=dword:00000001.
You need to use a specific versions of the module to be able to use Azure AD Conditional Access. This module is available for download through the Exchange Admin Center via admin.microsoft.com. The download is called Microsoft.Online.CSE.PSModule.Client.application. When logged into the Exchange Admin Center, you will find the download available from the hybrid menu.
Is targeting Conditional Access rules to "All users" a bad idea?
All users include every user which is somehow accessing your tenant. This includes also guest accounts, service accounts and like written above users receiving RMS protected documents without an account in your directory. But compared to the “All cloud Apps” option the users are much better, because you can include and exclude every user in your tenant. Therefore the All users is not per se a bad idea, you just have to ensure to cover all use cases when starting excluding groups, guests or Directory roles.
Especially do not forget excluding the following principals from each rule:
- Break the glass account / Emergency account
Create a group, where you can add accounts which are excluded from each Conditional Access rule. This is important to never loose access to your azure AD environment in case the Conditional Access infrastructure experience issues or an administrator of your company creates a problematic new rule. - Directory Synchronization Principal created by Azure AD Connect
Exclude the directory synchronization role to not break your Azure AD Connect synchronization.
What should I consider when using conditions?
Conditions are great to target specific access controls not in sign-in. But what often is not mentioned is, that some of the conditions are only based on “best effort” and an attacker could modify them according to his needs.
Platform
The platform (operating system) is determined based on the user-agent http header. Especially this platform condition is used by a lot of customers to target different rules for example to iOS/Android/macOS and Windows. This leads most often to two Azure AD Conditional access rules, but what happens if the device is a Linux device or something unrecognized? Then no protection is applied. To mitigate this you have to create a third policy which blocks access for All platforms but exclude the platforms for which you have specific other rules.
Client Apps
The client apps condition is great to apply different policies for the native app versus for browser access. But it’s important to know, that not all client applications support this scenario and it could lead to certificate selection popups for the users.
Reporting and Monitoring
Azure AD Conditional Access is sometimes referred as an identity driven Firewall. As with a network firewall it’s necessary to monitor the connections which are blocked and which went through from time to time to detect issues.
A good starting point is to export the sign-in log in Azure Active Directory and then filter in Excel for all blocked connections and also for the one where no Conditional Access rules was applied.
If you are eligible licensing and have the permissions in your tenant then you can also the new Workbooks which also help analyzing “Report Only” policies, which isn’t that easy when just using the Sing-In log.
- Microsoft Sentinel ASIM Parser demystified - March 31, 2024
- Enhancing Network Security Insights with IDS/IPS of Ubiquiti Dream Machine Pro and Microsoft Sentinel - March 10, 2024
- Ubiquiti Dream Machine Pro Logs to Microsoft Sentinel - February 6, 2024
1 Comment
The Conditional Access Experiment - Call4Cloud · November 6, 2020 at 14:48
[…] Lessons Learned: Azure AD Conditional Access […]