jimmyone

Wir überlegen derzeit, was wir mit unserem Exchange 2016 machen. Das System war auf CU18, wurde am Samstag auf CU19 gehoben und das KB installiert. Glaubt man diesem Kommentar: https://techcommunity.microsoft.com/t5/exchange-team-blog/released-march-2021-exchange-server-security-updates/bc-p/2188076/highlight/true#M29753 sind das nur Indikatoren. Diese treffen scheinbar auch auf uns zu. Wir sehen aber auch Zugriffe / Requests auf das OAB allerdings mit http Fehler 500. Hier hat allerdings unser Gateway, was quasi auf dem Leitungsweg nach Signaturen scannt einen Block durchgeführt. Im Weiteren Check der Logs wird das ganze mit einem AppError für OAB und ECP zurück gemeldet, der als Hinweistext beinhaltet, dass mittels des DOMÄNE\Administrator keine Verbindung hergestellt werden konnte. Der o.g. Benutzer ist bei uns auch kein Exchange Benutzer. Schaut man dann auf diesen Link: https://www.microsoft.com/security/blog/2021/03/02/hafnium-targeting-exchange-servers/#scan-log zur Prüfung auf Webshells etc. finden wir in keinem der angegeben Pfade etwas. Auch der MSERT findet nichts. Firewall seitig wurden die IPs, welche die Requests gesendet haben blockiert und mit Bekanntwerden, entsprechend erweitert. Diese waren aber nicht auf China zurückzuführen sondern u.a. aus Bonn (NRW) und den Niederlanden stammend. Wir sehen auch keine ZIPs, RARs, 7z die seltsam wären. Der hauseigene Virenscanner liefert keine Resultate. Alle Microsoft Hinweise haben wir damit abgefrühstückt und nichts gefunden, außer den Einträgen, die im Kommentar als Probing bezeichnet wurden. Wir sind allerdings etwas weiter auf die Suche gegangen und haben in diesem Blog: https://www.crowdstrike.com/blog/falcon-complete-stops-microsoft-exchange-server-zero-day-exploits/ noch ein paar Hinweise für uns mitgenommen. Ich weiß zwar nicht ob der Link erlaubt ist, aufgrund der Tragweite, sorry falls verboten. Jedenfalls wird hier ebenfalls von Indikatoren für folgende Files gesprochen: C:\Windows\Microsoft.NET\Framework64\*\Temporary ASP.NET Files\root\*\*\App_Web_[0-9a-z]{8}.dll Entsprechende Files finden wir, die sowohl vor, in der fraglichen Zeit, als auch nach Einspielen der Patches erstellt werden. Die Frage die sich stellt ist, in wie weit dieser Indikator nun zählt. Intern herrscht gemischte Stimmung. Es gibt die Fraktion vom Netz nehmen und die Fraktion, keine bis sehr wenige Indikatoren aber keine feststellbaren Exploits. Ich finde das ein Dilemma. Beide Seiten haben Stichhaltige Argumente. Weitere Checks waren bei uns z.B. auch auf Änderungen von Benutzern im AD (Erstellt, geändert etc.) auch das war unauffällig. Lokale Admins wurden nicht erstellt, die Gruppe der lokalen Admins nicht angepasst, die Virtual Directories weisen keine Änderung auf. Der Healthchecker ist unauffällig, ein PROCDUMP des LSASS ebenfalls. Sich jetzt noch weitere Meinungen zu holen macht es wahrscheinlich nicht besser: Aber wie würdet ihr das jetzt bewerten? Offensichtlich hätte man in das System eingebrochen, wenn man nicht schon auf dem Leitungsweg am Gateway gestoppt worden wäre und der Admin Benutzer tatsächlich Admin gewesen wäre. Ein bisschen unruhig machen mich die App_Web DLLs. Das Firewall / Monitoring Team hat zusätzlich keine Auffälligkeiten entdeckt, was den Datenstrom ein- und ausgehend angeht. Laut diesem Team bewegt sich das innerhalb der sonst üblichen Bewegungen. Irgendwie glaube ich, dass wir nur Spitze des Eisberges sehen... Grüße Jimmyone

