DirectAccess WinRM Conflicts and Errors

Introduction

When installing DirectAccess for the first time, an administrator may encounter the following error message while running the Remote Access Setup wizard.

Error. The client cannot connect to the destination specified in the request. Verify that the service on the destination is running and is accepting requests. Consult the logs and documentation for the WS-Management service running on the destination, most commonly IIS or WinRM. If the destination is the WinRM service, run the following command on the destination to analyze and configure the WinRM service: “winrm quickconfig”.

DirectAccess WinRM Conflicts and Errors

Troubleshooting

Running winrm quickconfig in an elevated PowerShell command window returns the following message.

WinRM service is already running on this machine.
WinRM is already set up for remote management on this computer.

DirectAccess WinRM Conflicts and Errors

Clicking Check prerequisites again does not resolve the error message.

Post-Installation Errors

If DirectAccess is already installed and working properly, an administrator may encounter a scenario in which the operations status page displays nothing, yet remote DirectAccess clients are connected and able to access corporate resources without issue.

DirectAccess WinRM Conflicts and Errors

In addition, clicking Edit on Step 2 in the Remote Access Management console and choosing Network Adapters produces an error message stating “An error occurred when validating interfaces”. You can select a network adapter from the drop-down list, but the Next and Finish buttons are grayed out.

DirectAccess WinRM Conflicts and Errors

Conflicts with WinRM

These errors are commonly caused by a conflict with WinRM Service settings enforced via Active Directory group policy. To confirm this, open an elevated PowerShell command window run the winrm enumerate winrm/config/listener command. The listener configuration source will be listed as GPO.

DirectAccess WinRM Conflicts and Errors

The administrator will also find the presence of the following registry keys on the DirectAccess server.

HKLM\Software\Policies\Microsoft\Windows\WinRM\Service\AllowAutoConfig
HKLM\Software\Policies\Microsoft\Windows\WinRM\Service\IPv4Filter
HKLM\Software\Policies\Microsoft\Windows\WinRM\Service\IPv6Filter

Resolution

To resolve this conflict, prevent the GPO with this setting from being applied to the DirectAccess server(s). You will find this GPO setting in the Group Policy Management console (GPMC) by navigating to Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Windows Remote Management (WinRM) -> WinRM Service and setting the state of Allow remote server management through WinRM to Not configured.

DirectAccess WinRM Conflicts and Errors

Additional Resources

DirectAccess and Windows 10 Better Together

DirectAccess and Windows 10 in Education

VIDEO – DirectAccess and Windows 10 in Action 

BOOK – Implementing DirectAccess with Windows Server 2016

DirectAccess IP-HTTPS Error 0x2af9

When troubleshooting DirectAccess client connectivity issues, you may encounter a scenario where clients are unable to connect using the IP-HTTPS IPv6 transition technology. Running ipconfig shows that the tunnel adapter IPHTTPSInterface media state is Media disconnected.

DirectAccess IP-HTTPS Error 0x2af9

Running the Get-NetIpHttpsState PowerShell command shows that the LastErrorCode is 0x2af9 (WSAHOST_NOT_FOUND) and the InterfaceStatus is Failed to connect to the IPHTTPS server; waiting to reconnect.

DirectAccess IP-HTTPS Error 0x2af9

The 0x2af9 error differs slightly from the more common 0x274c IP-HTTPS connection time out error (WSAETIMEDOUT). In this scenario the DirectAccess client can successfully resolve the DirectAccess public hostname to an IPv4 address, and if ICMP echo requests are allowed on the DirectAccess server’s public IPv4 address it will respond to ping.

DirectAccess IP-HTTPS Error 0x2af9

The DirectAccess client is also able to establish a TCP connection to the DirectAccess server using the Test-NetConnection PowerShell command.

DirectAccess IP-HTTPS Error 0x2af9

So, why is the IP-HTTPS interface unable to establish a transition tunnel connection when the DirectAccess server’s public hostname resolves correctly via DNS and the client can establish a TCP connection on port 443? Commonly this is caused by proxy server settings configured in the web browser on the DirectAccess client computer. Disabling the proxy server in the client’s web browser should restore DirectAccess client connectivity over IP-HTTPS.

DirectAccess IP-HTTPS Error 0x2af9

