Tag: 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.


What are Cipher Suites Explained

What are Cipher Suites Explained

Cipher Suites

Cipher SuitesSo when I mention Cipher suites, most people will find the nearest hole to hide in or think its an encryption protocol. But do you really need to know what Cipher Suites are and how they work. Well yes and no. You should have an overall understanding as these ciphers protect your communication channels between servers, websites or applications. Cipher suites are not indestructible and ciphers have been exposed to vulnerabilities.

What it is?

Cipher suites are used in TLS and SSL protocols. They are fundamentally based upon the HMAC (Keyed hash Message Authentication Code which used a cryptographic hash function and a secret cryptographic key)

How it works?

There are many ciphers available and it is the responsibility of the server to select a cipher to communicate upon. This is accomplished by  the client sending a list of available cipher it supports in order of preference to the server in a process called handshaking where the client says “hello” to the server and the server replying with “hello” and replies with the cipher suite it has selected.

What does it look like?

A cipher suite at first glance may look like a jumble of words, but lets break an example down:


The first section is stating what protocol the cipher is, so in our case TLS.

The second section states the key exchange algorithm ECDHE_RSA determines how the client/server will authenticate.

The third section states the bulk encryption algorithm in our case AES_128_GCM. This determines how to encrypt the message including key size.

The last section states the hash algorithm that is used to create the cryptographic hash of each block and in our case it is SHA256.

What about Null Cipher suites?

Well you may have come across Null Cipher Suites especially working with DirectAccess. When the word Null; is mentioned it is quickly seen as a secuirty risk. So lets discuss a Null Cipher suite. Null Cipher suites are encrypted however it is seen as an ancient form of encryption which always gets flagged up on audits. The message stream is encrypted with plain text and not random gibberish that you would expect for example:

KamHussain if encrypted using Null Cipher’s could look like:

Kangaroo Ant Mammoth Hyena Unicorn Seagal Seagal Alien Indigo Neptune

As you can see from above the message is encrypted, the first letter of each word if taken away makes up KamHussain.

So is this secure, well lets say you wouldn’t want to use this unless you have a specific requirement.

Creating a Certificate Signing Request using Windows 10

Creating a Certificate Signing Request using Windows 10

Creating a Certificate Signing Request using Windows 10

certificateCreating Certificate Signing Requests or CSR’s can be a daunting task, you don’t want to get it wrong as it can costs you, literally. Usually many administrators head over to IIS and create a request using the IIS management console. This will of course work but you may end up creating a SHA1 request, with no option for SHA2

I have however noticed Windows 10 being able to create CSR’s with all the latest cryptography and key lengths, as well as it being a breeze to process.

To get started you need to open the Certificate management console. Hit “Windows Key” + “R” and type “MMC” into the run window, now hit enter. Alternatively if you click “Start” and search for “Certificates” and click on “Manage Computer Certificates


Once the certificate console has opened, expand the personal store and right click on Certificates. Click All Tasks > Advanced Operations > Create Custom Request.


In the window click Next

Now click Next


Choose Proceed without enrollment policy and click Next


Click Properties


Now enter a Friendly Name (this can be anything, but something that you can use t easily identify the certificate) and enter a description.

Click the Subject tab


If you fail to enter the basic information like the image on the left, your certificate request will be invalid. You must enter:

Common Name – (this is the URL)

Organisational Unit – Department

Locality – Area e.g. Westminster

State – Area e.g. London

Country – this must be the two letter abbreviation for the United Kingdom use GB

To find your 2 letter country code click here

Finally enter the Alternative name DNS. This should be exactly the same as your URL.


Under the Extensions tab, select Server Authentication and Client Authentication for Extended Key Usage.


Under Key Usage select Digital signature and Key enciphement


Click the Private Key tab, select 2048 for Key Options and check Make private key exportable

Under Hash Algorithm select SHA256

Click OK and Next

Save your file as a .req

Validate your CSR

That’s pretty much it. You can verify that your request file is valid by opening it, copying the data and pasting it into the Symantec Crypto Report validation site click here .

Once you receive your certificate file it MUST be imported onto the computer where the CSR file was created as the private key exists on this machine and is never transmitted within the CSR. You can then export the certificate to any machine as it’s private key was marked as exportable.