NorbertFe

Das ist MS aber am Ende egal. Ich weiß genau was du meinst, aber das betrifft Kunden, die sowieso nicht wissen was ein OS ist. Alle anderen haben ja ansonsten schon die Möglichkeiten es zu steuern.

Ach was. ;) Finde ich ja grundsätzlich auch, nur inzwischen sollte man es doch auch begriffen haben, was das Ziel bei MS ist. Und das sind nicht die legacy Technologien.

Kein WSUS kein Mitleid, oder wie ging das? ;)

Das löst aber nicht das eigentliche Problem. Also wirds vermutlich eine andere Download Version als man eigentlich gekauft hat gegeben haben. ;)

So, hab mal nachgeschaut. SPAMHAUS-ZEN Barracuda Reputation Block List inps.de DNS Blacklist WPBL - Weighted Private Block List GBUdb.com Truncate Mailspike by AnubisNetworks (Combined) Wirklich relevant sind aber nur die beiden ersten, so nach einem groben Überblick in der Statistik. ;)

Hmm, aber wenns dann doch funktioniert? ;)

hmm. Wäre aber interessant, was da jetzt eine Lösung gewesen sein soll. ;)

Kann ich morgen gern hier posten. Aber exo hat soviele ip Adressen, da ist es recht wahrscheinlich, dass regelmäßig mal welche drauf und wieder runter sind. ;) Ich kann diesbezüglich aber mit exo keine besonderen Probleme bei mir erkennen.

Ich nicht, deswegen benutze ich die nicht mehr. Viel zu viele False positives. Und welche noch? Sind da dieselben IPs in anderen Listen? ;)

Achja stimmt. Das gibt rein technisch eigentlich auch kein RFC her. Ich vermute aber, dass das früher oder später kommen wird. Allerdings führt das im Normalfall auch nur dazu, dass die Spammer einfach entsprechend konfigurierte Domains verwenden werden und das als "Authentizitätsprüfung" am Ende auch nichts mehr aussagen wird.

Ja, das stimmt, aber auf halbwegs vernünftigen RBLs landet auch eher seltener solche Systeme. Ich überleg grad, aber mein Spamfilter hat aktuell noch keine Option Mails ohne SPF und ohne DKIM abzulehnen. Wie nennt sich bei euch denn das?

Welche Blacklists nimmst du denn? Ich hab da eigentlich kaum verstärkt Probleme mit ExO festgestellt. Aber ja, je größer der Absender, umso mehr kann er ja auftrumpfen. :/ Ist leider so.

Liest du die Fehlermeldungen auch? Target host responded with error. -> 554 IP=MX-IP - Dialup/transient IP not allowed. Use a mailgateway or contact toda@rx.t-online.de if obsolete. (DIAL)' Wie deutlich solls dir denn der T-Online Postmaster noch mitteilen? ;)

Automapping funktioniert auch mit ausgeblendeten Mailboxen soweit mir bekannt. Aber unabhängig davon hat das ja nichts mit deinem Problem zu tun. Wo befinden sich denn die User? Auch on-premises oder sind die in der Cloud?

Vorher readme lesen ;) Das kann man ggf. auch nachlesen: https://learn.microsoft.com/de-de/exchange/plan-and-deploy/post-installation-tasks/security-best-practices/exchange-extended-protection?view=exchserver-2019#prerequisites-for-enabling-extended-protection-on-exchange-server

War vorher schon die Extended Protection konfiguriert? Falls nein, dann wird da die Ursache zu suchen sein. (Abschalten der Extended Protection wird das Problem auf Kosten der Sicherheit erstmal lösen, aber keine Dauerhafte Lösung darstellen).

Nein. Wie soll das gehen? Wenn das installierbare Applikationen sind, wirst du die wohl neu auf dem neuen TS installieren müssen. Du kannst auf einer TS Session nicht ein Word 2016 starten, welches auf einem anderen Server installiert ist. ;)

Im Worst Case mal das auditing anschalten und schauen, woran es scheitert ;)

Schönes Beispiel für meine Frage oben. Und wenn das selbst bei Exchange so ist, dass da Lücken über Monate offen gelassen werden, weil sich keiner drum schert, dann will ich gar nicht wissen, wie das mit Diensten ist, wo das auch noch viel umständlicher oder gar nicht dokumentiert ist. ;)

Naja ein Sessionhost wär schon notwendig, oder? ;)

müßte ich echt mal nachschauen. ich hab das neulich für den AADC konfiguriert und ein install-MSA gabs da gar nicht mehr als befehl oder es gab irgendeinen Fehler (ich schau nachher mal)

Das ist ja auch korrekt so.

Super ;) wer hat eigentlich neben seiner sonstigen Arbeit Zeit, die ganzen CVE usw. zu lesen und ggf. Gegenmaßnahmen umzusetzen? ;) Aber der User sollte also in der Lage gewesen sein, anhand dieser Info klar zu erkennen, dass die Mail eben nicht von euch ist, oder?

Install-ADServiceAccount geht das unter 2019/2022 überhaupt noch? ich bekam da eigentlich immer Fehler. Unter 2016 war das noch notwendig.

Ist das vielleicht wieder so ein Trigger um den NTLM Hash abzugreifen aus Outlook heraus? Denn Outlook wird ja evtl. erstmal zum angegebenen Ort switchen wollen und ggf. die Anmeldedaten rübergeben (wobei es das eigentlich aufgrund der Sicherheitszone eigentlich nicht sollte. Wie sieht in so einem Fall denn der Sender usw. aus? Übrigens hatte ich gestern den Fall, dass der Adobe Sign Account wohl von einem externen Partner übernommen wurde und darüber dann diverse Mails mit Aufforderung rausgegangen sind. Schöne neue Welt, wenn niemand mehr seine Credentials bei den richtigen Services eingeben kann, weil er nicht mal mehr weiß, welches die richtigen Services sind und welche nicht. ;)