If clearing the proxy server settings in the client machine’s web browser still does not restore IP-HTTPS connectivity, it may be that a proxy server is also configured for winhttp. You can confirm this by opening an elevated PowerShell command window and running the netsh winhttp show proxy command.

DirectAccess IP-HTTPS Error 0x2af9

To clear the winhttp proxy server settings run the netsh winhttp reset proxy command.

DirectAccess IP-HTTPS Error 0x2af9

Additional Resources

DirectAccess Expired IP-HTTPS Certificate and Error 0x800b0101

DirectAccess IP-HTTPS Preauthentication

DirectAccess SSL Offload and IP-HTTPS Preauthentication with Citrix NetScaler

DirectAccess SSL Offload using F5 BIG-IP

DirectAccess IP-HTTPS Preauthentication with F5 BIG-IP

DirectAccess and Multi-SAN SSL Certificates for IP-HTTPS

Implementing DirectAccess with Windows Server 2016 Book

 

DirectAccess SSL Offload and IP-HTTPS Preauthentication with Citrix NetScaler

Introduction

Communication between the DirectAccess client and server takes place exclusively over IPv6. When DirectAccess servers and/or clients are on the IPv4 Internet, an IPv6 transition technology must be employed to allow those clients to connect to the DirectAccess server. DirectAccess deployment best practices dictate that only the IP-HTTPS IPv6 transition technology be used. IP-HTTPS uses SSL/TLS for server authentication and optionally encryption. To improve security and performance for IP-HTTPS, an Application Delivery Controller (ADC) like the Citrix NetScaler can be configured to perform SSL offloading and client preauthentication for DirectAccess IP-HTTPS connections.

Please note that the following caveats apply when enabling SSL offload for DirectAccess clients:

  • Enabling SSL offload and IP-HTTPS preauthentication on an ADC for DirectAccess is formally unsupported by Microsoft.
  • SSL offload should not be enabled with DirectAccess is configured to use one-time password (OTP) authentication. Offloading SSL will break OTP functionality.

IP-HTTPS Challenges

The IP-HTTPS IPv6 transition technology is a simple and effective way to allow DirectAccess clients and servers to communicate by encapsulating IPv6 traffic in HTTP and routing it over the public IPv4 Internet. However, there are two critical issues with the default implementation of IP-HTTPS in DirectAccess. One is a security issue, the other affects performance.

Security

The DirectAccess server does not authenticate clients establishing IP-HTTPS connections. This could allow an unauthorized client to obtain an IPv6 address from the DirectAccess server using the IPv6 Neighbor Discovery (ND) process. With a valid IPv6 address, the unauthorized user could perform internal network reconnaissance or launch a variety of Denial of Service (DoS) attacks on the DirectAccess infrastructure and connected clients. More details here.

Performance

Windows 7 DirectAccess clients use encrypted cipher suites when establishing IP-HTTPS connections. However, the payload being transported is already encrypted using IPsec. This double encryption increases resource utilization on the DirectAccess server, reducing performance and limiting scalability. More details here.


Note: Beginning with Windows Server 2012 and Windows 8, Microsoft introduced support for null encryption for IP-HTTPS connections. This eliminates the needless double encryption, greatly improving scalability and performance for DirectAccess clients using IP-HTTPS.


SSL Offload for DirectAccess IP-HTTPS

The Citrix NetScaler can be configured to perform SSL offload to improve performance for Windows 7 DirectAccess clients using IP-HTTPS. Since DirectAccess does not natively support SSL offload, the NetScaler must be configured in a non-traditional way. While the NetScaler will be configured to terminate incoming IP-HTTPS SSL connections, it must also use SSL for the back-end connection to the DirectAccess server. However, the NetScaler will be configured only to use null cipher suites when connecting to the DirectAccess server. Even though Windows 7 clients will still perform double encryption to the NetScaler, this configuration effectively offloads from the server the heavy burden of double encrypting every IP-HTTPS connection for all connected DirectAccess clients. This results in reduced CPU utilization on the DirectAccess server, yielding better scalability and performance.

SSL Offload and Windows 8.x/10 Clients

Offloading SSL for Windows 8.x/10 clients will not improve performance because they already use null cipher suites for IP-HTTPS when connecting to a Windows Server 2012 or later DirectAccess server. However, terminating SSL on the NetScaler is still required to perform IP-HTTPS preauthentication.

