Response issue time is either too old or with date in the future, skew 60 prevents users from log in to Azure Operation Manager with SSO

Products

• Operations Manager

Issue/Introduction

When logging into the ops manager user interface with Azure IaaS, the following error message is displayed on the screen:

Response issue time is either too old or with date in the future, skew 60

Ops Manager VM failed to synchronize with the NTP server. This blocks users to log into Ops Manager UI.

Environment

Product Version: 2.10

Resolution

Explanation:
As far as the OpsMan VM is concerned, it depends on the IaaS where it is deployed and the exact version. The background is that the Xenial Kernel (which Opsman 2.10 is using) at some point had an incompatibility with the Azure PHC (Precision Hardware Clock + chrony setup). Please refer: Time sync for Linux VMs in Azure

The Xenial Stemcell (that opsman 2.10 is based on) added this usage as well, but it eventually got reverted because of the aforementioned kernel issue. Please refer: Configure chrony to use hardware clock on Azure

There was a regression here that left Azure Opsman without chronyc enabled, therefore, Ops Manager did not do anything to sync it's time after initial boot. 

Permanent-Fix:
A fix for the Azure OpsMan issue has been shift in 2.10.55+.
Here is the related release note:

• [Bug Fix] Fix time synchronization on Azure-based Ops Manager VMs

 

Temporary-Fix:
For example, use time1.google.com as NTP server.

Manually edit the `chrony.conf` found at:

/etc/chrony/chrony.conf

Append these lines to configure your NTP Server.

# Added Servers:
# e.g. server time.example.com iburst
# e.g. server 1.2.3.4 iburst
server time1.google.com iburst

After applying the configuration changes,  enable and start the chrony service, then verify it is up and running:

sudo systemctl enable chrony
sudo systemctl start chrony
sudo systemctl status chrony

The last command should print out something similar to:

# systemctl status chrony
● chrony.service - LSB: Controls chronyd NTP time daemon
   Loaded: loaded (/etc/init.d/chrony; bad; vendor preset: enabled)
  Drop-In: /etc/systemd/system/chrony.service.d
           └─restart.conf
   Active: active (running) since Thu 2023-02-23 08:38:23 UTC; 57s ago
     Docs: man:systemd-sysv-generator(8)
 Main PID: 23162 (chronyd)
   CGroup: /system.slice/chrony.service
           └─23162 /usr/sbin/chronyd

Feb 23 08:38:21 ops-manager systemd[1]: Starting LSB: Controls chronyd NTP time daemon...
Feb 23 08:38:21 ops-manager chronyd[23162]: chronyd version 2.1.1 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP -DEBUG +ASYNCDNS +IPV6 +SECHASH)
Feb 23 08:38:21 ops-manager chronyd[23162]: Frequency 0.000 +/- 1000000.000 ppm read from /var/lib/chrony/chrony.drift
Feb 23 08:38:21 ops-manager chronyd[23162]: Could not open IPv6 command socket : Address family not supported by protocol
Feb 23 08:38:23 ops-manager chrony[23156]: chronyd is running and online.
Feb 23 08:38:23 ops-manager systemd[1]: Started LSB: Controls chronyd NTP time daemon.
Feb 23 08:38:25 ops-manager chronyd[23162]: Selected source 216.239.35.0
Feb 23 08:38:25 ops-manager chronyd[23162]: System clock wrong by 0.958821 seconds, adjustment started

You should see Active: active (running) from the result.

Finally, check the NTP sources and confirm that the system clock is synchronized correctly to the upstream time server:

root@paraguay-ops-manager:/home/ubuntu# nslookup time1.google.com
S...
Non-authoritative answer:
Name:   time1.google.com
Address: 216.239.35.0

In the case above, the Ops Manager VM is synchronized to time1.google.com(216.239.35.0).

Important Notice: 
In general, it is advised to use well known NTP servers instead of relying on a random public pool.