1

Hello,

I have more-or-less settled on DUO Security for 2FA for our RDS server. However, I have several concerns about it.

  1. I am worried it’s going to require a long and painful setup process with me having to put hands on a number of phones to get the software installed. (Because people forget their passwords to their Google account or their iCloud account or they have an earlier Droid that can’t support the application, etc.)

  2. I am worried I’m going to create a support nightmare because users will forget to have their phones with them or they’ll not answer the challenge quickly enough. When I say support nightmare, I mean calls to me at any time of the day or night because I am a two-man band.

On the other hand, stuff like RSA tokens and other fobs like Yubikey can get lost. (I don’t even know whether Yubikey supports RDS though I hear it supports AD so perhaps that’s enough.)

I’d like to hear some experiences and advice, please.

5 Spice ups
2

Any 2FA can have the headaches you mention. The beauty IMO with something like Duo is at least it’s flexible, you can text, you can phone, you can use the app, you can use a physical token, there is almost always a way around an issue if someone is in the shit.

I do agree with the potential headaches getting the app installed, but we didn’t find much that wouldn’t run the app (other than Blackberry), the issues were all around the ones you suggested and there’s nothing we can do about “I don’t know my iTunes Store password”.

Once it’s in place it’s pretty much seamless.

2 Spice ups
3

Yeah, it and it reduces the up-front capital expenses that would be necessary in hardware tokens.

Maybe I just need to get over myself. :wink:

4

Can Duo run internally, or is it only hosted?

5

YubiKeys can be used for remote desktop with AuthLite . (I only mention to answer the implicit question, not to sway you away from Duo.)

1 Spice up
6

Can I just ask if the RDP box is directly facing the internet?

I ask as if so I would focus on how to stop that as well as things like 2FA.

1 Spice up
7

Interesting. If the 2-factor auth is required at the network layer authentication, isn’t that pretty much as small an attack surface as if you had to connect a VPN first?

1 Spice up
8

That depends…

If the RDP server is in a proper DMZ, with access to internal resources restricted to the minimum necessary and those connections scrupulously watched by an IDS, then I’d say the risk is about equal to a similarly deployed VPN server. Yes, that’s a big “if”.

To answer the OP’s questions about Duo, we’ve been using it for several months now (different role, same tech) and have found it to be well worth the occasional “inconvenience”. Most users, by far, choose the “push” method and we have yet to have a single report of a user unable to gain access because they “forgot” their smartphone. People will forget a lot of things, but that particular item is almost always attached to it’s owner at the eyeballs, making it almost the ideal second factor. We also support the Yubikey, and we have had cases where that item was “left at home”.

3 Spice ups
9

I’d echo most of what John said on RDP simply because Windows is not a security device in the way that a proper firewall/VPN can be, and 2FA is an authentication method it will do nothing to deal with a vulnerability in Windows or Duo.

Ditto the comments on tokens, people tend to look after their smartphones and keep them close whilst I’ve handed people physical RSA tokens and watched them say thank you and then put them straight in the bag with the laptop.

2 Spice ups
10

The VM deployed is as a single RDS server with all roles installed. Those who have access to it are granted access via Security Group in AD. Not everyone has access. I am hoping to protect those logins with 2FA.

As far as “direct exposure” to the Internet, I am going to say, Yes.The server is not in a DMZ but is behind a Fortigate with IDS. Admittedly, I am a very small company and it’s hard to devote resources to constant management. (Although, I suppose I could work 18-hour days. I mean, really, what’s my problem? I’m kidding.) If I were to put the RDS server into the DMZ, I’d still need to open some access between DMZ and internal in order for RDS users to be able to access resources like shared network drives. I may need to have someone explain to me what putting the server in a DMZ would accomplish in this case.

