NorbertFe

Da ich die Fehler nicht auswendig kenne und selbst recherchieren müßte, wäre es schon von Vorteil, wenn du die komplette Fehlermeldung hier als Code reinkopieren könntest. Aber ich vermute mal, dass das Zertifikat entweder den im EHLO eingetragenen Namen eben nicht enthält (Tippfehler), oder nicht an den SMTP Service gebunden wurde. Bye Norbert

Ich vermute, du erwartest das, was ich dir oben schon erklärt habe, hier nicht geben zu können: Da ich deine grundsätzliche Konfiguration nicht kenne, wird das etwas schwierig, sowas im Forum als Schritt für Schritt Anleitung hinzuschreiben. Insofern habe ich dir die Werkzeuge an die Hand gegeben, dich mit diesem Problem auseinanderzusetzen: TlsAuthLevel : TlsCertificateName : TlsDomain : UseExternalDNSServersEnabled : False Konfiguriere das mal korrekt (mit validen Zertifikatsdaten) und auf der Gegenseite in Exchange Online mit Zertifikatsvalidierung und schau ob sich was ändert. Wenn du das selbst nicht machen kannst oder willst, wäre es jetzt an der Zeit sich an (s)einen Dienstleister für diese Themen zu wenden um zu schauen, ob das Problem gelöst werden kann. Ich kann dir nicht sagen, ob es dafür eine "vernünftige" Lösung gibt, aber ich gehe stark davon aus. Bye Norbert PS: Da hilft auch kein Siezen. Und wenn du immer nur deine Einzeiler hier postest, ohne mal mitzuarbeiten (zumindest ist das mein Eindruck), dann wird die Hilfe hier auch nicht sonderlich wirksam sein.

Ja, diese Vermutung wurde aber jetzt auch bereits von mir geäußert inklusive dem Vorschlag, den Sendeconnector mal zu bearbeiten. Ansonsten drehen wir uns hier im Kreis.

Ich dachte ich hätte mit den entsprechenden Links in die Hinweise auf die mögliche Lösung deines Problems gegeben. Du wirst also testen müssen, ob die Konfiguration des Sendeconnectors zum Ziel führt. Da ich deine grundsätzliche Konfiguration nicht kenne, wird das etwas schwierig, sowas im Forum als Schritt für Schritt Anleitung hinzuschreiben. Vor allem, weil du ja bspw. die erste meiner Frage noch nicht mal beanwortet hast: Es geht also um OOF Nachrichten die von On-Prem Postfächern an ExO Postfächer gesendet werden oder auch an externe Empfänger gehen? Je nach der Konfiguration und des gewünschten/konfigurierten Mailflows kann es also evtl. unterschiedliche (oder keine sinnvolle) Lösung geben.

Ohne es genau zu wissen oder belegen zu können, bezweifle ich, dass du dieses Attribut ändern kannst, denn es wird mit hoher Wahrscheinlichkeit (siehe die Einleitung) ein constructed attribute sein oder eben read only. Und wenn man "when created" änderbar wäre, dann wär der Zweck dieses Attributes irgendwie hinfällig, oder?

Wieso ist die externe WAN IP im Sendeconnector? Die Links oben geben dir sehr wahrscheinlich die Möglichkeiten vor. Das wird man im Zweifel der Reihe nach durchtesten können/müssen. Ein Sendeconnector hat einen Ziel Adressraum (* oder eben bestimmte Maildomains), damit er für diesen Adressraum verwendet wird (plus die jeweilige Priorität). In deinem Fall ist also nicht der Adressraum das Problem, sondern der Smarthost von MS (EOP), der von dir für die Annahme solcher Mails eben bestimmte Voraussetzungen definiert.

