NTP status is reject under PAM
search cancel

NTP status is reject under PAM


Article ID: 97875


Updated On:


CA Privileged Access Manager - Cloakware Password Authority (PA) CA Privileged Access Manager (PAM)


Even when NTP server was setup successfully and other devices can poll time from it, PAM shows "Reject" when trying to get time from this NTP server.
This "Reject" status continues even after several refresh from PAM.

1. Confirm NTP server is configured well, other device could get time information from it.
2. Port 123 is opened on firewall
3. Ping is OK from PAM to NTP server


Privileged Access Manager, all versions


1. Check portscan under PAM UI -> configuration -> Tools, to see port 123 is opened, you can also do this on NTP server itself by checking iptables policy is configured well.

2. At the NTP server, check ntp.conf to confirm if PAM server IP or subnet is permitted to get ntp parameter by RESTRICT. 
e.g. restrict mask nomodify

3. Check the syslog or ntplog, there may be some useful information recorded there.

4. Check whether your PAM DNS configured and if it works well to recognize NTP server by Tools -> Resolve Name, input NTP server hostname and check the result.  This may leads PAM not communicate to NTP well.

5. If possible, user NTP server on Linux (ntpd) instead of NTP server on Windows (w32time) as below description.
From the "Windows Time Service Technical Reference": 

"The W32Time service is not a full-featured NTP solution that meets time-sensitive application needs and is not supported by Microsoft as such. For more information, see Microsoft Knowledge Base article 939322, Support boundary to configure the Windows Time service for high-accuracy environments (http://go.microsoft.com/fwlink/?LinkID=179459)." 


ntpd is the reference implementation of an ntp protocol server. It is what is used on almost all unix server. You can also get versions compiled for windows. 

The problem is not that w32tm is not reliable (although it is not as accurate as ntpd), the problem is that the time server you are using, that happens to be running w32tm, is not considered reliable by the ntpd servers set to sync to it. 


"If the upstream stratum from which you are synchronizing your clock is off by 1000 milliseconds, or 1 full second, that time source will not be used in synchronizing your clock, and others will be picked instead (this is to help weed out bad time sources)." 


If all above does not resolve issue, double check to see if you can use the Global publicly available NTP servers:



or you can use the regional ones located here: