Skip to main content

How to Setup a Remote Desktop Gateway Windows Server 2016

Accomplished systems and network administrator with 10+ years of experience managing server infrastructures and data-center operations.



This tutorial will go through the steps of implementing a Remote Desktop Gateway on a Windows Server 2016 server. A Remote Desktop Gateway is often used to allow remote desktop clients to connect from the internet to servers behind the Remote Desktop Gateway located on the corporate network. The Remote Desktop Gateway acts like a “jumphost” except it never hosts the users remote desktop connections. It checks to see if a user belongs to a group that is allowed to remote in and checks to see if a user is allowed to remote into the destination server before allowing the session to the destination server.

Summary of Steps Required to Configure a Remote Desktop Gateway Windows Server 2016

The following is a summary of the steps required to configure a Remote Desktop Gateway on Windows Server 2016. Use it as a checklist to ensure everything has been covered.

  1. Join the Windows 2016 server to the Active Directory domain.
  2. Add the Remote Desktop Services role.
  3. Create a Connection Authorization Policy. This policy specifies which groups are allowed to access this Remote Desktop Gateway.
  4. Create a Resource Authorization Policy. This policy specifies which servers are allowed access by which groups.
  5. Purchase an SSL Certificate from a public Certificate Authority. (You can search the web to find where to purchase this from. No free advertising on this SPACE)
  6. Apply the SSL Certificate to the Remote Desktop Gateway.
  7. Accept the default Remote Desktop Gateway TCP Port of 443 or change it to another port number.
  8. Test the Remote Desktop Connection to a server behind the Remote Desktop Gateway DIRECTLY from the Remote Desktop Gateway server. This is to ensure that there is connectivity from the Remote Desktop Gateway to the servers that clients will need to connect to.
  9. Modify Firewall Rules to allow the Remote Desktop Gateway port to the Remote Desktop Gateway server.
  10. Test the Remote Desktop Connection to a server behind the Remote Desktop Gateway from the internet. You need to configure the Remote Desktop Client with the Remote Desktop Gateway address and port number. NOTE: Older versions of Remote Desktop Connection that came with Windows 7 and Windows 2008R2 has settings for a Remote Desktop Gateway but it doesn’t work. It is good practice to download the latest version of Remote Desktop Connection to use.

    To learn how to configure a Remote Desktop Connection client to use a Remote Desktop Gateway, you can follow

Detailed Steps to Configure a Remote Desktop Gateway Windows Server 2016

The following tutorial shows in detail how to configure a Remote Desktop Gateway on Windows Server 2016.

Adding the Remote Desktop Services Role

Open Server Manager and click on Add roles and features.

Click Next

Click Next

Choose role-based or feature-based installation and click Next

Choose role-based or feature-based installation and click Next

Click on a server in the server pool and click Next

Click on a server in the server pool and click Next

Select Remote Desktop Services then click Next

Select Remote Desktop Services then click Next

Click Next

Click Next

Adding the Remote Desktop Gateway Service Role

Click Next

Click Next

Select Remote Desktop Gateway and click Next.


A window will come up if we want to add features that are required for Remote Desktop Gateway. Click on Add Features.


Click Next.


Click Next for installing the Network Policy and Access Services.


Click Next for adding the Web Server Role (IIS).


Accept the default selections for the Web Server role services and click Next.


Click Install.


Installation successful.


Create the Connection Authorization Policy and the Resource Authorization Policy

Open the Remote Desktop Gateway Manager. This is done from the Tools menu from Server Manager.


Create Authorization Policies for RD Gateway

In the left pane, navigate to Policies, click on Connection Authorization Policies. On the Actions pane on the right, right click Create New Policy, and select Wizard.


Select Create a RD CAP and a RD RAP (recommended) and click Next.


Connection Authorization Policy

The Connection Authorization Policy ensures only selected groups ( i.e., group members) are allowed to use the Remote Desktop Gateway to access resources behind the Remote Desktop Gateway. You can use groups based on active directory users or groups based on the active directory computer objects. To provide flexibility in terms of what machines users can remote desktop from, I recommend using user groups.

Give the policy a name. An intuitive name is Allowed-To-Use-RDGateway, click Next.


Click Add Group.


For the purposes of this tutorial, I will select the Domain Admins group. Normally you would create another user group which you add users that you want to allow to use the Remote Desktop Gateway. You can create groups based on what resources the users need to access. In this way, you can add those groups here, and then use these groups in the Resource Authorization Policy later on.


We won’t use the client computer group membership. This option lets you allow connection based on computers that clients are connecting from. These computers need to be domain joined and that domain is in some ways related to the domain that the remote desktop gateway is a part of. Click Next.


Accept the default setting for device redirection, and click Next.