Supported NetScaler Platforms for DirectAccess SSL Offloading

The following configuration for Citrix NetScaler can be performed on any release of the VPX virtual ADC platform. However, be advised that there is a known issue with older releases on the MDX and SDX hardware platforms that will prevent this from working. For MDX and SDX deployments, upgrading to release 11.1 build 50.10 or later will be required.

Configure Citrix NetScaler for IP-HTTPS SSL Offload

To enable SSL offloading for DirectAccess IP-HTTPS on the Citrix NetScaler, open the NetScaler management console, expand Traffic Management and Load Balancing, and then perform the following procedures in order.

Add Servers

  1. Click Servers.
  2. Click Add.
  3. In the Name field enter a descriptive name for the first DirectAccess server.
  4. Select IP Address.
  5. In the IP Address field enter the IP address of the first DirectAccess server.
  6. Click Create.
  7. Repeat these steps for any additional servers in the load-balanced cluster.

DirectAccess SSL Offload and IP-HTTPS Preauthentication with Citrix NetScaler

Add Services

  1. Click Services.
  2. Click Add.
  3. In the Service Name field enter a descriptive name for the service.
  4. Select Existing Server from the Server drop-down list.
  5. Choose the first DirectAccess server in the cluster.
  6. Choose SSL from the Protocol drop-down list.
  7. Click Ok.DirectAccess SSL Offload and IP-HTTPS Preauthentication with Citrix NetScaler
  8. Edit SSL Parameters.
    1. In the Protocol section uncheck SSLv3.
    2. Click Ok.
  9. Edit SSL Ciphers.
    1. Click Remove All.
    2. Click Add.
    3. Type NULL in the Search Ciphers box.
    4. Check the box next to the first entry for SSL3-NULL-SHA.
    5.  Click the right arrow to add the cipher to the list.
    6. Click Ok.
    7. Click Done.
    8. Repeat these steps for any additional servers in the load-balanced cluster.DirectAccess SSL Offload and IP-HTTPS Preauthentication with Citrix NetScaler

A warning message may be displayed indicating that no usable ciphers are configured on the SSL vserver/service. This message can be safely ignored.

DirectAccess SSL Offload and IP-HTTPS Preauthentication with Citrix NetScaler

Add Virtual Server

  1. Click Virtual Servers.
    1. Click Add.
    2. In the Name field enter a descriptive name for the virtual server.
    3. Choose SSL from the Protocol drop-down list.
    4. In the IP Address field enter the IP address for the virtual server.
    5. Click Ok.DirectAccess SSL Offload and IP-HTTPS Preauthentication with Citrix NetScaler

      Note: When enabling load balancing in DirectAccess, the IP address assigned to the first DirectAccess server is reallocated for use as the load balancing Virtual IP Address (VIP). Ideally this IP address will be assigned to the load balancing virtual server on the NetScaler. However, this is not a hard requirement. It is possible to configure the VIP on the NetScaler to reside on any subnet that the load balancer has an interface to. More details here.


  2. In the Services and Groups section click No Load Balancing Virtual Server Service Binding.
    1. Click on the Select Service field.
    2. Check all DirectAccess server services and click Select.
    3. Click Bind.
    4. Click Continue.
  3. In the Certificate section click No Server Certificate.
    1. Click on the Select Server Certificate field.
    2. Choose the certificate to be used for DirectAccess IP-HTTPS.
    3. Click Select.
    4. Click Bind.
    5. Click Continue.
  4. Edit SSL Ciphers.
    1. Click Remove All.
    2. Click Add.
    3. Type ECDHE in to the Search Ciphers box.
    4. Check the box next to TLS1-ECDHE-RSA-AES128-SHA.
    5. Click the right arrow to add the cipher to the list.
    6. Type NULL in to the Search Ciphers box.
    7. Check the box next to SSL3-NULL-SHA.
    8. Click the right arrow to add the cipher to the list.
    9. Click Ok.
    10. Click Done.DirectAccess SSL Offload and IP-HTTPS Preauthentication with Citrix NetScaler

      Note: If Windows 8.x/10 clients are supported exclusively, SSL3-NULL-SHA is the only cipher suite required to be configured on the virtual server. If Windows 7 client support is required, the TLS1-ECDHE-RSA-AES128-SHA cipher suite should also be configured on the virtual server.


  5. Edit SSL Parameters.
    1. Uncheck SSLv3.
    2. Click Ok.

      Note: If Windows 8.x/10 clients are supported exclusively, TLSv1 can also be unchecked on the virtual server. If Windows 7 client support is required, TLSv1 must be enabled.


  6. In the Advanced Settings section click Persistence.
    1. Choose SSLSESSION.
    2. Enter 10 minutes for the Time-out (mins) value.
    3. Click Ok.
    4. Click Done.

