basstscho

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.

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

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. 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! Hast du mir ein paar Beispiele? Würde ich gerne ergänzen! 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

Hab ich gerade versucht - leider erfolglos. Auf einem W11 Pro 21H2 funktionieren die SRP dahingegen einwandfrei.