NTP and DCs

Jump to latest Follow Reply
J

jediatzinger

Ars Praefectus
3,260
  • #1
    I'm in the process of decomissioning two old Server 2008 R2 DCs.

    I've installed AD DS on two new Server 2022's (now DCs!). I had notes from way back when I setup the 2008 R2's, but those were the first DCs in the forest so there wasn't any migration.

    On the PDC emulator role (Server 2008 R2) I had opened Command Prompt and entered the following command:

    w32tm /config /syncfromflags:manual /manualpeerlist:0.pool.ntp.org,1.pool.ntp.org,2.pool.ntp.org,3.pool.ntp.org /reliable:yes /update

    This has worked since 2013 w/o any issues.

    There isn't any issue now, but I want to avoid any before I decomission and shutdown the old DCs!!

    I have setup DHCP, DNS, and moved the FSMO roles to one of the new 2022 DCs. It's been a week for DHCP and DNS and those are working perfectly. I entered the same command on this new DC for ntp, but other servers are still showing the old DC as their source when I run: w32tm /query /source

    I migrated the FSMO roles today. Have I not waited long enough for it to propigate? Or is there something I'm missing. Do I need to do anything to the old DC that's been running NTP? I'm not sure if there is a decomissioning for that service or not.

    comments, recommendations - all appreciated. TY.

    edit: I know NTP uses port 123 UDP. I’m not sure if by default that port is allowed in/out on the Windows Firewall? I don’t remember opening anything previously.
     
    Last edited:
    Ligushka

    Ligushka

    Ars Praefectus
    3,906
  • #2
    I suggest configuring PDCe time sync via GPO so that any time FSMO roles are moved (whether it be intentional or in a recovery situation), you don't have to remember to manually set up time sync again. This article seems to have a well-written overview of how NT5DS works and has an example of the GPO in question: https://www.ravenswoodtechnology.com/in-sync-proper-time-configuration-in-ad/

    Once that's done, make sure the rest of the domain controllers are properly set up to use NT5DS and aren't set manually to point to the old DC.

    When you run w32tm /query /source on a couple workstations, do they point to any of the DCs? Or something else?
     
    • Like
    Reactions: dodexahedron, Utildayael and sryan2k1
    J

    jediatzinger

    Ars Praefectus
    3,260
  • #3
    I'm going to look into setting up the GPO for sure, but after 10 years on the same two DCs I made better notes for next time, but I think the GPO is the right way to go for the long haul.

    I had to run several of these commands. All is good now, but the main one was /rediscover for the servers that didn't want to update or I didn't want to wait that long ;)

    w32tm /query /configuration
    w32tm /query /peers
    w32tm /resync /nowait
    w32tm /query /source
    w32tm /query /status

    w32tm /config /syncfromflags:DOMHIER /update
    w32tm /resync /nowait
    net stop w32time
    net start w32time

    w32tm /resync /rediscover

    All servers now show my PDC emulator (new 2022 server) and their /source and I checked several workstations and they're the same.

    edit: to answer my own question: Yes port 123 is open by default on the NTP server.
     
    C

    chalex

    Ars Legatus Legionis
    11,286
    Subscriptor++
  • #4
    Sorry for the thread necro but I have a very similar but different issue.

    We have a bunch of Windows clients that are losing network time sync. The common thread among this subset of clients is they are all on a particular network (we have a pile of VLANs at our site, with firewalls between).

    However, NTP traffic (udp port 123) is definitely allowed in the firewall and in fact I can tcpdump on the domain controller side and see the clients are talking to the DCs about NTP. But despite all the Windows NTP settings being correct on both the DCs and the clients (in fact they are all defaults, no site-specific changes), some machines fall back to "local CMOS clock". The error message is ...

    In the time GUI, it says "settings controlled by your domain" and then “time synchronization failed”.

    I ran various commands like
    Useful commands:
    w32tm /query /status
    w32tm /query /status /verbose
    w32tm /query /configuration
    w32tm /query /peers
    w32tm /resync
    w32tm /resync /rediscover
    w32tm /stripchart /computer:pve-dc02.calicolabs.local /samples:5 /dataonly


    on /resync, the error is "The computer did not resync because no time data was available." Even though I'm watching the NTP packet go to the DC and the DC responds with the time, e.g.:

    13:30:06.506290 IP (tos 0x0, ttl 127, id 49427, offset 0, flags [none], proto UDP (17), length 76) IT-W11-2358.obfuscated.local.ntp > pve-dc02.obfuscated.local.ntp: NTPv3, Client, length 48 Leap indicator: (0), Stratum 3 (secondary reference), poll 17 (131072s), precision -23 Root Delay: 0.000000, Root dispersion: 10.000000, Reference-ID: 0x0a0b0e0b Reference Timestamp: 3905872207.442359099 (2023-10-09T20:30:07Z) Originator Timestamp: 0.000000000 Receive Timestamp: 0.000000000 Transmit Timestamp: 3905872207.442360199 (2023-10-09T20:30:07Z) Originator - Receive Timestamp: 0.000000000 Originator - Transmit Timestamp: 3905872207.442360199 (2023-10-09T20:30:07Z) 13:30:06.506918 IP (tos 0x0, ttl 128, id 24236, offset 0, flags [none], proto UDP (17), length 76) pve-dc02.obfuscated.local.ntp > IT-W11-2358.obfuscated.local.ntp: NTPv3, Server, length 48 Leap indicator: (0), Stratum 2 (secondary reference), poll 17 (131072s), precision -23 Root Delay: 0.020034, Root dispersion: 0.021453, Reference-ID: 0xd8ef2300 Reference Timestamp: 3905872189.679096399 (2023-10-09T20:29:49Z) Originator Timestamp: 3905872207.442360199 (2023-10-09T20:30:07Z) Receive Timestamp: 3905872206.507066399 (2023-10-09T20:30:06Z) Transmit Timestamp: 3905872206.507098399 (2023-10-09T20:30:06Z) Originator - Receive Timestamp: -0.935293800 Originator - Transmit Timestamp: -0.935261800

    One thing that immediately fixes the client is switching to a different network. So originally we thought it was a simple problem of udp 123 not passing between those networks. But now it seems specific to a subset of clients but on a specific network.

    Any ideas about how to troubleshoot Windows client NTP further? I read through like every result on the first two pages of google for the various errors from w32tm and it seems like people usually find a simple culprit. Is it possible that we need something beyond udp/123? These are otherwise stock Win10/Win11 domain-joined desktops.
     
    C

    chalex

    Ars Legatus Legionis
    11,286
    Subscriptor++
  • #6
    So I tried it from a Linux box on the same network(s), talking to the same remote DCs and I'm able to see the NTP packets (and Linux NTP client works fine) but I guess you're right, for completeness I need to check on the Windows client itself to see if it's actually getting the answer back. But that would suggest again something different about the network...
     
    C

    chalex

    Ars Legatus Legionis
    11,286
    Subscriptor++
  • #7
    On the Windows client side, this is the process to stop the service, wipe its config (any relevant registry entries) then re-start it with default config:

    net stop w32time
    w32tm /unregister
    w32tm /register
    net start w32time

    As domain members they will automatically discover the DC as the time server and talk NTP to it. We can also double-check with "w32tm /query /status /verbose" that is says "mode 3 client"


    Actually I just ran into a new (to me) issue, on the Windows clients, if I run
    w32tm /monitor
    I get the error "GetDCList failed with error code: 0x80070005"
    I tried as regular user and as admin user both in cmd and powershell.
    But I get the same thing on the 3 Windows clients I tried so far, so either that's normal, or something is wrong with the DCs, or there is some other network issue preventing the machines from some communication with the DCs?

    Anyway, I'm back to the original hypothesis, something is weird about the firewall of this specific network.
     
    D

    DrWebster

    Ars Praefectus
    3,770
    Subscriptor++
  • #8
    chalex said:
    But that would suggest again something different about the network...
    Click to expand...
    You've confirmed this already when you said that the same machines suddenly work fine when on a different network. Do you have a firewall device (not the Windows host firewall) or ACL on the switches between this particular network and the DCs?
     
    C

    chalex

    Ars Legatus Legionis
    11,286
    Subscriptor++
  • #9
    DrWebster said:
    You've confirmed this already when you said that the same machines suddenly work fine when on a different network. Do you have a firewall device (not the Windows host firewall) or ACL on the switches between this particular network and the DCs?
    Click to expand...
    Yes, right, but other Windows and Linux machines work fine on this network also. So we're pretty sure the firewall is not to blame, but why just a subset of the Windows clients? Then the hypothesis would be that there is some different ntp client configuration on some clients but they are all in the same domain with default ntp client settings...
     
    C

    chalex

    Ars Legatus Legionis
    11,286
    Subscriptor++
  • #10
    So in the end it was firewall rules. In one direction they allowed traffic to port 123 but in the other direction they allowed port 123 -> high ports only. Turns out ntpdate on Linux uses a high source port but windows ntp client uses port 123.

    I should have used ntpd on Linux for testing instead of ntpdate, or should have been more rigorous about checking the packets received on the Windows clients and not just sent from the DCs. Or if our network guys knew more about NTP and just allowed packets with destination port 123 in both directions...
     
    • Like
    Reactions: oikjn
    I

    Incarnate

    Ars Tribunus Angusticlavius
    8,806
  • #11
    chalex said:
    So in the end it was firewall rules. In one direction they allowed traffic to port 123 but in the other direction they allowed port 123 -> high ports only. Turns out ntpdate on Linux uses a high source port but windows ntp client uses port 123.
    Click to expand...
    Is it really a firewall, or just ACLs? A firewall is usually stateful and will allow return traffic.
     
    Ligushka

    Ligushka

    Ars Praefectus
    3,906
  • #14
    CPX said:
    Is this just a GPO with the opposite filter? Or applies when the FSMO 5 filter is untrue? Or just turn them all back to /syncfromflags DOMHIER?
    Click to expand...
    Hmmm, I never set any time settings for clients via GPO (other than block users from being able to adjust time and/or timezone). It may "just work" if you set the DOMHIER back to default.
     
    D

    dodexahedron

    Ars Praefectus
    3,356
    Subscriptor++
  • #17
    Incarnate said:
    Is it really a firewall, or just ACLs? A firewall is usually stateful and will allow return traffic.
    Click to expand...
    Totally depends on how it's configured, of course.
    A cisco IOS(-XE) device with ACLs on interfaces? Yeah, that's totally stateless. The same device with ZBFW or (the old way) a service policy on the appropriate interfaces in the appropriate directions turns it stateful.

    Similar idiosyncrasies exist on various other platforms, as well.
    Just gotta know your technology and hope the guys on the relevant team have a clue without you having to step on any toes. 😅
     
    You must log in or register to reply here.
    Jump to latest Follow Reply
    Jump to latest Follow Reply