Exchange 2016: Zertifikate konfigurieren (Teil 1)

Mittlerweile erreichen mich täglich Mails mit Fragen zu Zertifikaten und/oder Outlook Anywhere. Wobei auch die Fragen zu Outlook Anywhere meistens ebenfalls auf die Zertifikate zurückzuführen sind. In den meisten Fällen enden die Mails einem Satz ähnlich wie diesem:

Zertifikate sind für mich ein rotes Tuch!

Der Satz stammt aus einer Mail die ich heute erhalten habe. Da wie schon erwähnt diese Mails langsam überhand nehmen, versuche ich mal ein bisschen Licht ins Dunkel zu bringen. Dazu soll dieser Artikel dienen. Dieser Artikel ist bewusst möglichst ausführlich und einfach gehalten und richtet sich an Einsteiger in diesem Thema. Ich hoffe es hilft einigen Leuten.

Noch eine Bitte vorab: Wenn etwas unklar ist, bitte einen Kommentar hinterlassen, damit ich den Artikel entsprechend aktualisieren kann.

Hintergrund: Wie funktionieren Zertifikate

Keine Angst, ich will gar nicht tief ins Detail gehen, sondern nur ganz oberflächlich erklären wie ein Zertifikat funktioniert. Als Beispiel nehmen wir mal einen Personalausweis. Ein Personalausweis enthält Daten zu meiner Person um diese zu identifizieren, also beispielsweise den Namen, ein Foto und eine Unterschrift. Ebenfalls wird ein Personalausweis von einem Land (oder einer Behörde) ausgestellt.

Beispiel Ausweis

Wenn ich die Identität von jemanden mit dem ich gerade rede feststellen möchte, kann ich mir also seinen Personalausweis zeigen lassen und kann die Daten auf dem Ausweis (Foto und Unterschrift) mit meinem Gesprächspartner vergleichen. Stimmen die Merkmale überein, handelt es sich wahrscheinlich um die entsprechende Person. Allerdings muss ich dazu jemandem Vertrauen. Erstens muss ich meinem Gesprächspartner vertrauen, das er den Ausweis nicht gefälscht hat und ich muss dem Staat oder der Behörde vertrauen, dass die Identität meines Gesprächspartners auch wirklich geprüft wurde und somit der Ausweis an sich vertrauenswürdig ist. Mein Gesprächspartner könnte mich ja schließlich auch einen Zettel mit Foto und Unterschrift zeigen, den er eben selbst gemalt hat. Als Ausweis akzeptiere ich das natürlich nicht.

Beispiel Zertifikate

Angenommen ich bin nun keine Person mehr, sondern ein PC der mit einem Server sprechen möchte. Ich als PC bekomme vom Server den Ausweis (Zertifikat) gezeigt. Die Daten auf dem Zertifikat kann ich nun prüfen:

  • Welcher Name steht auf dem Zertifikat?
  • Wer hat es ausgestellt?
  • Sehe ich das Zertifikat als gültig an?

Etwas genauer gesagt: Eine Zertifizierungsstelle (Behörde/Land) stellt ein Zertifikat aus, dieser Zertifizierungsstelle muss ich vertrauen, dass Sie ihre Arbeit gewissenhaft erledigt und die Identität entsprechend geprüft hat. Ein selbst ausgestelltes Zertifikat ähnelt dem selbst gemalten Ausweis. Wenn ich mir als PC in einem der Punkte nicht sicher bin, gebe ich eine entsprechende Warnung aus. Auf die Folgen kommen wir später zu sprechen.

Das soll es auch schon zum Hintergrund gewesen sein. Natürlich ist das Thema Zertifikate etwas komplexer, aber für diesen Artikel soll es erst einmal reichen. Verschlüsselung, Sperrlisten, Algorithmen  und was es noch alles gibt, interessiert hier erst einmal nicht weiter.

Hintergrund: Exchange 2016 und Zertifikate

Ein Exchange Server bietet mehrere Dienste an, die mit Zertifikaten konfiguriert werden können/müssen. Ein Dienst stellt dabei, um beim Beispiel zu bleiben, einen Gesprächspartner dar. Im wesentlichen sind es die folgenden Dienste, die ein Zertifikat (Stichwort Ausweis) benötigen:

  • IIS
  • SMTP
  • IMAP
  • POP

