The title says it all! I noticed recently as we’re constantly discussing CAPs (Conditional Access Policies) in InfoSec Twitter that people rarely talk about what policies are important for the standard customer. Today, we will discuss just that. This blog covers:

• What Is a Conditional Access Policy?
• MFA for EVERYONE
• Blocking Device Code Flow
• Blocking Legacy Authentication
• Enforcing Device Compliance on All Devices
• Requiring MFA for Intune Enrollment
  • Modifying the Require MFA for Enrollment Policy to Leverage Temporary Access Passes in Federated Environments
• Requiring Phishing Resist Auth for Admin Portals
• Token Protection for Managed Devices
• Requiring Phishing Resistant MFA for Trusted Devices
• Final Thoughts

What Is Entra Conditional Access?

This image below paints the picture of what Entra Conditional Access is:

When we look at conditional access, we think about If then statements. Signals are the “If” in the If statements, which are essentially the “what/who” we are evaluating. Signals could be:

• The Users or Groups entitled to the policy
• The Network the traffic originates from
• Devices or Apps
• Conditions like user risk, sign-in risk, authentication flows, platforms, and more.

The second part are decisions. This is the compelling aspect to conditional access. We focus on allow/block decisions based on various criteria. Some of the popular options are:

• Device in Compliance
• Multi-factor Authentication
• Auth strength
• Requiring Hybrid
• Require Approved Apps

Things get more interesting when you can also make session decisions like:

• Enforcing token protection
• Changing sign-in frequency
• Conditional Access App Control (lets you block downloads for certain cloud apps)
• Disable resilience (stop access to certain apps if Entra goes down)

These decisions led to the actual enforcement of the policy, which could be blocking, requiring users to sign-in to email more frequently, or enforcing MFA. In its totality, Entra Conditional Access is incredibly powerful if you manage to not lock yourself out in the process. Let’s move onto the first crucial policy.

MFA for All Users

This one is relatively easy. Overall, it’s a good idea to enforce MFA for all users at all times. Multifactor authentication is the tent stake of conditional access policies (CAPs).

We leverage this built-in policy and duplicate it by clicking on it, and clicking you guessed it… duplicate!

From there, we just change it to “All Users” and deploy the policy down. So just for reminder it looks like this below. The “Grant” is set the to the multifactor authentication strength, but you could even create your own if you feel so inclined:

Something that you might need to account for in this policy are service accounts/3rd party vendors that aren’t doing things in a great way. Let’s use Okta for example. Okta, currently supports username/password of a global administrator account for its Office 365 integration. We will stay off the “you should support system managed identities/app integrations, etc. soapbox for now.”

In this scenario, you will want to create a trusted network range for Okta specifically to exempt those accounts out of the policy. As you can see here for example:

The gist is, you will want to audit and look at devices that are authenticating sub-optimally and account for it in your policy. Another good example are guest accounts, which you can exempt out:

Chances are your standard guest account may not be able to work with your policy. Probably, I would recommend creating an Entra group of trusted guest users for this purpose instead of a sledgehammer approach.

Blocking Device Code Flow

So, the first question is WTF is device code flow?

Device code flow is used when signing into devices that could lack a local input like a shared device, digital signage, etc. Sort of like when you log into Netflix on your TV at home.

Device code flow is super high-risk that can be used with phishing or accessing corp apps on an unmanaged device. So, with that said we want to leverage a good policy to control device code flow to ensure it’s not okay. If there are places you need it, like in conference rooms there are plenty of leverageable paths to exclude out key devices. The best practice is to tell it to GTFO everywhere imaginable!

We can pretty easily configure this as you can see below. We point it at all users/all apps, the device code flow, and “Block” Access:

Now, if you need to exclude something like your AV VLAN the recommendation is to leverage network exclusions like below, but you could also exclude out with device filters or user groups, depending on your use case:

Blocking Legacy Authentication

