Blog Post

Microsoft Defender for Endpoint Blog
5 MIN READ

Disconnected environments, proxies and Microsoft Defender for Endpoint

BrianBaldock's avatar
BrianBaldock
Icon for Microsoft rankMicrosoft
Jan 06, 2023

Microsoft Defender for Endpoint is a multi-platform cloud-based endpoint protection product that comprises multiple capabilities and features. There are many moving parts that make up Defender for Endpoint, and many of these parts require network connectivity. Disconnected environments can pose a challenge to deploying and configuring Defender for Endpoint. When proxies are added into the mix, interesting things can happen.  This article is a part of a series of articles discussing Defender for Endpoint and disconnected environments. The other articles can be found here and here.

 

Recipe for a successful deployment 

To deploy Defender for Endpoint in a disconnected environment, you’ll need to keep in mind the following items: 

 

  1. Involve the correct parties. You’ll need representatives from your networking team, security team and infrastructure teams as well as leadership decision making power to implement changes in the disconnected environment. 
  2. Choose the appropriate Defender for Endpoint proxy configuration for your environment.  
    • WinHTTP 
      • Due to the system level nature of the WinHTTP configuration no additional configuration should be required. All outbound network traffic will continue through the proxy as expected if the proxy accepts unauthenticated network traffic. 
    • WinINET 
      • If your devices use user based WinINET there are some additional items to consider. This configuration is not ideal as Defender for Endpoint should always communicate with the URLs outlined here, regardless of whether a user is logged in or not. WinINET configuration often requires an authenticated proxy, which is not compatible with Defender for Endpoint in a proxy scenario. 
    • Static Proxy Configuration 
  3. Make sure that you have reviewed the list of URLs required for MDE to function. This URL list must be added to your allow list in your proxy and should not have TLS inspection on the network traffic. Check the following URL for more information and steps: Configure your network environment to ensure connectivity with Defender for Endpoint service - Microsoft Defender for Endpoint | Microsoft Learn. Remember, Microsoft does certificate pinning to prevent man-in-the-middle attacks. If TLS inspection is enabled, this will break the connectivity between the endpoint and the cloud service.  
  4. For the URLs, the proxy must accept unauthenticated traffic. The Defender for Endpoint services run as LocalSystem and LocalService. If a user is logged in, Defender for Endpoint traffic will be authenticated with the user (in the case of WinINET). 
  5. Simplify the communications between the endpoint and the proxy server. Avoid double-NAT and multiple hops. Testing connectivity can be accomplished in step 6. 
  6. Use the Defender for Endpoint client analyzer. This will help diagnose connectivity issues. For more information, see Download the Microsoft Defender for Endpoint client analyzer | Microsoft Learn 

 

Scenarios: Defender for Endpoint behind proxies 

Here are some scenarios to consider when deploying Defender for Endpoint in a disconnected environment. These scenarios will help you prepare and understand how Defender for Endpoint will behave depending on the proxy configuration used in your environment. 

 

Workstation with Defender for Endpoint and a logged in user 

 

Authenticated Proxy 

 

Unauthenticated Proxy 

 

Workstation with Defender for Endpoint and no logged in user 

 

Authenticated Proxy 

  • Defender for Endpoint will not function as expected because: 
    • There is no authentication context provided to the proxy. Once a user logs in, the local cache will update the URL endpoints, however this may cause delays in awareness of potential issues. 
    • Live Response, Network Scanner, cloud-delivered protection, Endpoint Detection and Response data, Command and Control functionalities, Automated Investigation and Response will not function as expected. 
    • Security/Product Updates won’t work unless there is an offline update solution available, such as WSUS. 
    • Microsoft Defender Antivirus will continue to work as expected, though it will only report centrally once network connection is re-established.  
    • Because an authenticated proxy requires user authentication, many of the connected services in Defender for Endpoint won't work as expected until the user on a device is able to authenticate to the proxy. 

 

Unauthenticated Proxy 

 

Server with Defender for Endpoint 

 

Authenticated Proxy 

  • Defender for Endpoint will not function as expected because: 
    • There is no authentication context provided to the proxy. Once a user logs in, the local cache will update the URL endpoints, however this may cause delays in the timeline updating with endpoint detection and response information in the security.microsoft.com portal. It will also prevent Live Response sessions from initializing and have a potentially negative impact on the Network Scanner, cloud-delivered protection, command and control, auto-investigation and response, and product update features of the product. 
    • This scenario will cause an inconsistent Defender for Endpoint onboarding experience: 
      • The server being onboarded may never appear as onboarded in the portal. 
      • The server may be onboarded because:  
        • A WinINET proxy configuration was applied to the user performing the onboarding. 
        • This often occurs during proof-of-concept testing as user profile will be providing the authentication context to the proxy. This often leads to confusion as the proof-of-concept deployment is successful but deployment to production is not. 
        • The server will lose access to the URLs once the user context is no longer applied to perform proxy authentication. 

 

Unauthenticated Proxy 

  • Defender for Endpoint will work as expected but may have some issues. It should be noted that these issues are typical of disconnected environments: 
    • Multiple gateways between subnets or double-NAT. The more complex a networking environment is the more difficult it will be to diagnose connectivity issues. Keep it simple and provide the most direct path to the list of URLs as possible. 
    • Proxies blocking external access from those disconnected environments. You will need to add the URLs to your proxy allow list. 
    • TLS inspection breaking the connection – don’t do this for the URLs in the list. 
    • Disconnected environment not receiving Windows Updates correctly. Defender for Endpoint is a cloud endpoint protection solution, and your endpoints need to be up to date to work properly. The disconnected environment should have an update strategy in place. 
    • Check step 6 of the “Recipe for a successful deployment,” this step calls out additional update configurations required in disconnected environments. 

 