Enter the timeout values as per below. Click Next.


Click Next.


Create Resource Authorization Policy

The Resource Authorization Policy is used to restrict access to servers based on group memberships. You will need to create active directory groups and add servers as members of these groups. Ideally these groups are created based on functionality or by department ownership. These groups of servers are the network resources that must be assigned to user groups for the users to be able to access them.

You can create multiple Resource Authorization Policies to granularly assign certain users access to certain servers.


Select User Groups which are allowed access to network resources i.e. can remote desktop to servers on the network. For this tutorial, I will select the Domain Admins group as I have already selected Domain Admins as the group which can use the Remote Desktop Gateway. Then click Next.


Select a group that contains the servers that you want the above user groups to be able to remote desktop to.

Click Browse.


For this tutorial, we will use the built-in group called Domain Controllers. You can create additional groups containing servers that are related or belong to particular departments. In this way, in the previous steps you can assign groups based on department users and allow them only to access particular servers.

Click Check Name to make sure the group is found, and then click OK.


Click Next.


If the remote desktop port on the servers were changed from the default, use this screen to specify the port. Otherwise, select Allow connections only to port 3389. Click Next.


Click Finish.


Click Close.


SSL Certificate

The Remote Desktop Gateway needs to have an SSL certificate installed. You can purchase an SSL certificate for the fully qualified internet domain name of the Remote Desktop Gateway or purchase a wild card SSL certificate for the domain.

To install the SSL certificate, firstly click on the remote desktop server name in the Remote Desktop Gateway management console.


If you’ve purchased and received the SSL certificate, copy it to any location on the server. Select Import a certificate into the RD Gateway and browse to the certificate to import it.

I haven’t purchased an SSL certificate for this tutorial so I will use a self-signed certificate. It will allow the Remote Desktop Gateway to work from some clients, such as the Microsoft Remote Desktop for Mac, but we will be prompted with a warning about the certificate when we try to connect. We can choose to continue after that.

However, it will not work with the latest windows version of the Remote Desktop Connection client (there is a work around for the purposes of testing).

You MUST use a trusted SSL certificate in your Production Remote Desktop Gateway and this means purchasing a public SSL certificate.

It is possible to setup your own PKI infrastructure in your active directory domain and assign your own SSL certificate and if the client machine is part of the domain, it should trust your domain’s CA. However, Remote Desktop Gateway environments are often used to allow external contractors who have their own laptops to be able to use the network resources. Therefore, it is best to use an SSL from a trusted root authority.

For this tutorial, we will generate a self-signed certificate by clicking on Create and Import Certificate .


Enter the FQDN internet name of this Remote Desktop Gateway for the Certificate name e.g. . For this tutorial, I will use the internet IP address that will be associated with this server.


We have now successfully installed a self-signed SSL certificate on TCP Port 443 (Default SSL port).

We can change the SSL port for the Remote Desktop Gateway to another port number. This is sometimes done by companies to try and trick hackers who may be targeting port 443 because that’s the default SSL port.

To change the SSL port number for the RD Gateway, right click on the Server name and select properties in the Remote Desktop Gateway management console.


We will change the port to 4430. We will use this port in our tutorial so you will get an understanding of how to configure a different port number in the Remote Desktop client.

Change the port number and click OK

Change the port number and click OK

Click Yes to apply changes

Click Yes to apply changes


Testing the Remote Desktop Gateway Server Can Access Network Resources

We must test connectivity from the Remote Desktop Gateway to the network resources that clients will need to connect to. Specifically, we need to test RDP traffic by using remote desktop client to connect to the allowed servers.

We’ve allowed the domain controllers to be accessed by the Domain Admins group through the Remote Desktop Gateway, and we’ve allowed the Domain Admins group to be able to use the Remote Desktop Gateway by using the Authorization policies. We will now test connecting to the domain controllers from the Remote Desktop Gateway.


We’ve confirmed we can reach the domain controllers from the Remote Desktop Gateway.

Now we need to ensure that external clients can reach the Remote Desktop Gateway.

Configuring the Firewall

Because we are going to be connecting to the Remote Desktop Gateway from the internet, we will need to modify the firewall to allow access to the Remote Desktop Gateway Port.

In the preceding steps, we had changed the TCP port to 4430 for the Remote Desktop Gateway. This means we need to allow TCP Port 4430 inbound on the firewall and to the destination port 4430 on the Remote Desktop Gateway.

If we had used the default port of 443, we would need to allow TCP port 443 instead.

Configuring the Remote Desktop Client with the Remote Desktop Gateway Settings

When configuring a remote desktop client that supports the Remote Desktop Gateway, and you will be connecting using the remote desktop gateway, always remember that the Computer name of the server you want to connect to is the local server name that is resolvable from the Remote Desktop Gateway.