UC lassen wir an dieser Stelle mal außen vor. Jeder dieser Dienste (Gesprächspartner) KANN ein eigenes Zertifikat (Ausweis) erhalten, MUSS aber nicht. Ein Zertifikat kann mehreren Diensten zugeordnet sein, ähnlich wie eine Gesprächspartner der mehrere Sprachen spricht, aber nur einen Ausweis hat.

Eine Besonderheit ist allerdings, dass ein Exchange Server mehrere Namen hat, die auf dem Zertifikat vorhanden sein müssen. Dies ist vergleichbar mit einem zweiten Vornamen auf dem Ausweis.

Beispielumgebung

Um die Sache mit den Ausweisen, äh… Zertifikaten etwas deutlicher zu machen, habe ich eine Beispielumgebung installiert.

Allgemeine Beschreibung

Beispielumgebung

Im wesentlichen besteht die Umgebung aus drei Abschnitten:

  • Einem Benutzer im Home Office (blau)
  • Das Internet mit einem Hoster für das Unternehmen (rot)
  • Das Unternehmen welches den Exchange Server bereitstellt (grün)

Der Benutzer im Home Office hat nur einen normalen Internetanschluss, kein VPN oder sonstiges, nur einen PC mit Outlook.

Das Unternehmen stellt die Exchange Infrastruktur bereit, verfügt also über einen Domain Controller und einen Exchange Server. Ob das Unternehmen nun Domain Controller und Exchange Server auf einer VM oder physikalisch betreibt oder ob es ein Server/VM oder getrennte Server sind, spielt in diesem Beispiel keine Rolle. Das Unternehmen hat ebenfalls Benutzer die auf Exchange zugreifen innerhalb des eigenen LANs.

Das Unternehmen hat einen Hoster im Internet damit beauftragt, eine Domain für das Unternehmen zu hosten.

Die Details zum Unternehmen

Der Name dieses fiktiven Unternehmens ist „FrankysWeb“. FrankysWeb hat einen Internetanschluss mit fester IP-Adresse und ein Active Directory welches auf den Namen „frankysweb.local“ hört. Die E-Mail Adressen des Unternehmen enden auf frankysweb.de. Intern sieht das Netzwerk also in etwa so aus:

Unternehmen

  • Name des Active Directory: frankysweb.local
  • Name des Domain Controllers: dc1.frankysweb.local
  • Name des Exchange Servers: EX1.frankysweb.local
  • E-Mail Adresse des internen Benutzers: frank@frankysweb.de
  • Benutzername: frank@frankysweb.local
  • Feste externe IP-Adresse: 81.169.145.159

Der Benutzer Frank nutzt ein Notebook und ist sowohl intern im Unternehmen als auch im Home Office tätig.

Die Details zum Hoster im Internet

Das fiktive Unternehmen FrankysWeb hat den Hoster Strato damit beauftragt die Domain frankysweb.de zu hosten.

Internet

Strato hostet ebenfalls die Website des Unternehmens und betreibt die DNS-Server für frankysweb.de

Die Details zum Home Office

Das Home Office wird gern vom Benutzer Frank genutzt, hier ist nur ein normaler Internetanschluss, ohne feste IP, oder sonstige Konfiguration. Es wird kein VPN genutzt, aber Mails sollen im Home Office bearbeitet werden können.

HomeOffice

Frank möchte dazu Outlook Anywhere vom PC aus benutzen und ActiveSync vom Smartphone. Wenn es schnell gehen muss, nutzt er auch Outlook Web Access. Frank möchte auf keinen Fall einen dieser Fehler sehen:

image

Und auch die folgenden Fehler möchte Frank nicht zu Gesicht bekommen:

image

Vorkonfiguration der Beispielumgebung

Bisher sind nur der Domain Controller für die Domain frankysweb.local und der Exchange 2016 Server installiert. Auf dem Exchange Server gibt es nur eine akzeptierte Domain, sowie das Postfach für Frank und eine Adressrichtlinie, die dem Postfach für Frank die E-Mail Adresse frank@frankysweb.de zuweist. Mehr ist bisher nicht konfiguriert worden. Der Vollständigkeit halber hier einmal die Screenshots:

image

image

Die Beispielumgebung ist also mehr oder weniger eine grüne Wiese. So oder so ähnlich werden aber die meisten Umgebungen in den Mails geschildert, in denen es immer wieder Probleme mit Zertifikaten gibt:

  • Active Directory Domain Name endet auf .local oder ähnlichem
  • Es gibt einen Domain Controller und einen Exchange Server bzw. Exchange und Domain Controller laufen auf einem Server (ungünstig, aber für diesen Artikel nicht von Bedeutung)
  • Ein Internet Anschluss mit fester IP ist vorhanden
  • Ein Hoster (Strato, 1und1 HostEurope, etc) hosten die Mail Domain

