Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: [Samba] Samba4: W2k clients cannot set / sync time with samba4 AD DC
2 views
Skip to first unread message
?icro MEGAS
Apr 25, 2013, 4:50:01 AM4/25/13
to
Hello,
I HAVE sniffed the network traffic for this w2k client and
provided the link via paste.ubuntu.com, so everybody can look inside
that without the need
of extra-tools like wireshark. And as I realized you have looked into
that sniffed result output. I did it this way, because I work on an
isolated test env which I cannot access through my computers and do file
transfers. And I dont have wireshark installed on samba4 host, so I
would not be able to transfer the .pcap file to my computer and upload
it. But if you really prefer a .PCAP sniff of tcpdump I could do that,
have to do some prerequisites for that network/switch to be able to
transfer these files additionally to my computer.
> Finally, I would ask that you help yourself:
>
> 08:28:00.436507 IP 172.16.200.66.3557 > samba4srv.mysite.com.ntp: NTPv2,
> Client, length 68
> 08:28:00.436576 IP samba4srv.mysite.com > 172.16.200.66: ICMP samba4srv
> .mysite.com udp port ntp unreachable, length 104
>
> Is the NTP server set up correctly? If the clients can't contact the
> NTP server, then it doesn't surprise me that they can't use it.
Well, the NTP server on samba4 server is definitely (!) up and
running. I can triple-check that by "ps", "netstat" and of course by
getting the time of all my other clients (winxp, win7, linux, unix) so
NTP server is definitely running on samba4 host.
> 08:28:00.436576 IP samba4srv.mysite.com > 172.16.200.66: ICMP samba4srv
> .mysite.com udp port ntp unreachable, length 104
This was the last packet as I posted. Looks like samba4srv tried
to reach the UDP:123 of w2k client, which of course will fail as no NTP
server is running on w2k client side? I cannot explain that, but I
definitely know that the NTP daemon is running fine on samba4 side.
> I also don't understand why you can't use any number of other tools
> (such as free NTP clients or forcing the NTP server with a script or
> policy) to set the time for this specific deployment.
Because I would prefer the raw way, as I would suppose from a
Microsoft client to do. The inital problem was, that w2k clients are not
able to perform dynamic updates, and one point that can cause this
error is that the w2k is not in time sync with its associated domain
controller (as it was in my case). I haved red carefully many tech and
white papers of Microsoft which explains that W2k clients are not
restricted on any way to do them because they CAN. But the problem is
TIME DIFFERENCE. So I have to focus on this time sync issue, else I will
not be able to do the final samba4 migration. As I said, I have lots of
W2k clients in prod. environment and one would expect that they can
sync their time. They can if a Microsoft Windows Server is used. So why
the need to install, deploy or whatever, a 3rd party tool when it should
work on raw way normally?
Cheers,
Lucas.
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba
I HAVE sniffed the network traffic for this w2k client and
provided the link via paste.ubuntu.com, so everybody can look inside
that without the need
of extra-tools like wireshark. And as I realized you have looked into
that sniffed result output. I did it this way, because I work on an
isolated test env which I cannot access through my computers and do file
transfers. And I dont have wireshark installed on samba4 host, so I
would not be able to transfer the .pcap file to my computer and upload
it. But if you really prefer a .PCAP sniff of tcpdump I could do that,
have to do some prerequisites for that network/switch to be able to
transfer these files additionally to my computer.
> Finally, I would ask that you help yourself:
>
> 08:28:00.436507 IP 172.16.200.66.3557 > samba4srv.mysite.com.ntp: NTPv2,
> Client, length 68
> 08:28:00.436576 IP samba4srv.mysite.com > 172.16.200.66: ICMP samba4srv
> .mysite.com udp port ntp unreachable, length 104
>
> Is the NTP server set up correctly? If the clients can't contact the
> NTP server, then it doesn't surprise me that they can't use it.
Well, the NTP server on samba4 server is definitely (!) up and
running. I can triple-check that by "ps", "netstat" and of course by
getting the time of all my other clients (winxp, win7, linux, unix) so
NTP server is definitely running on samba4 host.
> 08:28:00.436576 IP samba4srv.mysite.com > 172.16.200.66: ICMP samba4srv
> .mysite.com udp port ntp unreachable, length 104
This was the last packet as I posted. Looks like samba4srv tried
to reach the UDP:123 of w2k client, which of course will fail as no NTP
server is running on w2k client side? I cannot explain that, but I
definitely know that the NTP daemon is running fine on samba4 side.
> I also don't understand why you can't use any number of other tools
> (such as free NTP clients or forcing the NTP server with a script or
> policy) to set the time for this specific deployment.
Because I would prefer the raw way, as I would suppose from a
Microsoft client to do. The inital problem was, that w2k clients are not
able to perform dynamic updates, and one point that can cause this
error is that the w2k is not in time sync with its associated domain
controller (as it was in my case). I haved red carefully many tech and
white papers of Microsoft which explains that W2k clients are not
restricted on any way to do them because they CAN. But the problem is
TIME DIFFERENCE. So I have to focus on this time sync issue, else I will
not be able to do the final samba4 migration. As I said, I have lots of
W2k clients in prod. environment and one would expect that they can
sync their time. They can if a Microsoft Windows Server is used. So why
the need to install, deploy or whatever, a 3rd party tool when it should
work on raw way normally?
Cheers,
Lucas.
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba
L.P.H. van Belle
Apr 25, 2013, 9:10:03 AM4/25/13
to
Just hack the registry entry,
on the pc's policies add "DOMAIN\Domain Users" to allow to sync time.
Under, Computer policy, Windows settings, Security, Local .. , user rights, "systemtime change"
With windows it works, because the time sync is done on pc level, not user level as far as i know
( how the homegroups work withing Windows 7 )
and even better, add change the "time.windows.com" in time to ntp.yoursamba4server.local
you can do this with registry level, then your always ok.
Louis
>-----Oorspronkelijk bericht-----
>Van: micro...@mail333.com
>[mailto:samba-...@lists.samba.org] Namens ?icro MEGAS
>Verzonden: donderdag 25 april 2013 10:48
>Aan: sa...@lists.samba.org
>Onderwerp: Re: [Samba] Samba4: W2k clients cannot set / sync
>time with samba4 AD DC
on the pc's policies add "DOMAIN\Domain Users" to allow to sync time.
Under, Computer policy, Windows settings, Security, Local .. , user rights, "systemtime change"
With windows it works, because the time sync is done on pc level, not user level as far as i know
( how the homegroups work withing Windows 7 )
and even better, add change the "time.windows.com" in time to ntp.yoursamba4server.local
you can do this with registry level, then your always ok.
Louis
>-----Oorspronkelijk bericht-----
>Van: micro...@mail333.com
>[mailto:samba-...@lists.samba.org] Namens ?icro MEGAS
>Verzonden: donderdag 25 april 2013 10:48
>Aan: sa...@lists.samba.org
>Onderwerp: Re: [Samba] Samba4: W2k clients cannot set / sync
>time with samba4 AD DC
Gregory Sloop
Apr 25, 2013, 11:20:02 AM4/25/13
to
iM> Well, the NTP server on samba4 server is definitely (!) up and
iM> running. I can triple-check that by "ps", "netstat" and of course by
iM> getting the time of all my other clients (winxp, win7, linux, unix) so
iM> NTP server is definitely running on samba4 host.
Up and running doesn't mean it "works" and that clients can contact
it.
If you have not SPECIFICALLY taken a non W2K client and done an
explicit NTP sync that you can verify worked, and/or done a complete
capture of a successful NTP session, I don't think you're actually
verified that NTP works.
---
IMO, this pursuit seems really crazy - like you want to do nothing to
mitigate things on your end, and want the Samba folks to support a
long-dead client without any mitigation or changes on the long-dead
client end.
ALL W2K support ended in July 2010! [Nearly three YEARS ago!] Non
extended support [i.e. non-security related support] ended in 2005!
Yes, 2005!
So, expecting it all to work without very substantial changes on the
client side seems pretty demanding, at least IMO.
Andrew Bartlett
Apr 25, 2013, 7:30:01 PM4/25/13
to
On Thu, 2013-04-25 at 08:13 -0700, Gregory Sloop wrote:
> iM> Well, the NTP server on samba4 server is definitely (!) up and
> iM> running. I can triple-check that by "ps", "netstat" and of course by
> iM> getting the time of all my other clients (winxp, win7, linux, unix) so
> iM> NTP server is definitely running on samba4 host.
>
> Up and running doesn't mean it "works" and that clients can contact
> it.
>
> If you have not SPECIFICALLY taken a non W2K client and done an
> explicit NTP sync that you can verify worked, and/or done a complete
> capture of a successful NTP session, I don't think you're actually
> verified that NTP works.
>
> ---
> IMO, this pursuit seems really crazy - like you want to do nothing to
> mitigate things on your end, and want the Samba folks to support a
> long-dead client without any mitigation or changes on the long-dead
> client end.
>
> ALL W2K support ended in July 2010! [Nearly three YEARS ago!] Non
> extended support [i.e. non-security related support] ended in 2005!
> Yes, 2005!
>
> So, expecting it all to work without very substantial changes on the
> client side seems pretty demanding, at least IMO.
I'm looked into the PCAP files provided privately, and the source code.
> iM> Well, the NTP server on samba4 server is definitely (!) up and
> iM> running. I can triple-check that by "ps", "netstat" and of course by
> iM> getting the time of all my other clients (winxp, win7, linux, unix) so
> iM> NTP server is definitely running on samba4 host.
>
> Up and running doesn't mean it "works" and that clients can contact
> it.
>
> If you have not SPECIFICALLY taken a non W2K client and done an
> explicit NTP sync that you can verify worked, and/or done a complete
> capture of a successful NTP session, I don't think you're actually
> verified that NTP works.
>
> ---
> IMO, this pursuit seems really crazy - like you want to do nothing to
> mitigate things on your end, and want the Samba folks to support a
> long-dead client without any mitigation or changes on the long-dead
> client end.
>
> ALL W2K support ended in July 2010! [Nearly three YEARS ago!] Non
> extended support [i.e. non-security related support] ended in 2005!
> Yes, 2005!
>
> So, expecting it all to work without very substantial changes on the
> client side seems pretty demanding, at least IMO.
I can confidently explain that the reason the clients do not trigger the
authenticated time response is because they send un-initialised data on
in the 'MAC' field, which the server expects to be zero for these
clients. (Otherwise, it thinks it could be a legitimate, RFC-compliant
authenticated time client)
This is the code in ntpd/ntp_proto.c:
#ifdef HAVE_NTP_SIGND
/*
* If the signature is 20 bytes long, the last 16 of
* which are zero, then this is a Microsoft client
* wanting AD-style authentication of the server's
* reply.
*
* This is described in Microsoft's WSPP docs, in MS-SNTP:
* http://msdn.microsoft.com/en-us/library/cc212930.aspx
*/
} else if (has_mac == MAX_MD5_LEN && (restrict_mask & RES_MSSNTP) &&
(retcode == AM_FXMIT || retcode == AM_NEWPASS) &&
(memcmp(zero_key, (char *)pkt + authlen + 4, MAX_MD5_LEN - 4) ==
0)) {
is_authentic = AUTH_NONE;
#endif /* HAVE_NTP_SIGND */
As such, this is unlikely to ever be fixed in the ntp.org server, but of
course local patches may be possible. It seems much simpler to just set
the time by another route, on such legacy clients.
This is the end of the investigation I can afford into this matter, any
further discussion really needs to be with the ntp.org developers, as
this is now their code. (I wrote it originally).
Andrew Bartlett
--
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
0 new messages