Guten Abend, gute Frage. Ganz genau kann ich das nicht sagen. Ich würde behaupten rund 24 Stunden, vielleicht etwas weniger, zwischen der Anlage der Gruppen, dem bemerken des Export Fehlers und dem plötzlichen Einsetzen des erfolgreichen Exports.

Liebe Kollegen, ich war mir nicht sicher wohin mit dem Thema. Ob hier oder ins Azure Forum. Evtl. gerne verschieben. Ich würde gerne mal über folgendes Verhalten von AD Connect diskutieren bzw. eure Meinung dazu einholen. Vielleicht vorab: Gehen wir mal davon aus, dass die Konfiguration stimmig ist und die notwendigen Rechte passen. Warum ergibt sich gleich. Wir nutzen u.a. das Group write back Feature. Wie wahrscheinlich bekannt erstellt dieses eine Universelle Verteilergruppe im on-premise AD. Ich hatte mich gewundert, dass keine meiner MS365 Gruppen angelegt wurden. Also ging ich auf die Suche und sah im Exporter in Richtung on-prem AD Fehler. Faktisch sah ich den Fehler 5 - Zugriff verweigert. Das Netz bietet viele Optionen und Ansätze, die auf falsche Konfiguration zurück zu führen waren. Ich konnte das für mein System aber nicht bestätigen. Ich habe das dann für den Moment dabei belassen und dachte, ich setze dann heute mit der Analyse fort. In der Regel findet man bei guter Durchleuchtung das verursachende Issue oder hatte ein RTFM Problem. Die Merkwürdigkeit beginnt also heute Morgen. Ich wollte mir das Thema wieder vornehmen und sehe in meinem on-prem AD die angelegten Verteilergruppen. Weder Logs noch andere Reports geben Aufschluss darüber, was sich über Nacht denn plötzlich geändert haben soll. Ich sehe nur um 03:44 Uhr einen erfolgreichen Export. Tests mit neuen Gruppen bestätigen die fehlerfreie Funktion. Verständlich für mich aktuell null. Es gab weder Änderungen an Konfigurationen noch sonst welche Änderungen in der betreffenden Zeit. Menschlich würde man das jetzt ausdrücken mit: Das Tool hat es sich scheinbar überlegt und funktioniert nun doch. Technisch: ??? Vor allem sehe ich keinen Hinweis, was nun jetzt anders ist. Ich sehe aber nicht, dass ein technisches Gerät urplötzlich Zugriff verweigert überwindet, was ja schon sehr deutlich ist als Fehlermeldung. Das bring natürlich die weitere Überlegung mit sich, wenn der nächste Fehler auftritt in dem Zusammenhang wie man den aufarbeitet, wenn offenkundig die Konfiguration und Rechte stimmen. Würde mich über eure Interpretationen freuen. Vielleicht habt ihr ähnliche Erfahrungen? Schönes Wochenende! Liebe Grüße Jimmyone

Vielen Dank! Ich finde gerade diesen Austausch ganz wichtig, weil ich mich noch in den Anfängen zu diesem Thema befinde. Mir ist deshalb auch wichtig, dass dieser Thread für mich noch nicht den Anspruch hat, völlig durchdacht und zu Ende gedacht zu sein. Für mich war jetzt wichtig, lese ich die Doku richtig, stimmt mein Verständnis für das Thema soweit. Die Frage bezgl. Replikation bzw. Synchronisation kommt ja nicht von ungefähr. Ich kenne ja meine Pappenheimer die genau damit kommen werden. Deshalb hatte mich u.a, interessiert ob das grundsätzlich machbar ist. Warum soll man Stunden damit verbringen etwas zu ergooglen, wenn sich manches auch auf dem kurzen Weg klären lässt. Zumindest teilweise. :) Vielen Dank an alle für die bisherigen Antworten.

