Monitoring DirectAccess Machine and User Activity with Windows Component Event Logging

Monitoring DirectAccess Machine and User Activity with Component Event LoggingThe monitoring of DirectAccess machine and user activity presents some unique challenges for security administrators. All DirectAccess client communication destined for the internal corporate network is translated by the DirectAccess server and appears to originate from the DirectAccess server’s internal IPv4 address. Also, the public IPv4 address for DirectAccess clients using the IP-HTTPS IPv6 transition protocol is not visible using the native reporting tools. In addition, vital information such as source ports used by the DirectAccess server for internal connections and source ports used by DirectAccess clients is not available. This lack of granular connection logging creates a serious blind spot for administrators conducting forensic investigations.

As veteran Microsoft Premier Field Engineer (PFE) Martin Solis described in detail in a recent blog post, all of these details are in fact logged. However, gathering this information is not exactly intuitive. To collect this essential information it will be necessary to leverage Windows component event logging. By searching the IPHLPSVC, Base Filtering Engine Connections, Base Filtering Resource Flows, and WinNAT operational logs, it is possible to gather all of the information necessary for uniquely identifying DirectAccess corporate network communication.

Be sure to read Martin’s excellent article about using Windows component event logging to monitor DirectAccess machine and user activity, which can be found here.

DirectAccess Client Firewall Rule Configuration for ISATAP Manage Out

For DirectAccess manage out scenarios, it is necessary to configure the Windows firewall on the DirectAccess client to allow any required inbound communication from the corporate network. For example, if management hosts on the internal network need to initiate Remote Desktop sessions with remote connected DirectAccess clients, the Remote Desktop – User Mode (TCP-In) Windows firewall rule will need to be enabled for the Public and Private profiles.

DirectAccess Client Firewall Rule Configuration for ISATAP Manage Out

While enabling this rule will allow remote desktop connections to be made from the corporate network, its default configuration will also accept remote desktop connections from any network. From a security perspective this is not desirable.

DirectAccess Client Firewall Rule Configuration for ISATAP Manage Out

A better solution is to restrict access to connections originating only from the corporate network. To do this it will be necessary to identify the ISATAP prefix used internally. To determine the corporate ISATAP prefix, run the ipconfig command on a management workstation that is configured for ISATAP. The ISATAP prefix will be the first 96 bits of the IPv6 address assigned to the ISATAP tunnel adapter (essentially everything with the exception of the embedded IPv4 address).

DirectAccess Client Firewall Rule Configuration for ISATAP Manage Out

On the DirectAccess client, right-click the firewall rule and choose Properties. Choose the Scope tab and then select These IP addresses . Click Add and then enter the ISATAP prefix as shown here.

DirectAccess Client Firewall Rule Configuration for ISATAP Manage Out

Once the firewall rule is configured to restrict access to the ISATAP prefix, only corporate management workstations on the internal network will have access to remote DirectAccess clients.

ISP Address Field is Blank in DirectAccess Status and Reports

When viewing DirectAccess client status in the Remote Access Management console, you will notice that the ISP address field is blank for clients using the IP-HTTPS IPv6 transition protocol. However, the ISP Address information is displayed for clients using the 6to4 or Teredo IPv6 transition protocols.

ISP Address Field is Blank in DirectAccess Status and Reports

This is expected behavior and occurs as a result of the way in which the DirectAccess reports obtain the client’s public ISP address information. The ISP address is derived from the IPv6 address used to establish the DirectAccess client’s IPsec Security Associations (SAs) on the DirectAccess server. For clients using the 6to4 or Teredo IPv6 transition protocols, the client’s public IPv4 address is embedded in its IPv6 address. This information is displayed in the ISP Address field. However, the IP-HTTPS IPv6 transition protocol uses completely random IPv6 addresses. Without an embedded IPv4 address, the Remote Access Management console lacks the information to display in the ISP Address field.

Updated 3/22/2015: With a little extra work it is possible to find the IPv4 ISP address for DirectAccess clients using the IP-HTTPS IPv6 transition protocol. For more information, please refer to Microsoft PFE Martin Solis’ excellent blog post on the subject here.