Windows ACI: Stu's weeping

That we will utilize Microsoft's Active Directory (AD) to manage our server instances and users (accounts and profiles) has been the assumption from the beginning of this experiment. How best to accomplish this is a very challenging question. Hence the label: "Stu's weeping".

There are several reasons for using AD as part of our management strategy. First, it facilitates a single sign-on (SSO) solution. Without it, users would first need to log into the TS Gateway and then to their individual Terminal Server instance. Second it allows us to centrally manage user accounts, user profiles, and user and server configurations via group policies. And it permits us to leverage our existing management practices and procedures.

If we moved to production and on average only supported 2-3 TS instances and 5-25 user accounts, well then this would probably be overkill. However, we believe that if successful, we will likely be supporting many TS server instances with potentially hundreds of user accounts.

We've spent the better part of the last several weeks working to figure out whether the better approach is to create an AD structure within the cloud or try and join our cloud based servers to the University's test AD forest, under the ICPSR Organizational Unit (OU). We believe the better route is to join them to our on premise AD but it has been more difficult than anticipated for a variety of reasons which I'll explain in the next post.

Windows ACI: Terminal Server Gateway

I've elected to setup a Terminal Server Gateway as the entry point for access to the ACIs. This server role was introduced with Windows Server 2008 and provides several benefits that will help with the management and security of the ACIs. First and foremost, a TS Gateway provides a means to encapsulate the Remote Desktop Protocol (RDP) traffic through an SSL tunnel using HTTPS over port 443. In turn the TS Gateway facilitates a standard RDP connection, over port 3389, to the requested resource. This allows us to configure the firewall of our cloud service provider account and the individual server instances to isolate the ACIs to only be reachable via the TS Gateway and a few IP addresses here at ICPSR. The TS Gateway also provides for the implementation of client and resource access policies to control which resources can be accessed and by whom, therefore we can restrict access to individual ACIs to strictly the users identified in the associated research request. Additionally, the TS Gateway can be configured to utilize a Network Access Protection (NAP) health policy. This technology allows for us to define client "health" condition in order to be permitted to connect, for example that the client's firewall is enabled, current for operating system security patches, has anti-virus software.

Implementation of this server role should help to simplify support in a production scenario where there could be a large number of ACIs active at any given time.