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.

[SVMax]

@BabbittJE - Ours is also set to never. So that is not the issue.

@Amy - May you PLEASE pass this on as an critical feature request? Due to the current situation of COVID-19, our entire company is working from home using RDS. This has become absolutely infuriating to deal with. We need this to be fixed more than ever. PLEASE.

@mkorovesisduo Thank you, that FortiGate setting worked and our VPN users no longer get disconnected. The RD gateway timeout still stands.

[mkorovesisduo]

Great, I’m glad to hear that resolved your FortiGate issues!

Also, I’d like to let everyone in this thread know that we are very well aware that this is a high-priority issue for customers–especially given the COVID-19 situation. However, tagging Amy or I in this thread is less effective than bumping the feature request (or submitting your organization to be attached to it) with your Duo representative or Duo Support.

We really appreciate your feedback. I hope that you are all staying safe!

[secret_config]

As everyone else here, we are dealing with the same issue using RDGateway with DUO.

The fact that someone thought it would be a good idea to hard code an 8 hour limit without the ability to change it is ridiculous. Even worse, this isn’t a new issue that has just been discovered, this has been reported multiple times over the last two years and it seems to have been completely ignored. There is really no excuse for not addressing this.

Deleting posts and locking threads regarding this issue is shameful.

We will be looking at other MFA products as a result. Telling users to just accept it and reconnect after 8 hours is not an acceptable solution. Installing DUO on each workstation is definitely not a solution either.

[KeithPoole]

This undocumented ‘feature’ is driving our internal staff, and our customers which we just started onboarding, absolutely nutty.

We cannot deploy Duo on the workstations, as they are using personal devicse, and a lot of our team work well over 8 hours each day.

Please fix this ASAP, as I don’t like having to throw money down the drain.

[habdulla]

Chiming in on this. If this is due to a hard coded value of 8 hours, the amount of time that has gone by and with the amount of concern the community has expressed blows my mind. Being a developer myself, I believe as small as changing a hard coded value to use a configuration setting could be done very easily with minimal impact/risk. There is even a built out method of asking the user for information already in the install process. Adding a new field to that form and changing a hard coded value to a variable? That change can be made, tested, QA’d and published start to finish VERY quickly. Is there something I am missing in all of this? Please correct me if I am wrong about this, because if it really is as straightforward as what I am saying, I really do not understand why this issue still exists.

[InhoChoi8]

Hope you all are well.
Hey, is it that hard to update your DUO clients roughly when this issue can be sorted out or at least planned so we can get back to our clients and get them to be calm down?

As a sys admin, keep thinking why why why 8 hours and why hard coded with thinking and trying to believe there should be very reasonable REASON behind but still do not understand.

Hope we can get some info about your plan.

Thank you.

[BabbittJE]

I just had an user tell me she keeps getting disconnected everyday, even in the middle of typing, usually 3:30 PM (she signs in 7:30 PM). So, it does indeed appear that Duo disconnects our gateway every 8 hours, overriding my RDS values. Is there yet a fix for that? We’re still working from home and still need Duo. I’d hate to swap Duo for another product; too much work to switch.

[GaryChan2]

Joining in the chorus… This seems needlessly painful, please allow us to admin our own systems.

[Ron_DeFulio]

This issue is driving our staff crazy. As stated numerous times by others, the plug is pulled on the session mid-keystroke at 8 hours exactly. Please give us a way to change this default value.

[mark003]

We have been using DUO on RD Gateway forever and have run in to this exact issue a couple of times.

There is a ‘hidden’ regkey which defines this value. I am not sure why DUO support is not able to inform about this. Anyway, on to the details. This should help you guys out

Open regedit on the RD Gateway server and browse to:
HKEY_LOCAL_MACHINE\SOFTWARE\Duo Security\DuoTsg

Create new DWORD named ‘AuthorizedSession_MaxDuration’ with a value of 000003c0 (16 hours)

000003c0 equals 960 minutes which is 16 hours. Offcourse you are free to use what you wish here.

[SVMax]

@mark003

You are a brave soul posting this. This worked. We’ve had zero issues in the last week because of this. Thank you so much. You’ve been more help in one reply than Duo has been in almost two years.

[PatrickKnight · Accepted solution]

In light of COVID-19 and the exponential rise we’ve seen in RDGateway usage, we have updated our Knowledge Base article to include the necessary keys to edit the Max Sessions and Idle Timeout values. These options are still unsupported, but have been tested against Microsoft Server 2012R2 through Server 2019, so please utilize them at your own risk.

We know this has been a long-requested option that has gone unaddressed, and we hope offering these keys as an unsupported option will help improve your experience with Duo, but publishing these keys still does not live up to the expectation we’d like to offer around RDG. Hopefully this helps today and we’ll update the community with additional information we have to share around the future of RDG.

If you have any feedback please DM me here or reach out to me via email at pknight@duo.com

Thanks,

Patrick

[SVMax]

All I can say is thank you very much. You’re going to save the frustration of many of your customers.

[eg-je]

+2 for releasing the information to the community, even if “unsupported”.
-1 for the drama in getting here.

We’ve been using the registry fix since early March* on multiple Windows Server 2019 Brokers without incident. Your experience could differ due to so-called quality issues but I wish you the best of luck, hopefully Duo refines this element of the RDGateway solution in the coming months.

(* thanks to those Darknet-style ninjas for looking after the community, +5 for you.)

#StaySafe

[robnicholson]

Three years later and this post is still relevant. Thanks.