Neue Sicherheitsupdates für Exchange Server (August 2022)

von

Microsoft hat heute neue Sicherheitsupdates für Exchange Server 2013, 2016 und 2019 veröffentlicht. Das Update schließt für Exchange 2019 insgesamt 6 Sicherheitslücken, 3 der Lücken gelten als kritisch.

Hier geht es direkt zu den Downloads der Updates:

  • Exchange Server 2013 CU23
  • Exchange Server 2016 CU22 und CU23
  • Exchange Server 2019 CU11 und CU12

Diese Sicherheitslücken werden geschlossen:

Da es sich um teils kritische Lücken handelt, sollten die Updates zeitnah installiert werden. Exchange Server welche noch nicht auf ein aktuelles CU aktualisiert wurden, müssen zunächst das entsprechende CU erhalten, bevor das August Update installiert werden kann. Die Grafik vom Exchange Team Blog veranschaulicht die Vorgehensweise:

Neue Sicherheitsupdates für Exchange Server (August 2022)
Quelle: Exchange Team Blog

Außerdem empfiehlt Microsoft nach der Installation der August Updates „Windows Extended Protection“ zu aktivieren. Windows Extended Protection ist ein IIS Featuure, welches nun auch von Exchange Server unterstützt wird. Hier findet sich ein Artikel zu Exchange Server und Windows Extended Protection:

Auf der Seite findet sich auch ein Script um Windows Extended Protection für Exchange Server zu aktivieren.

