basstscho
-
Gesamte Inhalte
339 -
Registriert seit
-
Letzter Besuch
Beiträge erstellt von basstscho
-
-
Hallo zusammen,
in den Sicherheits-Meldungen eines Fileservers habe ich schon länger mehrmals pro Minute einen gescheiterten Überwachungseintrag - Ereignis ID 4625.
Auf dem DC gibt es keine Fehlermeldung und das last login in den Attributen ist auch erst heute gewesen. Technisch scheint alles reibungsfrei zu funktionieren.
Hat jemand einen Tipp wo ich überhaupt nach der Ursache des Phänomens schauen kann? Woher kommen überhaupt diese häufigen Authentifizierungsversuche des Computerkontos gegenüber der Domäne? Auf dem Server laufen nur Windows-Freigaben und sonst kein zusätzlicher Dienst.
Fehler beim Anmelden eines Kontos. Antragsteller: Sicherheits-ID: NULL SID Kontoname: - Kontodomäne: - Anmelde-ID: 0x0 Anmeldetyp: 3 Konto, für das die Anmeldung fehlgeschlagen ist: Sicherheits-ID: NULL SID Kontoname: FILESRV-IS$ Kontodomäne: COMPA Fehlerinformationen: Fehlerursache: Bei der Anmeldung ist ein Fehler aufgetreten. Status: 0xC000006D Unterstatus:: 0x0 Prozessinformationen: Aufrufprozess-ID: 0x0 Aufrufprozessname: - Netzwerkinformationen: Arbeitsstationsname: FILESRV-IS Quellnetzwerkadresse: 192.168.11.175 Quellport: 59553 Detaillierte Authentifizierungsinformationen: Anmeldeprozess: Authentifizierungspaket: NTLM Übertragene Dienste: - Paketname (nur NTLM): - Schlüssellänge: 0 Dieses Ereignis wird beim Erstellen einer Anmeldesitzung generiert. Es wird auf dem Computer generiert, auf den zugegriffen wurde. Die Antragstellerfelder geben das Konto auf dem lokalen System an, von dem die Anmeldung angefordert wurde. Dies ist meistens ein Dienst wie der Serverdienst oder ein lokaler Prozess wie "Winlogon.exe" oder "Services.exe". Das Anmeldetypfeld gibt den jeweiligen Anmeldetyp an. Die häufigsten Typen sind 2 (interaktiv) und 3 (Netzwerk). Die Felder für die Prozessinformationen geben den Prozess und das Konto an, für die die Anmeldung angefordert wurde. Die Netzwerkfelder geben die Quelle einer Remoteanmeldeanforderung an. Der Arbeitsstationsname ist nicht immer verfügbar und kann in manchen Fällen leer bleiben. Die Felder für die Authentifizierungsinformationen enthalten detaillierte Informationen zu dieser speziellen Anmeldeanforderung. - Die übertragenen Dienste geben an, welche Zwischendienste an der Anmeldeanforderung beteiligt waren. - Der Paketname gibt das in den NTLM-Protokollen verwendete Unterprotokoll an. - Die Schlüssellänge gibt die Länge des generierten Sitzungsschlüssels an. Wenn kein Sitzungsschlüssel angefordert wurde, ist dieser Wert 0. -
Hallo zusammen,
ich würde gerne in unserer Domänen-Umgebung die Windows-Logfiles zentral auswerten. Dazu habe ich auf einem Server 2022 (srv-win02) den WEC konfiguriert und möchte gerne von einem Client (ts12) die Logs per push einsammeln: Client->Server (HTTP).
Ich hab mich dabei an mehrere Tutorials gehalten, die im Endeffekt alle das gleiche Vorgehen beschreiben - sah für mich nach einer 10 Minuten-Aktion aus. Das zieht sich nun schon deutlich länger und ich scheitere leider mit folgender Fehlermeldung auf dem Client:
Ereignis-ID 105:
Bei der Weiterleitung ist beim Kommunizieren mit dem Abonnement-Manager unter der Adresse "http://srv-win02.x.local:5985/wsman/SubscriptionManager/WEC" ein Problem aufgetreten. Fehlercode: 2150859027, Fehlermeldung: <f:WSManFault xmlns:f="http://schemas.microsoft.com/wbem/wsman/1/wsmanfault" Code="2150859027" Machine="ts12.x.local"><f:Message>Der WinRM-Client hat eine Anforderung an den Remote-WS-Verwaltungsdienst gesendet und eine Antwort erhalten, in der gemeldet wurde, dass die angeforderte HTTP-URL nicht verfügbar ist. Diese Meldung wird normalerweise von einem HTTP-Server zurückgegeben, der das WS-Verwaltungsprotokoll nicht unterstützt. </f:Message></f:WSManFault>.
Was hab ich getestet:
- Firewall auf dem Server ist deaktiviert
- Dienste laufen
- Konfiguration mehrfach geprüft und neu gesetzt
- Server und Client mehrfach neugestartet
Ich finde keinen offensichtlichen Fehler in der Konfiguration. Das einzig auffällige aus meiner Sicht: Wenn ich mich vom Client aus über "winrm id" auf den server verbinde, wird der Zugriff verweigert. Wenn ich mich als lokaler administrator (vom Server) gegen den server authentifiziere, hab ich den Zugriff, Diesbzgl. hab ich aber keine Erwähnung in den Tutorials gefunden und leider auch keine Referenz zum Vergleich.
Die Gruppe "x-EventCollector" enthält das Computer-Konto des Clients.
Übersehe ich irgendwo etwas grundlegendes? Oder wird der Zugriff ggf. auf Grund einer anderen Sicherheitseinstellung limitiert, die irgendwo gesetzt sein könnte? Habt ihr einen Tipp, wie ich Ursache noch eingrenzen könnte?
Danke und Grüße,
Johannes
-
vor 8 Stunden schrieb testperson:
Hier ist ein ganz gutes Projekt bzw. eine Übersicht dazu: LOLBAS
Ein Ansatz für die Firewall: GitHub - eneerge/Powershell-Firewall-Block-LOLbins (Das solltest du dir aber recht genau ansehen, überarbeiten und testen. Das Profil "Any" würde ich spontan für too much halten in Domänen Umgebungen.)
Danke für den Hinweis. Ich hab das mal auf meine Testgruppe losgelassen. Ungünstig ist dabei natürlich, dass das quasi je nach System unterschiedliche Regeln gibt. Die "Klassiker" direkt aus dem Systemverzeichnis sind aber auf jeden Fall mal mit dabei.
vor 8 Stunden schrieb cj_berlin:Es gibt viele gute Ansätze hier, beim Threat Modelling für die Windows Firewall sollte eins jedoch nicht außer Acht gelassen werden: Die Konfiguration, ob sie lokal vorgenommen wurde oder aus GPOs kommt, steht im Klartext in der Registry. Somit kann die Angreiferin, wenn sie dort Lesezugriff hat, bereits genau wissen, was konfiguriert wurde. Das verrät ihr unter Umständen Dinge, die sie sonst nur mit Mühe und viel Noise herausgefunden hätte, wenn überhaupt.
Will damit sagen: weniger kann manchmal mehr sein.Das ist richtig. Ich war auch schon kurz davor ein paar Admin-IPs mehr Zugriff zu geben. Ist aber sowohl sicherheitstechnisch, als auch zwecks "Einsicht" nicht ideal.
-
Vielen Dank für eure erste Einschätzung!
vor 2 Stunden schrieb MurdocX:Was man dort konfigurieren würde, wären ausgehende Denys von OS seitigen LOLBINs. Dort wären dann genau die Tools drin, die durch den AppLocker normalerweise nicht blockiert werden, weil sie sich im Systemverzeichnis befinden und dem OS angehören.
Hast du mir ein paar Beispiele? Würde ich gerne ergänzen!
vor einer Stunde schrieb daabm:Nachtrag: "Bei uns im Netzwerk" ist etwas kurz gegriffen - was ist mit Laptops unterwegs oder zuhause?
Ja, das stimmt natürlich! Da könnte man sicher noch nachschärfen. Habt ihr das dann auf Port-Basis gemacht - also z.B. 80 & 443 offen oder die einzelnen Anwendungen freigeschaltet?
-
Hallo zusammen,
ich hatte vor einen Austausch mit einem befreundeten Kollegen, der die Windows-Firewall deutlich intensiver konfiguriert als ich. Gerne würde ich wissen wie ihr es bei euch im Unternehmen handhabt.
Bei mir (über GPO, lokale Regeln nicht zusammenführen):
- Allen ausgehenden Verkehr zulassen (und auch keine Regeln definiert)
- Bei den eingehenden Regeln ist:
- innerhalb der Domäne der ping erlaubt
- auf Clients dann i.d.R. auch nicht mehr
- auf Server natürlich die entsprechenden Dienste
Der Bekannte blockiert auch den ausgehenden Traffic und definiert dann die benötigten Ports/Anwendungen. Das ist aus meiner Sicht ein sehr aufwändig.
Hintergrund zu unserem System: Internetzugang geht bei uns im Netzwerk nur über einen gefilterten Proxy raus und auf allen Clients ist Applocker (whitelist) konfiguriert.
Mach ich es mir zu einfach? Konfiguriert ihr ebenfalls Ausgangsseitig die komplette Kommunikation?
Danke und Grüße,
Johannes
-
Besten Dank für die schnelle Antwort - hat wunderbar funktioniert!
-
Hallo zusammen,
ich muss auf einigen Rechnern (Win10, Win11, W2k22) .NET 8 ausrollen. Das musste ich in der Tat schon länger nicht mehr. Eine msi zur Verteilung über GPO kann ich weder als Download noch beim Entpacken der .exe finden.
Wie verteilt ihr .NET 8 mit Windows-Mitteln? Über WSUS hab ich im Internet gelesen, finde spontan aber nur Sicherheits-Updates, nachdem ich .NET 8 als Produkt im WSUS hinzugefügt und synchronisiert habe.
Danke und Grüße,
Johannes
-
Ich hab zwei VMs mit 22H2: 1x quasi alles deaktiviert (Smart Control, Defender, .... alles was ich irgendwie in den Zusammenhang mit SRP bringen konnte), die zweite frisch installiert und die neusten Updates von Microsoft geladen.
Bei beiden ging SRP nicht, aber dafür der AppLocker.
Was mir noch einfällt: Ich konnte den AppIdSvc nicht deaktiveren. Läuft auf deinen Rechnern der Dienst?
-
Neuinstalliert hab ich jetzt nicht, aber auf zwei VMs ist es eindeutig: Wenn ich eine Pfad-Änderung in der AppLocker-GPO durchführe (z.B. Ausführen von Anwendungen vom Desktop aus), dann werden die angewendet bzw. auch nicht, wenn sie gelöscht werden. Die müssten bei Win11 Pro ja eigentlich ignoriert werden.
-
Da ich mich schon damit abgefunden habe zukünftig auf die Enterprise-Version wechseln zu müssen, hab ich mich in meinem Testsystem mal mit dem Thema AppLocker beschäftigt. Ich hab aus Faulheit die AppLocker-Einstellungen einfach mal in der gleiche GPO gepackt, wie die vorab konfigurierten SRP. Dann hab ich mich auf dem Win 11 Pro 22H2 eingeloggt und konnte auf einmal meine Test-exe auf dem Desktop nicht mehr ausführen - interessant! Den "erzwingen"-Haken entfernt -> ich konnte die Datei wieder ausführen. Auf meinem Testsystem ziehen die vollen AppLocker-Regeln auf der Pro-Version. Kann das eventuell auch erklären, dass bei manchen Installationen vermeintlich die "SRP" funktioniert hat, es aber in Wahrheit die parallel konfigurierten AppLocker-Einstellungen waren?
SRP deaktivieren und dafür den AppLocker auf den Pro-Versionen zu aktivieren wäre für mich fair und verständlich.
-
Über den Link bin ich auch schon gestolpert, aber ich möchte ja eigentlich in Summe nicht auf den AppLocker setzen, sondern einfach die SRP nutzen.
Sollte also jemand erfolgreich Win11 Pro 22H2 mit SRP im Einsatz haben bitte melden. Bei mir hat es bei zwei Installationen nicht geklappt!
-
Hallo zusammen,
hat in der Zwischenzeit jemand ne Info bzgl. der SRP in Win11 Pro 22H2 bekommen können?
Danke und Grüße,
Johannes
-
Zusammengefasst:
- Win11 Pro 21H2: funktioniert wie erwartet
- Win11 Pro 22H2: keine Funktion des SRP
Ich hab nun aber mal das Detail-Logging auf beiden Rechnern aktiviert. Interessant ist Folgendes:
- Auf dem 21H2 erscheint wie erwartet im Log:
....exe as Unrestricted using path rule, Guid = ... ....exe as Disallowed using default rule, Guid = ...
- Auf dem 22H2 erscheint immer die für mich unbekannte Regel SRPv2
....exe as Unrestricted using SRPv2 rule, Guid = ...
Es sieht also so aus, wie wenn sich da was einmischt - vermutlich der AppLocker.
Dem bin ich nochmal etwas nachgegangen und hab festgestellt, dass auf dem 22H2 der Anwendungsidentität-Dienst ausgeführt wird (obwohl der Service auf manuell steht) und auf dem 21H2 nicht. Ich hab daraufhin lokal auf dem 22H2 die AppLocker-Einstellungen geprüft: Sie sind leer, ich hab sie dennoch zurückgesetzt und unter C:\Windows\System32\AppLocker die Regel-Dateien gelöscht. Den Dienst beendet und mein Glück erneut versucht. Es greift immer noch die SRPv2-Regel. Nach nem Neustart war der Anwendungsidentität-Dienst wieder gestartet (Abhängigkeiten und Beschreibung des Dienstes sind 1:1 wie im 21H2). Daher habe ich in der Registry den Dienst manuell auf Status 4 gesetzt (=deaktiviert). Nach dem Neustart war der Dienst nicht aktiv, aber die SRPv2 hat immer noch gezogen. Eine Suche in der Registry nach SRPv2 war leider auch ergebnislos. Ebenso sind die klassischen Reg-Speicherorte für die SRP auch leer.
Frage 1 ist somit, wieso in der Installation vom 22H2 der Anwendungsidentität-Dienst nun wohl standardmäßig ausgeführt wird und Frage 2), wie ich ihn wieder los werde ;) Vielleicht hat ja jemand von euch AppLocker-Profis ne Idee dazu.
Grüße,
Johannes
-
Am 14.10.2022 um 10:20 schrieb Sunny61:
Nimm den W11 Pro, installier dort die GPMC und pack den Rechner in eine eigene OU. Jetzt dort mit den ADMX Templates von W11 das GPO neu bauen für die OU in der nur W11 liegt.
Hab ich gerade versucht - leider erfolglos. Auf einem W11 Pro 21H2 funktionieren die SRP dahingegen einwandfrei.
-
Gestern hab ich noch nen PC mit Win 10 Pro in die OE umgehängt und die Einstellungen haben sofort funktioniert. Es hängt also scheinbar am Win11 Pro 22H2. Leider hab ich nicht die Enterprise im Einsatz :/ Hintergrund der Einführung ist natürlich der erweiterte Schutz gegen Schadsoftware. Habt ihr neben der SRP (/Applocker) noch eine Empfehlung dafür?
-
Vielen Dank für eure Rückmeldungen. Ich möchte das tatsächlich auf Computer-Ebene umsetzen, habe es aber nun zwischenzeitlich auch mal parallel auf Benutzer-Ebene konfiguriert und per default auf "nicht erlaubt" gesetzt. Zur Eingewöhnung wollte ich zunächst mal mit der Blacklist anfangen.
Meine Konfiguration ist also vergleichbar mit der von Sunny61, aber es möchte einfach nicht funktionieren. Die GPO greift (ich kann über rsop die Einstellungen auf Computer und Benutzerebene sehen), zeigt aber keine Wirkung. In der Ereignisanzeige taucht diesbzgl. auch kein Fehler auf.
Bei der weiteren Suche bin ich nun auf ein paar Artikel gestoßen, in denen beschrieben wird, dass Microsoft das Feature ab 1803 nicht mehr aktiv weiterentwickelt. Ich hab hier ein Win 11 Pro 22H2. Hat zufällig jemand die SRP unter dieser Version laufen?
-
Hallo zusammen,
ich bin gerade dabei in einer Testumgebung die "Richtlinien für Softwareeinschränkungen" zu testen.
Das ganze ist in einer GPO konfiguriert und ich verwendet den "Blacklist-Ansatz". Sprich standardmäßig ist alles erlaubt, aber in einigen Verzeichnissen sollen keine exe-Dateien ausgeführt werden dürfen. Dazu habe ich ein paar Pfade konfiguriert (siehe Screenshot). Die GPO wird auch auf dem Rechner angewendet (der Screenshot ist von rsop.msc). Allerdings kann ich nach belieben exe-Dateien in den angegeben Pfaden ausführen (egal ob als Administrator oder Benutzer). Die Reg-Pfade sind "C:\windows" und "C:\Program Files\Common Files" und dürften folglich nicht vorab greifen.
Hab ich noch irgendeine Einstellungen übersehen, bzw. kann die Richtlinie von einer anderen "übersteuert" werden?
Danke und Grüße,
Johannes
-
Vielen Dank für eure Rückmeldungen. Die Lancom sehen von der Beschreibung tatsächlich vielversprechend aus - werde ich definitiv ausprobieren. Mir kam am Wochenende noch eine Idee: An manchen dieser mobilen Arbeitsplätze haben wir auch ein Notebook, dass zur Eingabe verwendet wird. Ich möchte daher mal Versuchen diese ominöse Windows-Verbindungsbrücke zu verwenden. In Theorie könnte das klappen, über die Praxis halte ich euch auf dem Laufenden :)
Grüße,
Johannes
-
Hallo zusammen,
wir haben auf einem mobilen Arbeitsplatz (ein Rollwagen mit Batterie und DC/AC-Wandler) ein Gerät, dass leider nicht WLAN fähig ist. Ich würde daher gerne einfach einen AP im Client-Mode dazwischen schalten und das Gerät somit WLAN-fähig machen. Da der Arbeitsplatz mobil ist, wechselt er zwischen mehreren Hallen und folglich sollte der AP die Verbindung zu den entsprechenden APs mitziehen. Wir haben aktuell einen älteren Cisco-AP dazu im Einsatz, der sich leider nur zur MAC-Adresse eines AP verbindet. Sobald dieser außer Reichweite ist, ist somit auch die Verbindung weg.
Laut Dokumentation haben viele APs die Client-Funktion. Eine tiefere Funktionsbeschreibung bzgl. Roaming bleibt aber leider aus. Bevor ich nun alle günstigen Geräte kaufe und Teste: Kennt ihr einen AP (egal welche Marke, egal ob auch mehr Funktionen), der genau das kann? Ein kurzer Verbindungsabbruch zwischendurch ist unproblematisch, die Datenrate ist absolut vernachlässigbar und 2,4 und 5 Ghz sind als Host-Netz verfügbar.
Danke und Grüße,
Johannes
-
Hallo zusammen,
das Thema Bildschirmhintergrund über GPO ist eigentlich ausführlichst im Internet dokumentiert - bisher habe ich es auch immer hinbekommen. Nun habe ich aber ein Problem bei dem ich nicht weiterkomme: Bei einigen unserer Arbeitsplätze wurde bisher mittels einer .theme-Datei die grundlegende Design-Einstellung erzeugt. Das soll sich nun ändern und ich habe alles relevante direkt über die entsprechenden GPOs angepasst.
Ebenfalls soll in dem Zusammenhang auch der Bildschirmhintergrund über die GPO gesetzt werden. Die Datei wird hierzu lokal auf den Rechner kopiert wird und entsprechend darauf verwiesen. Logge ich mich mit einem neuen Benutzer ein klappt das wunderbar und der Desktophintergrund ist gesetzt.
Bei den bestehenden Profilen, die ursprünglich mittels der .theme "erstellt" wurden, verhält es sich anders: Der Desktophintergrund ist schwarz. Folgendes habe ich geprüft und getestet:
- Da es bei neuen Benutzern funktioniert, gehe ich davon aus, dass mit meinen GPOs soweit alles passt
- Wenn ich bei bestehenden Benutzern das Profil lösche und mich dann wieder neu einlogge funktioniert es auch -> Rechte sollten also auch nicht das Problem sein. Das Löschen der Profile ist aber natürlich keine Option.
- Bei den bestehenden Benutzern habe ich das Windows-Design gewählt und das alte gelöscht.
- In der Registry der Benutzer ist der richtige Pfad zum Hintergrund-Bild gesetzt (kommt also über die GPO an - das zeigt ebenfalls die rsop.msc)
- In den "Energieoptionen" und der "Erleichterten Bedienung" ist der Bildschirmhintergrund ebenfalls überall aktiv
- Die Vorschau bei "Anzeigeeinstellungen->Hintergrund" zeigt das Hintergrundbild, das eigentlich angezeigt werden soll - es erscheint nur nicht auf dem Desktop.
- Ich habe testweise die typischen Cache-Files gelöscht: "%USERPROFILE%\AppData\Roaming\Microsoft\Windows\Themes\TranscodedWallpaper" & "%USERPROFILE%\AppData\Roaming\Microsoft\Windows\Themes\CachedFiles\*"
Was mir aufgefallen ist:
- Bei den neuen Profilen wird sowohl das TranscodedWallpaper als auch das Bild in den CachedFiles erzeugt. Bei den bestehenden Profilen wird nur das TranscodedWallpaper erzeugt. Der Cached-Files-Ordner bleibt aber leer.
Hat jemand von euch eine Idee an was das noch liegen kann?
Danke für eure Hilfe und Grüße,
Johannes
-
Hallo zusammen,
es gibt mehrere Internetanschlüsse, die alle über einen Loadbalancing-Router zusammengefasst werden und somit den Clients/Servern eine "eindeutige" Route aufweisen. Ich möchte aber für einen Admin-PC, dass dieser unabhängig vom Loadbalancing-Router (falls da mal was ausfällt) ins Internet kommt, um im Notfall über z.B. Teamviewer auf zumindest diesen PC zuzugreifen und dann nötige Maßnahmen ergreifen zu können. Daher möchte ich testen ob die Gateways tatsächlich ins Internet kommen und dann das default-Gateway automatisch ändern.
Das Problem konnte ich nun identifizieren: Bei meinen Tests hab ich den Zugriff auf die 192.168.249.2 einfach komplett in der Firewall des Gateways blockiert. Somit hat Windows keine Antwort vom Gateway erhalten und dann das nächst beste (=das default-Gateway) als Route genommen. Ich hatte fälschlicherweise erwartet, dass der Ping in einen timeout läuft. Mein Script habe ich daher wie folgt angepasst: Ich prüfen zunächst ob das Gateway überhaupt erreichbar ist und erst bei Erfolg setze ich die Route und prüfe die Verbindung ins Internet.
Danke und Grüße,
Johannes
-
Hallo zusammen,
ich habe hier im Netz zwei Gateways (192.168.249.1 und 192.168.249.2). Default Gateway ist das 192.168.249.1. Nun möchte ich überprüfen, ob über das Gateway 192.168.249.2 eine Verbindung ins Internet funktioniert. Dazu möchte ich eine Test-IP anpingen (in dem Fall die 8.8.8.8). Unter Linux habe ich den Ansatz schon öfters verwendet, unter Windows klappt das aber aus mir nicht erklärlichen Gründen nicht:
- route add 8.8.8.8 mask 255.255.255.255 192.168.249.2
- ping ausführen
- route löschen
IPv4-Routentabelle =========================================================================== Aktive Routen: Netzwerkziel Netzwerkmaske Gateway Schnittstelle Metrik 0.0.0.0 0.0.0.0 192.168.249.1 192.168.249.40 281 8.8.8.8 255.255.255.255 192.168.249.2 192.168.249.40 26 127.0.0.0 255.0.0.0 Auf Verbindung 127.0.0.1 331 127.0.0.1 255.255.255.255 Auf Verbindung 127.0.0.1 331 127.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 331 192.168.249.0 255.255.255.0 Auf Verbindung 192.168.249.40 281 192.168.249.40 255.255.255.255 Auf Verbindung 192.168.249.40 281 192.168.249.255 255.255.255.255 Auf Verbindung 192.168.249.40 281 224.0.0.0 240.0.0.0 Auf Verbindung 127.0.0.1 331 224.0.0.0 240.0.0.0 Auf Verbindung 192.168.249.40 281 255.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 331 255.255.255.255 255.255.255.255 Auf Verbindung 192.168.249.40 281 =========================================================================== Ständige Routen: Netzwerkadresse Netzmaske Gatewayadresse Metrik 0.0.0.0 0.0.0.0 192.168.249.1 Standard ===========================================================================Ergebnis:
tracert 8.8.8.8 Routenverfolgung zu dns.google [8.8.8.8] über maximal 30 Hops: 1 <1 ms <1 ms <1 ms 192.168.249.1 ...Windows verwendet also trotz der spezifischen Route zum anderen Gateway offensichtlich das Standard-Gateway. Das Verhalten kann ich mir leider nicht erklären. Muss man die routing-Tabelle in Windows "aktualisieren"?
Danke und Grüße,
Johannes
-
Ok, das hatte ich so aus deiner ersten Antwort nicht heraus gelesen (dynamische Updates werden vom secondary abgelehnt und aus). In dem Fall gehen die dynamischen Updates auch mit dem Einsatz eines secondary DNS. Der wird wie von mir gewünscht nur für das Auflösen der Zonen verwendet. Ein dynamisches DNS-Update wird vom Client über einen der Master-DNS-Server realisiert. Somit sind ja all meine Anforderungen gelöst.
-
Schade, da hätte ich mir mehr Intelligenz erwartet. Z.B. dass das dynamische Update automatisch an den Master gerichtet wird (steht ja in der Zone).
Von daher sind die meisten sekundären DNS ja eher bedingt sinnig. Daher kann ich:
- Entweder den Weg über einen zusätzlichen AD-Server mit entsprechender Standortkonfiguration im AD gehen - etwas übertrieben für meinen Bedarf.
- Oder doch mit den Einschränkungen des sekundären DNS leben. Da mich das in dem Fall keine Lizenzen kostet, sondern nur ein paar Minuten Installation werde ich das einfach mal testen.
Grüße,
Johannes
Edit: Gerade den Beitrag noch gefunden: https://blog.mikejmcguire.com/2013/11/04/dns-dynamic-update-through-secondary-read-only-dns-servers-you-must-unlearn-what-you-have-learned/
Fehlermeldung 4625 - Anmeldung vom Computerkonto fehlgeschlagen auf Dateiserver
in Active Directory Forum
Geschrieben
Ich hab den Server heute Nacht neugestartet - leider bleibt das Phänomen bestehen. Interessanterweise tritt es über die Nacht quasi nicht auf. Gefühlt scheint es also mit den Zugriffen auf den Server (die Nachts definitiv deutlich geringer sind) zusammenzuhängen.
Wie bekomme ich den NTLM denn gesprächiger? Ich hab mal ein paar lokale GPOs gesetzt, aber das Ereignislog des NTLM ist komplett leer.