MDE: Windows disconnected environment - decision tree

It has always been challenging to deploy MDE in a disconnected environment i.e. behind a proxy. Thankfully, Microsoft and Brian Baldock have release a series of 3 blog posts on MDE connectivity in a Windows disconnected environment. In additional to that, I thought I would summarize it as a decision tree and share some notes from the field and additional related documentations.

Linux environments are more straight forward and use the traditional options to deploy a proxy (system-wide using the https_proxy variable or application wide by configuring the proxy on all required components)

Content

• Decision Tree

• Note from the field

• Reference

  • Brian Baldock blog posts

  • Windows Update offline solution

  • Trusted Root CA Certificate offline solution

  • Enable TLS 1.2

Decision Tree

1. Disconnected Environment: Does your machine have direct access to the internet? If yes you do not need a proxy

2. Live Response: Live Response requires WinHTTP or a direct internet connection.

3. Server: Workstation will generally use WinInet as they would be managed and receive Windows updates from MECM or Intune. It is configured with internet explorer settings (inetcpl.cpl), Windows setting page or a PAC file.

4. Offline/Local Windows Update: Do you have WSUS, MECM or a file share to manage your Windows Update? If yes, has this environment been optimised to support the frequent definition updates retrieval such as every 1-4 hours? If the answer is no, then use WinHTTP to retrieve updates from the Windows Update website.

5. Offline Certificate Management: Do you have an offline solution to manage your Trusted Root CA certificate updates and revocation lists? If no, then use WinHTTP to prevent any TLS issue.

6. Static Proxy: If the answer is yes to all questions then you can use the application/static/registry proxy.

Notes from the field

1. Your proxy must NOT inspect SSL/TLS traffic for all MDE URL endpoints except for *.blob.core.windows.net

2. Your proxy must be configured to bypass authentication for all MDE URL endpoints

3. Ensure that TLS 1.2 is enabled in your environment.

4. WinHTTP is configured using:

netsh winhttp set proxy [proxy-server=] ProxyServerName [bypass-list=] <HostsList>

1. Do not omit to setup your bypass list to prevent any disruption to on-premises workload such as SQL database or web server.

2. <local> in the bypass list only applies to non FQDN locations such as http://mylocation

3. <local> does NOT mean that all local locations will not use the proxy. For instance, traffic to http://mylocation.domain.local will indeed be redirected to your proxy.

4. To bypass proxy in your local environment, use *.domain.com including all your domains separated by a semi-colon for winhttp e.g. "*.domain.com;*.domain.local"

5. AWS SSM agent does NOT support <local> variable in the bypass when WinHTTP is configured and will lose connectivity with the console. Do Not include it in the bypass list.

6. Use the client analyser at the beginning of your deployment to identify any connectivity issue.

7. If you use MECM and add MECM as a definition update source, MECM will overseed any order specified except if MECM retrieval fails:

If Configuration Manager is specified as one of the sources, then the other sources are used only if software updates fail to download the client updates.

Definition Updates Settings

Reference

Brian Baldock blog posts

1. Disconnected environments, proxies and Microsoft Defender for Endpoint

2. Which proxy configuration wins?

3. Cloud-centric networking decisions

Windows update offline/local solution

1. WSUS: Use WSUS to deploy definition updates to computers that are running Windows Defender

2. MECM: Use Configuration Manager to deliver definition updates

3. File share: Create a UNC share for security intelligence and platform updates

Certificate offline solution

1. Configure a file or web server to download the CTL files

Enable TLS 1.2

1. Configuring Schannel protocols in the Windows Registry