Die Anforderungen sind dann schnell definiert:

  • Outlook Anywhere soll/muss funktionieren
  • Keine Zertifikatswarnungen mehr

Dieser Artikel soll dabei helfen diese Anforderungen umzusetzen, und gilt für Exchange 2013 und Exchange 2016 und entsprechend unterstützten Outlook Versionen.

Exchange in der Standardkonfiguration

Während der Exchange Installation wird bereits ein Zertifikat installiert und den Exchange Diensten zugewiesen. Dabei handelt es sich um ein Selbstsigniertes Zertifikat, wie diesem aus der Beispielumgebung:

image

Das Standard Zertifikat der Beispielumgebung, welches bei der Installation geniert wird, schaut im Browser dann wie folgt:

image

Der Exchange Server hört auf den Namen EX1 und hat sich daher ein Zertifikat mit dem Namen EX1 selbst ausgestellt, dies wird im Screenshot oben deutlich (Ausgestellt für EX1, Ausgestellt von EX1). Um bei dem Ausweisbeispiel zu bleiben: Dies ist der handgemalte Ausweis, kein offizielles Dokument einer Behörde, sondern eher vergleichbar mit einer Visitenkarte. Auf Visitenkarten kann jeglicher Unsinn stehen, niemand kann es prüfen, ob es auch stimmt.

Eine kleiner Besonderheit wird in diesem Screenshot sichtbar:

image

Das Standard Zertifikat enthält bereits zwei Namen (DNS-Name), einmal den Shortname (UNC-Name) und einmal den FQDN. Bei den Standard Zertifikat handelt es sich somit schon um ein SAN-Zertifikat (Subject Alternate Name). SAN hat in diesem Fall nichts mit Storage Netzwerken zu tun, sondern bezeichnet einen Zertifikatstyp. Hier werden mehrere Namen auf einem Zertifikat hinterlegt. Im Screenshot oben sind das die Namen EX1 und EX1.frankysweb.local. Wieder zurück zu den Ausweisen: Hier wurde Vorname und zweiter Vorname angegeben, oder Vor- und Zuname, aber das ist Haarspalterei.

Ein Client, der sich mit diesem Exchange Server verbindet wird die folgende Fehlermeldung im Browser bekommen:

image

Ob Internet Explorer, Edge, Chrome, Firefox ist erst einmal egal, die Fehlermeldung sieht überall ähnlich aus:

image

Warum der Fehler auftritt ist schnell erklärt: Der selbstgemalte Ausweis ist Schuld, zwar steht auf dem Ausweis ein Name, aber niemand hat überprüft und verifiziert, dass dieser Name auch wirklich stimmt. Vereinfacht erklärt: Bei unserer Ausweiskontrolle versucht sich hier jemand gerade mit einer Visitenkarte auszuweisen.

Jetzt stellt sich natürlich die Frage, wer denn überhaupt berechtigt ist, gültige Zertifikate (Ausweise) auszustellen?

Die Zertifizierungsstelle (Beispiel: Behörde/Land)

Damit ein Zertifikat als gültig angesehen wird, muss also nicht nur der Name auf dem Zertifikat stimmen, sondern es muss auch von einer vertrauenswürdigen Stelle ausgestellt worden sein. Eine Visitenkarte reicht also nicht, ein Personalausweis, der von einem Land oder entsprechender Behörde ausgestellt wurde, ist viel vertrauenswürdiger. Die Zertifizierungsstellen übernehmend das Ausstellen der Zertifikate und sind in diesem Beispiel vergleichbar mit einem Land oder Behörde. Im folgenden Beispiel hat die Zertifizierungsstelle (CA) Wosign (Roter Kasten) ein Zertifikat für mail.frankysweb.de (Blauer Kasten) ausgestellt:

Zertifikate

In den Screenshot oben ist auch zu sehen, dass Zertifizierungsstellen häufig mehrstufig aufgebaut sind. Die Stammzertifizierungsstelle (Root-CA, im Beispiel das Land) hat eine Zwischenzertifizierungsstelle (Sub-CA, im Beispiel Behörde) signiert, damit die Zwischenzertifizierungsstelle für den Server mail.frankysweb.de (im Beispiel die Person) ein Zertifikat ausstellen kann. Da sich das Zertifikat der Stammzertifizierungsstelle im Windows Zertifikatsspeicher befindet, werden entsprechende Zertifikat als vertrauenswürdig anerkannt, sofern der Name stimmt und das Zertifikat nicht abgelaufen ist.

