Probleme über Probleme

Server v7
8

Hallo zusammen,

vielen Dank für die viele angebotene Hilfe!

Es ist ja gott sei dank nicht so, dass ich kein lauffähiges System hinbekommen habe…an der einen Schule ist mir jetzt das Image halt „rausgeflogen“ (vermutlich hat das Image aber auch nie funktioniert…)…aber da schaue ich mir das mal mit der Uhrzeit an.

Kam halt dann gestern etwas geballt…3 Neuinstallationen (andere Schule) und Linbo geht nicht…erst nach dem „Linbo reinstall“…ich hoffe, dass das gesamte System aber in sich dann trotzdem funktioniert.

Ich habe die Systeme per „Install from Scratch“ installiert…und das läuft auch alles ohne Fehler durch (augenscheinlich). Snapshots habe ich erst gestern gemacht…und zwar nach der Installation der opnsense und des Ubuntuservers (bzw. bevor ich das lmn7-Appliance-Skript laufen lasse).

Bisher konnte ich ja auch alle „Probleme“ durch das Forum hier fixen.

@rettich Vielen Dank auch für deine Hilfe! VLans und Layer Switche nutze ich (noch) nicht.

Falls jemand eine Lösung für die englischen Tauschlaufwerke/Ordnerbezeichnungen hat, so wäre ich interessiert :-). Oder sind die wirklich ausschließlich auf Englisch?

Ich melde mich wieder…grad kann ich aber nicht testen…ich bin jetzt an der Schule an der die 6.2er läuft…erst ab Montag kann ich wieder an die 7er gehen. :slight_smile:

Liebe Grüße
Frank

9

Sodele…ich wieder :slight_smile:

Es sieht mittlerweile garnicht mehr so schlecht aus…Die Firewall zieht sich die Zeit von pool.ntp.org, der Server wohl auch von pool.ntp org…der ist am Server in der ntp.conf mit eingetragen (als pool)…von der Firewall kommt KoD packet from 10.0.0.254 has inconsiste…(wenn ich systemctl status ntp.service eingebe)…aber von pool.ntp.org scheint die korrekte Zeit immer zu kommen…d.h. Firewall und Server sind wohl synchron…ein Windows 10 Image an dem ich mich anmelden kann habe ich jetzt wohl auch…sieht auf jeden Fall so aus…allerdings zieht sich Windows nicht die richtige Zeit vom Server…an welcher Stellschraube kann ich da noch drehen? Mit dem Progrämmchen dimension4 bekomme ich das auch noch synchron…aber ist das zu empfehlen? Interessanterweise kann ich mich aber trotz falscher Zeit am Windows anmelden…auch wenn ich neu installiere und es auf einer anderen Hardware ausprobiere… ich freue mich auf Eure Hilfe…und freue mich, dass es bisher jetzt ganz gut aus sieht :slight_smile: Gruß Frank

10

Hallo frankb,
prüfe mal am Windows Client in einer Eingabeaufforderung mit erhöhten Rechten mit
w32tm /query /source
von welcher Quelle der Rechner seine Systemzeit ermittelt. Das sollte der DC sein, also hier der Samba auf dem Linuxmuster - Server.
Der DC verweigert die Authentifizierung von Clients erst, wenn deren Zeit mehr als 5 Minuten abweicht. Das ist die Voreinstellung und kann per GPO geändert werden.

Viele Grüße
Christian

11

Hey Christian,

danke dir! Das überprüfe ich mal! Die Abweichung war etwas über 1,5h…von dem her könnte das schon des Rätsels Lösung sein :slight_smile:

Liebe Grüße
Frank

12

so…wieder da…

hier an meiner zweiten Schule scheint sich die Uhrzeit auch nicht zu synchonisieren…

ein w32tm /query /source

ergibt Local CMOS Clock

…das ist glaube ich nicht das was da stehen sollte, oder? Muss ich das im Image noch irgendwo festlegen wer der Zeitserver ist?

Spricht prinzipiell was gegen ein Zeitservertool wie Dimension 4?

Liebe Grüße
Frank

13

Hi. Kennst du diesen Thread?

14

Oha…danke…werde ich mich durchkämpfen :slight_smile:
Gruß Frank

15

Hallo,

das ist falsch, dann funktioniert die automatische Zeitsynchronisation von Windows nicht.

Den Thread mit der Lösung hat Michael schon gepostet, damit sollte es dann funktionieren.

Wenn ich das von der Testinstallation damals richtig in Erinnerung habe, dann ist bei einer Installation von Linuxmuster nach der Anleitung die Installation fehlerhaft. Der NTP ist nicht als Zeitserver für das AD aktiv und der Eintrag in der smb.conf fehlt. Das sollte aber eigentlich schon gefixt sein, funktioniert aber scheinbar nicht.

Bei den VM-Versionen war das damals schon richtig konfiguriert.

Viel Spaß

Christian

16

Hallo Christian,

Nach welcher Anleitung?

Beste Grüße

Thorsten

17

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

18

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

19

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 w32time

Debugging am Client aktivieren:

w32tm /debug /enable /file:c:\time.log /entries:0-300 /size:10000000
w32tm /config /update

Debugging am Server aktivieren:

service ntp stop
ntpd -d

Nachsehen 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.411

Zeit 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 52

Sobald man den NTP-Client manuell konfiguriert, schickt dieser die Anfrage offenbar „richtig“ zum Server:

w32tm /config /manualpeerlist:server.linuxmuster.lan /syncfromflags:MANUAL
w32tm /config /update

Die 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 48

Kaputtes Windows…

Viele Grüße
Klaus

Edit: Debugging am Client wieder deaktivieren:

w32tm /debug /disable
w32tm /config /update
20

Hallo 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

21

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.

22

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

23

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 …

24

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.

25

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

26

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“
27

Hallo Christian,

ich habe die Ursache im linuxmuster Setup gefunden, welche verhindert, daß NT5DS nicht funktioniert.

  1. 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/
  1. Rechte am ntp_signd Socket:
chgrp ntp /var/lib/samba/ntp_signd/
  1. 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“