When entering the Remote Desktop Gateway details in the client, you need to specify the port if you are not using the default SSL port of 443. In our case, we need to enter as the Remote Desktop Gateway server. Had we use the default port, we just need to enter the FQDN without the port number e.g. .



This concludes the steps involved in setting up the Remote Desktop Gateway Windows Server 2016. You will now be able to configure a remote desktop client to connect using the Remote Desktop Gateway.

NOTE: Make sure you use the latest version of the Remote Desktop Client as I have seen an earlier version that came with Windows 7 not able to connect even though it has settings for a Remote Desktop Gateway.

I will write up a follow up article on how to configure a remote desktop client to use the Remote Desktop Gateway.

Related Article

  • How to Install Remote Desktop Services Windows 2016
    This tutorial will show how to install Remote Desktop Services in Windows Server 2016 but it can be applied to Windows 2012 or Windows 2012R2. The steps are based on a scenario where there is currently no Remote Desktop Services for Windows 2012 or l

This article is accurate and true to the best of the author’s knowledge. Content is for informational or entertainment purposes only and does not substitute for personal counsel or professional advice in business, financial, legal, or technical matters.

© 2018 sengstar2005


sengstar2005 (author) from Sydney on July 11, 2020:

Hi Ordinary_user, rolling the CA out via GPO via AD requires the machines to be Domain joined. If all the users are going to be using company supplied laptops that are domain joined, that should be fine.

As for security, different companies will have different ideas and methods. I’ve done an implementation where the user has to VPN in first and the user can not access anything after that without going via the RD gateway as a second barrier.

Ordinary_User on July 07, 2020:

No need to buy an official SSL cert, a self signed is ok too or your own PKI e.g. OpenSSL can do this and you can roll out the CA via AD.

And better to force users to use a VPN, this gateway thing is more security by obscurity and leaves the real problem, insecure RDP protocol, not solved.

Specially as the IIS setup won't be much helpful without further restrictions, e.g. client certificates. In the end on has dozens of services running which need care where a well designed network and VPN's can solve problems very well.

Newbie on June 22, 2020:

Just posting back for info, in case anybody else wants to do the same. One way to go is to use a reverse proxy such as NGINX to pool the devices and still connect through the gateway by using a generic hostname.

Newbie on May 22, 2020:

Hi, this is a great how to and it is taking my half way to where I want to be. I can route RD sessions through the gateway successfully by specifying the exact hostname (physical desktop PC). What more do I need to be able to specify a generic hostname that will then automatically connect the client to one of many available desktop PC (physical devices)? Do I need the services installed?

sengstar2005 (author) from Sydney on May 08, 2020:

Thanks for your comment Pedro.

Pedro Moreno on May 08, 2020:

Just commenting to expose my opinion on this tutorial. Helped me 100%, I managed to create my RDG

Thank you very much, excellent tutorial

sengstar2005 (author) from Sydney on March 18, 2020:

Hi Nikhil, sorry for the late reply. In RD Gateway Manager, you can right click on RD Gateway Manager, and select Connect to RD Gateway Server.

Nikhil on September 17, 2019:

I have installed the RD Gateway but in RD gateway manager, there is no RD Gateway server is available.

Mat3000 on July 18, 2019:

Thank you! This helped me alot. I have read seldom such a great tutorial.

Raja on July 02, 2019:

Hi, im currently stuck at Connection Authorization Policy, i cannot add name. Does the RD gateway server need to join domain in PDC? i have a PDC server in my network. Thanks

sengstar2005 (author) from Sydney on May 28, 2019:

Hi TomHigg, I think it's a balance between best practices vs costs. If you have a mission critical data centre servicing clients 24 x 7, then in most cases, you will have to put in at least 2 of everything i.e. 2 x internet connections (with different providers), 2 x firewalls acting in HA mode, 2 x switches, 2 x servers (for the same function) with your servers having one physical connection to each of the 2 switches. With regards to RD Licensing Manager, you don't need to install on a DC. It makes sense to piggy back onto a DC because a DC should always be up and running. If you already have a jumpbox, you may not need to put in an RD Gateway. But RD Gateway have the advantage of being able to restrict what your external users can access on your internal network. With a jumpbox, the users logged into the jumpbox usually can access any resources which the jumpbox can see.

TomHigg on May 16, 2019:

Thanks for a wonderful tutorial !

What are the best practices for setting up a Remote Desktop Server in terms of installing the below on a single server or multiple servers?  What are the advantages and disadvantages ?

- Remote Desktop Gateway

- Remote Desktop Session Host Server

- Remote Desktop Connection Broker

- RD Web Access server

- RD Licensing Manager

