Hallo,
Nein, das kann man so pauschal nicht sagen.
Zum Einen bringt der (immer noch sehr gut gepflegte) Exchange 2010 Technologien mit, die der 2016er nicht kennt. Denkbar ist, dass Systeme (CRM, Datensicherung, Archiv usw. usf.) über RPC o.Ä. angeflanscht sind.
Der Exchange 2016 unterstützt zudem nicht alle Clients.
Weiterhin gibt es Szenarien, wo man einen Exchange 2010 nicht "mal so eben" ablöst - wie zum Beispiel beim SBS2011. DAGs, CAS-Arrays usw. benötigen ebenfalls eine gesonderte Betrachtung.
Und letztendlich sollte man auch immer einen Blick auf den Datenschutz werfen. Idealerweise in Abstimmung mit dem Betriebsrat. Gerade beim 2016er geht ja doch Einiges in Richtung Office365 usw.
...nur wurde im gesamten Kontext hier nie(!) von selbstsignierten Zertifikaten gesprochen sondern immer nur von Zertifikaten, die von deiner (zugegebenermaßen selbst erstellten) Stammzertifizierungsstelle signiert wurden.
Diese ist grundlegender Bestandteil deiner eigenen Infrastruktur. Wenn Du tatsächlich nicht mal deinem AD vertraust, solltest Du dir einen neuen Administrator suchen
Der MX hat damit nichts zu tun. Dieser entscheidet, wohin E-Mails "von extern" landen.
Wenn Du direkt über Port 25 annimmst, dann ja. In dem Fall bedarf der Exchange-Server einer jedoch permantenten Überwachung. Sprich: Das lohnt sich frühestens dann, wenn Du einen Administrator hast, der sich exklusiv um nichts Anderes kümmert.
Für den Server, "den man mal irgendwo hinstellt und nebenbei mitlaufen lässt" wäre das - sicherheitstechnisch - der helle Wahnsinn. Des Weiteren sollte man sich dann auch mit diversen Antispam-Mechanismen (SPF-Records usw.) auseinandersetzen. Meiner Meinung nach kann man das mit ruhigem Gewissen dem ISP überlassen.
Gibt es bei LE sogar kostenlos. Zumal man sich bewusst sein sollte, dass man da eine Abhängigkeit schafft. Zu erwähnen wäre auch, dass es (Zertifikats-)Anbieter gibt, die sicherheitstechnisch bereits gehörig auf die Nase gefallen sind. Zum Beispiel Symantec.
Das macht man so nicht. Man nimmt natürlich ein Wildcard-Zerfitikat.
Zum Einen, weil man so z.B. mit einem reversen Proxy weitere Dienste und Hostnamen über HTTPs erreichbar machen kann. Zudem kann man dann extern mit einem öffentlichen Zertifikat arbeiten und intern gleichzeitig von der automatischen Zertifikatserneuerung profitieren
Zum Anderen, weil weil derartige Zertifikate Rückschlüsses auf die Infrastruktur zulassen. Security by obscurity funktionert natürlich nicht. Dennoch sollte man nur die Informationen öffentlich(!) verteilen, die zwingend benötigt werden.
Anzumerken ist auch, dass man vorab die internen und externen URIs gleichsetzen sollte.
Und genau da sehe ich die Gefahr. Dein Beitrag entspricht den Beobachtungen von jemanden, der sich "mal eben intuitiv durch alle Menüpunkte durchgeklickt hat". Die ausgebildete und erfahrene Fachkraft macht es anders
Ich persönlich setze z.B. grundsätzlich einen Apache als reversen Proxy davor.
Das ist nicht notwendig. Clients, die GPOs ziehen, sind sowieso im AD und kennen das Stammzertifikat "sowieso". Ob Du jetzt auch noch das Exchange Zertifikat verteilst, dürfte spätestens bei der automatischen Erneuerung maximal eine zusätzliche Fehlerquelle sein. Wobei Windows eigentlich intelligent genug ist, das neueste Zertifikat automatisch zu erkennen und die abgelaufenen zu ignorieren^^
Bei mir nicht - und ich habe auch "alles Richtig gemacht" und bin sogar der "best practice" von Microsoft gefolgt
Es ist sehr nett, dass Du versuchst, hier zu unterstützen. Aber, wie gesagt - wenn man konsequent ist und Wert auf Nachhaltigkeit, Sicherheit und Integrität legt, läuft es halt anders. Siehe oben
Gruß,
Jörg
