winmadness

Danke an euch für die Tipps. Ich habe mit Wireshark festgestellt, dass die Anfragen nicht verschlüsselt werden. Ein "Simple Bind" wird ohne Verschlüsselung abgelehnt - Fehlermeldung res = ldap_simple_bind_s(ld, 'domain\user', <unavailable>); // v.3 Error <8>: ldap_simple_bind_s() failed: Strenge Authentifizierung erforderlich Server error: 00002028: LdapErr: DSID-0C090273, comment: The server requires binds to turn on integrity checking if SSL\TLS are not already active on the connection, data 0, v3839 Error 0x2028 Eine sicherere Authentifizierungsmethode wird für diesen Server benötigt.

Danke für die schnelle Antwort. Was ist mit ".. geht nicht mit ohne ..." - meinst Du ".. geht nicht ohne domainmember"? Ich habe am DC CBT und Signing bereits erzwungen - Sicherheitsoptionen "Domänencontroller: Anforderungen an das LDAP-Serverkanal-Bindungstoken" auf "Immer" und "Domänencontroller: Signaturanforderungen für LDAP-Server" = "Signatur erforderlich". Auf dem Client zusätzliche "Netzwerksicherheit: Signaturanforderungen für LDAP-Clients" = "Signatur erforderlich" (wenn ich richtig verstanden habe, benötige ich diese Option aber eigentlich nicht). Wie gesagt wird nur Port 386 verwendet. Kann ich auf dem Server (Client) irgendwo sehen, ob die Verbindung verschlüsselt ist? Ich habe einen zusätzlichen Test vorgenommen: auf dem DC das Computerzertifikat in "Eigene Zertifikate" gelöscht. Wie erwartet ist damit keine TLS Verbindung (ldp.exe) mehr möglich. Jetzt auf dem Client wieder über Eigenschaften -> Sicherheit eines Netzwerklaufwerk eine LDAP Anfrage erzwungen. Diese war erfolgreich über Port 389 und somit unverschlüsselt.

Konfiguration: Windows 2016 Hyper-V VM als DC, Clients Windows 10 Anmeldung über VPN mit User Zertifikaten, kein Domainmitglied. Wie kann ich den LDAPS (SSL/TTLS) vom Client erzwingen? Ich habe auf dem DC das notwendige Computer Zertifikat erstellt. Der Test auf dem DC mit ldp.exe über Port 636 mit TLS verschlüsselt funktioniert. Auch der Test mit der Software "Softerra LDAP Administrator" mit den gleichen Einstellungen auf dem VPN Client funktioniert. D.h. der Client kann eine verschlüsselte Verbindung über Port 636 erfolgreich aufbauen. Wenn ich jetzt eine LDAP Abfrage auf dem Client z.B. über die Anzeige die Sicherheitseinstellungen einer Netzwerkfreigabe ausführe, dann sehe ich in der Firewall nur den Port 386. Laut MS Dokumentation erfolgt eine verschlüsselte Anfrage über Port 636. Deshalb die Frage wie kann die LDAP Verschlüsselung von einem Nicht-Domain-Mitglied erzwungen werden? Weitere Frage: ich habe die entsprechenden Einstellungen für LDAP Channel Binding und Signing auf DC und den Clients gesetzt. Wie kann ich überprüfen, ob die Einstellungen greifen? Die erweiterte Protokollierung über die Registry ("16 LDAP Interface Events" = 2) habe ich aktiviert. Im Ereignisprotokoll finde ich keine Einträge.

Richtig, eine Malware ist nicht wählerisch und auch nicht begrenzt in der Auswahl seiner Ziele. Weder die "Rundmail" noch Microsoft können die Malware von Deinem System beseitigen. Darum musst Du Dich schon selber kümmern.

