Home
You don't have any conditional access policies yet and don't know which ones to create? You already have conditional access policies but you are not sure if they are 'right'? You already have conditional access policies but no overview anymore?
The following sections will help you to find a policy set that consists of several policies with the intention to secure your tenant in a holistic way without having to change the policies every day.
You can find the policy sets here, just take a quick look at the folder names to be familiar with them.
Since risk-based conditional access policies require Azure AD Premium P2 (part of EMS E5, M365 E5 Security and M365 Security) the right policy set for your organization will be determined based on your licensing.
You have Azure AD Premium P2 for all users? Use Category structure for AADP2
Your users have a mixture of Azure AD Premium P1 and P2? Use Category structure for AADP1 and AADP2 mixture
You have Azure AD Premium P1 for all users? Use Category structure for AADP1
Every organization is different and so is every conditional access concept. The policy sets should therefore be seen as a blueprint that can be further customized.
There also is a 'bare minimum' policy set, I do not recommend it but it get's close to the deprecated baseline policies, even in my 'bare minimum' policy set you would have do think about your internet breakouts.
If you do not want to spend any time with conditional access but still want security, go enable security defaults.
Even if you have decided on a policy set, this does not mean that it is already the perfect solution for your company. The following questions can help you to customize the policy set, many of the required alternatives are already available as policies in the policy repository. These questions do not necessarily have to be clarified before the first deployment, some of them will have to be addressed at the latest in the evaluation and roll-out phase.
- The most important question will be where your company is in the maturity level for strong authentication, the policy sets are only at maturity level 1 or 2 of 4.
- A second key part is your BYOD approach, the policy sets are using session controls and app protection policies for O365.
- In addition, one question is how the policies are structured, the policy sets use a category structuring, for some companies a structure based on persona's makes more sense. Furthermore there are many other frameworks which can bring other structuring logic. The framework structure can give you some ideas.
In addition, there are numerous other factors that can influence the concept, fore more details and true deep-dive on the blueprint decisions you should take a look at the Conditional Access guidance and make yourself familiar with the zero trust maturity level.
- Download the Deploy-Policies.ps1 script
- Download your desired policy set
- The script requires the following Microsoft Graph PowerShell Modules which require PowerShell 5.1 or later (PowerShell 7 is supported):
- Microsoft.Graph.Authentication
- Microsoft.Graph.Groups
- Microsoft.Graph.Identity.SignIns
- The script connects with the delegated scopes "Policy.ReadWrite.ConditionalAccess", "Group.ReadWrite.All", "Policy.Read.All" and "Application.Read.All" hence you at least require the Conditional Access administrator and Groups administrator role and will have to consent to the Microsoft Graph PowerShell application. Note, even though it includes the "Application.Read.All" scope, you do NOT require Application administrator. However depending on your tenants consent settings you may initially require (Cloud) Application Administrator to consent the delegated permissions for the "Microsoft Graph PowerShell" application.
- Run the Deploy-Policies.ps1 script e.g. .\Deploy-Policies.ps1 -Prefix "CA" -Ring "ALL" -PoliciesFolder "C:\Repos\ConditionalAccess\Policies" - DISCLAIMER: The policy sets are provided in report-only mode - Policies in report-only mode requiring compliant devices may prompt users on macOS, iOS, and Android to select a device certificate. You can either adjust the JSON templates to exclude the device platforms macOS, iOS and Android or adjust the JSON files to deploy the policies in disabled state to get a better understanding first.
Note: The solution already supports updating existing policies based on a policy id in the JSON file.
- Add your emergency access account to the 'Exclusion_EmergencyAccessAccounts' group. If you do not have a emergency access account yet, create one.
- Add your Azure AD Connect Service Account to the 'Exclusion_SynchronizationServiceAccounts' group. Display name in AAD is 'On-Premises Directory Synchronization Service Account'
- Add your internet breakouts as trusted locations
- Enable the combined security information registration otherwise the policy to restrict MFA registration will not work.
- Ensure modern authentication is activated on Exchange Online via M365 Admin Portal or PowerShell - For tenants created after August 1, 2017 it's on by default.
- Ensure modern authentication is activated on Skype for Business Online - For tenants created after August 1, 2017 it's on by default.
- Consider re-certification of exclusions, e.g. you could create access reviews for your exclusion groups
- Define a strategy how your users will register for MFA
- If your policy set contains the O365 data protection policies, enable the app enforced restrictions on Exchange Online and SharePoint Online. Note, this will create two policies that are enabled for all users, you can delete them as your policy set already contains them.
- If your policy set contains the O365 data protection policies, create App Protection Policies
- Consider audit log alerts for a) Emergency access account usage b) Conditional access configuration changes c) Accounts added to conditional access exclusion. You could achieve this with Azure Sentinel or Azure Monitor. Example KQL queries can be found here.
- The admin protection currently covers Azure AD roles as well as the Azure Management application, you may want to extend this protection.
- This could mean to e.g. include AWS in the privileged systems applications.
- It could also mean that users are considered privileged users in other M365 RBAC systems. These other systems require you to list the accounts to be protected. As of now Conditional Access can only target Azure AD roles, which is only one of several M365 RBAC systems. To do this, the automation creates an administrator group which is protected by the M365 admin protection [100 - 103]. This group must be filled and maintained.:
- Exchange
- Intune
- Cloud App Security
- Security & Compliance Center
- Microsoft Defender Advanced Threat Protection
- Azure AD Entitlement Management
- Commerce
- Make sure your Intune compliance policy settings are set to "Mark devices with no compliance policy assigned as: Not Compliant.
- If you are using Intune compliance for your device trust make sure to create your compliance policies
- Convert users from per-user MFA to Conditional Access based MFA
- Enable password writeback for user risk policies
- Enable password hash sync if you want to benefit from the user risk policies / leaked credential detection
- If you already know service accounts that need to be excluded from the policies, you can add them to the permanent exclude groups created for each policy. At the same time you should ask yourself if the process can be optimized, e.g. changing the service account to a service principle e.g. with certificate based authentication or a managed identity for Azure resources. If you are not sure which service accounts have to be excluded, don't worry, they will be identified in the evaluation and roll-out phase described in the next section. However, here is a list of potential accounts:
- Azure Information Protection unified labeling scanner
- Blocking legacy authentication with Conditional Access is great, disabling legacy authentication on service level (e.g. SharePoint or Exchange Online) is even better, take a look.
I recommend to familiarize yourself with the rules in detail and to evaluate them first in report-only mode.
The process of a successful impact evaluation and rollout could look as follows:
- Deploy your desired policy set in report-only mode to all users. In Deploy-Policies.ps1 this is possible with the parameter $RingTargeted NOT set or set to FALSE. In this case the policies will be targeted to ALL USERS.
- Evaluate the impact of the policies using the Conditional Access Insights Workbook.
- Based on your evaluation you will find
- Policies you can enable immediately
- Policies you can enable for ALL USERS after minimal clarification / follow-ups with other teams
- Policies that will require testing and a ring based deployment method, e.g. IT first, KEYUSER next and finally the hole company.
- Lets imagine you did deploy a policy set with 24 policies and let's assume for 5 of these policies you will require a ring based rollout / testing. You can now use the ring-based deployment of this solution to deploy a second / third / X set of these 5 policies to bring the policies to your rings while keeping the initial 5 policies from your first deployment for report-only mode analysis.
If you use this solution to make changes to your policies, the JSON files serve as technical documentation that can be versioned and restored via source control.
In addition to this it can make sense to create an easy to read documentation, e.g. in form of an Excel sheet. Nicola Suter offers a script solution for this.
Daniel Chronlund also offers a documentation solution in his DCToolBox.
Microsoft also released Azure AD Exporter.
Fortigi offers a great Conditional Access PowerShell Module.
Microsoft365DSC is another great tool.