Implementing Duo for RDGateway without affecting existing RemoteApp?

[solmssen]

Hi all - looking for a little guidance here.

We have a Win2016 Hyper-V host that is not domain-attached running a Win2016 AD server VM called AD01 and a Win2016 RD server VM called ACT01. The ACT01 VM has all the RD roles – RD Gateway, RD Session Host, RD Web, RD Connection Broker, and RD Licensing, and is running a single LOB application – Act. Users in the same location as the server are running local copies of Act on their PCs to talk to the database on ACT01, and we have three branches that are on site-to-site VPN with 2-3 users each running Act via RemoteApp from the same server – not coming through the gateway, just doing straight RemoteApp sessions from their computers over the VPN. We also have about 4 users occasionally using the Remote Desktop Gateway for work-from-home – they are logging in through the gateway to either remote to their office PCs from home, or in one case, just run a RemoteApp session of Act. I also use the RD Gateway to administer ACT01 and the other VMs via RDP for full desktop sessions. I use a CAP/RAP policy to lock down the users that can use the RD Gateway and the machines they can talk to, and I make sure they have good passwords, etc., but it’s long past time to get everything all 2FAed up.

Also running on the Hyper-V server is a completely different virtualized network on a private virtual switch – I completely virtualized their 18-year-old accounting setup. It’s a separate AD domain with its own Win2008R2 AD server, a Win2003R2 server running MSSQL 2000 and Great Plains 8.0 ERP/Accounting, and 6 Win7 Great Plains clients. The users RDP into the Win7 clients from their desktop PCs and run Great Plains from there. I know, I know, but I did what I had to do to keep things running – this was all physical machines when I started with these folks. At least now it’s behind a pfSense firewall that doesn’t let anything in or out except the RDP sessions from the local office PCs to the GP client VMs. And now we are finally in the process of moving to a cloud-based ERP/accounting solution, and the people implementing that want access to the production accounting system. I was hoping to use ACT01 as a jump host – they RDP through the RD Gateway to ACT01, and from there RDP to a Win7 GP client VM that I’ve set up for them on the private virtual network.

What I want to do is 2FA the RD Gateway – so anyone using the gateway from the internet has to use 2FA. I don’t want to make the branch users using the RemoteApp version of Act from ACT01 to have to 2FA – they’re already on machines in the physical stores that are on the VPN, and presumably OK – if not I have bigger problems. But I want anyone coming into the RD Gateway from the internet have to 2FA to get an RD session, either to RemoteApp to ACT01 to run Act, to get a desktop session to use it as a jump host, or to connect to their desktop PCs.

I tried installing Duo for RD Gateway, and it worked pretty much the way I was hoping to talk to any of the other machines behind the gateway - I started the connection, got a push, OKed it, and was able to login to the AD01 server and a couple of other machines. But RDP sessions to the ACT01 server itself started and just died after the push notification was approved. It worked for other machines – I got the push, approved, and logged in. But attempts to login to the RD session host with a desktop session or a RemoteApp session even from within the network, not through the gateway, would send a push, I would approve, and then the session would just close. I thought maybe I needed to install Duo for RD Web as well, and I tried that, but the install just hung before I got to the part where it asks for the keys. I was running out of time in my maintenance window, so I rolled the machine back to a pre-Duo RDG install checkpoint and we’re back at square one.

Any thoughts about the inability to login to the machine Duo was running on? Any thoughts in general? Send brickbats and attaboys my way please…

[solmssen · Accepted solution]

Replying to my own thread here because it’s now moot - I got it working. I reinstalled Duo for RD Gateway, and it’s now behaving exactly the way I want. Logins coming through the RDG are denied if not Duo-enrolled, and the RemoteApp sessions are working as expected - you get a Duo prompt if coming through the RDG from the internet, but not if coming directly to the RD session server from a local or branch machine that’s on the VPN. I don’t know why it wasn’t behaving this way the first time, but it’s working now and I’m much happier.

[BabbittJE]

I also use Duo for RDG/Duo Access Gateway. Just be aware that DAG disables the CAP/RAP stuff. That became an issue when I tried to publish an app in RemoteApp. Rather, I had to build a new RDG then publish the app in RemoteApp then install DAG. But, if I need to publish a new app, I’ll have to do this again. Uninstalling DAG doesn’t help.

[solmssen]

I just tried it and you’re right. Duo why is this so hard to make work right?

[BabbittJE]

