Hello. In this video I'll demonstrate the steps needed to set up a Remote Desktop Services Gateway Server. An RDS Gateway Server is useful if you want to allow access to your RDS environment for users that are outside the corporate firewall. An RDS Gateway Server uses SSL to encrypt the communication between the clients and the RDS servers.
This is possible thanks to a certificate installed on the RDS Gateway Server that is trusted by the end user’s device. Another piece of the RDS Gateway component is IIS, which is used for authentication. Thanks to IIS we can create certain policies to granularly define which users should have access to what resources. I will show that later in this video as well. This demo assumes that an RDS deployment already exists.
If you need more information on setting up a basic or advanced RDS deployment from the ground up I suggest to check out the previous videos in this series. Here I'm showing the virtual machines that I will use. ‘RDSlab-DC’ is a domain controller. It also has the RD Licensing role installed. All other VMs are joined to the domain hosted in this domain controller. ‘RDSlab-CB’ is the connection broker for the deployment. ‘SH1’ and ‘SH2’ are the session hosts in the farm. This other virtual machine I've named ‘RDSFarm’, and it is the machine that I will configure as the RDS Gateway Server. It also hosts the RD Web Access role. I created this RDS environment using these five PowerShell lines, which I've included in the video description, and that I've discussed in previous videos.
So, to set up the RD Gateway server I will open the console to the virtual machine that hosts the Connection Broker role for the deployment. Open ‘Server Manager’ and click the ‘Remote Desktop Services’ node. The servers section shows that all roles are configured for this deployment except for the RD Gateway role. This is why this role appears with a green plus sign here under the overview section, indicating that it is pending to be deployed.
To set it up, let's first add the role to the target server. Click ‘Manage’ then ‘Add Roles and Features’. Select ‘Role-based or feature-based installation’, I'll select the target server for the RD Gateway role in this deployment and then click ‘Next’. Expand ‘Remote Desktop Services’ and click the ‘Remote Desktop Gateway’ checkbox. Click ‘Add Features’ to install the prerequisites, and then ‘Next’ onto the confirmation screen and finally ‘Install’. Wait for it to finish installing and then click ‘Close’. Back in Server Manager, if I click to refresh the deployment there's no change. This is because the binaries have been installed, but the deployment itself hasn't been configured with an RD Gateway Server.
So, to fix that click the green plus sign above ‘RD Gateway’ to start the wizard. Select the server that will be configured as the RD Gateway, move it to the right-hand side, and then click ‘Next’. This wizard will ask to configure a self-sign certificate and I need to enter the Fully Qualified Domain Name of the subject on that certificate here. This is not the certificate that I will use for this demo though. For now, click ‘Next’. Click ‘Add’ to confirm the addition to the deployment. Wait for it to finish installing the role, and then notice the warning indicating that a certificate needs to be configured but click close for now. Refreshing the deployment one more time shows that there's now an RD Gateway Server present under ‘Deployment Overview’ click ‘Tasks’ and then ‘Edit Deployment Properties’. Notice that the ‘RD Gateway’ section has been automatically configured with some settings. Click on the ‘Certificates’ node and notice that there's no certificate configured for the RD Web Access, nor the RD Gateway roles. I will click the RD Gateway role first. Here's this option to create a new certificate.
For testing purposes it is possible to use a self-signed certificate created here, or like the one that was automatically created earlier in the Wizard. For this demo I will configure a certificate from a trusted public certification authority. That way this certificate does not have to be installed on the client computers; they will just trust it out of the box. So, I will click ‘Select existing certificate’ here. I need to enter the path to the certificate. For this demo I've copied it to the root of the C drive in the domain controller. I will then enter the password with which it was saved, click to check this ‘Allow’ check box, and then click ‘OK’. Notice the ‘Ready to apply’ state in the deployment configuration screen.
So, let's click ‘Apply’. After a few moments the screen shows that the operation completed successfully, and the level column recognizes the certificate as trusted. If I were using a self-signed certificate, it would show differently. We would apply the certificate but it would show as untrusted and I would have to copy that certificate to the client computers and then install it. This is one of the main benefits of using a domain-based, or a public certification authority certificate as is the case in this demo. Clicking here in ‘View Details’ shows the subject of the certificate which happens to be the Windows host name of the RD Gateway Virtual Machine. I will repeat these steps for the RD Web Access role, that way that same certificate is used for IIS. Then click ‘OK’ to exit the deployment configuration screen.
That's all we need to do in the connection broker. The next step is to configure a connection authorization policy and a resource authorization policy. I will talk more about this as I create them. I will switch now to the RDS Gateway Virtual Machine. Open Server Manager, click ’Tools’, ‘Remote Desktop Services’ and then ‘Remote Desktop Gateway Manager’. First let's adjust the server properties under the ‘Server Farm’ tab. Let's add this RD Gateway Server and click ‘Apply’.
This error about a load balancer is expected. I'm not load balancing the RD Gateway service in this demo, it's just the one RD Gateway Server, so just click ‘OK’, ‘Apply’ one more time and the status shows now as ‘OK’. In the ‘SSL Certificate’ tab I can view and make changes to the certificate configuration of the RD Gateway server, even create a new self-sign certificate if I needed to. All of this however has been configured already in the connection broker so I will click ‘OK’ to exit out of the property screen. Back in the main screen of the RD Gateway Manager I'll expand the server and then ‘Policies’.
There are two types of policies in this context as shown here ‘Connection Authorization Policies’ allow you to specify who is permitted to connect to this RDS Gateway Server whereas ‘Resource Authorization Policies’ allow you to specify what servers or computers will the authorized users have access to. Simply put, one policy is for who will have access and the other for what will they have access to. Right click ‘Connection Authorization Policies’ then click ‘Create New Policy’ and then ‘Wizard’. You can create the policy separately, but I will follow the recommended option here, which is to create both the Remote Desktop Connection Authorization Policy and Remote Desktop Resource Authorization Policy in the same wizard and click ‘Next’. Enter a name for the RD CAP, click ‘Next’, click ‘Add Group’ and then enter the name of the group containing the users that will be allowed to connect. I will enter ‘Domain Users’ for this demo and then click ‘Next’. I leave the defaults in the ‘Device Redirection’ and ‘Session Timeout’ steps by clicking ‘Next’ on both screens, as well as in the summary screen, and then proceed with the RD Resource Authorization Policy. Enter a name, click ‘Next’.
Leave the default in the ‘User Groups’ section, then click ‘Next’. Again, here in the ‘Network Resource’ screen, if I had an Active Directory group containing the computer accounts of the session host servers of this RDS deployment I could specify. For this demo however, I will just choose the ‘Allow users to connect to any network resource or computer’ option and then click ‘Next’. I will leave the default of port 3389 for internet gateway to the RDS session hosts communication, and then click ‘Next’. Click ’Finish’ in the summary screen, and then click ‘Close’. So, at this point this RDS Gateway Server is ready to be placed beyond the firewall, facing the internet users. A user trying to connect to the RDS Session Hosts from a home or remote office location over the internet would need to go first through this RDS Gateway server.
I will show here on this client computer connected to the internet over a link that is completely separate from that of the RD Gateway Server how a remote user would need to set up the connection on the Remote Desktop Connection app. I will first enter the name of the RD Session Host let's remember this session host is not internet facing, so click on the ‘Show Options’ button, ‘Advanced’ tab and on the ‘Connect from anywhere’ section. Click ‘Settings’. Click the ‘Use these RD Gateway server settings’ radio button and enter the public DNS name of the RDS Gateway.
For this to work, of course, this public DNS name should resolve to the public IP address assigned to the RDS Gateway machine. This is something that needs to be configured in the settings of the public DNS service in use. I will also click to uncheck ‘Bypass RD Gateway for local addresses’ and to check use my RD Gateway credentials for the remote computer, as those are the same credentials for both machines. Then click ‘OK’ and ‘Connect’. Enter the domain username and password, and we can see that the connection succeeds. Notice that we did not have to install any certificate on the client machine.
There wasn't any message neither warning us about trusting the machine the client wanted to connect to. This is because the certificate that we are using is from a trusted Public Certification Authority. Back at the RDS Gateway machine in RD Gateway Manager and under ‘Monitoring’ we can see the connection details. Also, in Event Viewer in the Terminal Services Gateway operational log notice a series of events documenting the steps. Event 312 shows the initiated connection from the client computer event 200 shows that the credentials used met the connection authorization policy. Event 300 shows that the resource authorization policy was also met therefore access is authorized, and finally event 302 shows that the connection succeeds and that the connection protocol is HTTP.
This is because traffic between the client and the RDS Gateway is happening over HTTPS which uses encryption for secure communication. If the RDS Gateway machine is behind a firewall or net device the only port that needs to be allowed in is 443. This is actually what I did in this router device used for this demo. It has just been configured to port forward Port 443 to the RDS Gateway machine. So, this has been a demo on how to integrate an RDS Gateway server to a standard Remote Desktop Services deployment, to allow for secure encrypted access from a home or otherwise public internet location.
I hope you find it useful, and I’d like to thank you very much for watching.