Optional IP-HTTPS Preauthentication

To enable IP-HTTPS preauthentication to prevent unauthorized network access, perform the following procedures on the Citrix NetScaler appliance.

  1. Expand Traffic Management, Load Balancing, and then click Virtual Servers.
  2. Select the DirectAccess virtual server and click Edit.
    1. In the Certificate section click No CA Certificate.
    2. Click the Select CA Certificate field.
    3. Choose the certificate for the CA that issues certificates to DirectAccess clients and servers.

      Note: The CA certificate used for DirectAccess can be found by opening the Remote Access Management console, clicking Edit on Step 2, and then clicking Authentication. Alternatively, the CA certificate can be found by running the following PowerShell command.

      (Get-RemoteAccess).IPsecRootCertificate | Format-Table Thumbprint


    4. Click Select.
    5. Choose CRL Optional from the CRL and OCSP Check drop-down list.
    6. Click Bind.
  3. Edit SSL Parameters.
    1. Check the box next to Client Authentication.
    2. Choose Mandatory from the Client Certificate drop-down list.
    3. Click Ok.
    4. Click Done.
      DirectAccess SSL Offload and IP-HTTPS Preauthentication with Citrix NetScaler

Summary

Leveraging the advanced capabilities of the Citrix NetScaler ADC can improve performance when supporting Windows 7 clients and enhance security for all DirectAccess clients using IP-HTTPS. In terms of supportability, all of the changes described in this article are completely transparent and do not alter the native DirectAccess client or server configuration. If a Microsoft support engineer declines support due to this configuration, switching from SSL offload to SSL bridge is all that’s required to restore full supportability.

Additional Resources

NetScaler release 11.1 build 50.10 (requires login) – https://www.citrix.com/downloads/netscaler-adc/firmware/release-111-build-5010

Release notes for build 50.10 of NetScaler 11.1 release – https://www.citrix.com/content/dam/citrix/en_us/documents/downloads/netscaler-adc/NS_11_1_50_10.html

VIDEO: Enable Load Balancing for DirectAccess – https://www.youtube.com/watch?v=3tdqgY9Y-uo

DirectAccess IP-HTTPS preauthentication using F5 BIG-IP – https://directaccess.richardhicks.com/2016/05/23/directaccess-ip-https-preauthentication-using-f5-big-ip/

DirectAccess SSL offload for IP-HTTPS using F5 BIG-IP – https://directaccess.richardhicks.com/2013/07/10/ssl-offload-for-ip-https-directaccess-traffic-from-windows-7-clients-using-f5-big-ip/

Implementing DirectAccess with Windows Server 2016 book – http://directaccessbook.com/

DirectAccess Manage Out with ISATAP Fails on Windows 10 and Windows Server 2016

Introduction

For organizations that have implemented DirectAccess manage out using the Intrasite Automatic Tunnel Addressing Protocol (ISATAP), you may find connecting to remote DirectAccess clients by hostname using Windows 10 or Windows Server 2016 fails. Connections to remote DirectAccess clients using Windows 7, Windows 8.x, Windows Server 2008/2008R2, and Windows Server 2012/2012R2 work without issue.

Troubleshooting

On a Windows 10 or Windows Server 2016 host configured to use ISATAP for DirectAccess manage out, the remote DirectAccess client resolves to an IPv6 address correctly.

DirectAccess Manage Out with ISATAP Fails on Windows 10 and Windows Server 2016

In addition, a route to the DirectAccess client’s IPv6 prefix is also present in the routing table.

DirectAccess Manage Out with ISATAP Fails on Windows 10 and Windows Server 2016

Nevertheless, attempts to connect to the remote DirectAccess client by name fail.

DirectAccess Manage Out with ISATAP Fails on Windows 10 and Windows Server 2016

The DirectAccess client is reachable by its IPv6 address, however.

DirectAccess Manage Out with ISATAP Fails on Windows 10 and Windows Server 2016