Genau das hat Nils geschrieben: Heißt, wenn man nicht auf die Lifetime der vorhandenen Tickets Rücksicht nehmen kann/will/muss, dann kann man die Änderung im Krisenfall eben auch innerhalb weniger Sekunden ändern (je nach Umgebung mal ein paar mehr). Sieht jetzt nicht wirklich anders aus als meine Aussage: WEnn man nicht ganz viele LDAP Abfragen stellt die bestimmte sonst nicht lesbare Attribute benötigen, kann man das relativ easy abschalten. Ich lass mich aber gern belehren. Es gibt genug Praxisbeispiele, die eben wie deins dann gelten. Das geht nicht nur um das Lesen der Account restrictions, sondern bspw. in sehr viel häufigerem Umfang um das Auslesen von Mitgliedschaften der Nutzer, was eben dann auch nicht mehr funktioniert. Da dann noch abhängig welches der diversen Groupmembership Attribute ausgelesen werden muss usw. usf. Dem Rest deiner Aussage stimme ich natürlich zu, wobei man dann auch das entsprechende Auditing erstmal anschalten darf und vor allem auch auswerten, was je nach Größe und Häufigkeit der Abfragen echt mühsam werden kann. :)

https://learn.microsoft.com/de-de/exchange/troubleshoot/email-delivery/wrong-office-365-region-exo Ich würde sagen, an der Stelle ist der Fehler zu suchen. Für "normale" Mails wird das funktionieren, weil ihr da vermutlich einen SPF Record mit der public IP des On-Prem Servers habt. https://learn.microsoft.com/de-de/Exchange/mail-flow-best-practices/how-to-set-up-a-multifunction-device-or-application-to-send-email-using-microsoft-365-or-office-365?redirectSourcePath=%2farticle%2fhow-to-set-up-a-multifunction-device-or-application-to-send-email-using-office-365-69f58e99-c550-4274-ad18-c805d654b4c4#option-3-configure-a-connector-to-send-emails-using-microsoft-365-or-office-365-smtp-relay

Hallo, Microsoft unterstützt bereits seit längerem die Auswertung von ARC. Beschrieben ist das hier: https://techcommunity.microsoft.com/t5/microsoft-defender-for-office/improving-defense-in-depth-with-trusted-arc-sealers-for/ba-p/3440707 Was aus dem ganzen Text für mich nicht klar wird ist ob das auch für Hybrid Connectoren von Exchange On-Prem Installationen gilt oder ob evtl. die "Erweiterte Filterung" dann nicht aktiviert sein darf, oder ob die in ExO verwendete Domain nicht berücksichtigt wird als ARC trusted sealer. Bisher hab ich zwar unsere Domain als ARC trusted Sealers eingetragen, aber offenbar wird das im Falle von hybrid Connectors ignoriert und stattdessen die SPF Prüfung in der "Erweiterte Filterung für Connectors" durchgeführt. Obwohl eben entsprechend valide ARC-Seal Header Infos vorhanden sind. Hat da evtl. jemand weiterführende Infos oder Kenntnisse, warum das ARC Seal ignoriert wird? Ich seh grad, dass vermutlich das hier zutrifft: https://learn.microsoft.com/en-us/exchange/transport-options Wobei ich mich dann eben frage, warum die Erweiterte Filterung konfiguriert werden muss, damit die "dämliche" SPF Prüfung überhaupt funktioniert, die man ja afaik nicht abschalten kann an der Stelle. Denn dann würde ich eben erwarten, dass alle Mails über diesen Connector als "internal" behandelt werden. Danke Norbert

Es geht also um OOF Nachrichten die von On-Prem Postfächern an ExO Postfächer gesendet werden oder auch an externe Empfänger gehen? Ich vermute mal ein Problem von O365 mit dem empty sender einer OOF. Wie ist denn dein HybridConnector konfiguriert? Kannst du da mal ein get-sendconnector | fl hier posten (ggf. anonymisiert)?

Egal, aber die adressrichtlinie kann afair nur Domains enthalten die es auch als akzeptierte Domain gibt.

Ja korrekt. Der sollte wie MS auch verlinkt auf 5 gesetzt werden (Send NTLMv2 response only. Refuse LM & NTLM) Interessant, wie man so ein vergniesgnatteltes Exchange System betreibt und sich dann jetzt per PingCastle langsam vortastet. ;)

