How to manage Windows devices without Microsoft Entra ID accounts

Introduction

In our blog series, we have been going through the pillars that make up an effective Cybersecurity strategy (check out the original article if you haven’t already!). The four pillars — Identity Solutions, Device Management, Device Security, and SAAS application security — are all important individually, and tools should be selected in accordance to the requirements of your organization. However, it is equally important to consider the interaction of each of these pillars, and how the interplay can contribute to your overall security strategy. This enhances the robustness of your security strategy, and allows you to run it most effectively - both in terms of cost savings and management requirements (think reducing duplicative activities, and manual complex requirements). However, it can be challenging to apply this principle to reality.

‍

Take, for instance, the scenario of managing devices in the Microsoft ecosystem with an identity solution that isn’t Microsoft. When a Windows device is not joined to Entra (Microsoft’s identity solution tool), we see a series of challenges arise in managing these accounts and ensuring that the security measures are effectively enacted across the security pillars of device management and identity solutions. This article provides an overview of how to handle this situation, laying out some existing solutions, and equipping you with the right questions to ask to make sure this is not an issue that is being overlooked within your organization.

‍

Getting the Lay of the Land: How to think about the interaction between your Identity Solution and your Device Management Solution

When you are looking at how to secure your organization, there are different components that need to be taken into consideration. As discussed above, the interplay of different security pillars is just as important as the individual functionality of these pillars. So lets start by taking a look at the different components that you should be securing within your business:

1. The endpoints, or devices, think the laptops, mobile phones, or tablets that are being used. These are enrolled in MDMs (mobile device managers) and in EDR (endpoint detection & response) strategies to ensure protection.
2. The accounts, think the individual google accounts, AWS login, etc. Organizations also use a combination of cloud services and applications from different providers, each of which create accounts associated with users. Here, identity solutions are deployed to ensure authentication and management of accounts.
3. The user, which is the holistic ‘person’ who is using accounts and endpoints to do their work. A user will usually have multiple accounts, and could also have multiple devices that they use. Whilst this can be an extra layer of complexity, effective IdPs map out accounts to their users.
4. Groups, refers to the way we can ‘group’ users into buckets depending on certain criteria. This enables permissions and accesses. This is an additional layer of categorization, but is very helpful in on-going management, and particularly relevant when considering the problem at hand of ‘account syncing’ windows users to Entra.

While each of these components do map to specific primary security tools (for instance, users and accounts to Identity Solutions, and endpoints to Device Management), there is also overlap across them all, and being able to integrate them is a vital part of an effective (and efficient!) security strategy. Take for example, device and identity mapping, which is the process by which the specific devices in use are mapped to the accounts and user using them. A good security strategy can effectively ingrate Identity Provider and Device Manager for tasks like user account recovery, inventory tracking, and zero-touch configuration. If the two were separate, it would be challenging to execute on these important actions.

As an organization builds out their security toolkit across the key pillars, certain complications can arise when trying to effectively integration between different tool. One of the most challenging, and the topic we’re discussing today, is managing Windows devices when your identity solution lies outside of the Microsoft ecosystem.

‍

What are the challenges if a Windows device is not enrolled in Microsoft Entra or not managed by Intune?

An organization may not choose Microsoft Entra as their IdP for a variety of reasons. The functionality or cost of other IdPs, such  as Okta or Google Workspace, may lead an organization to choose those over Entra. Additionally, if they are already set up with a different tool they may be reluctant to doing a migration, due to the high thrash and burden to execute.

However, there are some unintended impacts that arise if you are choosing to manage some elements outside of the Microsoft Ecosystem. Opting to use a platform like JumpCloud or Kaseya, and operate outside of the Microsoft Ecosystem means you are not benefitting from the holistic powerhouse of Windows Device management, and devices do not have access to some features of the security toolkit, resulting in a worse user experience and increased risk exposure for these devices —  for example, user being unable to do a password reset, or use Windows Autopilot, (which is the Windows equivalent of “zero-touch” deployment). Additionally, the configuration of Windows devices without Entra and Intune is harder to manage (resulting in a heavier burden on the security team).

‍

What are the solutions?

This is a general challenge that faces organizations and security professionals, and in short there isn’t a great answer that solves this problem in a simple, clean way. If you're going to be using Windows devices without Entra as your primary IdP, you want to still be able to effectively manage those devices and allow a customer using a different primary IdP to have users enroll Windows devices without having to manage a second AzureAD-only account. There’s a couple ways to think about this:

1. Federating: this speaks to the process of setting up Google Workspace to federate identities to Entra ID to allow a customer using Google Workspace as their primary IDP to have users enroll Windows devices in Intune without managing an entirely separate Entra ID-only account. This means that Google is the authoritative identity source and Entra delegates authentication to Google using the SAML protocol. The user experience goes like this: when users want to log into a MIcrosoft service, they are redirected to the Google authentication flow and then directed back to wherever they were logging in. The downside of this, is that it is a complex and manual process, and not officially supported by Microsoft or Google for the purposes of device management. Secondarily, even with this solution in place, first-class features will not be available with this setup, for instance, by keeping local accounts in place, activities like recovering locked-out users is much more complicated to do.
2. Using Google Device Management and Google Credential Provider for Windows (if you’re using Google Workspace IdP): however, similarly to above issues with federation, this can be difficult to automate and results in a heavy management burden.
3. Maintain separate accounts for windows users only: one route to take is to choose to maintain separate accounts for Windows users only. This however, does not address the overall challenges of the issue, and is costly and time consuming to manage separate accounts for those users.
4. Zip’s ‘Account Syncing’ solution: we’ve recently built a feature that offers an alternative solution to this problem, which effectively ‘account syncs’ across different IdPs to have the same outcome. This is done by creating a group in an organization’s IdP with all windows users. In the backend, Entra accounts are created on behalf of those users. Significantly, this enables the device to benefit from the full host of features and functionality of Microsoft Entra and Intune. Additionally, there is the added benefit here that, relative to the options above, this offers the lightest management burden.

‍

So, how should you approach this if it applies to your organization?

1. The first step in addressing any problem is understanding your current situation, identifying if this is an issue that applies to your organization and devices, and mapping out the risk exposure of the devices if this is the case.
2. Assess your options based on the technical knowledge of your security team / who manages your security: it’s important to recognize the level of expertise of your security team to determine which course of action is the most realistic and efficient. Given the complexity of this, outsourcing the management of this may be the smartest solution.
3. If you’re already working with a provider (such as an MSP, or a ‘co-management’ partner like Zip), if they haven’t addressed this with you directly, ask them to explain their approach.

‍

Interested in learning more on this topic? Check out our latest article: What cybersecurity tools do you need to build and effective security strategy? and our other articles here.

To stay up to date on Company news, follow us on LinkedIn.

‍