You are authenticating users against an Active Directory and users receive this error message either intermittently or regularly. You want to know what causes this and what can be done to fix it.
Active Directory authentication (especially Kerberos) relies heavily on exact timestamps. For example Kerberos tickets only have a short lifetime, after which they expire and can't be used anymore. If the ProxySG is not synchronizing with the same NTP Server that the Active Directory uses or is not using NTP at all, you will eventually experience a time drift that is sufficiently large to cause this error message.
At this point in time, if NTP is used, we would also expect to see related error messages in the eventlog, similar to these:
"NTP: Periodic query of server 18.104.22.168, system clock is 0 seconds 300 ms slow compared to NTP time. Updated system clock."
"NTP: Periodic query of server 22.214.171.124, time within acceptable variance, 0 seconds, 198 ms slow compared to NTP time."
By default we query the configured NTP server once every hour - if the eventlog shows one of these messages every hour and the drift is significant (i.e. more than ~50ms), then we need to find out where this drift is happening. A small drift is normal and can be ignored.
NTP (udp/123) is designed to take network latency into account when making an NTP request, so unless network latency is extreme, it should not matter.
The first thing to check is to make sure you are actually using NTP. In the GUI, browse to Configuration -> General -> Clock and make sure the tick box for NTP is ticked:
Should you desire so, you can also change the query interval from the default 60 minutes to any other interval.
With NTP enabled, we can move on to the NTP tab to specify which NTP servers will be queried:
This is critical because you need to use the same NTP server that your Active Directory uses. NTP has a hierarchical structure of servers called strata. A stratum 0 server is a high-precision timer, usually an atomic clock, which is used as a reference time source. These stratum 0 servers are queried by the next lower level called stratum 1 servers. These stratum 1 servers get their time from stratum 0 servers and provide time to the next level, stratum 2 servers. This goes up to stratum 15, which is the lowest level (stratum 16 means the device is unsynchronized).
So in your AD you have a time server (this is a requirement for AD), this time server gets its time from the next higher stratum server, which in turn gets its time from its next higher level and so on. The time on all these strata should be identical, so ideally you should specify the same NTP Server that your AD uses, but you should also be able to use any of the servers in this NTP hierarchy.
If your AD deployment does not rely on an external high-level NTP server, then most likely you have an internal high-precision timer which provides time to your AD. By default the SG is configured to use Blue Coat NTP servers (which eventually get their time from a stratum 0 server) - this can cause a discrepancy if your internal NTP server is not as accurate as external NTP servers (going up through the strata). Eventually the drift between the SGs time and the ADs time will be big enough to cause these authentication problems.