Known Issue

There is a known issue with Windows 10 and Windows Server 2016 DNS client that prevents manage out using ISATAP on these operating systems from working correctly. A while back I wrote about implementing some registry entries as a workaround for this issue on Windows 10. Recently, Karsten Hentrup brought another effective workaround to my attention that also involves adding a registry entry on the ISATAP client machine. This method is preferred as it requires only one registry entry and does not adversely affect existing DNS operation. To make this change, on each machine that requires DirectAccess manage out functionality open an elevated PowerShell command window and run the following command.

New-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters\” -Name AddrConfigControl -PropertyType DWORD -Value 0 -Force

Summary

When using ISATAP, ensure that this workaround is implemented on any Windows 10 or Windows Server 2016 machine that will require manage out functionality to remote DirectAccess clients.

Additional Resources

ISATAP Recommendations for DirectAccess Deployments

DirectAccess Client Firewall Rule Configuration for ISATAP Manage Out

Implementing DirectAccess with Windows Server 2012 R2 Book

DirectAccess Consulting Services

DirectAccess Broken in Windows 10 Insider Preview Build 14971

DirectAccess Broken in Windows 10 Enterprise Insider Preview Build 14971Updated 12/9/2016: This issue has been resolved in build 14986. If you are still running build 14971, update to the latest build to resolve this issue.

For anyone running the Insider Preview version of Windows 10 Enterprise, be advised that the latest Fast Ring build (14971) has a bug that breaks DirectAccess connectivity. Microsoft is aware of the issue and is currently working to identify the root cause. As it stands now, there is no known workaround.

I’ll post an update as soon as I have more information. Stay tuned!

Migrating DirectAccess from NLB to External Load Balancer


Introduction

Migrating DirectAccess from NLB to External Load BalancerMultiple DirectAccess servers can be deployed in a load-balanced cluster to eliminate single crucial points of failure and to provide scalability for the remote access solution. Load balancing can be enabled using the integrated Windows Network Load Balancing (NLB) or an external physical or virtual load balancer.

NLB Drawbacks and Limitations

NLB is often deployed because it is simple and inexpensive. However, NLB suffers from some serious drawbacks that limit its effectiveness in all but the smallest deployments. For example, NLB uses network broadcasts to communicate cluster heartbeat information. Each node in the cluster sends out a heartbeat message every second, which generates a lot of additional network traffic on the link and reduces performance as more nodes are added. Scalability is limited with NLB too, as only 8 nodes are supported, although the practical limit is 4 nodes. Further, NLB supports only round-robin connection distribution.

External Load Balancer

A better alternative is to implement a dedicated physical or virtual load balancing appliance. A purpose-built load balancer provides additional security, greater scalability (up to 32 nodes per cluster), improved performance, and fine-grained traffic control.

Migrate from NLB to ELB

It is possible to migrate to an external load balancer (ELB) after NLB has already been configured. To do this, follow the guidance provided in my latest blog post on the KEMP Technologies blog entitled “Migrating DirectAccess from NLB to KEMP LoadMaster Load Balancers”.

Migrating DirectAccess from NLB to External Load Balancer

Additional Resources

DirectAccess Deployment Guide for KEMP LoadMaster Load Balancers

Migrating DirectAccess from NLB to KEMP LoadMaster Load Balancers

Load Balancing DirectAccess with KEMP LoadMaster Load Balancers

DirectAccess Load Balancing Tips and Tricks Webinar with KEMP Technologies

DirectAccess Single NIC Load Balancing with KEMP LoadMaster Load Balancer

Configuring the KEMP LoadMaster Load Balancer for DirectAccess NLS

Enable DirectAccess Load Balancing Video

Implementing DirectAccess with Windows Server 2016 Book

DirectAccess Expired IP-HTTPS Certificate and Error 0x800b0101

Introduction

DirectAccess is an IPv6 only solution, at least from the perspective of the client. When the DirectAccess client is remote, it communicates with the DirectAccess server using IPv6 exclusively. IPv6 transition technologies are used to enable this connectivity when the DirectAccess server and/or client are on the pubic IPv4 Internet.

IP-HTTPS

One of the IPv6 transition technologies used by DirectAccess is IP-HTTPS. With IP-HTTPS, IPv6 traffic is encapsulated in HTTP and delivered to the DirectAccess server using IPv4. IP-HTTPS is used exclusively when the DirectAccess server is located behind an edge firewall performing network address translation.