62 Gedanken zu „Neue Sicherheitsupdates für Exchange Server (August 2022)“

  1. Ich erhalte beim aktivieren der Extended Protection folgenden Fehler:

    Das Argument für den Parameter „SiteVDirLocations“ kann nicht überprüft werden. Das Argument ist NULL oder leer, oder ein Element der Argument Auflistung enthält einen NULL Wert. Geben Sie eine Auflistung an, die keine NULL-Werte enthält und führen Sie dann den Befehl erneut aus.

    Zeichen 35 in Exchange-Script

    Exchange 2016 auf Server 2012 – 15.01.2507.013 (Oktober 2022 SU Update auf CU 23)

    Antworten

    • Problem wurde gelöst. Es gab nochmal ein Update vom Script, danach ging es.
      Lag wohl daran, dass man direkt auf das Oktober SU Update gegangen ist und nicht vorher August installiert CU installiert hat. Er hat die KB Nummer gesucht, die logischerweise nicht vorhanden war.

      Antworten

    • Norbert, du bist mein Held. *LIKE*

      Wir haben bei einer einzigen von rd. 30 verteilten und verschiedenen Exchange Installationen (gut die Hälfte mit SSL Offloading mittels pfSense, haproxy, LetsEncrypt und Split DNS) replizierbar seit der Anwendung des Extended Protection Skriptes genau dieses Problem. Serverumgebung dort: Server 2022, Exchange 2019 mit aktuellsten CU und den aktuellen Updates. Das Problem trat ausschließlich Nutzung von Outlook an Clients im Haus auf. Die haben alle Windows 10 und Office 2019 oder 2021.

      Ich hatte die CSS Anleitung im Vorfeld gelesen. Allein: bei allen Clients in genau dieser Umgebung funktionierte die Anbindung des Outlook im Haus nicht mehr. Extern per Outlook Anywhere gibt es keine Probleme. Keine Ahnung woher dieser LSA Parameter je kam (alle Clients im Haus sind erst seit 1 1/2 Jahren oder weniger in Betrieb, wir fassen das nicht an), er stand überall auf 1 und damit treten genau diese Probleme auf. Danke an welchen ext. Dienstleister auch immer.

      Antworten

  3. Wir haben hier auch eine WAF mit Sophos UTM, greifen aber auch intern nur über die externe IP auf den Exchange zu. Nach Aktivieren der Extended Protection keine Anmeldung von Outlook möglich. Stelle ich den DNS wieder auf die interne IP, klappt der Zugriff problemlos. OWA ist davon nicht betroffen, das funktioniert einwandfrei.

    Die Let’s Encrsypt Zertifikate sind auf der Sophos und dem Exchange Server identisch. Ich vermute, dass man in der Sophos UTM genau wie bei der XG eine Ausnahme für HTTPS-Entschlüsselung und HTTPS-Zertifikat-Validierung für den Exchange Server vornehmen muss, habe dazu aber nichts entdeckt.

    Antworten

    • Korrektur….nach Check der Zertifikate (waren doch nicht identisch) funktioniert und der interne Zugriff. Aber Outlook von extern geht nicht (Aufforderung Kennworteingabe)

      Ich bin nun mit meinem Latein am Ende und habe wieder den Rollback gemacht.

      Mal schauen ob bald neue Infos kommen.

      Antworten

      • Hallo Zusammen,
        wir haben einen Ex2016cu23 und davor opnsense mit HAproxy. Wir sind uns ebenfalls unsicher, ob wir das Augustupdate tatsächlich einspielen sollen. Hat jemand in dieser Konstellation aktuelle Infos?
        Ich würde noch etwas warten bis die Erfahrungswerte mit dem Augustupdate gereift sind. Aber wie kritisch sind die Schwachstellen einzuschätzen. Kann man noch warten? Nur ActiveSync ist zu erreichen.

        MfG

        Antworten

        • Die Installation an sich ist ja erstmal sinnvoll und „ungefährlich“. ;) Ob man dann Extended Protection einschalten kann, hängt eben von der eigenen Umgebung ab. Und ob die Security Löcher „kritisch“ sind, kannst du doch selbst nachschauen. Ob das dann deiner Vorstellung entspricht, kann dir ja sowieso keiner sagen.

  4. Ich habe in unserer QS Umgebung (Exchange 2016 CU23, 2 Systeme über DAG) das Security Update 2022-08 installiert. Auf beiden Systemen ist ein Zertifikat unserer internen PKI installiert. Die Systeme werden über Kemp VLM’s veröffentlicht. Nachdem ich SSLOffloading über Set-OutlookAnywhere auf beiden Systemen deaktiviert habe, lief das Script für Extended Protection ohne Fehler durch.

    Von extern funktioniert alles (OWA, EWS, ActiveSync) bis auf Outlook Vollclient (getestet mit Outlook 2016, MAPI over HTTPS, RCP over HTTPS). Bei aktivierter Extended Protection hat sich Outlook direkt getrennt. Bei Neustart wird nach Kennwort gefragt, was aber nicht genommen wird. Neues Profil einrichten klappt bis zum Autodiscover, danach scheitert der Verbindungsaufbau. Nach dem ich Extended Protection mit Script wieder ausgeschaltet und SSLOffloading wieder aktiviert habe, hat sich Outlook wieder sofort verbunden.

    Da wir dieses Szenario bei allen unseren Kunden einsetzen, ist ein Schließen der Sicherheitslücke vorerst nicht möglich. Ich stehe mit unserem Kemp-Support in Kontakt, aber dort weiß man leider auch noch nichts näheres. Ich bin wirklich gespannt, was Microsoft in den nächsten Tagen vom Stapel lässt … so kann es jedenfalls nicht bleiben :( …

    Antworten

    • Setzt ihr wirklich offloading oder eher bridging ein? Bei letzterem muss das bridging mit dem selben Zertifikat erfolgen. Also kemp selbes Zertifikat wie die exchangeserver.
      Offloading braucht man auch nicht „aktivieren“, denn die meisten nutzen das sowieso nicht. Oder greift ihr hinter dem loadbalancer per http zu?

      Antworten

      • Ja, du hast recht. Eigentlich ist es SSL Bridging. Da wir aber tonnenweise Kunden dahinter veröffentlichen, die alle Zertifikate aus unserer internen PKI nutzen, ist es quasi unmöglich (oder erfordert einen riesigen Aufwand und Kosten), hier jeweils eigene Zertifikate zu beschaffen. Auf dem Kemp kommt ein Wildcard-Zertifikat zum Einsatz.

        Antworten

  6. Hab auf unseren 2016er Exchange Servern das aktuelle Sicherheitsupdate installiert und Extended Protection aktiviert.
    Outlook-Clients und der Mailabruf über die iOS-Mail App funktionieren. OWA funktioniert problemlos über Desktopclients, scheitert aber beim Zugriff z. B. über iPhone/iPad. Obowohl die gleiche URL aufgerufen wird. Jemand eine Idee?

    Antworten

    • Hi Marv,
      ich habe hier das gleiche Problem.
      Der Workaround ist aktuell der, dass ich Extended Protection für „OWA“ deaktiviert habe. So funktioniert es.
      Hast du eine Lösung gefunden?

      Antworten

  7. To enable Extended Protection on Exchange Server 2013, ensure you do not have any Public Folders on Exchange Server 2013. If you have coexistence of Exchange Server 2013 with Exchange Server 2016 or Exchange Server 2019, you must migrate your Public Folders to 2016 or 2019 before enabling Extended Protection. After enabling Extended Protection, if there are Public Folders on Exchange 2013, they will no longer appear to end users
    https://microsoft.github.io/CSS-Exchange/Security/Extended-Protection/

    :))

    Antworten

  8. Hallo zusammen,

    ich habe heute die WEP auf einem Ex2019 aktiviert. Outlook extern + intern. OWA. Läuft.

    Der Server sitzt hinter eine Palo mit aktivierter SSL inbound Inspection. OWA wird über DUO Security (MFA) zusätzlich „geschützt“. Spam/Antivirus über Exchange Server Toolbox von JAM.

    Grüße

    Diners

    Antworten

  9. Hallo,

    ich habe gestern auf einem Exchange 2016 CU23, mit Sophos UTM davor und der eingeschalteten WAF, sowie GData Virenscanner, das ganze durchgeführt.
    Ich musste noch diverse Anpassungen u.A. zu TLS vornehmen (Registry Einträge nach KB Artikeln), damit der Healthcheck weitestgehend sauber ist. Die verbleibenden Fehler werde ich mir im laufe der Woche ansehen (Habe noch SMBv1 Fehlermeldungen drin). Die für den Patch notwendigen Fixes sind nun aber aktiv, zumindest war das einschalten des Extended Protection Modes relativ Störungsfrei. Virenscanner und Outlook haben keine Probleme gemacht. Wie immer wurde für den Patch-Moment der Virenscanner abgeschaltet. Das Einschalten des Extended Protection Modes wurde beim eingeschalteten Virenscanner durchgeführt.

    Ich habe diverse Healthchecks durchgeführt um nach jeder Änderung und den damit verbundenen Reboots (HKLM Einträge) zu prüfen.
    Einige Fehler bzgl. der Netzwerkkarte, Powermode usw. die noch vorhanden waren hab ich dann gleich mit behoben.
    Mit allen Reboots, Recherchen und Behebungen, habe ich die Systeme nach 4h wieder freigegeben. Die reine Installation des Patches war nach 15min abgeschlossen (NVME Storage).
    Das Aktivieren zum Extended Protection, hat sich etwas hinausgezögert, da ich mich auch erstmal etwas einlesen musste. Schlussendlich kommt man aber nicht drum herum und muss ggf. noch TLS 1.0 und TLS 1.1 für Client und Server per Registry abschalten. Man wird über den Healthcheck aber an die meisten Artikel herangeführt (Links folgen). Das funktioniert auch Problemlos, Einträge müssen aber ggf. von Hand ergänzt werden (waren bei uns nicht vorhanden). Hinterher wird dann aber alles als „grün“ angezeigt. Was es so für Auswirkungen hat werde ich erst ab Montag mitbekommen.
    Alle Tests bzgl. OWA und Outlook waren aber aktuell reibungslos und erfolgreich.
    Oben war bereits die Frage nach einem Healthcheck nach der Installation, aber da war nur eine entscheidende Meldung zum Patch vorhanden, dass der Extended Protection Mode nicht aktiviert war. Daraus resultierten dann weitere Maßnahmen. Ist aber alle kein Hexenwerk.

    Wenn die Möglichkeit besteht, Snapshot des Servers machen, Protection Mode einschalten, Auswirkung angucken, notfalls rolle Rückwärts. Würde ich bei nur einem Server nicht im laufenden Betrieb machen, habe es Freitag Abend/Nacht durchgeführt.
    (Windows TS v1607, Office 2016, Citrix 1912 LTSR, GData)

    LG

    Antworten

  10. Hatte wie mein Vorredner auch das Problem, dass nach der Aktivierung der Extended Protection beim Start des Outlook Clients (Office 365 Variante) nach dem Kennwort gefragt wird.

    Im Security Eventlog auf dem Exchange Server findet man folgendes:
    An account failed to log on.

    Subject:
    Security ID: NULL SID
    Account Name: –
    Account Domain: –
    Logon ID: 0x0

    Logon Type: 3

    Account For Which Logon Failed:
    Security ID: NULL SID
    Account Name:
    Account Domain:

    Failure Information:
    Failure Reason: An Error occured during Logon.
    Status: 0xC000035B
    Sub Status: 0x0

    Konnte in meiner Umgebung das Problem dadurch lösen, indem ich die Adresse vom Mailserver, beim Antivirenprogramm (Kaspersky) zu den Ausnahmen hinzugefügt habe.
    Denn ich denke der Fehler wird durch die SSL-Terminierung beim AV-Programm verursacht, wobei verschlüsselte Netzwerkverkehr ja vom Antivirenprogramm per Man in Middle untersucht wird.

    Nun klappt alles wieder trotz aktivierter Extended Protection.

    Der Zugriff über OWA funktioniert übrigens auch ohne dieser Ausnahme…

    Weiß nicht, ob sich das mit Programmen andere Antiviren-Hersteller gleich verhält.

    Antworten

    • Danke Wolfgang. Das ist ein interessanter Ansatz. Bei allen 3 Servern/Clients ist Kaspersky installiert…..ich prüfe es und berichte dann……wäre super, wenn das mein Problem wäre…

      Antworten

    • Hallo Wolfgang, hier mit ESET Endpoint Protection das gleiche Problem. Mit aktivierter SSL/TLS-Analyse in der Endpoint Security erscheinen im Outlook 2016 bzw. beim Mailsetup in der Systemsteuerung ab und zu Anmeldedialoge. Die Dialoge verschwinden, wenn man in der Endpoint Protection die SSL/TLS-Analyse ausschaltet. Leider habe ich in der ESET Endpoint Protection die Stelle noch nicht gefunden, wo man HTTPS-URLs von der Analyse ausnehmen kann – aber eine Anfrage an ESET ist bereits ´raus.

      Gruß, Jörg

      Antworten

      • Hallo, der ESET-Support hat geantwortet. Leider ist es bei der ESET Endpoint Security nicht möglich, eine URL als Ausnahme für die Untersuchung von verschlüsseltem Verkehr einzutragen. Man kann nur eintragen, dass der Verkehr von HTTPS-Adressen mit bestimmten Zertifikaten nicht untersucht wird – also nur ein Zertifikat als Ausnahme eintragen. Ich habe dies getestet – funktioniert tatsächlich. Das ist leider bei Servern, die Lets Encrypt Zertifikate nutzen, die alle 3 Monate ablaufen, etwas pflegeaufwändig. Also bleibt hier als einfacher Weg nur die Abschaltung der SSL/TLS Protokollfilterung. Die Filterung findet sich in der Endpoint Security in der Policy-Einstellung „Web und Mail“ – hier bei SSL/TLS die SSL/TLS Protokollfilterung ausschalten oder ggf. bei der „Liste bekannter Zertifikate“ das Zertifikat eintragen.

        Bei Kaspersky Endpoint Security ist es möglich, eine URL als Ausnahme einzutragen. Die Einstellungen findet man unter „Allgemeine Einstellungen“, „Netzwerkeinstellungen“, „Untersuchung verschlüsselter Verbindungen“, „Vertrauenswürdige Adressen“. Dort habe ich die URL des Exchange-Servers mit allen Subdomains eingetragen, also z.B. *.meinexchange.de .

        Gruß, Jörg

        Antworten

  11. Problem nach Aktivierung von Extended Protection:
    ich habe an 3 unterschiedlichen Exchange Servern (2 x 2019 + 1 x 2016) das gleiche Problem nach der Aktivierung der extended protection:
    die internen Clients können sich nicht mehr am Exchange anmelden. Es kommt immer und immer wieder die Kennwortabfrage…wenn ich die EP wieder rückgängig mache, geht wieder alles. Bin ratlos und hoffe auf Hilfe, bzw. das ein anderer das Problem auch hatte und es gelöst hat. Danke.

    Antworten

  12. Muss der Exchange Server (bei mir 2013) nach der Installation neu gestartet werden oder ist der Mailfluss bei der Installation gestört?
    Sprich, gibt es Down-Zeiten für den Exchange Server?

    Antworten

    • Ich habe es mit diesem Patch jetzt noch nicht probiert (installiere den heute abend), aber bisher war es bei uns (Exchange 2019) immer so, dass er während der Installation die Exchange Dienste gestoppt hat und auch anschließend einen Reboot wollte. Somit würde ich auf jeden Fall mit einer Downtime rechnen, daher muss ich das bei uns auch immer außerhalb der regulären Arbeitszeit machen.

      Antworten

    • Jo der Stopp die Dienste und eine Reboot ist nach einem Update immer empfehlenswert.
      Hat bei mir Pro 2013 Exchange (DAG) ca 10 Minuten gedauert, ohne Windows Extended Protection.
      Das kommt nächste Woche bei uns

      Antworten

    • Natürlich gibts Down-Times für den Exchange. Der muss ja seine Dienste für das Installieren des Patches beenden. Dauert ca. 20min je nach Hardware usw.

      Antworten

      • Bei mir waren es ca. 1h mit Extended Protection aktivierung. Ist zwar auch NVME SSDs aber auch sehr groß die Kiste. Die meiste Zeit hat gleich am Anfang, das „scannen“ nach dem Speicherplatz gedauert.

        Antworten

  13. EX2016 CU23 mit Sophos UTM WOF
    SSL wildcard Zerti
    Update lief ohne Probleme durch.
    Windows Extended Protection: on (per script)
    Ohne Probleme.
    Alles mal getestet
    Morgen noch mal beobachten, aber schaut recht gut aus.

    Antworten

  14. Hallo zusammen,

    wir haben einen Exchange 2013 mit Öffentlichen Ordnern. Laut der Liste von Windows Extended Protection werden diese dann nicht mehr angezeigt.

    Beutetet nun das ich entweder meine Öffentlichen Ordner löschen muss oder ich bin unsicher? Was ist das denn für eine Logik? Warum macht man sowas?

    Ich bin ganz für sichere Systeme aber eine Funktion damit zu Streichen find ich schon ein wenig übertrieben. Ich spiele nun erst mal nur die Pachtes ein.
    Ich hoffe da kommt noch was von MS. Sonst wird hier ganz schön im Regen stehen gelassen.

    Antworten

    • Naja, Exchange 2013 ist inzwischen 10 Jahre alt und damals hat man evtl. architektonisch was „gebastelt“, was jetzt der Nutzung dieser Funktion (öffentliche Ordner) im Wege steht. Da Exchange 2013 sowieso nicht mehr lange supported ist, kannst du dir langsam Gedanken machen, was du ab 11.April 2023 einsetzen willst. Exchange 2016/2019 mit öffentlichen Ordnern oder ohne. ;)

      Antworten

  15. Habe mir nochmal jedes CVE durchgelesen und bei 5 von 6 steht -> EP ist zusätzlich notwendig…

    Heißt man wird nicht drum herum kommen, aber bislang noch keine Meldungen gelesen ob es auch wirklich alles klappt.

    Antworten

  16. Hallo zusammen,

    also das mit der Extended Protection ist ziemlich undurchsichtig. Scheint ja diverse Probleme zu verursachen
    wenn man das „mal schnell“ aktiviert.

    Wir sitzen z.b. auch hinter einer WAF mit Sophos UTM.
    Wäre super wenn da jemand mehr Infos hätte was das für Auswirkungen hat bzw. was zu beachten ist.

    Und der Health Checker spuckt bei mir jetzt zusätzlich auch Meldungen von wegen nicht signierten IIS Modulen aus.
    Hat das noch jemand? Online finde ich dazu gar nichts.

    VG!

    Antworten

    • Hallo
      Ich habe es gerade gemacht, Sophos XG mit WAF, Waf hat let encrypt wildcard Zerti.
      Bis jetzt keine Probleme.
      OWA von aussen OK.
      Activce Sync von aussen OK
      System: Ex 2019 mit Server 2022

      So schaut das aus wenn man das Script aufruft, es meldet auch wenn etwas fehlt

      [PS]xxxxxx>.\ExchangeExtendedProtectionManagement.ps1
      Version 22.08.09.1227

      Enabling Extended Protection
      Extended Protection is recommended to be enabled for security reasons. Known Issues: Following scenarios will not work
      when Extended Protection is enabled.
      – SSL offloading or SSL termination via Layer 7 load balancing.
      – Automated Archiving using Archive policy
      – Exchange Hybrid Features if using Modern Hybrid.
      – Access to Public folders on Exchange 2013 Servers. You can find more information on: https://aka.ms/ExchangeEPDoc. Do you want to proceed? [J] Ja [A] Ja, alle [N] Nein [K] Nein, keine [H] Anhalten [?] Hilfe (Standard ist „J“): j The following servers have the TLS Configuration below ALEX01 TLSVersion ServerEnabled ServerDbD ClientEnabled ClientDbD TLSConfiguration ———- ————- ——— ————- ——— —————- 1.0 0 1 0 1 Disabled 1.1 0 1 0 1 Disabled 1.2 1 0 1 0 Enabled

      NetVersion SystemTlsVersions WowSystemTlsVersions SchUseStrongCrypto WowSchUseStrongCrypto ———- —————– ——————– —————— ——————— v2.0.50727 v4.0.30319 1 1 1 1
      TLS prerequisites check successfully passed!

      WARNUNG: ‚ALEX01\RPC (Default Web Site)‘ has SSLOffloading set to true. Therefore we can’t configure Extended
      Protection.
      Please run the following to fix: Set-OutlookAnywhere -Identity ‚ALEX01\RPC (Default Web Site)‘ -SSLOffloading $false -InternalClientsRequireSsl $true -ExternalClientsRequireSsl $true
      Recommended to do this for all your servers in the environment so they are on the same configuration.
      Do you have feedback regarding the script? Please email ExToolsFeedback@microsoft.com.
      [PS] C:xxxxxxxxxxxxxxx\Downloads>Set-OutlookAnywhere -Identity ‚ALEX01\RPC (Default Web Site)‘ -SSLOffloading $false -InternalClientsRequireSsl $true -ExternalClientsRequireSsl $true
      [PS] C:\Usexxxxxxxxxx\Downloads>.\ExchangeExtendedProtectionManagement.ps1
      Version 22.08.09.1227

      Enabling Extended Protection
      Extended Protection is recommended to be enabled for security reasons. Known Issues: Following scenarios will not work
      when Extended Protection is enabled.
      – SSL offloading or SSL termination via Layer 7 load balancing.
      – Automated Archiving using Archive policy
      – Exchange Hybrid Features if using Modern Hybrid.
      – Access to Public folders on Exchange 2013 Servers. You can find more information on: https://aka.ms/ExchangeEPDoc. Do you want to proceed? [J] Ja [A] Ja, alle [N] Nein [K] Nein, keine [H] Anhalten [?] Hilfe (Standard ist „J“): j The following servers have the TLS Configuration below ALEX01

      TLSVersion ServerEnabled ServerDbD ClientEnabled ClientDbD TLSConfiguration
      ———- ————- ——— ————- ——— —————-
      1.0 0 1 0 1 Disabled
      1.1 0 1 0 1 Disabled
      1.2 1 0 1 0 Enabled

      NetVersion SystemTlsVersions WowSystemTlsVersions SchUseStrongCrypto WowSchUseStrongCrypto
      ———- —————– ——————– —————— ———————
      v2.0.50727
      v4.0.30319 1 1 1 1

      TLS prerequisites check successfully passed!

      An update has occurred to the application host config file for server ALEX01. Backing up the application host config file and updating it.
      Successful backup of the application host config file to C:\Windows\System32\inetsrv\config\applicationHost.cep.20220810220815.bak
      Successfully backed up and saved new application host config file.
      Successfully updated all of the following servers for extended protection: ALEX01
      Do you have feedback regarding the script? Please email ExToolsFeedback@microsoft.com.

      Antworten

      • Danke dir. Hat bei mir auch soweit alles funktioniert.
        Ich musste zusätzlich in der XG noch eine Ausnahme für HTTPS-Entschlüsselung und HTTPS-Zertifikat-Validierung für unseren internen Exchange DNS Namen setzen. Ansonsten kam auf den Clients die Passwort Abfrage in Outlook + OWA. Auf den Servern mit DPI ging es komischerweise auch ohne die Ausnahme. Eventuell weil die Clients wpad / Proxy nutzen.

        Antworten

  19. Da man hier öfter von Extended Protection lass ich liegen ließt:
    Leute, der Patch bringt die Funktionalität für Windows Extended Protection und diese muss zwingend aktiviert werden damit ihr die Schwachstellen zu macht! Der Patch ohne EP bringt 0,0! Wer die Voraussetzungen erfüllt steht wohl dann derzeit alleinig geschützt da.

    Antworten

    • Ist das sicher und kann jemand bestätigen? Ich lese das nämlich für meinen Teil nicht raus und heißt der Patch reicht aus..Eventuell das Powershell Skript zum überprüfen danach mal laufen lassen?

      Weil ganz ehrlich ich wollte auch noch nicht die EP aktivieren, wenn solche Meldungen auftauchen: Users cannot access their mailbox through one or more clients

      Antworten

        • Genau, dort schreibt er ja auch, dass nicht alle CVEs, die mit dem Patch behoben werden, die EP benötigen (deswegen soll man das Update auch auf Edge Servern anwenden, bei denen gibt es kein EP.

          Ich werde mich da auch erst mal tiefer einlesen müssen, bevor ich das aktiviere, da wir vor unserem Exchange eine Sophos UTM mit WAF stehen haben für die Zugriffe vom Handy und OWA von extern. Und da tappen wir fast sicher in die Falle bezüglich SSL-Bridging.
          Und das letzte was ich brauche ist eine GL und ein Vertrieb, die keine Mails mehr aufs Handy bekommen.

        • 5 von 6 gefixten Bugs benötigen die Aktivierung der EP. Also sollte man sich das nicht monatelange überlegen, ob man die aktiviert oder nicht. Andererseits sind gerade die Themen SSL Offloading/Bridging Themen, die vor allem daran hindern, das zeitnah umzusetzen. Viele nutzen eben extern über den Loadbalancer Lets-Encrypt und intern dann eigene Zertifikate. Das scheitert aber dann mit der EP. Also muss man auf allen Devices die beteiligt sind am SSL Bridging dasselbe Zertifikat verwenden. Wer kein Let’s Encrypt verwendet wäre hier eindeutig im Vorteil:
          „SSL Bridging supported scenarios
          Extended Protection is supported in environments that use SSL Bridging under certain conditions. To enable Extended Protection in your Exchange environment using SSL Bridging, you must use the same SSL certificate on Exchange and your Load Balancers. If not this will cause Extended Protection to fail.“

  20. Dasselbe hier. div. Exchange 2013-2019 ohne Probleme. Extended-Protection lass ich lieber noch ein paar Monate im Microsoft Weinkeller des Blödsinns reifen :) :)

    Antworten

  21. Update Exchange 2013 – 2016 – 2019 bei diversen Kunden durchgeführt. Keine Probleme meistens nach 10 Minuten erledigt.
    Das mit der Extended-Protection schaue ich mir erst mal genau an…
    Gut das ich mir über die Blackhat USA immer selbst schon eine Urlaubssperre gebe :)

    Antworten

  23. Habe ich was verpasst, was ist der 2022 H1 CU ? Ist der neuer als der CU23 ?
    Kann man nach der Installation des SUs von HEUTE auf CU22 nachträglich(!!) noch den CU23 installieren, oder sollte man den 2022 H1 nehmen ?
    Also: CU22 (Exch 2016) und SU von heute -> dann CU23 + nochmal den SU von heute, aber nun für CU23 – geht das?

    Antworten

  24. Ich verstehe nicht warum die ungetestete Patches auf die Menschheit loslassen:

    https://microsoft.github.io/CSS-Exchange/Security/Extended-Protection/

    Known issues and workarounds

    Customers using a Retention Policy containing Retention Tags which perform Move to Archive actions should not configure Extended Protection, as enabling Extended Protection will cause automated archiving to stop working. We are actively working to resolve this issue.

    Somit brauchen wir das erst gar nicht mal probieren, denn genau das haben wir bei uns onpremise

    Antworten

Schreibe einen Kommentar