Techtalk:
Top 5 policy misconfigurations

Hello everyone and welcome to another inforcer Techtalk. Today we're going to be talking about the top five most common policy misconfigurations that we see. So these can be things in entra, they could be in defender for office, they could be in Intune, all different common policy misconfigurations or misunderstandings on how things need to be set up.

So hopefully this will be a useful guide and please enjoy. So what's going to be our first policy that we're going to look at? Well, we're going to dive into Entra and have a look at geoblocking. Geobblocking is quite a well-known policy set and it's still widely used by MSPs out there. But what we're going to do is have a look at how some of the ways it could be misconfigured and hopefully we can avoid having that happen.

All right. So, what we need to do first is create some named locations. So, I'm going to create a country's location. So, I'm going to create Australia. And I'll leave it at that. So, I'm just going to name this location Australia. So, now that we've created this location, we can go in and create our policy. So, I'm going to create a new policy and I'm going to call it MFA geo-based. So, this is what we're going to start with.

So, we're going to call geo-based. I'm going to go users. I'll have this apply to all users. Target resources. I'm going to go all resources. Network. I'm going to in configure. Yes. Any selected network or location. So, I'm going to select Australia and I'm going to select my conditions can stay as is and I'm going to require MFA from anyone from Australia. So, I'm going to say require all of the selected controls. I'm happy to turn this on.

I understand that I'll be impacted. So, I've now created a policy to allow Australia. So now that we've created our geo based policy for MFA, let's actually test it. So if we go what if we can go select users cloud apps which is fine. I am going to select a country. So I'm going to say let's say we've logged in for Australia. So I need to enter an Australian IP address and I'm going to pop in an Australian IP address.

So device platform, I've got to pick that anyway. So we go Windows. We'll go modern authentication. That's all fine. Let's I think I actually have to select one. So let's go with Office 365. Let's select Office 365 Exchange online. We select that. And now we go. What if? So if we can see here that MFA geo-based will apply because we've put in an Australian IP address. So MFA will be required and this policy will apply.

Now what happens if we put in a IP address from a country that is not Australia? So I'm now going to pick another country and I'm picked Angola. So I've got an Angolan IP address here. So the same aspects apply. Let's go. What if we can see that our geo-based policy is not implying. So what happens if we had no other conditional access policies? This means that no policy would apply. No MFA would apply. So this is where you need to have the inverse block policy created as well.

So let's now go and create that. So what we're going to do is create a named location. Again, we're going to go countries and we're going to name this blocked countries. And I'm going to include unknown countries and regions. And I'm going to select all except for Australia, which is the one that we previously allowed. So I'm blocking every country now except these ones. So now when you create a new policy, I am going to call this blocked countries.

I'm going to have this apply to all users. I'm going to have all resources targeted again. And for network, I'm going to configure to include our blocked countries list. And in grant, I'm actually going to say block access. So I realize that I'm going to be impacted by this, but I'm happy for that. I'm going to leave it on and I hit create. That rule's now been created. So what we can now do is do that same what if.

So if we come in here, we select myself, select cloud apps. I'm going to select the same exchange online. Device platform will be Windows. Modern authentication. I'm going to put my Angolan IP address in there again. And I'm going to select Angola. What if? And you can see that my blocked countries is blocked access on. So this conditional access will not allow policy will not allow me in. So we can see now that this geoblocking policy is functioning correctly.

So when I'm logging in from Australia, I'm allowed. But when I'm logging in from a country that's not Australia, I'm blocked.

So that's how you configure a geoblocking policy. It's actually interesting too today cuz obviously Microsoft they still have this functionality but they've actually moving away a little bit from recommending it as a standalone security measure because obviously it can be quite easily circumvented by things like a VPN these days. So Microsoft's recommendations now is to use this in conjunction or use the other method instead of this is to use device compliance requirements. So using a conditional access policy that requires a compliant device enrolled in Intune and managed as a better way to secure your devices against nefarious actors getting in because the amount of overhead that's required to manage this with staff traveling and all of these sort of things making amendments to these lists is how mistakes can easily be made by either adding or removing users all the time.

So, it's actually easier to use the compliant device requirement because the device follows you can set your enrollment number lower and then just as users change their devices, they just need to add an extra device and get that user enrolled. So, that's a better method of actually protecting devices than the old geoblocking method. But we wanted to cover off that today to highlight how that can be configured and set up the right way without actually causing a hole in your security layer.

But compliant devices could be a good one to explore in the future.

All right, policy config number two, macro blocking. If you configure macros within Intune and you're wanting to block them, stop them, enforce the restriction upon them to be compliant with frameworks like Essential 8, SMB 101, NIST, ISO, etc., it's actually impossible to achieve with business premium because Microsoft doesn't make it available to the office that's included. So, Office in Business Premium is Microsoft 365 apps for business. And unfortunately, Microsoft doesn't support any policies being applied to that version of Office.

If you do want to have that, you need to have 365 apps for enterprise. So, you can get that as an add-on to your business premium SKU. Unfortunately, it does require that extra payment. So, you could move to an E3 or an E5 level license or you can do the business premium plus the add-on. Micros, it is it's been a pretty how to put it a open secret for many for a number of years that Microsoft didn't support this.

