none
Exchange 2016 - Implementierung , SHA256, Zertifikate, Interne/Externe URL, OutlookAnywhere RRS feed

  • Frage

  • Hallo Zusammen,

    hoffe wieder hier Unterstützung zu finden ...

    Umfeld:

    + AD Forest/Domain 2008 R2
    + Exchange 2010/2013 Coexsistenz (Exchange 2010 SP2 RU12 und Exchange 2013 CU11)
    + Keine Migration zu Exchange 2013 durchgeführt, nur Initial Setup.
    + Aktuell DirectAccess mit Ausnahme für OutlookAnywhere
    + AD integrierte Windows PKI 2008 R2 (3-stufig), Kein Zertifikat von einer externen CA
    + Einrichtung Exchange 2016 geplant:
    SiteA       = 2x Exchange2016 Nodes [(CAS Primär/Public) / MBX} mit 1x DAG und Split-DNS Roundrobin auf mail.PublicDomain.tld, autodiscover.PublicDomain.tld
    SubSitesBCD = 2-3x Exchange Nodes ((CAS Subsites)/MBX) ohne DAG
    TLS Kommunikation Ex intern und auch extern GW

    Aufgabenbeschreibung:

    Bisher konnte ich Erfahrungen mit einer zentral und offen geführten Exchange Umgebung sammeln. Aktuell stellt sich die CoEx 2010/2013 Umgebung zentral/dezentral mit Servern an weiteren Standorten und auch restriktiver dar. Da die Ex2013 Erst-Installation "unfertig" und nicht dokumentiert abgeschlossen wurde und auch keine Migration gestartet wurde, möchte ich eine saubere Ex2016 Einrichtung selbst vornehmen und die Migration durchführen. 

    Problemstellung:

    Unklarheiten bei der technischen Umsetzung und "best practice" Ansätze.

    Fragen:

    I. Zertifikate

    1. SHA256 ...

    I. Zertifikate
    1. SHA256 ...
    Wenn neue Zertifikate dann mit SHA256 ... wie hier beschrieben
    a. Ist bei einer PKI Umstellung von SHA1 auf SHA256 mit größeren Problemen zu rechnen?
    b. Erfahrungswerte oder wie kann dies geprüft werden?

    2. Interne/Externe URL ...

    Grundsätzlich würde ich bei den von extern (Public) erreichbaren CAS's die URL 'Intern/Extern' auf o.b. mail/autodiscover setzen und bei allen anderen 'Intern' auf den eigentlichen Hostnamen belassen ...
    a. Ist das Allgemein und in der CoEX 2010/2016 möglich oder müssen auch die 'Intern' URL der Ex Server der SubSites angepasst werden und wenn wie?              

    3. WildCard oder SAN (Subject Alternative Names) ...
    WildCard Zertifikate werden meines Erachtens unterstützt (hatte ich bisher auch), aber aus Sicherheitsgründen sollen nur SAN eingesetzt werden ... 
    a. Welche DNS-Namen sind alle im Feld 'Subject Alternative Names' einzubringen am CAS (Primär/Public)?
    b. Vermute eher nein, aber muss der eigentliche Hostname der CAS's (Primär/Public) auch ins Zertifikat Feld SAN?
    c. Welche DNS-Namen sind alle im Feld 'Subject Alternative Names' einzubringen an den CAS (Subsites)?
    d. Müssen die DNS-Namen aller akzeptierten Domänen (mail.PublicDomain2.tld, autodiscover.PublicDomain2.tld, etc.) auch ins Feld, wenn der MailFlow/DNS Reccords auf die primären CAS's zielen? 

    II. Outlook Anywhere
    1. Autodiscover und Absicherung Zugriff in Verbindung mit DirectAccess (aktuell EAS mit Device-Block und OA ohne Autodiscover) ...
    a. Wie kann man OA oder EAS als Funktion erhalten, aber sicherstellen das nur eigene Geräte diese nutzen können?
    Also Eingabe EMail/PWD >> AutoDiscover >> Überprüfung ist eigenes Gerät (vermutlich Zertifikat) >> Zugriff

    Damit bei bestehenden, unterbrochenen oder fehlerhaften Direct Access Tunnel der Outlook Client grundsätzlich die 'Public' URL nutzt, soll die OA-Funktion am Server oder Postfach des Benutzers grundsätzlich nicht abgeschaltet werden.

    Vielen Dank im Voraus für jede Art der Zusammenarbeit und "Sorry für die Formatierung"


    Manfred Schüler




    • Bearbeitet MSchueler Mittwoch, 24. Februar 2016 15:03
    Mittwoch, 24. Februar 2016 14:49

