RDS 2016 farm creation with high Availability and Autoscaling – Part 3

What is promised is debt! Therefore, this new blog post is a continuation of the two previous entries made by our partner Hugo Margallo, where he has been explaining in detail how to build a Windows Server 2016 farm using the roles of Remote Desktop Services and deploying on a hierarchical infrastructure in Cloud of 4 servers, in this new post we will complete the information explaining what it is and how a Certification Authority is created step by step and in a completely detailed way so that you have no doubt, are we going for it?

1. Certificate Authority

We already have the 100% functional RDS farm. All domain users can easily access any of the computers in the “Remote Desk” collection in a balanced way and with high availability (thanks to the use of brokers). However, Windows will be warning us at all times that we may not be accessing the place we want, either because the equipment is not identified correctly or because the source equipment (from which we access the farm) results a complete stranger.

This is where certificates come into play, in the same way that happens with web pages, and their operation is not very different.

We assume that both the computers and the users that will interact in the RDS farm will be part of the same domain, so it is simply necessary to have certificates that, in some way, are authorized only and exclusively within the domain itself, lacking all validity beyond that context.

As expected in Windows Server, this is achieved using a role, and this role must be installed on one of the machines in the domain, not requiring more requirements than being on and with the service running at the time it is Create team or user certificates (the latter is really useful for “Code Signing“). It is important that all machines that are part of the RDS farm have access to this machine, although not all users must necessarily have access.

We access the domain team where we want to install the role, and then the Server Manager. Once inside, we give “Manage” and “Add roles and characteristics“, from here the steps are the same as always, not needing another action to give “Next.” When we get to the list of roles, we mark the one that says “Active Directory Certificate Services“, as the capture shows:

When you click on “Next”, in the window that opens we click on “Add Features”. We return to “Next” without checking anything in the feature selection menu. Once we have reached the “Role Services” selection menu, we select only “Certification Entity” (this is enough for this example). We click on “Next” and then on “Install”, a progress bar will indicate the situation.

Once finished (it does not require a restart), we can see that in the menu on the left of the Server Manager the section “AD CS” has been added, which if we access it will show us a warning message that we have pending configurations:

For now, we do not need to access the specific “Certification Authority” menu. Simply click on the flag icon in the upper right corner of the Server Manager, which will show a “Warning” sign and then click on “Configure Active Directory Certificate Services“, which will open a new wizard. The first thing will be to select the user with whom we are going to perform the steps, which can be whatever “Admin. Of the Domain”, and we give “Next ”. In the next menu we mark “Certification Entity” only, for now it is no longer necessary. Then we select “CA Independiente” (Standalone in English). It would also be worth the business, but in this case it is necessary. In addition, the Standalone CA also serve us for WORKGROUPS. Later we select “CA Root”, since it is the first certificate we are creating and we do not need intermediary certificates. Then we select “Create a new private key”, since, in theory, based on this example, we don’t have any more. The menu regarding certificate encryption can be left as is, although it may require other configuration according to the security needs of the domain. We give “Next” and specify the name for the certification body, in this case “EnimbosCA”.

We can see how its suffix CN fits in AD to the name we have put:

We give “Next” The period of validity is customizable, although in this case we will leave it as it is, in 5 years. Click on “Next” and then again on “Next“. We will be shown a summary of everything we have selected. If it seems all right, we will click on “Configure”. If everything went well, we can access the specific menu of the Certification Authority. Click on “AD CS” in the menu on the left of the Server Manager and then click on the second button on the name of our server. In the context menu we select “Certification Authority” and a new menu will appear with our available CA certificate, called EnimbosCA.

If we deploy the CA and give “Certificates issued“, we see that there is none.

The next step will be to create equipment certificates that are authorized by this CA. This certificate must be configured to be shown in the access by RDP, so that the source equipment will be trusted by the destination computer and will not display a warning message. It should also be added in the brokers and in the Publish Profile, since we saw in the previous post that a “warning” was shown because the “editor” of the RDP file was unknown or unreliable. It also happens when accessing the DNS of the brokers.

On the destination computer where we want to configure the certificate, click on the magnifying glass on the taskbar and type “mmc“, click and enter. In the new menu we must give “File” and “Add or remove add-ons“. In the next menu we will select “Certificates” and click on “Add”. In the window that opens, it is important that we select “Team Account” and “Local Team” as it will be the certificate that will identify our team. We will see a menu similar to this:

Click with the second button on “Personnel/Certificates” and select “All tasks/Request a new certificate“. We click on “Next” until a window appears where we are given the choice of the type of certificate we want. In this case “Team” We can configure several parameters by giving “Details“, but in this case it is not necessary. We click on “Enroll” and the process will begin. If everything went correctly, we can see the certificate in the list and we can also see that it has been authorized by the CA we created before, instead of being self-signed.

The next step will be to configure that certificate to be shown in the access by RDP.

On the machine where we have created the certificate, we open a CMD window as Administrator and copy and paste the following command:

