Lampe2010 10 Geschrieben 18. April 2013 Melden Teilen Geschrieben 18. April 2013 (bearbeitet) Hallo, ich bin gerade dabei von Exchange 2010 auf Exchange 2013 umzustellen und habe in diesem Zusammenhang ein paar fragen. Meine Aktuelle Situation sieht wie folgt aus: Bisher haben wir eine interne PKI betrieben. Diese PKI wollen wir nun außer betrieb nehmen. Wir wollen vom selbst erstellten Zertifikat auf ein Offizielles Zertifikat umstellen. Unsere Domain wird extern gehostet Unser DNS wird extern gehostet und die DNS Einträge werden auf unsere externen IP umgeleitet. Als Beispiel sehen unsere DNS Einträge beim Provider wie folgt aus:IP : 111.111.111.xxx = IP Adressen beim HosterIP: 233.233.233.xxx = Unsere Öffentlichen IPs ANMERKUNG : Die Firewall antwortet bei https noch vor dem Exchange mit einem eigenen selbst erstellten Zertifikat und dieses lässt sich leider nicht umstellen. autodiscover A 233.233.233.234 download A 233.233.233.232 ftp A 111.111.111.130 gateway A 111.111.111.129 localhost A 127.0.0.1 mail A 233.233.233.234 remote A 233.233.233.239 support A 233.233.233.238 meinedomain.com. A 111.111.111.126 www A 111.111.111.126 meinedomain.com. NS 1dns.isp.com. meinedomain.com. NS 2dns.isp.com. mail MX 10 Wir wollen folgendes mit Zertifikaten abdecken : Ticketsystem : support - 233.233.233.238 ( Bei uns im Haus gehostet ) Fernwartung : remote - 233.233.233.239 ( Bei uns im Haus gehostet ) Exchange 2013 - 233.233.233.234 ( Bei uns im Haus gehostet ) Frage ist nun was für ein Zertifikat oder Zertifikate (wie sinnvoll ist eine Trennung von Exchange und den anderen Diensten im Zertifikat ? ) ich benötige und wie die Einträge im Zertifikat aussehen müssen. Für den Exchange 2013 habe ich bei uns im DNS schon die Zonen owa.meinedomain.com und autodiscover.meinedomain.com mit Host A Eintrag auf den Exchange gesetzt, so das trotz interner .local Domain das Zertifikat auf meinedomain.com aufgelöst wird und auch interne Clients die xxx.meinedomain.com anstatt xxx.meinedomain.local hernehmen. bearbeitet 18. April 2013 von Lampe2010 Zitieren Link zu diesem Kommentar
RobertWi 81 Geschrieben 18. April 2013 Melden Teilen Geschrieben 18. April 2013 Moin, Unsere Domain wird extern gehostet Unser DNS wird extern gehostet und die DNS Einträge werden auf unsere externen IP umgeleitet. Als Beispiel sehen unsere DNS Einträge beim Provider wie folgt aus:IP : 111.111.111.xxx = IP Adressen beim HosterIP: 233.233.233.xxx = Unsere Öffentlichen IPs Zu DNS-Einträgen gehören i.d.R. auch Namen, nicht nur IP-Adressen. ANMERKUNG : Die Firewall antwortet bei https noch vor dem Exchange mit einem eigenen selbst erstellten Zertifikat und dieses lässt sich leider nicht umstellen. Ich denke nicht, dass das nicht anpassen kann. Vermutlich ist das die Management-Oberfläche, die von Extern nicht erreichbar sein sollte und auf einen andere Port umgestellt werden sollte. Aber Exchange-Technisch ist das eigentlich egal, solange es sich bei der Firewall nicht noch um einen Proxy handelt. Port 443 an Exchange weiterleiten, fertig. Wir wollen folgendes mit Zertifikaten abdecken : Ticketsystem : support - 233.233.233.238 ( Bei uns im Haus gehostet ) Fernwartung : remote - 233.233.233.239 ( Bei uns im Haus gehostet ) Exchange 2013 - 233.233.233.234 ( Bei uns im Haus gehostet ) In Ein Zertifikat komme NAMEN, keine IP-Adressen (obwohl in SAN auch IP-Adressen gehen, aber wer will in der Webseite einen Dienst per IP-Adresse aufrufen?). Frage ist nun was für ein Zertifikat oder Zertifikate (wie sinnvoll ist eine Trennung von Exchange und den anderen Diensten im Zertifikat ? ) ich benötige und wie die Einträge im Zertifikat aussehen müssen. Leider kann man diese Frage nicht schlecht in einem Forum beantworten, weil man dafür deutlich mehr Infos braucht und das den Rahmen eines Forums sprengen würde. Zu klären wären alle Web-Dienste, die Geräte, die auf Exchange Zugriff haben sollen, ob SplitDNS eingesetzt wird, oder nicht, oder der externe DNS SRV-Einträge kann (beim ISP nicht unbedingt üblich), usw. usf. Am besten setzt Du Dich also zuerst mal hin und machst eine ordentliche Bestandserhebung. Für den Exchange 2013 habe ich bei uns im DNS schon die Zonen owa.meinedomain.com und autodiscover.meinedomain.com mit Host A Eintrag auf den Exchange gesetzt, so das trotz interner .local Domain das Zertifikat auf meinedomain.com aufgelöst wird und auch interne Clients die xxx.meinedomain.com anstatt xxx.meinedomain.local hernehmen. Ok, das deutet dann auch SplitDNS hin. Dann "reichen" für Exchange die beiden von Dir genannten Namen. Autodiscover kann man noch weglassen, wenn man SRV-Einträge setzt und mobile Geräte von Hand konfigurieren will. Ansonsten wie immer: Viel Spaß mit Ex 2013 und den 2010er nicht zu schnell deinstallieren. ;) Zitieren Link zu diesem Kommentar
Lampe2010 10 Geschrieben 18. April 2013 Autor Melden Teilen Geschrieben 18. April 2013 Hallo Robert,danke für deine schnelle Antwort zu meinem Post.Anbei meine Antworten : Zu DNS-Einträgen gehören i.d.R. auch Namen, nicht nur IP-Adressen. Habe hierbei die IP Range angegeben die mir vom ISP zugewiesen wurden, natürlich gibt es hierzu auch namen, die stehen weiter unten drin. ANMERKUNG : Die Firewall antwortet bei https noch vor dem Exchange mit einem eigenen selbst erstellten Zertifikat und dieses lässt sich leider nicht umstellen. Ich denke nicht, dass das nicht anpassen kann. Vermutlich ist das die Management-Oberfläche, die von Extern nicht erreichbar sein sollte und auf einen andere Port umgestellt werden sollte. Aber Exchange-Technisch ist das eigentlich egal, solange es sich bei der Firewall nicht noch um einen Proxy handelt. Port 443 an Exchange weiterleiten, fertig. Port 443 ist umgeleitet und hat bisher auch funktioniert, nervig ist halt nur die Zertifikats Warnung der Firewall, diesbezüglich habe ich schon ein Ticket bei dem Hersteller aufgemacht, da dazu nichts in der Doku steht. Lampe2010, am 18 Apr 2013 - 10:56, sagte:Wir wollen folgendes mit Zertifikaten abdecken : Ticketsystem : support - 233.233.233.238 ( Bei uns im Haus gehostet )Fernwartung : remote - 233.233.233.239 ( Bei uns im Haus gehostet )Exchange 2013 - 233.233.233.234 ( Bei uns im Haus gehostet ) In Ein Zertifikat komme NAMEN, keine IP-Adressen (obwohl in SAN auch IP-Adressen gehen, aber wer will in der Webseite einen Dienst per IP-Adresse aufrufen?). Ist mir schon soweit klar, ich habe hier nur die IP Adressen mit aufgelistet damit man sieht ob es der ISP Hoster oder unsere externen IPs sind. Lampe2010, am 18 Apr 2013 - 10:56, sagte:Frage ist nun was für ein Zertifikat oder Zertifikate (wie sinnvoll ist eine Trennung von Exchange und den anderen Diensten im Zertifikat ? ) ich benötige und wie die Einträge im Zertifikat aussehen müssen. Leider kann man diese Frage nicht schlecht in einem Forum beantworten, weil man dafür deutlich mehr Infos braucht und das den Rahmen eines Forums sprengen würde. Zu klären wären alle Web-Dienste, die Geräte, die auf Exchange Zugriff haben sollen, ob SplitDNS eingesetzt wird, oder nicht, oder der externe DNS SRV-Einträge kann (beim ISP nicht unbedingt üblich), usw. usf. Am besten setzt Du Dich also zuerst mal hin und machst eine ordentliche Bestandserhebung. Ok, da ich mich selber nicht all zu gut damit auskenne, werde ich das so machen.Meine Frage zielte auch mehr darauf ab, ob ich für den Exchange lieber 1 Zertifikat erstellen soll und für die anderen Dienste dann separate Zertifikate.Habe mich da wahrscheinlich etwas unklar ausgedrückt. Lampe2010, am 18 Apr 2013 - 10:56, sagte:Für den Exchange 2013 habe ich bei uns im DNS schon die Zonen owa.meinedomain.com und autodiscover.meinedomain.com mit Host A Eintrag auf den Exchange gesetzt, so das trotz interner .local Domain das Zertifikat auf meinedomain.com aufgelöst wird und auch interne Clients die xxx.meinedomain.com anstatt xxx.meinedomain.local hernehmen. Ok, das deutet dann auch SplitDNS hin. Dann "reichen" für Exchange die beiden von Dir genannten Namen. Autodiscover kann man noch weglassen, wenn man SRV-Einträge setzt und mobile Geräte von Hand konfigurieren will. Jepp, habe Split DNS eingeführt, vorher hatte wie dies anders gelöst, was auch ging aber Split DNS ist doch um einiges komfortabler :-) Ansonsten wie immer: Viel Spaß mit Ex 2013 und den 2010er nicht zu schnell deinstallieren. ;) Hm, was meinst Du damit ? Sind dir Probleme bekannt auf die ich unbedingt achten sollte ? Geh nach der MS Anleitung vor. Zitieren Link zu diesem Kommentar
RobertWi 81 Geschrieben 18. April 2013 Melden Teilen Geschrieben 18. April 2013 Port 443 ist umgeleitet und hat bisher auch funktioniert, nervig ist halt nur die Zertifikats Warnung der Firewall, diesbezüglich habe ich schon ein Ticket bei dem Hersteller aufgemacht, da dazu nichts in der Doku steht. Aber die sieht ja normalerweise niemand. Nur der Admin, der sich auf die Mangement-Webseite der Firewall bewegt. Und da kann ich mit einer Warnung leben, wie oft bin ich da schon. Ok, da ich mich selber nicht all zu gut damit auskenne, werde ich das so machen. Meine Frage zielte auch mehr darauf ab, ob ich für den Exchange lieber 1 Zertifikat erstellen soll und für die anderen Dienste dann separate Zertifikate. Im Prinzip kannst Du das halten, wie der berühmte Dachdecker - und am Ende ist es auch eine Kostenfrage. Ein Zertifikat mit nur einem Namen ist billiger, als ein SAN-Zertifikat. Wenn man aber mehrere Namen braucht, ist SAN am Ende billiger, als 10 einzelne Zertifikate. Wenn alles unter einer Hauptdomäne läuft, kannst Du eventuell auch ein Wildcard-Zertifikat einsetzen (d.h. es hört auf "*.deinedomäne.tld"). Exchange kann das, die Frage muss aber geklärt werden, ob es die anderen Dienste auch kenne. Die wichtigste Frage: Wie vertrauenswürdig muss das nach außen sein? Wenn es nur Mitarbeiter und ein paar ausgewählte externe sind, würde ich das sehr einfach halten. Wenn aber viele Kunden ein Zugriff haben, würde ich zumindest für diese Dienste eigene Zertifikate machen. Jepp, habe Split DNS eingeführt, vorher hatte wie dies anders gelöst, was auch ging aber Split DNS ist doch um einiges komfortabler :-) Korrekt. Hm, was meinst Du damit ? Sind dir Probleme bekannt auf die ich unbedingt achten sollte ? Aus meiner Sicht ist Ex 2013 einfach noch nicht marktreif. Das wurde schlicht 6 bis 12 Monate zu früh veröffentlicht. In der internen Maillingliste diskutieren wir eine Menge, lustiger Bugs. Bugs, die aber für manche Kunden sehr schnell zum Show-Stopper werden können (wenn z.B. der Transportdienst einfach aufhört zu funktionieren und nur durch einen Dienstrestart wieder aktiviert werden kann - ärgerlich dabei ist: Die Dienst selbst steht auf gestartet, er funktioniert nur schlicht nicht mehr). Es ist die merkwürdige Bedienoberfläche, wo viele Dinge einfach fehlen (keine Ausgabe der PowerShell-Befehle, z.B.). Es ist das sehr kritische Update-Verhalten der CU, die quasi jedesmal ein Service Pack sind, und besondere Berechtigungen und in vielen Firmen auch besonderes QM brauchen. Es ist die noch nahezu fehlende Drittanbeiter-Unterstützung, also fehlende Virenscanner, Anti-Spam oder Backup Lösungen. Meine Kunden bekommen von mir ganz deutlich gesagt: Testen ja, produktiv noch nicht. Zitieren Link zu diesem Kommentar
Lampe2010 10 Geschrieben 18. April 2013 Autor Melden Teilen Geschrieben 18. April 2013 Hallo Robert, nochmals danke für deine Antworten, soweit sind nun meine fragen geklärt. Wünsche Dir noch einen angenehmen Arbeitstag. Gruß Lampe2010 Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.