MDM & GP Tips Blog

Enterprise cloud accounts, particularly services like Office 365, face constant cybersecurity threats from malicious actors. While enforcing strict password complexity requirements can help protect these accounts, this approach alone has significant limitations. Complex passwords may lead users to create workarounds that actually reduce security such as writing passwords down or reusing them across multiple accounts. There is also a linear correlation that as password complexity increases, organizations typically see a corresponding rise in password-related help desk tickets, increasing IT support costs and reducing productivity.

However, even properly authenticated users can pose security risks when accessing systems from compromised devices. Organizations need to prevent access from endpoints that have security vulnerabilities or malware infections, regardless of valid user credentials. Of course, when users are accessing resources from their home, you can’t be sure what type of device they may be using.

If you use Microsoft Intune to manage your user accounts, you can leverage two key policy types working in tandem: Conditional Access policies and compliance policies. When implemented together, these policies ensure organizational resources are only accessible from devices that meet your security requirements. Conditional Access policies define the circumstances under which access is permitted, while compliance policies establish the security standards devices must maintain.

Create a Compliance Policy

Compliance policies in Microsoft Intune are sets of rules and conditions used to evaluate the configuration of your managed devices. These policies help secure organizational data and resources by ensuring devices meet specific configuration requirements. Devices must satisfy the conditions set in these policies to be considered compliant by Intune such as:

• Requiring encryption (e.g., BitLocker).
• Enforcing password complexity.
• Ensuring the device is not jailbroken or rooted.
• Setting minimum/maximum OS versions

To create a compliance policy in the Microsoft Intune Admin Center, navigate to Devices > Compliance and select “Create Policy” as shown in the screenshot below.

Name your policy and then choose the compliance settings you want. In the example below, I want all compliant machines to have BitLocker, Secure Boot, and Code integrity enabled. Because all my employees are running machines with Windows 11, version 22H2, I chose that as the minimum operating system to be compliant. For the minimum operating system version in Intune, you would specify:

Minimum OS Version: 10.0.22621.0

This corresponds to Windows 11, version 22H215. By leaving the maximum OS version blank, you are allowing those with later versions access. See the screenshot below.

Because I am running Microsoft Defender for Endpoint on employee machines, I will configure Microsoft Defender for Endpoint rules in the compliance policy. Here, I am requiring that all devices be at or under a machine risk score of Low. This means that Devices with "Medium" or "High" risk scores will be marked as noncompliant.

The compliance policy will immediately mark the device as noncompliant when any one of these conditions is not met. On the next screen, you can configure additional Actions for noncompliance, such as sending email notifications to users or remotely locking devices. For this example, I am going to skip this section and proceed to apply the policy to all users and groups.

Creating a Conditional Access Policy

Conditional access policies serve as a type of gatekeeper for designated resources of your organizations. These policies make real-time decisions about whether to grant, limit, or block access to resources based on specific conditions. You can create policies that do things such as:

• Require MFA when accessing resources from outside your corporate network
• Only allow access from devices that are encrypted and up-to-date on security patches
• Block access from countries where your company doesn't operate
• Enforce browser-only access for unmanaged devices
• Require periodic re-authentication for sensitive applications

To create a conditional access policy, navigate below to Conditional access and click on “Create new policy” and name it. In my example here, I selected a group and then chose Office 365 as the target as shown below.

One of the purposes of this conditional access policy is to scrutinize all the login attempts from off prem locations. By excluding trusted networks from the policy, we maintain seamless access for users on known secure networks while enforcing additional security measures for connections from elsewhere.

For this configuration to be effective, trusted network locations must be pre-defined in the Microsoft Entra admin center. These typically include:

• Corporate office network ranges
• Known VPN network ranges
• Other verified secure networks

The screenshot demonstrates this configuration:

I then created two conditions that must be met to grant access:

1. Require multifactor authentication (MFA) only for off-premises access attempts. Users accessing resources from within the corporate network (on-premises) will not need to go through MFA.
2. Require that all computers must be compliant with the organization's policies to prevent employees from logging in using personal, potentially unsecured devices when off-prem. The associated compliance policy created earlier ensures that off-premises devices meet the same operating system and Microsoft Defender for Endpoint requirements as on-premises users.

The selections are shown in the screenshot below:

Conclusion

