Is RDP and RDS the same?

We all know RDP open to the world, or for that matter open at all, on the firewall is a security no-no, but is deploying RDS servers include the same vulnerabilities?
Peter WilsonITAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Cliff GaliherCommented:
RDS is the service. RDP is the protocol. They are intertwined.
Peter WilsonITAuthor Commented:
But I'm confused on the difference of having a gateway server and having 3389 open. The gateway uses 443 and because so doesn't have the same vulnerabilities, correct?
Cliff GaliherCommented:
The gateway has extended policies that can be set as well as APIs for 3rd parties for 2FA. If all you did was have a gateway with default policies forwarding traffic to a single RDSH server then the risk assessment is essentially the same.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
The 7 Worst Nightmares of a Sysadmin

Fear not! To defend your business’ IT systems we’re going to shine a light on the seven most sinister terrors that haunt sysadmins. That way you can be sure there’s nothing in your stack waiting to go bump in the night.

VB ITSSpecialist ConsultantCommented:
Hi Peter, I would recommend you have a look at this article from Microsoft which answers some of your questions above.

In a nutshell you can better secure remote RDP access to your environment by using the Network Access Protection (or NAP for short) feature that the RD Gateway utilizes compared to enabling direct RDP access (i.e. forward port 3389) to your server. See this article for further information regarding how RD Gateway works with NAP:
As Cliff said, RDP is the protocol (Remote Desktop Protocol) and RDS is the implementation of that protocol. So yeah, they're the same thing and in terms of terminology, both are often used to mean the same thing.

Most people use the gateway server to assist with load balancing between the multiple remote desktop servers (RDS) in a farm or to work around restrictions on accessing port 3389 remotely, where port 443 is usually allowed for outbound connections. Not for enhanced security. I'm not saying you can't make things more secure using a RDS Gateway - you most certainly can - just that most people don't use it for that purpose.

I wouldn't say it doesn't have the same vulnerabilities - certainly not by default - because in large, it does have the same vulnerabilities. If you allow users to RDP straight to port 3389 on your remote desktop server / terminal server or you ask them to connect via a gateway, and in both cases they have a rubbish password, you're still pretty much in the same place.

For example, simply saying the gateway uses 443 offers no enhanced security whatsoever. RDP natively uses a certificate to encrypt the traffic in any case. Try it - go connect to an RDS that's configured "out of the box" and you'll see a message about the certificate not being able to be verified ( - data is encrypted by default over RDP). Simply changing the port to 443 instead of 3389 and tunnelling over TLS isn't going to make this process more secure.

Sniffing traffic is not your concern with RDP. Crappy username/passwords are. Simply having an Active Directory policy in place to enforce complex passwords unfortunately doesn't stop people using things like, literally, Password1. It just says they need to be 7 characters, upper/lower and a numeric.

NAP is probably the last thing you need to worry about (not saying don't worry about it - just that there are other things you need to get done first!). If you control all endpoints in the process, the RDS and the people connecting to it, NAP can help but if not, then I'd recommend you simply deny users the ability to map their local drives and just try to focus on people having genuinely strong passwords and minimising the damage they can do, if connected to the RDS. However if you already control all endpoints in the network, then frankly NAP security is a little bit redundant because you already (largely) trust the people and devices connecting to you and already have control policies over them. You'd be better off limiting the IP addresses that you allow to connect, if you can.

If you're opening up RDP from the world, you're opening up a risk. First things first - work on minimising the risk by controlling what people can do, once connected to the RDS, rather than trying to worry about if they have up to date AV on their home computer. If your concern is malicious attackers gaining access, your #1 concern is password strength because all the other policies are useless if you allow someone with permissions to copy or delete data to login with the username fred and the password TrustNo1.
Peter WilsonITAuthor Commented:
Thanks for all the insight and info.

So the scenario is that we do open it to the is not using 3389 but rather 443 for remote users (externally) and thin client users (internally) to access network resources. On top of which we have user with local share access to their C drive and other network share access plus one application.

After reviewing everything, it seems like we are not in good shape. I was thinking of implementing 2FA via

Since GP doesn't handle password policies very well as you have pointed out does this seem like the best course of action for us?

HI Peter,

I hate to answer it such, but "it depends".

It really depends on what you're doing, what you're exposing, what your budget is, how much you are prepared to put into this, etc. I know all data is important and needs to be secure but spending $20k on setting up a high security system is out of the budget for many small businesses.

I know this is not the "high security" answer - but if you have a simple remote desktop environment in place, with a bunch of fairly static, reliable users who don't do much out of the ordinary, you can probably just leave things as they are and make put your effort into making sure that passwords are not completely retarded (you'd be surprised what some people get away with, with just default "strong passwords" enabled in AD). That will probably suffice for many smaller businesses.

