winmadness

Hallo,

wir hatten schon mal ein ähnliches Problem und meine Lösung ist hier beschrieben. Nur ein Hinweis, ich kann auf die Schnelle nicht beurteilen ob Dein Problem das Selbe ist.

Hallo Peter, hast Du das Problem inzwischen lösen können.

Wir haben ebenfalls die Version 11a im Einsatz und bisher noch ohne Probleme. Allerdings haben wir Windows 2016 Server und VMs im Einsatz. 

Wir setzen die Produkte von ESET ein, sowohl für die Clients als auch für die Server. Bisher gute Erfahrungen. Die Lizenzen werden über das ESET Online Portal verwaltet. Des Weiteren hat man die Möglichkeit die Einstellungen über die ESET Cloud zu verwalten – sofern man der Cloud vertraut.

Kaspersky hat nicht nur das Problem der Vertrauenswürdigkeit sondern es besteht nach meiner Meinung auch die Gefahr von Sanktionen. Wenn USA beschließt Kaspersky auf die „rote Liste“ zu setzen dann wird es eng. Für Behörden ist der Einsatz in den USA schon seit 2017 verboten.

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

vor 28 Minuten schrieb congeries:

die "Vererbung" in den Erweiterten Sicherheitseinstellungen deaktiviert habe, daher jetzt die Frage nach einer Zeile die dies macht.

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

Zitat

/inheritancelevel: [e | d | r]

Legt die Vererbungsebene fest, die wie die folgenden sein kann: e: Aktiviert vererbung d: Deaktiviert die Vererbung und kopiert die ACEs. r: Entfernt alle geerbten ACEs.

vor 5 Stunden schrieb Edvvde:

Alle anderen VMs auf dem Host und sogar der Host selbst haben das selbe Update erhalten und machen keine Probleme

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?

vor 18 Minuten schrieb BlacksGood:

user,gruppe1,gruppe2,gruppe3,gruppe4,gruppe5,gruppe6

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. 

vor 28 Minuten schrieb illumina7:

Als Business Kunde sollten wir mit der statischen IPv4 also grundsätzlich keinen DS (Lite) Anschluss haben.

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.

vor 46 Minuten schrieb MichaAchim:

Aktiviert man die Optionen für die ausgewählten Nutzer erneut, funktionieren diese wieder ohne Probleme.

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.

vor 2 Stunden schrieb ellileon:

Google hat mir zu dem Thema auch nichts ausgespuckt

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/

vor 1 Minute schrieb NorbertFe:

Welche denn?

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.

vor einer Stunde schrieb Dag:

habe ein lokales Konto für denjenigen eingerichtet, allerdings, ihr werdet mich steinigen, ohne Adminrechte.

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.

vor 1 Minute schrieb NorbertFe:

wirst du dann deinen Usern sagen, das dürft ihr aber nicht verwenden

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:

Zitat

Dass Outlook und Exchange hier einfache, HTTP-authentifizierte Klartext-Anmeldedaten an irgendwelche unbekannten Server verschicken ist ein riesiges Problem. Zwar untersuchten die Forscher nur eine Version (basierend auf Plain Old XML oder POX) von vielen des Autodiscover-Protokolls und es gelang ihnen auch bei weitem nicht in allen möglichen Konfigurationen Daten auszulesen, der Erfolg ihrer Datenspionage im öffentlichen Netz mit den selbst registrierten Domains sollte allerdings zu denken geben.

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:

Zitat

Für Clients, die auf Versionen von Exchange ab Exchange Server 2010 abzielen, wird empfohlen, den SOAP-AutoErmittlungsdienst anstelle des POX-AutoErmittlungsdiensts zu verwenden. Clients, die auf Exchange 2007 Zielen, müssen den POX-AutoErmittlungsdienst verwenden. Es wird empfohlen, dass Clients, die das .NET Framework verwenden, den verwaltete EWS-API verwenden, da er einen robusten und bewährten POX-Auto Ermittlungs Client enthält. Weitere Informationen zum verwaltete EWS-API finden Sie unter Erste Schritte mit verwaltete EWS-API-Clientanwendungen

vor 2 Minuten schrieb NorbertFe:

Wäre ja nicht das erste Mal, dass MS das schon fixt während es hochkommt. ;) Ich denke Outlook und MS Clients sind vermutlich sowieso die einzigen Stellen an denen MS kurzfristig ansetzen kann. Der "arme Exchange" kann ja eigentlich gar nix dafür. ;)

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.

vor 6 Minuten schrieb NorbertFe:

Stellt sich halt die Frage, was die anders machen, als ihr aktuell? :)

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):

Zitat

Windows+NT+10.0;+Microsoft+Outlook+16.0.13901;+Pro

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).

Gerade eben schrieb NorbertFe:

Oder wo ist das Problem?

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