It is a hardcore requirement to install the RD Licensing  Manager on a Domain Controller(DC) or is it good to have ? What if my Domain Controller is on a different server from Licensing Manager? I already have an existing DC in my environment.

I am already using a Jump-box in my environment, do I still need a RD Gateway ?

aca on April 02, 2019:

Don't forget to register NPS server in AD

sengstar2005 (author) from Sydney on January 23, 2019:

Yes, it should work for 2012r2 also.

Chris on January 23, 2019:

Will this work with 2012 R2?

Seems similar

sengstar2005 (author) from Sydney on October 16, 2018:


Jonas on October 11, 2018:

Thanks for the excellent guide, it has been very helpful. A tip is to have two network interfaces, one for the outside and one for the inside.

sengstar2005 (author) from Sydney on August 15, 2018:

Hi Baster, I am not sure how you have set this up, but I suggest you follow the checklist in the tutorial to help you with your troubleshooting. Also, the following article shows how to configure an RDP client to use the RD Gateway :

Baster on August 14, 2018:

I have configured the remote desktop gateway, and when accessing through the external network, I always prompt the user name and password error. Is there any error in my configuration?

K.Miller on August 13, 2018:

Great Tutorial.

The only step I struggled with was the installation of the self-signed certificate because it needed to be installed in the Trusted Root Certificates. Once I got past that, I was good to go!

Thanks for all your hard work in making this work.

sengstar2005 (author) from Sydney on July 19, 2018:

Hi Lucas, please follow my article. The scenario is for configuring Remote Desktop Gateway so external users can access internal resources. The whole point of RD Gateway is so you don’t need VPN. And yes, for Production, BUY an SSL certificate from well known third party. The first part of the article summarizes the steps needed. You can use this as a checklist, to make sure you cover everything. The second part expands on each point with explanations.

Lucas on July 19, 2018:

Hi Sengstar2005, thanks for you tips. But I need to configure my server to be able access from external enviroment? Right?

sengstar2005 (author) from Sydney on July 19, 2018:

Hi Jun, if you mean those 5 users are going to remote desktop into your remote desktop server, you can install the RD CALs on your RD Licensing Server. Your remote desktop server needs to point to your RD Licensing server.

sengstar2005 (author) from Sydney on July 19, 2018:

Hi Lucas, I will assume that it's a certificate issue as you would have made sure the SSL port was opened as well to the Remote Desktop Gateway. If you are using an SSL certificate signed by your domain's CA server, firstly, make sure the "external" server name of the remote desktop gateway you used in your Remote Desktop Client is in the SSL certificate. Since you would have the "internal" server name of the RD Gateway in the certificate already, then you would have to add this external name as a Subject Alternative Name (SAN) in the certificate. This way, you can use two different DNS names and the SSL certificate would be valid for both the names. Since this external machine is not on your domain, after you installed the new SSL certificate with the SAN name on the RD Gateway, you will have to export this SSL certificate and import it into the Computer's Personal Certificate store. Then you will also need to export your CA's certificate and import it into the Computer's Trusted Root Certification Authorities certificate store. Basically, this is one way I know of to get around purchasing a third party SSL certificate, and to make your PC trust the SSL certificate.

Lucas Amorim on July 19, 2018:

To tell you the truth, I've already made countless attempts here.

But to confirm what you said, yes. On my internal network it goes normally, but when I'm on an external network, outside of my domain, even though I can ping my server, I can not access it.

Jun on July 18, 2018:

I have 5 users outside the company to connect to my server? Where can i install the CAL user license? thank you.

sengstar2005 (author) from Sydney on July 18, 2018:

Hi Lucas, without seeing or knowing your setup, I can only guess at what you have done. So I am assuming that your Remote Desktop Gateway works from machines in your domain on the internal network, and you have installed either a self-signed SSL certificate or an SSL certificate issued by your internal CA server on the Remote Desktop Gateway?

Lucas on July 18, 2018:

I'm having trouble getting external access. Internal was ok. But externally I can not access, what should I do to get external access over VPN and without Ceritifcate?

sengstar2005 (author) from Sydney on July 18, 2018:

Can you translate to English?

martin chung on June 24, 2018:

Thanks Seng. That came in handy ;)

lolix on June 21, 2018:

OK, got it ; HTTPS...

lolix on June 21, 2018:

Great Tutorial. Thanks.

I don't understand why the Web Server role is required.

sengstar2005 (author) from Sydney on June 15, 2018:

Thanks Norm. The systems in the tutorial was also setup within AWS.

Norm Bagley on June 14, 2018:

Thank you! This was one of the best and most straight forward articles on this subject! I was able to take the information and with some good troubleshooting, set up a Windows Bastian Host (RDP Gateway) jumpbox for accessing our Systems within AWS Cloud.