Renew DirectAccess Self-Signed Certificates

Renew DirectAccess Self-Signed CertificatesImportant! Updated July 15, 2019 to support all versions of Windows Server including Windows Server 2012 and 2012 R2. Also added functionality to renew self-signed certificates individually.

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 and NLS scripts above are executed, DirectAccess clients outside will be immediately disconnected and will be unable to reconnect until they update group policy (the RADIUS encryption certificate can be updated without impacting users). This will require connecting to the internal network locally or remotely using another VPN solution. 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

 

 

Always On VPN and DirectAccess Scripts and Sample Files on GitHub

Always On VPN and DirectAccess Scripts and Sample Files on GitHubIf you’re looking for specialized configuration scripts for Windows 10 Always On VPN, Windows Server Routing and Remote Access Service (RRAS), or DirectAccess then have a look at my GitHub page! There I’ve uploaded a few tools I’ve created (with the help of my good friend Jeff Hicks!) along with some sample ProfileXML files. Here’s a sample of what you’ll find there today.

Always On VPN

This repository includes PowerShell scripts and sample ProfileXML files used for configuring Windows 10 Always On VPN. These scripts have been adopted from those provided by Microsoft and modified to work with a separate XML file. These scripts can be used for local testing and for deploying Always On VPN connections using System Center Configuration Manager (SCCM). The ProfileXML files can be helpful for those administrators looking for real world configuration examples.

https://github.com/richardhicks/aovpn

SstpOffload

This repository includes a PowerShell script to enable TLS offload for Windows Server RRAS Secure Socket Tunneling Protocol (SSTP) VPN connections when the public SSL certificate can’t be installed on the RRAS server. TLS offload for SSTP can be enabled in scenarios where better security, performance, and scalability are desired.

https://github.com/richardhicks/sstpoffload

DirectAccess

This repository includes the PowerShell script Move-DaInboxAccountingDatabase which can be used to move the DirectAccess inbox accounting database files. The default location of the database files is on the C: drive, and many administrators have encountered disk space issues, especially in large scale deployments. This script will relocate the database files to the location of your choice.

https://github.com/richardhicks/directaccess

More to Come!

Be sure to check my GitHub site for more PowerShell script and sample files on a regular basis. Or better yet, give me a follow! I’ll be sure to post more as time goes on. In addition, I’ll be going through my older articles where I’ve provided PowerShell code samples and will include them in the repository too.

Standard Disclaimer

All the sample files and PowerShell scripts I’ve shared on GitHub are provided as-is. Although they’ve been thoroughly tested, I can’t be certain I’ve accommodated every deployment scenario. Please use caution when running these scripts on production machines.

Additional Information

Always On VPN Hands-On Training Classes 2019

Jeff Hicks’ Blog

DirectAccess IP-HTTPS Not Working Properly in Windows Server 2019

After installing and configuring DirectAccess in Windows Server 2019 you may encounter an error message indicating that IP-HTTPS is not working properly. Looking at the Operations Status overview in the Dashboard of the Remote Access Management console shows that the IP-HTTPS interface is in error.

DirectAccess IP-HTTPS Not Working Properly in Windows Server 2019

IP-HTTPS Route Error

Viewing the detailed Operations Status shows the following error message.

Error: The IP-HTTPS route does not have published property enabled.

DirectAccess IP-HTTPS Not Working Properly in Windows Server 2019

Missing Route

Looking at the routing table on the DirectAccess server reveals that a route to the client IPv6 prefix is indeed missing.

DirectAccess IP-HTTPS Not Working Properly in Windows Server 2019

Resolution

To resolve this error message, add the client IPv6 route to the DirectAccess server’s routing table and publish it. This is accomplished by running the following PowerShell commands on the DirectAccess server.

$IPv6prefix = (Get-RemoteAccess).ClientIPv6Prefix
New-NetRoute -AddressFamily IPv6 -DestinationPrefix $IPv6prefix -InterfaceAlias “Microsoft IP-HTTPS Platform Interface” -Publish Yes