@cosmo87 Was ich nicht nachvollziehen kann, warum Du eine Backup Software "neu erfinden" willst. Das Kopieren der 43 zip-Dateien ist ja nur der erste Schritt. Die Backups müssen verwaltet werden, was passiert, wenn einige Backups nicht laufen, wer wird wie benachrichtigt. Es gibt gute Backup-Programme für wenig Geld.

Wäre es nicht einfacher, die Ereignissanzeige nach Fehler bzgl. Datenbank. Webserver etc. zu scannen. Ich gehe davon aus, dass z.B. bei fehlender Datenbankanbindung der DB Server nicht sauber gestartet wird und eine entsprechende Meldung absetzt.

Auf reddit beschreibt einer das gleiche Problem (letzter Beitrag von led352). Falls der Post nicht von Dir bzw. von einem Kollegen stammt ist es evlt. eine hilfreiche Quelle.

Dann würde ich jetzt noch mal den Blacklist Check machen. Und wenn das Problem bereits am Montag bestand, was wurde seitdem unternommen?

Dein Mail Server steht auf 5 Blacklists und es werden "komische" Entwurfs-EMail erstellt. Und Du gehst weiter davon aus "es waren nur Entwürfe"? Lade mal auf den Exchange Server und den betroffenen Clients malwarbytes und lasse mal einen Scan laufen. Welchen Virenscanner habt Ihr im Einsatz. Evtl. einen Profi für "Virenbeseitigung" engagieren. Die Frage sollte Dir weitere Anhaltspunkte geben:

Du kannst mal für Testzwecke den DNS für die "Remote-Zone" über NRPT angeben. Ist keine Dauerlösung, aber evtl. gibt es dadurch neue Erkenntnisse. Was steht in "Weiterleitungen" des lokalen DNS, was in "Stammhinweise". Evtl. mal zum Testen den DNS der Remote Zone in "Weiterleitungen" eintragen. Im DNS der Remote Zone - hat "Jeder" Leserechte + Spezielle Rechte (evtl. mit dem lokalen DNS vergleichen) auf die Zone?

Kannst Du vom Gateway aus einen ping/nslookup erfolgreich absetzen? Was ist es für ein Gateway - Cisco etc.?

Du hast geschrieben, dass ein ping auf die IP funktioniert. Also gehe ich davon aus, dass die Route entsprechend gesetzt ist. Evtl. trotzdem mal mit "route print" prüfen. Soweit ich gesehen habe, hast Du auch IPv6 eingereichtet. Was passiert bei einem nslookup mit der IPv6 Adresse?

Evtl. mal folgendes versuchen: auf beiden Servern die Bedingte Weiterleitung löschen, dann Kommando dnscmd /clearcache ausführen. Danach nur auf Server 192.168.0.2 die bedingte Weiterleitung eintragen und testen.

Mit Problemen kann ich leider nicht dienen Wir verwenden Veeam und sichern damit unsere Hyper-V Server (DC, Exchange, Fileserver, mit "application-aware processing"). Auf einer Testmaschine erstelle ich min. einmal im Monat einen Restore der VMs. Dann teste ich alle Funktionen (Outlook, ActiveSync, Fileserver, VPN Login mit User Zertifikaten, Datenbank-Anwendungen) - bisher immer ohne Probleme. Lediglich die VM des Exchange Servers muss ich zweimal starten, da beim ersten Mal nicht alle Dienste gestartet werden. Ansonsten ist kein manueller Eingriff notwendig. Was ich ebenfalls getestet habe sind die Veeam Tools für den direkten Zugriff auf die Exchange Datenbank und des AD - auch hier keine Probleme. Allerdings habe ich keine Erfahrungen mit dem Backup/Restore eines Bare-Metal-Servers.

Zu WDFilter gibt es Fehlerbehebungen - evtl. etwas für Dein Problem dabei: MS Forum und Blog Beitrag

Danke, damit ist es klar. Eine Frage bzgl. Was ist der Grund hierfür?