I could additionally set up VPN via the Fortigate and require that access before they can access the RDS server. That would allow me to remove direct exposure to the Internet. The main problem I see with that is that the VPN technology available via FortiOS (so far as I know) is not as robust as, say, the FortiClient which we’d have to purchase licenses for. That’s likely out of the budget scope at this time. Even though this company is behind a 100mb Cogent circuit the access via, say, PPTP to the Fortigate has proven flaky and never stays up all day. I’ve never really looked at IPSec options except in the case of Fortigate to Fortigate. And, quite frankly, some of the users are very, very bad at making sure the VPN connection is up before trying to access resources. (We’ve had this experience and they got angry at us.) Nevertheless, I could do this and may do it.

Hope this helps fill in some of the details.

11

So if I find a vulnerability on the RDP server and am able to exploit it, I now own some very valuable “high ground” with direct access to the internal network - no IDS watching me, no impediments of any kind. To your one security device (your Fortigate) all the traffic looks like “authorized” RDP traffic. Meanwhile I am going to town on the internal network and nobody is watching me.
It’s true, that we all have to draw a line somewhere and call that “as good as I can do with the resources at hand.” I’d punt a lot of stuff to at least get a DMZ in place and that server deployed there so my Fortigate can watch the traffic between the server and the world, and between the server and my LAN.

1 Spice up
12

And I suppose a 2FA may not make a difference if it’s an exploit that gets you in as opposed to breaking into an account.

Hmmm… So if I have the server in the DMZ and the users need access to shares, how is having the server in the DMZ going to make a difference?

**Edit:** I guess I should ask it this way. What can I do to prevent the situation you describe? I suppose that if I put the server behind a VPN at the Fortigate level, you could still find an exploit with the Fortigate VPN. But then you’d have to exploit RDP too. Down the rabbit hole I go. FWIW: only 443 is exposed to the Internet, not RDP ports.

13

Well, if you are forced to keep your current setup, make sure you require network layer authentication (don’t allow connections from older clients). This means you have to authenticate successfully on the initial connection before the graphical logon screen comes up. This reduces the attack surface exposed, down from “all of RDP and all of Win32 API that’s available on the secure desktop”, to just “the portion of RDP that does the TCP connection and authentication”. This is what NLA was designed for.

It would be cool if you could also require 2FA on this connection, but I don’t know of anything but AuthLite which does that. This would prevent brute force (or low-and-slow) attacks against the NLA to guess passwords.

Make sure you have a lockout policy applied so attackers can’t just chew away at the entry point to guess creds as fast as they want.

1 Spice up
14

Ok. Thanks. Where can I go to turn on NLA or at least confirm it’s on. Since it’s Windows Server 2012, I imagine it’s already on. I will poke around to see if I can find out where.

Is the lockout policy you refer to the lockout in AD that locks the user’s account after so many attempts?

15

OK seems to be on by default:

http://superuser.com/questions/959728/how-do-you-configure-nla-for-rdp-in-windows-server-2012

Yes, I’m referring to AD account lockout.

1 Spice up
16

Thank you. I was able to determine that NLA is on.

I also found the policy settings for Account Lockout and have adjusted it to something much more restrictive.

Thank you for your help.

17

Speaking directly to your original question, I thought I remembered Duo having a self-enrolment option. Meaning you could setup the accounts and have each individual manage the 2FA enrolment process. You can also do AD sync or batch enrolments. Here’s the link that talks to those items…

1 Spice up
18

John hit it on the head - pull that thing away from the internet, fast. Your idea of using SSL VPN to the Fortigate (w/2FA) is the better way to do this; especially if you have limited access and IDP setup internally. Layers are always best, and certainly when you are small and can’t have big walls, you will do better with as many little ones as you can get.

19

We’re kind of off-topic a bit, but I appreciate this. I have pulled it off the Internet since we’re not using it at the moment. I will speak with Fortinet about 2FA options and see how much it would cost to do 2FA for VPN. In the meantime, perhaps when we start using it off-site, I could force users to use PPTP VPN as a workaround.

20

Don’t bother with PPTP, it isn’t secure at all. At a minimum you should be using L2TP/IPSec.

2 Spice ups