NorbertFe

Braucht dann aber Cals. ;)

Muss er ja nicht mal. :(

Ich kenne mindestens eine Umgebung, da wurde die lsass gedumpt.

Ja, hab heute früh noch keine Lust gehabt den link rauszusuchen. ;)

Wäre sinnvoll für sowas eine eigene ca zu nutzen würde ich sagen. Afaik gilt die manuelle Prüfung für alle Zertifikate einer ca, unabhängig von autoenrollment oder nicht.

Was ist denn dein Ziel? Autoenrollment bedeutet, dass man das im allgemeinen auch dem Client per Richtlinie beibringen muss. An der ca muss man dazu normalerweise nichts ändern, wenn man keine manuelle Prüfung drin hat.

Mach mal nen punkt hinter den host. ;)

Die Info steht seit JAHREN bei jedem Security Patch von Exchange dabei. Man müßte die entsprechenden Artikel halt auch mal lesen. ;)

Einfach ne transportrule nutzen. Sollte gehen, hab’s aber nicht getestet.

Das msret ist inzwischen auch hypersensibel und erkennt 2 Schädlinge auch auf einer Neuinstallation ohne jeglichen externen Zugang. Am Ende bekommt man dann trotzdem grünen Haken.

Gut, dann ist das ja auch mal gesagt. 🙃

Rdp ins Internet zu stellen ist fahrlässig. Es gab genügend rdp Lücken in der Vergangenheit. VPN wäre die richtige Lösung, alternativ dann entsprechende Infrastruktur die das per https anbietet.

DAS unterschreibe ich sofort. @autowolf Bitte wieder abschalten, denn das führt nicht dazu, was du dir vorstellst.

Es ist NICHT deine Umgebung und deine Daten und die Verantwortung kann der Kunde auch nicht in dem Maße wegdelegieren. auch wenn viele das glauben (auf beiden Seiten). Und glaub mir, ich kenne sowohl solche Kunden und auch bei größeren Kunden gibts solche Kandidaten, bei denen man sich nur noch an den Kopf fassen will (sollte man nur nicht im Kundengespräch tun) :)

Das würde ich nicht unterschreiben

Ja, aber auch das ist nicht das Problem des Dienstleisters, sondern des Kunden. Habe ich MEHRFACH inklusive PM.

Dsa Problem ist klein, aber du willst ja unbedingt von 0 auf 1 auf irgendwas. :) SP1=CU4 (wie hier schon mitgeteilt wurde) und dann ggf. eben CU23 plus Security Patch (den du hoffentlich gefunden hast). :) Man "könnte" sich dann aber CU4 auch sparen, denn so oder so ist der Sprung ziemlich groß Bei MS braucht man keinen Link suchen. Die supporteten CUs sind einfach auffindbar und die nicht mehr im Support befindlichen, findest du NICHT mehr bei MS. Da kannst du fröhlich oder unfröhlich suchen.

Die hat man auf Platte, braucht sie aber eigentlich nicht. ;)

Das sind Probleme. ;) wie wärs mit „lösch das, welches nicht konfiguriert ist“?

Steht oben. ;) irgendwas mit dem receive connectors hab ich da noch im Hinterkopf. Aber das merkst du dann schon.

Was gibt denn da nicht zu verstehen? Cu23 ist so alt, da werden die nicht noch für cu22-cu10 was nachliefern. ;)

Sieht du ihn da? ROOOOOT markiert. ;) Man müßte halt lesen :)

Dann hier der neue offizielle Stand ;) https://docs.microsoft.com/en-us/Exchange/plan-and-deploy/supportability-matrix?view=exchserver-2019#microsoft-net-framework Liest du die von dir geposteten Links auch? :) https://support.microsoft.com/en-us/topic/description-of-the-security-update-for-microsoft-exchange-server-2019-2016-and-2013-march-2-2021-kb5000871-9800a6bb-0a21-4ee7-b9da-fa85b3e1d23b Runterscrollen bis: How to get and install the update

Ohne das jetzt zu bewerten, aber die Aussage die ich kenne (und ja die kommt noch aus 2010er Zeiten), ist: Stelle keine Firewall zwischen Exchangeserver und keine zwischen DomainController und Exchange bzw. wenn dann darf kein Traffic geändert oder geblockt werden. Und wenn man das "annimmt", dann ist es ganz einfach. Du kommst mit den Client Ports zum CAS (https, IMAP, IMAPs, POP3, POP3s und SMTP 25, 587) alles andere passiert dann "in einer Blackbox" firewalltechnisch gesehen. Deswegen stehen die Exchangeserver und dazugehörige DCs eigentlich auch getrennt vom Rest. Das betrifft dann deine Replikationsports (DAG, Kerberos usw.). Man kann sich jetzt natürlich hinsetzen und das mitschneiden und hoffen, dass man es hinbekommt, aber das hilft dir halt immer nur bis zum nächsten Problem. Meine Empfehlung wäre also, schotte lieber die Exchangeumgebung vom Rest ab als die Exchangekommunikation zwischen Exchange und beteiligten Systemen zu restriktieren. Das hilft am Ende dann sowieso nicht wirklich weiter. Solltest du es hinbekommen, dann Glückwunsch. :)

Ist der schon übernommen?