Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#1033088: ntpsec: mssntp in ntp.conf breaks time service to all clients
134 views
Skip to first unread message
Steven Monai
Mar 16, 2023, 10:50:05 PM3/16/23
to
Package: ntpsec
Version: 1.2.2+dfsg1-1
Severity: normal
X-Debbugs-Cc: stev...@gmail.com
Dear Maintainer,
On my LAN, I run Samba on Debian servers to implement Domain
Controllers (DCs) for an Active Directory (AD) domain. Per the Samba
documentation, I have set up authenticated time service (known as
MS-SNTP) on the DCs for Windows clients. Non-Windows clients also use
the DCs for non-auth time service, via unicast [S]NTP. Up to and
including bullseye, I have always used the 'ntp' package for this
purpose on the DCs, and it was functional.
Recently, however, upon upgrading from bullseye to bookworm, I found
that the DCs would no longer respond correctly to client requests for
time service. In other words, neither authenticated clients (Windows,
MS-SNTP) nor non-auth clients ([S]NTP) would receive any valid time
responses from the DCs running on bookworm.
Doing some experimentation, I discovered that when the 'mssntp'
keyword was removed from the 'restrict' line in 'ntp.conf', non-auth
time service was restored to clients (while MS-SNTP was disabled,
ofc). I can only assume this is a bug in the 'ntpsec' implementation
of MS-SNTP.
Without MS-SNTP service working on the DCs, Windows domain clients
(with the default time client settings) never receive time service
from the DCs as they should. Although it is easy enough to modify the
Windows time client settings to use non-auth NTP services, it would
be nice for MS-SNTP to work as advertised in 'ntpsec'.
Please let me know if there's any more information I can provide to
aid in troubleshooting/debugging this issue.
Thank you for your time.
Cheers,
-S.M.
-- System Information:
Debian Release: bookworm/sid
APT prefers testing-security
APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-6-amd64 (SMP w/1 CPU thread; PREEMPT)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8),
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages ntpsec depends on:
ii adduser 3.131
ii init-system-helpers 1.65.2
ii libbsd0 0.11.7-2
ii libc6 2.36-8
ii libcap2 1:2.66-3
ii libssl3 3.0.8-1
ii netbase 6.4
ii python3 3.11.2-1
ii python3-ntp 1.2.2+dfsg1-1
ii sysvinit-utils [lsb-base] 3.06-2
ii tzdata 2022g-7
Versions of packages ntpsec recommends:
ii cron [cron-daemon] 3.0pl1-162
ii systemd 252.6-1
Versions of packages ntpsec suggests:
ii apparmor 3.0.8-3
pn certbot <none>
pn ntpsec-doc <none>
pn ntpsec-ntpviz <none>
-- Configuration Files:
/etc/ntpsec/ntp.conf changed:
driftfile /var/lib/ntpsec/ntp.drift
leapfile /usr/share/zoneinfo/leap-seconds.list
statsdir /var/log/ntpsec/
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable
tos maxclock 11
tos minclock 4 minsane 3
tos orphan 7
tinker panic 0
ntpsigndsocket /var/lib/samba/ntp_signd/
server 10.150.10.10 iburst burst prefer
server 10.150.10.11 iburst burst prefer
pool 0.pool.ntp.org iburst
pool 1.pool.ntp.org iburst
pool 2.pool.ntp.org iburst
pool 3.pool.ntp.org iburst
restrict default kod nomodify limited mssntp
restrict 127.0.0.1
restrict ::1
-- no debconf information
Version: 1.2.2+dfsg1-1
Severity: normal
X-Debbugs-Cc: stev...@gmail.com
Dear Maintainer,
On my LAN, I run Samba on Debian servers to implement Domain
Controllers (DCs) for an Active Directory (AD) domain. Per the Samba
documentation, I have set up authenticated time service (known as
MS-SNTP) on the DCs for Windows clients. Non-Windows clients also use
the DCs for non-auth time service, via unicast [S]NTP. Up to and
including bullseye, I have always used the 'ntp' package for this
purpose on the DCs, and it was functional.
Recently, however, upon upgrading from bullseye to bookworm, I found
that the DCs would no longer respond correctly to client requests for
time service. In other words, neither authenticated clients (Windows,
MS-SNTP) nor non-auth clients ([S]NTP) would receive any valid time
responses from the DCs running on bookworm.
Doing some experimentation, I discovered that when the 'mssntp'
keyword was removed from the 'restrict' line in 'ntp.conf', non-auth
time service was restored to clients (while MS-SNTP was disabled,
ofc). I can only assume this is a bug in the 'ntpsec' implementation
of MS-SNTP.
Without MS-SNTP service working on the DCs, Windows domain clients
(with the default time client settings) never receive time service
from the DCs as they should. Although it is easy enough to modify the
Windows time client settings to use non-auth NTP services, it would
be nice for MS-SNTP to work as advertised in 'ntpsec'.
Please let me know if there's any more information I can provide to
aid in troubleshooting/debugging this issue.
Thank you for your time.
Cheers,
-S.M.
-- System Information:
Debian Release: bookworm/sid
APT prefers testing-security
APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-6-amd64 (SMP w/1 CPU thread; PREEMPT)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8),
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages ntpsec depends on:
ii adduser 3.131
ii init-system-helpers 1.65.2
ii libbsd0 0.11.7-2
ii libc6 2.36-8
ii libcap2 1:2.66-3
ii libssl3 3.0.8-1
ii netbase 6.4
ii python3 3.11.2-1
ii python3-ntp 1.2.2+dfsg1-1
ii sysvinit-utils [lsb-base] 3.06-2
ii tzdata 2022g-7
Versions of packages ntpsec recommends:
ii cron [cron-daemon] 3.0pl1-162
ii systemd 252.6-1
Versions of packages ntpsec suggests:
ii apparmor 3.0.8-3
pn certbot <none>
pn ntpsec-doc <none>
pn ntpsec-ntpviz <none>
-- Configuration Files:
/etc/ntpsec/ntp.conf changed:
driftfile /var/lib/ntpsec/ntp.drift
leapfile /usr/share/zoneinfo/leap-seconds.list
statsdir /var/log/ntpsec/
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable
tos maxclock 11
tos minclock 4 minsane 3
tos orphan 7
tinker panic 0
ntpsigndsocket /var/lib/samba/ntp_signd/
server 10.150.10.10 iburst burst prefer
server 10.150.10.11 iburst burst prefer
pool 0.pool.ntp.org iburst
pool 1.pool.ntp.org iburst
pool 2.pool.ntp.org iburst
pool 3.pool.ntp.org iburst
restrict default kod nomodify limited mssntp
restrict 127.0.0.1
restrict ::1
-- no debconf information
Richard Laager
Apr 29, 2023, 1:30:05 AM4/29/23
to
forwarded 1033088 https://gitlab.com/NTPsec/ntpsec/-/issues/785
thanks
Sorry for the delay in responding. I had hoped to try to reproduce this
myself. But I need to be honest with myself that it's simply not going
to happen.
Can you confirm whether you get either of these messages to stderr on
startup:
A) MS-SNTP signd operations currently block ntpd degrading service to
all clients.
B) mssntp restrict bit ignored, this ntpd was configured without
--enable-mssntp.
I would expect "A". If you are getting "B", that is bad (and makes no
sense, as the Debian ntpsec package is built with --enable-mssntp).
Is there any chance you could test with ntpsec 1.1.3? You'd have to
build from source (and note that upstream stores the config file in
/etc/ntp, not /etc/ntpsec). It is available here:
https://ftp.ntpsec.org/pub/releases/ntpsec-1.1.3.tar.gz
If ntpsec 1.1.3 works and 1.1.4 does not, then I'm wondering if commit
ee7677d0cff27c9e208cc3716db41f51bf29c1fb would be to blame. That said, I
don't see anything wrong with that change. It's just that there aren't
many other changes to mssntp code in ntpsec.
Other than that, I don't have any ideas. I've forwarded the bug
upstream. You can see the URL in the control commands at the top of this
message.
--
Richard
thanks
Sorry for the delay in responding. I had hoped to try to reproduce this
myself. But I need to be honest with myself that it's simply not going
to happen.
Can you confirm whether you get either of these messages to stderr on
startup:
A) MS-SNTP signd operations currently block ntpd degrading service to
all clients.
B) mssntp restrict bit ignored, this ntpd was configured without
--enable-mssntp.
I would expect "A". If you are getting "B", that is bad (and makes no
sense, as the Debian ntpsec package is built with --enable-mssntp).
Is there any chance you could test with ntpsec 1.1.3? You'd have to
build from source (and note that upstream stores the config file in
/etc/ntp, not /etc/ntpsec). It is available here:
https://ftp.ntpsec.org/pub/releases/ntpsec-1.1.3.tar.gz
If ntpsec 1.1.3 works and 1.1.4 does not, then I'm wondering if commit
ee7677d0cff27c9e208cc3716db41f51bf29c1fb would be to blame. That said, I
don't see anything wrong with that change. It's just that there aren't
many other changes to mssntp code in ntpsec.
Other than that, I don't have any ideas. I've forwarded the bug
upstream. You can see the URL in the control commands at the top of this
message.
--
Richard
Steven Monai
Apr 29, 2023, 11:00:04 PM4/29/23
to
On 2023-04-28 10:20 p.m., Richard Laager wrote:
> Can you confirm whether you get either of these messages to stderr on
> startup:
>
> A) MS-SNTP signd operations currently block ntpd degrading service to
> all clients.
Definitely this one, A.
> Can you confirm whether you get either of these messages to stderr on
> startup:
>
> A) MS-SNTP signd operations currently block ntpd degrading service to
> all clients.
> Is there any chance you could test with ntpsec 1.1.3? You'd have to
> build from source (and note that upstream stores the config file in
> /etc/ntp, not /etc/ntpsec). It is available here:
> https://ftp.ntpsec.org/pub/releases/ntpsec-1.1.3.tar.gz
system bundled with the source ("waf") seems to assume python 2.x, but,
unfortunately, Bookworm provides only python3. Any hints?
> I've forwarded the bug
> upstream. You can see the URL in the control commands at the top of this
> message.
Cheers,
-S.M.
Richard Laager
Apr 30, 2023, 12:10:05 AM4/30/23
to
On 4/29/23 21:54, Steven Monai wrote:
> I downloaded and unpacked this source on a Bookworm host. The build
> system bundled with the source ("waf") seems to assume python 2.x, but,
> unfortunately, Bookworm provides only python3. Any hints?
Quick approach is try this:
> I downloaded and unpacked this source on a Bookworm host. The build
> system bundled with the source ("waf") seems to assume python 2.x, but,
> unfortunately, Bookworm provides only python3. Any hints?
python3 waf configure ...
python3 waf build
A longer, but possibly better, approach might be something like:
git clone g...@salsa.debian.org:debian/ntpsec.git
cd ntpsec
git checkout debian/1.1.3+dfsg1-1
debuild -uc -us
An intermediate approach might be to test with the binary package from
buster. You can get download links here, by architecture, plus there are
links to related packages, some of which (like python3-ntp) you might need:
https://packages.debian.org/buster/ntpsec
Hopefully this will turn out to be something broken during code
cleanups/refactorings in NTPsec that you can bisect (at least somewhat).
--
Richard
Steven Monai
May 2, 2023, 11:30:04 PM5/2/23
to
On 2023-04-29 9:04 p.m., Richard Laager wrote:
> Quick approach is try this:
> python3 waf configure ...
> python3 waf build
I tried this, but the bundled 'waf' tool did not work in Python3. I
> Quick approach is try this:
> python3 waf configure ...
> python3 waf build
could not get past the 'configure' step. Here's the output I got on a
Bookworm host with all the ntpsec build dependencies installed:
te...@book.test:~$ python3 -V
Python 3.11.2
te...@book.test:~$ wget -q
https://ftp.ntpsec.org/pub/releases/ntpsec-1.1.3.tar.gz
te...@book.test:~$ tar -xf ntpsec-1.1.3.tar.gz
te...@book.test:~$ cd ntpsec-1.1.3/
te...@book.test:~/ntpsec-1.1.3$ python3 waf configure
Waf: The wscript in '/home/tech/ntpsec-1.1.3' is unreadable
Traceback (most recent call last):
File
"/home/tech/ntpsec-1.1.3/.waf3-1.9.15-7481b2b5d90177d4bb747dbff06bef90/waflib/Scripting.py",
line 106, in waf_entry_point
set_main_module(os.path.normpath(os.path.join(Context.run_dir,Context.WSCRIPT_FILE)))
File
"/home/tech/ntpsec-1.1.3/.waf3-1.9.15-7481b2b5d90177d4bb747dbff06bef90/waflib/Scripting.py",
line 137, in set_main_module
Context.g_module=Context.load_module(file_path)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File
"/home/tech/ntpsec-1.1.3/.waf3-1.9.15-7481b2b5d90177d4bb747dbff06bef90/waflib/Context.py",
line 352, in load_module
code=Utils.readf(path,m='rU',encoding=encoding)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File
"/home/tech/ntpsec-1.1.3/.waf3-1.9.15-7481b2b5d90177d4bb747dbff06bef90/waflib/Utils.py",
line 127, in readf
f=open(fname,m)
^^^^^^^^^^^^^
ValueError: invalid mode: 'rUb'
> A longer, but possibly better, approach might be something like:
> git clone g...@salsa.debian.org:debian/ntpsec.git
> cd ntpsec
> git checkout debian/1.1.3+dfsg1-1
> debuild -uc -us
to work, which broke the build.
I don't believe I will be able to "forward-port" old ntpsec releases to
Bookworm without a lot more time and effort. Perhaps someone more
familiar with the build system would have better luck?
> An intermediate approach might be to test with the binary package from
> buster. You can get download links here, by architecture, plus there are
> links to related packages, some of which (like python3-ntp) you might need:
> https://packages.debian.org/buster/ntpsec
controller running on Buster, so I can't test whether Windows clients
will get properly signed responses from the server. But I can still test
whether the 'mssntp' configuration in ntp.conf causes ntpsec to stop
serving non-auth clients. I will try to get to this in the next few days.
-S.M.
Jakob Haufe
Jan 9, 2024, 6:50:05 PM1/9/24
to
Hi all,
just to add some info: I imported 1.2.3 and built a package. A quick
check from an AD Windows host and using ntpdig both returned success.
Necessary changes:
- drop all accepted and forwarded patches
- quilt refresh debian/patches/use-etc-ntpsec.patch
- drop "--enable-debug-gdb" in debian/rules
Will put it on salsa for reference tomorrow.
Cheers,
sur5r
--
ceterum censeo microsoftem esse delendam.
just to add some info: I imported 1.2.3 and built a package. A quick
check from an AD Windows host and using ntpdig both returned success.
Necessary changes:
- drop all accepted and forwarded patches
- quilt refresh debian/patches/use-etc-ntpsec.patch
- drop "--enable-debug-gdb" in debian/rules
Will put it on salsa for reference tomorrow.
Cheers,
sur5r
--
ceterum censeo microsoftem esse delendam.
0 new messages