Next, restart the Remote Access Management service (RaMgmtSvc) using the following PowerShell command.

Restart-Service RaMgmtSvc -PassThru

DirectAccess IP-HTTPS Not Working Properly in Windows Server 2019

Once complete, refresh the management console and the IP-HTTPS error message should be resolved and the operations status should state that it is now working properly.

DirectAccess IP-HTTPS Not Working Properly in Windows Server 2019

 

Additional Information

SSL Certificate Conisderations for DirectAccess IP-HTTPS

DirectAccess Expire IP-HTTPS Certificate and Error 0x800b0101

Comparing DirectAccess and NetMotion Mobility – Australia and New Zealand

Australia and New Zealand! Comparing DirectAccess and NetMotion Mobility free live webinar Thursday, November 29 at 10:00AM AEDT. Register here!

DirectAccess on Windows Server 2016 CoreFor many years, DirectAccess has been the gold standard for enterprise remote access. Its seamless and transparent operation improves productivity for mobile workers, and since it is always on, administrators enjoy improved visibility and management for their field-based assets.

As incredible as DirectAccess is, it is not without its limitations. For example, DirectAccess works only with Windows Enterprise edition clients that are joined to the domain. Professional Edition and non-domain joined machines are not supported. It also lacks many of the security features enterprise organizations require, such as device health checks and granular network access. In addition, DirectAccess communication is complex, with many different layers of encapsulation, authentication, and encryption. High protocol overhead can lead to poor performance over high latency or low bandwidth connections.

NetMotion Mobility as an Alternative to DirectAccessNetMotion Mobility is a secure remote access solution that is an excellent alternative to DirectAccess. It provides the same seamless, transparent, always on remote connectivity that DirectAccess provides, while at the same time offering much more in terms of features and capabilities. It supports a much broader range of clients, includes native Network Access Control (NAC) and application filtering, and offers enhanced performance.

To learn more about NetMotion Mobility, join me on Thursday, November 29 at 10:00AM AEDT (UTC +11) for a free live webinar with NetMotion. I’ll provide an overview of NetMotion Mobility and how it compares with DirectAccess. I’ll also demonstrate how it can help overcome some of the inherent limitations of DirectAccess too. Register today!

DirectAccess and NetMotion Mobility Webinar

DirectAccess Get-NetIPHttpsState Fails on Windows 10 1803

DirectAccess Get-NetIPHttpsState Fails on Windows 10 1803PowerShell is an essential tool for Windows administrators for configuration, task automation, monitoring, reporting, and problem resolution. When troubleshooting DirectAccess connectivity using the IP-HTTPS IPv6 transition technology, the Get-NetIPHttpsConfiguration and Get-NetIPHttpsState PowerShell commands are important for assessing the configuration and current state of the IP-HTTPS connection. When DirectAccess connectivity fails, these are some of the first commands an administrator will use to identify and resolve the issue.

Get-NetIPHttpsState

Get-NetIPHttpsState is especially helpful when IP-HTTPS connectivity fails because it returns an error code and interface status information that can provide clues as to why the connection was not completed successfully.

DirectAccess Get-NetIPHttpsState Fails on Windows 10 1803

No Output in 1803

Beginning with Windows 10 1803, the DirectAccess administrator will notice that Get-NetIPHttpsState returns no data. The output of Get-NetIPHttpsState is blank.

DirectAccess Get-NetIPHttpsState Fails on Windows 10 1803

Changes in 1803

As it turns out, this is a bug first introduced in Windows 10 1803 that is the result of a fundamental change in the way in which the IP-HTTPS interface is implemented in Windows. As of this writing, the bug has not been addressed in Windows 10 1803 or 1809.

Workaround

The good news is that there’s an easy workaround for this. Instead of using Get-NetIPHttpsState, the administrator can retrieve essential information about the IP-HTTPS interface using the following netsh command.

