Dies ist der letzte Teil der Beitragsserie “Zertifikate konfigurieren” für Exchange Server 2013 und Exchange 2016. Die vorherigen Teile finden sich hier:
Hinweis: Auch dieser Teil baut auf Teil 1 und Teil 2 auf, also bitte unbedingt vorher die ersten beiden Teile lesen.
In diesem Teil geht es um zwei Themen, zum einen die Anbindung weiterer E-Mails Domänen und zum anderen die Punkte die zu beachten sind , wenn eine interne Zertifizierungsstelle anstatt öffentlicher Zertifikate genutzt wird.
Anbindung weiterer E-Mail Domänen
Um es direkt vorweg zu nehmen: Für das Anbinden weiterer E-Mail Domänen, muss das Zertifikat nicht geändert werden.
In Teil 2 wurde das folgende Zertifikat für Exchange Server ausgestellt und nutzbar gemacht:
Als Namen wurden mail.frankysweb.de für die Exchange Benutzerschnittstellen (OWA, ActiveSync, EWS, MAPI) eingetragen und für Autodiscover der Name autodiscover.frankysweb.de. Als E-Mail Domain wird entsprechend @frankysweb.de verwendet.
Nehmen wir mal an, dass neben frankysweb.de und auch firma.de als E-Mail Domain genutzt werden soll. Wie hier zu sehen, gibt es jetzt einen Benutzer mit der E-Mail Adresse hans@firma.de:
firma.de ist dann natürlich auch als akzeptierte Domain angelegt:
Um die Domain firma.de entsprechend auch per Autodiscover erreichbar zu machen sind nur Änderungen am DNS des Hosters und am internen DNS nötig.
Anpassung interner DNS Server
Am internen DNS Server, also normalerweise auf dem Domain Controller, wird eine weitere DNS Zone erstellt:
Als Typ wird wieder “Primäre Zone” ausgewählt:
Die Zone wird auf allen DNS Server ausgeführt:
Als Zonenname wird “firma.de” angegeben:
Dynamische Updates können deaktiviert werden:
Nachdem der Assistent abgeschlossen wurde, gibt es nun eine DNS-Zone mit dem Namen “firma.de”:
Achtung: Hierbei handelt es sich jetzt um eine DNS-Split Brain Konfiguration. Das heißt konkret, der DNS Server ist jetzt für interne Rechner, die den internen DNS Server nutzen für die Zone firma.de authorativ. Versuchen jetzt interne Clients beispielsweise www.firma.de aufzurufen, wird der interne DNS Server mit NXDOMAIN (non existent Domain, gibts nicht) antworten. Der Hintergrund ist einfach: Der Domain Controller geht davon aus, das er der Chef für firma.de ist, da die Zone firma.de wie oben zu sehen keine Einträge enthält (Beispielsweise www) antwortet er mit “Gibt’s nicht”:
Wenn es sich bei www.firma.de nun um einen Webserver beim Hoster handelt der die Firmenwebsite hostet, dann muss dieser Server entsprechend intern bekannt gemacht werden. Nehmen wir an, der Webserver des Hosters hat die IP 12.34.12.34, dann wird nun ein HOST-A Eintrag in der Zone firma.de angelegt:
Nachdem der Eintrag angelegt wurde, ist auch www.firma.de zu erreichen:
Auf diese Weise müssen nun alle externen Server eingetragen werden, beispielsweise shop.firma.de, portal.firma.de oder was es sonst noch geben mag.
Wenn alle externen Ressourcen eingetragen wurden, kann ein Autodiscover Eintrag angelegt werden. Bei dem Autodiscover Eintrag handelt es sich um einen SRV-Record, dieser kann über “Weitere neue Einträge” angelegt werden:
Im Assistenten muss “Dienstidentifizierung (SRV)” ausgewählt werden:
Für den SRV-Record gelten folgende Werte:
- Dienst: _autodiscover
- Protokoll: _tcp
- Portnummer: 443
- Host: autodiscover.FRANKYSWEB.de
Hinweis: Die Unterstriche müssen mit eingegeben werden!
So sieht es nach dem Anlegen des Eintrags aus:
Vereinfacht gesagt haben wir jetzt einen Verweis angelegt, der Outlook mitteilt, dass Autodiscover für firma.de unter autodiscover.frankysweb.de zu erreichen ist. Da autodiscover.frankysweb.de auf dem Zertifikat vorhanden ist, wird Outlook das Zertifikat als gültig akzeptieren.
Auf diese Art und Weise lassen sich beliebige Domains anbinden. Das Zertifikat muss nicht mehr angefasst werden.
Anpassung externer DNS (Hoster)
Die Änderung, wie oben beschrieben, ist für das interne LAN. Damit auch Outlook Anywhere funktioniert, muss ebenfalls ein SRV-Record beim Hoster angelegt werden. Da sich hier die Einrichtung wieder von Hoster zu Hoster unterscheidet, gibt es hier nur ein Beispiel für Strato. Als Beispiel dient hier die Domain “exchange-tools.de” (Denken wir uns einfach exchange-tools.de ist firma.de):
Wenn vorhanden, muss zunächst die Hoster eigene Autodiscover Funktion abgeschaltet werden:
Danach kann in den DNS Einstellungen ein SRV-Record angelegt werden:
Für den SRV-Record sind die gleichen Einstellungen wie für den internen DNS vorzunehmen:
- Service: _autodiscover
- Protokoll: _tcp
- Port: 443
- Ziel: autodiscover.FRANKYSWEB.de
Das war schon alles. Jetzt können Tests folgen.
Outlook Anywhere (Client nicht Mitglied im Active Directory)
Wie eingangs erwähnt, habe ich einen Benutzer “Hans” mit der E-Mail Adresse hans@firma.de angelegt. Wenn Hans nun Outlook auf einem PC nutzen möchte, der NICHT Mitglied des Active Directory ist, dann läuft die Einrichtung wie folgt ab:
Hans startet Outlook beispielsweise im Home Office:
Hans möchte ein E-Mail Konto einrichten:
Hans trägt seinen Namen, E-Mail Adresse und sein Passwort des ActiveDirectory Benutzerkontos ein:
Bei der Konfiguration wird Hans jetzt nach seinem Benutzernamen und Kennwort gefragt, in dem Fall ist es normal:
- Der Benutzername ist nicht hans@firma.de sondern hans@frankysweb.local, Nur die E-Mail Adresse ist hans@firma.de:
- Outlook kann keine Anmeldeinformationen durchreichen, denn der PC befindet sich nicht im ActiveDirectory und Hans ist ein lokaler Benutzer
- Hans muss also seine Anmeldedaten angeben und wird daher gefragt:
Hans muss seine Active Directory Daten angeben:
Hans ist glücklich, ohne Zertifikatswarnungen:
Die Outlook Verbindung läuft nun wie für alle anderen Benutzer gegen den Server mail.frankysweb.de:
Da ein SRV Record gefunden wurde, funktioniert auch Autodiscover problemlos:
Outlook innerhalb des Active Directory
Zum Vergleich hier noch einmal die Einrichtung von Outlook wenn Hans einen PC nutzt der Mitglied des Active Directory ist und Hans sich mit seinem Benutzerkonto angemeldet hat:
Name und E-Mail Adresse wird automatisch ausgefüllt, das Passwort Feld existiert nicht:
Direkte Anmeldung an Exchange, ohne Abfrage von Benutzername und Kennwort und selbstverständlich ohne Zertifikatsfehler:
Auch hier laufen die Verbindungen gegen mail.frankysweb.de
Autodiscover funktioniert ebenfalls ohne Probleme:
Nutzung einer internen Zertifizierungsstelle
Die Einrichtung einer eigenen Zertifizierungsstelle habe ich hier bereits detailliert beschrieben und das HowTo ist ebenfalls für Exchange 2016 gültig, daher spare ich mir an dieser Stelle noch einmal die Konfiguration zu beschreiben:
https://www.frankysweb.de/exchange-2013-san-zertifikat-und-interne-zertifizierungsstelle-ca/
Es gibt allerdings ein paar Punkte zu beachten:
Im oben angegebenen Artikel wird eine interne Zertifizierungsstelle eingerichtet, diese Zertifizierungsstelle generiert sich das Zertifikat selbst. Die Zertifizierungsstelle verfügt also über ein selbst ausgestelltes Zertifikat. Hier ist wieder der Vergleich mit dem Ausweis und der Behörde: Die Zertifizierungsstelle behauptet sie wäre ein Staat/Behörde und stellt entsprechende Ausweise (Zertifikate) aus. Die Frage ist nun wer akzeptiert die Ausweise und die Behörde? Innerhalb des Aktive Directory wird das Zertifikat der Zertifizierungsstelle per Gruppenrichtlinie automatisch verteilt, somit sehen alle Active Directory Mitglieder die Zertifizierungsstelle als vertrauensvolle Behörde an. Alle Clients die nicht Mitglied es Active Directory sind (Smartphones, ggf. HomeOffice, etc) kennen die Behörde nicht und sehen sie daher auch als nicht vertrauenswürdig an, die Ausweise sind damit ebenfalls nicht vertrauenswürdig: Zertifikatsfehler.
Entweder man sorgt nun dafür, dass das Zertifikat der Zertifizierungsstelle auf allen Clients installiert wird, was bei Clients ausserhalb des Active Directory (PCs im HomeOffice, Smartphones, Notebooks, etc) ziemlich viel Arbeit machen kann, oder man investiert direkt ein bisschen Geld in ein entsprechendes Zertifikat einer öffentlichen Zertifizierungsstelle. Ich würde zum öffentlichen Zertifikat raten.
Wer die interne Zertifizierungsstelle auch auf Clients vertrauenswürdig machen möchte, muss das Stammzertifizierungsstellenzertifikat seiner eignen Zertifizierungsstelle auf den Clients installieren.
Installation des Stammzertifizierungsstellenzertifikats unter Windows
Das Stammzertifizierungsstellenzertifikat befindet sich auf der Zertifizierungsstelle im folgenden Ordner:
C:\Windows\System32\CertSrv\CertEnroll
Dieses Zertifikat muss nun auf allen Clients installiert werden:
Das Zertifikat sollte im Speicher für den Computer installiert werden, damit es nicht für jeden Benutzer einzeln installiert werden muss:
Das Zertifikat wird im Zertifikatsspeicher “Vertrauenswürdige Stammzertifizierungsstellen” installiert.
Hinweis: Das Zertifikat des Exchange Servers welches von dieser Zertifizierungsstelle ausgestellt wurde, muss NICHT installiert werden. Alle Zertifikate die von der installierten Zertifizierungsstelle ausgestellt werden, werden akzeptiert. Sofern natürlich die Namen und das Ablaufdatum stimmen.
Übrigens: Firefox bringt seinen eignen Zertifikatsspeicher mit und greift nicht auf den Windows Zertifikatsspeicher zu. Hier muss das Zertifikat gesondert importiert werden.
Hallo Frank,
leider hat wohl Microsoft im Exchange 2016 Cu23 die Möglichkeit zur Erstellung eines Zertifikat Request entfernt.
Es kann jetzt nur noch ein Selbstsignierten Zertifikat über die Admin Webseite erstellt werden.
Anscheinend geht es jetzt nur noch über die Powershell.
Viele Grüße HD
Hallo Franky,
vielen vielen Dank für deine umfangreichen Artikel. Sie sind für mich in vielen Fällen der Erste Anlaufpunkt bei Fragen/Problemen geworden!
Ich habe einen Kunden der (gegen meine Empfehlung) kein Split-DNS einrichten will, weil er ein sehr kompliziertes DNS-Setup (viele DNS-Zonen etc.) hat. Er behandelt das wie seinen Augapfel…
Nun hatten wir einen mehrstündigen Ausfall des Exchange-Servers und das fehlende Split-DNS erschwert die Fehlersuche extrem – man weiß ja nie, welche Folgen letztendlich diese abweichende Konfiguration haben kann.
Meine Idee war, einen Wildcard A-Record zu setzen, der alle Anfragen zur Zone zum DNS-Server des Hosters schickt und nur die anfragen zum Exchange-Server direkt beantwortet. Nach einigem suchen habe ich einen Artikel dazu gefunden:
https://www.itgeared.com/articles/1037-configuring-wildcard-dns-records/
Im MS-Forum wird auch davon berichtet:
https://social.technet.microsoft.com/forums/windowsserver/en-US/75118b80-1031-46c5-bcde-0377ea01569c/dns-wildcard
An sich raten diese davon aber ab…was hältst du davon?
Hallo,
das Zertifikat im Tutorial beinhaltet ja auch beide Domänen: mail. und autodiscover.
Wenn bei dir für „autodiscover.deinedomain.de“ kein Zertifikat vorliegt, wird es wohl auch immmer eine Warnung geben.
Ich verwende deshalb immer ein Wildcard-Zertifikat (*.deinedomain.de).
Dann sind mit einem Zertifikat alle Subdomänen immer korrekt zertifiziert.
Damit kann man dann auch andere Weiterleitungen absichern, wie z.B. vpn.deinedomäne.de, sophos.deinedomäne.de, usw.
Das erspart einem viel Zertifikats-Wirrwarr.
Gruß,
Andreas
Hallo Andreas,
danke für deine Info aber das Zertifikat selbst ist nicht das Problem, ich habe ein Wildcard.
Das Problem ist das Outlook beim Autodiscover die Umlenken erkennt:
– test@anderedomain.de wird im Outlook eingerichtet
– autodiscover.anderedomain.de (ohne zert) verweisst auf autodiscover.hauptdomain.de (mit wildcart)
Wenn ich dann bestätige, dass mein Autodiscover auf eine andere Domain verweisst,.. dann läuft es ohne Zertifikat Fehler. Der umgelengte FQDN passt dann zum Namen des Zertifikats
Drum sagte ich ja, ich finde die Meldung schon logisch,…
Da sie aber im Artikel keine Erwähnung findet, frage ich mich ob es auch ohne diese Meldung geht.
Hallöle,
erstmal vorweg, die ganze Seite mit all ihren Inhalten ist ein Traum.
Dieser Artikel war sehr Hilfreich und kam mir sehr gelegen, da wir für unseren MSP Hosted Exchange vermeiden wollen, das jede Domain ihr eigenes Zertifikat braucht. Leider hat es noch nicht so ganz geklappt.
Alle Clients kommen nur von Extern, drum hab ich mir die DNS Einträge auf dem internen DC gespart.
Nach dem ich nun beim Hoster alle Standard Einträge gelöscht habe und nur die autodiscover umlenkung drin gelassen habe, klappt dieses zumindest, …
Trotzdem kommt bei der Einrichtung vom Outlook der Sicherheitshinweis, dass autodiscover auf einen anderen fqdn verweist, ob man diesem zustimmen möchte. Dieses Verhalten wurde hier im Artikel nur beschrieben wenn ich bei den virtuellen Verzeichnissen den FQDN für autodiscover anpassen würde, was ich nicht gemacht habe.
Daher bin ich nun verunsichert ob ich was falsch gemacht habe, oder hier in dem sonst perfekten Artikel nur der kleine Hinweis fehlt, dass man bei Nutzung mehrerer Domains mit nur einem Zert. mit dieser kleinen Einschränkung leben muss. Logisch wäre es, wenn es zu umgehen ist, wäre aber noch besser. Danke vorab
Super kompetente und verständliche Hilfe auf dieser http://www.frankysweb.de
DANKE, DANKE, DANKE !!!
Hat mir schon öfter das arbeiten erleichtert!
Hallo,
meine Idee macht aber auch keinen Sinn, da ich ohne VPN keine Mails abholen kann.
Also geh ich intern nicht über den Proxy normalerweise. Der Haken bei „Proxy für lokalen Datenverkehr umgehen“ ist auch überall an den Clients gesetzt.
Gruß Jan
Hallo Frank,
der ExChange wurde von einem anderen EDV-Betreuer eingerichtet. Die Zertifikate dienen nur dem Aufruf über Autodiscover.
Ein Proxy wird nur benötigt für den Mailverkehr nach außerhalb.
Ich schaue gerade in meinem Outlook bei „Informationen“. Dort steht Zugriff auf dieses Konto nur über https://autodiscover.***.de. Liegt der Fehler da? Das Outlook zuerst nach außen geht und dann zurück? Weil es immer über den autodiscover geht?
Gruß Jan
Hallo Frank,
ich habe eine Frage zu den Zertifikaten.
Unser altes SSL-Zertifikat ist abgelaufen. Ich hab anstatt auf Erneuern zu klicken ein neues Erstellt….
Habe die Schritte befolgt und das Zertifikat befindet sich nun auch im ExChange mit dem Status gültig. Das alte abgelaufene Zertifikat habe ich gelöscht. Auch sind die Dienste zugewiesen wie bei dem anderen Zertifikat. Den Standard habe ich auch überschrieben.
Trotzdem meldet mir jeder Outlook Client das das Zertifikat abgelaufen ist. Schaue ich in die Details, wird mir das alte Zertifikat angezeigt (welches ich nicht erneuert habe).
Die Bindungen im IIS habe ich auch kontrolliert und angepasst.
Hast du vielleicht noch eine Idee?
Hallo Jan,
wird dir das neue Zertifikat angezeigt wenn du auf dem Exchange Server https://localhost aufrufst? Kann es sein, dass die Clients die Verbindung über einen Proxy oder Loadbalancer herstellen?
Gruß,
Frank
Ganz herzlichen Dank für dieses ausführliche Lehrmittel, endlich die ganzen Geschichten im Kontext.
Hallo Frank,
sehr schöne Anleitung einer kompletten Exchange Installation und Einrichtung, nicht nur für das Thema Zertifikate. Sehr umfassend und hilfreich, danke dafür.
Ich hab eine Frage zum „Default Frontend“-Empfangsconnector. Das fehlt irgendwie bei Deinen How-tos bzw. passt es gut rein. FQDN für HELO/EHLO sollte am Besten eigentlich auch der MX-Record sein, oder?(mail.domain.tld bzw. mail.frankysweb.de)?
Da dies heisst, dass man die Exchange-Serverauthentifizierung im Connector abschalten muss, empfiehlt sich für den Internetempfang ein neuer Frontend-Connector für anonym und TLS sowie setzen im „Default Frontend“ auf internen IP-Adressbereich?
Hallo Frank,
soeben ist mir selbst aufgefallen, was ich übersehen habe:
In Szenario1 habe ich in der Forward-Lookup-Zone im internen DNS auch einen SRV-Eintrag für Autodiscover gesetzt.
In Szenario2 hatte ich den vergessen.
SRV-Eintrag für Autodiscover in Zone „exchange.szene2.de“ erstellt — Fehler weg!!
Schön, dass wir darüber gesprochen haben. ;-)
Hallo Frank,
erstmal großes Lob für deine Seite!
Hat mir schon wirklich oft weitergeholfen.
Jetzt habe ich hier aber ein Zertifikatsproblem, das ich nicht ganz verstehe:
Ich habe 2 (fast) identische Exchange-Umgebungen:
Szenario1: Exchange 2013 mit SSL-123-Zertifikat von Thawte.
Das Zertifikat läuft auf exchange.szene1.eu (interne Domäne ist „ganzwasanderes.local“)
Hierfür gibt es auch eine Forward-Lookup-Zone im lokalen DNS.
Extern habe ich einen Host A-Eintrag der auf die externe IP-Adresse zeigt.
Für Autodiscover habe ich keine interne DNS-Zone, sondern nur einen SRV-Eintrag beim Provider.
( _autodiscover._tcp IN SRV 0 0 443 exchange.szene1.eu. )
Funktioniert tadellos.
Szenario2: Exchange 2016, [interne Domäne ist „ad.szene2.de“ (da bin ich deiner Empfehlung gefolgt)]
aber ansonsten gleiches Setup:
Zertifikat auf exchange.szene2.de / interne Forward-Lookup-Zone / Host A und SRV extern.
Hier bekomme ich im Outlook nun immer eine Fehlermeldung für „autodiscover.szene2.de“:
„Der Name auf dem Sicherheitszertifikat stimmt nicht mit dem Namen der Webseite überein“
Stimmt natürlich, denn das Zertifikat lautet ja auf exchange.szene2.de – nicht auf autodiscover.szene2.de.
In deinem Beispiel löst du das über die zusätzliche SAN-Domain.
Das wird für die SSL-123-Zertifikate aber nicht angeboten.
Ist in Szenario1 aber auch nicht erforderlich und funktioniert trotzdem.
In Szenario2 kriege ich den Fehler einfach nicht weg.
Was habe ich übersehen??
Vielen Dank im Voraus.
Hallo Frank,
bei meinem Provider kann ich autodiscover nicht deaktivieren und habe mir mit einem CNAME Eintrag geholfen.
D.h. ich habe autodiscover.meine-firma.COM und E-Mail-Adressen mail@meine-firma.DE.
CNAME autodiscover.meine-firma.DE auf autodiscover.meine-firma.COM
Jetzt bräuchte ich wohl doch einen weiteren Namen auf dem Zertifikat damit ich keine Warnung bekomme.
Der naive Versuch die Namen einfach zusätzlich einzutragen ist gescheitert.
Hast Du eine Idee?
Viele Grüße
Erik
Hallo Frank,
so, auch hier gehts nun. Ich hatte einen Fehler in den Entry Urls bei der Firewall-Regel für die Webservices gehabt.
Besten Dank für alles.
Gruß
Christoph
Hallo Frank,
so, habe Deine Erläuterungen zur Sophos gefunden und so umgesetzt. Der Fehler mit den Intermediate-Zertifikaten über die WAF ist nun weg ;-). Auch der MS Connectivity Analyzer läuft fast sauber durch. Er meckert die autodiscover.xml an, aber nicht als „roten“ Fehler sondern als Hinweis.
Ich habe aber noch ein kleines Problem. OWA von intern überhaupt kein Problem. Wenn ich allerdings von extern (iPhone) die Webseite https://mail.klahn.net aufrufe, dann kommt folgende Fehlermeldung:
„Request blocked
The web application firewall has blocked access to / for the following reason:
No signature found“
Die gleiche Meldung sehe ich im Live-Protokoll der UTM bei den virtuellen Webservern.
Hättest Du da eine Idee?
Gruß
Christoph
Hallo Frank,
jepp, gerade herausgefunden. Vielen Dank für den Hinweis.
Mein Benutzerkonto war Mitglied der Domänen-Admins. Die Mitgliedschaft habe ich aufgelöst. Danach ging es immer noch nicht. Ich mußte in meinem Benutzerkonto unter Sicherheit noch die Vererbung „nach unten“ einschalten.
Nun geht’s :-).
Bzgl. des Intermediate-Zertifikats bin ich auch weiter. Ich habe eine Sophos UTM 9.4 im Einsatz und habe als Webserver den Exchange definiert. Dann noch einen virtuellen Webserver, der auf Port 443 hört und dieses an den Webserver weiterleitet. Da wird scheinbar etwas verschluckt.
Wenn ich eine DNAT-Regel definiere, daß Port 443 direkt an den Exchange weitergeleitet wird, dann kommt die Fehlermeldung nicht mehr. Da muß ich mal schauen, was da klemmt.
Oder hast Du dazu auch schon eine Lösung ;-) ?
Gruß
Christoph
Vielen Dank dafür.
Hallo,
noch eine Ergänzung:
Ich habe den „MS Remote Connectivity Analyzer“ mal durchlaufen lassen. Und der sagte mir, daß das Intermediate-Zertifikat fehlt.
Ich habe von Geotrust eins mitbekommen, aber nicht installiert, da Frank dieses auch nicht beschrieben hatte.
Scheinbar muß das installiert werden…. Wenn ja, wie?
Vielen Dank im voraus
MfG
Christoph
Hi Christoph,
das Intermediate Zertifikate kannst du in den Zertifikatsspeicher „Zwischenzertifizierungsstellen“ des Exchange Servers ablegen. Somit wird es dann auch durch den IIS Server ausgeliefert, dies wird jedoch nicht dein Problem mit ActiveSync lösen, kann es sein, dass du versuchst mit einem Konto welches Domain Admin Rechte hat eine ActiveSync Verbindung herzustellen? Wenn ja, dann schau mal hier:
https://www.frankysweb.de/exchange-2010-sp1-ereignis-1053-im-event-log-msexchange-activesync/
Gruß, Frank
Hallo Frank,
tolles „HowTo“ (alle 3 Artikel). Ich habe bei mir je einen Server 2016 als DC und als Exchange Server aufgesetzt und eine Domäne angelegt. Dann Exchange 2016 CU5 installiert und nach verschiedensten Artikeln aus Deinem Blog konfiguriert.
DNS, Autodiscover usw. funktioniert hervorragend, Ich habe eine feste IP und habe mir ein SSL-Zertifikat der vorgeschlagenen Zertifizierungsstelle gekauft und auf dem Exchange nach Deiner Anleitung eingebunden.
Auf meinem Notebook habe ich Outlook 2016 per Mapi over HTTP per Autodiscover eingerichtet und der Zugriff auf mein Exchange-Konto funktioniert ebenfalls. Auch OWA klappt sowohl intern als auch extern.
So weit so gut. Was ich aber partout nicht hinbekomme, ist die Anbindung meines iPhones und meines iPads.
Wenn ich auf den Geräten einen neuen Account einrichte und „Exchange“ wähle, dann werde ich nach der email-Adresse gefragt. Ich gabe diese ein und das iPhone/iPad sollte anhand des Domainnamens per Autodiscover den Exchange finden. Nachdem ich weiter gedrückt habe, soll ich das Passwort eingeben. Wenn ich das dann gemacht habe, dauert es ziemlich lange und dann werden alle Parameter wie z.B. Server, Benutzer usw. abgefragt.
Das zeigt mir, daß Autodiscover nicht funktioniert hat.
Wenn ich also nun alle Daten manuell eingebe und „Weiter“ drücke, dann erscheinen hinter allen Einträgen blaue Haken und der Account ist angelegt. Scheinbar klappt die Kommunikation mit dem Exchange.
Wenn ich aber die Apple-Mail-App starte und auf den Account gehe, dann bekomme ich die Fehlermeldung: „E-Mails können nicht empfangen werden. Die Verbindung mit dem Server ist fehlgeschlagen“.
Hast Du, oder ein Mitleser, eine Idee, woran das liegen könnte?
Gruß
Christoph
Hallo, vielen Dank für diese tolle(n) Anleitung(en)!
Ich habe bisher alles erfolgreich nachvollziehen können, stocke jetzt aber bei dem Schritt der Zertifikatinstallation auf dem Exchange.
Da ich mir ein Wildcard-SSL-Zertifikat besorgt habe für meine Domain, kann ich vom Exchange heraus jetzt natürlich keine CSR erstellen – denn wer soll mir dafür ein Zertifikat ausstellen – ich habe ja ein Zertifikat. Gibt es hier auch eine Trick wie man solch ein Zertifikat importieren kann?
Danke und weiter so!
Daniel
Hi Daniel,
du kannst das vorhandene Zertifikat direkt in der GUI importieren und brauchst es dann nur noch den Diensten zuweisen. Die URLs musst du natürlich trotzdem konfigurieren.
Gruß, Frank
Anstelle von „firma.de“ als interne Zone anzulegen kann man auch „_tcp.firma.de“ als interne Zone anlegen. Das spart das Anlegen und Pflegen der externen Adressen wie „www.firma.de“. Das Anlegen des „_autodiscover“-SRV-Records ist über die GUI etwas tricky. Man muss, obwohl man schon innerhalb von „_tcp“ ist, dennoch „_tcp“ und „_autodiscover“ eintippen, genau wie im Screenshot oben.