Dear IT Pros,
We knew that it is normal for Domain Controller and critical servers to be in isolated network without internet access.
How could we provide the cloud-based, Azure log analytic services for these objects? The services could originate from different products like DLP Cloud, MDE Cloud, MDI Cloud, Azure Log Analytics and more. What is the best way to accommodate these needs?
We will discuss the following topics:
- Microsoft Monitoring Agent - MMA connection for older servers (Windows 2008R2, 2012R2, 2016 Servers) in isolated network.
- Telemetry connection for newer servers (Windows 10, Windows 2019) in isolated network.
- Stand-alone Sensor in isolated network.
Microsoft Monitoring Agent Connection for older Windows in isolated network
The steps below are applicable only to devices running previous versions of Windows such as: Windows Server 2016 and earlier or Windows 8.1 and earlier. Offline devices in the same network of Azure Log Analytics
- The only extra step is that we configure MMA with proxy setting pointed to Proxy Server IP address or FQDN together with its port. We need the following steps:
- Install MMA with Cloud Service workspace key & ID for example: MDE ID and Key, Log Analytics Workspace ID and Key, DLP Service ID and Key.
- Click Advance button and enter the Proxy IP Address:Port Number
LAB Demo
In this Demo Lab, we will use the Proxy Server on a Windows 2019 device instead of Proxy Appliance.
Proxy Server on Windows 2019 with Internet Connection:
- Download WinGate (80MB) and Install WinGate:
Configure Wingate \ services
> WWW Proxy server
On Windows 2012R2 Server,
Run MMA setup
> Run MMA setup as usual
> Connect the agent to Azure Log Analytics (OMS)
> Click Advance
Typing in the proxy server IP Address and Port number (8080)
> Next, Finish.
Result:
There is no problem as long as the system time is within time discrepancy (15min) with Azure time.
Telemetry connection for Windows 10, 2019 in isolated network
For newer Server of Windows 2019 and Workstation of Windows 10, we need to use the built-in Telemetry service of Windows OS together with Proxy configuration to transport diagnostic logs to the Cloud Analytic Services like MDE,
For endpoint devices that aren't permitted to connect to the Internet, you need to configure a proxy connection to allow telemetry to forward log diagnostic data to Microsoft Cloud Service.
Let us start with an important notice:
- An OMS gateway server cannot be used as proxy for disconnected Windows 10 or Windows Server 2019 devices when configured via 'TelemetryProxyServer' registry or GPO.
- For Windows 10 or Windows Server 2019 - while you may use TelemetryProxyServer, it must point to a standard proxy device or appliance.
- In addition, Windows 10 or Windows Server 2019 in disconnected environments must be able to update Certificate Trust Lists offline via an internal file or web server.
The WinHTTP configuration setting is independent of the Windows Internet (WinINet) Internet browsing proxy settings and can only discover a proxy server by using the following auto discovery methods:
- Transparent proxy, no extra configuration needed.
- Web Proxy Auto-discovery Protocol (WPAD), no extra configuration needed.
- Registry-based configuration, manual static proxy configuration.
- Netsh command, manual static proxy configuration. It is suitable only for desktops in a stable topology (for example: a desktop in a corporate network behind the same proxy)
Configure the proxy server manually using a registry-based static proxy
Prerequisite:
When using this option on Windows 10 or Windows Server 2019, it is recommended to have the following (or later) build and cumulative update rollup:
- Windows 10, version 1809 or Windows Server 2019 - https://support.microsoft.com/kb/5001384
- Windows 10, version 1909 - https://support.microsoft.com/kb/4601380
- Windows 10, version 2004 - https://support.microsoft.com/kb/4601382
- Windows 10, version 20H2 - https://support.microsoft.com/kb/4601382
These updates improve the connectivity and reliability of the CnC (Command and Control) channel.
Enable access to Microsoft Defender for Endpoint service URLs in the proxy server
- If a proxy or firewall is blocking all traffic by default and allowing only specific domains through, add the domains listed in the downloadable sheet to the allowed domains list.
- The following downloadable spreadsheet lists the MDE services and their associated URLs that your network Firewall filtering rules must be set to allow the connections to them.
Spreadsheet of specific DNS records for service locations, geographic locations, and OS.
Download the spreadsheet here.
- If a proxy or firewall has HTTPS scanning (SSL inspection) enabled, exclude the domains listed in the above table from HTTPS scanning.
Configure the proxy server manually using a registry-based static proxy
The static proxy is configurable through Group Policy (GP). The group policy can be found under:
Administrative Templates > Windows Components > Data Collection and Preview Builds > Configure Authenticated Proxy usage for the Connected User Experience and Telemetry Service
- select Disable Authenticated Proxy usage:
- Enable "Configure Connected User Experiences and Telemetry"
The policy sets two registry values TelemetryProxyServer as REG_SZ and DisableEnterpriseAuthProxy as REG_DWORD under the registry key HKLM\Software\Policies\Microsoft\Windows\DataCollection.
- The registry value TelemetryProxyServer is in this format <server name or ip>:<port>. For example: 10.0.0.3:8080
- The registry value DisableEnterpriseAuthProxy should be set to 1.
Configure the proxy server manually using "netsh" command
Use netsh to configure a system-wide static proxy.
Note:
This will affect all applications including Windows services which use WinHTTP with default proxy. - Laptops that are changing topology (for example: from office to home) will malfunction with netsh. Use the registry-based static proxy configuration if you do not want the whole system communicate over the internet.
- Open an elevated command line as administrator.
- netsh winhttp set proxy <proxy>:<port>
For example: netsh winhttp set proxy 10.0.0.3:8080
To reset the winhttp proxy, enter the following command and press Enter:
- netsh winhttp reset proxy
MDI Mirroring in Isolated Network
For MDI in Isolated Network, you will need to install a stand-alone sensor which will collect log data from all the Domain Controllers on the LAN Network.
Defender for Identity standalone sensor requirements:
- The Defender for Identity standalone sensor supports installation on a server running Windows Server 2012 R2 or Windows Server 2016 (Include server core).
- The Defender for Identity standalone sensor can be installed on a server that is a member of a domain or workgroup.
- The Defender for Identity standalone sensor can be used to monitor Domain Controllers with Domain Functional Level of Windows 2003 and above.
- 2 NICs, one for Management and one for Capturing log data.
Setup steps
- Configure Network adapters
The Npcap driver allow network adapter to collect all network traffic packets (windows capture in promicuos mode). Download the Npcap version 1.0 from https://nmap.org/npcap/
- Uninstall Wincap if you already installed it.
- Installing Npcap with the following options: loopback_support=no and winpcap_mode=yes. (deselect the loopback support and select WinPcap mode).
The Defender for Identity standalone sensor requires at least one Management adapter and at least one Capture adapter:
- Management adapter - used for communications on your corporate network. The sensor will use this adapter to query the DC it's protecting and performing resolution to machine accounts.
This adapter should be configured with the following settings:
- Static IP address including default gateway
- Preferred and alternate DNS servers
- The DNS suffix for this connection should be the DNS name of the domain for each domain being monitored.
Ports
The following table lists the minimum ports that the Defender for Identity standalone sensor requires configured on the management adapter:
|
MANAGEMENT ADAPTER PORTS |
||||
|
Protocol |
Transport |
Port |
From |
To |
|
Internet ports |
||||
|
SSL (*.atp.azure.com) |
TCP |
443 |
Defender for Identity Sensor |
Defender for Identity cloud service |
|
Internal ports |
||||
|
LDAP |
TCP and UDP |
389 |
Defender for Identity Sensor |
Domain controllers |
|
Secure LDAP (LDAPS) |
TCP |
636 |
Defender for Identity Sensor |
Domain controllers |
|
LDAP to Global Catalog |
TCP |
3268 |
Defender for Identity Sensor |
Domain controllers |
|
LDAPS to Global Catalog |
TCP |
3269 |
Defender for Identity Sensor |
Domain controllers |
|
Kerberos |
TCP and UDP |
88 |
Defender for Identity Sensor |
Domain controllers |
|
Netlogon (SMB, CIFS, SAM-R) |
TCP and UDP |
445 |
Defender for Identity Sensor |
All devices on network |
|
Windows Time |
UDP |
123 |
Defender for Identity Sensor |
Domain controllers |
|
DNS |
TCP and UDP |
53 |
Defender for Identity Sensor |
DNS Servers |
|
Syslog (optional) |
TCP/UDP |
514, depending on configuration |
SIEM Server |
Defender for Identity Sensor |
|
RADIUS |
UDP |
1813 |
RADIUS |
Defender for Identity sensor |
|
Localhost ports |
Required for Sensor Service updater |
|||
|
SSL (localhost) |
TCP |
444 |
Sensor Service |
Sensor Updater Service |
|
NNR ports |
||||
|
NTLM over RPC |
TCP |
135 |
Defender for Identity |
All devices on network |
|
NetBIOS |
UDP |
137 |
Defender for Identity |
All devices on network |
|
RDP |
TCP |
3389, only the first packet of Client hello |
Defender for Identity |
All devices on network |
Capture adapter - used to capture traffic to and from the domain controllers.
- Configure port mirroring for the capture adapter as the destination of the domain controller network traffic. You could use one of the following method:
- Switched Port Analyzer (SPAN) – Copies network traffic ports to another port on the same switch. Both the Defender for Identity standalone sensor and domain controllers must be connected to the same physical switch.
- Remote Switch Port Analyzer (RSPAN) – Allows you to monitor network traffic from source ports distributed over multiple physical switches. RSPAN copies the source traffic into a special RSPAN configured VLAN and switches’ trunks. RSPAN works at Layer 2.
- Encapsulated Remote Switch Port Analyzer (ERSPAN) – Is a Cisco proprietary technology working at Layer 3. ERSPAN allows you to monitor traffic across switches without the need for VLAN trunks. For Defender for Identity to work with ERSPAN traffic, a switch or router that can decapsulate the traffic needs to be configured as the destination of ERSPAN where the traffic is decapsulated. Then configure the switch or router to forward the decapsulated traffic to the Defender for Identity standalone sensor using either SPAN or RSPAN.
- On the Capture Adapter, TCP/IP v4 properties:
- Configure a static non-routable IP address (with /32 mask) for your environment For example, 10.10.0.10/32.
- no default sensor gateway and no DNS server addresses.
- Installing the Sensor and configure MDI as the normal case, you could also take reference of the setup steps from Microsoft documents or from my techblog article “MDI Setup and Troubleshooting”
Limitation:
- Defender for Identity standalone sensors do not support the collection of Event Tracing for Windows (ETW) log
I hope the information is useful for future deployment in isolated environment.
Until next time, Cheer.
Reference:
- Defender for Identity sizing tool
- Defender for Identity architecture
- Install Defender for Identity
- Endpoint DLP Proxy Setup.
- Configure device proxy and Internet connection settings | Microsoft Docs
- MDE M365 Onboard offline machines
- MDE M365 Proxy settings
- MDI Mirroring Network
Disclaimer The sample scripts are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages.
Posted at https://sl.advdat.com/3iDa2W5
