Current Best Practices for RDS Gateway?

[HCHTech]

Most all of my clients are small, and when we upgraded their servers from SBS 2011 to something current, we didn't look to replicate the RDS gateway. We let the small number of users that wanted remote access VPN into the firewall and then RDP to their desktop though the tunnel.

Now, I'm proposing a little bit bigger group's upgrade for later this year. They have about 15 employees and a lot of folks use RWW in SBS 2011, so it looks like I'll have to plan for my first RDS Gateway server.

Since the new server will be HyperV, would you normally recommend a dedicated VM server for the RDS role, or can this role be added to, say a file server without bogging down performance? I'm guessing a separate server would be easier to secure, but I haven't done one before, so I'm just looking for some opinions on how the big boys do things.

Plus, I see the RDS CALs are pricey compared to regular server user CALs, so I don't want to buy more than I have to.

TIA!

 

[Sky-Knight]

I always put any workload that is exposed to the world on its own VM. So my RDS servers tend to be dedicated to that purpose, with the possibility of being shared with SSTP VPN and IIS workloads.

So with Standard you'd get two VMs, use one for the DC/Files/Printers internal stuff, and the other for the external stuff. The only thing that gets a bit prickly is SQL, SQL server doesn't like installing on a DC. BUT, you can do it, you just have to make a service account for it ahead of time and tell the installer what to use.

Oh, and get RDS USER CALs, your server is then concurrent. You have 10 of those? 10 people can be on it at a time. You can have 20 people, but only 10 on the server using RDS at a time.

 

[YeOldeStonecat]

For smaller clients, we'll have the TSGateway running on the terminal server itself. For some clients with larger networks, we may have the role running on a server just for file/print sharing, if there is not a terminal server. We have some clients where they have no terminal server they just use TSGateway to proxy to their workstations. Only port 443 is needed, no port 3389 exposed to the internet at all.

Really depends on the "load". For some terminal servers they may just have a few concurrent clients running basic applications...so adding the TSGateway role to that server is fine. For other clients...the terminal server may be busy...over 20 or 40 concurrent clients, and/or running heavy apps that are CPU intensive....so you don't want TSGateway running on that same server...performance would suffer. Treat the TSGateway role as a router...think about performance..it's moving packets for clients...packets for their remote desktop. While that itself is not resource intensive, you want it to be fast/responsive...not running on a server that has CPU utilization frequently above 60% for other services.

As a clients network starts to grow beyond one, two, or three servers...I like to break out a DC to be ..just a dedicated DC. The domain controller dong nothing else but running network infrastructure services...DHCP, DNS, and all the AD tools....and the local probe for the RMM, repository for RMM services. And have a dedicated file/print server. That file/print server also hosting the folder redirection shares for end users. Dedicated application server. Any terminal server would be dedicated...never shared on another server like the DC or file/print or an app server. Terminal server should be something you can nuke 'n pave without losing data....since users would have their important folders redirected to another server.

Security wise...most of us stopped doing traditional terminal servers years ago (ya know, expose port 3389 or alternates)...due to them being easy prey for hackers. From what I gather, it's older operating systems (2008 non r2 and older) that are easy prey and hacked into like a hot knife through butter, newer ones (like server 2012 and newer) are, from what I know, not able to be hacked into directly like older OS's...they just get constant grinding attacks going through user/pass attempts looking for weak passwords, or of course used if the passwords were phished. None the less, because it's a juicy target and I'm sure some tool will be out to directly hack into newer OS terminal servers as easily as older ones, I stopped doing old fashioned terminal servers a couple of years ago and the few out there I have are behind TSGateway. For the end users that just want to remote to their desktops now...instead of TSGateway I've moved to doing VPN and then RDP to their desktop. I still consider TSGateway secure..so long as users accounts have complex passwords, regular password changes, and they're not phished. I'm not aware of TSGateway having any weakness to exploits/direct attacks to bust in. Necessary SSL version updates necessary too.

Firewall wise, I minimize the port 443 exposure for TSGateway by putting Geo Blocking in place. Allowing only US and close neighbors access. I know..I know, many attacks are launched from compromised sources inside the US, big data centers that have hacked web servers, etc. But still, to me Geo Blocking cuts out at least 75% of the incoming "bad noise" on there. So it's another layer that helps a bit. Hey, it's free, and takes just a minute to set up. I also setup IDS to alert..and ensure exploits against https and rdp are included in the monitored defs. This way you'll get an email soon as someone is banging on the front door huffing and puffing and trying to blow that door down...and you go into the firewall rules and block that IP (after doing a quick IP lookup to see where it's coming from just for curiosity).