These scenarios should provide you an overview of the different configurations required when you are deploying Microsoft Defender for Endpoint in a disconnected environment using a proxy to access the internet. 

 

References 

Updated Jul 09, 2024
Version 5.0

20 Comments

  • Hi M4R10s,

     

    Your statement: "Can we route MDE traffic to other host and this proxy host will be communicating with MDE cloud endpoint?" Maybe I'm misunderstanding but it appears like your describing a standard proxy server scenario which is supported by Defender for Endpoint. The endpoint in the disconnected segment routes traffic to a proxy server and that server routes the traffic to the cloud endpoint. Many customers with regulated environments use MDE in this way. 

  • Hi autopoiesis

    No, I can't recommend a specific proxy server or service for Defender for Endpoint. Any proxy that adheres to the recipe will work. Let's examine your requirements and their relationship with Defender for Endpoint:

    1. No TLS inspection: This is necessary for security, but may be hard to argue with security departments. Microsoft uses certificate pinning to prevent man-in-the-middle attacks, and we can't determine if a tampered connection was legitimate, so we drop it.
    2. Authenticated/unauthenticated connections: Most proxy servers support authenticated or unauthenticated traffic. As Defender for Endpoint services run at the SYSTEM level, authentication with a user account is not possible. A proxy server with certificate validation would confirm if the source is legitimate. This is not a necessity for Defender for Endpoint, it's more of a self-imposed standard.
    3. Dynamic URL Lists, constantly-changing geo-specific IPs: The challenge is communication with the right URLs without TLS inspection. Ideally, endpoints should speak to a specific proxy server using static proxy configuration (GPO/Registry settings). This proxy server should only communicate with the URL list outlined in the mde-urls-commercial.xlsxSupporting dynamic URL lists (including wildcard URLs) is critical, not mandatory but important and will make the admins life easier. 

    You want a proxy server that supports wildcard URLs, but it may not be required if the gateway behind the proxy has this capability. Hope this helps.

  • autopoiesis's avatar
    autopoiesis
    Copper Contributor

    Hi BrianBaldock, thank you for the article.

     

    Re proxies for otherwise disconnected MDE endpoints (ie, no outbound internet access): are there any suggestions for suitable forward proxies to use?  There's plenty of info on URLs to configure, etc, but little info/advice on which proxy products actually work well.

     

    With requirements like no-TLS-inspection, handling authenticated/unauthenticated connections, dynamic URL lists, and constantly-changing geo-specific IPs, etc, product selection is not obvious.

     

    Any insight/suggestions/war stories very welcome.

  • M4R10s's avatar
    M4R10s
    Copper Contributor

    Hi Steve Newby  what if the host cannot have a proxy configured to the MDE cloud endpoint? 

    Can we route MDE traffic to other host and this proxy host will be communicating with MDE cloud endpoint?

    don't think so, MDE does not support such isolated scenarios. I believe that you are aware that highly regulated companies will have such requirements.  I will be happy to see other article about this how MDE is going address such a scenario. :xd:

  • Hi M4R10s 

     

    When you talk about internet traffic forwarded to another host, surely this is exactly what a proxy does?

    For scenarios such as this we have customers that have set up dedicated proxy servers that will only communicate to the MDE cloud endpoints and not other destinations/traffic.  This has worked well for scenarios such as DMZ or other environments that are typically disconnected from the corporate network.

    HTH

     

    Steve

  • M4R10s's avatar
    M4R10s
    Copper Contributor

    BrianBaldock the title of the article is a bit misleading, "Disconnected environments" in my understanding it's an environment that cannot be accessed even through direct proxy access; for example servers hosted in the DMZ, in this scenario internet traffic should be forwarded to another host, but MDE does not support such scenarios.

  • Hi wlawn001,

     

    Microsoft Defender for Endpoint on Linux supports proxies. An additional step is required as you'll have to define the environment proxy on the Linux OS first in order for the installation to succeed. You can then remove that configuration and add the static proxy to the MDE config. Reference: Microsoft Defender for Endpoint on Linux static proxy discovery | Microsoft Learn

     

    For Mac OS has it's similarities to both Windows and Linux. Microsoft Defender for Endpoint can discover a proxy server by using the following discovery methods: Proxy Auto-Config (PAC) or, Web Proxy Autodiscovery Protocol (WPAD) or, Manual static proxy configuration. Reference: Microsoft Defender for Endpoint on Mac | Microsoft Learn

     

    Hope this helps,

    Brian

  • Hi wlawn001,

     

    Microsoft Defender for Endpoint on Linux supports proxies. An additional step is required as you'll have to define the environment proxy on the Linux OS first in order for the installation to succeed. You can then remove that configuration and add the static proxy to the MDE config. Reference: Microsoft Defender for Endpoint on Linux static proxy discovery | Microsoft Learn

     

    For Mac OS has it's similarities to both Windows and Linux. Microsoft Defender for Endpoint can discover a proxy server by using the following discovery methods: Proxy Auto-Config (PAC) or, Web Proxy Autodiscovery Protocol (WPAD) or, Manual static proxy configuration. Reference: Microsoft Defender for Endpoint on Mac | Microsoft Learn

     

    Hope this helps,

    Brian

  • wlawn001's avatar
    wlawn001
    Copper Contributor

    Seems like the solution is focused on Windows clients.  Can Linux and Mac MDE clients function in a disconnected environment?  if so, are there details on setting those clients up?  Thanks.