If you would like to read the other articles in this series please see:
In Part 1 of this article series, I showed you how to install the Terminal Service Gateway Service and all of the underlying dependencies. In this article, I will continue the discussion by showing you how to confirm that the necessary services are installed correctly. From there, I will show you how to create a certificate authority that issues the certificates used to encrypt gateway traffic.
Verify That Services Are Started
Now that the Terminal Service Gateway Services and the various dependency services have been installed, we need to verify that they are functional. To do so, select the Computer Management command from Longhorn’s Administrative Tools menu. When the Computer Management console opens, navigate through the console tree to Computer Management | Services and Applications | Services.
When you select the Services container, a list of system services should appear within the console’s Details pane. Scroll through the list of services and verify that the Internet Authentication Service has started. If it has not started, then right click on the Internet Authentication Service and select the Start command from the resulting shortcut menu.
Next, scroll down toward the bottom of the list of services and make sure that the World Wide Web Publishing Service has started. Again, if the service has not started, then right click on it and select the Start command from the resulting shortcut menu.
Now that you are familiar with the procedure for making sure that services have started, check to be sure that the RPC / HTTP Load Balancing Service and the Terminal Services Gateway Services are running and start them if necessary.
The Terminal Services Gateway Service is dependent on the use of TLS encryption. In case you aren’t familiar with TLS, it is the latest implementation of SSL encryption. From what I have been told, the Terminal Service Gateway Service will eventually contain a mechanism that makes it easy to acquire a certificate as a part of the initial installation process. For now though the process tends to be a little messy and cumbersome.
The Terminal Service Gateway Service is designed so that you can either use a certificate from an in-house Enterprise Certificate Authority, or you can use a third party TLS certificate. Since my purpose in writing this article is to familiarize you with the Terminal Service Gateway Service rather than configure an ideal real world deployment, let’s create an Enterprise Certificate Authority and then use it to issue the necessary certificate.
Installing an Enterprise Certificate Authority
Being that Longhorn Server is still in beta testing and that this article is not intended to walk you through a real world deployment, we don’t have to worry too much about the semantics involved in setting up an enterprise certificate authority. The only real requirement is that you will want to make sure that the server that will act as a certificate authority and the server that will act as a Terminal Service Gateway Server both exist in a forest that is separate from your production forest. You would never want to do this in the real world, but for demonstration purposes, you can even run the Enterprise Certificate Authority services on the same physical server as the Terminal Server Gateway Services.
If this were a real world deployment, you would want to put some serious thought into your certificate server. There are a couple of reasons for this. First, if someone were to gain access to your certificate server then they own your network. Therefore, the security of your certificate server would need to be an extremely high priority in a real world environment. I know that in this day and age, security is always a concern, but when it comes to a certificate authority, you need to go way above and beyond when it comes to security.
Likewise, if you were planning a real world certificate authority, reliability and fault tolerance would also have to be an extremely high priority. Obviously, nobody ever wants to have a server to crash, especially if that crash happens to result in data loss. This is especially important with a certificate authority though. The keys that a certificate authority contains are used to encrypt data. If you encrypt a bunch of data and then lose the keys, then under the right set of circumstances you could lose the ability to decrypt (access) your data. You therefore want to make sure that your certificate authority is well protected against hardware failures and data loss.
In this case though, we are installing the certificate authority in a lab environment for a single purpose, so we really don’t have to worry about all of the usual precautions (again though, make sure you are using a dedicated forest). That being the case, I am just going to walk you through the process of getting a certificate authority up and running as quickly and easily as possible.
Begin the process by opening Longhorn Server’s Server Manager and select the Manage Roles option from the console tree. Next, click the Add Roles link found in the Roles Summary section of the console. This will cause Windows to launch the Add Roles Wizard. Click Next to bypass the wizard’s Welcome screen. You will now see a list of all of the available roles. Select the Active Directory Certificate Server option from the list. Although it may appear that way at first, the roles are not listed in alphabetical order, so you may have to read through the whole list to find the service. Click Next to continue.
At this point, you will see a screen that introduces you to the certificate services and provides you with some words of caution. Click Next to ignore this screen and you will see another screen that asks you which components you want to install. Select the Certification Authority and the Certificate Authority Web Enrollment check boxes and click Next.
You will now see a screen that asks you if you would like to create an enterprise certificate authority or a standalone certificate authority. Choose the Enterprise Certificate Authority option and click Next. You will now be prompted as to whether this server should act as a Root CA or as a Subordinate CA. Since this is the first (and only) certificate authority in your lab, you should choose the Root CA option. Click Next to continue.
The Wizard will now ask you if you want to create a new private key or if you want to use an existing private key. Again, this is a lab setup, so choose the option to create a new private key and click Next to continue.
The next screen that you will encounter asks you to select a cryptographic service provider, a key length, and a hash algorithm. In a real world deployment these are all things that you would want to carefully consider. Since we are setting this certificate authority up solely for demonstration purposes though, just go with the defaults and click Next.
The next screen that you will see gives you a chance to define a common name and a distinguished name suffix for the certificate authority. Again, just go with the defaults and click Next.
You should now see a screen asking how long the certificates should be valid for. The default time period is 5 years, which is fine for our purposes, so just click Next. The next screen that you will see asks you where the certificate databases and the corresponding transaction logs should be located. In a production environment, choosing an appropriate location is critical to fault tolerance and security. Since this is a lab though, just go with the defaults and click Next.
You will now see a screen detailing the options that you have selected. Click the Install button and Windows will copy the necessary files and configure the underlying services.
In Part 3 of this article series I will continue the discussion by showing you how to request a certificate and then map that certificate to the Terminal Services Gateway Service. For right now though, I am assuming that you probably want to be able to verify that the Certificate Authority installed correctly (aside from the confirmation message when the installation process completes).
The easiest way to make sure that the Certificate Authority is working correctly is to open your Web browser and go to the Certificate Authority’s URL. When you do, you should see a Web page containing several options pertaining to the certificate authority.
The URL is HTTP:// followed by the server’s fully qualified domain name, and /CertSrv/Default.asp. For example, while researching this article, I installed the certificate services onto a server named LONGHORN-DC. That server is a domain controller in a domain named EXCH12.COM. As such, my certificate Authority’s URL is: http://longhorn-dc.exch12.com/certsrv/default.asp
If you would like to read the other articles in this series please see: