PfSense and Windows Primary Domain Controller (NTP)?

[Robert Fontaine]

After a fair bit of tire kicking I have a 2016 Server Primary Domain Controller set up with DNS, DHCP, and NTP up and working correctly.

I configured the Windows NTP Server to point at my national NTP server pool.

.... I have just been looking at my PfSense firewall/router and thinking. Hmmm.... Should my Firewall NTP Server be pointed at the national pool and the Internal PDC be pointed at my Firewall/Router.
-> In my head it seems like it would be betterer to have a layer of indirection such that the PDC doesn't talk to the outside world but I can't think why (just seems like a righter solution).

So what is best practice here?
It is my understanding the MSFT is a lot happier with DNS, DHCP managed on the domain controller with Active Directory but that may not make it right either.

Thanks,
robert

 

[kapone]

I also use a "single point" strategy. Have "one" device sync time with an external provider, and everything else syncs with that. That of course brings up your question as to which device to choose. Up until I was using a single firewall/router (pfsense as well), I let pfsense be that one device. However, over the last few months, I have added redundancy to pfsense, sp now I have two, as well as a backup internet connection. That complicates things in terms of a single point strategy.

With that, I decided to use my primary DC as that one device. The thinking was, I'm only ever going to have one "primary" DC, so make it the time server.

Off topic: I'm still on Server 2012 R2 (not that it matters) and have no intention of moving to Server 2016, unless Microsoft decides to offer users control (to the extent that it can) over their telemetry in Server 2016 (and Windows 10)...

 

[EffrafaxOfWug]

On a scale like this it doesn't really matter, but normally if you're using external time sources (as opposed to internal clocks) it's generally safer and easier to get your network equipment (in this case pfsense) to query the external NTP, and then present it internally. This way your DC can query the pfsense directly and you don't need a firewall rule allowing 123 to the outside world.

In any case, NTP on pfsense should be a much better behaved beast than SNTP on windows (although caveats apply for things like virtualisation).

So my advice would be to set up NTP on pfsense pointed to at least three different servers and reconfigure your domain controller (and indeed, everything else you have that can talk NTP) to point at pfsense instead of the external pool.

 

[Robert Fontaine]

Thanks guys, appreciate the input.

Tonight, I will start standing up the IIS Server, then on to Exchange, S4B, SQL SErver, and a MS File Server....

Trying to get to the point of a miniature msft corporate network in the dungeon to hack on.

I wish userland was unix based.

 

[PigLover]

On a scale like this it doesn't really matter, but normally if you're using external time sources (as opposed to internal clocks) it's generally safer and easier to get your network equipment (in this case pfsense) to query the external NTP, and then present it internally. This way your DC can query the pfsense directly and you don't need a firewall rule allowing 123 to the outside world.

In any case, NTP on pfsense should be a much better behaved beast than SNTP on windows (although caveats apply for things like virtualisation).

So my advice would be to set up NTP on pfsense pointed to at least three different servers and reconfigure your domain controller (and indeed, everything else you have that can talk NTP) to point at pfsense instead of the external pool.

+1 for this.

Have pfSense sync to the outside world. Have the DC sync to pfSense. Let your windows clients sync to the DC. Have any "non domain" devices just sync to pfSense.

While the "extra hop" might bother some people this approach works for the Domain in failures because the domain members are all sync'd to the DC. This is in addition to the minor security improvement noted by @EffrafaxOfWug.