Duo on RD Gateway causing timeout after 8 hours. What should we do?

[SVMax]

Hello,

We have a Remote Desktop Session (RDS) collection with all of our servers running Windows Server 2016.

We currently have Duo installed on our RD Web Access so that our users get prompted with Duo when they login to the web portal. This is not enough security for us. The web portal downloads .RDP files that log into our session hosts. A user could easily save an .RDP on their computer to log into for next time (or worse, an attacker obtains it) so that they bypass the web portal. Because of this, we either have to have Duo on our RD Gateway or RD Session hosts to prevent the web portal bypass.

We have been trying out Duo on our RD Gateway but have come across into a HUGE issue. Our users are being disconnected after 8 hours, no matter if they’re active or idle. It seems like several customers of Duo have been experiencing this issue but the issue has not been resolved since October 2018. Link here: Duo RD Gateway CAP/RAP Session timeout settings .

A potential workaround is to install Duo right on our session hosts. While this would work, it’s extremely frustrating for our users to have to use Duo every time they open an application. RDS gives us the capability to publish apps into a “Work Resources” folder on the users start menu. When they click the app, it logs them into the server and opens the app. But when we install Duo on the session host, it asks them to authenticate every time. Since this is not a web-based application, we cannot use the “remembered devices” feature. We also cannot use the “authorized networks” feature because all connections are being made come from the RD web access/gateway, thus appearing from an internal IP.

Both of these options greatly affect our users and we don’t want to have to choose our poison. Does any one have any suggestions on how to implement Duo in an RDS environment that’s not invasive to users?

If the Duo on RD Gateway bug was fixed, all of this would be a non-issue.

[GaryDoven]

+1
I hope this request is listened to.

[eg-je]

+1, but don’t get your hopes up or hold your breath.

Since Apr '19, Duo appears to have invested more time in editing/deleting posts, and suppressing conversation, as demonstrated within the thread which you linked to.

As @Amy wants this community to be one of the best places for Duo admins, end users, and anyone interested in security to connect and engage in conversations, perhaps Amy could make [y]our experience better by nudging @PatrickKnight to provide us with an update?

Be honest with us; not a priority for you? Just tell us. Working on it? How’s it going? However, please don’t keep shutting us down with the whole raise a feature request, this should be being treated as a bug.

(And just a friendly reminder for Duo, when you shutdown/censor conversations on your own community it has a tendency to alienate your customers. This results in the conversation moving to other social platforms, places where you have less control and the ability to engage as easily and constructively with - so maximise the home advantage and make this community as open, honest and collaborative as possible.)

[Amy2]

We understand the frustration this is causing you and many others as well. Not just the experience in the product, but that we have given the impression we are not listening. We take your concerns and feedback very seriously, and we know this is important. I’m sorry we have given you that impression.

This is not a bug, but rather an intentional choice that was made with the product. We recognize and acknowledge that not every choice will meet everyone’s ideal use case. This is why we tell people to submit a feature request, so that this feature can be prioritized correctly by the team based on a number of factors, only one of which is customer impact and demand. There are always limitations, and no solution will be 100% right for everybody.

To address @eg-je’s questions directly:

Be honest with us; not a priority for you? Just tell us.

We cannot speak directly to the prioritization of feature requests, especially in a public forum such as this. All we can say is along the same lines of what we have said before in the previous thread: This is something that is under consideration for the future, and the team is evaluating how we can best approach addressing this. We don’t have a timeline to share.

Working on it? How’s it going?

Please see above. We have no additional news to share at this time, and as soon as we do, we will share it with this community.

To be clear, the thread was closed due to continued requests and distribution of an unsupported configuration which has the potential to stop working at any time, ultimately impacting many users. There has also historically been a lot of uncertainty and inconsistency around the use of the configuration in question.

[SVMax]

This is not a bug, but rather an intentional choice that was made with the product.