Vielen Dank zunächst! Wieso? Der entsprechende Client kann doch eine LAN Verbindung haben aber keinen Zugriff auf das Internet. Der On-Premises Server wäre damit ja erreichbar. Oder formulieren wir das Beispiel mal anders. Der Client ist ein Notebook und bewegt sich in Ex geschützten Bereichen oder Sicherheitsbereichen. Hier steht nur das LAN aber kein Internet zur Verfügung. Das heißt Exchange Online wäre nicht erreichbar, On-Premises aber durchaus. Oder bauen wir mal ein ganz anderes Szenario zusammen. Stromausfall, die USV ist am Ende, die Dieseltanks leer und die on-Premises Systeme fahren herunter. Ich weiß das Szenario ist unwahrscheinlich, man würde die Tanks rechtzeitig befüllen, aber nur mal um dem Beispiel wegen: Die On-Premises Systeme wären nicht mehr erreichbar, nicht migrierte Mailboxen wären somit auch nicht erreichbar. Gibt es grundsätzlich einen Weg wie man die beiden Welten synchronisieren könnte?

Hallo Zusammen, vielleicht kann jemand bei folgender Fragestellung helfen. Wenn eine Exchange Hybrid Umgebung in Planung ist, kann man die Konfiguration so vornehmen, das On-Premises und Exchange Online jeweils das Postfach untereinander replizieren? Ziel soll sein, dass entweder Exchange Online zur Verfügung steht oder in Bereichen ohne Internetzugang ein on-premises Exchange im Netz das Postfach bereitstellt. Bis jetzt lese ich das immer so, dass man das Postfach entweder auf dem Exchange Online hat oder on-premises. Da ich mich aber zum ersten Mal mit dem diesem Thema befasse, will ich nicht ausschließen das ggf. falsch zu verstehen. Ich freue mich über hilfreiche Infos. Besten Dank vorab.

Hi testperson, erst mal vielen Dank für die Beteiligung an dem Anliegen. Aber die UAC gabs doch 2012 auch schon. Und der Fileserver 2012 verhält sich nicht so wie oben beschrieben. Das wundert mich ein wenig. Ich analysiere das nochmal weiter, was wir auf dem 2012 anders gemacht haben.

Hallo Zusammen, ich habe in meiner DEV oder Demo Umgebung einen Windows Server 2019 Standard installiert. Nun habe ich etwas bemerkt, was ich persönlich so nicht kenne. Lokaler Admin: Im Test für einen zukünftigen Fileserver habe ich ein Testvolume aus unserem Storage angebunden. Im Anschluss habe ich einen Ordner erstellt und habe simuliert, das es sich dabei um das persönliche Verzeichnis eines Mitarbeiters handelt. In this case: Me. Berechtigungen sind folgende: Als Besitzer ist die lokale Administratorengruppe hinterlegt. Im Anschluss habe ich eine Freigabe erzeugt und dann mit meinem Domänen Benutzer den Zugriff und das Handling getestet. Bis hier hin ein normales Verhalten und keine Probleme. Da aber nicht jeder über den lokalen Admin verfügt, sondern es durchaus Gruppen gibt wie die Domänen-Admins oder wie bei uns die Fileserver Admins habe ich diese Gruppen jeweils den lokalen Administratoren hinzugefügt. Naturgemäß war durch den Join zur Domäne die Gruppe Domänen-Admins bereits vorhanden. Nach erneuter Anmeldung an den Server als Mitghlied einer der beiden Gruppen, ob Fileserver Admins oder Domänen-Admins ist egal, hat dieser Benutzer keinen Zugriff auf die Ordner und auch nicht auf seine Eigenschaften. Der Reiter Sicherheit meldet, das keine Lesende Berechtigung vorliegt. Seltsam an der Sache ist, das der angemeldete Benutzer aber Mitglied der loaklen Administratoren Gruppe ist, durch Zugehörigkeit zu einer anderen Gruppe und somit Zugriff haben müsste. Wenn ich nun Zugriff auf den Ordner nehmen will, wird eine Meldung eingeblendet, die mich auffordert "Weiter" zu klicken um hier mit Administratorenrechten zu arbeiten. Klicke ich dann auf Weiter komme ich an den Ordner und seine Inhalte dran. Allerdings wird der Registerkarte Sicherheit mein Benutzer dann als Vollzugriff hinzugefügt. Dieses Verhalten stelle ich so für mich erstmalig fest. Auf meinem aktuellen Fileserver (W2K12) ist das so nicht der Fall. Wenn ich mich dort als Mitglieder einer der beiden Gruppen anmelde ist der Zugriff gewährt ohne Rückfrage und das hinzufügen des Benutzers. Kennt ihr das beschriebene Verhalten? Wir planen den Umstieg von Server 2012 weil Ende 2020 unser Supportvertrag für diese Betriebssystemgeneration ausläuft. Dann liegt natürlich die Idee nahe dies mit dem aktuellen Release zu machen. Mit Server 2016 habe ich das o.a. Verhalten nicht überprüft. Das System hat Stand: 10.0.17763 Grüße Jimmyone