https://learn.microsoft.com/de-de/exchange/plan-and-deploy/post-installation-tasks/security-best-practices/exchange-extended-protection?view=exchserver-2019#ntlm-version-requirements Dein Screenshot zeigt aber was anderes. Siehe oben (HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa LmCompatibilityLevel)

Wenn du nicht noch mit XP unterwegs sein solltest, ist eigentlich TLS 1.2 bei allen Clients seit Windows 8.1 (afair) per default aktiv. NTLM hab ich doch oben gesagt, dass du das zwingend benötigst, damit EP mit Exchange funktioniert. Da ich die üblichen PS-Skripte nicht kenne, die du da nutzt, kann ich dazu nix sagen. Aber ansonsten, wenn du es abschaltest melden sich deine User recht schnell ;)

Ach hör doch auf Natürlich auch die brauchen mal Feierabend.

Ja, aber ich ging dabei davon aus, dass üblicherweise eine Arbeitszeit von 8h in Deutschland gilt. ;) Ansonsten hast du natürlich Recht. Aber auch von 2012 aus ist es im Allgemeinen "eher unkritisch". Oder an welcher STelle ist dir das mal auf die Füße gefallen.

Dann musst du es manuell aktivieren: https://microsoft.github.io/CSS-Exchange/Security/ExchangeExtendedProtectionManagement/ Hätte dir das HealthCheckerscript auch verraten.

Wenn du Exchange 2019 mit CU14 betreibst, wurde es normalerweise selbständig aktiviert. Wenn du nachschauen willst: https://microsoft.github.io/CSS-Exchange/Diagnostics/HealthChecker/ ADFS hat da auch ein paar Probleme, soweit ich mich erinnere. Muss mal nachschauen. edit: Ja korrekt mein Group Managed Service Account für die ADFS Farm hat auch die erwähnte Gruppenmitgliedschaft. ;)

Das wird in den wenigstens Fällen sinnvoll funktionieren, wenn man nicht vorher schon eine saubere Admin Trennung umgesetzt hat. 1. Unkritisch 2. "normalerweise" unkritisch in der Umsetzung und aus Security Gründen definitiv schnellstmöglich umzusetzen. Und zwar nicht nur auf den Domänencontrollern, sondern auf ALLEN Systemen (Client, Member, DC und Drucker usw.) 3. Wenn Exchange mit Extended Protection im Einsatz sein sollte, dürfte sowieso kein LM mehr eingesetzt werden, so dass man das im Allgemeinen heutzutage problemlos auf 3 oder 4 konfigurieren kann. 4. Ja aktivieren. Jedes moderne System ab Vista kommt damit klar. Alle anderen Systeme auch, wenn sie nicht total veraltete Varianten nutzen. Aber das merkst du dann schon ;) 5. Siehe oben. 6. Ja kannst du mit entsprechender Vorlaufzeit (innerhalb von 8h problemlos _2x_ ändern. 7. WEnn man nicht ganz viele LDAP Abfragen stellt die bestimmte sonst nicht lesbare Attribute benötigen, kann man das relativ easy abschalten. Ich lass mich aber gern belehren. 8. Kann man "relativ" unkritisch auf die modernen Varianten umstellen/einschränken. Bye Norbert

Wenn’s nicht eine der beiden default policies ist, dann hilft der Befehl aber auch nix. Oder meinst du den Hinweis einfach ein neues gpo anzulegen?

Macht man heute so, wenn man KI Eingaben gewöhnt ist ;)

Nein, der steht da nur, wenn das System ursprünglich mal FRS lief. Bei neu installierten Systemen die nie FRS haben, ist es immer direkt sysvol (ohne _dfrs).

Ja.

Es gibt wirklich Leute, die sich sowas als Video antun? Viel Gelaber und die wichtigsten Dinge kommen am Ende oder gar nicht vor? ;) scnr norbert

Wenn du händisch die recipient Details im Sync anpasst, sollte man schon genau wissen was und wann und warum man das tut. Da jetzt den genauen Grund rauszufinden wird im Forum schwierig. Das hätte man aber bereinigen können und jetzt nicht so einen Zustand. ;)