Last month, a customer located in Norway reached out to us at RDS Gurus, regarding a project they were starting. They had an existing, aging Citrix XenApp 6.5 environment in place and due to the costs to upgrade and maintain such environment, they decided to investigate if a plain Microsoft RDS environment would be able to deliver what they needed.

According to them (please note, these are their own words, not mine) after reaching out to several consultants and consulting firms in Norway, pretty much all of them gave the same verdict: RDS would not be able to deliver it.

So there we were, with a customer certainly moving away from Citrix and being told RDS would not cut it. Before explaining what the project was and the requirements, I want to make one thing very clear: I have nothing against ANY EUC product and/or vendor. That said, I have no formal ties to any of them and the bottom line (one more time) is, sell to your customers the right solution to the job. That is the most important thing. In this particular case, if Citrix had to be the product of choice for whatever reason, I would be the first one telling the customer he was insane and that RDS would suck for that particular case.

With that out of the way, this is what we were presented with…

• Three types of users:
  • External: connecting from external locations (i.e. home) but using their own clients, therefore considered ‘unmanaged’.
  • External over VPN: connecting from anywhere but in this case using a company (‘Company 1’) provided machine (‘managed’) and establishing a VPN first, before accessing any corporate resource. Updates/etc are enforced/pushed to these.
  • Company 2: these are users from a ‘sister-like’ company. Their network is connected to the ‘Company 1’ network and is considered ‘trusted’. They use machines considered ‘managed’. Like their own endpoints, updates/etc are enforced/pushed to these by ‘Company 2’.
• Three application ‘sets’.
  • Internal. Applications that are available on the ‘Company 1’ internal network. This is a controlled network but with most things available to the users/apps (i.e. internet access).
  • Secure. Applications considered sensitive. These reside on a separate network segment, with way more restrictions (i.e. no internet access).
  • Secure Restricted. Same as secure but with further restrictions in place and potentially only available to users flagged as ‘Company 2’ users.
• MFA requirements.
  • Users connecting from the outside with their own machines must have MFA. They only access ‘Internal’ apps. No access to ‘Secure’ ones.
  • Users connecting from the outside with ‘Company 1’ managed machines over VPN should not have MFA, unless they try to access ‘Secure’ applications.
  • Users connecting from the ‘Internal’ network should be able to access ‘Internal’ and ‘Secure’ apps but MFA must be there if trying to reach ‘Secure’ apps only.
  • Users on the ‘Company 2’ networks should be able to access ‘Secure’, ‘Secure Restricted’ and ‘Internal’ apps, with no MFA. Also the FQDN they will use with be something like ‘whatever.company2.com’ with a certificate provided by them.
• Ideally, have all this in a single ‘RDS’ deployment. Different collections for the different application sets but all under a single deployment. Yep, you read that right.

Note: ‘Company 1’ users will always hit an FQDN like ‘whatever.company1.com’.

With all that in mind, this is what we came up with (and I will explain the logic and tweaks behind it):

First of all, yes, this is indeed a single ‘RDS’ deployment. Two ‘RDS’ Connection Brokers with a SQL back-end for redundancy.

Three ‘RDS Session Collections’. One ‘Internal’, one ‘Secure’ and one ‘Secure Restricted’. Multiple ‘RDS’ Session Hosts to cope with the load and for redundancy purposes as well.

One ‘RDS Web Access’ pair for the ‘Internal’ (managed) users, another one for the ‘Internal’ but unmanaged ones (so for people coming from the internet, no VPN) and another one for the ‘Company 2’ users. The ‘RDS Web Access’ pairs had their code tweaked so when a user connects to the ‘Internal’ RDWA pair over the internet (no VPN), he does NOT see the ‘Secure’ apps, even though he is a member of the required group. When he connects over the VPN using a managed client, even though he uses the same URL (rds.company1.com) due to split-DNS, he reaches another RDWA pair and in this case, after logging in, he sees both ‘Internal’ and ‘Secure’ apps. Users from ‘Company 2’ hit rds.company2.com and after logging in, they see ‘Secure’, ‘Internal’ and ‘Secure Restricted’ apps.

Two ‘RDS Gateway’ pairs for the ‘Internal’ (managed’) users, with MFA enabled in one pair (going to ‘Secure’ apps). Another pair for the ‘Internal’ users (unmanaged) with MFA and finally another pair for the ‘Company 2’ users, with no MFA. Microsoft Web Application Proxy servers are in front of the RDWA/RDGWs used for ‘Company 2’ access (so they handle their certificate and pass traffic back to the servers behind them).

The main trick with the RDGWs, is to use PowerShell to set a specific RD Gateway for a particular collection (Set-RDSessionCollectionConfiguration). This allows you to have a gateway that has MFA for a particular collection and one with no MFA for another.

On the RDWAs as already mentioned, the code had to be modified to hide certain apps depending on the RDWA pair.

The end result is a thing of beauty that does pushes RDS beyond its limits and certainly way beyond what Microsoft ever thought would be possible with its own platform.

If that is supported by Microsoft, it is another story. Also as many will notice, if you do use the RDMS to change anything, you may break the RDGW settings for a particular collection. Therefore the customer has to be aware of these potential drawbacks and may need to use another tool to manage the environment (what many do already, considering the POS that RDMS is).

At the end of the day, this works and works great. Proof that when you have screws there is no need for that hammer.

CR