netsh interface httpstunnel show interface

DirectAccess Get-NetIPHttpsState Fails on Windows 10 1803

Additional Information

SSL Certificate Considerations for DirectAccess IP-HTTPS 

Troubleshooting DirectAccess IP-HTTPS Error Code 0x800b0109

Troubleshooting DirectAccess IP-HTTPS Error Code 0x80090326

Troubleshooting DirectAccess IP-HTTPS Error Code 0x90320

Troubleshooting DirectAccess IP-HTTPS Error Code 0x2af9

Troubleshooting DirectAccess IP-HTTPS Error Code 0x800b0101

Always On VPN Device Tunnel Missing in Windows 10 UI

Always On VPN Device Tunnel Missing in Windows 10 UIUnlike DirectAccess, Always On VPN connections are provisioned to the user, not the machine. Beginning with Windows 10 release 1709 Microsoft introduced the device tunnel option to provide feature parity with DirectAccess. The device tunnel provides pre-logon network connectivity to support important deployment scenarios such as logging on without cached credentials and unattended remote systems management.

Device Tunnel Configuration

Guidance for creating and deploying a device tunnel connection can be found here. It’s important to note that the device tunnel is always on by default. Also, there can only be a single device tunnel configured per device. You must remove an existing device tunnel before configuring a new one.

Known Issues

After configuring a Windows 10 Always On VPN device tunnel the administrator may notice two anomalies. First, the device tunnel is missing in the Windows UI after it is created. Second, viewing the status of the device tunnel connection using PowerShell indicates the connection is “disconnected” even though it is connected.

Device Tunnel Missing

As you can see below, event though both a device and user tunnel have been provisioned, the Windows UI reports only a single Always On VPN connection, that being the user connection.

Always On VPN Device Tunnel Missing in Windows 10 UI

However, the device tunnel does appear in the Network Connections control panel applet (ncpa.cpl), as shown here.

Always On VPN Device Tunnel Missing in Windows 10 UI

This is expected and by design. The device tunnel is not displayed to the user in the Windows UI as it is provisioned to the machine, not the user. It appears on the Control Panel because the applet is capable of enumerating both user and system connections.

Device Tunnel Disconnected

The status of the Windows 10 Always On VPN device tunnel connection can be viewed by running the Get-VpnConnection -AllUserConnection PowerShell command. However, at the time of this writing, PowerShell always reports the connection status as “Disconnected”. This appears to be a bug; one which Microsoft is hopefully working to address.

Always On VPN Device Tunnel Missing in Windows 10 UI

Summary

The Windows 10 Always On VPN device tunnel option allows administrators to enable scenarios previously supported with DirectAccess, including logging on without cached credentials and unattended remote support. Not all deployments require a device tunnel, but it is an important option available to administrators to address specific use cases.

Additional Information

Windows 10 Always On VPN Device Tunnel Configuration using PowerShell

Windows 10 Always On VPN RasMan Device Tunnel Failure

Deleting a Windows 10 Always On VPN Device Tunnel

 

Comparing DirectAccess and NetMotion Mobility Webinar – October 2018

CORRECTION: This webinar will take place 14:00 BST on Thursday, 25 October.

DirectAccess on Windows Server 2016 CoreFor many years, DirectAccess has been the gold standard for enterprise remote access. Its seamless and transparent operation improves productivity for mobile workers, and since it is always on, administrators enjoy improved visibility and management for their field-based assets.

As incredible as DirectAccess is, it is not without its limitations. For example, DirectAccess works only with Windows Enterprise edition clients that are joined to the domain. Professional Edition and non-domain joined machines are not supported. It also lacks many of the security features enterprise organizations require, such as device health checks and granular network access. In addition, DirectAccess communication is complex, with many different layers of encapsulation, authentication, and encryption. High protocol overhead can lead to poor performance over high latency or low bandwidth connections.

