Hallo Christian,
Nach welcher Anleitung?
Beste Grüße
Thorsten
Hallo Thorsten,
nach dieser Anleitung:
Der Teil Das Skript lmn7-appliance ist an der Stelle für mich etwas unglücklich. Die Befehle von lmn7-appliance werden erst auf der nächsten Seite erklärt, zudem ist ein großes „Follow me“ zur Erstkonfiguration.
Ich habe nochmals ein entsprechendes Testsystem mit Firewall und Linuxmuster-Server 7 erstellt und einen Win 10 Client ohne Linbo hinzugefügt. Nur als VM installiert. Die Aufnahme in die Domain lief problemlos, mit global-admin kann man sich anmelden. Dabei ist mir folgendes zur Zeitsynchronisation aufgefallen:
Win10 Client an einem Windows Server 2019 als DC
w32tm /resync
Befehl zum erneuten Synchronisieren wird an den lokalen Computer gesendet.
Der Befehl wurde erfolgreich ausgeführt.
Win10 Client an Linuxmuster 7 als DC:
w32tm /resync
Befehl zum erneuten Synchronisieren wird an den lokalen Computer gesendet. Der Computer wurde nicht synchronisiert, da keine Zeitdaten verfügbar waren.
Also keine automatische Synchronisation der Zeit duch den DC.
Umstellung auf den auf den Server selbst:
w32tm /config /manualpeerlist:"10.16.1.1" /syncfromflags:manual /reliable:yes /update
Der Befehl wurde erfolgreich ausgeführt.
w32tm /resync
Befehl zum erneuten Synchronisieren wird an den lokalen Computer gesendet.
Der Befehl wurde erfolgreich ausgeführt.
Also funktioniert es nun.
Wieder Umstellung auf die Samba - DC Funktion:
w32tm /config /syncfromflags:domhier /update
Der Befehl wurde erfolgreich ausgeführt.
w32tm /resync
Befehl zum erneuten Synchronisieren wird an den lokalen Computer gesendet. Der Computer wurde nicht synchronisiert, da keine Zeitdaten verfügbar waren.
Die Zeitsynchronisation duch Samba als DC scheint zumindest in diesem Setting nicht zu funktionieren.
Vielleicht kann das jemand prüfen.
Viele Grüße
Christian
Hallo Christian,
bis der Server synchron ist, dauerts ein Bisschen.
Du kannst das mit ntpq -p checken. Oder mit ntpq -p firewall die Firewall checken.
Sobald vor einem Zeitserver ein * steht sollte der Server synchronisiert sein.
Ach ja, ich habe in der ntp.conf pool firewall durch server firewall ersetzt.
Gruß,
Mathias
Hallo Christian,
ich kann Deine Tests bestätigen. Auch bei mir synchronisiert sich ein Windows 10 2004 Client nicht in den Standardeinstellungen. Das liegt allerdings nicht an linuxmuster, sondern an einem offenbar seit Jahren kaputtem Windows NTP-Client, siehe z.B. hier
Einstellungen am Client zurücksetzen:
net stop w32time
w32tm /unregister
w32tm /register
net start w32timeDebugging am Client aktivieren:
w32tm /debug /enable /file:c:\time.log /entries:0-300 /size:10000000
w32tm /config /updateDebugging am Server aktivieren:
service ntp stop
ntpd -dNachsehen und warten bis Server syncronisiert (*) ist:
root@server:~# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
10.0.0.254 .POOL. 16 p - 64 0 0.000 0.000 0.000
*firewall.linuxm 78.46.60.40 3 u 3 64 377 0.519 4.962 0.411Zeit am Client syncronisieren:
C:\WINDOWS\system32>w32tm /resync
Befehl zum erneuten Synchronisieren wird an den lokalen Computer gesendet.
Der Computer wurde nicht synchronisiert, da keine Zeitdaten verfügbar waren.Auszug aus dem Client Debug Log c:\time.log. Hier sieht man, daß die Anfrage an den Server server.linuxmuster.lan geschickt wird, aber keine Antwort kommt:
...
153255 08:06:13.3959094s - Polling peer server.linuxmuster.lan (ntp.d|0.0.0.0:123->10.0.0.1:123)
153255 08:06:13.3959369s - Sending packet to server.linuxmuster.lan (ntp.d|0.0.0.0:123->10.0.0.1:123) in Win2K detect mode, stage 1.
153255 08:06:13.3965466s - PollIntervalChange(server.linuxmuster.lan (ntp.d|0.0.0.0:123->10.0.0.1:123)): adjust: (--) -> 9
153255 08:06:13.3966126s - No response from peer server.linuxmuster.lan (ntp.d|0.0.0.0:123->10.0.0.1:123).
153255 08:06:13.3966638s - TSI_PhaseOffset returned:373369596288
153255 08:06:13.3966987s - 5 Age:5 Ofs:+00.0000000s COfs:+00.0000000s Dly:+00.0000000s RDly:+00.0000000s Dsp:16.0000126s RDsp:00.0000000s Pnt:00.0000504s Dst:16.0000000s FDsp:00.2500001s Jitter:00.0000000s AgeTime:+13241261173.3966479s
153255 08:06:13.3968056s - 4 Age:4 Ofs:+00.0000000s COfs:+00.0000000s Dly:+00.0000000s RDly:+00.0000000s Dsp:16.0000126s RDsp:00.0000000s Pnt:00.0000504s Dst:16.0000000s FDsp:00.7500004s Jitter:00.0000000s AgeTime:+13241261173.3966479s
153255 08:06:13.3971266s - 3 Age:3 Ofs:+00.0000000s COfs:+00.0000000s Dly:+00.0000000s RDly:+00.0000000s Dsp:16.0000126s RDsp:00.0000000s Pnt:00.0000504s Dst:16.0000000s FDsp:01.7500011s Jitter:00.0000000s AgeTime:+13241261173.3966479s
153255 08:06:13.3973175s - 2 Age:2 Ofs:+00.0000000s COfs:+00.0000000s Dly:+00.0000000s RDly:+00.0000000s Dsp:16.0000126s RDsp:00.0000000s Pnt:00.0000504s Dst:16.0000000s FDsp:03.7500026s Jitter:00.0000000s AgeTime:+13241261173.3966479s
153255 08:06:13.3973902s - 1 Age:1 Ofs:+00.0000000s COfs:+00.0000000s Dly:+00.0000000s RDly:+00.0000000s Dsp:16.0000126s RDsp:00.0000000s Pnt:00.0000504s Dst:16.0000000s FDsp:07.7500057s Jitter:00.0000000s AgeTime:+13241261173.3966479s
153255 08:06:13.3974476s - 0 Age:0 Ofs:+00.0000000s COfs:+00.0000000s Dly:+00.0000000s RDly:+00.0000000s Dsp:16.0000000s RDsp:00.0000000s Pnt:00.0000000s Dst:16.0000000s FDsp:15.7500057s Jitter:00.0000000s AgeTime:+13241261173.3966479s
153255 08:06:13.3975821s - Peer jitter: 00.0000000s Filter Dispersion: 15.7500057s
153255 08:06:13.3976120s - Logging information: NtpClient has not received response from server server.linuxmuster.lan (ntp.d|0.0.0.0:123->10.0.0.1:123).
...Am Server sieht man diese Anfrage auch auf der ‚‚ntpd -d‘‘ Console:
...
fast_xmit: at 2181 10.0.0.1->10.0.0.10 mode 4 keyid 00000000 len 52Sobald man den NTP-Client manuell konfiguriert, schickt dieser die Anfrage offenbar „richtig“ zum Server:
w32tm /config /manualpeerlist:server.linuxmuster.lan /syncfromflags:MANUAL
w32tm /config /updateDie Zeitsynchronisation klappt jetzt:
C:\WINDOWS\system32>w32tm /resync
Befehl zum erneuten Synchronisieren wird an den lokalen Computer gesendet.
Der Befehl wurde erfolgreich ausgeführt.Auszug aus dem Client Debug Log c:\time.log
...
153255 08:15:39.4511609s - PollIntervalChange(server.linuxmuster.lan (ntp.m|0x0|0.0.0.0:123->10.0.0.1:123)): peer receive: 17 -> 10
153255 08:15:39.4511766s - Peer poll: Max:1024.0000000s Cur:1023.9843094s
153255 08:15:39.4511949s - Response from peer server.linuxmuster.lan (ntp.m|0x0|0.0.0.0:123->10.0.0.1:123), ofs: +00.0658940s
...An der „ntpd -d“ Server Console:
fast_xmit: at 2335 10.0.0.1->10.0.0.10 mode 4 keyid 00000000 len 52
fast_xmit: at 2361 10.0.0.1->10.0.0.10 mode 4 len 48
fast_xmit: at 2365 10.0.0.1->10.0.0.10 mode 4 len 48Kaputtes Windows…
Viele Grüße
Klaus
Edit: Debugging am Client wieder deaktivieren:
w32tm /debug /disable
w32tm /config /updateHallo Christian,
entschuldige bitte das ich dich ins Labyrinth geschickt habe. Wie @cweikl in einem anderen Thread sind wir beim Umstruktrieren noch nicht ganz fertig. Was ich jetzt erst einmal gemacht habe, sollte sich demnächst (x Minuten) zeigen. Ist allerdings ersteinmal nur ein workaround.
Wäre schön, wenn du noch einmal drüber schauen könntest, ob es jetzt besser ist.
Beste Grüße
Thorsten
Hallo Klaus,
danke für deinen Test.
Jetzt ist klar, dass die Zeitsynchronisation von Linuxmuster über Samba noch immer grundsätzlich defekt ist.
Der Zeitdienst des Windows-Client funktioniert, schließlich holt er sich bei einem Windows 2019 Server tadellos die richtige Zeit.
Bei deinem Test sieht man auch, dass er beim Linuxmuster Server anfragt, dieser aber keine gültige Antwort liefern kann. In der Ntp.conf des Servers fehlen ja auch ntpsigndsocket und ein paar andere Dinge.
Wenn ein Windows-Client in die Domain aufgenommen wird, dann wird die Uhrzeit standardmäßig über die Domänenhierarchie im gesicherten NT5DS Format übertragen. In Samba gibt es daher die entsprechenden Funktionen, aber bei Linuxmuster sind sie nicht aktiviert bzw. konfiguriert.
Durch den Befehl w32tm /config /manualpeerlist:server.linuxmuster.lan /syncfromflags:MANUAL wird der Windows-Client angewiesen, das NTP Protokoll zu verwenden und die Zeit mit einem NTP-Server abzugleichen.
Mit w32tm /config /syncfromflags:domhier /Update wird wieder auf das NT5DS Protokoll umgestellt und die Zeit soll wieder vom Domäne-Server geholt werden. Das scheitert dann beim Samba von Linuxmuster.
Das hat gpeter im oben zitierten Beitrag Ntp.service status inactive (dead) vom Dezember 2019 hervorragend erläutert und die Lösung gleich mitgeliefert. Respekt.
Der Fix in Linuxmuster hat aber nur die NTP Funktion für die Linux-Clients repariert.
Die Windows-Client waren scheinbar egal, jedenfalls steht schon in damaligen Beitrag, dass für die entsprechende Samba Funktion die notwendigen Einträge weiter fehlen.
Eine fehlerhafte Zeitsynchronisation führt dann halt zum Verlust der Vertrauensstellung des Clients, Problemen bei der Anmeldung, fehlenden Laufwerkszuweisungen, Fehlern im DNS,…
Das sollte bei Linuxmuster ordentlich gefixt werden, vor allem, da gpeter die Lösung schon vor langem geliefert hat
@MachtDochNix
Die Doku und das mit den Domainbezeichnungen schau ich mir an, sobald ich Zeit habe.
Hallo Christian,
da ich ncht so tief in der Materie drinstecke wie du, frage ich mal ganz plump:
Könntest du deine ntp.conf mit den fehlenden Einträgen hier bitte mal posten? Ich erstelle dann ein Issue auf github damit das gefixt wird. Danke für deine Fehlersuche.
Beste Grüße
Thorsten
Ich hatte übrigens auch Probleme mit der Zeit-Synchronisation. Ich habe das so gelöst, dass ich auf dem Host (Proxmox, in /etc/systemd/timesyncd.conf), auf dem Server (in /etc/systemd/timesyncd.conf) und in der OpnSense (in der Oberfläche) manuell die Zeitserver der PTB eingetragen habe. Danach ging alles. Ob das ein sauberer Weg war, weiß ich allerdings nicht …
Hallo Thorsten
Ich bin gerade im Urlaub. Aber die Arbeit hat sich ja @gpeter bereits gemacht, da kann ich es einfach kopieren.
Status von timesyncd anzeigen:
timedatectl status
Deaktivieren des timesyncd.service
timedatectl set-ntp 0
oder
systemctl status systemd-timesyncd.service
systemctl stop systemd-timesyncd.service
systemctl disable systemd-timesyncd.service
systemctl status systemd-timesyncd.service
Verzeichnis des NTP Signierungs-Sockets:
ll /var/lib/samba/ntp_signd/
Damit der NTP Dienst darauf zugreifen kann, müssen hier die Rechte geändert werden:
root@server:~# chgrp ntp /var/lib/samba/ntp_signd/
root@server:~# chmod g+rx /var/lib/samba/ntp_signd/
root@server:~# ll /var/lib/samba/ntp_signd/
total 8,0K
drwxr-x— 2 root ntp 4,0K Dez 2 21:59 .
drwxr-xr-x 8 root root 4,0K Dez 2 21:59 …
srwxrwxrwx 1 root root 0 Dez 2 21:59 socket
Folgende zusätzliche Zeile muss in die /etc/ntp.conf
ntpsigndsocket /var/lib/samba/ntp_signd/
NTP Restart:
systemctl restart ntp.service
systemctl status ntp.service
Seine vollständige Ntp.conf:
driftfile /var/lib/ntp/ntp.drift
logfile /var/log/ntp
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
server 0.de.pool.ntp.org
server 1.de.pool.ntp.org
server 2.de.pool.ntp.org
server 3.de.pool.ntp.org
restrict -4 default kod notrap nomodify nopeer noquery limited
restrict 127.0.0.1
restrict 0.de.pool.ntp.org notrap nomodify noquery
restrict 1.de.pool.ntp.org notrap nomodify noquery
restrict 2.de.pool.ntp.org notrap nomodify noquery
restrict 3.de.pool.ntp.org notrap nomodify noquery
restrict source notrap nomodify noquery
ntpsigndsocket /var/lib/samba/ntp_signd/
Nochmals vielen Dank an @gpeter für seine Mühe.
Sorry für die schlechte Formatierung, aber am Handy geht das schlecht.
Hallo Christian,
danke für Deine Erklärungen zu NT5DS/NTP Unterschied in der Verwendung von w32tm /config. Auch ich hatte bereits mit der offiziellen Dokumentation aus dem Samba Wiki zur Zeitsyncronisierung getestet und die Konfiguration der ntp.conf und Rechte auf /var/lib/samba/ntp_signd/ entsprechend umgesetzt.
Jedenfalls ist es so, daß ich den Windows 10 NTP Client nicht dazu bewegen kann sich mit dem Samba 4 DC mit NT5DS die Zeit zu holen.
In Post #13 von @gpeter sieht man, daß auch hier die Zeitsynchronisierung nicht über NT5DS, sondern NTP läuft:
PS C:\Windows\system32> w32tm /query /status
Sprungindikator: 0(keine Warnung)
Stratum: 4 (Sekundärreferenz - synchr. über (S)NTP)
Präzision: -23 (119.209ns pro Tick)
Stammverzögerung: 0.0256009s
Stammabweichung: 7.7816893s
Referenz-ID: 0x0A100001 (Quell-IP: 10.16.0.1)
Letzte erfolgr. Synchronisierungszeit: 03.12.2019 16:24:23
Quelle: server.bs-wiz.llan,0x9
Abrufintervall: 6 (64s)
Für eine Zeitsynchronisierung via NTP sind auf dem lmn7 keine Änderungen zur bisherhigen Konfiguration nötig. Lediglich der Windows 10 Client muß entsprechend geändert werden, so daß dieser NTP statt NT5DS benutzt.
Sollte es eine Möglichkeit geben, NT5DS zu nutzen, wäre das natürlich sauberer, da am Client nichts geändert werden muß.
Eine Möglichkeit das mit chrony statt ntp zu testen hatte ich nicht, da bei dem Versuch chrony zu installieren ntp entfernt wird und damit linuxmuster7-base etc. Hier gibt es eine Abhängigkeit zu ntp.
Viele Grüße
Klaus
Hallo Klaus,
so wie ich das verstanden habe ist nt5ds nur signiertes ntp, so wie https nur verschlüsseltes http ist.
Der Client meldet sich über nt5ds beim Server, der bestätigt mit einer signierten Antwort, dass er ein autorisierter Zeitserver ist und die Zeit selbst wird dann per ntp abgeglichen.
Das macht Sinn, da sonst dem Client ein fremder NTP-Server mit gleichem Namen aber falscher Zeit untergeschoben werden könnte und dann abgelaufene Kerberos Tickets wieder gültig sind.
In der Ntp.conf müssen eigentlich nur mssntp und ntpsigndsocket eingefügt werden, dann kann Samba die digitalen Signaturen übermitteln und den NTP das Servers authentifizieren. Natürlich müssen auch die Ordner mit den richtigen Berechtigungen vorhanden sein.
Ich kann das im Moment nicht testen, aber das wäre der sauberste Weg.
Alternativ kann man am Server eine GPO erstellen, die Windows anweist, nur ntp oder nt5ds und ntp (allsync) zu akzeptieren.
Als weitere Alternative kann das per reg File oder Batch geändert werden. Details sind unter http://www.windowspage.com/tipps/022082.html zu finden. Alt, aber noch immer gültig.
1 „Gefällt mir“
Hallo Christian,
ich habe die Ursache im linuxmuster Setup gefunden, welche verhindert, daß NT5DS nicht funktioniert.
- Wie Du schon geschrieben hattest, die ntp.conf. Hier meine Variante mit Anpassungen und der OPNsense als bevorzugte Zeitquelle:
root@server:~# cat /etc/ntp.conf | grep "^[^#]"
driftfile /var/lib/ntp/ntp.drift
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
server 10.0.0.254 iburst prefer
restrict -4 default kod notrap nomodify nopeer noquery limited mssntp
restrict -6 default kod notrap nomodify nopeer noquery limited mssntp
restrict 127.0.0.1
restrict ::1
restrict source notrap nomodify noquery
ntpsigndsocket /var/lib/samba/ntp_signd/- Rechte am ntp_signd Socket:
chgrp ntp /var/lib/samba/ntp_signd/- Entscheidend ist aber, daß in der linuxmuster Standardinstallation apparmor aktiv ist und die dortige Einstellung für ntp nicht stimmt und somit der ntp nicht auf den Samba Socket zugreifen kann, auch wenn die Rechte am Verzeichnis stimmen:
/etc/apparmor.d/usr.sbin.ntpd
...
# samba4 ntp signing socket
# falsch:
#/{,var/}run/samba/ntp_signd/socket rw,
# richtig:
/{,var/}lib/samba/ntp_signd/socket rw,
...Alternativ ist natürlich möglich ntp signd socket directory der smb.conf zu ändern, so daß man die apparmor Konfiguration nicht anpassen muß. Das müssen die Entwicker entscheiden, was einfacher/sauberer ist.
Am Client muß jetzt nichts mehr geändert werden.
Thorsten, @MachtDochNix wenn das noch jemand verifizieren kann, dann könntest Du das eventuell als Issue einbringen? Danke!
Viele Grüße
Klaus
1 „Gefällt mir“
Hallo Klaus,
das mit Apparmor hatte ich gar nicht auf dem Schirm.
Ich konnte deine Lösung ausprobieren. Sie funktioniert wie erwartet.
Jetzt müsste sie nur jemand in git einstellen oder einer der Entwickler sich melden.
Viele Grüße
Christian
Danke
Das vermeidet bei dem ein oder anderen sicher ein paar Probleme.
Hallo zusammen, hallo Thomas @thomas,
das klappt so noch nicht. Bitte nochmal genau den ergänzten Bugreport lesen.
Bitte außerdem nicht per Update eine ntp.conf einfach überschreiben, vor allem nicht dann, wenn das Setup so nicht funktioniert.
Bestehende Systemdateien sollten IMHO nur nach Nachfrage überschrieben werden, wenn die Originaldatei manuell verändert wurde. Das ist Debian/Ubuntu Standard und so sollten auch linuxmuster.net .deb Pakete gebaut werden. Ich kann nicht nach jedem Update kontrollieren welche Systemdateien wieder überschrieben wurden.
Danke und viele Grüße
Klaus
2 „Gefällt mir“
@garblixa
Wir sind halt im Moment noch in einer Phase, in der wir die Grundkonfiguration immer mal wieder nachjustieren müssen, damit möglichst viele Anwendungen im Feld abgedeckt werden. Das hört irgendwann auf.
VG Thomas
1 „Gefällt mir“
Hallo Thomas,
ja, das passt schon. Ich bemühe mich einfach mit meinen Vorschlägen das Produkt zu verbessern.
Weiter so 
Viele Grüße
Klaus
1 „Gefällt mir“
Und dafür ein dickes Danke von mir.
Beste Grüße
Thorsten
Das kann ich nur zurückgeben, danke 
Auch an die Entwickler für das tolle Produkt!
Viele Grüße
Klaus