Exchange Server 2016 - Netzwerkports

[eotil 0]

Hallo,

 

ich baue derzeit eine größere Exchange-Umgebung mit 4 Servern inkl. Witness und einer entsprechenden DAG auf. Ich bin kein nativer Microsoft-Admin, kann mich aber gut einlesen und hab das System auch soweit schon stehen.

Netzwerktechnisch ist mir das aber zu offen und das soll nun restriktiver gehandhabt werden. Leider suche ich mir im Internet die Finger wund, welche Ports nun für einen reibungslosen Betrieb wirklich gebraucht werden.

Ohne jemanden auf den Schlips treten zu wollen, aber die Dokumentation von Microsoft ist eine absolute Katastrophe. Ich bin es gewohnt mir Sachverhalte anzulesen, gute Dokumentationen zu haben oder in Man-Pages herumzusuchen. Fündig werde ich eigentlich immer. Nicht jedoch zu Exchange... Gibt es irgendwo eine gescheite Übersicht wo ich ablesen kann, was ich für welchen Dienst brauche?

 

Über DNS, AD-Anbindung und sonstige Basics gehts gar nicht, es geht explizit um notwendige Netzwerkverbindungen für den reibungslosen Betrieb des Exchanges an sich.

 

Los geht es hiermit:

https://docs.microsoft.com/de-de/exchange/plan-and-deploy/deployment-ref/network-ports?view=exchserver-2019

 

Interessant, Microsoft nennt einige Ports, vergisst aber mal, dass für den Frontend Transport Service, Transport Service und Mailbox Transport Service weitere Ports benötigt werden (mind. 2525, 465, 475, 745 und ggf. 717 und 587). Das habe ich aus einer Drittquelle, auf die ich mich eigentlich nicht verlassen möchte. Zu erwarten wäre, dass Microsoft das in einem entsprechenden Artikel erwähnen würde, dem ist aber leider nicht so:

https://docs.microsoft.com/de-de/exchange/mail-flow/mail-flow?view=exchserver-2019

 

Für den Witness brauche ich wohl SMB 445, aber in welche Richtung lässt Microsft offen:

https://docs.microsoft.com/de-de/exchange/high-availability/manage-ha/manage-dags?view=exchserver-2019

 

Für die DAG brauche ich TCP 64327, Richtung auch nicht ganz klar:

https://docs.microsoft.com/de-de/exchange/high-availability/manage-ha/manage-ha?view=exchserver-2019

 

Für Clusterdienste kommt noch was dazu, Port UDP+DTLS+TCP 3343, TCP 135, UDP 137, UDP 1024-65535, UDP 49152-65535 (das ist doch bereits bei 1024-65535 enthalten?!):

https://docs.microsoft.com/de-de/troubleshoot/windows-server/networking/service-overview-and-network-port-requirements

 

 

Über die Notwendigkeit von TCP 444 bin ich jetzt auch schon gestolpert, habe aber den Hintergrund noch nicht identifiziert.

 

Ich kann mir nicht vorstellen, dass jeder Exchange Admin sich quer verteilt über das Internet alle Netzwerk-Anforderungen zusammensuchen muss. Auf Trial-and-Error hab ich ehrlich gesagt bei so einem teuren Produkt kein Interesse.
Vielleicht bin ich da von Unix und OpenSource zu sehr verwöhnt, dass alles gescheit dokumentiert ist, oder der Hase läuft bei Microsoft anders und ich suche nur an der falschen Stelle. Ich kann natürlich nicht ausschließen, dass meine Informationsbeschaffung für MS-Produkte nicht gut ist, aber das Internet kann ich eigentlich bedienen....

 

Für Hilfe wäre ich sehr dankbar!

 

eotil

bearbeitet 9. März 2021 von eotil

[NorbertFe 2.034]

vor 2 Stunden schrieb eotil:

Netzwerktechnisch ist mir das aber zu offen und das soll nun restriktiver gehandhabt werden. Leider suche ich mir im Internet die Finger wund, welche Ports nun für einen reibungslosen Betrieb wirklich gebraucht werden.

Ohne jemanden auf den Schlips treten zu wollen, aber die Dokumentation von Microsoft ist eine absolute Katastrophe. Ich bin es gewohnt mir Sachverhalte anzulesen, gute Dokumentationen zu haben oder in Man-Pages herumzusuchen. Fündig werde ich eigentlich immer. Nicht jedoch zu Exchange... Gibt es irgendwo eine gescheite Übersicht wo ich ablesen kann, was ich für welchen Dienst brauche?

 

Über DNS, AD-Anbindung und sonstige Basics gehts gar nicht, es geht explizit um notwendige Netzwerkverbindungen für den reibungslosen Betrieb des Exchanges an sich.

Ohne das jetzt zu bewerten, aber die Aussage die ich kenne (und ja die kommt noch aus 2010er Zeiten), ist: Stelle keine Firewall zwischen Exchangeserver und keine zwischen DomainController und Exchange bzw. wenn dann darf kein Traffic geändert oder geblockt werden.

Und wenn man das "annimmt", dann ist es ganz einfach. Du kommst mit den Client Ports zum CAS (https, IMAP, IMAPs, POP3, POP3s und SMTP 25, 587) alles andere passiert dann "in einer Blackbox" firewalltechnisch gesehen. Deswegen stehen die Exchangeserver und dazugehörige DCs eigentlich auch getrennt vom Rest. Das betrifft dann deine Replikationsports (DAG, Kerberos usw.).

Man kann sich jetzt natürlich hinsetzen und das mitschneiden und hoffen, dass man es hinbekommt, aber das hilft dir halt immer nur bis zum nächsten Problem. Meine Empfehlung wäre also, schotte lieber die Exchangeumgebung vom Rest ab als die Exchangekommunikation zwischen Exchange und beteiligten Systemen zu restriktieren. Das hilft am Ende dann sowieso nicht wirklich weiter.

 

Solltest du es hinbekommen, dann Glückwunsch. :)

 

 

[MrCocktail 192]

Hi,

 

die Aussage von @NorbertFe ist fast korrekt (war ab 2007) und auch für die aktuellen Exchange Server so, zwischen den Exchange Servern einer Site und den dazugehörigen DCs darf keine Firewall stehen, dieses ist weder supportet, noch wirklich sinnvoll.

Und ja, als Linux Admin ist das wahrscheinlich eine entsprechende Umstellung.

 

siehe

Zitat

Starting with Exchange Server 2007 and current as of Exchange Server 2013, having network devices blocking ports/protocols between Exchange servers within a single organization or between Exchange servers and domain controllers in an organization is not supported. A network device may sit in the communication path between the servers, but a rule allowing “ANY/ANY” port and protocol communication must be in place allowing free communication between Exchange servers as well as between Exchange servers and domain controllers.

https://techcommunity.microsoft.com/t5/exchange-team-blog/exchange-firewalls-and-support-8230-oh-my/ba-p/595710

 

und bevor du sagst, das ist keine Microsoft Quelle, das ist das Dev Team