So, you rolled out Windows 365 and followed my blogs and did all of your fancy things for your offshore resources throughout Europe and Asia. With these being remote workers, you have concerns about them using Windows 365 to access your Microsoft environment from untrusted or insecure endpoints. Maybe you can just restrict things from international IP addresses? Nope, that won’t work! So, what do we do?! Enter the Dragon…err Entra Conditional Access to the rescue! We will talk about how to restrict access for specific users to their Cloud PCs, break down the policy, and ensure we’re on solid footing moving forward.
What Does an Entra Conditional Access Policy Solve?
As I’ve covered in the past, the artist formerly known as Azure AD Conditional Access will basically focus a signal, a decision, and enforcing that decision.
Basically, a thing will be the scope known as the signal like a user, group, device, etc., a decision will be made about that signal, and we’ll enforce it. When it comes to Windows 365, if we’re not using Windows 365 Boot (which is still in preview), how can we be sure that people are accessing resources from the device we intended?
Luckily now, we can leverage Entra Conditional Access to solve this exact problem. Let’s cover each part of this!
Windows 365 Signals for Entra Conditional Access
Our first signal is the user groups that we want to scope this to. We scope it because we don’t want to enforce it for all of our US users. Well, you might, but I don’t!
Next, we look at the resources we’re targeting. Ideally, I wanted to target all cloud apps:
I learned that currently you cannot exempt out Windows 365’s client (as it uses AVD), so I had to pick the apps that I want to lockdown:
The final part of the signals is the exclusion filter. We add in a basic filter to say “exclude all Cloud PCs from this policy”
You can either physically add the rule syntax or specifically just select the rule builder property “model”
device.model -startsWith "Cloud PC"Another option that some may consider is only scoping this to specific platforms. For example, if we want to let those people access their email from their mobile device, we might just scope it to desktop platforms like this:
Now that we have finished that, we move to decisions and enforcement to finish things up.
Windows 365 Decisions and Enforcement for Entra Conditional Access
Our decision is pretty basic. You just need to select “Block Access”
The decisions and enforcement are fairly simple in this particular case as we simply don’t want to allow any access that isn’t coming from a Cloud PC for our offshore resources, but overall, the idea is simple. Build out the scope, exclude Cloud PCs from the policy, and block access.
It’s a very easy thing to overlook because we never know how users are going to try to use our technology, but with Entra Conditional Access we can fill gaps through looking for holes in our design.
Final Thoughts
The main point of this article was to bring something to light that many people are likely overlooking. We never know how people are going to use our services, but the data is available for us to evaluate this regularly.
This is a great example of the utility of Windows 365 performance metrics which showed us that one of our new remote workers had basically 0 active time connected to the device. That was a major problem!
Now, we realized that some oversight was required to ensure our remote workers used our technology as we intended. It’s very easy to overlook these sorts of things, but the idea is to address them in a scalable way that ensures we are protecting our apps and data. Luckily, Microsoft wrote a nice article on this, which led me to realizing how we could extend Entra to strengthen our security posture, which is crucial for all organizations.