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

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.


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.

1 Like

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.

1 Like

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.

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

@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.

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!

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.

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.


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.

1 Like

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.

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.

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.

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

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.

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:

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.



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.


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




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

+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.)