Remote Desktop Services 2016, Standard Deployment – Part 8 – RD Gateway

Remote Desktop Gateway is a very important component of the RDS deployment, because if we go with a traditional remote desktop scenario, the external user would connect through the firewall to the connection broker, which would then pass them on to the Remote Desktop Session Host, which means the first place the user gets challenged for credentials is at the Remote Desktop Session Host, at which point they’re well inside the company network. So when we deploy Remote Desktop Gateway, this is a server that sits usually in a DMZ or a perimeter network that acts as a middle-man. The external user connects to the Remote Desktop Gateway. They are authenticated by the Gateway, and the Gateway makes sure that they have permissions to access internal resources. Then, once all that’s been verified, the Remote Desktop Gateway passes the connection to the Remote Desktop Connection Broker, which in turn connects the client to the Remote Desktop Session Host.

PORTS / PROTOCOLS / REQUIREMENTS

The Gateway sits in the middle, so historically the idea was that all the traffic going between the Gateway and the client is done using HTTPS SSL, which means we only have to open port 443 in the external firewall. Because UDP is used to set up the transport, you’re going to have to open up a UDP port in the external firewall so that you can get the connection made to the RD Gateway. Now the RD Gateway always continues to proxy a communication, so that communication comes in over HTTPS, the RD Gateway strips away the HTTPS and then makes the connection to the connection broker using the Remote Desktop Protocol, and that proxying continues to happen for the entire conversation. And then once it’s connected to the connection broker it gets passed along to the Remote Desktop Session Host, but remember RD Gateway remains the middle-man.

The requirements for an RD Gateway, first of all, it must be joined to the domain because it has to authenticate and authorize corporate domain users and resources. You also have to open up a number of firewall ports.

On the external firewall you have to open up:

TCP 443 –> to allow HTTPS traffic to the RD Gateway.

UDP 3391 –> When using Server 2012 and above you also have to open up this port which allows the transport to create that connection.

On your internal firewall you need to open up:

TCP 88 –> for Kerberos, which is the Active Directory Authentication protocol.

TCP 135 –> RPC Endpoint Mapper so we can communicate with Active Directory.

TCP & UDP 389 –>  which supports LDAP, which is also used to talk to Active Directory to authenticate the user.

TCP &UDP 53 for DNS

RDP 3389 –>  so that the RD Gateway can forward RDP packets from the client

Port 80 –> HTTP

Port 21 –>  for FTP to contact the CRL, unless you’re using HTTP for the CRL

If you’re using RADIUS or RADIUS Accounting, you need ports 1812 or 1813. So a lot of ports have to be opened up in those firewalls for the communication to go back and forth. The idea is that very few ports need to be opened up in the external firewall because we want to make as small a hole as possible for the client to come in. In the internal firewall it’s not so bad because it’s just from the Remote Desktop Gateway to all of these ports.

Our first step is to install RD Gateway role. Access your Connection Broker server and be sure to add your gateway server to all servers. I will install RD Gateway role on RDGW01. In the Remote Desktop Services node you will notice that RD Gateway is not set-up and you can start configuring it by clicking on green icon marked on the picture below.

Select the server from your server pool and click on next

Now as we’re going through the wizard, it’s going to create a self-signed SSL certificate. We actually don’t want a self-signed certificate, but we’ll go ahead and make one just for now, and in a little bit we’ll see how we can replace that with a trusted certificate. So I’m just going to give it the name of the Remote Desktop Gateway, which is rdgw01.nm.com, and then we’ll hit Next and click ADD

And once we’ve succeeded in adding it, you can see right down here it tells you we need to configure the certificate, but we’re going to do that in a little bit. We’re going to go ahead and click Close, and now we do have an RD Gateway.

 

RD GATEWAY AND DNS SETTINGS

External clients must be able to resolve the name of the RD Gateway to the right IP address using DNS. If you’re using a NAT router, that would be the external IP address of the NAT router closest to the internet, and you would need to configure port forwarding. If it’s a firewall, it would be the external IP address of the firewall that connects to the internet, and you would need to open ports 443 and 3391 and there is also split-brain DNS option if you are using it. In split-brain DNS, there are two different DNS servers that are authoritative for the same zone.

CONFIGURING CERTIFICATES FOR RD GATEWAY

First of all, the certificate names much match the external name of the RD Gateway. When you’re using certificates for identification, there has to be an exact match between the entity you’re contacting and the name of the certificate. So let’s say the real name of our server is rdgw01.nm.com, but out on the internet we’re going to point people to rd.nm.com. We need to make sure that the rd.nm.com name is on that certificate.

The client must trust the certificate, and remember, trust means really two things, the CA certificate must be in the Trusted Root Certification Authorities store on the client, and the client must be able to contact the CRL, Certificate Revocation List, to make sure that the certificate is still good. So you need to make sure that you jump through all the hoops in order for the client to do that, so that when you’re setting up that external firewall or NAT router, make sure you not only take into consideration ports that you need to allow through for Remote Desktop Gateway, as we saw we want to go through and make that name of that Certificate Authority accessible via DNS out on the internet so that the client knows where to send those CRL queries.