RDS is not an inherently insecure protocol. Traffic is encrypted by default (you do not need to tunnel this over HTTPS because it's already encrypted at the same level). Since version 6 or 7 (I forget which) it forces initial handshaking, encryption channels and so on to be established before the password is transmitted, so I don't see a lot of benefit in using HTTPS to establish the connection.

The weakness in RDP comes from that fact that all that prevents a user from gaining access is a simple password challenge. There's no by default IP restriction, or remote party restrictions - just a simple password challenge, so if the password isn't great, you're in trouble. The thing is, I'm willing to bet your Exchange Server (should you have one) is in the same boat with the same username and passwords protecting it. It's got basically no more or less security than RDP does.

2 Factor authentication will go a long way to helping with that issue and a long way to making your life miserable. Forcing users who used to be able to "just log on" to suddenly need their phone to log on, without a strong justification (unfortunately, the kind of user who uses "Awesome1" as a password isn't going to be on board with this) isn't going to be the best experience of your life.

I think a much cheaper and probably more effective option would be to get a 3rd party strong password enforcement tool. Sure, it'll annoy users just as much as anything else but it will actually be useful, too. Oh - and make sure you keep the TS patched.

Sorry to be so down on it - what you're trying to do is laudable and I wish you all the best. I've just been through these exercises many times and I can tell you, the initial discussion of "we need to be more secure" might get a lot of head nodding and agreement - but the implementation of said security rarely involves the same level of end user enthusiasm.
Peter WilsonITAuthor Commented:
Excellent points!

Here is some perspective, we are a ~300 user environment and users are exactly as you described...a bunch of's really baby sitting from 9-5. And I completely see and agree with your point about management agreeing to tighten security but users hating it and ultimately ending up in my lap.

Anyway, what 3rd party password enforcement apps do you recommend without busting the bank?
I think if you set people to get locked out for 15 minutes if they get their password wrong 7 times in 10 minutes (which I believe is the default AD setting for password lockout policies) then this will go a long way to stopping brute force attacks.

I have heard that is very good but I have not used it.
Peter WilsonITAuthor Commented:
Ok, thanks! So it looks like l0phtcrack is kind of hands on and post care, right? It seems like you scan and it finds bad passwords that you then need to take care of if I understand it.

We are also going to implement password rotation...I think every 60 days.
VB ITSSpecialist ConsultantCommented:
Hi HostOne, whilst you make some very, very excellent points regarding passwords and the overall inherent secure nature of RDP, I think you may have misinterpreted what I was trying to say. I'm mostly at fault though for not elaborating further as I typed that reply while I was in a rush.

I was merely trying to point out that from a manager's point of view, RD Gateway has a number of security benefits as opposed to opening port 3389 externally.

When you open up port 3389 to the world, one of the main issues is that you cannot easily control with any granularity which of your staff members can log in to the Terminal Servers remotely. Whoever that already has access to your Terminal Servers internally will be able to access it externally by default. There's also the risk of staff stealing company data if you don't have the necessary settings to disable printer/local drive redirection.

This is where something like RD Gateway comes in. Provided you set up the necessary policies beforehand, you can mitigate a lot of  the vulnerabilities present in direct access over port 3389. This article sums up what I'm trying to say quite nicely:

I do 100% agree with you about the above points though. Weak passwords can be your downfall.
Peter WilsonITAuthor Commented:
Thank you for the clarification. Great points as well!

I also downloaded and it is good at finding passwords that violate policies aka are weak but I'm looking for something with more automation.

Does anyone know of any good password enforcement utilities?
Thanks VB ITS - your points are all great, as well.

AS there's no additional licensing implications for using the RD Gateway, I would agree that you should implement it in the near future, as well.
Peter WilsonITAuthor Commented:
Just to be clear we already have Rd gateway implemented.

To the point of security I need a better password enforcement utility.

Any ideas?
Maybe try this:

It shows you how to enforce different password rules by AD OU or by AD group.

So, yes, it still uses Microsoft's rules for complexity (which suck) but on top of that you could add a rule that if someone has access to RDS, then they must have, say, a 10 or 12 character password as minimum. That would allow you to not harass non-RDP users with longer passwords but it would force users who have dictionary words + a number to rethink their password because there's not a whole lot of 12 character dictionary words.

Even if they use a stupid password, like (i.e.) PasswordPassword1, when combined with a lock out policy of say 30 minutes on 5 wrong guesses, the probability of someone cracking a password from outside the organisation, with just 5 guesses an hour, against a 12 character password is...exceptionally remote.

By using the above linked approach, you can just force these rules on users who have RDP access, instead of, say the account lady who just wants to come in and do on site data entry at an approved terminal.

That will go a long way towards fixing the issue you have with passwords not being great. The next issue you'll face (not to continuously raise problems) is that people can set their RDP client to save the password for connections or just write their password on a sticky note and leave it stuck to their laptop (yes, I've seen this done). So, if they're company laptops, the next challenge you'll have to raise is that, when they leave the building, they need to a) have a password for login to the OS (they probably already do) and b) have an encrypted volume, so no one can just read the disk or reset the password with a Trinity USB key to log in. Those steps can easily be handled by Active Directory and should be considered, if security is a real concern.