NetMotion Mobility as an Alternative to DirectAccessNetMotion Mobility is a secure remote access solution that is an excellent alternative to DirectAccess. It provides the same seamless, transparent, always on remote connectivity that DirectAccess provides, while at the same time offering much more in terms of features and capabilities. It supports a much broader range of clients, includes native Network Access Control (NAC) and application filtering, and offers enhanced performance.

To learn more about NetMotion Mobility, join me on Thursday, 25 October at 14:00 BST for a free live webinar with NetMotion. I’ll provide an overview of NetMotion Mobility and how it compares with DirectAccess. I’ll also demonstrate how it can help overcome some of the inherent limitations of DirectAccess too. Register today!

DirectAccess and NetMotion Mobility Webinar

Comparing DirectAccess and NetMotion Mobility

Comparing DirectAccess and NetMotion Mobility With DirectAccess approaching the end of its useful lifetime, many organizations are considering alternative solutions to provide seamless, transparent, always on remote connectivity for their field-based workers. Microsoft is positioning Windows 10 Always On VPN as the replacement for DirectAccess. While it provides many new features that were missing from DirectAccess, it has its own unique limitations and shortcomings.

NetMotion Mobility Purpose-Built Enterprise VPN

NetMotion Mobility Purpose-Built Enterprise VPN Advanced Features

NetMotion Mobility

Comparing DirectAccess and NetMotion Mobility NetMotion Mobility is an excellent alternative to DirectAccess and Always On VPN, and it has many advantages over both native Microsoft offerings. NetMotion Mobility offers better security and performance. It provides deep visibility with broad client support, and the solution is easier to support than DirectAccess.

Comparing DirectAccess and NetMotion Mobility

If you’d like to learn more about how NetMotion Mobility compares with DirectAccess, you will find detailed comparison information in my Comparing NetMotion Mobility and DirectAccess article series on the NetMotion blog.

Comparing NetMotion Mobility and DirectAccess – Security
Comparing NetMotion Mobility and DirectAccess – Performance
Comparing NetMotion Mobility and DirectAccess – Visibility
Comparing NetMotion Mobility and DirectAccess – Supported Clients
Comparing NetMotion Mobility and DirectAccess – Support

NetMotion Mobility in Action

Watch the following videos to see NetMotion Mobility in action.

NetMotion Mobility Demonstration Video
NetMotion Mobility and Skype for Business Demonstration Video

DirectAccess Alternative

NetMotion Mobility is a premium remote access solution with many of the same characteristics as DirectAccess; seamless, transparent, and always on. It is feature rich with numerous compelling benefits over native Microsoft remote access technologies. Organizations seeking a solution to replace Microsoft DirectAccess would benefit greatly from NetMotion Mobility.

Learn More

If you’d like to learn more about NetMotion Mobility, or if you’d like to evaluate their solution, fill out the form below and I’ll respond with more information.

 

Deploying Windows 10 Always On VPN with Microsoft Intune

Deploying Windows 10 Always On VPN with Microsoft IntuneWindows 10 Always On VPN is the replacement for Microsoft’s popular DirectAccess remote access solution. It provides the same seamless, transparent, always on remote connectivity as DirectAccess. Where DirectAccess relied heavily on classic on-premises infrastructure such as Active Directory and Group Policy, Always On VPN is infrastructure independent and is designed to be provisioned and managed using a Mobile Device Management (MDM) platform such as Microsoft Intune.

Intune and Always On VPN

Until recently, provisioning Windows 10 Always On VPN connections involved manually creating a ProfileXML and uploading to Intune using a custom profile. This has proven to be challenging for many, as the process is unintuitive and error prone.

A recent Intune update now allows administrators to create a basic Windows 10 Always On VPN deployment. Although it still has its limitations, it will go a long way to making the adoption of Always On VPN easier.

Prerequisites

Certificates must first be provisioned to all clients before deploying Windows 10 Always On VPN using Intune. In addition, if using a third-party VPN client, the VPN plug-in software must be installed prior to deploying the VPN profile.

