DCToolbox – An Easy Approach to Deploy Conditional Access Policies

type

status

date

summary

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.

1	winget search Microsoft.PowerShell

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

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

1	Install-Module -Name DCToolbox

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

1	Install-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! 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.

1	Deploy-DCConditionalAccessBaselinePoC

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.

Global Admin Authentication

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.

Deploy Conditional Access Policy through DCToolbox - Permissions

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.

DCToolbox Conditional Access Policy Deployment

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.

DCToolbox - CA policies

While the 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. After analyzing these policies 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.

1	Deploy-DCConditionalAccessBaselinePoC –ExcludeGroupDisplayName <GroupNameThatYouWishToUpdate>

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

1	Deploy-DCConditionalAccessBaselinePoC –ServiceAccountGroupDisplayName <GroupNameThatYouWishToUpdate>

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

1	Deploy-DCConditionalAccessBaselinePoC –NamedLocationCorpNetwork <CustomNameforCorpNetworkList>

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

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

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.

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 .

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 !

Lock and Unlock SharePoint Sites in Microsoft 365

SharePoint Online, an integral part of Microsoft 365, serves as a valuable resource to collaborate and share information through dedicated sites. While SharePoint Online offers effective collaboration, there are instances where controlling site access becomes crucial, particularly to meet compliance requirements. In such situations, it is essential for an admin to know how to lock and unlock SharePoint sites.

In this informative blog, we will explore the process of how to lock and unlock SharePoint sites in Microsoft 365. Let’s get started!

Purpose of Unlocking and Locking SharePoint Sites in Microsoft 365

Locking and unlocking the SharePoint sites serves the following essential purposes for the SharePoint site collection administrators:

Locking up the SharePoint sites helps the admins to prevent users from adding new contents when the site is under maintenance or upgradation.

Keeping a SPO site in a read-only state ensures that the content remains unaltered and untouched by users.

The unlock permissions allow the users to access or update the SPO sites that that have been locked or set to read-only.

Lock and Unlock Sites in SharePoint Online

In Microsoft 365, a Global administrator or a SharePoint administrator can restrict access to a SharePoint Online site collection using Windows PowerShell.

Admins can perform any of the below listed SharePoint Online Sites operations with respect to their needs. Before getting started with any of the following listed operations, make sure to connect to the SharePoint Online PowerShell. You can use either Windows PowerShell or the SharePoint Online Management Shell to perform the cmdlet operations.

Lock SharePoint Online site

Set SharePoint Online site to read-only

Unlock SharePoint site collections

Check lock status for site collections

Redirect SharePoint sites with no access to another site

Lock SharePoint Online Site Using PowerShell

As an admin, you can lock a particular SharePoint site in your tenant using the ‘Set-SPOSite’ cmdlet.

1	Set-SPOSite -Identity https://contoso.sharepoint.com/sites/resourceportal -LockState NoAccess

The SharePoint ‘LockState’ parameter with the value ‘NoAccess’ in the above cmdlet renders the “Resource Portal” site inaccessible. Replace the site URL with the appropriate SPO site URL to lock access.

When a user attempts to access the SharePoint Online site which has no access, they will receive a “403 FORBIDDEN” error.

Lock a SharePoint Online Site

Set SharePoint Online Site to Read-only Mode Using PowerShell

The ‘ReadOnly’ value with the ‘LockState’ parameter in the ‘Set-SPOSite’ cmdlet makes the SharePoint Online site read-only mode. Users of the specific SharePoint Online site are unable to update any content within the site.

1	Set-SPOSite -Identity https://contoso.sharepoint.com/sites/resourceportal -LockState ReadOnly

The execution of the cmdlet with the appropriate SharePoint site URL makes the site read-only mode.

Read Only mode SharePoint Online Site

While accessing the SPO site having read-only permission, site owners and users will encounter a message stating, “This site is read-only at the administrator’s request.”

Furthermore, when opening any documents on the site, these documents are also accessible in read-only mode.

Note: To provide read-only access or different permission levels for only a certain set of SharePoint users, consider configuring SharePoint permission levels.

Unlock SharePoint Site Collections Using PowerShell

To remove SharePoint site from read-only mode or no access mode, you can use the below cmdlet.

1	Set-SPOSite -Identity https://contoso.sharepoint.com/sites/resourceportal -LockState Unlock

Executing this cmdlet will bring the SharePoint Online site to its normal state without any restrictions.

Note: This cmdlet will not unlock the site if the SharePoint site is closed and set to read-only through a site closure policy.

Check Lock Status for Site Collections Using SharePoint Online PowerShell

Execution of the below cmdlet with the appropriate site URL gives the SharePoint lock state.

To know which site collections are locked in SharePoint online, run the following cmdlet.

Lock Status for all SharePoint and OneDrive Site Using PowerShell

Redirect SharePoint Sites with No Access to Another Site

Admins can opt to redirect the SharePoint site with restricted access to a particular URL rather than showing the usual “403 FORBIDDEN” page. To do so, utilize the ’Set-SPOTenant’ cmdlet with the required URL as demonstrated below.

To revert the redirection, you can use an empty string (“”), indicating no redirection site URL.

Note: If you want to manage site redirects to another page simply execute the same cmdlet with another site URL.

Important Points to Remember

As of now, you can’t lock and unlock SharePoint sites through the Microsoft 365 admin center or SharePoint admin center.

The same configuration regarding the locking and unlocking SharePoint sites can be applied to the personal OneDrive sites. Configuring these operations in OneDrive sites will block the respective Microsoft 365 users from accessing or making changes to those sites.

SharePoint Online root site can’t be locked as it would potentially block access to critical administrative and organizational resources.

The SharePoint site collection can’t be deleted, if it is in a locked or read-only state.

Conclusion:

In this guide, we’ve learned how to manage SPO sites, specifically focusing on how to lock and unlock SharePoint sites in Microsoft 365. These PowerShell cmdlets support your organization, helping you meet compliance requirements and maintain precise access control.

If you have any questions about the blog, don’t hesitate to ask in the comments section. We’re here to address your inquiries.