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…