Test VPN Connection

It is recommended that a test VPN connection be created on a client machine locally before deploying an Always On VPN profile using Intune. This allows the administrator to test connectivity and validate Extensible Authentication Protocol (EAP) settings. Once complete, run the following PowerShell commands to extract the EAP configuration settings to a file for later publishing with Intune.

$Vpn = Get-VpnConnection -Name [Test VPN connection name]
$Xml = $Vpn.EapConfigXmlStream.InnerXml | Out-File .\eapconfig.xml -Encoding ASCII

Deploying Always On VPN with Intune

Follow the steps below to deploy an Always On VPN connection using Intune.

Create a VPN Profile

  1. Open the Microsoft Intune management portal.
  2. Click Device configuration.
  3. Click Profiles.
  4. Click Create profile.

Deploying Windows 10 Always On VPN with Microsoft Intune

  1. Enter a name for the VPN profile.
  2. Enter a description (optional).
  3. From the Platform drop-down menu select Windows 10 and later.
  4. From the Profile type drop-down menu select VPN.
  5. In the Settings section click Configure.

Deploying Windows 10 Always On VPN with Microsoft Intune

Define VPN Profile Settings

  1. Click Base VPN.
  2. Enter a name for the connection.
  3. Enter a description and provide the Fully Qualified Domain Name (FQDN) of the VPN server. If it will be the default server select True and click Add.
  4. Enter a description and provide the FQDN for any additional VPN servers, as required.
  5. From the Connection type drop-down list choose the preferred connection type.
  6. In the Always On section click Enable.
  7. Select Enable to Remember credentials at each logon (optional).
  8. Click Select a certificate.
  9. Choose a client authentication certificate and click Ok.
  10. Paste the contents of eapconfig.xml (saved previously) in the EAP Xml field.
  11. Click Ok.

Deploying Windows 10 Always On VPN with Microsoft Intune

Define Additional Settings

You can also configure the following optional VPN settings using Intune.

  • Apps and Traffic Rules
  • Conditional Access
  • DNS Settings
  • Proxy
  • Split Tunneling

Deploying Windows 10 Always On VPN with Microsoft Intune

After configuring any required additional settings, click Create.

Assign VPN Profile

  1. Click Assignments.
  2. From the Assign to drop-down menu choose Selected Groups.
  3. Click Select groups to include.
  4. Choose an Azure Active Directory group to apply the VPN profile and click Select.
  5. Click Save.

Deploying Windows 10 Always On VPN with Microsoft Intune

Limitations

Although the ability to provision Always On VPN using Microsoft Intune without using a custom profile is welcome, it is not without its limitations. At the time of this writing, only Always On VPN user profiles can be configured. A device tunnel, which is optional, must be configured manually using a custom profile. In addition, the Intune user interface lacks the ability to define settings for the following parameters:

  • Custom IKEv2 cryptography policy
  • Exclusion routes
  • Lockdown mode

To make changes to the default settings for any of the above parameters, a ProfileXML must be created manually and provisioned with Intune using a custom policy.

Additional Information

Windows 10 Always On VPN Device Tunnel Step-by-Step Configuration using PowerShell

Windows 10 Always On VPN Certificate Requirements for IKEv2

Windows 10 Always On VPN and the Name Resolution Policy Table (NRPT)

Windows 10 Always On VPN Hands-On Training

 

DirectAccess Selective Tunneling

DirectAccess Selective TunnelingDirectAccess administrators, and network administrators in general, are likely familiar with the terms “split tunneling” and “force tunneling”. They dictate how traffic is handled when a DirectAccess (or VPN) connection is established by a client. Split tunneling routes only traffic destined for the internal network over the DirectAccess connection; all other traffic is routed directly over the Internet. Force tunneling routes all traffic over the DirectAccess connection.

Force Tunneling

DirectAccess uses split tunneling by default. Optionally, it can be configured to use force tunneling if required. Force tunneling is commonly enabled when DirectAccess administrators want to inspect and monitor Internet traffic from field-based clients.