Hallo Zusammen, vielleicht kann hier jemand den richtigen Denkanstoß geben. Exchange 2016 mit dem CU7. Outlook 2013 Konfiguration wie folgt: Im ECP wurde auf dem Freigegebenen Postfach im Bereich Stellvertretung eine AD Gruppe als "Vollzugriff" und dem Recht "Senden als" definiert. Auf dem Postfach selbst eine Gruppe für "nur lesende" Benutzer mit dem Recht Prüfer. Der Benutzer ist nachweislich in der Gruppe die im Vollzugriff der Stellvertretung eingetragen ist. Versucht nun jemand Ordner zu verschieben z.B. "A 2017, B 2017" nach "Kram 2017" , dann erhält er die Meldung: "Der Ordner kann nicht kopiert werden, da er möglicherweise private Elemente enthält." Eine Suche bei MS ergab, es muss eine Berechtigung im Postfach gesetzt werden, die sich "Stellvertretung kann private Elemente sehen" nennt. Dazu muss das Postfach als Profil verbunden werden und das Recht muss über Outlook hinterlegt werden. Link: https://support.microsoft.com/en-us/help/3205975/cannot-copy-this-folder-because-it-may-contain-private-items-error-in Die Lösung ist Ansatz Nummer 3, alles andere ist unpraktikabel. Ich hätte jetzt erwartet, dass an dieser Stelle die über ECP eingetragene Gruppe auftaucht. Stattdessen ist das Objekt leer. Wenn ich da jetzt jede Person einzeln anlegen müsste, geht ja die Grundidee über AD Gruppen verloren. Hat jemand dazu einen schlauen Tipp? Danke! Lieben Gruß Jimmyone

Hallo Zusammen, ich komme nochmal darauf zurück. Ich habe bei Microsoft einen Call geöffnet zu dem Thema. Die Antwort ist irgendwie unbefriedigend. Ich weiß nicht ob der Kollege dort mich nicht verstanden hat (vermutlich dem Name nach Rumäne) oder das Thema tatsächlich so ist. Die Antwort auf die oben gestellte Frage, warum muss ich zusätzlich das Limit eines Default Connectors erhöhen muss, wenn über einen neuen mit höherem MessageRateLimit versendet wird, war die, Mal zusammengefasst: Works as designed in Exchnage 2016. Anbei mal ein Zitat aus der Antwort: Meine Konfig ist meiner Meinung nach in keiner Weise spezifisch. Oder ist ein neuer Connector mit anderem MessageRateLimit so spezifisch das dafür Werte anderer Connectoren angepasst werden müssen? LG Jimmyone

Einen wunderschönen guten Abend, kann jemand von euch ggf. folgendes Verhalten bei einem Exchange 2016 CU7 Version 15.1 ‎(Build 1261.35) bestätigen? Folgender Sachverhalt: Neuer Empfangsconnector. Freigegeben für eine IP innerhalb des Netzes auf einem bestimmten beliebigen Port. Nur für Exchange Benutzer mit Windows Auth und TLS Auth. Bild zu Config der Limits anbei. Verhalten: Nachrichten können über den Connector versendet werden. Limit Einstellungen greifen nicht. Settings des "Client Frontend Servername" werden angewandt. Log meldet Verwendung des "richtigen" neuen Connectors bei Versand über die Applikation. Dienste und Server neu gestartet. Bei Anpassung der Limits des Default und des Default Frontend Connectors auf die gewünschten Werte ist die Versendung nach Maßgabe möglich. Frage: Kann das ggf. jemand bestätigen? ich wundere mich, dass das Transport Log die Nutzung des Connectors meldet und auch die Versendung belegt, die Limits aber vom falschen Connector gezogen werden. LG Jimmyone