Fixing the sticky note problem is a whole different issue. :-P
Oh sorry - one more issue to raise, so you're forewarned. If you're using password time limits (i.e. new password every 30 days or 60 days, etc.) and Remote Desktop Gateways, this is a bit tricky.

Generally, when you use a RD Gateway, you would not use the RDS as this role, because (presumably) you'd have multiple RDS for 300 users and a gateway would be separate, for redundancy.

When a user logs in with an RD Gateway and their password has already expired, they cannot log in. The connection to the RD Gateway will fail but, because they won't yet have been passed to the RDS by the gateway (because the gateway will not accept their expired password) to be presented with a password change screen, they won't have any way available to change their password and, as such, they simply cannot log in. So you'll be getting an 8pm phone call to reset their password.

So if you plan to time limit passwords you need to make sure people get a warning in advance and they actually listen to the warning. For users who rarely log in via RDP and mostly just get mail on their Android or iPhone, they'll just suddenly find their phone stops working for email and they have no way to fix it.

And on that final note, one last related issue. When a user changes their password, remind them to change it on their BYOD devices, too. Otherwise, their mobile phone is just going to bang away at the Exchange server with the wrong password and get their account locked out. So this starts to lead down the path of remote/mobile/BYOD management.

As you can see, what seems like a simple change to passwords or RDP access leads into a never ending tunnel of changes! :-)
Peter WilsonITAuthor Commented:
Wow thanks for revealing the rabbit hole! This is going to require much more planning than I originally anticipated. I was going on a 60 or 90 day password rotation with a 5 times permanent lockout. We have a nifty password resetter so I'm not thinking it was going to burden us too much but then again....

We are planning to role SSO as many places as we 365, ssl-vpn, RDS, etc. I was hoping that a prompt from one of those locations would help remediate the RD gateway scenario you painted above.
Peter WilsonITAuthor Commented:
Thanks again for all your input!!!

Sorry for closing so late. I need to work on that. :(
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Windows Server 2012

From novice to tech pro — start learning today.