[9.090][ANSWERED] NTP Sync

I imagine that the SYNC should happen to the IP 192.168.3.43, my AD/NTP Server. As if the timetables are not synchronized, with proxy authentication errors may occur.

ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*127.127.1.0     .LOCL.          10 l   95  128    1    0.000    0.000   0.000
 192.168.3.43    .LOCL.           1 u   58  128    7    1.146  -567668   0.742

I imagine that the SYNC should happen to the IP 192.168.3.43, my AD/NTP Server. As if the timetables are not synchronized, with proxy authentication errors may occur.

ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*127.127.1.0     .LOCL.          10 l   95  128    1    0.000    0.000   0.000
 192.168.3.43    .LOCL.           1 u   58  128    7    1.146  -567668   0.742

Yes, for some reason astaro does not consider your time server to be valid. The asterisk 

•  beside 127.127.1.0 means astaro is using the local hardware clock and not the time server that you provided. Also from the output, looks like your AD time server is not syncing with any upstream ntp server and maybe the reason its not considered an accurate time source. 
  
  Here is an article that explains the output of ntpq http://tech.kulish.com/2007/10/30/ntp-ntpq-output-explained/
  
  Regards
  Bill

This behavior should not happen, UTm should use the NTP that I set, regardless of being an external server or internal site/server. For example, my AD should not have external access to synchronize and my stations must believe that he has the time.

This is an internal policy of each company and this behavior should not be changed. Any chance of being changed in 9.1?

This behavior should not happen, UTm should use the NTP that I set, regardless of being an external server or internal site/server.

I've worked with NTP for several years (I run several pool servers) and what you are seeing is normal for NTP. Basically, if the NTP server doesn't see any servers on it's peer list that it 'trusts' (are supplying good time), it will fallback to it's own internal clock.

The practice we follow, and I believe is the best way to handle this, is to set the UTM to query the NTP Pool Servers. Active Directory PDC's can then query the UTM as required.

This keeps AD within the protected fence of the UTM