NorbertFe

alternativ: Neuinstall before pfusching ;)

Nein der scp kann auch direkt auf owa.domain.tld zeigen. Wozu sollte er auf autodiscover zeigen müssen?

Du beschreibst grad das gefühl, nachdem ich mein neues Auto gestern in Empfang genommen habe:

Weißt du, warum es hier die codeblock Formatierung im Forum gibt? ;)

Moin, das sollte ja der „lizenzberater“ dann auch irgendwie belegen können, diese Aussage. bye norbert

Die wäre üblicherweise zu bevorzugen, wenn man eine IP für den http Redirect nutzen kann. Sprich meine Priorität wäre umgekehrt zu deiner Liste (von unten nach oben).

270€ wären mir auch zuviel wenn es um Exchange Domains ginge. ;)

definiert aber auch jeder anders. Bei mir wäre da spätestens bei 3 Schluss. ;) Hab aber Kunden die hatten da 10-20 drin. ;)

Eigentlich ist es nicht eleganter und hilft halt nur bei Windows Outlook. Alle anderen Clients kennen den SRV Lookup im Autodiscover nicht.

Das kommt darauf an, ob dein Exchange Server die Mails direkt aus dem Internet annimmt, oder ob du ein Relay davor hast, von welchem der Exchange die Mails zugestellt bekommt. Im ersteren Fall musst du den Default Connector dann erstmal auf die internen IP Kreise eindampfen, damit die 0.0.0.0 an deinen neuen Connector gebunden werden kann. Im zweiteren Fall legst du einfach einen neunen Connector an und definierst nur das Mailgateway als erlaubte Remote IP Address. Bye Norbert

Da geht es um den Default Frontend Connector. Dessen EHLO String kannst du nur anpassen, wenn du ihn "umkonfigurierst". Aus diesen Grund solltest du NICHT den Default Frontend Connector benutzen, sondern einen eigenen mit den richtigen notwendigen Einstellungen. Denn der Default Frontend Connector nutzt im Default den Hostnamen des Exchangeservers, damit er sich mit anderen Exchange Servern seiner Organisation sicher "unterhalten" kann.

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