Wie schon erwähnt befinden sich die Stammzertifizierungsstellenzertifikate im Windows Zertifikatsspeicher, in diesem Speicher befinden sich eine ganze Reihe offizieller Zertifizierungsstellen, die alle ein Prüfungsverfahren durchlaufen haben, um sicherzustellen, dass nur berechtigte Inhaber ein Zertifikat ausgestellt bekommen. Im folgenden Beispiel findet sich das Zertifikat für WoSign:

image

Die meisten Windows Programme greifen auf den Windows Zertifikatsspeicher zurück um Zertifikate zu prüfen. Eine bekannte Ausnahme bildet hier der Browser Firefox. Firefox bringt seine eigene Zertifikatsverwaltung mit.

Überlegungen zur Exchange Konfiguration

Wie bereits oben beschrieben, reicht das Zertifikat der Standard Exchange Konfiguration nicht aus und muss ausgetauscht werden. Da auf einem Zertifikat aber DNS-Namen (wie Namen auf einem Ausweis) angegeben werden müssen, muss zunächst einmal überlegt werden, über welche DNS-Namen und Protokolle die verschiedenen Programme und Geräte auf den Exchange Server zugreifen werden. In kleinen Umgebungen ist diese Planung recht schnell erledigt, da sich nahezu alles über einen einzelnen DNS-Namen realisieren lässt, Autodiscover bildet allerdings eine Ausnahme: Die folgende Tabelle stellt einmal die Standardkonfiguration dar:

Dienst / Protokoll DNS-Name
OWA (Interne URL) https://ex1.frankysweb.local/owa
OWA (externe URL) https://ex1.frankysweb.local/owa
OAB (interne URL) https://ex1.frankysweb.local/OAB
OAB (externe URL) (leer)
ActiveSync (interne URL) https://ex1.frankysweb.local/Microsoft-Server-ActiveSync
ActiveSync (externe URL) (leer)
MAPI (interne URL) https://ex1.frankysweb.local/mapi
MAPI (externe URL) (leer)
EWS (interne URL) https://ex1.frankysweb.local/EWS/Exchange.asmx
EWS (externe URL) (leer)
ECP (interne URL) https://ex1.frankysweb.local/ecp
ECP (externe URL) (leer)
Outlook Anywhere (Intern) ex1.frankysweb.local
Outlook Anywhere (extern) (leer)
Autodiscover (Intern) https://ex1.frankysweb.local/Autodiscover/Autodiscover.xml

In der Standardkonfiguration enthalten also alle Zugriffspunkte den internen Servernamen und die externen sind leer. Mit internen Servernamen kann der Benutzer im Home Office natürlich nichts anfangen, wenn er keine VPN Verbindung hat. Weiterhin gilt für Exchange Server 2013 und Exchange Server 2016 die Best Practise interne und externe Zugriffsnamen gleich zu halten.

Wenn es also nur einen Exchange Server im Unternehmen gibt, dann wird dieser Server von internen Benutzern, sowie von externen Benutzern angesprochen werden.

Da wir in diesem Fall ja glücklicher Besitzer einer öffentlichen Domain bei einem Hoster sind, können wir mittels Subdomain einen öffentlichen Namen definieren. Für die Domain frankysweb.de könnte der Exchange Zugriff also über die folgende Subdomain erfolgen: mail.frankysweb.de (Alternativ irgendein anderen Namen den sich die Benutzer gut merken können).

Eine kleine Ausnahme bildet Autodiscover, der Autodiscover Eintrag sollte immer unter autodiscover.domain.tld veröffentlicht werden, die Veröffentlichung von autodiscover unter dem entsprechenden Namen verhindert eine Warnung die einmalig von Outlook angezeigt wird. Für die Domain frankysweb.de wäre der Autodiscover Eintrag also autodiscover.frankysweb.de.

Darauf würde sich unter der Berücksichtigung der Best Practise (interne und externe Namen gleich, keine internen Namen auf öffentlichen Zertifikaten, Autodiscover mit separaten Namen) die folgende Konfiguration ergeben:

