TechMentor Conference Orlando 2017

I'm Speaking at Live!360 and TechMentor Event 2017 in Orlando, Florida November 12-17. Join me!I’m pleased to announce that I’ll be speaking at the TechMentor Conference (which is part of Live! 360) in Orlando, FL. The event takes place November 12-17 and I will be delivering several sessions on DirectAccess, DNS policies, and network troubleshooting in Windows Server 2016. More details these sessions can be found here.

TMT02 – Implementing DirectAccess with Windows Server 2016

TMW01 – Network Troubleshooting for Windows Administrators

TMW04 – Introducing DNS Policies in Windows Server 2016

Sign up using promotion code LSPK34 and save $500.00. Register now!

 

 

Top 5 DirectAccess Troubleshooting PowerShell Commands

Top 5 DirectAccess Troubleshooting PowerShell CommandsNative PowerShell commands in Windows 10 make DirectAccess troubleshooting much easier than older operating systems like Windows 7. For example, with one PowerShell command an administrator can quickly determine if a DirectAccess client has received the DirectAccess client settings policy. In addition, PowerShell can be used to view the status of the connection and retrieve additional information or error codes that can be helpful for determining the cause of a failed connection. Further, PowerShell can also be used to review configuration details and perform other troubleshooting and connectivity validation tasks.

Here are my top 5 PowerShell commands for troubleshooting DirectAccess on Windows 10.

1. Get-DAClientExperienceConfiguration

Ensuring that the DirectAccess Client Settings group policy has been applied to the client is one of the first steps in troubleshooting failed DirectAccess connections. While it is possible to use gpresult to do this, using the Get-DAClientExperienceConfiguration PowerShell command is much simpler. If DirectAccess client settings have been applied, the output of the command will include information such as the IPsec tunnel endpoint IPv6 addresses and the Network Connectivity Assistant (NCA) corporate resource URL. If DirectAccess client settings have not been applied, this information will be missing.

Top 5 DirectAccess Troubleshooting PowerShell Commands

Figure 1. DirectAccess Client Settings group policy successfully applied.

Top 5 DirectAccess Troubleshooting PowerShell Commands

Figure 2. DirectAccess Client Settings group policy not applied.

2. Get-NetIPHttpsState

Performance improvements first introduced in Windows 8 have made IP-HTTPS the IPv6 transition technology of choice when it comes to supporting DirectAccess client connectivity. Also, if the DirectAccess server is located behind an edge device performing Network Address Translation (NAT), IP-HTTPS is the only supported transition technology. Using the Get-NetIPHttpsState PowerShell command, the DirectAccess administrator can quickly determine if the IP-HTTPS connection was successful. If it was not, the command will return an error code and interface status that will indicate why the IP-HTTPS connection was unsuccessful.

Top 5 DirectAccess Troubleshooting PowerShell Commands

Figure 3. Get-NetIPHttpsState

3. Get-NetIPHttpsConfiguration

When troubleshooting IP-HTTPS connection failures, it is necessary to obtain additional information to continue the troubleshooting process. Using the Get-NetIPHttpsConfiguration PowerShell command, the DirectAccess administrator can obtain the public hostname for the DirectAccess server and ensure that the name resolves to the correct IP address in DNS and that it is reachable on TCP port 443.

Top 5 DirectAccess Troubleshooting PowerShell Commands

Figure 4. Get-NetIPHttpsConfiguration

4. Resolve-DnsName

Using the Resolve-DnsName PowerShell command is crucial when performing any name resolution tasks on the DirectAccess client. This is because Resolve-DnsName is aware of the Name Resolution Policy Table (NRPT) and will direct name resolution requests accordingly. Tools like nslookup are DNS server testing tools and are unaware of the NRPT. Typically they do not yield expected results when testing name resolution on a DirectAccess client.

Top 5 DirectAccess Troubleshooting PowerShell Commands

Figure 5. Name resolution results from Resolve-DnsName and nslookup.

5. Get-DnsClientNrptPolicy

Often the cause of DirectAccess client connectivity issues is a misconfigured NRPT. Using the Get-DnsClientNrptPolicy PowerShell command the DirectAccess administrator can validate that name resolution requests for host names in any internal namespaces are being sent to the DirectAccess DNS64 IPv6 address.

Top 5 DirectAccess Troubleshooting PowerShell Commands

Figure 6. Get-DnsClientNrptPolicy

Additional Resources

Top 5 DirectAccess Troubleshooting Tips

Troubleshooting Name Resolution Issues on DirectAccess Clients

Learn PowerShell in a Month of Lunches Book by Don Jones and Jeff Hicks

Implementing DirectAccess with Windows Server 2016 Book

Planning and Implementing DirectAccess with Windows Server 2016 Video Training Course

Managing and Supporting DirectAccess with Windows Server 2016 Video Training Course

 

 

DirectAccess Reporting Fails and Schannel Event ID 36871 after Disabling TLS 1.0

IMPORTANT NOTE: The guidance in this post will disable support for null SSL/TLS cipher suites on the DirectAccess server. This will result in reduced scalability and performance for all clients, including Windows 8.x and Windows 10. It is recommended that TLS 1.0 not be disabled on the DirectAccess server if at all possible.

When performing security hardening on the DirectAccess server it is not uncommon to disable weak cipher suites or insecure protocols such as SSL 3.0 and TLS 1.0. However, after disabling SSL 3.0 and TLS 1.0 you will find that it is no longer possible generate reports. Clicking the Generate Report link in the Remote Access Management console returns no data.

DirectAccess Reporting Fails after Disabling TLS 1.0

In addition, the System event log indicates Schannel errors with Event ID 36871. The error message states that “A fatal error occurred while creating a TLS client credential. The internal error state is 10013.”

DirectAccess Reporting Fails after Disabling TLS 1.0

To resolve this issue and restore DirectAccess reporting functionality you must enable the use of FIPS compliant encryption algorithms on the DirectAccess server. This change can be made locally or via Active Directory group policy. Open the Group Policy Management Console (gpmc.msc) for Active Directory GPO, or the Local Group Policy Editor (gpedit.msc) on the DirectAccess server and navigate to Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options. Double-click System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing and select Enabled.

DirectAccess Reporting Fails after Disabling TLS 1.0

If using Active Directory GPO, ensure that the GPO is applied all DirectAccess servers in the organization. A restart is not required for this setting to take effect. Once this change has been made, reporting should work as expected.

Additional Resources

DirectAccess IP-HTTPS SSL and TLS Insecure Cipher Suites
DirectAccess Video Training Courses on Pluralsight
Implementing DirectAccess with Windows Server 2016 Book on Amazon.com