I imagine within another 2 years I'll no longer have any TSGateways out there. With O365 and other cloud file sync services like DattoDrive, we're coming to a time where having any port forwarding for "internal services" is much less needed. Fewer and fewer on-prem Exchange servers. Hardly any SBS servers left out there with Remote Web Workplace. It's nice to know a clients network is locked up pretty tight.

 

[trevm999]

Anyone know of any 2 step authentication plugins for RD Gateway that are lower cost than what you get via Google search?

 

[Sky-Knight]

I use Duo for multifactor on RDS, not exactly cheap but it works well.

 

[fencepost]

I've cheated, I'm actually using straight RDP, but only from known-good hosts (Comcast residential IPs these days appear to be pretty much static) and ones that have port knocked (with a timeout on those varying from 4-12 hours depending on the client). Where I have client VPN connections set up, they actually have to either port knock or be on that known-good address list as well.

My basic feeling is that I want precisely zero visible/connectable ports on my client's networks, not even RDS gateways. Can't grind what you can't see.

The knocking is done through password-protected pages on the client websites, but that is just using basic http auth with a single user/pass combination. The knock patterns are non-sequential with broadly-enough spaced ports that a port scan is unlikely to trigger them, though I haven't hardened them fully by detecting for port scans.

 

[Yosebas84]

XXXX


Edited per violation of the forum policies

 

[trevm999]

I use Fortigate web access, and normally a win10 jump server, so everyone goes to the public ip and hit the fw auth with double factor, then they auth with the domain to a win10 jump server and then, they can use RDP to reach what the policy for that user allows him to reach.

And yeah i know win10 does not allow you to get more than 1 concurrent sessions at the same time, but there are ways to bypass that limitation..

RDPWrapper

So you're in violation of the licencing and advocating for others to do the same?

I believe the EULA goes further than just concurrent sessions, but only the regular user of the OS is allowed to remote in.

 

[Yosebas84]

So you're in violation of the licencing and advocating for others to do the same?

I believe the EULA goes further than just concurrent sessions, but only the regular user of the OS is allowed to remote in.

I'm not advocating for others to do the same, i share what i do, i apply this workaround explaining to my clients the EULA violation, the legal complications it may carry, etc. but i'm not asking you or anyone to do the same, if that's what you or anyone else understood, i'm sorry, but it's NOT my intention.

I apply this if i got 2 or 3 users that just want to look at some intern software in the company or work on some local files once or twice a week.

But if it's a permanent way to work, RDS.

If this is against the forum policies please @Kraken let me know.

 

[trevm999]

I like it when people have to reap the consequences of using Windows, rather than helping workaround things that hide it's true cost.

 

[Yosebas84]

Most all of my clients are small, and when we upgraded their servers from SBS 2011 to something current, we didn't look to replicate the RDS gateway. We let the small number of users that wanted remote access VPN into the firewall and then RDP to their desktop though the tunnel.

Now, I'm proposing a little bit bigger group's upgrade for later this year. They have about 15 employees and a lot of folks use RWW in SBS 2011, so it looks like I'll have to plan for my first RDS Gateway server.

Since the new server will be HyperV, would you normally recommend a dedicated VM server for the RDS role, or can this role be added to, say a file server without bogging down performance? I'm guessing a separate server would be easier to secure, but I haven't done one before, so I'm just looking for some opinions on how the big boys do things.

Plus, I see the RDS CALs are pricey compared to regular server user CALs, so I don't want to buy more than I have to.

TIA!

I tend to use a separate RDS, since it will be exposed, and since it may grow i prefer to have it totally separated of other roles, for best practice i will say separate the roles whenever you can, so if someone for some reason crashes the VM, it won't affect the domain/FS&P/BBDD/etc.

 

[Markverhyden]

I'm not advocating for others to do the same, i share what i do, i apply this workaround explaining to my clients the EULA violation, the legal complications it may carry, etc. but i'm not asking you or anyone to do the same, if that's what you or anyone else understood, i'm sorry, but it's NOT my intention.

I apply this if i got 2 or 3 users that just want to look at some intern software in the company or work on some local files once or twice a week.

But if it's a permanent way to work, RDS.

If this is against the forum policies please @Kraken let me know.

It's been mentioned many times. Advocating or describing how to violate EULA's, copyrights, etc is against the forum's ToC's.

 

[Yosebas84]

