winmadness

Der Fehler ist mir bekannt. Hast Du die von Veeam empfohlene Ausschlüsse in Deiner Antvirus-Software eingetragen? Dies war bei mir die Ursache. Hier noch eine Möglichkeit, das Backup ohne VM Neustart wieder zu aktivieren: · Überprüfen, ob in der betroffen VM das Verzeichnis „C:\Windows\VeeamVssSupport“ vorhanden ist · Dateien im Verzeichnis werden durch Dienst „Hyper-V-Volumeschattenkopie-Anforderer“ (vmicvss) blockiert; Dienst stoppen · Verzeichnis „C:\Windows\VeeamVssSupport“ löschen · Dienst vmicvss wieder starten · Wenn Dienst „VeeamVSSSupport“ vorhanden, dann diesen löschen: sc delete veeamvsssupport

Mit folgender Option kannst Du die Vererbung deaktivieren (aus der MS Anleitung):

Und das heißt nun, dass die VM ebenfalls keine Probleme bereiten dürfte - macht sie aber. Du hast schon viel Zeit in alle möglichen Lösungsversuche gesteckt, deshalb die Frage wie aufwendig ist der Test mit dem Spooler-Dienst?

Mache eine Foreach Schleife für die Gruppenfelder gruppe1 bis gruppe 6. In dieser Schleife dann die if-Abfrage mit Berechtigung setzen.

Im Internet finden sich vielen Hinweise bzgl. Druckprobleme , wenn auch unter Windows 10. Evtl. mal den Spooler-Service deatkiveren und dann installieren. Ansonsten würde ich auf den Oktober Update warten und diesen Update überspringen, wenn dies möglich ist.

Evtl. noch einmal nachfragen bzgl. Dual Stack bzw. evtl. auch mal Anbindung über IPv6 testen. Wir hatten mit IPv4 bei beiden Anschlussarten Probleme - Dual Stack und Dual Stack Lite.

Ich habe das Problem im Posteingang / Exchange Cache Modus im Zusammenhang mit Synchronisations-Fehlern. Deshalb den Ordner "Synchronisierungsprobleme" prüfen. Des Weiteren könnte auch der Virenscanner dazwischenfunken. Testweise mal deaktivieren.

Evtl. helfen Dir meine Erfahrungen mit VPN Verbindungen weiter. Konfiguration: VPN mit IPSec / IKEv2, OPNSense als VPN Server, Windows 10 als VPN Clients, Internet Provider Vodafone und Telekom im Home Office. Fehlerbild: manche Tage ohne Probleme, andere Tage mit Programmabstürzen bzw. VPN Verbindungsproblemen. Bei uns lag es an IPv4 über Dual Stack (Lite). Nachdem die VPN Verbindung über IPv6 aufgebaut wird haben wir keine Probleme mehr.

Aktiviert Ihr die Optionen über das ECP? Wenn ja, die Aktivierung mit Exchange Powershell vornehmen. Hintergrund: Es gibt mit Exchange 2016 CU 21 ein Problem bei der Einstellungen von benutzerdefinierten Attributen über ECP - diese werden nicht übernommen. Evtl. auch hier ein Fehler im ECP.

@Fries Evtl. mal folgenden Test mit einem Client durchführen: alle Programme beenden, Verbindung trennen. Verbindung aufbauen und Programme einzeln starten. Auf dem Server nach jedem Programmstart die Sitzungen kontrollieren.

@wolfiru Ich verwende Windows PKI mit dem entsprechenden CA-Zertifikat. Dementsprechend ist das Exchange Zertifikat über meine PKI ausgestellt. Evtl. hilft Dir die kostenlose Software iMazing Profil Editor weiter, dort kannst Du ein Exchange Profile mit Zertifikaten anlegen und dann auf dem iPhone installieren. Ich erstelle mit Hilfe dieser Software meine iPhone Profile für ActiveSync mit Anmeldung über User Zertifikaten - läuft problemlos. Auf dem iPhone kannst Du das CA Zertifikat in der App "Einstellungen" unter "Allgemein -> Info -> Zertifikatsvertrauenseinstellungen" mit "volles Vertrauen ..." aktivieren. Du musst vorher natürlich das CA Zertifikat auf dem iPhone installieren.

In diesem Fall ist es immer gut mit englischen Begriffen zu suchen. Evtl. helfen Dir diese Tipps weiter: https://silicophilic.com/change-clock-on-lock-screen/