Of course, I have only scratched the surface here of possibilities. The configurations discussed here represent just a small sample of Intune's extensive security capabilities. Conditional Access and compliance policies can be customized with numerous additional controls and requirements to match your organization's specific security needs and risk tolerance. As threats evolve and organizational requirements change, these policies can be adjusted and you should regularly review and update your policies. By leveraging the full potential of Intune's policy framework, organizations can build a dynamic, responsive security posture that aligns with the principles of zero trust while enabling a modern, flexible workplace.

Since the early days of Group Policy, I have been talking about the importance of blocking Windows command prompt for non-administrative users. While it is an essential tool for IT personnel, in the wrong hands, the command prompt can be used to execute potentially harmful commands, access sensitive system files, modify system settings, run malicious scripts, or launch programs that could compromise system integrity. Even barring malicious intent, preventing access helps maintain system stability by preventing accidental misuse of powerful command-line tools that could disrupt operations or expose confidential data.

While the objective may be the same, there are multiple methods to implement this policy in modern IT environments. Let’s explore the various ways to achieve this security measure using Group Policy, Microsoft Intune and the Intune Education portal.  

Using Group Policy

The way to block access to Windows Command Prompt using Group Policy hasn’t changed at all over the years. It is still a straightforward approach. Simply create a new GPO and navigate to User Configuration > Administrative Templates > System > and enable the policy setting “Prevent access to the command prompt" as shown in the screenshot below:

Note that the setting, “Prevent access to registry editing tools” has been enabled which as well and is highly recommended.

Using Intune Settings

Settings Picker

When we start talking about Microsoft Intune, there are multiple ways to block access. The simplest approach is to use the Settings Catalog Configuration Profile. Using the Microsoft Intune admin center, navigate to Devices > Configuration > Create > New policy. Choose Windows 10 and later as the Platform and Settings catalog as the Profile type. Do a search for “CMD” and browse Administrative Templates\System. Then enable the “Prevent access to the command prompt (User)" setting” and choose the “Disable the command prompt script processing also? (User)" if desired. These steps are outlined in the screenshot below.

Note that until December 2024 you could use Administrative Templates to create a new configuration profile to block CMD access. Microsoft has now phased out the use of Administrative Templates for creating new configuration profiles to block CMD access.

OMA-URI Settings

You can also create a Configuration profile using OMA-URI settings. Here are the settings:

• OMA-URI path:  ./User/Vendor/MSFT/Policy/Config/ADMX_ShellCommandPromptRegEditTools/DisableCMD
• Data type: Integer
• Value: 1 (to block) or 2 (to block and disable scripting)

See the screenshot below for an example:

AppLocker Settings

If you've already created an AppLocker Group Policy that successfully blocks the CMD prompt, you can leverage this existing configuration in Intune. Extract the XML content from your Group Policy and deploy it through Intune using OMA-URI settings.

• OMA-URI: ./Vendor/MSFT/AppLocker/ApplicationLaunchRestrictions/apps/EXE/Policy
• Data type: String
• Value: (Paste the XML content of your AppLocker policy here)

Education Portal Method

Some educational institutions with limited IT resources opt for the Education version of Microsoft Intune. This simplified platform is designed to be more accessible, allowing staff members with basic technical knowledge, such as teachers with some IT background, to manage and implement fundamental Mobile Device Management (MDM) policies.