It’s because DAG is no longer being maintained. They suggested using their cloud-based one instead of their deprecated on-premise one. I have yet to make that transition as everything is currently working very well at the moment. Maybe I’ll transit to the new cloud-based one the next time I have to publish a new app in RemoteApp.

[solmssen]

can you explain what you mean by “cloud-based one”? I just installed Duo for RDG, I’m not wedded to it, and if there’s a better way to do this I’m all ears.

[DuoKristina]

Just be aware that DAG disables the CAP/RAP stuff.

I’m confused by this statement @BabbittJE . Duo Access Gateway (DAG), Duo’s on-premises SAML IdP, has nothing to do with Microsoft’s Remote Desktop Services.

Installing DAG does not disable RDG CAP/RAPs. Installing Duo’s plugin for RD Gateway totally does disable RDG CAPs/RAPs. Neither DAG nor Duo SSO (the cloud-based successor to DAG) publish remote desktop applications.

I can understand that you might have issues trying to colocate a DAG install with an existing RD Gateway install because they are both IIS apps and we didn’t really design DAG with a shared IIS host in mind, but it should not be the case that installing DAG renders RD Gateway totally functional except that it disables CAPs and RAPs.

Something that you might want to check out is that Duo Network Gateway (DNG) can now provide access to RDP servers as of 1.6.0 (as a public preview feature). Previous DNG versions supported web applications and SSH server access. Learn more about this new functionality here: Protect RDP Servers with Duo Network Gateway. This means that it’s possible to replace RD Gateway for external to internal RDP access with DNG.

[BabbittJE]

Sorry for the confusion but I installed both Duo for RDG and DAG. Yes, my DAG has nothing to do with Duo for RDG. It’s the latter that disables RDG CAP/RAPs. Thanks for the opportunity to clarify.

[DuoKristina]

Too many TLAs!

[solmssen]

@DuoKristina - so for this poor dude in the trenches, here’s where I’m at. Duo for RDG is protecting my RD Gateway, but now I’m afraid to install Duo for RDWeb because it might affect my RemoteApp published application on that machine, and that leaves my remote.company.com/rdweb site exposed without MFA. I knew that CAP/RAP is disabled, and I know now that I am unable to publish new apps, which is annoying. Is there a better solution? Can I install Duo for RD Web without breaking my server? Please let me know…

[DuoKristina]

What does “break my server” mean? You could install Duo for RD Web and Duo for RD Gateway on the same server when it is a server that runs all the RDS roles, and they would both work.

When you ask if it will break your server do you mean “Will RDW/RDG stop working?” or are you asking about some specific functionality that stops working? Like, my memory says that when you install Duo for RDW then the RemoteApp feed from the RD Web server isn’t accessible. Would you consider that “breaking” your server?

[DuoKristina]

Glad you figured it out.

[solmssen]

Currently, having installed Duo RDG, I can no longer publish new applications to RD Web. According to @BabbittJE, uninstalling Duo RDG doesn’t return that functionality. That strikes me as a broken server.

But to my immediate issue, if I install Duo for RD Web, if the RemoteApp feed doesn’t work, that’s not a stopper - they are connecting with a downloaded RDP document I put on their desktops. But will users have to MFA when launching the already-published RemoteApp via that RDP file? Can I exclude certain networks from having to do that - i.e. if they are connecting from a segment on our VPN, no MFA prompt?

[BabbittJE]

With Duo for RDG, I don’t need Duo for RD Web. That, to me, is redundant. Anyways, when I am using RDC or RemoteApp, there’s a checkbox that says “bypass RD Gateway server for local addresses”. Mine is checked. When users connect to RDC/RApp and are on the local LAN (or one of the local subnets), they automatically bypasses the RD Gateway, thus, do not get prompted for MFA credentials. Only those from outside of our local LAN(s) are prompted. I did have to put in one of my subnets as a trusted network or otherwise it kept incorrectly prompting for MFA credentials.

What I had to do to publish any new app is to build a new RDG and publish apps THEN add Duo for RDG. Sucks but I don’t see any other workarounds.

[solmssen]

@BabbittJE I see your point about RDWeb being redundant, but it’s still an internet exposed website and I would like 2FA on it. I guess even if someone logs in with user creds, all they can see is the RemoteApp that will download an RDP file that will require connection through the gateway and thus 2FA, or if they connect to the feed, a similar thing, but I’d still prefer to see the site 2FAed because I don’t want people even connecting to the site with user creds if they shouldn’t be. If I install Duo RDWeb, the RDWeb site will require 2FA? What about connections to RemoteApp-published apps that don’t go through the gateway?