Wie vorgeschlagen über die Firewall die Domains autodiscover.tld blockieren. Weitere Möglichkeiten sind die Verwendung von User Zertifikaten, wie wir es sowohl für die Windows Clients als auch für die ActiveSync Geräte im Einsatz haben. Einrichten von Exchange Clients (Outlook, ActiveSync Geräte) im lokalen Netzwerk (LAN / WLAN) mit entsprechenden Firewall Eintragungen. Soweit ich getestet habe, werden Anfragen an autodiscover vom MS Outlook Client nur bei der Anlage eines Profiles gesendet. D.h. bei der alltäglichen Nutzung von Outlook sollte das Problem gar nicht erst auftreten.

Unter Passwort zurücksetzten in der Suchmaschine findest Du einige Tricks, um das Passwort zurück zu setzen. Tipp Nummer 3 habe ich selbst schon angewendet. Dafür nicht, im Gegenteil Lob für das Arbeiten mit einem Konto ohne Adminrechte. Also in Zukunft ein reines Admin-Konto zur Verwaltung und ein Arbeitskonto ohne Admin-Rechte für das tägliche Arbeiten anlegen.

Nein, aber man könnte einschätzen, welche Clients betroffen sind und entsprechende Absicherungsmaßnahmen treffen.

Im Heise-Artikel findet sich ein Hinweis auf das verwendete Autodiscover Protokoll: Kann einer beurteilen, bei welchen Clients POX im Autodiscover Protokoll verwendet wird? Anscheinen nicht bei MS Outlook 2016. Ich habe noch einen weiteren Test durchgeführt. Outlook verbindet sich bei meinem Client über eine VPN Verbindung. Also Outlook gestartet und mit Exchange verbunden, VPN Verbindung getrennt und dann den in Outlook integrierten "E-Mail-Autokonfigurations-Test" durchgeführt. Auch hier werden nur Domain / Subdomain von firma.com abgefragt, keine Anfrage an autodiscover.com. Nachtrag: Ich habe in der MS Dokumentation eine Beschreibung des POX Formates inkl. folgenden Hinweis gefunden:

Sehe ich genau so. Deshalb bin ich etwas verwundert über die "Alarmmeldung". Entweder das Testszenario ist nicht sauber beschrieben oder der Fehler wurde bereits behoben.

Wenn ich mir die Screenshots des Profil Managers und die Beschreibung anschaue, finde ich keinen Unterschied zu meinem Tests. Bzw. spiegeln meine Tests unsere Routine beim Einrichten eines Exchange Kontos wieder. Lediglich die MS Office Version unterscheidet sich. Ich benutze natürlich den aktuellen Build 16.0.5215, die Sicherheitsforscher 16.0.13901. Ich habe bei meinen Tests auch die unverschlüsselte Einrichtung des Profils getestet. Darauf bezieht sich die Sicherheitslücke mit der Übermittlung der Account-Daten über Port 80. Beim Einrichten eines Exchange Profils würde man natürlich die Abfrage nach einem unverschlüsselten Einrichten des Kontos (nach Fehlschlag der verschlüsselten Verbindung) nicht durchführen, sondern auf Fehlersuche gehen.

Danke für das Feedback. Ich habe eine ausführliche Beschreibung der Sicherheitslücke unter https://www.guardicore.com/labs/autodiscovering-the-great-leak/ gefunden. In dem Auszug aus dem Webserver Protokoll ist die Outlook Version zu sehen - Windows 10 mit MS Office 2016 bzw. 2019 bzw. Microsoft 365 (sofern ich das richtig interpretiere): Nachtrag: Unter https://docs.microsoft.com/de-de/officeupdates/update-history-office-2019 habe ich Infos bzgl. der Buildnummer 13901 gefunden. Diese betreffen die MS Office 2016 / 2019 Version im Zeitraum April / März 2021

Ich kann das Verhalten nicht nachvollziehen. Ich habe mit dem Profil-Manager von Outlook 2016 sowohl ein Exchange als auch ein ActiveSync Profil mit Testdaten und unserer Domain firma.com angelegt. Über den ESET Virenscanner die Firewall auf "Interaktiver Modus" eingestellt, so dass alle angefragten Domain zur Freigabe angezeigt werden. Unsere Autodiscover Domain autodiscover.firma.com entsprechend blockiert, damit keine Einrichtung des Kontos möglich ist. Es wurde in keinem Testfall die Domain autodiscover.com angefragt, immer nur Domain / Subdomain firma.com. Mache im beim Testen etwas falsch bzw. kann jemand von euch die Sicherheitslücke nachvollziehen? Könnte es sein, dass nur ältere Versionen von MS Outlook betroffen sind?

Zum Testen würde ich im ESET den "E-Mail Client Schutz" komplett deaktivieren. Damit kannst Du den Virenscanner schon mal ausschließen (oder auch nicht ). Alternativ den Virenscanner mal deinstallieren und mal einen Tag ohne testen (sofern es die Compliance zulässt).

Kein Problem, Post war nur als Rückmeldung gedacht.

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.