Renew DirectAccess Self-Signed Certificates

Renew DirectAccess Self-Signed CertificatesImportant! Updated April 29, 2020 to resolve an issue where the DirectAccess RADIUS encryption certificate was not published to the DirectAccess Server Settings GPO in Active Directory.

When DirectAccess is deployed using the Getting Started Wizard (GSW), sometimes referred to as the “simplified deployment” method, self-signed certificates are created during the installation and used for the IP-HTTPS IPv6 transition technology, the Network Location Server (NLS), and for RADIUS secret encryption. Administrators may also selectively choose to use self-signed certificates for IP-HTTPS, or when collocating the NLS on the DirectAccess server. The RADIUS encryption certificate is always self-signed.

Renew DirectAccess Self-Signed Certificates

Certificate Expiration

These self-signed certificates expire 5 years after they are created, which means many DirectAccess administrators who have used this deployment option will need to renew these certificates at some point in the future. Unfortunately, there’s no published guidance from Microsoft on how to accomplish this. However, the process is simple enough using PowerShell and the New-SelfSignedCertificate cmdlet.

PowerShell Script on GitHub

The PowerShell script to renew DirectAccess self-signed certificates has been published on GitHub. You can download Renew-DaSelfSignedCertificates.ps1 here.

Important Considerations

When the IP-HTTPS certificate is renewed using this script, DirectAccess clients outside will be immediately disconnected and will be unable to reconnect until they update group policy. This will require connecting to the internal network locally or remotely using another VPN solution. The NLS and RADIUS encryption certificates can be updated without impacting remote users.

In addition, internal clients that are not online when this change is made will be unable to access internal resources by name until they update group policy. If this happens, delete the Name Resolution Policy Table (NRPT) on the client using the following PowerShell command and reboot to restore connectivity.

Get-Item -Path “HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient\DnsPolicyConfig” | Remove-Item -Confirm:$false

Additional Information

PowerShell Recommended Reading for DirectAccess Administrators

Top 5 DirectAccess Troubleshooting PowerShell Commands

 

 

NetMotion Mobility for DirectAccess Administrators – Trusted Network Detection

NetMotion Mobility for DirectAccess Administrators – Trusted Network DetectionDirectAccess clients use the Network Location Server (NLS) for trusted network detection. If the NLS can be reached, the client will assume it is on the internal network and the DirectAccess connection will not be made. If the NLS cannot be reached, the client will assume it is outside the network and it will then attempt to establish a connection to the DirectAccess server.

Critical Infrastructure

DirectAccess NLS availability and reachability is crucial to ensuring uninterrupted operation for DirectAccess clients on the internal network. If the NLS is offline or unreachable for any reason, DirectAccess clients on the internal network will be unable to access internal resources by name until the NLS is once again available. To ensure reliable NLS operation and to avoid potential disruption, the NLS should be highly available and geographically redundant. Close attention must be paid to NLS SSL certificate expiration dates too.

NetMotion Mobility

NetMotion Mobility does not require additional infrastructure for inside/outside detection as DirectAccess does. Instead, Mobility clients determine their network location by the IP address of the Mobility server they are connected to.

Unlike DirectAccess, NetMotion Mobility clients will connect to the Mobility server whenever it is reachable, even if they are on the internal network. There are some advantages to this, but if this behavior isn’t desired, a policy can be created that effectively replicates DirectAccess client behavior by bypassing the Mobility client when the client is on the internal network.

Configuring Trusted Network Detection

Follow the steps below to create a policy to enable trusted network detection for NetMotion Mobility clients.

Create a Rule Set

  1. From the drop-down menu in the NetMotion Mobility management console click Policy and then Policy Management.
  2. Click New.
  3. Enter a descriptive name for the new rule set.
  4. Click Ok.

NetMotion Mobility for DirectAccess Administrators – Trusted Network Detection

Create a Rule

  1. Click New.
  2. Enter a descriptive name for the new rule.
  3. Click Ok.

NetMotion Mobility for DirectAccess Administrators – Trusted Network Detection

Define a Condition

  1. Click on the Conditions tab.
  2. In the Addresses section check the box next to When the Mobility server address is address.
    NetMotion Mobility for DirectAccess Administrators – Trusted Network Detection
  3. In the Policy rule definition section click the equal to address(es) (v9.0) link.
    NetMotion Mobility for DirectAccess Administrators – Trusted Network Detection
  4. Click Add.
  5. Select Mobility server address.
  6. Select the IP address assigned to the Mobility server’s internal network interface.
  7. Click Ok.
  8. Click Ok.