wmic / namespace: \\ root \ cimv2 \ TerminalServices PATH Win32_TSGeneralSetting Set SSLCertificateSHA1Hash = “THUMBPRINT”

We haven’t launched it yet, because we have to know the thumprint or fingerprint of our certificate. To do this we return to the previous menu, to “Personnel/Certificates” and double click on our certificate. In the new window, we select the “Details” tab and go down to the “Fingerprint” field, where when we click it we will see a series of hexadecimal characters in the box below.

All these characters must be selected and copied with CTRL + C. It is convenient to paste them in a notebook beforehand, because we must eliminate all the spaces. Once done, we change the word THUMBPRINT from the previous command to the characters we have obtained. When you launch it, something similar to this should be displayed:

Now we will no longer have warning messages on access to that equipment by RDP.

Now we just have to configure the certificates of the special servers of the farm, such as brokers and rdweb. The process of creating the certificate in the rdweb is similar to the RDHost equipment of the farm, unless you want to use a different DNS name to access the website that publishes the RDP files. For example, if our machine that has the role of web server in the farm is called “enimbosweb” (name that would appear in Active Directory as enimbosweb.enimbos.local, for example), we can create a certificate following the previous method, and it would be worth for those cases in which we would like to access that website by entering in the browser https: //enimbosweb.enimbos.local (the configured DNS suffixes could autocomplete the complete address from “enimbosweb”), but we may be interested in the URL be of the type “granjards.enimbos.local“, because that way transparency is gained and users and / or administrators will not know the name of the machine and the URL describes only and exclusively the service that interests them, without needing know more.

In that case it is necessary to create certificates using another method, one that is simple and allows us to enter a custom “CN” value, so we would make the FQDN and the certificate CN coincide regardless of whether the machine offered the service. In addition, this method is mandatory in brokers with HA, since it is necessary to reference a DNS shared by both servers and not one that refers to only one, because, even if we were still maintaining high availability, the equipment that access the farm would be “ trusting ”in one broker and not in the other, therefore, a certificate whose complete CN is that common DNS is necessary.

A simple way to do this is through IIS (Internet Information Services), which is not a problem because the machine that has the role of RDWEB has that service installed. We access that machine and open the IIS Manager, which we can do by searching the taskbar or by accessing “Control Panel/Administrative Tools” Once inside, in the menu on the left (“Connections“) we can see the name of our web server, click on it. In the menu shown on the right we can see the option “Server Certificates“, which we access with double click. We will see a menu similar to this, where we must choose the menu option on the right that says “Create domain certificate”:

A wizard will start where we must enter the certificate data, such as your common name, the organizational unit, etc. That data will depend on each particular case, but it is important that the common name matches the entire DNS name.

After filling in those fields, we click on “Next” and we will have to select the CA, which we will not have to enter manually, but we will click on “Select” and choose it. Then, we must add a friendly name, which will be, as a rule, the common name that goes before the first point (enimbosweb, for example, instead of enimbosweb.enimbos.local). We click on “Finish” and the certificate will be created. We can see that now appears in the list. Now we just need to export it, so we will click with the second button on it and select “Export” in the context menu. The following will be to indicate the name and path of the file and specify a password for the private key. Ideally, save it on a shared route, like the one we created in the previous entry with SMB. It will be saved, unless otherwise indicated, in “pfx” format. Once exported, we must go to the Domain Controller or the domain server where, centrally, we manage the RDS farm. In our case we are using the first domain controller.

We access that machine and then the Server Manager. In the menu on the left we click on “Remote Desktop Services” and then, on the right, in “General Information”. We can see a graphic scheme of the RDS farm, click on the upper right corner of that box in “Tasks” and then “Edit implementation properties“. In the new menu, we must access the “Certificates” section.

We have to select the services one by one. The first refers to the certificate that will identify the team in each of the brokers. Once selected, click on “Select existing certificate” and, in the new window, we will select “Choose a different certificate”, where we will indicate the path where the “.pfx” ​​file is and enter the password specified before. It is important to check the box below so that the import can be done. Once we have clicked on “Accept”, we just have to click on “Apply” in the previous window. We should now see how “Trusted” is indicated next to the service as a level. In addition, we can also see information about the certificate below and even click on “see details” to see more. Then we repeat the same process for the service below, which refers to the Publisher or editor of the RDP files that we download from the RDWEB. This certificate can be the same as the previous one or a new one can be created for this case. With these two steps we prevent messages like this from appearing when executing RDP files:

In the case of not putting a correct certificate in the Publisher, the message would be similar to when we run unknown applications in Windows.

The last step would be to do it for the rdweb service and, as we have already said, we can do it by creating a certificate for the name of the machine or for the DNS name that we have chosen personally. Anyway, it will be a secure https connection.

These certificates are also subject to expiration and we will have to take them into account to make a renewal when necessary.

In the next post we will discuss the topic of autoscaling of RDHost machines in AWS, where it will be necessary to combine Powershell scripts with scheduled Tasks.

In the next entry we will explain the autoscaling function using Powershell scripts and Scheduled Tasks.

Related Posts