Now if you want to use the certificate for more than one role, you can also create a certificate that would have a wildcard and be good for anything that ends in nm.com.

I have a wildcard so I will use it for all roles. Now very important to know is that there are two ways to apply certificates to the RD Gateway Service. First way is to open Server Manager and click on Tools –> Remote Desktop Services –> RD Gateway Manager

Right-Click on your server and select properties

Here we have SSL tab, now I can actually go in and click Import Certificate, and because it’s in the store it’s listed there. The disadvantage of this is that it only applies to this particular Remote Desktop Gateway server, so if there’s more than one, only this server will have the certificate.

The right way of configuring cerificates in RDS is to do this through the Deployment Properties. On the RDS node click on the Collections –> Tasks –> Edit Deployment Properties

We’ll go over and click on Certificates, and you can see that they’re not configured because they’re just using the self-signed. Click on Select existing cert and configure it

Once done it should show Trusted

Now let’s try to connect using RD gateway. When you connect to Session Host probably one of the only ways we can tell that the user is successfully coming through the RD Gateway is to login to RD gateway server Tools –> and click on Remote Desktop Services –> Remote Desktop Gateway and if you expand the server you will see Monitoring. Click on that and you will see users that connected through the RD Gateway.

 

RD CAPs and RD RAPs

The last piece we have to look at that’s absolutely critical just to getting the Remote Desktop Gateway up and running would be RD CAPs and RD RAPs.

Let’s start with RD CAPs

Remote Desktop Connection Authorization Policies

They specify what users are allowed to connect through the RD Gateway. And the way I always remember it is RD CAPs, the C is for connect, so who is going to be able to connect. When we installed the role it created a default RD CAP that’s used unless I change anything or make RD CAPs of my own. So let’s take a look at what’s inside the RD CAP. Double-Click on the CAP policy

GENERAL –> here we can see if the policy has been enabled and we can go here to disable it.

REQUIREMENTS –>  Requirements specify what requirements they need to get through the Gateway, so by default they need a password. I could also force them to use a smart card if I have smart cards in my environment. I can specify particular user groups. Notice by default all Domain Users are allowed in. Maybe you don’t want that, you want to change that to specific users, and I can even require that the client computer be a member of a group as well.

DEVICE REDIRECTION –> by default, allows redirection for all clients. If I wanted to disable it if they’re coming through the Gateway, I have the option to come down there and disable selectively different things that I don’t want redirected.

TIMEOUTS –>  very similar to what we saw in the sessions, a session idle timeout or a complete session timeout, and then if I actually check the session timeout, what will happen after that timeout is reached. Now if you don’t timeout the session, they’re going to be able to come through, pretty much unlimited and that may cause a problem. Specifically if you need to make changes to an RD RAP, you should have the session timeout in the RD CAP because that way once they need to reconnect, the new RD RAP will be in effect. So those are our RD CAPs, but again, the main deal with RD CAPs is who is allowed to connect.

Now the RD CAPs go hand in hand with the Resource Authorization Policies or the RD RAPs.

Remote Desktop Resource Authorization Policies

RD RAPs, specify what resources users are allowed to access through their Remote Desktop Gateway. So RAPs, R is for resources. What are they allowed to connect to? So let’s open up the default one that was made for us. You will notice that we have 2 RAP polices. Let’s first discuss about AlldomainComputers

RDG_ALLDOMAINCOMPUTERS POLICY

GENERAL –> Here we can enable the policy or disable it.

USER GROUPS –>  it needs to specify the same user groups that are specified in the RD CAP, even though it’s the CAP that really allows them to come through, it’s also specified in the RD RAP and of course you would modify this in the production and remove domain users

NETWORK RESOURCE –-> So right now it’s saying any computer that’s a member of Domain Computers is a resource users are allowed to connect to if they come through the Gateway. I can actually select an RD managed Gateway group or create a new one. And this would have a little bit more security, so if I were going to do this I’d create a group that would contain my specific session host server specially if I am hosting and sharing this across multiple customers. (If you are running earlier versions you will need to add connection broker as well in that group)

ALLOWED PORTS –> by default, we are allowing connections only to port 3389, which is the default port for Remote Desktop. We could specify particular ports or we could allow connections to any port.

 

RDG_CONNECTIONBROKERS POLICY

This policy is very helpful because when admins start to remove and modify default RDG_AllDomainComputers group in many cases they forget to add connection broker server to the group as well. (I will add second RD Connection Broker later and configure High Availability so that you see how third policy for HA looks like)

 

RD GATEWAY SERVER PROPERTIES

Let’s right-click on our server and explore server properties.

 

GENERAL –> here we have the ability to configure the maximum number of connections that are allowed to connect to this RD Gateway. If you are concerned with server performance, we can set a hard limit of allowed simultaneous connections. We can also disable new connections if we are performing scheduled maintenance on our server