Hallo, bevor ich weiter teste frage ich lieber mal nach. Wir haben einen Exchange Server 2016 und Windows Server 2016 DC. Auf den Clients läuft Office 2016. Ich habe zum testen einen User in die Gruppe "Geschützte Benutzer" (Protected User) eingestellt. Damit kann ich von einem Domain-Rechner Outlook öffnen und verbinden - ohne Passworteingabe. Wenn ich versuche, Outlook von einem VPN Rechner (ohne Domainanbindung) aufzurufen oder ein Profil anzulegen, wird ständig die Eingab des Benutzers / Passwortes verlangt. Nach korrekter Eingabe der Login-Daten erscheint die Aufforderung sofort wieder. Wenn ich ein bestehendes Outlook Profil verwenden und die Kennwort-Abfrage abbreche, verbindest sich zwar Outlook aber das Problem "Kennworteingabe erforderlich" bleibt bestehen. Eine Profil-Anlage ist nicht möglich. Die VPN-Verbindung erfolgt mit dem Windows Client über IPsec/IKEv2 und mit Benutzer Zertifikaten. "klist" zeigt korrekt die Kerberos Tickets an. Deshalb die grundsätzliche Frage, ob ein Nicht-Domain-Client Probleme mit einem User in der Gruppe "Protected User" hat?

Ach wir haben immer wieder das im Blog beschriebene Problem, dass EMails an MS Konten einfach gelöscht werden. Ich würde an Deiner Stelle noch folgende Tests durchführen: Eintrag Deiner Firmen-Mail-Adresse im live.de Account im Bereich "Sichere Absender". Damit ist bei uns das Problem gelöst. Anlage eines weiteren live.de Accounts und testen mit "Large Files". Wenn das selbe Verhalten auftritt kannst Du sicher sein, dass es an MS liegt und Dein Konto nicht gecrackt wurde.

Hallo Peter, welcher Fehler wird angezeigt? Versuche mal die Aktivierung mit dem Setup-Key über Powershell - MS Anleitung

Solche alte Software kann ich nicht bedienen Mit PS funktioniert es und geht auch schneller.

Hallo, ich habe bei der Neuanlage eines Exchange Postfaches mit ECP auf einem Exchange 2016 Standard CU 21 folgenden Fehler festgestellt: Änderungen der „benutzerdefinierten Attribute“ werden nicht übernommen. Anlegen über Powershell funktioniert. Einzige Änderung war die Installation des CU 21. Eine Recherche ergab, dass das Problem mit den Attributen bekannt ist: Kommentare MS und Forums-Eintrag

Bereits Anfang 2021 wurde eine Sicherheitslücke in den Druckertreibern von Laser-Drucker der Firmen HP, Samsung und Xerox gefunden. Es stehen seit Mai Patches bereit. Die Sicherheitslücke erlaubt einem Angreifer über einen Pufferüberlauf die Rechte des "SYSTEM" Kontos zu erlangen. Ausführliche Meldung bei Heise.

Danke, mein Fehler.

Ich habe folgenden Powershell Befehl mal versucht (wurde in diesem Tweet beschrieben): [System.IO.File]::Copy("c:\windows\system32\config\security", "c:\users\test\Documents\security.copy") Hierbei bekomme ich die Fehlermeldung: Ausnahme beim Aufrufen von "Copy" mit 2 Argument(en): "Der Prozess kann nicht auf die Datei "c:\windows\system32\config\sam" zugreifen, da sie von einem anderen Prozess verwendet wird." Kann dies jemand nachvollziehen? Auf dem System war der beschriebene Lesezugriff für einen normalen Nutzer möglich. Ein Video zur Ausnutzung der Lücke mit mimikatz. Nachtrag: Habe für den Powershell-Befehl den falschen Pfad verwendet, laut Tweet muss [VSS-Path-to-SAM/SYSTEM/SECURITY] verwendet werden.

Eine weitere Sicherheitslücke in Windows 10 / 11 wurde entdeckt - Infos und Workaround unter CVE und Heise.