Auch wenn das jetzt mal Off-Topic ist: Was bringen denn solch eine Empfehlungen die man immer wieder liest? In der Regel rein gar nichts. Jemand der keine Erfahrung mit dem Umgang und den Projekten hat würde hier nicht nachfragen müssen, wenn die Unternehmen nicht den meiner Meinung nach fatalen Fehler begehen würden und jemandem etwas abverlangen, dass er gar nicht leisten kann. Ganz oft ist: "Such dir einen Dienstleister" für das betreffende Unternehmen schwer machbar insbesondere wenn es kleine Unternehmen sind. Zurück zum Thema: Das Thema scheint nach den vorliegenden Infos kein Exchange Thema zu sein. Wurde an eurem AD DS etwas verändert? Wurden Dateirechte geändert etc. Gibt es Fehlermeldungen im Log des AD? Bist Du dir zum einen wirklich sicher, dass der Benutzer mit dem Du das ganze versuchst auch wirklich die o.a. Berechtigungen hat. Hast Du mal versucht einen zweiten Benutzer mit diesen Rechten zu erstellen? Was passiert, wenn Du AD Objekte ändern willst, z.B. Gruppenmitgliedschaften? Im übrigen stimme ich Norberts Ausführungen zu. Grüße Jimmyone

Welche Berechtigungen hat der ausführende Benutzer? Ich würde das Fehlerlog nochmal bearbeiten und die Klarnamen ggf. herausnehmen.

Guten Morgen Zusammen, ich denke diese Frage lässt sich sehr einfach beantworten und ich vermute die Antwort wird so ausfallen wie ich mir das ganze denke. Sachverhalt: AD Gruppen sind auf Postfächer berechtigt um ein Modell für nur lesende Berechtigungen umzusetzen. Das klappt auch alles ganz wunderbar. Frage: Nicht jeder soll und hat Zugriff auf Exchange. Ich habe bisher die Verteilung in diesen Sicherheitsgruppen selbst vorgenommen über ECP. Reicht es aus, wenn Benutzer über die Anwendung Active Directory Benutzer und Computer den Gruppen hinzugefügt wird? Die Gruppen haben ja bereits alle Exchange Elemente aktiviert insofern gehe ich davon aus das dies reicht. Im Test war es jedenfalls kein Problem aber es könnte sein, dass es hier einen Exchange Experten gibt, der sagt, aus Grund XY kann oder sollte man das nicht machen. Schönen Start in diesen verregneten Tag. Jimmyone

Ja ganz sicher.

Nein, es war meine Aussage. Da es auch meine Umgebung ist, kann ich sicher sagen, dass kein Cache Mode aktiviert ist. Das ist eine 100% sichere Sache. ;)

...ja ist im eigenen Kalender. ;)

Hi, die Version des Exchange lautet: Version 15.1 ‎(Build 1261.35) Der Cache Modus ist deaktiviert weil das eine Vorgabe ist. Argumente für Cache Modus wurden abgeschmettert. Ist mir aber auch egal und für das "spannende" Problem nicht weiter relevant. :) ;) Seltsam finde ich das der Full Client einen Termin meldet aber OWA nicht. "Kennen" also von schon mal gesehen könnte ich das nur andersrum bestätigen. War auch mein Ansatz. Hier gehen leider Realität und so sollte das sein auseinander. Danke für den Tipp bezgl. mfcmapi. Es war Sonntag und ich auf einem Weihnachtsmarkt mit den langweilisgten Menschen die es gibt. :cry: Da habe ich einfach behauptet ich muss mal arbeiten. :p :D :rolleyes: Sorry ich weiß das jede Info von Wert ist die man kriegen kann. Jimmyone

