In part 1 of this series, we configured DirectAccess for an IP-HTTPS connection in a simple (home) environment. In part 2, we enabled reporting and improved client settings to reduce connection time.
- Part 1: Implementing a Basic DirectAccess configuration with IP-HTTPS on Windows Server 2012 Core
- Part 2: Reporting and Optimizing IP-HTTPS connections
- Part 3: Authenticating IP-HTTPS connections with a PKI certificate
- Part 4: Authenticating DirectAccess clients with certificates
- Part 5: Troubleshooting guide for DirectAccess
- Part 6: Configuring DirectAccess for Windows 7
In the two next parts, I propose to improve the security. In this part, we will remove the self-signed certificate used for IP-HTTPS connections and we will generate a certificate from our PKI.
Next part is dedicated to client authentication.
Next part is dedicated to client authentication.
PART 3: AUTHENTICATING IP-HTTPS CONNECTIONS WITH A PKI
1. Preparing PKI
If you don't have a PKI, Install the AD CS (Active Directory Certificate Services) role on a server (your DC if you want).
You can install it from the Server Manager dashboard (add role...) or with powershell with the command lines :
Install-WindowsFeature AD-Certificate -IncludeManagementToolsInstall-AdcsCertificationAuthority -Force
For more information, read the instructions on Basic PKI for Windows Server 2012.
2. Remove the self-signed certificate for IP-HTTPS connections
From a server or a computer with a GUI, open a mmc console
Add the snap-in Certificates
Connect on your DirectAccess server
In the Personal Store, find and select the IP-HTTPS certificates
Its friendly name is normally DirectAccess-IPHTTPS
Remove that certificate
Close the mmc console.
3. Request the IP-HTTPS certificate to your PKI
You can't request and import a certificate with a private key if you're not connected locally on the server. So with a core server, don't try to request the IPHTTPS certificates, with a mmc console from another computer.
So, there are 2 solutions:
- Autoenrollment : you create the IPHTTPS certificates template on your PKI and you define security options to allow only your DirectAccess server to enroll that certificate automatically. Good idea !
- Request certificate with command lines. Let's do that !
Open a command line option on you DirectAccess Server
In a temporary folder, create (locally or remotely) the file certRequest.inf with the following content:
[NewRequest]
Subject = "CN=<public domain name of your server. For example da.nomizo.fr>"
Exportable = FALSE
KeyLength = 2048
KeyUsage = "CERT_DIGITAL_SIGNATURE_KEY_USAGE | CERT_KEY_ENCIPHERMENT_KEY_USAGE"
MachineKeySet = TRUE
FriendlyName = "IPHTTPS PKI"
[RequestAttributes]
CertificateTemplate="WebServer"
Generate your request file with the command line
certreq -new certRequest.inf certRequest.req
To check the content of your request, use the command line
certutil certRequest.req
Submit your request to your PKI and get you certificate with the command line
certreq -submit certRequest.req IPHTTPS-Cert.cer
Select the CA you want to contact and click on OK
On your CA, you can see the generated certificate
On your DirectAccess server, you can confirm the RequestID
Now that you've got your .cer file, just accept it
certreq –accept IPHTTPS-Cert.cer
With a remote MMC console, you can watch you new IP-HTTPS certificate
For information, this is the IP-HTTPS certificate generated for my DirectAccess Server
Note that I've got an alert for the CA certificate. That's only because my local machine can't confirm that my DirectAccess server trusts the CA certificate.
You can read certreq references on Technet to get more information :
http://technet.microsoft.com/library/cc725793.aspx
4. Define your new IP-HTTPS certificate in DirectAccess
Open the DirectAccess console
In the Step 2 - Remote Access Server Box, click on Edit
On the Network Adapters screen, click on Browse
Select your new IP-HTTPS certificate
You can ensure that you select the right certificate by clicking on Click here to view certificate properties.
Note that private key information is not shown.
Click on OK to select your certificate. The Common Name of your certificate appears.
Click on Next
Click on Finish
5. Update configuration
At the bottom of the screen, click on Finish
Click on Apply
Click on Close
To monitor your server status, click on Dashboard
You will certainly get several alerts and a message that says "Configuration for server servername not yet retrieved from the domain controller"
Just wait or type the command line gpupdate /force to speed the process
If you still receive an alert that says "Configuration for server servername retrieved from the domain controller, but not yet applied.", that means probably that you made a mistake during the IP-HTTPS certificate creation.
See technet for more information about configuration distribution issues. 6. Certificate for NLS Server
With the same method you can replace the self-signed certificate for NLS (Network Location Server) server by a PKI generated certificate.
You can use the certRequest.inf file with the following content
[NewRequest]
Subject = "CN=<NLS name of your server. For example DirectAccess-NLS.sc.lab>"
Exportable = FALSE
KeyLength = 2048
KeyUsage = "CERT_DIGITAL_SIGNATURE_KEY_USAGE | CERT_KEY_ENCIPHERMENT_KEY_USAGE"
MachineKeySet = TRUE
FriendlyName = "NLS PKI"
[RequestAttributes]
CertificateTemplate="WebServer"
Note : Ensure that your DNS record exists. Especially, if you use the same CN than the self-signed certificate, DirectAccess may remove the DNS record.
You can also set an HTTPS server what you can reach on your network. Be careful, that URL must be available ONLY from your internal network, otherwise your clients will suppose it is locating on your network and won't create a DirectAccess communication.
Now, our DirectAccess server use certificates generated from our PKI. It's really more secure !
In the next part, I will show you how to improve client authentication security with certificates.
See you soon
Julien
