When it comes to Conditional Access policies in Microsoft 365, the task isn’t a walk in the park for administrators; it is a critical task to do! While our primary concern is safeguarding our data with these policies, it’s equally important to configure them correctly without disrupting existing user access, apps, locations, and more. Despite our best intentions, tackling this task can become time-consuming! But skipping Conditional Access policies is not the right choice! We must deploy them to protect our organization, as there are no suitable alternatives.
What if you could implement Conditional Access policies in just a few minutes? It’s like finding a hidden treasure but guess what; we’ve really got it! 😌🚀
Daniel Chronlund, a Microsoft MVP, introduces his groundbreaking solution – DCToolbox. With it, he simplifies the intricate process of setting up critical Conditional Access policies, providing your organization with top-tier security.
A single cmdlet, “Deploy-DCConditionalAccessBaselinePoC,” from the DCToolbox provides Microsoft 365 admins with the ability to rapidly deploy Conditional Access policies 😉. The tool offers the following benefits:
- Deployment of 18 essential Conditional Access policies (DCToolbox includes major policies such as blocking high-risk users, mandating MFA for device registrations from non-corporate networks, and disabling token persistence for administrator accounts).
- Configuration times shorter than your coffee break!
- Deployment of Conditional Access policies in report-only mode, allowing for risk-free testing and adjustment.
Let’s dive into the step-by-step guide to easily deploy Conditional Access policies through the DCToolbox for your cybersecurity needs.
Prerequisites to Use the DCToolbox
Before deploying the Conditional Access proof-of-concept design with DCToolbox in your Microsoft 365 tenant, make sure you meet the following prerequisites:
1. Install PowerShell 7 in Windows:
The “Deploy-DCConditionalAccessBaselinePoC” cmdlet from the DCToolbox module requires a minimum version of PowerShell 7. You might be thinking about “how to install PowerShell 7”, but the answer to the question is very simple! So, follow the steps below for installing PowerShell 7 in Windows.
- Execute the below cmdlet in the Windows PowerShell to check the latest version of the PowerShell.
1winget search Microsoft.PowerShell - Then, run the following cmdlet to install the latest version of PowerShell.
1winget install --id Microsoft.Powershell --source winget
2. M365 Global Administrator Role:
You need to run DCToolbox with Global Admin permissions to consent to the required permissions during authentication. These permissions allow the DCToolbox to access the organization’s data through the MS Graph PowerShell.
Baseline Conditional Access Policies – DCToolbox
DCToolbox is a central hub for Daniel’s Conditional Access automation tools, PowerShell Graph functions, and more. However, before deploying Conditional Access policy automation, it is important to understand the actions that are performed when “Deploy-DCConditionalAccessBaselinePoC” is successfully run.
- 18 Conditional Access policies -Designed to manage and control user access, guest access, app usage, access from specific countries, and more.
- Out of these 18 policies, 16 policies are in report-only mode. The remaining two are set to an off state.
-
- One is a sample policy, and the other one is a policy that requires device compliance.
- Because device compliance doesn’t support the report-only mode, it will be deployed in the off state.
Expert’s insight: According to Daniel, these 18 baseline Conditional Access policies have safeguarded hundreds of thousands of users for over four years. Hence, organizations can effectively utilize them to elevate their security measures 🚀.
Deploy-DCConditionalAccessBaselinePoC: Cmdlet Highlights
The cmdlet “Deploy-DCConditionalAccessBaselinePoC” offers the following key benefits within the DCToolbox PowerShell module.
- The cmdlet checks for the presence of the Microsoft Graph PowerShell module and installs it if not found on your PC.
- It automatically prompts you for your Microsoft 365 global administrator credentials to connect to Microsoft Graph PowerShell.
- It newly creates a group for break glass accounts and adds the admin to it who is currently working with the DCToolbox.
- The cmdlet separately creates a service account group for non-human identities (identities to represent software workload, computers, mobile, IoT sensors, and more) in the Entra ID.
- Creates a named location in CA policies for your corporate IP addresses and automatically adds your current public IP address to the list.
- Creates a named location for some allowed countries, as the developer added some countries that he tends to work in as examples.
- Uploads a terms of use for CA policies template in the English language.
Configure Entra ID Conditional Access PoC with DCToolbox
To deploy the complete suite of Conditional Access Policies in your tenant using the DCToolbox, follow the steps below:
- Install DCToolbox module: First, install the DCToolbox module in the PowerShell 7 core using the following cmdlet.
1Install-Module -Name DCToolbox - Update DCToolbox module: If you already installed this module, just execute the above same cmdlet with parameter ‘Force’.
1Install-Module -Name DCToolbox –Force - Execute the cmdlet: Next, execute the PowerShell cmdlet below which deploys the Complete Entra ID Conditional Access proof-of-concept. This cmdlet automatically connects to MS Graph PowerShell and deploys the list of the 18 policies to be configured. It also creates the groups, terms of use, and named locations required for the 18 policies. The whole process will be finished within a few minutes!
1Deploy-DCConditionalAccessBaselinePoC
Points to Remember!
1. As mentioned earlier, the cmdlet auto-generates policies, groups, named locations, and terms of use with default names. If you wish to create these elements with custom names or to use existing groups, you can do so by using distinct PowerShell parameters.2. However, it’s important to note that once you’ve deployed the CA policies without custom names, you cannot rename them using these parameters. Attempting to do so will result in the creation of a new set of 18 policies with different name dependencies.
- Sign in as global admin: Upon execution, it asks for the admin credential details in the browser. Sign in with the global administrator credentials.
- Grant permissions: After successful authentication, permissions to access and modify data of users, applications, policies, and groups must be granted. So, click the ‘Accept’ button to continue. This action allows the cmdlet to access and manage Microsoft Graph resources, such as users, groups, and applications.
- CA policies deployment: Finally, the 18 baseline Conditional Access policies will begin to deploy in your tenant in the read-only mode. These policies are designed to provide a basic level of security for your organization’s resources.
Once the “Deploy-DCConditionalAccessBaselinePoC” cmdlet has completed its execution, your organization will have a basic set of Conditional Access policies established. You can then customize the deployed policies to align with the specific requirements of your organization.
Monitor and Manage Conditional Access Policies Deployed with DCToolbox
The Conditional Access policies state will be set to “report-only” mode, so it’s essential to review and activate them in the Entra ID environment. Just follow the below path to access the configured CA policies:
Microsoft Entra Admin Center → Protection → Conditional Access → Policies
Here, you’ll find a table listing the policies configured in Entra ID.
Policies starting with “GLOBAL…” are configured through DCToolbox. These DCToolbox CA policies are categorized into three sessions: Block Policies, Grant Policies, and Session Policies.
- Block Policies: This category consists of 8 policies that focus on preventing unauthorized access to your organization’s resources under specific conditions. These policies are on proactively securing sensitive data and mitigating potential threats.
- Grant Policies: This section contains 7 policies focused on access provisioning, which controls user access to cloud resources based on specific conditions. This can be useful for controlling user access to grant your organization’s data and resources.
- Session Policies: The session policy category encompasses 2 policies that control the active sessions, determining factors like token persistence and file downloads on managed and unmanaged devices.
While the Conditional Access policies are deployed in report-only mode, you can monitor CA policy changes through Microsoft Entra ID using sign-in logs, audit logs, reporting workbooks, and more. By viewing these CA policy changes using the methods described above, you will gain insights into their impacts and effectiveness within your environment.Based on these results, you can selectively enable the policies in your organization one by one.
The following table presents 18 Conditional Access policies with a small description configured through the DCToolbox.
| Category | DCToolbox Policy Name | Description |
| Example Policy | CUSTOM – GRANT – Example | An example policy for deviations from global policies. Group of users with the custom grant example policy can be excluded from global policies. |
| Block Policies | GLOBAL – BLOCK – Legacy Authentication | Blocks insecure legacy protocols such as ActiveSync and IMAP. |
| GLOBAL – BLOCK – Unsupported Device Platforms | Blocks unsupported device platforms like Linux. | |
| GLOBAL – BLOCK – Countries not Allowed | Blocks connections from countries not in the whitelist. | |
| GLOBAL – BLOCK – Service Accounts (Trusted Locations Excluded) | Blocks service accounts from untrusted IP addresses. | |
| GLOBAL – BLOCK – Explicitly Blocked Cloud Apps | Explicitly blocks certain cloud apps. | |
| GLOBAL – BLOCK – Guest Access to Sensitive Apps | Blocks guest access to sensitive apps. | |
| GLOBAL – BLOCK – High-Risk Sign-Ins | Blocks high-risk authentications detected by Entra ID Protection. | |
| GLOBAL – BLOCK – High-Risk Users | Blocks high-risk users based on user risk level. | |
| Grant Policies | GLOBAL – GRANT – Medium-Risk Sign-Ins | Enforces MFA on medium-risk authentications. |
| GLOBAL – GRANT – Medium-Risk Users | Enforces MFA on medium-risk users. | |
| GLOBAL – GRANT – Device Registration | Enforces MFA for device registrations from non-corporate networks. | |
| GLOBAL – GRANT – Terms of Use | Requires users to agree to terms of use policies. | |
| GLOBAL – GRANT – MFA for All Users | Protects all user authentications with MFA. | |
| GLOBAL – GRANT – Mobile Apps and Desktop Clients | Requires mobile apps and desktop clients to be Intune compliant. | |
| GLOBAL – GRANT – Mobile Device Access Requirements | Requires apps to be protected by Intune App Protection Policies. | |
| Session Policies | GLOBAL – SESSION – Admin Persistence | Disables token persistence for admin accounts. |
| GLOBAL – SESSION – Block File Downloads On Unmanaged Devices | Blocks file downloads on unmanaged devices. |
Advanced Operations with Different PowerShell Parameters
Adding specific parameters with the “Deploy-DCConditionalAccessBaselinePoC” cmdlet can perform some advanced actions with the baseline policy creation.
Add Prefix to the CA Policy Names
To add a prefix with the policy name, use the ‘AddCustomPrefix’ parameter with the cmdlet. The prefix with the policy name helps identify that the policy is created using DCToolbox. This makes it easy to differentiate from existing policies.
|
1 |
Deploy-DCConditionalAccessBaselinePoC –AddCustomPrefix <CustomPrefixThatYouWishToUpdate> |
Use Custom Name for Groups and Named Locations
The tool automatically creates groups and named locations with a predefined default name. To create those with other names or to link with the existing ones, execute any one of the following cmdlets concerning your needs.
- For a break glass exclude group, you can link to an existing group, or you can specify a name to create a new group using the ‘ExcludeGroupDisplayName’ parameter.
1Deploy-DCConditionalAccessBaselinePoC –ExcludeGroupDisplayName <GroupNameThatYouWishToUpdate> - By the way, you can use the ‘ServiceAccountGroupDisplayName’ parameter for the service account groups as demonstrated below.
1Deploy-DCConditionalAccessBaselinePoC –ServiceAccountGroupDisplayName <GroupNameThatYouWishToUpdate> - To set a custom name for the corporate network named locations, use the ‘NamedLocationCorpNetwork’ parameter.
1Deploy-DCConditionalAccessBaselinePoC –NamedLocationCorpNetwork <CustomNameforCorpNetworkList> - To set a custom name for the allowed country’s named locations, use the ‘NamedLocationAllowedCountries’ parameter.
1Deploy-DCConditionalAccessBaselinePoC –NamedLocationAllowedCountries <CustomNameforAllowedCountriesList>
Use Existing Terms of Use
To use the existing terms of use for the DCToolbox CA policies, use the ‘TermsOfUseName’ parameter.
|
1 |
Deploy-DCConditionalAccessBaselinePoC –TermsOfUseName <ExistingTermsName> |
Skip Conditional Access Policies
To skip some of the baseline CA policies from the list of 18, you can use the ‘SkipPolicies’ parameter.
|
1 |
Deploy-DCConditionalAccessBaselinePoC -SkipPolicies <DCToolboxCAPolicyNamesSeparatedByComma> |
Directly Enforce Conditional Access Policy
To skip the report-only mode and to apply the CA policies directly, use the parameter ‘SkipReportOnlyMode’.
|
1 |
Deploy-DCConditionalAccessBaselinePoC -SkipReportOnlyMode #Not Recommended! |
Warning: This direct enforcement is not recommended! Any misconfiguration in the policies can immediately disrupt user access to critical resources, leading to potential business interruptions. Users might be denied access to applications and data, affecting their productivity and causing frustration. That’s why it is always recommended to test the policy with the report-only mode before enabling it for normal use.
PowerShell Script to Customize the DCToolbox CA Policies Dependency Names
In addition to the above parameters with the cmdlets, you can generate and use a script like below to apply different names for the dependencies. This methodology helps the Microsoft 365 admins to incorporate the above-discussed parameters in a single execution.
|
1 2 3 4 5 6 7 8 |
$Parameters = @{ ExcludeGroupDisplayName = 'Excluded from Conditional Access' ServiceAccountGroupDisplayName = 'Conditional Access Service Accounts' NamedLocationCorpNetwork = 'Corporate Network' NamedLocationAllowedCountries = 'Allowed Countries' TermsOfUseName = 'Terms of Use' } Deploy-DCConditionalAccessBaselinePoC @Parameters |
Final Thoughts
In just a matter of minutes, M365 admins can create fully functional Conditional Access policies without the need to configure individually! This approach is tailored for admins, those who appreciate the value of time and security, providing a streamlined, automated solution.
Kudos to the Most Valuable Professional, Daniel Chronlund for his wonderful work 👏.
Also, you can easily monitor Conditional Access policies with the Maester tool, which has 20+ CA policy tests to find misconfigurations in your tenant. Furthermore, there is one more beneficial tool- “Microsoft365DSC“. It’s your one-stop solution! You can make use of Microsoft365DSC to auto-deploy tenant settings like conditional access, user properties, mailbox permissions, bulk license updates, and more. Use it too, and let automation handle your task!
We hope that this blog will help M365 admins deploy Conditional Access policies in their domain. Feel free to leave your thoughts in the comments section. Stay tuned for more insights 🙌!