Hallo Zusammnen, in der Umgebung gibt es keinen Cache Modus für Exchange, das heißt die Ansicht ist immer Online. Ich werde mich zurück melden, sobald ich weiß wie sich das System verhält wenn man einen Termin einsetzt. Mir fällt gerade auf, dass ich gestern den wichtigen Hinweis unterschlagen habe, dass es sich bei dem Benutzer um ein Migriertes Postfach handelt, welches von IBM Domino übertragen wurde. Jedoch gab es keinen besonderen Fehler für dieses Postfach. Ist denn der Zugriff auf Inhalte grundsätzlich unterschiedlich zwischen OWA und Outlook? Grüße Jimmyone

Nein. Ein Benutzerpostfach.

Die Anzeige funktioniert auf jedem Client. Nur nicht in owa. Exchange ist auf CU7 Outlook kann ich nicht auswendig sagen zur Zeit. Aber recht aktuell. Wird per WSUS versorgt. Lg Jimmyone

Hallo Zusammen, ich hab hier einen Exchange 2016 in Verbindung mit Outlook 2013. Der Fullclient zeigt einen Termin an. Owa nicht. Dabei ist es egal von welchem Fullclient das Postfach geöffnet wird. Bei dem Termin handelt es sich um einen Serientermin. Hat da jemand ggf. einen Tipp? Pst Files gibt es nicht. jimmyone

Huhu. Ja ich bin mit dieser Idee schon gekommen. Auch mit der Idee könnte ja auch nur das File verschlüsseln mit Boardmitteln. Wohl wissend, dass immer eine unverschlüsselte Variante im RAM liegt. Aber es wäre ja ein Kompromiss aus Usability und Datenschutz. Das wurde alles abgelehnt. Es heißt: "Diesen Methoden kann man nicht vertrauen, da sie von Microsoft stammen und damit der Kontrolle der US Behörden unterliegen, die MS zwingen könnten, Zugriff auf die Daten möglich zu machen." Laut DS wäre die einzige akzeptable Möglichkeit ein TrueCrypt Container. Am Ende ist es Sache der Geschäftsleitung das zu entscheiden, jedoch kann mir schon bildlich vorstellen was das auslöst. Ich meine Erfahrungen zeigen doch, da werdet ihr sicher zustimmen. Was zu schwer für Benutzer umzusetzen ist, wird irgendwie umgangen. Und wenn E-Mails einfach ans private Postfach weitergeleitet werden. Wohl wissend, das dies verboten ist. Das ist wie mit Kennwortrichtlinien die zu streng sind. Kennwörter die sich keiner mehr merken kann, werden aufgeschrieben. Ich fand die Bitlocker Sache oder EFS auf File Ebene einen Kompromiss. Und wenn das File so und so schon von Anfang verschlüsselt wird, gibt es eine doppelte Sicherheit. Da müsste man nur die Frage beantworten, ist diese Sicherheit ein Trugschluss... Aber find mal eine offizielle Quelle dazu. Grüße Jimmyone

Hallo Zusammen, wie geht ihr mit dem Thema .ost Dateien um? Ich suche eigentlich nach einer offiziellen Aussage, dass ost Files verschlüsselt sind. Wenn man dieser Quelle glauben mag, dann ist das so: https://www.msxfaq.de/exchange/clients/unterwegs4.htm Die Frage kommt auf, weil es Datenschutz Bedenken gibt, wenn ein Notebook User sein Gerät mal verliert oder es gestohlen wird. Wenn das File aber tatsächlich "sicher" verschlüsselt ist dann wäre das Thema etwas weniger stressig. Kann da jemand etwas genaueres zu sagen? Ich finde die msxfaq zwar selbst als Quelle ganz gut. Der "Datenschutz" hätte aber gerne eine offizielle Quelle dazu gesehen. Die Antwort auf meine Frage, warum ihm das genau jetzt einfällt, wo die Lösung schon ewig im Einsatz ist poste ich jetzt mal nicht... :cool: :D LG Jimmyone

Habe ja auch nie behauptet, dass dies ein Problem wäre. In einem Satz schrieb ich ja: "Für die Produktive Umgebung kein Problem." ;) Es hat mich nur ein bisschen interessiert was diesen enormen Größenunterschied ausmacht. :) Bzw. warum er doch so enorm ausfällt. Ich hatte selbst damit gerechnet das es größer wird. Aber nicht so groß. ;)