SSL Certificate

To support IP-HTTPS, an SSL certificate is installed on each DirectAccess server. The SSL certificate is commonly issued by a public certification authority, but it can also be issued by an internal PKI. The SSL certificate used for IP-HTTPS can and does expire, and when it does it will prevent any DirectAccess connection from being established using this transition technology.

Troubleshooting

When troubleshooting DirectAccess connectivity via IP-HTTPS, the first thing the administrator will notice is that the media state for the DirectAccess client’s IP-HTTPS tunnel adapter interface is shown as disconnected.

DirectAccess Expired IP-HTTPS Certificate and Error 0x800b0101

In addition, the Get-NetIPHttpsState PowerShell command returns an error code 0x800b0101 indicating Failed to connect to the IP-HTTPS server; waiting to reconnect.

DirectAccess Expired IP-HTTPS Certificate and Error 0x800b0101

Err.exe translates this error to CERT_E_EXPIRED, indicating that the SSL certificate is no longer valid.

DirectAccess Expired IP-HTTPS Certificate and Error 0x800b0101

Viewing the IP-HTTPS SSL certificate is not possible using a web browser. Instead, use Nmap and the ssl-cert script to view the certificate.

nmap.exe -n -Pn -p443 [FQDN] –script ssl-cert

DirectAccess Expired IP-HTTPS Certificate and Error 0x800b0101

In the Operations Status window of the Remote Access Management console on the DirectAccess server, the IP-HTTPS status is listed as Critical. Details show IP-HTTPS not working properly, with an error stating the IP-HTTPS certificate is not valid, and clearly indicating that the certificate is expired.

DirectAccess Expired IP-HTTPS Certificate and Error 0x800b0101

The IP-HTTPS status can also be viewed at the command line by issuing the following command in an elevated PowerShell command window.

Get-RemoteAccessHealth | Where-Object Component -eq IP-Https | Format-List

DirectAccess Expired IP-HTTPS Certificate and Error 0x800b0101

Updating the Certificate

Simply renewing the SSL certificate is not sufficient to restore IP-HTTPS connectivity for remote DirectAccess clients. The DirectAccess configuration must also be updated to use the new certificate. In the Remote Access Management console, highlight DirectAccess and VPN under Configuration and then click Edit on Step 2 (for load-balanced or multisite DirectAccess deployments, first highlight the individual server and then click Configure Server Settings). Click Network Adapters, click Browse, and then select the new SSL certificate.

DirectAccess Expired IP-HTTPS Certificate and Error 0x800b0101

Click Ok, Next, and then Finish twice and Apply. Repeat these steps for each server in the load-balanced cluster, and for all servers in all entry points in the enterprise.

Alternatively, the IP-HTTPS certificate can be updated in the DirectAccess configuration by opening an elevated PowerShell command window and entering the following commands.

$cert = Get-ChildItem -Path cert:\localmachine\my | Where-Object Thumbprint -eq [cert_thumbprint]
Set-RemoteAccess -SslCertificate $cert -Verbose

For example…

$cert = Get-ChildItem -Path cert:\localmachine\my | Where-Object Thumbprint -eq 2BFD1BC5805EBBF8ACB584DA025AD75B341A8B33
Set-RemoteAccess -SslCertificate $cert -Verbose


Important Note: Be sure to execute these commands on each DirectAccess server in the load-balanced cluster, and for all servers in all entry points in the enterprise.


Self-Signed Certificates

When DirectAccess is deployed using the Getting Started Wizard (GSW), also known as a “simplified deployment“, a self-signed certificate is used for IP-HTTPS. By default, this certificate expires 5 years after it is created. The expiration of a self-signed certificate presentsa unique challenge. Although the self-signed certificate can’t be renewed, it can be re-created or cloned using the New-SelfSignedCertificate PowerShell command. However, DirectAccess clients will not trust this new certificate until they receive the updated client settings via group policy. DirectAccess clients outside the network will not be able to establish IP-HTTPS connections until they receive these new policies. When they attempt to connect to the DirectAccess server without first updating group policy, the IP-HTTPS status will indicate an error code 0x800b0109 which translates to CERT_E_UNTRUSTEDROOT.

