What are the limitations with Microsoft Defender for Business Standalone?Alex Fields
Most of my readers will already be familiar with Microsoft Defender for Business (MDB), which is included with Microsoft 365 Business Premium. And a majority of those will be deploying MDB as one part of a broader security solution which includes other services within the Business Premium bundle. But a subset of folks have asked about the “Standalone” version of Microsoft Defender for Business.
Yes, it is true, there is indeed a standalone version (USD $3/user/month), which was announced last month. The use case? Consider a scenario where the customer is using a different productivity platform such as Google Workspace, or they haven’t yet made the transition to other Microsoft 365 services. Using the standalone SKU, you could theoretically onboard devices and start providing protection, ahead of deploying other services, and with far less upfront licensing commitment.
Some of the MDB-related services will function much in the same way as you are used to with the full product, however, you should be aware that certain services would only be available with an Intune license (Microsoft Endpoint Manager). For example, the “Automatic onboarding” option during the first-run wizard experience requires devices to be enrolled with Endpoint Manager already. As well, certain functionality in the Microsoft 365 Lighthouse product may rely on the presence of the Intune licenses in order to work. At the same time, some functionality within Endpoint Manager will still be available, even without the “complete” license set. In fact, just enough of the MEM product is activated to make basic policy deployment possible for the “standalone” scenario. Clear as mud, right?
Let’s take a look at an example where I have onboarded a new “standalone” device into a tenant where I also happen to have some “fully licensed” Microsoft 365 Business Premium users.
In the first place, I need to actually purchase and assign the standalone license product to the correct users. For this purpose, I created a new user named “Mark Twain” in my tenant, and assigned the MDB standalone product.
Next, we want to check on a couple of settings related to this scenario. Begin by navigating to Settings > Endpoints from the Microsoft 365 Defender Security Center, and click on Enforcement scope.
You will want to turn On the setting called Use MDE to enforce security configuration settings from MEM and select the OS choices below (and yes: Windows Server support is coming soon to the Business product).
Then, check Microsoft Endpoint Manager by navigating to Endpoint Security > Microsoft Defender for Endpoint.
Be sure that the option Allow Microsoft Defender for Endpoint to enforce Endpoint Security Configurations is switched to On, and Save settings if necessary.
With those settings in place, let’s onboard a device named “Workstation10” using the local script method (you could also use GPO or other methods, but just note that you cannot use MEM to onboard the device in this scenario since the requisite license is not available and the device is not enrolled into the service).
Okay, now that the script has been run, we expect the device to show up in our inventory. Let’s take a look. We should be able to see it from the Defender Security Center:
Yep. And as well, from Endpoint Manager:
You will notice in both cases that there is a column called Managed by which will indicate whether the device is being managed by Intune or MDE (which is the Enterprise term for MDB). Those devices which are managed by MDE are the so-called “standalone” devices. You will also notice that not all the data are available for standalone devices, because they are not enrolled with Intune (therefore things like Compliance cannot be evaluated).
Finally, you will notice that we can still take all the same actions against standalone devices, such as Isolate device, Restrict app execution, Run antivirus scan, Collect investigation package, Initiate Live Response Session, etc.
I will also add that in addition to the device inventory and device actions, the Vulnerability management functionality that we have via the Microsoft 365 Defender Security Center is still available and visible for standalone devices.
Let’s say you want to assign policies to your standalone devices. We can either use the Microsoft 365 Defender Security Center (you will find it under Configuration management > Device configuration), or we can use MEM. Since the purpose of this blog is to highlight the boundaries and limitations of MEM with regard to these standalone devices, let’s examine the option to assign policies from Endpoint Manager.
Start by creating a Dynamic device-based security group. Go to Groups, and create a new group. Name it something descriptive like “MDB Standalone Devices” or similar. Then, use the following expression to capture the devices managed by MDE:
- (device.systemLabels -contains “MDEJoined”) or (device.systemLabels -contains “MDEManaged”)
(Note: I have also observed that using the “All devices” option works as well when making assignments, but it can be useful to have a group that can identify for you which devices are managed by MDE/MDB, and not yet onboarded to MEM.)
Next we can create a policy and assign it to our new security group. The following policy types are supported currently:
- Firewall rules
- Endpoint Detection & Response
I suspect we will see additional policy types supported in the future (e.g., Attack Surface Reduction), but at the time of this writing, the above is all that is included.
I created a simple Antivirus policy. Again this could also be achieved from the Microsoft 365 Defender Security Center, but I have elected to manage my policies in MEM instead for the purposes of demonstration.
Now, if I try to create and assign a policy that isn’t yet supported, such as Attack Surface Reduction rules, what happens?
As of now, we see that it just remains in a perpetual “Pending” state. I hope to see support for more policies soon, though. Fingers crossed.
So can the standalone product do everything that the MDB product can when bundled with a more complete subscription set such as Business Premium? No.
Certain policies and functionality would require the “full” license bundle including Azure AD Premium and Intune/MEM. For example, if you want to unlock features like the Conditional Access integration, and measure device Compliance, or if you want to view and managing additional device attributes. But it appears that Microsoft is attempting to open “just enough” functionality here to support a sort of “lite” management scenario of the MDE/MDB product via MEM, even if you don’t have an Intune license. (It is always best of course if you can move into the full experience with the complete license bundle).
In my opinion, we should at least get support for Attack Surface Reduction rules added both to the MEM for standalone scenario, as well as receive a new way to deploy these policies from the Defender portal (like we have with Antivirus and Firewall policies today). I do not know if/when this will happen, but my hope is that we will see it yet this year.
And that is basically the whole story in a nutshell, as of right now. Hopefully that cleared up some of the more confusing points. If we get additional functionality in the future, I will be sure to report back.
[…] What are the limitations with Microsoft Defender for Business Standalone? Defender for Business is also available in a stand-alone version, but it has some limitations that you should be aware of. […]
What is current status (November 2022) with Attack Surface Reduction rules for standalone DfB? Still Pending status?
ASR rules are available for standalone, but all controls are still via Intune (you get enough licensing to allow you to configure policies via Intune, even though you don’t have full Intune license).
My experience is that ASR rules (for DfB standalone or server add-on) can not be (so far?) controlled via (light) Intune, so it possible only via GPO (https://www.itprotoday.com/data-security-encryption-and-blockchain/how-use-group-policy-windows-attack-surface-reduction) or PowerShell (https://techcommunity.microsoft.com/t5/microsoft-defender-for-endpoint/demystifying-attack-surface-reduction-rules-part-3/ba-p/1360968) with fancy GUI tool (https://github.com/hemaurer/MDATP_PoSh_Scripts/tree/master/ASR%20GUI).
M365 Business Premium (with full Intune) works fine…
Hm, I would need to stand up another tenant to test this out again, but as long as you have the connector between Intune and Defender set up, my understanding is that with regard to standalone licensed folks, you should be able to get devices onboarded and show up in Intune but it will show them as specifically managed by MDE, and you (theoretically) can still apply endpoint security policies including ASR. If not working, maybe get support ticket to find out why?
We just evaluating this product and after two weeks we gave up, even asked the MS support, and we got no response in two weeks. We are using the 25 users defender for business trial.
The problem is that the test devices are successfully onboarded (the security center nicely collects and display data from the devices), but all our device “Managed by” status is “unknown’. The devices are never shows up in the endpoint manager! This means the policies are not applied to the devices. So we have only one way communication between the devices and the security center. Obviously we have no intune licenses!
Checking tutorials all over the web we always find talking about intune… However if intune (per user price is more than double of the defender for business price!) is really required for defender for business, this means that this product suddenly becomes the most expensive antivirus product in earth :(
It is not antivirus, but EDR, TVM, ASR, etc. as well. But you do NOT require Intune. They “open” enough Intune functionality to allow you to manage the MDB policies with just the MDB licenses. If you are using the Standalone version (as opposed to Business Premium which is the recommended configuration), there may be additional set up steps. For example, you have to explicitly turn on connectors between Intune portal and Defender. Once devices are onboarded, policies can be managed from Defender portal, and then you can check/confirm whether policies are being received/applied by the endpoint. As for support–yes, I agree they are notoriously slow (for all M365 support, not just in particular to this product). Need to build your own skill/muscles in this area or hire MSP who knows their stuff when it comes to the full breadth/depth of the Microsoft ecosystem.
Thanks for the reply Alex! Our main license is “MS 365 Business Standard”, and my goal was to add defender for business as an extra subscription, and my attempt is failed. The connector between defender and MEM is set (using ms learn sites and your tutorial). In MEM when I check the device list I see this: “You’re using Office 365 for device management. Click here to add Intune”. Also in MEM I can find our office 365 users, if I select a user I can even see the devices for the user (MDM status is “none”) However all other devices list (home/devices/windows devices) are empty. In the defender portal I see the devices, but managed by state is “unknown”. I checked the policy distribution, changed the default policy in defender, but the policy is not applied to clients, also tried to start a manual scan from the portal, but not works. What is strange that the portal correctly shows for a given device the incidenst and alerts (test virus catch, outdated softwares etc.). Maybe defender for business is not compatible with ms 365 business standard, now I’m still waiting for ms support (got no response in 14 days)
It is absolutely compatible. The standalone version was made for folks just like you who have something other than Business premium. It is still recommended to have the entire Business Premium suite of course, as it is dollar for dollar the best value by far. So why not just upgrade? Get all the other goodness too: shared computer activation, DLP, encryption, sensitivity labels, Defender for Office 365, archive mailboxes, retention policies, etc. But, Standard is for sure compatible with the standalone version of MDB. It is okay for your MDM status to be “none” since you are not using Intune as your MDM, so that is fine. If the MDM authority is still Office 365, that may not be correct depending on your situation. However, if you are using Office 365 MDM features then you would have to get rid of that before changing the MDM authority over to Intune (and I assume at that point you want at least one license to access Intune features).
Anyway, as for your issue, I am having trouble understanding what the issue is… From what I read here, it is working. For example, it will correctly apply policies to the devices, if it didn’t then the devices would not report in when there is an incident. And the devices are reporting their data to the portal, right? It catches the incidents on the devices, etc. So that means it is working. I don’t think the devices are supposed to show up in the Intune portal as managed devices under Devices > Windows, since they are not actually enrolled with Intune at all. You can still see the devices in other contexts such as Defender, and they appear to report in their data. So what’s the problem? Is it just that you expect to see and manage them via the Intune portal? That is only possible if you have the complete license. So it is certainly better if you do own Business Premium, but the basic functionality is still present in Standalone.
1. Run onboarding script or whatever to onboard the devices and deploy policies
2. Verify the devices are reporting into the portal
3. Verify it catches the test incidents/alerts
And you’re done.
With the Intune license you get much richer data and controls over the devices when they are enrolled. It’s not really part of Defender but it enriches the experience. Of course, you don’t get that for free.
Alex thanks for your effort to help me! In short I don’t want use the “Endpoint manager admin center” at all, I try to work with “Microsoft 365 Defender” portal only. My only issue that policies (including the default ones) are not applied to the onboarded devices. For example if I navigate in the defender portal to endpoints/configuration management/device configuration and change the “NGP Windows default policy” the changes won’t apply to devices. If I try to create a custom “next-generation protection” policy I cannot do it, because during the policy creation I need to provide the targeted devices, and that fails: “you don’t have any devices yet”. In Assets/Devices/Device Inventory I see my onboarded windows devices, but when I check the “NGP Windows deafult policy” both the assigned and the applied devices report “0 devices”. It seems that device configuration part (the policies) not recognizes the onboarded devices, but other parts of the defender portal works without issue.
Okay, I would suggest then that you try to get just one device working. Make sure all third-party endpoint security solutions are removed from the endpoint, and re-run the Defender onboarding script on that device to see if it starts reporting in and taking policy. Check out both sides (Intune and Defender) to ensure integration is enabled and that the “Enforcement scope” option is enabled as well. You can also try connecting the device to a network that you know has no egress filtering /open outbound just in case there is a firewall getting in the way… but that is less likely to be the problem. More often, third-party endpoint security remnants cause interference with Defender. And if it’s none of those things, then you have to pester support to look into your tenant further.
I think I found the problem. We are using sbs 2016, the cloud service integration is not configured on this server. Devices are connected to the local sbs domain, in the defender portal these devices managed by status suddenly changed to “MDE”, but with errors. Some device reports “DNS” error (it seems no body knows on the web what is DNS error for MDE), some device reports “aad connect misconfiguration” etc. What I’ve learnt that local domain joined devices must have hybrid azure active directory registration(?) But this is impossible with sbs 2016, because azure ad connector is not supported(?) Also run dsregtool, and it reported that hybrid azure ad join failed. Following your tip I decided to test a standalone brand new device, so I made a non domain joined win11 vm, onboarded it, and it works, that device is listed in the endpoint portal! The big question for me that it is possible at all to correctly MDE register a local domain joined device, if the domain controller is an sbs 2016 server? If not we cannot use this product, or we need to migrate to a different server product, which would be a little bit overkill.
I do not know if this is the reason your machines are not showing as MDE managed in the portal… However, I will say that for most SMB’s, I recommend ditching all server related products and going to 100% SaaS / cloud apps, and joining your computers directly to Azure AD rather than a legacy domain controller. It is very rare that an on-prem server is actually required anymore. Hybrid Join is another option but not necessary per se. I am not aware of a technical reason you could not run the onboarding script on any computer, joined to a domain or not. I assume that there may be a limitation with Windows Home edition but any up-to-date Pro version I would expect to work. If there is some requirement for domain-joined computers to be Hybrid Joined before onboarding to MDE I have never seen that printed anywhere…if you find out this is indeed a pre-requisite I would love to hear confirmation and cite a source, too, if possible. But I would encourage anyone who is still tied to a legacy server to get off it as soon as possible, as there are too many drawbacks in terms of security and long-term supportability. In this case you would definately want the Business Premium subscription rather than Standard licenses, because running only Standard is equivalent to having a “workgroup” in the cloud. You want a real domain with full management capabilities, which is the Business Premium subscription, and Azure AD join the computers.
I found the official ms doc “Troubleshoot onboarding issues related to Security Management for Microsoft Defender for Endpoint” (https://learn.microsoft.com/en-us/microsoft-365/security/defender-endpoint/troubleshoot-security-config-mgt?view=o365-worldwide), where I read about the hybrid join. I think this information is useful for other potential defender business users using legacy domain controllers. In the referred doc in the pink table you can see what should happen during the onboarding operation. My failed devices’ initial state are “Not AADJ or Hybrid Azure Active Directory Join (HAADJ) + Domain joined”, and this should change to “Device is HAADJ’d”. This is impossible(?) with sbs 2016, because I’ve not yet found any way to configure hybrid azure active directory for this type of server product. I checked the affected devices with “dsregcmd /status” and the devices are not azure joined! However when I onboarded one test device with simple workgroup, that device works perfectly, and dsregcmd reports device is azure ad joined. (I already tried on the local domain joined devices to connect a work/school account manually, but obviously it not works, not enough.)