DCToolbox – An Easy Approach to Deploy Conditional Access Policies

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.

Before deploying the Conditional Access proof-of-concept design with DCToolbox in your Microsoft 365 tenant, make sure you meet the following prerequisites:

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.

1. Execute the below cmdlet in the Windows PowerShell to check the latest version of the PowerShell.
   
   PowerShell

   winget search Microsoft.PowerShell

   1	winget search Microsoft.PowerShell

2. Then, run the following cmdlet to install the latest version of PowerShell.
   
   PowerShell

   winget install --id Microsoft.Powershell --source winget

   1	winget install --id Microsoft.Powershell --source winget

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.

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 🚀.

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.

To deploy the complete suite of Conditional Access Policies in your tenant using the DCToolbox, follow the steps below:

1. Install DCToolbox module: First, install the DCToolbox module in the PowerShell 7 core using the following cmdlet.
   
   PowerShell

   Install-Module -Name DCToolbox

   1	Install-Module -Name DCToolbox

2. Update DCToolbox module: If you already installed this module, just execute the above same cmdlet with parameter ‘Force’.
   
   PowerShell

   Install-Module -Name DCToolbox –Force

   1	Install-Module -Name DCToolbox –Force

3. 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!
   
   PowerShell

   Deploy-DCConditionalAccessBaselinePoC

   1	Deploy-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.

4. Sign in as global admin: Upon execution, it asks for the admin credential details in the browser. Sign in with the global administrator credentials.
   
   
5. 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.
   
   
6. 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.

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, Conditional Access insights and reporting workbook, 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.

Adding specific parameters with the “Deploy-DCConditionalAccessBaselinePoC” cmdlet can perform some advanced actions with the baseline policy creation.

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.

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.
  
  PowerShell

  Deploy-DCConditionalAccessBaselinePoC –ExcludeGroupDisplayName <GroupNameThatYouWishToUpdate>

  1	Deploy-DCConditionalAccessBaselinePoC –ExcludeGroupDisplayName <GroupNameThatYouWishToUpdate>

• By the way, you can use the ‘ServiceAccountGroupDisplayName’ parameter for the service account groups as demonstrated below.
  
  PowerShell

  Deploy-DCConditionalAccessBaselinePoC –ServiceAccountGroupDisplayName <GroupNameThatYouWishToUpdate>

  1	Deploy-DCConditionalAccessBaselinePoC –ServiceAccountGroupDisplayName <GroupNameThatYouWishToUpdate>

• To set a custom name for the corporate network named locations, use the ‘NamedLocationCorpNetwork’ parameter.
  
  PowerShell

  Deploy-DCConditionalAccessBaselinePoC –NamedLocationCorpNetwork <CustomNameforCorpNetworkList>

  1	Deploy-DCConditionalAccessBaselinePoC –NamedLocationCorpNetwork <CustomNameforCorpNetworkList>

• To set a custom name for the allowed country’s named locations, use the ‘NamedLocationAllowedCountries’ parameter.
  
  PowerShell

  Deploy-DCConditionalAccessBaselinePoC –NamedLocationAllowedCountries <CustomNameforAllowedCountriesList>

  1	Deploy-DCConditionalAccessBaselinePoC –NamedLocationAllowedCountries <CustomNameforAllowedCountriesList>

To use the existing terms of use for the DCToolbox CA policies, use the ‘TermsOfUseName’ parameter.

To skip some of the baseline CA policies from the list of 18, you can use the ‘SkipPolicies’ parameter.

To skip the report-only mode and to apply the CA policies directly, use the parameter ‘SkipReportOnlyMode’.

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.

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.

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 🙌!