Category: DirectAccess

The remote access role is already installed and DirectAccess console cannot load the configuration

The remote access role is already installed and DirectAccess console cannot load the configuration

Troubleshooting DirectAccess Remote Access role is already installed

I recently came across an issue with adding additional servers to the DirectAccess cluster I created. All servers were on the same subnet and no firewalls were placed in between the servers. After extensive digging and tinkering I realized that the Remote Registry was disabled. This is in fact required by DirectAccess and disabling this does seem good practice but you will face the following issues when doing so:

  1. The remote access console will fail to load correctly, error messages usually state the configuration was not loaded from a domain controller, in addition
  2. adding additional servers to the DirectAccess cluster will result in an error stating the “Remote access role is already installed”

Just to clarify when adding additional servers to a DirectAccess cluster you must:


  1. Configure the network cards on the new server (Dual homed is recommended)
  2. Install the IPHTTPS certificate
  3. Install the Remote Access role from Server Manager (but do not configure the role once installed)
DirectAccess and Null Cipher Suites

DirectAccess and Null Cipher Suites

Are Null Cipher Suites Safe to Use

ssllabsYou may at some-point you may be questioned about the security protocols used by DirectAccess. If you have a pen test performed they may flag the following two cipher suites:


Within a typical solution Null ciphers would be disabled, however DirectAccess is special in the way it works. NULL cipher suites are enabled by deafult. DirectAccess is an IPv6 only solution. In order to transport IPv6 data over the public IPv4 internet the traffic must be encapsulated within an IPv6 tunnelling technology. Now there are 3 technologies that can be used:

  1. IPHTTPS (preferred when using Windows 8 onwards)
  2. Teredo
  3. 6to4

DirectAccess servers must be domain joined in order to function. Teredo and 6to4 tunnelling protocols require that the servers/clients be publicly accessible without a firewall placed in front. This of course is dependant on an organisations risk appetite, where possible security will dictate that the servers be placed behind a firewall. In addition the National Cyber Security Centre (NCSC) provide Commercial Product Assurance scripts in order to harden the DirectAccess cryptography which cannot be applied to 6to4. The IPHTTPS tunnelling protocol allows the servers and clients to be placed behind a firewall and uses 443 which is commonly opened on the majority of routers whether corporate or private and is therefore is the more preferred IPv6 tunnelling method. Moreover IPHTTPS tunnelling aligns with the NCSC wall gardened approach with firewalls placed in front and behind the DirectAccess servers.

Previously Teredo was considered the preferred tunnelling protocol to use for DirectAccess as IPHTTPS resulted in the traffic being double encrypted, as Windows 7 did not support Null Cipher suites. This increased the overhead processing on the DirectAccess servers and resulted in poor performance for users. With the introduction of Windows 8 onwards. Microsoft enabled support for Null Cipher suites removing the need for double encryption with IPHTTPS. Thus IPHTTPS is now considered the preferred tunnelling protocol. IPHTTPS should only be viewed as a transport mechanism for IPv6 data over the public IPv4 internet. The data within the IPHTTPS is still IPsec encrypted.

DirectAccess Tunnels

DirectAccess clients initiate two tunnels. These tunnels are broken down into:

  1. Infrastructure Tunnel – The client device (Windows 10 for example) will know when it is outside the corporate network and as long as it has an internet connection it will initiate a connection back into the corporate network. This allows the device to be managed without the user initiating the connection. The computer certificate and NTLMv2 are used for authentication.
  2. Intranet Tunnel – Once the user logs onto the client device, the user tunnel in then created. The computer certificate and Kerberos are used for authentication.

These tunnels are encrypted with IPsec using the computer certificate in order to provide a secure and encrypted communication channel between the DirectAccess Servers and Clients.

An IPHTTPS tunnel is the outer tunnel for the transportation of IPv6 over the IPv4 internet. The inner tunnel consists of the IPsec tunnels of the encrypted IPv6 data.

In regards to SSL 3.0, RC4 ciphers, a hacker would not be able to access the DirectAccess traffic as the data is still IPsec encrypted. But these can be disabled on the DirectAccess servers if requested. SSL 3.0 should be disabled on all systems.

Limit the Cipher Suites

In order to limit the Ciphers used by a system, you can use Nartac which provides a user friendly GUI in addition to the following features:


  • Single click to secure your website using best practices
  • Create custom templates that can be saved and run on multiple servers
  • Stop DROWN, logjam, FREAK, POODLE and BEAST attacks
  • Disable weak protocols and ciphers such as SSL 2.0, 3.0 and MD5
  • Enable TLS 1.1 and 1.2
  • Enable forward secrecy
  • Reorder cipher suites
  • Built in Best Practices, PCI, PCI 3.1 and FIPS 140-2 templates
  • Site scanner to test your configuration
  • Command line version


Nartac provides some best practice templates, when using these templates ensure you check the below two Null cipher suites as they are deselected by default:


Nartac can be downloaded here 

In addition my friend Richard Hicks has a great article on applying a scaled down version of Cipher Suites using Group Policy.

You can test what Ciphers are being presented using SSL Labs, You should see the below output once applied. Rememebr your rating for DirectAccess will be capped at F as we have Null Ciphers enabled.