Note: One-time password user authentication is not supported when force tunneling is enabled. Details here.

Drawbacks

Force tunneling is not without its drawbacks. It requires that an on-premises proxy server be used by DirectAccess clients to access the Internet, in most cases. In addition, the user experience is often poor when force tunneling is enabled. This is caused by routing Internet traffic, which is commonly encrypted, over an already encrypted connection. The added protocol overhead caused by double encryption (triple encryption if you are using Windows 7!) along with using a sub-optimal network path increases latency and can degrade performance significantly. Also, location-based services typically fail to work correctly.

Selective Tunneling

“Selective Tunneling” is a term that I commonly use to describe a configuration where only one or a few specific public resources are tunneled over the DirectAccess connection. A common use case is where access to a cloud-based application is restricted to the IP address of a corporate proxy or firewall.

Using the Name Resolution Policy Table (NRPT) and taking advantage of DirectAccess and its requirement for IPv6, DirectAccess administrators can choose to selectively route requests for public hosts or domains over the DirectAccess connection. The process involves defining the public Fully Qualified Domain Name (FQDN) as “internal” in the DirectAccess configuration and then assigning an on-premises proxy server for DirectAccess clients to use to access that namespace.

Enable Selective Tunneling

While some of the selective tunneling configuration can be performed using the Remote Access Management console, some of it can only be done using PowerShell. For this reason, I prefer to do everything in PowerShell to streamline the process.

Run the following PowerShell commands on the DirectAccess server to enable selective tunneling for the “.example.com” domain.

$namespace = “.example.com” # include preceding dot for namespace, omit for individual host
$dnsserver = Get-ItemPropertyValue –Path HKLM:\\SYSTEM\CurrentControlSet\Services\RaMgmtSvc\Config\Parameters -Name DnsServers

Add-DAClientDnsConfiguration -DnsSuffix $namespace -DnsIpAddress $dnsserver -PassThru

$gpo = (Get-RemoteAccess).ClientGpoName
$gpo = $gpo.Split(‘\’)[1]
$proxy = “proxy.corp.example.net:8080” # this is the FQDN and port for the internal proxy server
$rule = (Get-DnsClientNrptRule -GpoName $gpo | Where-Object Namespace -eq $namespace | Select-Object -ExpandProperty “Name”)

Set-DnsClientNrptRule -DAEnable $true -DAProxyServerName $proxy -DAProxyType “UseProxyName” -Name $rule -GpoName $gpo

If Windows 7 client support has been enabled, run the following PowerShell commands on the DirectAccess server. If multisite is enabled, run these commands on one DirectAccess server in each entry point.

$downlevelgpo = (Get-RemoteAccess).DownlevelGpoName
$downlevelgpo = $downlevelgpo.Split(‘\’)[1]
$proxy = “proxy.corp.example.net:8080” # this is the FQDN and port for the internal proxy server
$downlevelrule = (Get-DnsClientNrptRule -GpoName $downlevelgpo | Where-Object Namespace -eq $namespace | Select-Object -ExpandProperty “Name”)

Set-DnsClientNrptRule -DAEnable $true -DAProxyServerName $proxy -DAProxyType “UseProxyName” -Name $downlevelrule -GpoName $downlevelgpo

To remove a namespace from the NRPT, run the following PowerShell command.

Remove-DAClientDnsConfiguration -DnsSuffix $namespace

Caveats

While selective tunneling works well for the most part, the real drawback is that only Microsoft browsers (Internet Explorer and Edge) are supported. Web sites configured for selective tunneling will not be reachable when using Chrome, Firefox, or any other third-party web browser. In addition, many web sites deliver content using more than one FQDN, which may cause some web pages to load improperly.

Additional Resources

DirectAccess Force Tunneling and Proxy Server Configuration

NetMotion Mobility for DirectAccess Administrators – Split vs. Force Tunneling

%d bloggers like this: