Office 365 – AD FS Authentication Fails Due To Time Skew

I’ve run across this issue enough times now that I figured it was worth a short post. It’s a quick reminder to always check the simple things.
On several occasions I’ve found AD FS environments where authentication via the internal AD FS servers works but authentication via the AD FS proxy does not. With this statement, it’s also important to remember that the Outlook client authentication is proxied by Exchange Online via the AD FS proxy, even when on the internal network.
When attempting to authenticate via the proxy, you might be greeted with the error below:

Revolutionize Your Business With Generative AI

From product design and software development to virtual agents, content creation, and reporting, GenAI is transforming business. Our AI experts help you unlock GenAI’s full potential and drive growth.

Let’s Get Started

You can pull Office 365 out of the mix by trying to access the following URL from an external machine.

https://sts.company.com/adfs/ls/IdpInitiatedSignon.aspx

If you receive the error above instead of being prompted to sign in, it’s time to start looking at event logs on the AD FS servers.
Looking at the event logs on the proxy, you might find an event ID 364:

While this error can be caused by a number of different things, one of them is time skew between the AD FS proxy and the AD FS internal server.
Given that the AD FS proxy resides in a DMZ network and is not domain joined, it’s not uncommon to find that the server does not have the same time sync configuration as an internal server might; in many cases, I’ve found that it has no time sync configured at all. On virtualized platforms, the platform’s respective client-side tools usually have time sync settings in them that come into play as well.
Of the possible resolutions for event ID 364, checking the time is surely the quickest. So give those clocks (both time & time zone) a quick check!