But there was never any documentation anywhere. Microsoft employees would talk about it, but it wasn't any documentation that actually highlighted it. Thankfully recently Microsoft has updated their documentation to include a little disclaimer there that states that this is not supported. So it's actually good that's available now but it's one that we just learned over from experience as we tried to block it especially for here being Australianbased we had the essential 8 macros forms a very important part of that framework.

So we would be blocking it and then finding on intune that it didn't actually work. So it's not so much a policy misconfiguration as it's a bit of a license misconfiguration. So that's one to keep an eye out on as well because even though we can push the policies, we can create the policy to protect office in a business premium tenant, it won't apply and that it won't it won't take any effect. Office still by defaults default allows for macros to be blocked.

So that's on by default in even apps for business, but the user can easily change it. They can turn it on. They can do whatever they want to do it and it's not enforced. If you try to do things like registry scripts, registry hacks, scripts, etc., it'll apply for a short time and then it'll just revert. So unfortunately if you want to be compliant with that particular aspect of a framework you would need to have either the apps for enterprise add-on or you need an E3 or an E5 license SKU.

Policy number three is actually not really a policy on its own but a collection of policies and we're going to be looking at the Defender for Office 365 suite. Now when Microsoft when you first open your tenant and Microsoft has done its job and provisioned that tenant you're left with a set of default policies. Now these are configured in a fairly loose configuration but they are effectively a default policy set and a lot of people think that you can actually just keep them as they are and they're offering the protection that you need in your environment but actually they're not.

So let's dive in and have a little bit of a look at what's in the default policy set. So here we have our defender security policy portal. Let's jump in and have a look at anti-phishing. So we can see we've got two different policies here. We've got the default policy and we also have a policy that I've created. So if I click on this particular policy, we can see here that our phishing threshold is one standard user impersonation protection is off.

Domain is protection is off. Trust trusted impersonated senator domains is off. Mailbox intelligence is off and a number of the controls contact safety tips etc. All of these are off in a default state. Now none of these controls this policy in its current state would not meet secure score. It wouldn't pass the secure score protection requirements. So if I now look at this policy which I've built to be part of secure score, we can actually start to see here where things differ.

So we can see that our phishing threshold is more aggressive. We can see that domain impersonation is on. User impersonation is on. These trusted impersonated senders and domain is off cuz I don't have anyone that I want to trust. Mailbox intelligence is on. Spoofing's on, etc. We can see that the controls are more on as well. We've got certain tips and tricks on. We've got default full access, reject the message instead of quarantining. So, we can actually modify and create a new policy.

Now, why would you want to have why couldn't you just modify the default policy? And yes, you could, but using the default is never it's never really the best thing to do.

You're much better off to actually create your own policy and modify it so that you can protect your devices or in this case your mailboxes in a much better way. It's also important to note that when using inforcer default policies can't be standardized. Microsoft does not allow for them to be modified, deleted, removed or added by inforcer. So they actually need you need to have custom policies in place. And then when you have a custom policy in place, that's when you can standardize, deploy, modify as needed.

So, that's one thing to keep in mind as well. Our fourth policy set is compliance policies. So, again, a bit of a group of policies, but they fall into a couple of different areas. So, they're not only just compliance for devices, you can also use them for compliance for Intune, which we mentioned earlier in our geoblocking one. But a lot of people don't know how much you can or what you should configure in a compliance policy.

So let's dive in and have a look. So here we have our Intune portal. We're going to create a compliance policy. So we're going to create one for Windows 10 and later. We're going to use a Windows 10/1 compliance policy. We're going to create that. We're going to use call it Windows 11 compliance because obviously Windows 10 is end of life. So there's a number of different options as you can see here if we open these up.

There's lots you can choose from to create a compliance policy. Now some people just do it as simple as a you know minimum OS version. You might do 10.0.26200 and that's for Windows 11 25H2. And that might be all that you set as a compliance requirement, but really you should be doing more than this because we want to have the best chance of making sure that our devices are compliant. So requiring secure boot is a minimum.

We want to have BitLocker. That should also be a minimum requirement. We want to make sure that these sort of things are protected. What other things do we want to make sure? Defender. If you're using Defender Antivirus, then you should absolutely require it. Do we require a minimum version? Not necessarily. Requiring that it's up to date and real-time protection is turned on. These are all important things. If you're using Defender Antivirus, if you're using a third party, then you probably wouldn't turn this sort of requirement on.

Obviously, we're not using anything for Linux, but you can even set a minimum standard. So we would want the require the device to be either at or under this machine risk score. So we would say medium. Now this is actually quite a comprehensive policy set. Passwords probably not so important. Configuration manager compliance. This is not an on-remise machine. So I think this is a pretty good overall control of what we want to have in place.