NetMotion Mobility for DirectAccess Administrators – Trusted Network Detection

Define an Action

  1. Click on the Actions tab.
  2. In the Passthrough Mode section check the box next to Enable/disable passthrough mode.
    NetMotion Mobility for DirectAccess Administrators – Trusted Network Detection
  3. Click Save.
  4. Click Save.

Assign the Policy

  1. Click on the Subscribers tab.
  2. Choose a group to assign the policy to. This can be users, groups, devices, etc.
    NetMotion Mobility for DirectAccess Administrators – Trusted Network Detection
  3. Click Subscribe.
  4. Select the Trusted Network Detection policy.
  5. Click Ok.

NetMotion Mobility for DirectAccess Administrators – Trusted Network Detection

Validation Testing

The NetMotion Mobility client will connect normally when the client is outside of the network. However, if the Mobility client detects that it is connected to the internal interface of the Mobility server, all network traffic will bypass the Mobility client.

NetMotion Mobility for DirectAccess Administrators – Trusted Network Detection

Summary

Trusted network detection can be used to control client behavior based on their network location. Many administrators prefer that connections only be made when clients are outside the network. DirectAccess clients use the NLS to determine network location and will not establish a DirectAccess connection if the NLS is reachable.

NetMotion Mobility trusted network detection relies on detecting the IP address of the Mobility server to which the connection was made. This is more elegant and effective than the DirectAccess NLS, and more reliable too.

Additional Information

Enabling Secure Remote Administrator for the NetMotion Mobility Management Console

NetMotion Mobility Device Tunnel Configuration

Deploying NetMotion Mobility in Azure

3 Important Advantages of Always On VPN over DirectAccess

3 Important Advantages of Always On VPN over DirectAccess Windows 10 Always On VPN hands-on training classes now forming. Details here.

Windows 10 Always On VPN provides seamless and transparent, always on remote network access similar to DirectAccess. The mechanics of how it is delivered and managed are fundamentally different, as I discussed here. Some of these changes will no doubt present challenges to our way of thinking, especially in the terms of client provisioning. However, Always On VPN brings along with it some important and significant advantages too.

No More NLS

A Network Location Server (NLS) is used for inside/outside detection by DirectAccess clients. By design, the NLS is reachable by DirectAccess machines only when they are on the internal network. NLS availability is crucial. If the NLS is offline or unreachable for any reason at all, DirectAccess clients on the internal network will mistakenly believe they are outside the network. In this scenario, the client will attempt to establish a DirectAccess connection even though it is inside. This often fails, leaving the DirectAccess client in a state where it cannot connect to any internal resources by name until the NLS is brought back online.

Always On VPN eliminates the frailty of NLS by using the DNS connection suffix for trusted network detection. When a network connection is established, an Always On VPN connection will not be established if the DNS connection suffix matches what the administrator has defined as the internal trusted network.

Full Support for IPv4

DirectAccess uses IPv6 exclusively for communication between remote DirectAccess clients and the DirectAccess server. IPv6 translation technologies allow for communication to internal IPv4 hosts. While this works for the vast majority of scenarios, there are still many challenges with applications that do not support IPv6.

Always On VPN supports both IPv4 and IPv6, so application incompatibility issues will be a thing of the past! With full support for IPv4, the need for IPv6 transition and translation technologies is eliminated. This reduces protocol overhead and improves network performance.

Infrastructure Independent

3 Important Advantages of Always On VPN over DirectAccess Windows servers are required to implement DirectAccess. Always On VPN can be implemented using Windows servers as well, but it isn’t a hard requirement. Always On VPN is implemented entirely on the Windows 10 client, which means any third-party VPN device can be used on the back end, including Cisco, Checkpoint, Juniper, Palo Alto, Fortinet, SonicWALL, F5, strongSwan, and others! This provides tremendous deployment flexibility, making it possible to mix and match backend infrastructure if required. For example, a Windows RRAS VPN server with Palo Alto and SonicWALL firewalls could all be implemented at the same time (using the Windows built-in VPN client). Importantly, making changes to VPN infrastructure is much less impactful and disruptive to clients in the field. VPN devices can be upgraded, replaced, and moved internally without requiring corresponding policy changes on the client.

Additional Information

Always On VPN and the Future of Microsoft DirectAccess 

5 Things DirectAccess Administrators Should Know about Always On VPN 

Contact Me

Have questions about Windows 10 Always On VPN? Interested in learning more about this new solution? Fill out the form below and I’ll get in touch with you.

%d bloggers like this: