NorbertFe

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

Ist doch auch so, oder wie muss ich das verstehen? Dein RDS Lizenzserver ist 2022 und verteilt 2022 und 2019er RDS CALs. Obwohl er nur 2022 RDS CALs installiert hat. Letzteres ist dann definitiv neu, denn ein 2019er RDS Server hat afaik keine RDS CALs für 2016 rausgerückt, wenn man die nicht auch vorher auf ihm installiert hatte. Und ein 2019er RDS Lizenzserver verteilt afaik auch keine 2022er CALs.

OK, das ist dann aber neu. Ist das bei MS irgendwo dokumentiert?

Weil nur Admins interessante Dinge zu sagen und zeigen haben, oder wie stellt man sich das vor? ;)

Nein, nur kann ein User natürlich im ad nur einen Anmeldenamen haben. smtp domains kannst du sehr viele an einen User vergeben. wenn du das getrennt haben willst, wäre vermutlich ein Hauptpostfach und dann jeweils eine Shared Mailbox für jeden User ein Äquivalent zum Strato Konstrukt.

Ja wir. Aber das Remote Support Gedöhns kenne ich nicht. Aber wenn das ähnlich schlecht ist, wie die normale Desktop Sharing, dann will man das nicht haben. ;) Das wär für unseren Einsatzzweck mit sehr hoher Wahrscheinlichkeit einfach nur überteuert. Und wenn SSO das einzige Feature ist, warum man nicht die Business Lizenz nimmt, dann ist das ein sehr teures Feature. ;) Ich fänds toll, wenn Teamviewer die Option einfach monatlich eingepreist mit im normalen Lizenzmodell mit anbieten würde.