Legacy authentication is always an interesting item. Mostly, we want to make sure legacy protocols e.g. POP, IMAP, etc. cannot be used for basic authentication. In Office 365, we can run these commands:

##Login to Exchange Online##
$Session = New-PSSession -ConfigurationName
Microsoft.Exchange -ConnectionUri
https://outlook.office365.com/powershell-liveid/ -Credential
$UserCredential -Authentication Basic -AllowRedirection
##Create the Basic Auth Block Policy##
New-AuthenticationPolicy -Name "Block Basic Authentication"
-BlockLegacyAuthActiveSync -BlockLegacyAuthAutodiscover -BlockLegacyAuthImap -BlockLegacyAuthMapi -BlockLegacyAuthOfflineAddressBook -BlockLegacyAuthPop -BlockLegacyAuthRpc -BlockLegacyAuthWebServices
##Set the Block Policy for Everyone##
Set-OrganizationConfig -DefaultAuthenticationPolicy "Block
Basic Authentication"

You may not even need the policy as most of these items are now blocked by default, but I rather be safe than sorry there. In addition, leveraging Entra conditional access is also a good idea. Overall, it’s a super easy policy to configure.

We scope it to all users and apps, while leveraging conditions to block access for legacy authentication clients as you can see below:

Enforcing Device Compliance on All Devices

This is an item that I am particularly sensitive to. I’ve been in many consulting shops where they let all sorts of people access Office 365/Entra on unmanaged devices. I say, NO MORE! It’s a major challenge because you have to invest in hardware, but it’s super important for your security posture.

Basically, you can give people options (enroll their own device, Cloud PC, physical PC, etc.). From there, we need to look at and make sure our compliance policies are attainable.

In Windows, I keep it fairly basic, as we focus on device security features like TPM, Firewall, AV, etc. The most important part is deploying the policy and see what is creating consistency issues. Once you solidify your device compliance, you have built the foundation for your conditional access policies:

Similarly, in iOS you focus on a policy you know its achievable:

Your policy is easy to configure here as well. We scope everything, set a condition for all device types, and grant access if a device is compliant. The strategy starts and ends with building the right compliance policies. We only want to block people that need to actually be blocked.

One offshoot of this policy is where you might want to block downloads for unmanaged devices. We can create exclusion filters and block downloads for non-compliant devices from OneDrive for example. One key thing to note here are these are Defender for Cloud Apps policies, which require either an E5 license or the standalone cloud apps license.

Check out the video below on how to do that!

Requiring MFA for Intune Enrollment

Update: I’m going to keep this one in the blog article, but after additional testing and consideration I disabled it in my environment. Although it’s a good idea, I don’t think the policy design Microsoft created here was great. The main issue is that it will impact your admins to log in incredibly frequently, so overall I think MFA for everyone is better to focus on.

Another key item that we are focused on is requiring MFA for Intune enrollments. A few things have come up while engineering this one if you use any sort of bulk enrollment tokens. Make sure you create a dynamic group to collect your package accounts and exclude them from the policy. Otherwise, it breaks those enrollments.

That package group rule is super easy:

(user.displayName -startsWith "package_")

We target two apps with our conditional access policy (Intune and Intune Enrollment). I only recommend Intune if you’re going to give people access to their BitLocker keys in the company portal. If so, this is a good measure to keep those secure.

The other half of the policy is setting the grant to “Require multifactor authentication” and “require device to be marked compliant” along with sign-in frequency of every time.

With all of these policies, you should evaluate if you would prefer to leverage authentication strength instead. Sometimes that gives you more of what you are looking for. With that in mind, check out my video in the next section on creating custom auth strengths to meet your organizational needs.

Modifying the Require MFA for Enrollment Policy to Leverage Temporary Access Passes in Federated Environments

I found an interesting use case for leveraging this conditional access policy in federated environments. Specifically, how to let your desktop team pre-setup and enroll devices using TAP despite using an IDP like Ping or Okta. To be clear, this could also apply to Entra-federated environments, you would just remove federated multifactor from the enrollment auth strength policy.

