Remote Desktop Gateway for Workstations

Introduction 
We recently built a Microsoft Remote Desktop Gateway, formerly known as Terminal Services Gateway, for a client. They’re a smaller office and not quite ready for a full-on Remote Desktop Server (Microsoft has replaced “Remote Desktop” for “Terminal” in many of these terms) or Citrix server. The task was to provide gateway services to Windows 7 workstations on the internal office network.

At first we tried also using Remote Desktop Web Access to present the remote connections to the end-users, but the best it offers is a field into which the user must type in the name of the desired internal workstation. That just wouldn’t have been seamless enough and would have undoubtedly lead to calls to the Help Desk. Therefore we discarded that idea and just created our own static web page that lists all the workstations available, complete with descriptions. This page gets rebuilt automatically by a script which extracts all such machines from Active Directory. The script is run as part of workstation build or decommissioning procedures in order to keep the list refreshed.

The gateway technology is a commercial strength remote access solution and is the same used for the full-blown Remote Desktop Server suite, however the presentation part of the solution shown here is more of a cheaper quick and dirty way to present the links to the end-users on a web page. The underlying technology is just as secure, but we are saving money by not having an actual Remote Desktop Server to which to connect, and only connecting to powered on workstations in the office. Further savings are realised because no Terminal Services Client Access Licenses (CALs) are required for this solution.

Environment

The client has about ten internal Windows 7 Professional laptops and desktops. There is a Windows Server 2008, R2 which is a DC and runs DHCP, DNS, file, print, anti-virus push, and WSUS. For this project we purchased a new server to act as Remote Desktop (RD) Gateway and to take on and replicate a few roles from the other server. It is an HP DL360 G7 single processor box with 8gb RAM and RAIDed disks. The load for these services is very small, so of course this could have easily been installed to a virtual machine, had that environment been in place. We installed the Windows Server 2008, R2 operating system.

Remote Desktop Services

We added the Remote Desktop Services role and only the Remote Desktop Gateway role service plus its minimum required features.

• At the initial wizard we selected to choose the SSL certificate later and also to create the authorisation policies later.
• We decided to install the Network Policy Server role service onto this server, and so let the wizard do so.
• We let the wizard install the required Web Server role services, selecting those shown to the right. 

Digital Certificate

• First in IIS Manager and selecting the server in the left pane, we selected Server Certificates in the centre pane and went through the create and complete certificate request procedures. We made sure to purchase an external common third-party certificate so that the associated root certificates would already be on most computers out there. The common name of the certificate must match the URL that users will be typing or directed to when connecting for remote access.
• Then in RD Gateway Manager we right-clicked on the server object and selected Properties. In the SSL Certificate tab we clicked Import Certificate and selected the recently installed one above. 

CAP and RAP

A Remote Desktop Connection Authorisation Policy (RD CAP) determines which users can connect to the RD Gateway and a Resource Authorisation Policy (RD RAP) determines to which resources in the network they can connect.

• Still in RD Gateway Manager, expand the server object, then Policies, and select Connection Authorisation Policies.
• In our case, we created one CAP only, using the Windows Password authentication method and allowing only users that are members of the “RemoteGateway” user group we had created for this purpose. We disabled drives, ports, and plug and play device redirections. We set an idle timeout of 30 minutes and a session timeout of 240 minutes, after which sessions are disconnected. Obviously all these values are down to preferences.

• Then in RD Gateway Manager select Resource Authorisation Policies.
• We used the same user group we defined above and allowed users to connect to computers in the “RemoteDesktops” Active Directory (AD) group. We kept the default port of 3389 for allowed connections.

Landing Web Site

The Web Role and associated Role Services were already installed as prerequisites for the Remote Desktop Gateway role service. The digital certificate was also already added, above. Static pages were then created to welcome users and to list available internal workstations (available in AD, not necessarily connected and powered on).

• A “/remote” virtual directory was added to the Default Web Site, with its physical path at “d:\ServerApps\RemoteDesktops”.
• The remote virtual directory has the “.reg” extension added to MIME Types with type “application/octet-stream”. This is because there will be a registry file for client Windows computers to import, discussed later.
• The directory also has Require SSL checked and is set to ignore client certificates. It has Windows Authentication (only) enabled with the “Negotiate” and “NTLM” providers listed in that order. Extended Protection is off and Kernel-mode authentication is checked.

• A sub-folder. “/remote/Desktops”, was added. It also has its SSL and authentication settings set as above.
• The remote/Desktops sub-folder has the “.rdp” extension added to MIME Types with type “application/x-rdp”. This is the page that will contain all the pre-created RDP (Remote Desktop Protocol) files that will connect to each internal workstation.
• The sub-directory is also configured to enable its contents to be browsed from a web browser. Ensure that the resulting “web.config” file is itself hidden (via the file system) so that it does not appear in browse results.

To configure MIME Types, Directory Browsing, and SSL Settings in the folders above, launch IIS Manager and select the relevant folder in the left pane. The pertinent icons will appear in the centre pane.

Web Site Contents

The landing page has some instructions to end-users to run the one-time registry import if it’s the first time they are accessing this gateway from their current client computer, a link to registry import file, and a link to the remote/Desktops sub-folder. Here is the registry file:

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\RDP.File]

"EditFlags"=dword:00010000

"BrowserFlags"=dword:00000008

[HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\PublisherBypassList]

"a long hexadecimal number"=dword:00000044