Alle Antworten

  • tl;dr - nur die Fragen:

     

    > a. Ist bei einer PKI Umstellung von SHA1 auf SHA256 mit größeren Problemen zu rechnen?

    Nein. Exchange ist nur Nutzer der Zertifikate und hat mit SHA256 Zertifikaten keine Probleme.

    > a. Ist das Allgemein und in der CoEX 2010/2016 möglich oder müssen auch die 'Intern' URL der Ex Server der SubSites angepasst werden und wenn wie?

    Es ist zwar möglich, aber nicht empfohlen. Leichter und weniger fehleranfällig ist eine Split-DNS-Konfiguration.

    Außerdem kommt hinzu, dass Du interne Name heutzutage nicht mehr in externen PKIs validiert bekommst. Du musst dann also zwei Zertifikate nehmen und am Proxy neue Verschlüsselung durchführen. Ist blöd und IMHO bei 2016 auch nicht mehr supported.

    > WildCard Zertifikate werden meines Erachtens unterstützt (hatte ich bisher auch), aber aus Sicherheitsgründen sollen nur SAN eingesetzt werden ... 

    Der erste Teilsatz ist korrekt, mit dem zweiten gehe ich nicht konform. Der private Schlüssel eines Zertifikates ist IMMER wichtig. Wenn Du bei einem Wildcard-Zertifkat nicht garantieren kannst, dass Dir der private Schlüssel geklaut wird, hast Du mit einem SAN-Zertifikat wenig gewonnen.

    > a. Welche DNS-Namen sind alle im Feld 'Subject Alternative Names' einzubringen am CAS (Primär/Public)?

    "mail.xxx" und "autodiscover.xxx". Für Autodiscover geht notfalls auch ein SRV-Eintrag, mit dem kommen aber manchen mobilen Geräte nicht klar. Dann würde "mail.xxx" reichen.

    > b. Vermute eher nein, aber muss der eigentliche Hostname der CAS's (Primär/Public) auch ins Zertifikat 

    Denn kennt niemand, daher muss er auch nicht ins Zertifikat.

    > c. Welche DNS-Namen sind alle im Feld 'Subject Alternative Names' einzubringen an den CAS (Subsites)?

    Dito.

    > d. Müssen die DNS-Namen aller akzeptierten Domänen (mail.PublicDomain2.tld, autodiscover.PublicDomain2.tld, etc.) auch ins Feld, wenn der MailFlow/DNS Reccords auf die primären CAS's zielen? 

    Das kommt drauf an.... ;)

    Der Name "mail.*** ist nicht notwendig, weil die URL, die beim Autodiscover übergeben wird, frei eingestellt werden kann. "autodiscover*.xxxx" ist theoretisch für jede Mail-Domäne notwendig. Wenn Du dagegen willst, dass die User eine OWA mit "ihrer" Domäne aufrufen, müssen mehr Namen ins Zertifikat.

    Hier noch mal den dringenden Hinweis, Split-DNS zu nutzen! Gerade bei einer so komplexen Umgeben spart das Arbeit und Fehlersuche!

    > a. Wie kann man OA oder EAS als Funktion erhalten, aber sicherstellen das nur eigene Geräte diese nutzen können?

    Mit Bordmitteln gar nicht, haben wir just diese Woche intern diskutiert. VPN/DirectAccess oder Drittanbieter-Lösungen.




    Gruesse aus Berlin schickt Robert - MVP Office Servers and Services (Exchange Server)

    Mittwoch, 24. Februar 2016 16:25
  • Am 24.02.2016 schrieb Robert Wille [MVP]:
    Hi,

    /> WildCard Zertifikate werden meines Erachtens unterstützt (hatte ich bisher auch), aber aus Sicherheitsgründen sollen nur SAN eingesetzt werden ... /

    Der erste Teilsatz ist korrekt, mit dem zweiten gehe ich nicht konform. Der private Schlüssel eines Zertifikates ist IMMER wichtig. Wenn Du bei einem Wildcard-Zertifkat nicht garantieren kannst, dass Dir der private Schlüssel geklaut wird, hast Du mit einem SAN-Zertifikat wenig gewonnen.

    Naja Wildcard Zertifikate werden ja meist auf x-verschiedenen Servern eingesetzt, und somit fluktuiert der private Key auf x-verschiedenen Servern und Systemen und durch diverse Hände die nicht immer die des Exchange Admins sind. ;)

    Zum Thema Autodiscover und viele SMTP Domains, das geht "sinnvoller" mit einem http Redirect auf nur eine Domain. Spart Namen im Zertifikat und Geld. ;)

    Bye
    Norbert


    Dilbert's words of wisdom #32:
    If it wasn't for the last minute, nothing would get done.
    nntp-bridge Zugriff auf die MS Foren wieder möglich: https://communitybridge.codeplex.com/

    Mittwoch, 24. Februar 2016 22:21
  • > Naja Wildcard Zertifikate werden ja meist auf x-verschiedenen Servern eingesetzt, und somit fluktuiert der private Key auf x-verschiedenen Servern und Systemen und durch diverse Hände die nicht immer die des Exchange Admins sind. ;)

    Wenn ich Admins Zertifikate geben, muss ich denen Admins Vertrauen können. Da spielt der Typ des Zertifikates für mich erstmal eine untergeordnete Rolle. Wenn ich Angst habe, dass ein Admin ein Zertifikat missbraucht, habe ich ein Problem mit dem Admin, nicht mit dem Zertifikat.

    Und wenn ich mir dann die Praxis in manchen Unternehmen anschaue, dass jeder Admin mit einer kleinen Anforderung ohne echte Begründung eh jedes Zertifikat ausgestellt bekommen kann, sind die Probleme da auch wieder an anderer Stelle.

    Der Hauptgrund, warum wir bei uns auch kein Wildcard einsetzen, liegt vielmehr daran, dass das Sperren im Notfall eines solchen sehr viel Aufwand macht, weil man es dann auf vielen System austauschen muss. Dieser Fall ist mit einzelnen Zertifikaten besser handelbar.

    > Zum Thema Autodiscover und viele SMTP Domains, das geht "sinnvoller" mit einem http Redirect auf nur eine Domain. Spart Namen im Zertifikat und Geld. ;)

    IMHO passiert der Redirect nach dem SSL-Handshake, d.h. es gibt immer vorher eine Warnung und erst dann erfolgt die Weiterleitung. Und den Fallback über HTTP finde ich nicht so gut, da er bei Fehlkonfiguration ein massives Sicherheitsleck darstellen kann.

    Zumal das die Clients unterstützen müssen, da der Redirect vom Client ausgeführt wird. Und ich weiß nicht, welche das dann wieder nicht können.

    Und es ist extrem schwer zu troubleshooten, weil ich den Redirect bei Problmen im schlimmsten Fall nur mit Netzwerksniffer sehe.

    Kurz gesagt: Das ist mir ein Layer zu tief und damit zu instranparent, wenn mal was nicht geht.


    Gruesse aus Berlin schickt Robert - MVP Office Servers and Services (Exchange Server)

    Donnerstag, 25. Februar 2016 08:36
  • Am 25.02.2016 schrieb Robert Wille [MVP]:
    Hi Robert,

    > Naja Wildcard Zertifikate werden ja meist auf x-verschiedenen Servern eingesetzt, und somit fluktuiert der private Key auf x-verschiedenen Servern und Systemen und durch diverse Hände die nicht immer die des Exchange Admins sind. ;)

    Wenn ich Admins Zertifikate geben, muss ich denen Admins Vertrauen können. Da spielt der Typ des Zertifikates für mich erstmal eine untergeordnete Rolle. Wenn ich Angst habe, dass ein Admin ein Zertifikat missbraucht, habe ich ein Problem mit dem Admin, nicht mit dem Zertifikat.

    Ich meinte eher, dass der Private Key auf "zig" Webservern usw. rumliegt. Also das Risiko nicht immer klar erkennbar ist und nicht, dass die Admins nicht aufpassen. ;)
     > IMHO passiert der Redirect nach dem SSL-Handshake, d.h. es gibt immer vorher eine Warnung und erst dann erfolgt die Weiterleitung. Und den Fallback über HTTP finde ich nicht so gut, da er bei Fehlkonfiguration ein massives Sicherheitsleck darstellen kann.

    Ich meinte den Redirect auf http Ebene. Da gibts keinen SSL-Handshake. ;) Da ist auch kein Massives Sicherheitsleck, oder ich habs noch nicht gefunden/gezeigt bekommen. autodiscover.firma-b.com wird per http redirect (afair 302) an https://autodiscover.firma-a.com umgeleitet. Da seh ich jetzt kein Sicherheitsleck. Natürlich darf autodiscover.firma-b.com nicht auf https reagieren.

    Zumal das die Clients unterstützen müssen, da der Redirect vom Client ausgeführt wird. Und ich weiß nicht, welche das dann wieder nicht können.

    Mir wäre keiner bekannt, der das nicht könnte. Das muß nichts heißen, aber zumindest Outlook (ab 2007, Mac Mail, Outlook for Mac, iPhones und Windows Mobile) machen das problemlos. Android will ich nicht testen, da dort der Autodiscoverprozess sowieso "kaputt" ist in meinen Augen. ;)

    Kurz gesagt: Das ist mir ein Layer zu tief und damit zu instranparent, wenn mal was nicht geht.

    Ja kann ich verstehen, seh ich aber nicht so kritisch. ;)

    Bye
    Norbert

    Donnerstag, 25. Februar 2016 09:30
  • > Ich meinte den Redirect auf http Ebene. Da gibts keinen SSL-Handshake. ;)

    Was Du meintest, ist mir schon klar.

    Allerdings gibt es hier auch das technische Problem, dass der Kunde mehrere externe IP-Adressen haben muss, wenn er noch andere SSL-Verbindungen in sein Unternehmen bekommt.

    Der Client probiert immer zuerst https aus und hier darf auf diesem Namen nichts antworten. Sobald dort, weil nur eine IP-Adresse vorhanden ist, ein anderer SSL-Host antwortet (oder die T-Online-Fehlerseite), hast Du ein Zertifikatsproblem.

    Erst im zweiten Schritt erfolgt vom Client der Fallback auf http.

    > Da ist auch kein Massives Sicherheitsleck, oder ich habs noch nicht gefunden/gezeigt bekommen.

    Aus Sicherheitssicht hast Du hier eine sogenannte "Downgrade Attacke". Du bringst den Client aus einem Zustand mit höherer Sicherheit in einen Zustand mit weniger Sicherheit.

    In einem offenen WLAN (z.B. beim Flugplatz) oder einem manipulierten LAN wäre es kein Problem, dem Client einen manipulierten Redirect unterzuschieben. Da der Redirect auf jede beliebige Seite gehen kann, kann ich ihn damit auf eine andere Seite mit SSL schieben und muss hier noch nicht mal das Zertifikat fälschen, wie es bei einer HTTPS-Man in the middle Attacke notwendig wäre.

    Die bessere (aber immer noch nicht perfekte) Lösung für dieses Problem wäre die Nutzung von "HTTP Strict Transport Security". Das können IMHO aber weder Client noch Exchange.

    Mir ist klar, dass MitM-Attacken auch mit HTTPS möglich sind, sie sind aber deutlich aufwendig.

    Schick wäre es, wenn die Windows-Landschaft auch ohne VPN/DirektAccess Client-Zertifikate nutzen könnte. Und noch schöner wäre es, wenn Microsoft endlich einfaches Zertifikats-Pinning könnte. Das wäre auch außerhalb von Exchange sehr nützlich.

    Gruesse aus Berlin schickt Robert - MVP Office Servers and Services (Exchange Server)

    Donnerstag, 25. Februar 2016 13:29
  • Hallo Norbert, Hallo Robert,

    erstmal Danke für eure Kommentare, an denen ich als 'normaler' Admin erkenne, das das Thema an sich schon interessant ist. Wo ist der Kaffee Becher zum Münzeinwurf ;-)

    Ich weiß nicht wie ihr die 'grau' Text Hinterlegung im Editor hin bekommt (vermutlich HTML), deshalb zu den Themen eine Auflistung in 'old school ' :-(  .... Hier könnte Microsoft mal nachbessern

    'SHA256'

    Nutzen grundsätzlich nur Server / Client sowie Benutzer Zertifikate im klassischen Windows Umfeld mit PortAuth und denke eher an die Probleme einzelner Clients. Denke ab Win7 sollte dies dann eher kein Problem darstellen. DANKE

    'Zertifikate'

    Bleiben wir beim SAN Zertifikat, ohne auf die Sicherheit zu schauen und wie auch schon angedacht beim bevorzugten Split-DNS.

    • Bedeutet im Fall Split-DNS, für jede SMTP-Domain sollten private/public entsprechende DNS A/SRV-Einträge vorliegen, richtig?
    • Es reicht aus für den Autodiscover Dienst der weiteren SMTP-Domänen in deren DNS Namensraum, einen SRV Eintrag als Verweis auf den primären SMTP-Namensraum (autodiscover als zu setzen, wie hierals Methode 1 beschrieben) mit der Prämisse das bei der Ersteinrichtung eine Zertifikats-Warnung erreicht.
    • In dem Fall brauche ich im primären Zertifikat außer (mail.PublicDomain.tld, autodiscover.PublicDomain.tld) keine weitere Einträge, richtig?
    • Was ist im Bezug CoEx mit Exchange 2010, wo grundsätzlich älter DNS-Namen mit ins Zertifikat sollen. Ist dies bei Ex2016 auch so?
      Die aktuelle Konfiguration ist der hier oben dargestellten und hier beschriebenen Variante 'Ambiguous URLs NOT in Use' gleich.
      Gesamt Ziel wäre dann in einer späteren reinen Ex2016 Umgebung nur die beiden (mail.PublicDomain.tld, autodiscover.PublicDomain.tld) Namen noch zu nutzen.

    'OA und EAS Protection'

    VPN/DirectAccess oder Drittanbieter-Lösungen?

    • DA > Problem ist das bestimmte Länder die Verbindungen blocken oder bei Verbindungsabbrüche der Zugriff auf OA aufrecht zu halten gilt. Hierbei muss der Outlook Zugriff ja dann von 'Public' erfolgen, am Tunnel vorbei als Ausnahme. WIe sieht es hierbei aus, in Bezug auf DNS-Split aus?
    • Welche Drittanbieter Lösung 'Reverse Proxy' (z.B:  Sophos UTM) unterstützt dies und mit welcher Technologie(Zertifikats basierend?)

    Ausgangsstellung stellt sich so dar...

    Ziel wäre dann dies ... 

    LG


    Manfred Schüler

    Donnerstag, 25. Februar 2016 13:47
  • Hallo Robert,

    die Sicherheitsaspekte sind für mich nicht Prio 1.

    Jedoch fällt der Einsatz mit Zertifikaten auch den 'normalen' Adminstratoren sichtlich schwer und ich gebe dir Recht, das hier Microsoft noch Verbesserungspotenziale hat, siehe Beispiel letsencrypt.

    Dadurch wird die Sicherheit quasi von alleine erhöht und dies wäre auch ein guter Ansatz Dienste wie Exchange nicht Offline gehen zu sehen, nur weil das Zertifikat mal wieder ausgelaufen ist und der 'Super' Admin gerade nicht griffbereit ist ;-)

    LG


    Manfred Schüler

    Donnerstag, 25. Februar 2016 13:57
  • > Bedeutet im Fall Split-DNS, für jede SMTP-Domain sollten private/public entsprechende DNS A/SRV-Einträge vorliegen, richtig?

    Korrekt.

    > Es reicht aus für den Autodiscover Dienst der weiteren SMTP-Domänen in deren DNS Namensraum, einen SRV Eintrag als Verweis auf den primären SMTP-Namensraum (autodiscover als zu setzen, wie hierals Methode 1 beschrieben) mit der Prämisse das bei der Ersteinrichtung eine Zertifikats-Warnung erreicht.

    Korrekt. Es gibt aber keine Zertifikats-Warnung (das wäre fatal, dann funktioniert Outlook nicht richtig), sondern eine Umleitungs-Warnung.

    > In dem Fall brauche ich im primären Zertifikat außer (mail.PublicDomain.tld, autodiscover.PublicDomain.tld) keine weitere Einträge, richtig?

    Korrekt.

    > Was ist im Bezug CoEx mit Exchange 2010, wo grundsätzlich älter DNS-Namen mit ins Zertifikat sollen. Ist dies bei Ex2016 auch so?

    Bei einer korrekten 2010er-Umgebung hättest Du bereits alles fertig, was Du brauchst. Du müsstest nur das Zertifikat exportieren und auf die neuen 2016 importieren. Die Vorgehensweise bei den Zertifikaten hat sich nicht geändert.

    > VPN/DirectAccess oder Drittanbieter-Lösungen?

    Hierzu kann Norbert eventuell mehr sagen, das ist nicht mein Spezialgebiet.

    Gruesse aus Berlin schickt Robert - MVP Office Servers and Services (Exchange Server)

    Donnerstag, 25. Februar 2016 14:02
  • Am 25.02.2016 schrieb Robert Wille [MVP]:

    > Bedeutet im Fall Split-DNS, für jede SMTP-Domain sollten private/public entsprechende DNS A/SRV-Einträge vorliegen, richtig?

    Korrekt.

    Es reicht aus für den Autodiscover Dienst der weiteren SMTP-Domänen in deren DNS Namensraum, einen SRV Eintrag als Verweis auf den primären SMTP-Namensraum (autodiscover als zu setzen, wie hierals Methode 1 beschrieben) mit der Prämisse das bei der Ersteinrichtung eine Zertifikats-Warnung erreicht.

    Korrekt. Es gibt aber keine Zertifikats-Warnung (das wäre fatal, dann funktioniert Outlook nicht richtig), sondern eine Umleitungs-Warnung.

    Man sollte aber dazu sagen, dass SRV Records eben nur mit Outlook (für Windows?) funktionieren. Alle anderen mir bekannten Clients nutzen die nicht.

    Bye
    Norbert


    Frank, I never thought I'd say this again. I'm getting the pig!
    nntp-bridge Zugriff auf die MS Foren wieder möglich: https://communitybridge.codeplex.com/

    Donnerstag, 25. Februar 2016 15:42
  • Am 25.02.2016 schrieb MSchueler:
    Hi,

    * DA > Problem ist das bestimmte Länder die Verbindungen blocken oder bei Verbindungsabbrüche der Zugriff auf OA aufrecht zu halten gilt. Hierbei muss der Outlook Zugriff ja dann von '/Public/' erfolgen, am Tunnel vorbei als Ausnahme. WIe sieht es hierbei aus, in Bezug auf DNS-Split aus?
    * Welche Drittanbieter Lösung '/Reverse Proxy/' (z.B:  Sophos UTM) unterstützt dies und mit welcher Technologie(Zertifikats basierend?)

    Das hat doch nichts mit Reverse Proxy zu tun. Sondern das muß deine Direct Access Konfiguration hergeben, dass der Exchangeserver eben nicht durch den Tunnel erreicht werden darf. Das verbietet sich schon aufgrund von Performancefragen in meinen Augen. Sprich... selbst bei aufgebauter DirectAccess Verbindung geht mein Outlook immer "aussen" rum zum Exchange. Und das funktioniert sehr gut. ;)

    Bye
    Norbert


    Dilbert's words of wisdom #18:
    Never argue with an idiot. They drag you down to their level then beat you with experience.
    nntp-bridge Zugriff auf die MS Foren wieder möglich: https://communitybridge.codeplex.com/

    Donnerstag, 25. Februar 2016 15:45
  • Am 25.02.2016 schrieb Robert Wille [MVP]:

    > Ich meinte den Redirect auf http Ebene. Da gibts keinen SSL-Handshake. ;)

    Was Du meintest, ist mir schon klar.

    Gut. :)

    Allerdings gibt es hier auch das technische Problem, dass der Kunde mehrere externe IP-Adressen haben muss, wenn er noch andere SSL-Verbindungen in sein Unternehmen bekommt.

    Ja, davon geh ich in so einer Konstellation auch aus. Wobei das in dem Fall ja sogar beim Hoster "gemieteter" Webserver auf Port 80 sein kann.

    Der Client probiert immer zuerst https aus und hier darf auf diesem Namen nichts antworten. Sobald dort, weil nur eine IP-Adresse vorhanden ist, ein anderer SSL-Host antwortet (oder die T-Online-Fehlerseite), hast Du ein Zertifikatsproblem.

    Ja, wenn ich was "falsch" konfiguriere gibt es Fehler. ;)

    Aus Sicherheitssicht hast Du hier eine sogenannte "Downgrade Attacke". Du bringst den Client aus einem Zustand mit höherer Sicherheit in einen Zustand mit weniger Sicherheit.

    Naja eigentlich nicht, denn das ist ja das erwartete Verhalten von Autodiscover. Ich stimme dir zu, aber ich bezweifle, dass jemand in einem Zertifikat wirklich gefühlte 50 Domains mit demzufolge dann 100 Host Einträgen nutzt. Denn sonst wäre O365 ständig am Zertifikate tauschen. ;)

    In einem offenen WLAN (z.B. beim Flugplatz) oder einem manipulierten LAN wäre es kein Problem, dem Client einen manipulierten Redirect unterzuschieben. Da der Redirect auf jede beliebige Seite gehen kann, kann ich ihn damit auf eine andere Seite mit SSL schieben und muss hier noch nicht mal das Zertifikat fälschen, wie es bei einer HTTPS-Man in the middle Attacke notwendig wäre.

    Naja mit SSL Inspection und "Kram" bekommt man das auch mit SSL hin. Ob und an welcher Stelle dann unsicher ist, ist auch wieder egal. ;)

    Die bessere (aber immer noch nicht perfekte) Lösung für dieses Problem wäre die Nutzung von "HTTP Strict Transport Security". Das können IMHO aber weder Client noch Exchange.

    Müßte ich mich erstmal einlesen.

    Schick wäre es, wenn die Windows-Landschaft auch ohne VPN/DirektAccess Client-Zertifikate nutzen könnte. Und noch schöner wäre es, wenn Microsoft endlich einfaches Zertifikats-Pinning könnte. Das wäre auch außerhalb von Exchange sehr nützlich.

    Naja es muß doch noch Optimierungsmöglichkeiten für die Zukunft geben. ;)

    Bye
    Norbert


    Dilbert's words of wisdom #19:
    Am I getting smart with you? How would you know?
    nntp-bridge Zugriff auf die MS Foren wieder möglich: https://communitybridge.codeplex.com/

    Donnerstag, 25. Februar 2016 15:50
  • Am 25.02.2016 schrieb MSchueler:
    Hi,

    Jedoch fällt der Einsatz mit Zertifikaten auch den 'normalen' Adminstratoren sichtlich schwer und ich gebe dir Recht, das hier Microsoft noch Verbesserungspotenziale hat, siehe Beispiel letsencrypt <https://letsencrypt.org/>.

    Den Zusammenhang zwischen Microsoft/Verbesserungspotenzial und Letsencrypt müßtest du mir erklären. Worauf zielst du dabei ab?

    Dadurch wird die Sicherheit quasi von alleine erhöht und dies wäre auch ein guter Ansatz Dienste wie Exchange nicht Offline gehen zu sehen, nur weil das Zertifikat mal wieder ausgelaufen ist und der 'Super' Admin gerade nicht griffbereit ist ;-)

    Ehrlich jetzt? Naja... Wenn mein Auto Rote Lampe anmacht fahr ich in die Werkstatt (zumindest ruf ich mal an). ;)

    Bye
    Norbert


    Frank, I never thought I'd say this again. I'm getting the pig!
    nntp-bridge Zugriff auf die MS Foren wieder möglich: https://communitybridge.codeplex.com/

    Donnerstag, 25. Februar 2016 15:52
  • Am 25.02.2016 schrieb MSchueler:

    Ich weiß nicht wie ihr die 'grau' Text Hinterlegung im Editor hin bekommt (vermutlich HTML), deshalb zu den Themen eine Auflistung in 'old school ' :-(  .... Hier könnte Microsoft mal nachbessern

    Siehe meine Signatur. ;)

    Bye
    Norbert


    Dilbert's words of wisdom #32:
    If it wasn't for the last minute, nothing would get done.
    nntp-bridge Zugriff auf die MS Foren wieder möglich: https://communitybridge.codeplex.com/

    Donnerstag, 25. Februar 2016 16:10
  • Hi Norbert,

    • automatische Zertifikats Erneuerungen und Bindung für die Server Systeme. Oder ich weiß nicht wie es geht.
    • meine eher in Hinsicht auf die Verwaltung und nicht aus Sicht der Anwender. Klar rote Lampe geht gar nicht, deshalb drücken wir auch immer weiter .. weiter ;)

    LG und schönes WE


    Manfred Schüler

    Freitag, 26. Februar 2016 10:06
  • Hi Norbert,

    nntp-bridge Zugriff!?
    Warum nicht direkt einen modernen Editor, wie manche 'lowcoast' Lösungen wie z.B. Wordpress anbieten. Das sollte doch für einen Konzern wie Microsoft möglich sein? OK, meine Ansprüche sind zu hoch...
    Danke, versuche ich aber gerne mal. 

    LG

     


    Manfred Schüler

    Freitag, 26. Februar 2016 10:13
  • Hi Norbert,

    ja richtig und ist auch so konfiguriert. Bei bestehender DA Verbindung kommt der Outlook Client von 'aussen' rein. Es geht ja darum Outlook Anywhere in Verbindung mit Autodiscover (SMTP + PWD)  nur den "bekannten eigenen" Geräten zu ermöglichen.

    LG


    Manfred Schüler

    Freitag, 26. Februar 2016 13:05
  • Am 26.02.2016 schrieb MSchueler:
    Hi,

    ja richtig und ist auch so konfiguriert. Bei bestehender DA Verbindung kommt der Outlook Client von 'aussen' rein. Es geht ja darum Outlook Anywhere in Verbindung mit Autodiscover/(SMTP + PWD)/  nur den "bekannten eigenen" Geräten zu ermöglichen.

    Das wird wohl schwierig, da du eher selten auf Geräte filtern kannst, oder? Evtl. wäre Zertifikatsbasierende Authentifizierung ein Weg, aber hab ich nicht getestet.

    Bye
    Norbert

    Sonntag, 28. Februar 2016 21:23
  • Am 26.02.2016 schrieb MSchueler:
    Hi,

    nntp-bridge Zugriff!?

    Jupp.

    Warum nicht direkt einen modernen Editor, wie manche '/lowcoast/' Lösungen wie z.B. Wordpress anbieten.

    Ich brauch keinen "modernen" Editor um Text zu schreiben. ;)

    Das sollte doch für einen Konzern wie Microsoft möglich sein? OK, meine Ansprüche sind zu hoch...

    Tja der Hoffung hingen viele MVPs nach. ;)

    Bye
    Norbert


    Frank, I never thought I'd say this again. I'm getting the pig!
    nntp-bridge Zugriff auf die MS Foren wieder möglich: https://communitybridge.codeplex.com/

    Sonntag, 28. Februar 2016 21:24
  • Hi Norbert,

    noch was anderes, zum Thema Datenbank und Postfach Limits. Ich weiß es ist ein blödes Thema und 'Admins' wissen, dieses Thema stirbt nie aus, aber folgendes in Zeiten von 'Big-Data' und 'Online' Konkurrenz ;-) ...

    • Was sind die empfohlenen Datenbank/Postfach Limits in Bezug auf Sicherheit (ich bin immer noch der Meinung, es sollte ein Limit gesetzt werden), Performance (Postfachgröße / Anzahl der Elemente bei Client und Server) und Offline Cache (Änderungen durch Microsoft in der Umsetzung des Outlook Clients ab 2013). In der Zusammenarbeit mit Microsoft Mitarbeiter hieß es mal selbst im 'eigenen Hause', seien bei Exchange 2010 Limits von 5 GB gesetzt und zu empfehlen.
      Mit Online Postfach Limits von 5-50 GB sollten Exchange 2013/2016 keine Probleme haben, das sizing aktuell auf 5 GB geplant, wohl wissend das es wieder Ausnahmen gibt.
    • Gibt es eigentlich im Office 365 Umfeld auch Kontingent Warn und Senden/Empfangen Limits oder 'unlimited' gesetzt ;) ?

    Desweiteren würde ich gerne wissen, ob mit Exchange 2016 bei der Benutzer/Postfach-Erstellung mittels EAC die Postfächer auf die zur Verfügung stehenden Datenbanken automatisch verteilt werden?


    Manfred Schüler

    Dienstag, 1. März 2016 15:16
  • Moin,

    > Was sind die empfohlenen Datenbank/Postfach Limits in Bezug auf Sicherheit (ich bin immer noch der Meinung, es sollte ein Limit gesetzt werden),

    das hängt von den Anforderungen und Möglichkeiten des Unternehmens ab.

    > Performance (Postfachgröße / Anzahl der Elemente bei Client und Server) und Offline Cache (Änderungen durch Microsoft in der Umsetzung des Outlook Clients ab 2013).

    Irgendwo hatte ich das mal:
     - 2007 -> 2 GB
     - 2010 -> 10 GB
     - 2013 -> 100 GB

    Für 2016 kenne ich keine Zahlung, dürften sich aber auf 2013-Niveau bewegen.

    Sowohl für das Postfach, also auch für den Client. Sind aber nur die empfohlenen Werte, wir haben wir 2010 mit bis zu 30 GB relativ problemlos.

    > In der Zusammenarbeit mit Microsoft Mitarbeiter hieß es mal selbst im 'eigenen Hause', seien bei Exchange 2010 Limits von 5 GB gesetzt und zu empfehlen.

    Ja, das war mal - vor 5 Jahren zu Zeiten von Exchange 2010.

    > Mit Online Postfach Limits von 5-50 GB sollten Exchange 2013/2016 keine Probleme haben, das sizing aktuell auf 5 GB geplant, wohl wissend das es wieder Ausnahmen gibt.

    Sollte kein Problem sein, siehe ob.

    Rein technisch spielt die Größe eine untergeordnete Rolle für die Performance. Natürlich muss ich Storage, Backup, usw. danach planen, aber die Postfächer sind ja nicht ständig komplett geladen. Für die gefühlte (und tatsächliche Geschwindigkeit) sind die Änderungen viel wichtiger, als wieviele Mails kommen rein und raus und wieviele Aktionen gibt es im Postfach sonst noch.

    > Gibt es eigentlich im Office 365 Umfeld auch Kontingent Warn und Senden/Empfangen Limits oder 'unlimited' gesetzt ;) ?

    Ja, Microsoft bietet 50 GB pro Postfach an. Ich vermute, da gibt es auch Warnstufen, allerdings habe ich noch keine erlebt, so groß sind meine PF noch nicht.

    > Desweiteren würde ich gerne wissen, ob mit Exchange 2016 bei der Benutzer/Postfach-Erstellung mittels EAC die Postfächer auf die zur Verfügung stehenden Datenbanken automatisch verteilt werden?

    Ja, auch 2016 verteilt die Postfächer automatisch, wenn man keine Datenbank angibt. Und wie vorher aber zufällig, IMHO wurde an dieser Logik  nichts geändert. Bei einer entsprechend hohen Anzahl Postfächer funktioniert es aber relativ gut.


    Gruesse aus Berlin schickt Robert - MVP Office Servers and Services (Exchange Server)

    Dienstag, 1. März 2016 15:30
  • Am 01.03.2016 schrieb MSchueler:
    Hi,

    * Was sind die empfohlenen Datenbank/Postfach Limits in Bezug auf Sicherheit (ich bin immer noch der Meinung, es sollte ein Limit gesetzt werden)  , Performance/(Postfachgröße / Anzahl der Elemente bei Client und Server)/   und Offline Cache/(Änderungen durch Microsoft in der Umsetzung des Outlook Clients ab 2013)/  . In der Zusammenarbeit mit Microsoft Mitarbeiter hieß es mal selbst im 'eigenen Hause', seien bei Exchange 2010 Limits von 5 GB gesetzt und zu empfehlen.
      Mit Online Postfach Limits von 5-50 GB sollten Exchange 2013/2016 keine Probleme haben, das sizing aktuell auf 5 GB geplant, wohl wissend das es wieder Ausnahmen gibt.

    http://aka.ms/ex2013limits
    Ich würde sagen, das ist eher ein reines Backup/Recovery Thema. Denn Storage ist billig und Exchange hat auch technisch wenig Probleme mit großen Mailboxen.

    * Gibt es eigentlich im Office 365 Umfeld auch Kontingent Warn und Senden/Empfangen Limits oder 'unlimited' gesetzt ;) ?

    Siehe obiger Link "Capacity alerts accronss standalone plans".

    Desweiteren würde ich gerne wissen, ob mit Exchange 2016 bei der Benutzer/Postfach-Erstellung mittels EAC die Postfächer auf die zur Verfügung stehenden Datenbanken automatisch verteilt werden?

    Wenn du keine Datenbank angibst, dann ja.

    Bye
    Norbert


    Dilbert's words of wisdom #18:
    Never argue with an idiot. They drag you down to their level then beat you with experience.
    nntp-bridge Zugriff auf die MS Foren wieder möglich: https://communitybridge.codeplex.com/

    Dienstag, 1. März 2016 15:36
  • Am 26.02.2016 schrieb MSchueler:
    Hi,

    * automatische Zertifikats Erneuerungen und Bindung für die Server Systeme. Oder ich weiß nicht wie es geht.

    Und dann hat jemand dafür zu sorgen, dass es immer geht - automagisch? ;) Ich kenne ADFS, da gibts ein automatisches Zertifikatsrollover. Wenn dann dein System auf der anderen Seite nicht klarkommt hast du auch nichts gewonnen. ;) Hilft die beste Automatik nicht, wenn man das System nicht kapiert hat.
    Und beim Thema Server und Sicherheit bin ich eh skeptisch, dass da über Automatismus per se mehr Sicherheit gewonnen wird.

    Bye
    Norbert

    Dienstag, 1. März 2016 15:42
  • Hallo Zusammen,

    nachdem ich nun Exchange 2016 mit 2x Nodes und einer DAG, inkl. aktuellem CU1, installiert und konfiguriert habe, ist mir folgendes aufgefallen oder möchte ich ansprechen:

    1. Beim Versuch mittels Exchange Admin Center (EAC) ein 'Benutzerpostfach' mit der Option 'Neuer Benutzer' zu erstellen und eine passende Organisationseinheit (OU) auszuwählen über 'Durchsuchen' erhalte ich unter 'Organisationseinheit auswählen' nur OU's die nicht die Option gesetzt haben "Protect Object from accidential deletion".
      Was soll das? Bug oder Konfigurierbar?
    2. Der Anzeigename des Standard "Offline Adressbuch (OAB)" der mit Exchange 2016 erstellt wurde, lautet  "default (Ex2013)", was nur kosmetischer Art ist und wohl in zukünftigen CU behoben wird, wie hier beschrieben.
    3. Nach erfolgreicher Anmeldung im OWA finde ich unter den Einstellungen den Punkt "APPS". Diese kann zentral gesteuert EAC >> Organisation >> Apps werden. Stellt wohl ein Zugriff von Anwendungen aus dem Office Store auf das Postfach mittels OWA dar, richtig? 
    4. In der Vergangenheit konnte ich mittels OWA und der URL https://mail.domain.tld/owa/mailbox@domain-tld andere Postfächer direkt öffnen, wenn Berechtigungen oder Anmeldedaten vorhanden.
      Beim Versuch des Zugriffs erhalte ich folgende Fehlermeldung:
      "Dieser Fehler wird vom benutzerdefinierten Fehlermodul nicht erkannt."
      Ist nun nicht mehr möglich oder evtl. noch durch die Koexistenz mit Exchange 2010/2013 begründet?
    5. Outlook Profile zeigen in den "Servereinstellungen", statt wie bisher den "Exchange Server Namen", nun einen generischen Servernamen an, was ein normales Verhalten seit Exchange 2013 darstellt, wie hier beschrieben. Hier handelt es sich um die PostfachGUID@domain-tld.
      Spielt diese Einstellung beim externen Zugriff / Namensauflösung eine Rolle, wenn die "Autodiscover" Funktion gewollt nicht erwünscht ist (was ich nicht so sehe), da dies ja kein Server FQDN darstellt?
    6. Habe ich in keiner Anleitung mehr gefunden.
      Wird das "Microsoft Filter Pack" für Exchange 2016 noch benötigt?
    7. In verschieden Anleitungen wird der Hinweis aufgeführt, dass die interner Outlook Anywhere (OA) URL sich von der externen URL unterscheiden muss. Andere setzen, wie ich auch, die interne URL der externen URL gleich (Split DNS).
      Was stimmt?
    8. Auf beiden Exchange 2016 Nodes fällt mir, auf das der Dienst "Microsoft Exchange Notifications Broker"(MSExchangeNotificationsBroker) [StartTyp: Automatisch] nicht automatisch startet!? Manuell ist das möglich.
      "Bug" oder Start Typ auf "Automatisch Verzögert" stellen?
    9. Und zuletzt, was ich gar nicht verstehe, fällt mir auf, dass der Standard Empfangs Konnektor "Default Frontend ExNode" der auf Port 25 läuft, Nachrichten verarbeitet ohne Authentifizierung (Exchange-Benutzer)!?! Ok, ein anonymes Relay ist nicht möglich, jedoch können Nachrichten auf SMTP Wege aus dem internen Netz an die akzeptierten SMTP-Domänen versendet werden. Wie hier und hier beschrieben, handelt es sich um "... gängige Eintrittspunkt für Nachrichten, die an Ihre Organisation gesendet werden".
      Da die "Bereichsdefinition" alle Netze entspricht und dieser EC nicht geändert werden sollte (Probleme im Nachrichtentransport), stellt sich die Frage:
      a) Wie schränke ich auf Port 25 den Empfang ein, dass nur authentifizierte Benutzer "Exchange Benutzer" Nachrichten an die akzeptierten SMTP-Domänen versenden dürfen. (Was im Exchange 2010 Umfeld meine ich Standard war)?
      b) Der "Default Frontend ExNode" entspricht mehr einem Inbound-Mail-Gateway Empfangs Konnektor, richtig? Hier sollte also nur bestimme IP Adressen der Bereichsdefinition gesetzt sein.
      Also doch die Bereichsdefinition ändern oder hat dies Einfluss auf den Exchange Mailflow?

    Danke für jedes Feedback und eine schöne Woche noch.


    Manfred Schüler

    Montag, 21. März 2016 08:09
  • tl;dr - nur die wichtigsten:

    > Der Anzeigename des Standard "Offline Adressbuch (OAB)" der mit Exchange 2016 erstellt wurde, lautet  "default (Ex2013)", was nur kosmetischer Art ist und wohl in zukünftigen CU behoben wird, wie hier beschrieben.

    1. Tipp #1: Artikel dieses Autors grundsätzlich und immer und ohne Ausnahme ignorieren. Es gibt keinen Plan, diesen rein optischen Bug (den nur der Admin sieht) zu beheben.

    > Spielt diese Einstellung beim externen Zugriff / Namensauflösung eine Rolle, wenn die "Autodiscover" Funktion gewollt nicht erwünscht ist (was ich nicht so sehe), da dies ja kein Server FQDN darstellt?

    Nein, weil die Zugriff per Outlook Anywhere erfolgen.

    BTW: Outlook 2016 funktioniert ohne Autodiscover nicht mehr, weil man dort keine manuellen Exchange-Einstellungen mehr vornehmen kann.

    > a) Wie schränke ich auf Port 25 den Empfang ein, dass nur authentifizierte Benutzer "Exchange Benutzer" Nachrichten an die akzeptierten SMTP-Domänen versenden dürfen. (Was im Exchange 2010 Umfeld meine ich Standard war)?

    Gegenfrage: Wieviele Server aus dem Internet können sich bei Dir authentifizieren. Wenn Du das einschaltest, wird sehr ruhig auf dem Server werden....

    Bei 2010 musste man daher immer den Sendeconnector öffnen, um Mails von außen zu bekommen, was Microsoft mit 2013 geändert hat.

    Wenn Dich das stört und sichergestellt ist, dass z.B. ein Gateway authentifiziert einliefert, dann kannst Du das in den Berechtigungs-Eigenschaften des Connectors mit einem Klick ändern.

    Gruesse aus Berlin schickt Robert - MVP Office Servers and Services (Exchange Server)

    Montag, 21. März 2016 10:00
  • Hallo Robert,

    danke für deine Antwort.

    1. Tipp #1: Artikel dieses Autors grundsätzlich und immer und ohne Ausnahme ignorieren. Es gibt keinen Plan, diesen rein optischen Bug (den nur der Admin sieht) zu beheben.

    Was sprichte gegen den Artikel? Hatte ich auch nur aufgegriffen, da ich selber erstaunt war.

    Nein, weil die Zugriff per Outlook Anywhere erfolgen.

    OK, dann habe ich wieder mein Problem. OA und Autodiscover sollen nur für "eigene Geräte" bereitgestellt werden (Feature wie Active-Sync Geräte wäre schön) und wiederrum die Frage können die OA URLs gleich lauten?

    Gegenfrage: Wieviele Server aus dem Internet können sich bei Dir authentifizieren. Wenn Du das einschaltest, wird sehr ruhig auf dem Server werden....

    Wird schwierig ;-)

    Ist schon lange her, aber musste man hierzu in der Vergangenheit nicht extra einen "Externen Gateway" - Empfangskonnetor erstellen, wenn Inbound Mailflow bei Systemen ausserhalb der Exchange Umgebung liegen? Bei einem Edge Server ok, aber im Backend? Wieder die Frage, wie schränke ich dies intern in der Exchange Umgebung ein?


    Manfred Schüler

    Montag, 21. März 2016 10:42
  • Am 21.03.2016 schrieb MSchueler:
    Hi,

    Nein, weil die Zugriff per Outlook Anywhere erfolgen.

    OK, dann habe ich wieder mein Problem. OA und Autodiscover sollen nur für "eigene Geräte" bereitgestellt werden (Feature wie Active-Sync Geräte wäre schön) und wiederrum die Frage können die OA URLs gleich lauten?

    Das bekommst du aber derzeit nicht "sinnvoll" gelöst. Manche Probleme bekommst du eben nur organisatorisch gelöst. ;) Ja die OA URLS können gleich lauten.

    Gegenfrage: Wieviele Server aus dem Internet können sich bei Dir authentifizieren. Wenn Du das einschaltest, wird sehr ruhig auf dem Server werden....

    Wird schwierig ;-)

    Positiv verkaufen: 0% Spam!

    Ist schon lange her, aber musste man hierzu in der Vergangenheit nicht extra einen "Externen Gateway" - Empfangskonnetor erstellen, wenn Inbound Mailflow bei Systemen ausserhalb der Exchange Umgebung liegen? Bei einem Edge Server ok, aber im Backend? Wieder die Frage, wie schränke ich dies intern in der Exchange Umgebung ein?

    Was genau willst du denn einschränken? Anonym ja wohl kaum, weil sonst 0% Spamrate realistisch sind. Ansonsten kannst du das auf jedem neuen Connector definieren. Darf nur keine "Dopplungen" geben.

    Bye
    Norbert


    Dilbert's words of wisdom #32:
    If it wasn't for the last minute, nothing would get done.
    nntp-bridge Zugriff auf die MS Foren wieder möglich: https://communitybridge.codeplex.com/


    Montag, 21. März 2016 11:15
  • Hi Norbert,

    Was genau willst du denn einschränken? Anonym ja wohl kaum, weil sonst 0% Spamrate realistisch sind. Ansonsten kannst du das auf jedem neuen Connector definieren. Darf nur keine "Dopplungen" geben.

    Genau diese "Doppelungen" scheinen ja die Probleme zu verursachen und scheinbar nicht nur bei mir ;-) 

    1. [RC-GW]
      Inbound Mail von einem externen GW/Edge/FW-Forwarding auf Port 25 wie mit den entsprechenden aktuellen Einstellungen des "Default Frontend ExNode" EC 
    2. [RC-Auth]
      Alle aus dem internen Netzwerk authentifizierte Benutzer auf Port 25 interne und externe smtp-domains.
    3. [RC-NoAuth]
      Bestimmte IP oder IP-Bereiche aus dem internen Netzwerk ohne A
      uthentifizierung auf Port 25 nur interne (akzeptierte smtp-domains)
    4. [RC-NoAuthRelay]
      Bestimmte IP oder IP-Bereiche aus dem internen Netzwerk ohne Authentifizierung auf Port 25 interne und externe smtp-domains
    5. [RC-"Default Frontend ExNode"]
      Anfragen ohne Authentifizierung aus dem internen Netzwerk auf Port 25 verweigern.

    Bei Exchange 2010 im Standard "Client ExNode" EC war die Berechtigungsgruppe "Exchange-Benutzer" und kein "Anonyme Benutzer" gesetzt. Es reichte für die zuvor beschriebenen Anforderung, weitere EC mit entsprechenden IP / IP-Bereiche hinzuzufügen....

    War und sollte doch möglich sein oder stehe ich (aber scheinbar auch andere) auf dem Holzweg?


    Manfred Schüler

    Montag, 21. März 2016 12:31
  • Am 21.03.2016 schrieb MSchueler:

    Hi Norbert,

    Was genau willst du denn einschränken? Anonym ja wohl kaum, weil sonst 0% Spamrate realistisch sind. Ansonsten kannst du das auf jedem neuen Connector definieren. Darf nur keine "Dopplungen" geben.

    Genau diese "Doppelungen" scheinen ja die Probleme zu verursachen und scheinbar nicht nur bei mir ;-)

    Nochmal: Es kann keine Dopplungen geben, weil das nicht konfigurierbar ist. Kannst du ja gern mal testen.

    1. [RC-GW]
    Inbound Mail von einem externen GW/Edge/FW-Forwarding auf Port 25 wie mit den entsprechenden aktuellen Einstellungen des "Default Frontend ExNode" EC

    OK.

    2. [RC-Auth]
    Alle aus dem internen Netzwerk authentifizierte Benutzer auf Port 25 interne und externe smtp-domains.

    OK.

    3. [RC-NoAuth]
    Bestimmte IP oder IP-Bereiche aus dem internen Netzwerk_ohne_Authentifizierung auf Port 25 nur interne (akzeptierte smtp-domains)

    Damit schließt du dann 2. für diese IPs und IP Bereiche aus.

    4. [RC-NoAuthRelay]
    Bestimmte IP oder IP-Bereiche aus dem internen Netzwerk ohne Authentifizierung auf Port 25 interne und externe smtp-domains

    Damit schließt du dann 2. und 3. für diese IPs und IP Bereiche aus.

    5. [RC-"Default Frontend ExNode"]
    Anfragen_ohne_ Authentifizierung aus dem internen Netzwerk auf Port 25 verweigern.

    Wie verweigert man denn Anfragen ohne Authentifizierung?

    Bei Exchange 2010 im Standard "Client ExNode" EC war die Berechtigungsgruppe "Exchange-Benutzer" und_kein_"Anonyme Benutzer" gesetzt. Es reichte für die zuvor beschriebenen Anforderung, weitere EC mit entsprechenden IP / IP-Bereiche hinzuzufügen....

    Das funktioniert quasi identisch auch mit 2013 und 2016 nimm einfach immer nen Frontend Connector und konfiguriere das wie unter 2010.

    War und sollte doch möglich sein oder stehe ich (aber scheinbar auch andere) auf dem Holzweg?

    Kann schon sein.

    Bye
    Norbert


    Dilbert's words of wisdom #18:
    Never argue with an idiot. They drag you down to their level then beat you with experience.
    nntp-bridge Zugriff auf die MS Foren wieder möglich: https://communitybridge.codeplex.com/

    Montag, 21. März 2016 12:35
  • > Was sprichte gegen den Artikel? Hatte ich auch nur aufgegriffen, da ich selber erstaunt war.

    Im Prinzip spricht nichts gegen den Artikel - wenn man davon absieht, dass die Aussage "wird gefixed" falsch ist und es sich gar nicht um einen Fehler handelt. Allerdings ist der Autor so von sich überzeugt, dass noch nicht mal die Microsoft-Mitarbeiter der Exchange Product Group ihn überzeugen konnten.

    > OK, dann habe ich wieder mein Problem. OA und Autodiscover sollen nur für "eigene Geräte" bereitgestellt werden (Feature wie Active-Sync Geräte wäre schön) und wiederrum die Frage können die OA URLs gleich lauten?

    Wie Norbert schon schreibt: Das geht Stand heute technisch nicht (oder zumindest nicht ohne erheblichen Aufwand und/oder Dritt-Anbieter).

    Die OA URLs können und sollten gleichlauten - Split DNS.

    > Ist schon lange her, aber musste man hierzu in der Vergangenheit nicht extra einen "Externen Gateway" - Empfangskonnetor erstellen, wenn Inbound Mailflow bei Systemen ausserhalb der Exchange Umgebung liegen?

    Jein. Exchange 2000/2003 nahmen Mails aus dem Internet entgegen. Bei 2007/2010 hatte Microsoft den Connector nicht auf anonym gestellt, das musste man dann von Hand nachbessern. Aber es passte nicht in die Philosophie von Microsoft, dass die Mails ja direkt bei Exchange landen sollen, so dass das mit 2013 wieder geändert wurde.

    Das Risiko ist IMHO überschaubar, denn Exchange nimmt nur Mails an eigene Empfänger an, ist also kein offnes Relay. Einen internen Spamer habe ich in der freien Wildbahn noch nicht erlebt. In der Regel wollen die von gekaperten PCs raus senden und das muss ich an der Firewall blocken.

    Kann aber mit einem Knopfdruck deaktiviert werden, wenn das Mailrouting anders ist.


    Gruesse aus Berlin schickt Robert - MVP Office Servers and Services (Exchange Server)

    Montag, 21. März 2016 12:36