I use this new auth strength I call “Enrollment Strength”:

I made a few changes to the previous policy as well because I learned a few things:

• Modify the app to only be “Microsoft Intune Enrollment”
• Removed the sign-in frequency of every time.
• Modified the MFA for EVERYONE to exclude the Intune Enrollment application.

With these changes, IF you want to, you can now enroll devices with TAP so you can make sure they are SUPER ready for your users and complete the user-driven flow. I find this is useful in certain scenarios and frankly is sort of neat that you can use TAP despite being a federated environment.

Requiring Phishing Resistant Auth for Admin Portals

Another strong recommendation is enforcing phishing resistant MFA for all admin portals. A few key things to mention are:

• The Microsoft Admin Portals app is awesome because its dynamic and will add other portals as we move on.
• If you aren’t using Entra like me, you need to create a custom authentication strength like I mentioned in the previous section and showed on the video.

Phishing resistant MFA are things like Windows Hello for Business, Passkeys, and certificates. We often don’t realize that WH4B isn’t as simple as “I logged in with my PC so I’m good right?”

It means you authenticated to that application with it. So, for those of us with IDPs, we will create a custom auth strength. Check the video below to see how to create it:

Otherwise, this policy is super easy. We just target the Microsoft Admin Portals app and use our custom auth strength and we’re good to go!

Token Protection for Managed Devices

This one needs a bit more explanation. The token protection feature is known as “token binding” to most. This protection will reduce token theft attacks by making it so a token can only be used by that managed device. As a reminder, you will need to have Entra P2 licenses to support this amazing capability.

Attackers frequently now are using various attacks like hijacking or replay to impersonate users. Token protection creates a crypto secure tie between the token and device, which makes the token useless on any other device. This binding is created at Entra join, which gives you some great protections. I just want to touch on the requirements for this one too:

• Windows 10+ that are Entra joined, hybrid joined, or Entra registered.
• OneDrive sync client 22.217+
• Teams 1.6.00.1331+
• Power BI desktop 2.117.841.0+
• Visual Studio 2022+ using Windows authentication broker
• No support for Office perpetual clients

These flows will break things like PS modules, PowerQuery in Excel, Teams 2.1 client, Windows Server, Surface Hub, and MTRs. So, make sure you exclude those device types accordingly. One other note that this feature requires Entra P2 licenses. Now, let’s move onto the setup!

First, we can target two apps (Exchange and SharePoint):

Next, we filter to Entra joined devices (you can add my friend Hybrid in here too):

We only select “mobile apps and desktop clients”

The final piece is requiring token protection for sign-in sessions. We have to do it this way because during the preview we can run into a few different issues if we don’t like:

• Teams web services that leverage MSAL.js can get blocked
• If you try to use other apps beyond SPO and EOL, you will likely run into failures and issues overall.

Requiring Phishing Resistant MFA for Trusted Devices

The final conditional access policy I want to touch on is for a recent attack. Recently, we learned attackers can bypass Windows Hello’s strong authentication as you can read here.

A good way of combating this issue is with this policy, which uses our same device filter:

It will take all of your Entra joined devices and enforce/require phishing resistant authentication:

Essentially, this policy helps ensure that any device that is Entra joined will leverage phishing resistant authentication (or whatever your auth strength policy dictates) to help secure against these attacks.

Final Thoughts

As we wrap things up, I hope this was helpful for people. The reality with Entra CAPs is you will likely have some swings and misses. Make sure you emphasize the need to leverage “Report Only” and monitor how your policies are working and impacting your company.

Don’t be like me and turn on a policy to block device code flow and forget to add block device code flow to it! Conditional Access is pretty difficult, but through testing, iterating, and hard work you can build a strong security strategy for accessing your resources.

More than anything, just keep it simple. Don’t get crazy. When we get complicated and deviate too far from “All Cloud Apps” is where we wind up locking ourselves out and scurrying for our break-glass accounts.