Hallo zusammen,
ich bin eben zufällig über einen Tread gestolpert der mich veranlasst hatte
mal einen PC ( intern) via SP zu synchronisieren.... => Es geht nicht! :shock:
Was habe ich gemacht:
- net time-Aufruf mit IP der SP ( kommt 53 Fehler)
ok, mal eben das Log geprüft => Firewall Drop => "aha alles klar!"
- Gruppe erstellt (ntp) , Dienste der Gruppe zugewiesen ( ntp-tcp u. ntp-udp)
- Regel erstellt: Von Gruppe "ntp" zu Gruppe "FW-Intern"
Resultat: Es geht noch immer nicht! :shock:
(FW-Drop)
Welchen Denkfehler hab ich bzw. hab ich etwas nicht berücksichtigt?
Fakten: - Test-PC kommuniziert mit jedem Zeitserver im I-Net u. auch im LAN
- FW Ntp-Dienst läuft auch einwandfrei
Danke
Ps.: Ich rausch bestimmt gleich gegen die Tischplatte wenn ich die Lösung lese :roll:
Zeit synchronisieren Client <-> SP
Moderator: Securepoint
Zeit synchronisieren Client <-> SP
Wenn die Menschen nur über Dinge reden würden, von denen Sie etwas verstehen -
das Schweigen wäre bedrückend.
das Schweigen wäre bedrückend.
Nabend zusammen,
das Problem habe ich gerade mal versucht nachzustellen.
Das Problem mit Fehler 53 über das CLI interface von Windows habe ich auch, obwohl ich zeitweise dem Kompletten LAN das recht ANY auf das FW_INTERN gegeben habe.
Nutz ich aber das Grafische Interface von Windows und sag dem er soll Jetzt mit der IP der SecurePoint Synchronisieren so erhalte ich die Meldung Synchronisation erfolgreich um 17:25 abgeschlossen.
Denke das das ein Fehler im CLI interface von Windows ist. Werde aber weiterhin schauen was das seien könnte.
Grüße Dallas
das Problem habe ich gerade mal versucht nachzustellen.
Das Problem mit Fehler 53 über das CLI interface von Windows habe ich auch, obwohl ich zeitweise dem Kompletten LAN das recht ANY auf das FW_INTERN gegeben habe.
Nutz ich aber das Grafische Interface von Windows und sag dem er soll Jetzt mit der IP der SecurePoint Synchronisieren so erhalte ich die Meldung Synchronisation erfolgreich um 17:25 abgeschlossen.
Denke das das ein Fehler im CLI interface von Windows ist. Werde aber weiterhin schauen was das seien könnte.
Grüße Dallas
Some people want it to happen, some wish it would happen, others make it happen.
OK Fehler entdeckt,
das Windows CLI funktioniert nur mit einem dns namen.
Also kurzerhand ein A-Record erstellt, und dann
net time /setsntp:securepoint.test.local
Und schon funktioniert das ganze..
Hoffe ich konnte dir Helfen.
Grüße
Dallas
das Windows CLI funktioniert nur mit einem dns namen.
Also kurzerhand ein A-Record erstellt, und dann
net time /setsntp:securepoint.test.local
Und schon funktioniert das ganze..
Hoffe ich konnte dir Helfen.
Grüße
Dallas
Some people want it to happen, some wish it would happen, others make it happen.
Firewall Drop und 53er Fehlermeldung bekomme ich zurück ^^
Ich hatte es auch bereits erfolglos via dns probiert!
Ich hatte es auch bereits erfolglos via dns probiert!
Wenn die Menschen nur über Dinge reden würden, von denen Sie etwas verstehen -
das Schweigen wäre bedrückend.
das Schweigen wäre bedrückend.
Hallo,
mhhh....also DNS hin oder her....die Kiste sollte trotzdem eine Zeit beziehen koennen.
Was mich irritiert ist die "53"....was ich als "Systemfehler 53" interpretiere.
Das kann so nicht sein bzw. stimmen....da keine Anmeldung erfolgt und 53 = "Zugriff verweigert"......was eher zu Windows, als zur Securepoint verweist.
Ich wuerde zuerst folgendes checken:
1. Lokale Daten, die "net time /query" an der Maschine bringt
2. Existieren GPOs, die sich einklinken?! - Evtl. mit "RSOP" mal gegenchecken.
Wenn ueber eine GPO die NTP-Daten verteilt werden, ist die lokale Ausgabe nur Schall und Rauch (It's not a Bug-It's a Feature), da die Daten der GPO und nicht der lokalen Konfig greifen.
Was bringt denn am cmd-prompt: w32tm /resync ?
Denke dann sollten wir langsam der Sache auf die Spur kommen.
Gruss
M. Goeres
mhhh....also DNS hin oder her....die Kiste sollte trotzdem eine Zeit beziehen koennen.
Was mich irritiert ist die "53"....was ich als "Systemfehler 53" interpretiere.
Das kann so nicht sein bzw. stimmen....da keine Anmeldung erfolgt und 53 = "Zugriff verweigert"......was eher zu Windows, als zur Securepoint verweist.
Ich wuerde zuerst folgendes checken:
1. Lokale Daten, die "net time /query" an der Maschine bringt
2. Existieren GPOs, die sich einklinken?! - Evtl. mit "RSOP" mal gegenchecken.
Wenn ueber eine GPO die NTP-Daten verteilt werden, ist die lokale Ausgabe nur Schall und Rauch (It's not a Bug-It's a Feature), da die Daten der GPO und nicht der lokalen Konfig greifen.
Was bringt denn am cmd-prompt: w32tm /resync ?
Denke dann sollten wir langsam der Sache auf die Spur kommen.
Gruss
M. Goeres
Die Welt wird nicht bedroht von den Menschen, die böse sind, sondern von denen, die das Böse zulassen
- Albert Einstein -
- Albert Einstein -
Gelöst!
Völlig richtig ^^ mich hat die 53 auch gestört und hatte jetzt einfach mal komplett den Vorgang analysiert wenn ich die Zeitanfrage an die Securepoint stelle.
1. Ich habe momentan noch keine Ahnung wieso aber, Windows geht raus über die Ports 40xx ( unterschiedlich) wenn man per "net time" die Anfrage startet.
=> Somit ist völlig klar das die Securepoint die ntp-Anfrage blockt und der Drop zu sehen ist .
2. Für mich völlig in Vergessenheit geraten, der W32time-Aufruf...und siehe da ...
=> Anfrage an Sp über die 123er Ports, kein Block und man solls kaum glauben, die Uhrzeit wird synchronisiert! :roll:
Worin nun genauer das Problem liegt ( Protokollprobleme ntp/sntp etc.) werde ich mal unter die Lupe nehmen müssen aber eines ist sicher:
Die SP selbst funktioniert und das Betriebssystem hat den "Hau" weg !
Völlig richtig ^^ mich hat die 53 auch gestört und hatte jetzt einfach mal komplett den Vorgang analysiert wenn ich die Zeitanfrage an die Securepoint stelle.
1. Ich habe momentan noch keine Ahnung wieso aber, Windows geht raus über die Ports 40xx ( unterschiedlich) wenn man per "net time" die Anfrage startet.
=> Somit ist völlig klar das die Securepoint die ntp-Anfrage blockt und der Drop zu sehen ist .
2. Für mich völlig in Vergessenheit geraten, der W32time-Aufruf...und siehe da ...
=> Anfrage an Sp über die 123er Ports, kein Block und man solls kaum glauben, die Uhrzeit wird synchronisiert! :roll:
Worin nun genauer das Problem liegt ( Protokollprobleme ntp/sntp etc.) werde ich mal unter die Lupe nehmen müssen aber eines ist sicher:
Die SP selbst funktioniert und das Betriebssystem hat den "Hau" weg !
Wenn die Menschen nur über Dinge reden würden, von denen Sie etwas verstehen -
das Schweigen wäre bedrückend.
das Schweigen wäre bedrückend.