We've got BitLocker Secure Boot Windows 11 25H2. So, the latest build, not necessarily the latest update, but the latest base build. We've then got a Defender anti-malware requirements as we can see here, and a medium score. We then hit next. Actions for non-compliance. We can send an email to the user. So, we can This is You need to have a template set up. I don't have any set up in this tenant but you can set up a action for a non-compliance to send an email scope tags if you want to assignments you would say ne probably most likely all devices hit next you hit create this compliance policy will now be used to filter on devices and mark devices that are not compliant with these set of controls non-compliant.

But how do we use this? So, how does this work? If we just create this policy in and of itself, what is it doing? It might send a notification. Other than that, the policy doesn't really do much until you tie it in with conditional access. So, if we go into here, devices, and we go to conditional access, this is where we can create a new policy. So, I'm going to call this device compliance. So what do we want this to apply to?

All users. Resources. We would want this again to target all resources. Not too worried about the network at this state, but conditions. We want to have a condition set. Device platforms. We want to include and configure. We want to select Windows because this is only going to apply to Windows devices. We hit done. Access controls. We're going to say require MFA, but we're also going to require the device to be marked as compliant. If the device is not marked as compliant in the compliance policy that we have, then this user will never be able to log into this tenant.

So, this requires the device that the user has to be enrolled in Intune. There is a grace period if it's just a brand new enrollment, but it requires that device to be enrolled into Intune and compliant for them to be able to access resources. This means that if we create this policy, then users will not be able to use any device to log in. They can't use their personal desktop. They wouldn't even be able to use their personal phone.

So, we can set up this for Windows. We can set up a separate one for iOS and iPad OS and Android using MAM policies. We can require all of these specific items to be able to allow them to log in. So, we can just hit select. Make sure down here that you've got require all the selected controls selected, not just requiring one. Otherwise, one, it'll either go yes, this one, or this one. So, you want all to form that policy.

You can select on because I don't have a device in this tenant at the moment. I'm going to exclude myself. But you can create this policy. And now that's how we can get conditional access working with the device compliance policy that we've created. So now Windows 11 compliance is more than just making sure that devices have a green tick or a red cross. It's now making sure that they are compliant and then authenticating the user into the organization.

This is how compliance policies are meant to be used. This is their recommendation by Microsoft. So, it's a good security measure to have in place. So, that's how you configure compliance policies in conjunction with conditional access. The good news being that inforcer can obviously standardize these policies because a compliance policy is targeted to all devices. You can deploy that policy using inforcer across all of your tenants. You can also you can deploy that conditional access policy as well across all of your tenants and have them all link up together.

So that's why with the policy with the geoblocking with this you can create a uniform security posture and have your tenants protected.

Our last but not least policy set that we're going to be looking at is well not actually a policy. It's more of a setting. We're going to be looking at SharePoint and OneDrive sharing settings. Now, that's an interesting one, you might think, because basically there's a few different options there, but Microsoft by default has it quite unsecured in the way that it defaults. So, normally it will default to the most unsecured state, which is not ideal.

So, as an MSP or as the manager of the site that you're managing, you actually want to make sure that you bring that security setting into what is known as the best practice. So, we're going to now dive in and have a look at these settings. All right. So, let's have a look at this setting. So, what we're going to do is open policies. We're going to go to sharing. Now, we can see that we have two different options.

One for share SharePoint one for one drive and what we can actually see here is that it is a slider. So the most permissive action is for anyone. So anyone who uses these files or anyone who creates a file wants to share it they can just share a link and it means that anybody can access it which is probably not the best but that is the default function within SharePoint. The next one is for new and existing guests.

So guests must sign in or provide a verification code. Existing guests. So these are existing guests within your organization that are B2B invited. And then the least permissive is only people in your organization. So basically what you would normally set as your default is your new and existing guests. So guests must sign in or provide a verification code. Or you could even have it as guests already in your organization's directory. So, you also want to set some of the more external sharing settings as well.

So, you want you may want to only allow users in specific security groups. Again, probably not a good default action when you're setting this up. You want to think like the default action. So, we might say that guest access will expire after 60 days. That's probably a fairly safe one. The other one is files and folder links. Do you want to specify only people in your organization or you can say specific people? So you can specify who gets to what the default is when that sharing option is selected.

I would spe I'd go with the specific people function cuz if you are wanting to share externally, it's just handy to enter that email address there and choose the permission that's selected by default. I would choose view by default. That way we're always going with least permission first by act by default. Then by accident if someone changes it or sends it to the wrong person they won't have edit access. They would only have view.

So it just protects the organization in a way. We can then hit save on this and that permission is now set. The important thing to remember about this is the tenantwide setting. So this setting applies to the whole tenant both for what sharepoint and one drive but for each individual site. If you have certain sites that require more confidential or stricter controls you can set the sharing level on each individual site as well. But you can never set it higher than what the default sharing level is for the tenant.

The site always has to be that level or lower. And so great to make it that more secure set when you're dealing with documentation or you know PII information. If you're using Purview with classifications, then having those sharing settings set a bit stricter is always a good idea. Well, that's our top five most common policy misconfigurations.

If you have any questions on anything you've seen, please feel free to reach out through the inforcer platform or through your account manager. We would be more than happy to answer any questions that you guys might have. Thank you very much for watching and I hope this has been helpful.