SSL CERTIFICATE –> We already talked about this. Here we can import the SSL certificate but the disadvantage of this is that it only applies to this particular Remote Desktop Gateway server, so if there’s more than one, only this server will have the certificate.

TRANSPORT SETTINGS –> Here we can change the HTTP and/or UDP Transport ports. Now when you change the ports, the HTTP and/or UDP transport port number that the listener rules within the firewall will be modified. So what that means is it’s going to automatically adjust the firewall on the Remote Desktop Gateway to listen for the new port. All active sessions will be disconnected, and then the RD Gateway Service will be restarted. Now if you choose to do this, you’re going to need to do some additional configuration. So custom ports require RDP Client 8.0, which is Windows 2012, Windows 8, or Windows 7 with Service Pack 1 with RDP 8 Protocol update. Any of those clients can automatically adjust for the new port. If it’s an older client, theoretically you could put a colon and put the port number in there, but it doesn’t work that great, so you want to make sure that you have clients that will support changing the ports. The other problem that you’re going to run into is that RDMS, so the Remote Desktop Management Service that you see in Server Manager, does not receive the update. So any published RemoteApps and Desktops are not going to work anymore because they’re still trying to connect to the RD Gateway port 443. So you’re going to have to go through and update the collection to have these RemoteApps and Desktop sessions listen on the correct port

RD CAP STORE –> If you are running NPS on this server you can leave it set to local server running NPS. If you have another server that’s doing NAP then you would want to choose central server running NPS and enter the name or IP address of the server that’s in charge of NAP. By using a central server running NPS for RD Gateway, you can centralize the storage, management, and validation of RD CAPs.

SERVER FARM –> If you need to provide high availability for Remote Desktop Gateway, you could create a Remote Desktop Gateway farm. All the members of the farm need to be added to the properties of the Remote Desktop Gateway, and as of Server 2012, DNS Round Robin is no longer supported. When you have a farm it kind of works like this: Each member of the farm has its own individual name and IP address. But when you use Network Load Balancing to create a farm, the farm itself has a name and an IP address, and this is the only time where you’ll see a duplicate IP address on more than one computer, so each of the members of that farm have the farm IP address. We point the clients to the name and IP address of the farm, and then whatever the client sends out is given to all of the members of the farm, and they actually run an algorithm and they know which member of the farm is going to service the client.

AUDITING –> allows you to select or deselect events that you would wish to log. These corresponding events are stored in Event Viewer under Application and Services Logs\Microsoft\Windows\Terminal Services-Gateway. By default, all items under the Auditing tab are selected to be captured and logged.

SSL BRIDGING –> it allows that external firewall or whichever firewall is involved, to inspect inbound traffic. And what it does is it terminates the HTTPS connection at the firewall, the firewall inspects the packets, and then forwards them to the RD Gateway.

There are 2 types of SSL Bridging: HTTPS –> HTTPS and HTTPS –> HTTP

HTTPS-TO-HTTPS –> The firewall decrypts the packet so it terminates the HTTPS connection from the client, and inspects them for malicious code or other attacks, but the packet is then re-encrypted and sent to the RD Gateway using SSL. Now the great thing about this is it’s secure. The only bad thing about this is you’ve got to re-encrypt it, so the firewall is going to have to have the same certificate as the one installed on the RD Gateway, and not only the certificate, but also the private key, but you’re going to have the most security that way, a little bit more overhead.

HTTPS-TO-HTTP –> The firewall decrypts the packets and inspects them for malicious code or other attacks just like it does in the other type of bridging, but the channel between the firewall and the RD Gateway is unencrypted. This is not as secure, but it does have an advantage where it allows the firewall to do the decrypting, which may improve performance on your RD Gateway, because any time you get into encrypting and decrypting, it takes more processing. One thing to know, when you’re doing HTTPS to HTTP bridging, the firewall is also going to authenticate the user. If you remove that firewall and you do not disable bridging on the RD Gateway, then the users will not be authenticated, so just keep that in mind.

MESSAGING –> it allows administrators to send messages to the users. You can either have a message that’s displayed every time they log on, or you can also send maintenance messages, which are delivered to users who are already logged on.

 

RD CONNECTION BROKER HIGH AVAILABILITY RDG POLICY

I configured RD Connection broker HA so that we could see the new policy that was added to RD Gateway.

If we open the new policy we will see that it gives us access to an RD Gateway Managed group called RDG_DNSRoundRobin that holds the RD Connection Broker FQDN

If we open the collection deployment properties we will see that RDG_DNSRoundRobin policy matches High Availability settings in Server Manager. This is really useful addition to the RDS Deployment.

That’s it. I hope you enjoyed reading. We covered RD Gateway role deployment, protocols, ports, RD Gateway policies (new policies that are added to RD Gateway), server properties etc. and I hope that after reading this you have better understanding on how RDG works.

Thanks for reading!

Cheers,

Nedim