Additional way to monitor DirectAccess machine/user activity on Windows 2012 and 2012R2 DirectAccess with component event logging
The following blog applies to DirectAccess on Windows Server 2012 or Windows Server 2012 R2 and shows a way to monitor DirectAccess machine/user activity by using component event logging, rather than, or in addition to the built-in Reporting and Remote Client Status in the DirectAccess Management Console. This is especially useful if the internal network is only IPv4 since the DA server sources all DA client traffic with its IPv4 address.
There are some advantages to the component event logging over the built-in reporting in the console and even the Get-RemoteAccessConnectionStatistics and Get-RemoteAccessUserActivity cmdlets.
Here are some of the possible advantages:
The source port used by the DirectAccess server for all connections to internal resources by DA clients is recorded. The source port is not visible in the DA Management console (only the destination IP and port is). This is important to track down instances when for example two DA machines/users connected to the same internal resource using the same DA server at the same time. Tracking the source port used by the DA server for each machine/user allows us to track exactly which machine/user generated specific traffic when only the source and destination ports are known for the traffic in question, since all DA client traffic is sourced with the IPv4 address of the DA server as it is sent inside the corporate network. This is important when the internal network does not have native IPv6.
In the built-in Reporting and Remote Client Status in the DirectAccess Management Console we can search for machine names and other criteria, but we can’t search by an internal IP address and or port to see who connected to it. But by using the component event logging we can search the event logs to look for this level of detail.
The IPHTTPS protocol has a limitation where the ISP IP address is not recorded. But by using the component event logging we can find the ISP IP address in the IPHLPSVC Operational event log for IPHTTPS traffic and then match it to an event in the Base-Filtering-Engine (BFE) Connections Operational log in order to identify the machine/user who connected with a specific ISP IP address.
The Get-RemoteAccessConnectionStatistics cmdlet is of limited use because while it dumps the users connected, it does not dump the resources they are connected to. The Get-RemoteAccessUserActivity cmdlet is also of limited use because while it dumps the connection to resources, it only does for a single user specified and it only dumps the destination port, not the source port. A combination of the two could possibly provide a dump of all the resources being accessed by all the computers/users but as mentioned earlier, it still would not provide the source port being used by the Direct Access server for the connection, which would not allow us to tell multiple client traffic apart, if they were connected to the same internal resource at the same time using the same Direct Access server.
Component event logging in some ways is easier to collect centrally (use Subscriptions) and analyze, than to use the built-in Reporting and Remote Client Status in the DirectAccess Management Console especially when there are multiple DA servers deployed. See https://technet.microsoft.com/en-us/library/cc748890.aspx
The following event logs are used:
IPHLPSVC Operational event log
Base-Filtering-Engine (BFE) Connections Operational log.
Base-Filtering-Engine (BFE) Resource Flows Operational log
WinNAT Operational log
Security event log
NOTE: In order to use it in production you probably have to increase the size of the event logs depending on how often the events will be saved/exported centrally and how much activity is recorded. Performance should also be taken into consideration depending on the size of the event logs and the hardware being used.
IPHLPSVC Operational event log
When DirectAccess clients connect to a DA server, first the “outer shell” connection is made with IPHTTPS (TCP 443) or Teredo (UDP3544). This connection is not authenticated but the client cannot access any corporate network resources at that time. After the “outer shell” connection is made, the Client and the DA server authenticate each other using IPSec.
When an IPHTTPS connection is established an event 4303 is logged in the iphlpsvc Operational log and it contains the date and time the IPHTTPS connection was made. (The event is not logged for Teredo)
When the IPHTTPS connection id dropped an event 4304 is logged with the date and time.
One key thing which also gets logged is the DA client IP address where the connection came from (ISP IP address). This overcomes the limitation of the IPHTTPS protocol which does not provide an ISP IP address and leaves the “ISP Address” blank in Reporting and Remote Client Status within the Remote Access Management Console.
NOTE: Actually three 4303 events get logged for Windows7/8.x at the time the IPHTTPS connection is made. One for the IPv6 temporary address, one for the non-temporarily IPv6 address, and one for the Link Local address. These addresses are bound to the IPHTTPS adapter on the client:
The temporary IPv6 address is the one which gets used by the Windows 7/8.x clients to make DA connections. Current builds of Windows 10 do not have a temporary IPv6 address for the IPHTTPS adapter. The non-temporary address is used by Windows 10.
Base-Filtering-Engine (BFE) Connections Operational log.
To associate this IPv6 address found in the iphlpsvc operational log to a computer/user, find (search) for the IPv6 address in the Base-Filtering-Engine (BFE) Connections Operational log. (note: only the temporary IPv6 address will be found for Win7/8)
For example the details tab of this event 2000 we see the matching IPv6 address form the event 4303 earlier and shows the machine CONSOSO\C0-Win7 is associated with the IPv6 address at the same time: 2:52:12 PM. If this was a user initiated connection the RemoteUserAccount would show the domain\username.
This is when the Main Mode IPSec Security association (MMSA) was created which is where the actual authentication takes place.
When the session closes, a corresponding event 2001 gets logged in the Base-Filtering-Engine (BFE) Connections Operational log
The Details tab has matching connectionid to match the event 2000 (New connection) and event 2001 (Connection closed)
The event 2001 contains a summary for the connection with detail on the inbound/outbound bytes transferred, and the total bytes transferred. Also it includes the session start/end date and time.
Base-Filtering-Engine (BFE) Resource Flows Operational log
The next interesting event log is the Base-Filtering-Engine (BFE) Resource Flows Operational log.
This event log is interesting but not very useful to track down machine/user connectivity (except maybe while troubleshooting). The reason it is not very useful is because this event log tracks only the connections (flows) between the DA client and the DA server, but not between the DA server and the internal resource.
When a DA client accesses some internal resource an event 2002 is logged in the Base-Filtering-Engine (BFE) Resource Flows Operational log
The details tab contains the detail information between the DA client and the DA server.
The connectionUserid can be matched to the Connectionid event 2000 in the Base-Filtering-Engine (BFE) Connections Operational log to see what computer/user made the connection.
The protocol used for the connection (6=TCP, 17=UDP)
The RemoteIPAddress is the IPv6 address of the DA client
The localIPAddress is a NATed IPv6 address. In the example above if we convert A1CBF02 we can convert it to decimal and we can tell the client connected to IPv4 address 10.18.191.2
The RemotePort is the source port from the DA client.
The LocalPort is the destination port the DA client sent on the request (its “local” to the DA server since that’s where the client is sending the request to)
StartTime is the date and time the connection was made.
Again, this event is interesting and good to know it’s there, but it’s not useful because while we can convert the LocalIPAddress to decimal to tell what resource the DA client connected to, the source port was the port used from the DA client to the DA server, it is not the same port used by the DA server when it forwards the traffic inside the corporate network.
WinNAT Operational log
The log which is of most interest to track down the resources the DA client connected to is the WinNAT Operational log.
When a DA client connects to an internal resource an event 1017 is logged.
In this example if it was a TCP connection.
It shows the IPv6 address of the DA client and the source port number by the client for this connection (between the client and the DA server)
NOTE: Search for this IPv6 address in the Base-Filtering-Engine (BFE) Connections Operational log to get the machine/user who made the connection.
It shows the destination IPv6 address for the resource and the port number (135)
This is a Unique Local Address (ULA) made up by the DA server.
It shows the IPv4 address of the DA server (10.28.191.18) and the source port (6002) by the DA server used to make the NATed connection to the internal resource. This is the source IP and port an IPS or network trace inside the corporate network would see.
NOTE: This is useful to track down exactly which machines/users who were connected to the same internal resource at the same time using the same DA server (each will have an event 1017 logged with a different source port by the DA server). The DA server source port is not exposed in the DirectAccess Management Console under the built-in Reporting and Remote Client Status.
It shows the destination IPv4 address (10.28.191.2) and destination port (135) for the resource inside the corporate network. . This is the destination IP and port an IPS or network trace inside the corporate network would see.
Note: The destination IPv6 ULA address 
is derived from the destination IPv4 address
fd0d:36e:62b8:7777:a1c:bf02
10.28.191.2
A = 10
1C = 28
BF = 191
02 = 2
And it shows the date and time the connection to the resource was made by the DA client.
Also an event 1018 is logged when the connection to the resource closes.
Q/A
Q1.How do DA machines/users authenticate with DirectAccess?
A1.It depends on how DA is configured. If Windows 7 support and certificates is enabled, then the machine authenticates to the DA server using machine certificates and NTLMv2 and the user authenticates to the DA server using machine certificate and Kerberos.
For the user authentication method, the default setting is Active Directory username/password, but two-factor authentication can be enabled on step 2 of the Remote Access Management Console wizard. Smart card authentication can be selected here and you can also add one-time password (OTP) support.
If user 2FA is used (smart card /OTP) then this certificate is used to derive the Kerberos tickets for user authentication instead of the user password. See PKINIT details here: https://msdn.microsoft.com/en-us/library/cc238456.aspx
If no Windows 7 support or certificate support is selected, or you use the Getting Started Wizard (https://blogs.technet.com/b/mspfe/archive/2012/09/20/enriched-remote-access-experience-in-windows-server-2012.aspx) then Kerberos (kerbproxy) is used for the machine authentication and there is no support for 2FA.
Q2. Can these event logs show if a machine/user failed to authenticate to DA?
A2. The events we covered won’t show authentication failures, but the Security event log will. For example if a machine/user can’t authenticate with the DA server because it is disabled in Active Directory, an event 4625 is logged. For example:
Additionally IPSec can be configured to log failures in the Security event log with the following commands:
C:> auditpol /set /subcategory:"IPsec Main Mode" /failure:enable
C:> auditpol /set /subcategory:"IPsec Quick Mode" /failure:enable
C:> auditpol /set /subcategory:"IPsec Extended Mode" /failure:enable
in which case additional events will be logged when IPSec fails to authenticate. For example:
Q3. How can I match the ISP IP address to a user/computer when IPHTTPS is used?
A3. For IPHTTPS, in the iphlpsvc Operational log find the ISP IP address and the corresponding IPv6 DA client address (event 4303/4304. Then search for the IPv6 address in the Filtering-Engine (BFE) Connections Operational log to find the DA machine/user who authenticated at that time with the particular IPv6 address (event 2000/2001).
Or the other way around. To find what the ISP IP address is for a given machine/user, find the machine/user in the Filtering-Engine (BFE) Connections Operational log to get the IPv6 address, then search for the IPv6 address in the iphlpsvc Operational log.
Q4. How can I tell when a machine/user session was established to the DA server?
A4. Event 2001 in the Filtering-Engine (BFE) Connections Operational log is logged with a “start time” and “close time”
NOTE: This is fundamentally very different than VPN. With VPN when a connection is made, all machine and user connections to resources are made within that VPN tunnel. When the VPN tunnel drops, that’s when the logs would show the VPN session disconnected, even if the machine/user had no active connections to any internal resources in the VPN tunnel for a long time. With Direct Access the “start time” and “close time” are based on IPSec, so the session times may be a lot shorter and there may be multiple active sessions at the same time. If you want to see when the “full” (outer shell) IPHTTPS connection was dropped, look for an event 4304 in the iphlpsvc operational log
Q5. How do I identify the computer/user who made a connection to a resource at a given time?
A5. In the WinNAT Operational log find the resource by IP and or port at the time of interest, and find the IPv6 address for the client in the event 1017 . Then search for the IPv6 address in the Filtering-Engine (BFE) Connections Operational log to find the DA machine/user who authenticated at that time with the particular IPv6 address (event 2000/2001)
Q6. How can I tell how much data was sent/received by a machine/user?
A6. Event 2001 in the Filtering-Engine (BFE) Connections Operational log has the bytes in/out and total.
Q7. How can I tell the source and destination IPs and ports used by a DA client and by the DA server?
A7. Event 1017 in the WinNAT Operational log has the source/destination IP/ports from the DA client to the DA server and also from the DA server to the internal resource.
Q8. How can I track suspicious network activity on the network by a DA computer/user if all the traffic from DA clients is sourced with the same internal IP address of the DA server?
A8. Get the source port and destination port of the suspicious network traffic along with the destination IP (from an IPS or a network trace) and search the WinNAT Operational log to get the DA client IPv6 address. Then search for the IPv6 address in the Filtering-Engine (BFE) Connections Operational log to find the DA machine/user who authenticated at that time with the particular IPv6 address (event 2000/2001)
Additionally to get a “live” dump of all the DA machines/users currently connected to the DA server and all the corporate resources being accessed at that time (including source and destination ports), run the following PsH script on the DA server:
---------------------------------------------------------------------------------------------------------------------------
$Mapping = @{}
$NatTransitions=Get-NetNatTransitionMonitoring
foreach($NatTransition in $NatTransitions)
{
$Entries=$NatTransition.InstanceID.split(";")
$ClientIPv6 = $Entries[0].split("]")[0].trim("[")
$Resource = '[' + $NatTransition.TransportProtocol + ',' + $NatTransition.InBoundAddress + ',' + $NatTransition.OutBoundAddress + ']'
#Add this info to the Mapping
if(-not $Mapping.Contains($ClientIPv6))
{
$Mapping.Add($ClientIPv6, $Resource)
}
else
{
$Resources = $Mapping.Get_Item($ClientIPv6)
$Resources = $Resources + "," + $Resource
$Mapping.Set_Item($ClientIPv6,$Resources)
}
}
$OutPutArray = @()
$ConnectionStatistics = Get-RemoteAccessConnectionStatistics
foreach($ConnectionStatistic in $ConnectionStatistics)
{
if($ConnectionStatistic.ConnectionType -eq "DirectAccess")
{
$ClientIPv6=$ConnectionStatistic.ClientIPAddress.IPAddressToString
$Resources = $Mapping.Get_Item($ClientIPv6)
$OutPut = new-object psobject -Property @{
HostName = $ConnectionStatistic.HostName
UserName = $ConnectionStatistic.UserName
ClientIPAddress = $ConnectionStatistic.ClientIPAddress
ResourcesAccessed = $Resources
}
$OutPutArray += $OutPut
}
}
$OutPutArray | Format-List HostName,ClientIPAddress,UserName,ResourcesAccessed
----------------------------------------------------------------------------------------------------------------------------------
This is an example of the output from the PsH script generates:
In the example above we can see two DA clients are connected. One client is just the machine connected (C3-win81) and the other (C0-Win7) the machine and the user are connected (Contoso-user1).
The ResourcesAccessed uses the following format:
[<protocol number>, <Source IP address> :<source port>, <Destination IP address> :<destination port> ]
The source IP address is always the IP address of the DA server.
The source port number is the source port the DA server NAT64 component is using for the connection.
The destination IP is the IP address of the resource inside corpnet.
The destination port is the destination port for the resource inside corpnet.
For example the machine C3-Win81 first active connection is:
TCP (protocol6) from DA server IP 10.28.191.18 using source port 6005. The connection is to an internal resource with IP address 10.28.191.101 and the destination port is 445.
Machine C0-Win7 first active connection is:
UDP (protocol 17) from DA server IP 10.28.191.18 using source port 6006. The connection is to an internal resource with IP address 10.28.191.1 and the destination port is 389.
NOTE: UDP sessions stay active and are displayed for about 5 minutes after they are sent, and TCP connections are displayed for about 2 minutes after they are closed.
Q9. Will Pings (ICMP echo) get logged?
A9. Yes. ICMPv6 gets logged in the WinNAT operational log. Instead of a port number it shows the protocol number since there is no port number on ICMPs.
At least one event gets logged in a series of ICMP Echo’s to the same destination IP, and they get logged even if the destination IP was unreachable.
Example output from PsH script:
Reference: https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xml
Microsoft Corporation. All rights reserved. Sample scripts in this guide are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Microsoft 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.
Comments
- Anonymous
January 28, 2016
Hi Martin,
Should there also be events logged on the client side ? I checked and the IPhlpsvc event log is empty no all my clients. Is that normal ?
Thanks in advance,