May I ask why 8 hours was decided for a time out? Should it not be significantly longer, or even doubled? This seems to be causing a large amount of issues with your customers, including myself. Almost everyone takes lunch breaks, thus exceeding 8 hours in a typical work day. Sure they aren’t working during their lunch break, but we can’t expect users to log out when they take lunch, and log back in when they return all because it’s Duo’s “Intentional choice”. When managers hear that the issue is caused by Duo, they question if Duo is the correct tool for our organization.

If this isn’t a bug, then it should be even easier to get it changed. What is the drawback of having it longer than 8 hours?

This is why we tell people to submit a feature request

We HAVE done this (via support phone call), and I’m sure many others have as well. But when you’re told that “This is something that is under consideration for the future” for the past year and a half it becomes completely hopeless at this point and does not make me, and many others, feel any better about it.

To me, this seems like a low-hanging fruit that can have such a large and positive impact.

Edit: Forgot to mention the part about our managers.

[Amy2]

Hi @SVMax, you and others have raised some good questions here. While we can’t speak publicly about timelines on our roadmap or the reasons behind prioritization of requests, we’d like to extend an offer for anyone who is interested to join a call with Product Manager @PKnight to discuss further. Please note that you will have to be verified as a customer and sign a non-disclosure agreement in order to participate.

If you are interested, please send me a DM with the following info:

• Your first and last name
• Company name and address
• Timezone
• Email address

Edit: We are targeting the end of April/early May for a call. If you are interested in participating, please respond by Monday, April 13.

[Ronnie1]

Hi,

Thanks for your reply.

This is something that is under consideration for the future, and the team is evaluating how we can best approach addressing this.

I know you’re not a developer but if you were I would tell you that the best approach is to remove the timeout functionality entirely. RDP timeout is controlled by a bunch of group policies on the server/domain where you have more granular control, therefor this functionality is completely redundant and unnecessary to begin with.

[BabbittJE]

I use Duo for Microsoft Remote Desktop Gateway, installed right on our Remote Desktop Gateway server, and it works just great, both web-based and RDP-based. When users are logging in from our internal network, Duo doesn’t prompt. When accessing from the Internet, Duo prompts. You can’t go wrong with this type of setup. Just make sure that the RDP is set to either “Automatically detect RD Gateway server settings” or “Bypass RD Gateway server for local addresses.” It’s been great since I got this installed in 2017. Good luck to you!

[SVMax]

Hello everyone.

Just an update on this thread, things have become even worse. We have users that sign in remotely, or from home, that use our FortiClient VPN. We’ve installed and configured our Fortinet FortiGate SSL VPN application and it’s working great - it prompts for a Duo push like it should. However, we’ve found out that this also disconnects the user after exactly 8 hours. This has become unbelievably frustrating and completely unacceptable in an environment.

Has anyone else used Duo with the Fortinet FortiGate SSL VPN application, and how did you work around or fix the 8 hour timeout?

Thanks,
SVMax

[mkorovesisduo]

Hi SVMax, that sounds like it could be an issue on the FortiGate side of things. I found this Fortinet Knowledge Base article about the session timeout, does it help? https://kb.fortinet.com/kb/documentLink.do?externalID=FD39435

[SVMax]

Hi @mkorovesisduo

Thanks for pointing this out. We will place this in our environment and see how things go.

The issue for RD Gateway still stands.

Thanks,
SVMax

[BabbittJE]

In your RDS session Collection setup, are either your Active or Idle session limit set? My Active one is set to “Never”. See screenshot:

It could’ve also been set in one of your GPOs.

[shawnrasmussen]

I think @Amy and the other Duo folks should consider prioritizing this feature. Since we now have TONS of people who are working remotely that weren’t doing that before - and now all day too - this has taken on a level of criticality it didn’t have before. It’d be nice if we could make it as user friendly as possible for them and not timing them out for no reason.

[RichardSteensma]

Hi @Amy, as you are aware, there are complete businesses operating from home at the moment.
The need for a steady connection is more important than ever!
Therefore it would be appreciated if Duo can look at this issue on a short term.

[Bryan_o]

This is a huge issue for all of our users, please fix this as soon as possible!