[Samba] Joining Windows 10 Domain Member to Samba AD/DC

[Mark Foley]

I think this didn't get sent to the maillist.

--Mark

-----Original Message-----
Date: Fri, 05 Jan 2024 13:58:08 -0500
Organization: Novatec Software Engineering, LLC
To: samba-bounces at lists.samba.org
Subject: Re: [Samba] Joining Windows 10 Domain Member to Samba AD/DC

On Thu Jan  4 22:42:38 2024 Sonic <sonicsmith at gmail.com> wrote:
>
> On Thu, Jan 4, 2024 at 7:46 PM Mark Foley via samba
> <samba at lists.samba.org> wrote:
> > I've added a Windows 10 domain member to my Domain. I'm now following the
> > procedure in https://wiki.samba.org/index.php/Time_Synchronisation#Configuring_Time_Synchronisation_on_a_Windows_Domain_Member.
> > What's going wrong here?
>
> Is there some reason you need a GPO for this? By default the system
> should get its time from the DC.
> From the page you refer to:
> "Windows AD domain members will use any DC as their default time
> source. If you have set up ntp on the DC as described on this page,
> you usually do not need to reconfigure the clients. Alternative
> configuration options for the clients are described below."
>
> I've only used a GPO to point to a different time server when the DC
> is incapable of providing the time service (older DC running in a
> container).
> Chris

When I initially did 'w32tm /query /source' on the Windows domain member I got
back time.windows.com, not the DC.  On my current Samba DC I had to set the NTP
server on the Windows 10 computers when using the Samba DC.  

I missed a couple of commands in my previous post.  On the Windows as Admin:

net stop w32time
w32tm /unregister
w32tm /register
w32tm /config /manualpeerlist:dc1,0x8 /syncfromflags:MANUAL
net start w32time
w32tm /config /update

When I did the first 3 and last of the above command initially, 'w32tm /query
/source' returned 'Local CMOS Clock', and this query has remained like that
since, even doing all the commands listed above again and rebooting both Windows
and DC computers.

I don't think 'Local CMOS Clock' is right in any case. This is likely worse than
using time.windows.com. 

Maybe I didn't build ntpd with --enable-ntp-signd. How would I test for that?

Thanks --Mark