It's been mentioned many times. Advocating or describing how to violate EULA's, copyrights, etc is against the forum's ToC's.

Thanks Mark, just edited the post.

 

[marley1]

Rdgateway to their own PC
If terminal server needed then we add

Add 2fa if needed

 

[G8racingfool]

Most all of my clients are small, and when we upgraded their servers from SBS 2011 to something current, we didn't look to replicate the RDS gateway. We let the small number of users that wanted remote access VPN into the firewall and then RDP to their desktop though the tunnel.

Now, I'm proposing a little bit bigger group's upgrade for later this year. They have about 15 employees and a lot of folks use RWW in SBS 2011, so it looks like I'll have to plan for my first RDS Gateway server.

Since the new server will be HyperV, would you normally recommend a dedicated VM server for the RDS role, or can this role be added to, say a file server without bogging down performance? I'm guessing a separate server would be easier to secure, but I haven't done one before, so I'm just looking for some opinions on how the big boys do things.

Plus, I see the RDS CALs are pricey compared to regular server user CALs, so I don't want to buy more than I have to.

TIA!

"Tradishunully" you'd usually put the RDSG on the same VM/server as your DNS/SMTP/etc "outside" services in the DMZ (if you're using one) and then keep the RDSSH servers separate inside the firewall. Having the Gateway on the same system as the Session Hosts isn't a huge deal performance-wise but it is a security concern. However, depending on how your network is set up and how the company operates, you may not have the option to keep everything separated out in which case, I'd keep RDS on one system and then keep your file/application data on a separate system/vm if possible.

That said, I side with @YeOldeStonecat about doing a VPN into the local network and then doing an RDS session from there. In fact, I've been doing things that way for years because, funny enough, I actually thought the setup was easier than doing the RDSG method (why? idk, I just found it that way at the time). You also don't need to buy an SSL cert for the Gateway when using VPN although performance may be slightly slower (don't even think about using self-signed in production).

Also, you probably already know this but it bears repeating that you need a regular CAL + an RDS CAL for each remote user. So if you have 15 total users and 5 of them are remote you'd need 15 user CALs and 5 RDS CALs. (server licensing! yay!)

 

[HCHTech]

That said, I side with @YeOldeStonecat about doing a VPN into the local network and then doing an RDS session from there. In fact, I've been doing things that way for years because, funny enough, I actually thought the setup was easier than doing the RDSG method

Oh, I agree. That's the way we setup almost all of my other clients. My concern is that this doesn't scale as easily. We're adding SSLVPN connections to the firewall, but what's the limit on that? 5-10, probably never notice it's happening. 35? 50? Somewhere, there's a breakeven point where it's got to be simpler to have an RDS gateway taking that processing load. I don't really know, because I don't swim in that end of the pool. That's why this is a bit of a challenge for me. I put together my quote, we'll see how it goes. Man, those RDS CALs are expensive!

 

[Sky-Knight]

If you need to scale, you use RRAS's SSTP VPN as your terminator, and use GPOs to not only automatically configure all your stations for the VPN, but add the appropriate remote app connection too. Then AD group membership does all the lifting. You can do this for 10 people, or 1,000 people the load on the admin is the same. If you have a compliance audit, you slap DUO on the IIS instance doing the SSTP and poof, two factor.

 

[Markverhyden]

If you need to scale, you use RRAS's SSTP VPN as your terminator, and use GPOs to not only automatically configure all your stations for the VPN, but add the appropriate remote app connection too. Then AD group membership does all the lifting. You can do this for 10 people, or 1,000 people the load on the admin is the same. If you have a compliance audit, you slap DUO on the IIS instance doing the SSTP and poof, two factor.

How popular is this setup? I mean in the real world.

I know M$ has made huge improvements in security but I'm still very leery of having it on the edge for anything. A server certainly has plenty more horse power than appliances but those same appliances, at least on the higher end, use ASIC's which have their own advantages.

 

[Sky-Knight]

How popular is this setup? I mean in the real world.

I know M$ has made huge improvements in security but I'm still very leery of having it on the edge for anything. A server certainly has plenty more horse power than appliances but those same appliances, at least on the higher end, use ASIC's which have their own advantages.

SSTP runs over HTTPS on IIS, if you're worried about IIS's security at this point... you're a bit behind. But I do perform this stuff on a dedicated VM. Take care, I'm not talking about that nightmare called PPTP, SSTP is a different thing entirely... And it's got some seriously powerful knobs to turn.

For smaller offices I still prefer Untangle's OpenVPN.