Offline access with RDP...when you have 100's of systems

[Goatherder]

I may be missing something, as we are currently using the trial, but can someone confirm how this should be set up and work ?
Say, we have 100 servers, that we want to protect with Duo for RDP access. We want to ensure we have offline access, incase of a network outage. Say for example we have 25 admins that require this offline access.
Does every admin have to add each of the 100 servers ? It seems to me, unless I am missing something, that the generated code is different per server for each admin, and not really what I expected. That how it works ?

[BWarrenITC]

Following.

I’m in the same boat, Goatherder. We are trying to get a handle on how this “offline” stuff works. I haven’t found a very cut and dry explanation of how each of these scenarios will play out.

I did ask support a few questions yesterday and will summarize what I heard from them:

EACH Admin user will need “Offline Access” profiles for EACH Server that they want to be able to access in the event Duo cannot be contacted.

“Offline Access” ONLY works for local console connections. RDP access DOES NOT work with “Offline Access”.

I also have another concern in regards to remote access via VPN to RDP into a system. You will get a minimum of 3 prompts if you are using the Duo Mobile App with Push to authenticate. First, to log into the laptop, second to connect to the VPN, and third to RDP into the remote system.

Not having RDP access in “offline” mode is a big deal, at least for us, so we are back at the drawing board to figure out how to best deal with this.

[Goatherder]

Offline access definitely works with RDP. Perhaps I am misunderstanding your scenario, but for sure, when the Internet connection is gone, I use offline codes (for each server, hence my grumble or lack of understanding) to access VMware and Hyper-V guests, via RDP.
I am simply struggling, in an Enterprise with a gazillion servers to understand how to design for offline access

[BWarrenITC]

This is the reply I got from Duo Support last night. I have not tested this for myself yet, but it’s on my list of things to check.

Edit: I just tested this and it does seem to work just fine. I have sent a reply to support to ask why this was their response when it appears to work correctly via RDP.

[Goatherder]

When you did testing, did you simply RDP to a server (physical or virtual) ? Did support say anything about needing an offline code for every host and user/admin accessing ?

[BWarrenITC]

I did a test from my PC to my laptop. I put 127.0.0.1 as my DNS on the laptop so that it could not contact Duo and then RDP’d into the laptop from my PC and it gave me a prompt to enter an offline code.

I received the below response this morning:

So support is assuming that ONLY the customers internal network would ever have an issue. I’m just as concerned, if not more, with something upstream from us having an issue; whether that be an internet provider or Duo Cloud themselves being down. Based on my testing and yours, and the response from support, we should be able to use Offline access via RDP.

As for the Offline Codes per host scenario, this was the response i received on that:

[Goatherder]

nah…that is rubbish, on both accounts. I actually found out by accident, as I tried to RDP into a server, and Duo said “enter the offline code”. It alarmed me, and fumbled for my phone…only to find that out ISP had had an outage. Subsequent testing, by disabling the network for a VM, repro’ed the same behaviour. This has got nothing to do with local…simply if the host cannot get to Duo’s server…the offline will be used.
So, the last snippit from support…each server needs to have an offline code for each admin. That pretty much discounts me from using Duo. That, is a poor design choice. Our Enterprise is ~7000 servers, with ~400 admins, so that set up is going to be unmanageable.

[BWarrenITC]

It would be nice if Duo Support would chime in on this thread.

The only other options I see being possible is to use a Hardware Token like a Yubikey. Then you would still have to add that key for offline access on each server, but you wouldn’t have thousands of offline access codes in the Duo Mobile App. (This would still be a big pain) Or, you would have to run FailOpen mode so that when Duo cannot be contacted, it bypasses MFA. This seems like a huge security risk to me and could be easily circumvented by threat actors, essentially rendering your MFA solution useless.

[Goatherder]

One would hope Duo would chime in.
This is over complicated…and having a user using the same generated code for multiple servers, should not be hard. This is how RSA tokens operated for years…and actually how Google Authenticator and MS Authenticator work with OTP. I don’t want to manage Yubikeys…that is why I came to Duo !!

[Amy2]

Hi @BWarrenITC and @Goatherder, thanks for your discussion here! As a friendly reminder, the Duo Community is not an official support channel, and while we do our best to reply to everyone, responses aren’t guaranteed. Hopefully, I can add some helpful context here though.

From what you’ve said here, the use case you’re describing is fail-safe access into servers. Our Offline Access solution is only intended for temporary offline cases, however.

We developed this feature in response to customers who were asking for a better option than the fail open/closed behavior the Duo application had while a system is temporarily offline, such as employees using their laptop while on a plane.

While it’s likely not ideal for your purposes, if FailOpen is a concern for you, you could set the fail mode to FailClosed knowing that Duo has maintained an uptime of greater than 99.99% for more than four years, and we offer a hard service level guarantee backed by SLA (link here).

ETA: We do have an open feature request for bulk provisioning offline access for users. If you’re interested in adding your support for that, you can do so through the Duo Support team or by working with your Customer Success Manager, Account Executive, or MSP Provider if those are applicable to you!

[Goatherder]

Thanks Amy.
The intent of this conversation was to ascertain, what is Duo’s design philosophy behind offline access in an Enterprise, when you have several thousand servers and hundreds of admins. Whilst I appreciate that offline access is a temporary solution, I fully understand that…but frankly, I don’t want hosts to drop off the network either ! This is a “get yourself out of a hole” issue, but when you think of this from a large Enterprise perspective, it is not scalable. The ask was “is it supposed to be like this” or “how would Duo suggest using their product, in such an Enterprise”. If there is an ingress to Duo directly, that can succinctly answer this, I would appreciate it…after all, this is a huge sales opportunity, that may just be dismissed.

[Amy2]

Goatherder:

what is Duo’s design philosophy behind offline access in an Enterprise, when you have several thousand servers and hundreds of admins

Offline Access is not intended for admins to log on when a server or machine is offline. It is intended for users to log in when offline.

For an admin to gain access when a system or server is offline, there are other methods. FailMode is one of those methods. You can also boot into Safe Mode and temporarily disable Duo Authentication to regain access. Given Safe Mode is a means of access in an emergency, you will want to ensure your systems have BIOS passwords and are encrypted.

You will also need to furnish your admins with the passwords and keys to access Safe Mode in the first place. They will either need to have physical access to the machine, console access for a virtual machine, or even potentially ILO card access for physical servers.

Another option is to use a break-glass account that can be shared among admins if needed for offline access. This would still need to be set up on each server.

[pgp]

If these systems are in Active Directory, and the internal network (to the Domain Controllers) is still working, couldn’t you use the GPOs for Duo Authentication for Windows to push out a change from FailClosed to FailOpen? At worst (with default settings) the change would happen within approx. 2 hours.