Disconnected environments, proxies and Microsoft Defender for Endpoint

Posted on by — No Comments ↓

This post has been republished via RSS; it originally appeared at: Microsoft Tech Community - Latest Blogs - .

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 and air-gapped environments can pose a challenge to deploying and configuring Defender for Endpoint. When proxies are added into the mix, interesting things can happen.  

 

Recipe for a successful deployment 

To deploy Defender for Endpoint in a disconnected or air-gapped 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. All of the regional URLs listed in the mde-urls-commercial.xlsx (live.com) must be added to your allow list in your proxy and should not have TLS inspection on the network traffic. 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 listed in the spreadsheet, 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 

Defender for Endpoint will function as expected provided: 

  • A user remains in a logged in state; effectively establishing an authentication flow through the proxy. 
  • The proxy is not performing TLS inspection on the Defender for Endpoint URLs listed in the mde-urls-commercial.xlsx (live.com). 
  • The proxy has bypassed URLs in the URL list to allow unauthenticated traffic. 

 

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 or air gapped 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 URL list as possible. 
    • Proxies blocking external access from those disconnected or air gapped environments. You will need to add 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 

Leave a Reply

Your email address will not be published. Required fields are marked *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.