Dienst / Protokoll DNS-Name
OWA (Interne URL) https://mail.frankysweb.de/owa
OWA (externe URL) https://mail.frankysweb.de/owa
OAB (interne URL) https://mail.frankysweb.de/OAB
OAB (externe URL) https://mail.frankysweb.de/OAB
ActiveSync (interne URL) https://mail.frankysweb.de/Microsoft-Server-ActiveSync
ActiveSync (externe URL) https://mail.frankysweb.de/Microsoft-Server-ActiveSync
MAPI (interne URL) https://mail.frankysweb.de/mapi
MAPI (externe URL) https://mail.frankysweb.de/mapi
EWS (interne URL) https://mail.frankysweb.de/EWS/Exchange.asmx
EWS (externe URL) https://mail.frankysweb.de/EWS/Exchange.asmx
ECP (interne URL) https://mail.frankysweb.de/ecp
ECP (externe URL) https://mail.frankysweb.de/ecp
Outlook Anywhere (Intern) mail.frankysweb.de
Outlook Anywhere (extern) mail.frankysweb.de
Autodiscover (Intern) https://autodiscover.frankysweb.de/Autodiscover/Autodiscover.xml

Aus dieser Konfiguration ergibt nun das Zertifikat.

Überlegungen für das Zertifikat

Aus der Konfiguration oben ergeben sich schon die Anforderungen für das Zertifikat. Auf einem Zertifikat werden nur die FQDNs (DNS-Namen) angegeben, keine URLs! Daher wird auch ntur ein Zertifikat mit genau zwei Namen benötigt:

  • mail.frankysweb.de
  • autodiscover.frankysweb.de

In diesem Fall wird also ein SAN-Zertifikat (Subject Alternate Name) benötigt, welches die oben angegebenen Namen enthält. Mehr nicht.

Das Zertifikat muss aber von einer Zertifizierungsstelle ausgestellt werden, wenn es als gültig anerkannt werden soll. Es besteht die Möglichkeit selbst eine Zertifizierungsstelle zu betreiben, allerdings lohnt meist der Aufwand in kleinen Umgebungen nicht, denn ein entsprechendes Zertifikat gibt es kostenlos oder auch gegen geringe Gebühr. Hinzu kommt: Eine eigne Zertifizierungsstelle die auf einem Windows Server installiert wird, ist erst einmal nur innerhalb des Active Directory vertrauenswürdig. Ein Smartphone oder ein Client der nicht Mitglied des Active Directory ist, wird das Zertifikat nicht als vertrauenswürdig ansehen und wieder mit den bekannten Fehlern reagieren.

Meine Empfehlung daher: Entsprechendes Zertifikat von einer offiziellen Zertifizierungsstelle beziehen.

Konfiguration Exchange Server

Da dieser Artikel schon recht lang geworden ist, wird die Konfiguration im nächsten Artikel behandelt. Sobald der Artikel online ist, werde ich ihn hier verlinken.

Update: Teil 2 ist inzwischen ebenfalls verfügbar.