You can access the Intune Education portal at (https://intuneeducation.portal.azure.com/). Then navigate to Groups > All Devices > Settings > Windows Device Settings > Apps. Use the "Block Access to Administrative Apps" option as shown in the screenshot below.

Note that by default, this setting also blocks access to other system apps such as PowerShell and regedit.

It’s a Cloud, Cloud, Cloud, Cloud, Cloud, Cloud world. Except actually most of your stuff is still likely mostly on-prem, or acts that way. Take Windows 10 for instance. Windows 10 has events in the event logs, and maybe you already know about on-prem Event Forwarding.

Tip: If you want to learn more about on-prem Event Forwarding, you can see my Walkthrough of that here video and text.

But how do we take on-prem events from Windows 10 (or Windows Server) and get the up to the cloud for later analysis? If you have 24, 250, or 25,000 domain joined (or even NON-domain joined) machines, say with Windows Intune or PolicyPak Cloud… how can you do the equivalent of event forwarding to some central place?

That is the job of Azure Log Analytics. I’m going to call it “LA” for short.

LA had an original name, OMS which stood for Operations Management Suite, but as near as I can tell, that’s over. But its good to know LA’s original name, because you’ll see OMS pop up from time to time in the walkthrough, docs, and software. Additionally, it’s also good to know that what you’ll see here is build upon the original System Center Microsoft Operations Manager (SCOM); but I won’t be using that function.

The official documentation for LA can be found here; but I had a few stumbles. Some tips o’ the hat to Travis Roberts’ video and blog which also helped give me a leg up. The blog is here and the helpful video series on Azure Log Analytics (though a little old now because of the name and UI changes) can be found at: https://www.youtube.com/watch?v=6hgvjgPBNzE&list=PLnWpsLZNgHzVXXyN9a0jm9xNNDrikHf8I

My goal in researching this project was to give some PolicyPak MDM Customers a quick guide to research interesting events that PolicyPak automatically logs to its own event log. But in this guide, I’m also going to show you how to collect some standard and also some extra event logs.

To get started you need a Log Workspace. This is basically a security block between this collection of logs, and say another collection of logs. Each Log Workspace has a GUID based Workspace ID and two keys (Primary and Secondary.) You’ll use these to send, say, YOUR Windows 10 machines’ event logs to your workspace. And the other Azure admins … you know, those SQL server people or Exchange or whatever … they’ll send their event logs to their workspaces.

To get started use the big search thingie to find “Log Analytics workspaces” like what’s seen here.

Then, there’s a little Wizard (not shown) to help you get started. Basically it’s asking you for names and which Azure region you want to keep the data in. Then after it gets going you’ll see “Your deployment is underway” like what’s seen here.

Then you should be thrown into the Advanced settings like what’s seen here. If not, find the Workspace you just created and click Advanced in the left-side menu. It should get you to this place. Note then the “WORKSPACE ID” and “PRIMARY KEY” like what’s seen here. Hang on to those, you’ll need these in a bit. Then also download the Windows Agent 64-bit or 32-bit to get started for your example machines.

In this example, we’ll be installing the LA Agent by hand on a test machine. In real life you could use, say Windows Intune to deploy it with command line options to just chuck in your Workspace ID and Primary Keys and do the whole thing silently and automatically.

Once you have the download, get it over to your test machine. Machine can be real or virtual. Note that you shouldn’t do this (nor do you need to) for WVD virtual machines. Those have a magical connector to accept event logs to LA; and you shouldn’t need to use this method. (Docs: https://docs.microsoft.com/en-us/azure/virtual-desktop/diagnostics-log-analytics and a blog https://www.mdmandgpanswers.com/blogs/view-blog/windows-10-and-server-event-logs-to-azure-log-analytics-walkthru)

Then, Up, Up and away. Launch the agent.. which requires admin rights. (Or, pro tip: Use PolicyPak Scripts to install it automatically where the script is elevated. https://kb.policypak.com/kb/article/901-policypak-scripts-deploy-software-via-vpn-or-with-policypak-cloud/ )

You’ll need to select “Connect the agent to Azure Log Analytics (OMS)” like what’s seen here.

Then, it’s time to chuck in your Workspace ID and Workspace Key. And you’ll likely keep the default of Azure Cloud: Azure Commercial. Pull the pulldown if you have something unusual to select here.

Yes, you want to check for updates when MS Update kicks in….

And.. you’re basically done.

Now let’s make sure we’re talking in both directions. The Microsoft Monitoring Agent is found in Control Panel… which is a weird place, but, hey… that’s okay.

Then click the Azure Log Analytics (OMS) tab and … see you’re talking outbound.

Back in Azure, in the Advanced Settings page, the zero should be one !

Now it’s time to add in the actual event logs you want to capture. Note that the more you capture, the more you pay. Strictly speaking for the PolicyPak customer I made this blog entry for, he only needed to capture the PolicyPak log (which I do last.) But just for completeness and testing, I’ll capture some more too, since you might not have the PolicyPak Log. (And, why don’t you!? Come on over and check out PolicyPak for Pete’s sake. Really, your sake to be honest.)

So just type Application then +. Then System and + and bingo. Those are “well known” logs which LA knows about and pre-populates this list. But PolicyPak? Not as common.. (Yet !) Therefore you could take a guess that our event logs are named PolicyPak (they are…). But how would you know?

The trick is to find the log you want to capture in Windows, and go to its properties and get its Full Name like what’s seen here. Yeah, this one was easy.

But some are harder. I also wanted to capture the MDM event log which has a goofy and weird name. To get it, I went into an Event inside that log and captured its name microsoft-windows-devicemanagement-enterprise-diagnostics-provider/Operational and its brother microsoft-windows-devicemanagement-enterprise-diagnostics-provider/admin.

You can see that second log here…

Once I pasted in all the logs and added them, I clicked Save and got this !

Data.. data? Do we have data ? Click on Logs and close the sample queries. Let’s just see what have. All of it (which shouldn’t be much.)

In the top box, type
SEARCH *
Then click Run. Bingo.. out should pop all the events that have been captured. You can change the Display Time to make sure that you’re getting the right events, right now.

It took a little while for the non-well-known logs to show up. But maybe it will work faster for you than for me. If you want to give it a shot and try your non-well-known logs, like this, give it a go.
Event | where Eventlog == "PolicyPak"
Then click Run again.
Pow! Here come your logs.

Then I can also dig into an event, and … hey look ! EastSalesUser1 ran Procmon, and PolicyPak did the elevation ! Amazeballs !

That’s it. Well, that’s basics anyway.

Remember this blog is a simple walkthrough / getting started. This isn’t “Magic Tricks with Windows Analytics.” But if I had this guide, I would have been up and running about 10x faster. So I hope this helps you out and shows how you can take on-prem or “Always on the go” Windows 10 machines and record their logs, then sort thru them for actionable items and trends.

In Part 1, of our blog series outlining the details of Azure security defaults, we left off on the topic of MFA registration, which utilizes the Microsoft Authenticator app.  While all users MUST register for MFA, MFA is not required for all users every time.  Security defaults does enforce MFA for privileged accounts every time they log on as these accounts have increased access to your environment.  Security defaults requires added authentication for the following nine Azure administrator roles.

• Global administrator
• SharePoint administrator
• Exchange administrator
• Conditional Access administrator
• Security administrator
• Helpdesk administrator or password administrator
• Billing administrator
• User administrator
• Authentication administrator

MFA should be standard policy for all Azure admin account as account takeover attacks are one of the leading types of threats today.  Cybercriminals specifically target privileged accounts so special attention is needed.

Protecting all users

Security defaults is about improving the protection for all users, not just admin accounts.  While MFA is not required of every logon attempt, non-admin users are prompted for additional authentication when connecting from a new device or app.  There may be other instances that trigger MFA for standard users as well.

Limitations of MFA using security defaults

As mentioned, security defaults gives you free access to Azure AD MFA.  Free however, has its limitations.  Some of these shortcomings are listed below.

• Admins have no control over verification methods
• SMS and phone calls are not available as second factors
• You cannot configure trusted IPs for MFA exclusion
• An exclusion account for emergency access
• No MFA reports or fraud alerts

Again, keep in mind that Azure security defaults gives you the bare security minimum.  To obtain more features and control over MFA, you will need to ante up some additional money.  If you have a license for Conditional Access but have not yet enabled it, you can use security defaults as a temporary security band-aid until you are ready to enable Conditional Access policies.

Blocking legacy authentication

The majority of compromising sign-in attempts come from legacy authentication.  These credential stuffing or account takeover attacks tend to be automated and performed by bot nets.  Legacy authentication utilizes protocols that only use basic authentication.  These outdated protocols only require single factor authentication and cannot enforce a second factor as part of the natural authentication flow.  This is in contrast to modern authentication, which does support second factor authentication.  Using legacy authentication, an imposter can simply bypass your active MFA policy.

Client applications or services that use legacy authentication also have a blaring vulnerability in that credentials are collected and then stored until validated against an authority.   Apps or services that utilize modern authentication never store credentials.  Instead, they only present them.  In other words, modern authentication never trusts the app or service that is requesting your credentials. 

For these reasons, it is highly recommended that legacy authentication protocols such as IMAP, SMTP and POP3 be blocked.  This means that clients cannot use an older version of Office 2010 but can use a more current version such as Office 2016.  Some email/faxing software and other types of applications require the use of these older protocols.  Make sure that none of your applications are using legacy authentication protocols before enabling security defaults.   

Protecting privileged actions

We mentioned how security defaults uses MFA to protect privileged user accounts.  It also protects privileged actions as well.  This is important because non-admin users can be delegated to Azure Resources.  Azure services can be managed through the Azure Resource Manager API.  These services include:

• Azure portal
• Azure PowerShell
• Azure CLI

These services give users tenant wide powers such as the ability to modify configurations, service settings and billing subscriptions.  This is why it is imperative to verify the identity of users that utilize them.  When enabled, security defaults will require added authentication before allowing delegated access. 

Conclusion

Azure AD security defaults certainly has its shortcomings and should not be considered a long-term solution for any sizable organization.  It also does not provide the rich security protections that many organizations need to satisfy security policies or compliances.  It does provide a “one-click” easy button that new tenants can use to protect themselves right out of the gate while they begin to learn their solution options.  While it may provide ample protection for small organizations, tenant owners should view it as a transitory measure only.  Security defaults is a great first step and one that hopefully, will better secure the entire O365 community as well. 

The old adage, “You can lead a horse to water but you can’t make them drink,” certainly applies to cybersecurity today.   You can provide users and organizations with all types of cybersecurity tools and policies, but as long as they are optional, you cannot make them utilize them.  A case in point is the enforcement of multifactor authentication (MFA) for Azure.  Despite the fact that Microsoft attests that MFA will prevent 99.9 percent of account compromises, only around 8 percent of administrative accounts in Azure AD use it.  In a world in which credential stuffing attacks initiate billions of malicious login attempts on a monthly basis, MFA should be an enforced policy for every organization.  The hard truth is that we live in a digital world in which security is no longer optional. 

Depreciation of Baseline Security Policies

Microsoft has already been providing a set of predefined policies to help organizations protect themselves against common attacks.  There were four baseline policies.

• Require MFA for admins (preview)
• End user protection (preview)
• Block legacy authentication (preview)
• Require MFA for service management (preview

Azure admins could enable or disable them for their Azure userbase.  Unfortunately, too many organizations have not taken advantage of these policies or the rich set of security capabilities such as Conditional Access.  This not only makes them more vulnerable, but adds to the collective threat environment for everyone else as well.  Every computer that is compromised serves as one more potential attack vehicle that perpetrators can use for malicious deeds towards others.  The IT industry is starting to recognize that organizations not only have a responsibility to protect their own users, but share in the universal collective effort to make the world a less vulnerable place.  By hardening up our own attack surfaces, we harden the world as well.  As a result, Microsoft is depreciating these predefined policies on February 29, 2020, replacing them with the new “Security Defaults.”

What are Azure Security Defaults?

The intention of Security Defaults is simple; provide an enforced default security state for all Azure organizations that do not implement security policy initiatives on their own.  Security Defaults are available to all tenants and like Baseline Security policies, are offered at no additional cost.  New tenants will automatically have security defaults enabled by default.  If your tenant was created on or after October 22, 2019, chances are that security defaults is already enabled.  In the coming phase, Microsoft will begin retroactively enabling it for existing domains who have failed to enact any security measures on their own.  These security defaults enforce the following:

• Unified Multi-Factor Authentication registration
• Multi-Factor Authentication enforcement
• Blocking legacy authentication
• Protecting privileged actions

If you are an existing tenant prior to the October date and currently and currently do not utilize security policies of any kind, you will need to enable Security Defaults for now.  You can do this by going to Azure Active Directory > Properties > “Manage Security defaults” and set the Enable security defaults toggle to Yes as is shown below.

If you currently utilize Conditional Access, Classic or Identity Protection policies that consist of settings that may conflict with any of the security default offerings, you will receive an error message when trying to enable default security policies as is shown below.

Note that you will have to disable Security defaults before creating conditional access or other security policies that involve conflicting settings.  Keep in mind too that Security defaults is a bare minimum.  While they may be appropriate for small organizations, medium or large enterprises should expand into policies that are more comprehensive. 

MFA Registration

Let’s start with multifactor authentication.  Security defaults require all users within the tenant to register for MFA.  MFA requires a user to use a second method of authentication to prove their identity in addition to their logon credentials.  The most popular method currently is SMS MFA in which the user must type in a unique one-time code sent to their cell phone after logging on with their assigned credentials.  While this and other methods are available in Azure Conditional Access policies, it is not an available option under Security defaults.  Azure Security defaults only utilizes the Microsoft Authenticator app

Once you enable Security defaults, users are required to register for MFA within 14 days.  The 14-day clock starts from the time the user logs on for the first time once the security defaults are enabled.  Should a user fail to register within this required time frame, the user will not be able to logon until the FMA registration is completed.  The screenshot below shows what users will see during the 14-day registration period.

In addition to completing the MFA registration process, users must also install the Microsoft Authenticator app on their cell phone.  We will cover Multi-Factor Authentication enforcement in Part 2 of this blog series.