If the expired self-signed certificate is replaced with another self-signed certificate (not recommended), DirectAccess clients will have to come back to the internal network or connect remotely via client-based VPN to update group policy and receive the new DirectAccess client settings. A better alternative is to replace the expired self-signed certificate with a public SSL certificate that matches the existing public hostname. This will allow remote clients to reestablish DirectAccess connectivity without the need to udpate group policy first.

Summary

Certificate expiration must be monitored closely to ensure the highest level of availability for the DirectAccess remote access solution. Certificate auto enrollment can be leveraged to ensure that IPsec certificates are automatically renewed prior to expiration. However, the IP-HTTPS certificate must be renewed manually and requires additional configuration after it has been updated.

Additional Resources

DirectAccess Computer Certificate Auto Enrollment

DirectAccess and Multi-SAN SSL Certificates for IP-HTTPS

Implementing DirectAccess with Windows Server 2016 book

DirectAccess No Longer Supported in Microsoft Azure

DirectAccess No Longer Supported on Windows Server in AzureMicrosoft has historically not supported DirectAccess running on Windows Server in the Microsoft Azure public cloud. In the past, this was due to limitations imposed by the underlying cloud infrastructure, as I documented here. When Microsoft moved from the old service manager model (classic) to the newer resource manager infrastructure, many of the issues that prevented the DirectAccess workload from being stable were resolved. There are still some fundamental limitations to deploying DirectAccess in Azure as I documented here, but for the most part it was a workable solution. In fact, Microsoft even updated their support statement for DirectAccess on Azure, quietly removing it from the unsupported roles list in July 2016.

Sadly, Microsoft has reversed their decision on the support of DirectAccess in Azure. As many of you have noticed or commented on some of my posts, Microsoft recently added clarification on support for remote access on Windows Server in Azure, explicitly indicating that DirectAccess was not included in Remote Access support.

Reference: https://support.microsoft.com/en-us/kb/2721672

You’ll be glad to know that DirectAccess is indeed supported in Amazon’s public cloud infrastructure, Amazon Web Services (AWS). I’ll be drafting some guidance for deploying DirectAccess in AWS soon. Stay tuned!

Additional Resources

Azure Resource Manager vs. Classic Deployment: Understand Deployment Models and the State of your Resources

Deploying DirectAccess in Microsoft Azure

Implementing DirectAccess in Windows Server 2016 Book

DirectAccess Training at TechMentor Conference Orlando 2016

Live! 360 Orlando 2016I am pleased to announce that I’ll be participating in the upcoming TechMentor conference in Orlando, FL in December. The TechMentor conference is part of the larger Live!360 event and offers a compelling agenda of training for IT professionals. I’ll be delivering the following sessions that are focused on providing secure remote access using Windows Server 2016.

TMT01 – Implementing DirectAccess in Windows Server 2016
TMT04 – DirectAccess Troubleshooting Deep Dive
TMT11 – Client-based VPN in Azure with Windows Server 2016

Don’t miss out on this outstanding conference. Register today and save $500.00!

Implementing DirectAccess with Windows Server 2016 Book Now Available

I am very excited to announce that my new DirectAccess book, Implementing DirectAccess with Windows Server 2016 from Apress media, is now shipping! The book is available on popular online sites like Amazon.com, Barnes & Noble, Springer.com, Apress.com, and others. The book is also available in electronic formats such as Amazon Kindle and Barnes & Noble Nook, as well as a variety of subscription formats including Safari, Books24x7, and SpringerLink.

Implementing DirectAccess with Windows Server 2016

This book contains detailed and prescriptive guidance for the planning, design, implementation, and support of a DirectAccess remote access solution on Windows Server 2016. It also includes valuable insight, tips, tricks, and best practice recommendations gained from my many years of deploying DirectAccess for some of the largest organizations in the world.

Current DirectAccess administrators will also find this book helpful, as the majority of content is still applicable to DirectAccess in Windows Server 2012 and Windows Server 2012 R2. In addition, the book also includes essential information on the design and deployment of highly available and geographically redundant DirectAccess deployments.

Troubleshooting DirectAccess can be a daunting task, so I’ve dedicated an entire chapter in the book to this topic. For those responsible for the maintenance and support of DirectAccess in their organization, this chapter alone will be worth the investment.

Be sure to order your copy today!

%d bloggers like this: