DirectAccess reports Error: there is no valid certificate to be used by IPsec which chains to the root/intermediate certificate configured to be used by IPsec in the DirectAccess configuration." when device-certificates are enabled

The amount of accurate documentation on how to implement device-certificate based authentication for Direct Access clients is extremely low. If you’re implementing Direct Access from scratch I would recommend getting it working with AD credentials only, then enable device-certificates once you are confident in the general config. I recently did just this, the Direct Access server and clients were functioning correctly. The next stage was to enable Computer Certificates from Step 2 – Remote Access Server.

In my lab I only have a single tier AD CS PKI setup, therefore I selected Use Computer Certificates but did not tick Use an Intermediate Certificate. This would be required if you had a two-tier AD CS PKI.

For clarity at this point you should choose the certificate that is that is issued by your Certificate Authority. It is unclear what else is required to make IPsec work correctly. 

Once you do the above, and Group Policy refreshes you will start getting an error about IPsec not working. 

“Error: there is no valid certificate to be used by IPsec which chains to the root/intermediate certificate configured to be used by IPsec in the DirectAccess configuration.”

“Causes: the certificate has not been installed or is not valid.”

“Resolution: please ensure that a valid certificate is present in the machine store and DA server is configured to use the corresponding root certificate.”

The reason for this error is that a suitable certificate is not installed on the Direct Access server, this might seem obvious. However, the configuration step from Direct Access Step 2 – Remote Access Server does not install a certificate to make IPsec work, it simply points the Direct Access configuration at the PKI to trust for device certificates. 

With that said, you must configure a custom AD CS template with specific settings to make IPsec work for Direct Access, a certificate from this template then must be installed on all of the Direct Access servers.

To do this open up Certification Authority and click Certificate Templates.

Open Manage from Certificate Templates.

Find the default Certificate Template called RAS and IAS Server, right click it and select Duplicate Template. 

On the General tab give your new template a descriptive name I also select Publish Certificate in Active Directory.

Click on the Security tab and add the context Domain Computers and grant the following permissions

• Read
• Enroll
• Autoenroll 

Click the Extensions tab and click Application Policies, then Edit. 

Click Add from the Edit Application Policies Extension window.

Enter a descriptive text string for the new Application Policy, do not make any alterations to the Object Identifier and click OK. 

Do not forget to do a Certificate Template to Issue to ensure the new template is available for certificate enrolment. 

The next step to fix “IPsec is not working properly.” is to enroll a certificate on each of the Direct Access servers using the new template. It should be installed under the Computer context under the Personal store on each of the Direct Access servers. 

Once this certificate is installed do a gpupdate /force on each of the Direct Access servers, the IPsec errors should disappear. 

Part 2: Clustering Microsoft DirectAccess with Network Load Balancing (NLB)

This post is intended to be part 2 of my previous post "Deploying Microsoft's DirectAccess on Windows Server 2012 R2, in a Simple Topology behind a NAT Firewall" which you can see here http://blog.ryanbetts.co.uk/2014/09/deploying-microsofts-directaccess-on.html

I am going to document the fairly easy process of configuring Windows Network Load Balancing (NLB), to make the DirectAccess installation highly available. To get started I have provisioned a second Windows Server 2012 R2 VM, I used the following command to install all of the required roles and features to support DirectAccess.

Add-WindowsFeature –Name DirectAccess-VPN, NLB -IncludeManagementTools

Once the roles are installed, return to the Remote Access console. Click on the Configuration pane, and from the Tasks section click Enable Load Balancing. Click Next at the initial wizard screen.

Selected Use Windows Network Load Balancing (NLB) I am going to cover load balancing DirectAccess with a pair of Citrix NetScaler VPX Load Balancers in a future post. Click Next.

This part is a little confusing at first, you must enter a Dedicated IP Address (DIP). This address will be assigned to the network interface of the first DirectAccess server, the IP in which it had will then become the NLB VIP. Click Next.

On the Summary page click Commit.

If everything is configured correctly, you should see green lights on the GPO update window. Click Close.

From the Configuration pane, click Add or Remote Servers from the Tasks list.

Click Browse and enter the hostname of the second DirectAccess server, click Next.

For now I am going to remain using self-signed certificates, click Next.

At this stage I have left the Network Location Server (NLS) on-box, although this will throw an error during the GPO reconfiguration changes. Click Next.

Click Add from the Summary page.

When the server is added to the list click Commit.

As expected the GPO reconfiguration throws the following error "When adding a server (running the network location server using a self-signed certificate) to a cluster, point the network location server DNS entry to the internal DIP of each cluster server. After GPO updates, update the DNS entry again to the cluster...".

At this point I am going reconfigure my Network Location Server (NLS) to reside on one of my Domain Controllers, the following blog post http://blog.ryanbetts.co.uk/2014/06/directaccess-configuring-network.html outlines exactly how to do this. To test it try connecting to the NLS website via Internet Explorer.

There is one gotcha when using an internal Certificate Authority for your Network Location Server (NLS), you must export the Root Certificate from the CA and import on the DirectAccess Server(s).

Now return to the Configuration pane, and click Configure under Step 3.

Click The Network Location Server is Deployed on a Remote Web Server (Recommended) and enter the FQDN you configured for the NLS website, click Validate to test this is working. If you do not have the Root CA Certificate imported into the Trusted Root Certificate Store this part will fail. Click Next.

From the Dashboard DirectAccess should report to be working correctly.

To view the DirectAccess NLB settings, and to view the NLB VIP use the following PowerShell command.

Get-RemoteAccessLoadBalancer

Part 1: Deploying Microsoft's DirectAccess on Windows Server 2012 R2, in a Simple Topology behind a NAT Firewall

I am going to post a series of DirectAccess posts on how to deploy and configure it, this will hopefully give some useful information on things I have learned while deploying it in production. It's got to be said, DirectAccess can be "flaky", meaning it's behavior is sometimes inconsistent, I have personally installed DirectAccess four times into a production environment, each time I have required Microsoft support.

To install the required roles and features for DirectAccess, use the following PowerShell command, the SXS folder must be available locally or it will fail. I have included NLB to support a future post.

Add-WindowsFeature –Name DirectAccess-VPN, NLB   -IncludeManagementTools

Once you have restarted the server, open the Remote Access Management Console from the start menu. Click on the Run the Remote Access Setup Wizard, it would be my advice to avoid using the Run the Getting Started Wizard.

This part will depends on your requirements but I learned the hard way that if you have DirectAccess and VPN deployed, the NULL encyption for clients is invalid and connections are still suseptable to double encryption which makes performance terrible. Richard Hicks (MVP) blog outlines this known issue in more depth http://directaccess.richardhicks.com/2014/06/24/directaccess-ip-https-null-encryption-and-sstp-vpn/

Click Deploy DirectAccess Only.

The interface will refresh and you can click Configure under Step 1 - Remote Clients.

By default Deploy full DirectAccess for client access and remote management is selected, click Next.

I have created a domain local security group that contains the computer objects of all authorized DirectAccess clients, I suggest you do the same click Add and point to the group. I have seen disasters where people put Domain Computers in here, with no WMI Filtering which deploys DirectAccess to everything. This is part because if you mis-configure DirectAccess the GPO that gets deployed can tatoo the registry in a way that breaks DNS on the local devices, not something you would want across your entire domain.

If you tick Enable DirectAccess for Mobile Computers Only this configures a GPO WMI Filter to query the device for a battery, I have chosen not to enable this. I have also not selected Use Force Tunneling because it degrades performance so much, again down to the requirements.

At the next step you should configure the Network Connectivity Assistant (NCA), I personally always configure this to use PING and point it to my Domain Controllers, by default the DirectAccess wizard configures it to use HTTP and points it to a website http://DirectAccessWebHostProbe I have seen this cause issues so I do it this way.

You should consider changing the DirectAccess Connection Name this is the string of text that is displayed to users, below is an example of Windows 8.1.

Click Finish. Now you can move on to Step 2 - Remote Access Server click Configure.

In this simple topology example I am deploying DirectAccess behind a Cisco ASA 5510 Firewall therefore I have selected Behind an Edge Device (with a Single Network Adapter) in future posts I will go into deploying DirectAccess on the Edge. You must configure an externally resolvable FQDN for DirectAccess clients. I have configured directaccess.ryanbetts.co.uk, click Next.

As this server only has a single interface it has been automatically selected, if you rename interfaces Internal or External for example DirectAccess can automatically  detect these at this stage. Again this is a simple example so I am using self -signed certificates. Click Next.

Although it is not a requirement for Windows 8 clients, if you are planning to use Windows 7 Enterprise clients you must configure Use Computer Certificates and point it to your Certificate Authority. If you are using Windows 7, and are hosting the Certificate Authority, ensure the Certificate Revocation List (CRL) is externally reachable. Click Next.

Click Configure for Step 3 Infrastructure Servers.

For this example I am installing the Network Location Server (NLS) on box, with DirectAccess. This is not considered a good practice as the NLS is so important to DirectAccess. If you are looking to configure the Network Location Server (NLS) on a seperate server check out my other blog post on how to do this for DirectAccess - http://blog.ryanbetts.co.uk/2014/06/directaccess-configuring-network.html

The DNS Server configuration can be a bit confusing, the address should be set to the DirectAccess Servers IP, most people would think this should be a DNS server address. Definately got me the first time I deployed DirectAccess.

This is straight forward in my lab as I only have a single domain, if you want to exclude domains remove them from the Domain Suffixes to Use list. Click Next.

On the Management tab, this is where you define the SCCM/WSUS servers in the environment. I personally have an SCCM 2012 R2 server, so I have pointed it to that. Click Finish.

Click Finish to write the GPO's.

The wizard will compile a review of all the settings, click Apply when you are happy with them. You can use the Change button to rename the GPO's it creates if your GPO structure uses a naming convention.

Don't worry if the Dashboard looks like this at first, it seems to take a few minutes (sometimes longer) for DirectAccess to compose itself.

Click Refresh a couple of times and it will come back green for every service if you have configured it correctly.

If you remember back to earlier in this post I chose Behind Edge (with one network adapter) this means I am going to use Network Address Translation (NAT) to enable DirectAccess to sit behind a firewall, although this is a supported configuration it means the only connection protocol that can be used for clients to connect is HTTPS which is a TCP protocol, this means performance is degraded as it's a connection orientated protocol that handshakes. In a NAT'd environment you must have a 1:1 NAT rule configured on the firewall that points to the internal IP of the DirectAccess server, port 443 is required if HTTPS is going to be used.

If you are looking to deploy DirectAccess, I would also check out the following resources;

http://directaccess.richardhicks.com/ (MVP DirectAccess Blog)

http://www.amazon.com/Microsoft-DirectAccess-Best-Practices-Troubleshooting/dp/1782171061/ref=sr_1_1?ie=UTF8&qid=1411295281&sr=8-1&keywords=directaccess (Book by DirectAccess MVP)

http://www.amazon.com/Windows-Server-Unified-Planning-Deployment/dp/1849688281/ref=sr_1_2?ie=UTF8&qid=1411295281&sr=8-2&keywords=directaccess (Another good book for DirectAccess)