This sets up two things on the client Windows computer: it suppresses the prompt that would normally occur when downloading a “*.reg” file in Internet Explorer and it suppresses a second prompt to trust running the file from the file’s publisher. The RDP files will be digitally signed with the hash of the same certificate the web site uses, therefore “published” from that site. That hash number replaces “a long hexadecimal number” in the registry file above.

The remote/Desktops sub-folder simply contains all the RDP files, one pointing to each computer inside. The names of the file include the name of the workstation and also a description so that end users will be able to identify their computer. This web site sub-folder is configured to simply list these files as a directory listing rather than to display a web page.

The RDP Files

Remote Desktop files can be created in a text editor such as Notepad, or created using batch files or scripts. It’s best to start the base or template file by launching Remote Desktop Connection, clicking Options, and filling in all your preferred settings in all the GUI tabs. Important fields:

• computer: the internal DNS name of the computer to which to connect
• user name: as this is a remote access solution, it would be more secure to leave this field blank
• local resources: as this is a remote access solution, it would be more secure not to allow drives and plug and play devices to be available in the remote session
• display and local experience: the lower the resolution and experience, the lesser the latency, a personal choice

Then Save As the file. Now the file can be edited with a text editor. Some important fields to double-check below:

full address:s:internal DNS name, does not necessarily need to be fully qualified

authentication level:i:0

prompt for credentials:i:0

negotiate security layer:i:1

remoteapplicationmode:i:0

gatewayhostname:s:fully qualified domain name of the gateway, matching the certificate and URL

gatewayusagemethod:i:2

gatewaycredentialssource:i:0

gatewayprofileusagemethod:i:1

promptcredentialonce:i:1

connection type:i:2

redirectdirectx:i:1

use redirection server name:i:0

alternate full address:s:internal DNS name, does not necessarily need to be fully qualified

The next step is to digitally sign the RDP file. This is done by command line:

rdpsign.exe /sha1 “a long hexadecimal number without the quotes” /v NameOfRDPfile.rdp

The hash number is obtained from the “thumbprint” field of the digital certificate and also matches that in the registry file to import above. Once the file is signed, it can no longer be edited.

Managing the RDP Files

We created a script to manage these files. Our assumption is that all internal workstations be available for remote access via the gateway, but not the servers (we access these via SSL VPN instead). The script extracts the names and descriptions of all computers from the “Desktops” and “Laptops” AD Organisational Units (OUs). Each computer name plus its description becomes the name of the resulting RDP file. For each file the script echos out most values described above including the unique computer name, and digitally signs the file. It then adds the workstation to the “RemoteDesktops” AD group.

So our procedure when building a new workstation includes placing it in either of the OUs mentioned above, keeping the description field of the AD object of the computer short, simple, and understandable to end-users (for example, “Jessica - TP X220” - cannot include commas, etc, as it becomes part of a file name), and running the script. We also run the script after decommissioning a workstation and removing it from AD.

These scripts could probably be taken further. A script could probably be run when users connect to the web site (I’m not a very strong web person), which could then audit and refresh the list of workstations. They could also do a PING to each machine to ensure that it is online before adding it to the list.

Access from the Internet

The server running RD Gateway and the web site resides on the internal network. The firewall has a 1-to-1 NAT mapping an external address to the internal, and it allows port TCP:443 to the external address. That is the only port needed, which makes this such a nice solution. Port 443 is allowed out from virtually every other internal network in the world. Obviously, there is also an external DNS entry for the fully qualified domain name of the gateway, the one that matches the digital certificate and the URL.

End-User Experience

There is a portal web page in the client’s DMZ. On it are two links: one for web-mail to the cloud hosted Exchange and the other to the remote access web site described above. This link is the URL which matches the digital certificate.

Once connecting to the remote access site, the user is prompted for their AD (Windows domain) credentials. The domain name is required here, so the user must either type in “Domain Name\User Name” or in our case we have trained them to use their e-mail address. (We have an additional AD User Principle Name matching the domain name used for e-mail, and each user account has this set as their User Logon Name.)

They see the instructions and if they have not used this before from their current computer, they click on the “One-time setup” link, which imports the registry file. Then they click on the “List of computers” link, and from there they select their chosen workstation. Again, the computer must actually be at the office, connected, and powered up. Once they click the link, they are prompted for user credentials a second and last time from the RD Gateway, and then they are presented with their full Windows Desktop at work.

Users must be trained to Log Off when done and not to simply close the window. It keeps things more seamless and clean.

Limitations

This is quick and basic solution that uses a convenient and secure method of connection. Limitations:

• The workstation must be in the office, connected, and powered up. A user can either take their laptop home or leave it in the office for accessibility via remote access, but not both.
• This solution is geared strongly for Microsoft client computers. The registry import file is specifically for Internet Explorer. Mac users must be given a Mac-equivalent RDP file already configured. It connects directly to the RD Gateway, bypassing the more user friendly and centrally manageable remote access web site.
• Users must log on twice.
• There are still some features available in a Citrix solution that are not available in a pure Microsoft environment.

Next Steps

The next step would be to add an RD Server, complete with the RD Session Host, RD Licensing, RD Connection Broker, and RD Web Access role services. The existing gateway server would continue to be used as is and it would also host the additional role services apart from the RD Server itself. Once users become used to connecting to the RD Server only, we could do away with access to individual workstations. Single sign-on would be available, but it would still be geared strongly to Microsoft clients.

The best solution, of course, is Citrix's XenApp solution, complete with their Access Gateway product. The existing gateway server would have its RD Gateway roles removed, but the server could then host the internal portion of Citrix’s Access Gateway and also its Web Interface. Citrix provides a more seamless, configurable, and flexible solution over-all, and it works very well from Mac or Unix clients.