Autodiscover veröffentlichen
Diese Seite basiert auf Exchange 2007 aber ist in weiten Teilen auch für Exchange 2010/2013 und 2016 gültig.
Details zur Technik und Funktion selbst finden Sie auf den anderen Seiten in diesem Bereich Exchange Autodiscover.
Exchange 2007 und Outlook 2007 nutzen intensiv die Funktion "Autodiscover", um Konfigurationsinformationen zu ermitteln. Das funktioniert meist innerhalb des eigenen Netzwerks problemlos, da Exchange 2007 bei der Installation bereits ein Selbstzertifikat für SSL generiert und im Active Directory die URL zu den CAS-Servern über Service Connection Points veröffentlicht werden. Interessant wird es aber, wenn Sie Outlook auch außerhalb der eigenen Netzwerke, z.B. per RPC over HTTP verwenden oder Outlook 2007 Installationen "aus dem Internet" sich automatisch konfigurieren sollen. Auch hier ist es erforderlich, dass "Autodiscover" über das Internet funktioniert.
Die genauen Details zu Autodiscover habe ich auf Autodiscover bereits beschrieben. Diese Seite hat den Anspruch, zwei häufige Konfigurationen bei kleinen und mittleren Firmen praktisch zu beschreiben, d.h. welche Einstellungen und Zertifikate wo installiert sind. Ich gehe dabei von einem Exchange 2007 Server aus, der auch die CAS-Rolle Trägt. Auch die Trennung von CAS von anderen Rollen ist denkbar. Sobald Sie aber mehrere Active Directory Standorte mit dort installierten Exchange CAS-Servern haben, ist diese Seite nicht mehr ausreichend.
Diese Seite beschreibt die beiden folgenden Konfigurationen:
- Exchange hinter NAT
Diese Konfiguration ist eher eine "Small Business Konfiguration", bei der das Netzwerk hinter einen Router mit NAT steht und per NAT die Verbindung zum Webserver:443 ohne weiteren Filter veröffentlicht wird. Wird ein offizielles Zertifikat genutzt, dann muss das auf dem Exchange CAS Server installiert werden. - Exchange CAS hinter ISA/TMG
Hierbei ist der Exchange CAS Server nicht direkt erreichbar, sondern Verbindungen aus dem Internet landen auf einem ISA-Server, welcher auch den SSL-Tunnel terminiert und die Anfragen nach intern zum Exchange 2007 CAS weiter reicht. Auf dem Exchange 2007 CAS ist dann kein offizielles Zertifikat. Natürlich können Sie auch einen Apache als Reverse Proxy verwenden, der jedoch weniger gut Exchange schützt.
Es ist aus meiner Sicht nicht sinnvoll, einen CAS-Server eine ein DMZ zu stellen. Dieses "Konzept" eines Frontend Servers in der DMZ als zusätzliche Sicherheit war nur ganz am Anfang von Exchange 2000 einmal dokumentiert aber hält sich hartnäckig. Ein Exchange 2007-CAS-Server gehört wie ein Exchange 2000/2003 Frontend Server in das intern LAN, da auch dieser Server sehr viele Verbindungen in das interne Netzwerk aufbaut, wodurch die Firewall zwischen DMZ und internem LAN stark perforiert wird. Es ist auf jeden einfacher, genau ein Protokoll (https) mit Authentifizierung und Inspektion sicher nach innen weiter zu reichen, als eine ganze Bandbreite von TCP-Ports zu öffnen.
Exchange hinter NAT
Die einfachere Konfiguration wird man sicher bei sehr kleinen Firmen finden, die auf eine Applicationfirewall verzichten und zwischen dem privaten Netzwerk und dem Internet nur einen Router mit NAT haben. Ich habe aber auch schon größere Firmen gesehen, die auf eine genauere Inspektion von HTTP-Traffic verzichten und interne Webserver einfach per Reverse-NAT veröffentlichen.
Ich kann von dieser Art "Webveröffentlichung" nur abraten, da Sie den kompletten Webserver direkt im Internet veröffentlicht und nur den Port beschränkt. Zwar sind Webserver heute relativ sicher aber jede Erweiterung, die sie intern auf dem Webserver machen, wird automatisch auch von extern erreichbar sein. Wenn Sie als auf dem Exchange IIS nebenbei noch ein Sharepoint Intranet oder eine andere Webapplikation nachinstallieren, dann ist diese auch aus dem Internet erreichbar. Zudem landen ALLE Anfragen immer auf dem Exchange Server, der bei einen Angriff eventuell viel Last tragen muss.
Technisch ist die Konfiguration entsprechend einfach: Ein Router nimmt die Anfragen auf Port 443 auf der öffentlichen Schnittstelle an und leitet dies an die private IP-Adresse des Exchange Servers weiter.
Damit ein Client im Internet nicht dauernd die Warnungen bezüglich des Zertifikats bekommt, muss man dann das offizielle Zertifikat auf dem Exchange Server installieren. Wenn man nur eine Webseite hat, dann muss man dazu das von Exchange 2007 selbst erstellte Zertifikat entfernen. Wenn "Autodiscover" aus dem Internet funktionieren soll, dann sollte das Zertifikat auch den "Subject Alternate Name" für Autodiscover enthalten. Ansonsten benötigen Sie Outlook 2007 SP1 mit einem SRV-Record im DNS oder eine zweite Webseite, die eine Anfrage auf Autodiscover ohne SSL auf webmail.msxfaq.de per SSL umleitet. Das ist bei einer NAT-Konfiguration jedoch eher ungewöhnlich. Auf "Autodiscover" können Sie verzichten, wenn Sie über eine lokale XML-Datei Outlook entsprechend den Weg auf "webmail.msxfaq.de" weisen. (siehe Autodiscover).
Wenn man nun das Zertifikat auf dem Exchange Server tauscht, dann stimmen ja die URLs nicht mehr, die in Exchange als URLs hinterlegt sind. Auch der Service Connection Point im Active Directory verweist ja noch auf "srv01.msxfaq.local. Nur gibt es dort nicht mehr das passende Zertifikat und Outlook wird entsprechende Warnungen und Fehler generieren. Also müssen noch weiter konfigurieren
- Wir müssen Exchange mitteilen, dass sich die Erreichbarkeit geändert
haben.
Dazu sind folgende PowerShell Commandlets anzuwenden (ohne Zeilenumbruch):
Set-ClientAccessServer -AutoDiscoverServiceInternalUri https://webmail.msxfaq.de/Autodiscover/Autodiscover.xml set-AutodiscoverVirtualDirectory - InternalURL https://webmail.msxfaq.de/Autodiscover/Autodiscover.xml - ExternalURL https://webmail.msxfaq.de/Autodiscover/Autodiscover.xml set-OWAVirtualDirectory ` -identity "owa (Default Web Site)" -ExternalURL "https://webmail.msxfaq.de/owa" ` -InternalURL "https://webmail.msxfaq.de/owa" set-ActiveSyncVirtualDirectory ` -identity "Microsoft-Server-ActiveSync (Default Web Site)" ' -ExternalURL "https://webmail.msxfaq.de/Microsoft-Server-ActiveSync" ` -InternalURL "https://webmail.msxfaq.de/Microsoft-Server-ActiveSync" set-AutoDiscoverVirtualDirectory ` -Websitename "Autodiscover (Default Web Site)" ` -WindowsAuthentication $true ` -DigestAuthentication $true ` -ExternalURL "https://autodiscover.msxfaq.de/autodiscover/autodiscover.aspx" ` -InternalURL "https://autodiscover.msxfaq.de/autodiscover/autodiscover.aspx" set-WebServicesVirtualDirectory ` -WebsiteName "EWS (Default Web Site)" ` -ExternalURL "https://webmail.msxfaq.de/EWS/Exchange.asmx" ` -InternalURL "https://webmail.msxfaq.de/EWS/Exchange.asmx" Set-UMVirtualdirectory -Identity "MAIL05ADD\UnifiedMessaging (Default Web Site)"` -InternalURL "https://autodiscover.msxfaq.de/UnifiedMessaging/Service.asmx" ` -ExternalURL "https://autodiscover.msxfaq.de/UnifiedMessaging/Service.asmx" Set-ClientAccessServer ` -Identity "CAS-01" ` -AutodiscoverServiceInternalURI "https://autodisover.msxfaq.de/autodiscover/autodiscover.xml" ` -AutodiscoverServiceSiteScope "Paderborn"
- DNS anpassen
Weiterhin müssen wir natürlich im DNS dafür sorgen, dass die Client sowohl aus dem Internet als auch intern die Adressen auflösen können. Nutzt man intern eine andere Zone (z.B. msxfaq.local statt msxfaq.de) dann muss man eben intern eine msxfaq.de-Zone anlegen, die ein Schatten der offiziellen Zone ist und die erforderlichen Einträge auf die interne private Adresse auflöst. Siehe auch DNS
So sollten die Clients intern die zum offiziellen Zertifikat passenden URLs ansprechen und auch von extern die richtigen Pfade bekommen.
Exchange hinter ISA
Besser aber auch etwas komplizierter ist die sichere Veröffentlichung über einen ISA-Server oder einen anderen Reverse Proxy
Dieser Variante gebe ich immer den Vorzug, da das vorgelagerte Gateway zum einen die SSL-Verschlüsselung abnehmen, die Anwender bereits authentifizieren kann und URLs filtern kann. Damit landen auf dem nachgeschalteten Exchange Server nur Anfragen von Clients, die bereits authentifiziert sind und eine erlaubte URL nutzen. Nebenbei kann so ein Gateway abhängig von der URL unter einem Namen und einer Adresse viele interne Webserver gezielt veröffentlichen.
Hierbei landet der Client aus dem Internet erst auf dem ISA-Server, der ihm auch das offizielle SSL-Zertifikat liefert und die Verschlüsselung terminiert. Der ISA kann dann schon dem Anwender die Anmeldeseite liefern, so dass der Anwender sich hier schon anmelden muss. Nach erfolgreicher Anwendung prüft der ISA, ob die vom Client angeforderte URL überhaupt veröffentlicht ist und gewissen Regularien entspricht.
Ist all dies gegeben, dann verbindet sich der ISA-Server mit dem Exchange Server unter Verwendung der ihm überlassenen Anmeldedaten. Der ISA-Server kann dazu auch SSL nutzen. Wird intern aber weiter das private Zertifikat genutzt, dann muss der ISA-Server der ausstellenden CA vertrauen. Mit einer eigenen CA ist dies relativ einfach. Nutzen Sie aber immer noch das Selbstzertifikat, dann müssen Sie eben dieses Zertifikat jedes Jahr auf dem ISA-Server als vertrauenswürdiges Stammzertifikat installieren.
Da auf dem Exchange Server das "Selbstzertifikat" erhalten bleibt, funktionieren erst einmal alle internen Zugriffe wie gewohnt. Exchange veröffentlicht die CAS-Server über den Service Connection Point und die Clients greifen darauf zu. Dabei könnte man es eigentlich belassen, wenn alle Outlooks 2007 Mitglied der Domäne sind und damit den SCP finden und nutzen. Auch die Tatsache, dass es nur ein CAS-Server in einem Active Directory Standort ist, macht die Konfiguration einfach.
Es ist nicht erforderlich, die "ExternalURL" zu pflegen, da es ja keinen zweiten CAS-Server gibt, welcher einen Client auf diesen CAS-Server umleiten muss. Im DNS muss man nun dafür sorgen, dass Systeme, die nicht in der Domäne sind bzw. nicht intern sind, über den Namen "Autodiscover" den Weg zum ISA-Server finden. Nutzen Sie intern eine andere Zone (z.B. msxfaq.local statt msxfaq.de) dann müssen Sie intern eine msxfaq.de-Zone anlegen, die ein Schatten der offiziellen Zone ist und die erforderlichen Einträge auf die ISA-Adresse auflöst. Siehe auch DNS.
Autodiscover bei Net at Work
Als kleines HowTo habe ich einfach die Autodiscover Konfiguration bei Net at Work beschrieben. Wir nutzen offizielle Zertifikate aber sind natürlich sparsam, wenn es um die Anzahl der Namen geht. Auf Autodiscover haben sich sicher gelesen, wie Outlook "tickt" und dass Outlook immer dann die Autodiscover Abfrage per HTTPS ausführt, wenn der PC nicht Mitglied im Active Directory ist und damit keinen "Service Connection Point" auflösen kann.
Das gilt im allgemeinen, wenn wir Systemingenieure selbst bei Kunden unterwegs sind. Schon daher haben wir natürlich ein Interesse, dass Autodiscover ohne Probleme funktioniert. Wir nutzen dazu folgendes Verfahren mit einem "SplitDNS"
- Voraussetzung ist Outlook 2007 SP1
Erst damit kann man SRV-Records im DNS verwenden und auf "autodiscover.maildomain.tld" verzichten. - Sichere "owa.netatwork.de"
Diese Webseite ist natürlich per SSL mit einem Zertifikat auf den Namen "owa.netatwork.de" abgesichert. Hier ist auch die Exchange 2007 URL "autodiscover" veröffentlicht. - DNS-Eintrag
Über diesen Weg ersparen wir und das SANZertifkat für den Namen "Autodiscover". Das funktioniert natürlich nur, wenn die Webseite die auf "autodiscover" reagiert, entweder kein SSL anbietet oder ein gültiges Zertifikat verwendet. Das "könnte" auch ein privates Zertifikat sein, wenn der Client der privaten Stamm-CA vertraut. (Siehe auch SSL-Grundlagen)
Für die interne Funktion von Autodiscover müssen wir auch nichts einrichten, da hier Outlook per LDAP im Active Directory schon die entsprechenden URLs ausliest und das Selbstzertifikat der Exchange Installation genauso klaglos akzeptiert wird, wie das Zertifikat, welches durch unsere interne "privat" CA ausgestellt wurde.
DNS Eintrag
Wenn ihr OWA-Server ein privates SAN-Zertifikat benutzt und der Client der Zertifizierungsstelle vertraut oder sie ein offizielles SAN-Zertifikat gekauft haben, dann müssen Sie diesen Aufwand nicht betreiben. Dann sollte der Eintrag "autodiscover" einfach auf den CAS-Server bzw. die ISA-Veröffentlichung verweisen
Der erste Schritt ist natürlich der Eintrag in der offiziellen DNS-Zone.
xxx Bild ist "falsch"
In der Regel dauert es einige Stunden, bis "das Internet" den neuen Eintrag auch repliziert hat und damit die Clients die Adresse auch auflösen können. Der Zugriff erfolgt dann auf den Webserver
Autodiscover "erreichbar" machen
Nun müssen wir nur noch dafür sorgen, dass eben diese neue URL aus dem Internet auch erreichbar ist. Bei einem ISA-Server muss man auf der Web Veröffentlichungsregel nun auch den Pfad "/autodiscover" erreichbar machen.
Wer "nur" einen Router mit NAT einsetzt, muss in der Regel nichts weiter freigeben. Hier ist allerdings zu prüfen, ob man nicht generell entweder eine richtige Firewall einsetzt nicht besser entweder eine eigene virtuelle Webseite einrichtet, auf der NUR die öffentlichen Ressourcen bereitgestellt werden oder man all die Verzeichnisse, die nicht erreichbar sein dürfen, über IP-Beschränkungen weiter absichert.
Client
Das einzige, was nun etwas "störend" ist, ist die Meldung von Outlook bei der Umleitung über den SRV-Record:
Diese Meldung muss man aber nur einmal bestätigen, damit zukünftig die Autodiscover-Funktion gegeben ist.
Weitere Links
- Autodiscover
- CAS und NLB
- CASProxy 2010
- CAS Intern/Extern
- IIS SSL einrichten
- CA installieren
- DNS
- POP3 und IMAP4 Clients - Thunderbird kennt auch ein "AutoConfigure"
-
White Paper: Exchange 2007 Autodiscover Service
http://technet.microsoft.com/en-us/library/bb332063(EXCHG.80).aspx#ConfiguringADMultipleForestsHowTo - http://blogs.technet.com/isablog/archive/2007/08/29/certificates-with-multiple-san-entries-may-break-isa-server-web-publishing.aspx
- Publishing Exchange 2007 Autodisover in ISA 2006
http://www.shudnow.net/2007/07/15/publishing-exchange-2007-autodisover-in-isa-2006