Bad Request Timestamp 40105 Error


#1

So I upgraded the client on a Windows Server 2012 R2 to the latest version and when I try to log back in, I am now faced with this error message. I’m effectively locked out of my server with no way in either directly logging into the server (physical access) or from remote. I found an article that mentioned to make sure the server is properly synched with a time server but I can’t get access to make that happen! And this wasn’t an issue with the previous version of the Duo client.

Any suggestions?


#2

Hello NashBrydges!

I have three suggestions:

  1. Log into your Duo Admin Panel and see if you can find your failed authentication attempt in the Authentication Logs. If you do see it, this indicates your Windows Server has connectivity to Duo’s cloud service. If this is the case, put your user in bypass status and try logging in again.

  2. If the authentication attempt is not appearing in the Authentication Logs, that’s a good indicator your Windows Server does not have connectivity to Duo’s cloud service. You could push an update to that Windows Server via GPO to tell it to FailOpen under this condition.
    https://duo.com/docs/rdp-faq#how-can-i-configure-the-fail-mode?

  3. If you have physical access to the Windows Server, you could try booting into safe mode and uninstalling Duo.
    https://duo.com/docs/rdp-faq#how-do-i-disable-or-uninstall-duo-authentication-for-windows-logon-in-safe-mode?

best,
-Greg


#3

I don’t really see this as solution. Answers to the suggestions provided:

  1. Yes, the server does have internet access but no log shows on duo admin.
  2. Server not part of a domain, can’t push group policy. Even setting the Fail mode beforehand won’t work as the server can communicate with the duo servers.
  3. No access to the console of the server (virtual)

So we are locked out of the server due to the time on the server to be out. Enable bypass on the user does not work. Now we need to power down the production server, attach the windows os disk to another virtual server, modify the registry to bypass/disable duo at login, reattach to original server and boot it up. This causes us to have down time on production servers due to the time to be out by a few minutes.

There must be better solutions for this issue.


#4

Do you not have console access to the host via whatever virtualization hypervisor you’re using (e.g. if VMWare connect to the console from vCenter)?

If so, you could try the previous suggestion #3 to remove the Duo software, or perhaps one of these solutions:

  1. If you accepted the default “fail open” setting and have virtual console access to the server, disconnect the network and log in at the console to update your system’s time or uninstall Duo. If Duo for Windows Logon can’t contact the cloud service and the application is configured to fail open you can log in.

Similarly to #2, if you accepted the default “fail open” setting and have remote file system access to the server (like via the UNC path \\servername\c$), you could add an entry for your Duo API host with a fake IP to the server’s hosts file, and then RDP to the machine to update the system time or uninstall Duo.


#5

No access to console, using 3rd party virtual environment and they do not provide console access.

Thanks for the idea on editing the hosts file to force fail communications with duo. Easier might be to block duo servers on the outgoing firewall.

I still think that the easiest solution will be that the duo app will comply with the ‘bypass’ setting set on the duo admin console. Thus, if this happens we can disable duo for the account with no access / changes required on the server/firewall.


#6

I do understand your idea about respecting the user’s bypass status to let a user log in, but if the Duo service isn’t able to verify the integrity of the incoming request (due to the bad timestamp or invalid integration information) then we’d be remiss to allow access.


#7

Ah, thought it might be a blocker. Thanks