15 Gedanken zu „Exchange 2016: Zertifikate konfigurieren (Teil 1)“

  1. Hallo, ich habe alles richtig installiert und konfiguriert aber leider nach Kompletter der Zertifikate, verschwindet sich es und ist nicht mehr sichtbar. Woran liegt es?

    Antworten
  2. Vielen Dank für diese ausführliche Anleitung! Kannst du mir diese Vorgehensweise näher erklären?
    „Weiterhin gilt für Exchange Server 2013 und Exchange Server 2016 die Best Practise interne und externe Zugriffsnamen gleich zu halten.“
    Mit welchen Folgen ist zu rechnen, wenn man logischerweise die internen und externen Adressen entsprechend einträgt?

    Mit freundlichen Grüßen
    René

    Antworten
  3. Hallo Frank,

    ich verfolge mit starkem Interesse deine Artikel – auf diesem Weg vielen Dank. Wir müssen unser externes Zertifikat erneuern und stoßen hierbei auf die Frage ob wir bei einem Exchange 2010 auch den von dir vorgeschlagenen Best Practice von MS mit gleichem internen und externen Zugriffsnamen wählen könne oder ob dies ausschließlich bei ESX 2013 / 2016 gilt.

    Danke für die Hilfe!
    Gruß,
    Benny

    Antworten
    • Hi Benny,
      es geht auch mit Exchange 2010, allerdings wäre es hier besser intern einen anderen Namen wie extern zu verwenden (Beispielsweise outlookint.domain.de für intern und Outlook.domain.de für extern). Es funktioniert aber auch wenn du beide Namen gleich hast, allerdings dauert dann der Verbindungsaufbau unter Umständen von extern etwas länger.
      Gruß, Frank

      Antworten
  4. Hallo,
    das ist ein guter Beitrag. Prima.
    Ich habe ein Frage zum Begriff Subdomain. Und das ist meiner Meinung nach nicht Haarspalterei, sondern essentiell. Du nennst „mail.frankysweb.de“ eine Subdomain. Meiner Meinung nach ist es das nicht. testlabor.frankysweb.de wäre m.M.n. eine Subdomain, wenn sich dahinter Rechnernamen EXTEST.testlabor.frankysweb.de befinden. Eine Domain, und damit auch eine Subdomain ist doch nur das Verzeichnis, in dem Hostnamen eingetragen werden.
    Ich beschäftige mich schon sehr viele Jahre mit Netzwerktechnologien, und interessanterweise werde ich ab etwa einem Jahr immer mal wieder damit konfrontiert, dass Menschen FQDN als Subdomains bezeichnen. Ist das jetzt eine schleichende Unkorrektheit, wie es in der deutschen Sprache ja auch immer wieder vorkommt, und irgendwann ist es dann per DUDEN erlaubt? Oder ist es tatsächlich falsch? Ich glaube, letzteres. Weiss es jemand genau?
    MfG, Frank Pusch

    Antworten
    • Hi Frank,
      du hast vollkommen Recht. Ich habe den Begriff Subdomain nicht ganz unbewusst gewählt. es gibt einige Hoster die zwar eine Subdomain zulassen, innerhalb der Subdomain lässt sich dann allerdings nur die Möglichkeit einen HOST-A nur mit der IP zu vergeben. Im zweiten Teil wird der interne DNS und auch der externe DNS entsprechend konfiguriert, sodass der Name der Subdomain gleichzeitig der FQDN des Servers ist.
      Ich werde das bei der Überarbeitung der Artikel deutlicher machen. Vielen Dank für deinen Hinweis.
      Gruß, Frank

      Antworten
    • Hallo Frank,

      die Begriffe SubDomain, HostName, FQDN usw. bringen fast alle Menschen (auch IT’ler und vor allem Hoster wie 1&1, etc.) durcheinander.

      Beispiel für einen HostName bzw. FQDN : autodiscover.domain.tld oder http://www.domain.tld oder mail.domain.tld
      Beispiel für eine SubDomain : .subdomain.domain.tld oder .subdomain.subdomain.domain.tld
      Beispiel für einen Host in einer SubDomain : autodiscover.subdomain.domain.tld

      Gruß
      Franz

      Antworten
  5. Du hast das perfekt beschrieben, hätte es nicht besser machen können… ;-)

    Bin auf Teil 2 gespannt. Hier mal Vorweg einen günstigen SAN-Zertifikatsanbieter http://www.psw.net. Bestelle seit Jahren bei ihm die Zertifikate Bronze (Multidomain-Zertifikat) 99€ für 3 Jahre (3 FQDN’s).

    Gruss Dave

    Antworten
  6. Danke für diesen klasse geschriebenen Beitrag.
    In unserem KMU hab ich grad das Problem – neuinstallierter EX13 – das es mir die Fehlermeldungen nur so um die Ohren haut. Allerdings kommt bei uns noch dazu, dass die INTERNE DOMAIN (.de) auch eine EXTERNE ist, diese jedoch nicht zu unserem Unternehmen gehört. Bin auf deinen zweiten Teil gespannt, dann werde ich das bei uns auch mal angehen.
    Vielen Dank.
    Gruß Swen

    Antworten
  7. Hallo Franky,
    ein interessanter Artikel. Hätte es den früher gegeben… dann hätte ich mir viel Arbeit erspart.
    Wie ist es aber, wenn ein Exchange Server nicht eine Domain sondern viele verwalten soll:
    mail.dom1.de
    autodiscover.dom1.de
    mail.dom2.de
    autodiscover.dom2.de

    mail.dom99.de
    autodiscover.dom99.de

    Dann brauche ich ein SAN Zertifikat für 99*2=198 Namen. Wenn das technisch überhaupt geht – dann ist es nicht bezahlbar.
    Ich habe aber schon vielfach gelesen, dass man das mit einem DNS-Eintrag (Dienstindentivizierung SRV)umgehen könnte. Leider klappt das bisher nicht wie gewünscht…

    Danke in jedem Fall.

    Manfred Bauer

    Antworten

Schreibe einen Kommentar