Exchange 2010 und Outlook 2016 – Autodiscover

Derzeit erreichen mich viele Mails von Leuten die über Probleme mit Outlook 2016 in Verbindung mit Exchange 2010 klagen.

Mit Outlook 2016 ist scheinbar für viele eine entscheidende Funktion weggefallen: Es können keine Exchange Accounts mehr manuell konfiguriert werden. Ehrlich gesagt hätte ich nicht gedacht, dass scheinbar viele die Exchange Accounts manuell konfiguriert haben.

Outlook unterstützt immer die aktuelle Exchange Version, die beiden vorherigen Exchange Versionen und die beiden nächsten Exchange Versionen. Das heißt konkret: Outlook 2016 unterstützt Exchange 2016, Exchange 2013, Exchange 2010, die beiden zukünftigen Versionen, aber kein Exchange 2007.

In einer frühen Outlook 2016 Preview gab es einen Registry Key, den man setzten konnte um RPCoverHTTP (besser bekannt als das Exchange 2010 Outlook Anywhere Protokoll) zu aktivieren. In der RTM Version ist dies aber nicht mehr nötig. Im Screenshot sieht man Outlook 2016 in Verbindung mit Exchange 2010, ohne irgendwelchen Registry Keys etc.

Outlook 2016

Ursache warum viele über Verbindungprobleme klagen, war bisher immer: Kein Autodiscover konfiguriert!

Wie schon eingangs erwähnt, die manuelle Konfiguration der Exchange Konten wurde entfernt, ebenfalls werden keine PRF Dateien mehr unterstützt. Hier mal der Vergleich zwischen Outlook 2010 und Outlook 2016.

Outlook 2010:

image

Outlook 2016:

2

4

Autodiscover entsprechend einzurichten ist aber auch kein Hexenwerk. Denn Autodiscover sucht sich seine Konfiguration automatisch zusammen, es müssen nur die Exchange Verzeichnisse im IIS konfiguriert werden. Alle 15 Minuten wird dann die Autodiscover Konfiguration erstellt.

Hier mal ein Bespiel für der die Verzeichnisse auf „outlook.frankysweb.de“ konfiguriert und Autodisover auf „autodiscover.frankysweb.de“

Set-OWAVirtualDirectory –Identity "OWA (default web site)" -ExternalURL "https://outlook.frankysweb.de/OWA" 
Set-OWAVirtualDirectory –Identity "OWA (default web site)" -InternalURL "https://outlook.frankysweb.de/OWA"

Set-OABVirtualDirectory –Identity "OAB (default web site)" -ExternalURL "https://outlook.frankysweb.de/OAB" 
Set-OABVirtualDirectory –Identity "OAB (default web site)" -InternalURL "https://outlook.frankysweb.de/OAB"

Set-ECPVirtualDirectory –Identity "ECP (default web site)" -ExternalURL "https://outlook.frankysweb.de/ECP" 
Set-ECPVirtualDirectory –Identity "ECP (default web site)" -InternalURL "https://outlook.frankysweb.de/ECP"

Set-WebServicesVirtualDirectory –Identity "EWS (default web site)" -ExternalUrl "https://outlook.frankysweb.de/ews/exchange.asmx"
Set-WebServicesVirtualDirectory –Identity "EWS (default web site)" -InternalUrl "https://outlook.frankysweb.de/ews/exchange.asmx"

Set-ActiveSyncVirtualDirectory –Identity "Microsoft-Server-ActiveSync (default web site)" -ExternalURL "https://outlook.frankysweb.de/Microsoft-Server-ActiveSync"
Set-ActiveSyncVirtualDirectory –Identity "Microsoft-Server-ActiveSync (default web site)" -InternalURL https://outlook.frankysweb.de/Microsoft-Server-ActiveSync

Set-ClientAccessServer -AutoDiscoverServiceInternalUri "https://autodiscover.frankysweb.de/Autodiscover/Autodiscover.xml"

Die aktuelle Konfiguration lässt sich mit den folgenden Befehlen anzeigen:

Get-ClientAccessServer | fl autodiscover*
Get-ActiveSyncVirtualDirectory | fl *url*
Get-OutlookAnywhere | fl *hostname
Get-WebServicesVirtualDirectory | fl *url*
Get-OwaVirtualDirectory | fl *url*
Get-OabVirtualDirectory | fl *url*

Alles was jetzt noch benötigt wird ist ein Zertifikat welches die Namen „autodiscover.frankysweb.de“ und „outlook.frankysweb.de“ enthält und die DNS Einträge.

Die meisten werden wohl Split Brain DNS betreiben, sprich die externe Domain, in diesem Beispiel frankysweb.de. liegt bei irgendeinem Provider. Dort werden autodiscover.frankysweb.de und outlook.frankysweb.de als Subdomain, oder HOST-A (je nachdem wie der Provider das gerade nennt) eingetragen. Die HOST-A Einträge enthalten dann die externe IP Adresse unter der Exchange erreichbar ist.

Am internen DNS das gleiche Spiel, jedoch mit der internen IP-Adresse. Fertig. 15 Minuten warten nicht vergessen, so klappts auch mit Outlook 2016 und Exchange 2010.

Update 24.01.2017: Ein umfangreiches Whitepaper wie Autodiscover funktioniert und konfiguriert wird, gibt es hier:

Exchange 2016: Umfangreiches Whitepaper zu Autodiscover

Update 31.03.2017:

Hier gibt es eine Konfigurationsanleitung inkl. Let’s Encrypt Zertifikaten:

74 Replies to “Exchange 2010 und Outlook 2016 – Autodiscover”

  1. Hallo Frank.
    Vielen Dank für Deinen jüngsten Newsletter. Dort schreibst Du „Ehrlich gesagt hätte ich nicht gedacht, dass scheinbar viele die Exchange Accounts manuell konfiguriert haben.“ Diese Aussage wundert mich wiederum ;-)
    Wie handhabst Du denn den Fall „Windows-Account Email-Account“? Da hilft Autodiscover nichts, OWA ist nicht immer eine ausreichende Alternative und somit bleibt nur eine manuelle Konfiguration des Email-Clients. Siehst Du da noch eine Möglichkeit mit Outlook2016?
    Freundliche Grüsse,
    Paul

  2. Hi Paul,
    was meinst du mit „Windows-Account Email-Account“? Nicht-Exchange Accounts lassen sich doch wie gehabt manuell konfigurieren. Es geht doch nur um Exchange Accounts.
    Gruß, Frank

  3. Oh, da ging das Ungleich-Zeichen wohl verloren. Ich meine, was ist, wenn ich Outlook mit einem anderen Exchange-Mailkonto konfigurieren will, als derzeitig an Windows angemeldet ist. Das geht ja nicht mit Autodiscover, sondern da muss ich manuell eingeben, welches Konto ich verbinden will. Das geht jetzt mit 2016 nicht mehr?
    Gruss, Paul

  4. Auch das funktioniert via Autodiscover. Natürlich wird in dem Fall Benutzername und Passwort abgefragt, es geht darum, dass nicht mehr manuell konfiguriert werden kann, wie der Servername ist, oder welche Authentifizierungsmethode verwendet wird, all das nimmt dir Autodiscover ab.
    Gruß, Frank

  5. Moin!
    Genau vor dem Problem stehe ich aktuell. Bei Exchange 2010ern habe ich bislang nur ein SSL-Zertifikat auf den FQDN des Servers bestellt, also bspw. mx.contoso.com
    Bei der Einrichtung von Exchange 2013ern habe ich dann schon auf Wildcard-Zertifikate gesetzt, womit dann ja auch die Sache mit dem autodiscover.contosoccom geregelt war.

    Nun aber zu den Bestandskunden, die noch Exchange 2010 und plötzlich Outlook 2016 einsetzen…
    MUSS ich hier nun ein neues Zertifikat bestellen, welches auf mx.contoso.com UND autodiscover.contoso.com lautet (Multi-SAN),
    – oder ein Wildcard-SSL,
    – oder ein einzelnes (was das günstigste wäre), welches eben nur auf autodiscover-contoso.com zeigt?
    Und wenn es ein weiteres einzelnes wäre… das ist ja eigentlich gar nicht möglich auf ein und der selben IP mehrere Zertifikatbindings zu haben… dann bliebe ja nur der folgende Weg:
    Aktuell wird der Server angesprochen via mx.domain.local und extern via mx.contoso.com. Intern wie extern wäre dann aber ja künftig mx.contoso.com (wie für Ex2013 üblich) und man nutzt ne zweite IP ausschließlich für ein neu erstelltes autodiscover-Directory… <– oder bin ich mit dem Gedanken auf dem Holzweg? Wobei die Einrichtungskosten sehr wahrscheinlich die geringeren Kosten gegenüber nem Multi-SAN Zertifikat schnell wieder auffressen (aus Kundensicht)

  6. Hi all,

    Sorry for writing in English ;)

    I have installed Exchange 2016, and setup everything, all works fine with Outlook 2013, but Outlook 2016 cannot connect to it, I have setup mapi via http and everything, but even autodiscover does not work with it, and thats the only way outlook 2016 works, any of you have tried this combination?

    best regards
    Martin

  7. Hi Martin,
    you are right. Outlook 2016 requiers working Autodiscover. I am running Outlook 2016 and Exchange 2016 with no Problems. Do you have configured all Exchange virtual Directory URLs?
    BTW: some Firewalls dosen’t Support MAPIoverHTTP yet.
    best regards,
    Frank

  8. Hi,
    ich würde ein SAN Zertifikat nehmen, die kosten kaum mehr und man erspart sich das gefummel. Zweite IP würde auch klappen, aber… nein… :-D
    Gruß, Frank

  9. I found out so far, it’s when it’s a domainjoined computer o nthe LAN, that there is issues.
    When connection outside, there is no problems.
    In have looked at the SCP record but the serviceBindingInformation attribute shows the correct url also.
    Is your environment also tested from the AD? If so could you publish the contents of:
    CN=Autodiscover,CN=Protocols,CN=,CN=Servers,CN=Exchange Administrative Group,CN=Administrative Groups,CN=First Organization,CN=Microsoft Exchange,CN=Services

    Thnaks in advance ;)

    Best regards Martin

  10. Hi,

    whats the Output for get-clientaccessservice | fl *autodiscover* ?
    I think there will be an internal URL right?

    regards, Frank

  11. Hallo Frank,
    was wenn der Kunde (wie bei einigen SBS Kunden) die Mails per POP abrufen, also kein veröffentlichter Exchange vorhanden ist, autodiscover.kunde.de zeigt dann auf den Provider.
    Wenn ich bsp. intern den DNS Eintrag setze autodiscover.kunde.de auf interne IP Exchange, schickt er keine Mails mehr raus,da über Smarthost verschickt wird.
    Clients sind keine domainjoined PCs.
    Gruß Oli

  12. Hi wynni,

    ja, man kann auch einen SRV Record für AUtodiscover nutzen, allerdings lassen das manche Hoster nicht zu. Um bei Bind zu bleiben:

    _autodiscover._tcp IN SRV 0 0 443 outlook.frankysweb.de.

    Ich kenne viele Hoster die nur Subdomains zulassen, bei denen nur ein Redirect oder eben ein Host-A angelegt werden kann. Ein Alias würde auch gehen.
    Gruß, Frank

  13. Hi Oli,

    Autodiscover hat nichts mit Mail verschicken oder empfangen zu tun. Autodiscover.kunde.de soll also auf die öffentliche IP des Exchange Servers zeigen. Wohin deine MX-Records zeigen und wie du deine Mails verschickst spielt für Autodiscover keine Rolle. Wenn du DNS Split Brain nutzt, zeigt am internen DNS autodiscover.kunde.de auf die interne IP und autodiscover.kunde.de beim Hoster/Provider auf die öffentliche IP.

    Gruß, Frank

  14. Wichtig: Der Exchange Server 2010 muss mit dem SP3 ausgestattet sein, da dies die eine Voraussetzung für die Anbindung von Outlook 2016 ist.

  15. Hallo,
    wir haben am Wochenende unseren Exchange 2013 auf Exchange 2016 migriert (funktioniert auch ohne Probleme). Jedoch haben wir das selbe Problem mit Outlook 2016, dass es nicht verbindet. Er findet die Einstellungen, aber es kommt immer die Passwortabfrage. Egal was ich dort eingebe und Passwort speichern anklicke, die Aufforderung erscheint immer wieder. Ich gehe davon aus, dass Autodiscover richtig funktioniert, wenn ich mich mit Outlook 2013 verbinde, funktioniert es ohne Probleme. Exportiere ich dann den Registry-Eintrag und ändere den auf Outlook 2016 um, funktioniert dieses dann auch.

  16. Hallo Frank,
    vielen Dank für die Antwort.
    Wie meinst du das mit unterschiedlichen Authentifizierungseinstellungen? Wenn ich bei Outlook auf den Verbindungsstatus gehe, macht er bei mapi over http NTLM Authentifizierung, was auch so eingestellt ist.

    Gruß Jo

  17. Hallo Jo,
    Frank meint die Authentifizierung die bei den virtuellen Directorys eingestellt ist.
    Gruß Pad

  18. Hallo Pad,
    vielen Dank für deine Antwort.
    Hab ich kontrolliert, nur wenn ich das richtig verstehe, habe ich doch generell unterschiedliche Authentifizierungseinstellungen. Bei OWA z.B. hab ich nur Standardauthentifizierung.
    Was ich nicht verstehe, bei Outlook 2013 gehts ohne Probleme. Nur bei Outlook 2016 kommt immer die Kennworteingabe.

  19. Hi,

    sorry, hab mich blöd ausgedrückt. Ich meinte ob es unterschiedliche Auth. Methoden für Outlook Anywhere gibt. Auf dem neuen Exchange Negotiate auf dem alten NTLM, bzw auf dem neuen Negotiate (Aushandeln) auf dem alten Basic.

    Gruß, Frank

  20. Vielen Dank für die wunderbare Aufklärung hier!
    Meine Frage ist noch, der Autodiscover funktioniert mit Domänenanmeldename wunderbar.
    Wie bekomme ich es jetzt noch hin, das der Autodiscover zusätzlich mit mail@domain.com und passwort läuft?

    lg

  21. Hi Sebi,
    dazu musst du alternative Benutzerprinzipalnamen-Suffixe erstellen und den Benutzernamen entsprechend ändern. Als Alternativen Suffix müsstest du dann Domain.com konfigurieren und den AD-Benutzer Namen auf „mail“ ändern. Daraus ergibt sich dann der Benutzername mail@domain.com, also AD-Benutzername gleich E-Mail Adresse.
    Gruß, Frank

  22. hallo zusammen,
    ich habe seit gut 2 jahren ein hostet exchange bei ovh und office 365.
    alles läuft bislang super, sync auf android, ipad und am windows7 pc und windows 8.1 lappi klappen fehlerfrei.

    nun habe ich einen neuen, laptop gekauft und wollte dem natürlh meine office lizenz verpassen und fortan auch hierüber – selbstverständlich – mein exchenge nutzen.

    meine domain ist bei strato,gehostet und ein entsprchender mx-eintrag ist korrekt eingetragen.

    auf dem neuen nitebook fehlt nun leider der punkt für die manuelle installation eines exchange accounts, bei dem ich wie früher meine einträge zum hostet exchange eintragen konto.
    es fing an mit exchange. server.local
    dann wurde die mailadresse als login und das passwort abgefragt, danach ging es darum „meinen server“ und den proxy hierfür mit msstd:“mein server“ anzugeben. etwas warten und fertig.

    leider geht das so eben nicht mehr, denn auf dem neuen notebook wird mit dem installer aus office365 ein 2016er outlook installiert.

    was kann ich tun?

  23. hallo frank – habe ein seltsames problem – habe ein notebook, welches über openvpn mit meinem server kommuniziert
    auf dem notebook ist win 7 prof und office 2016 drauf

    bei mir im lan steht der windows server 2011 mit exchange drauf

    die kommunikation klappte bereits mit outlook 2016 und exchange
    dann wurde auds irgendwelchen gründen 2016 runter genommen und 2007 installiert – das funzte auch – nun wollte ich wieder 2016 drauf spielen nun kommen die probleme

    beim konto anlegen
    also nach eintrag der konto daten

    Sicherheitshinweis
    grünes häckchen bei Das Sicherheitszertifikat stammt von einer vertrauenswürdigen Zertifizierungsstelle
    grünes Häckchen bei Das Datum des Sicherheitszertifikat ist gültig
    rotes Kreuz bei Der Name auf dem Sicherheitszertifikat ist ungültig oder stimmt nicht mit dem Namen der Website überein

  24. habe auch auf Zertifikat installieren geklickt –
    aktuelle user – Zertifikatspeicher automatisch auswählen

    danach weiter

    – dann kommt die meldung, dass er den server nicht findet –

    richtig eingetragen ist er aber schon – und anpingen kann ich ihn auch

  25. Hallo Frank, hab mit Interesse die Artikel über activesync gelesen und versucht eine funktionierende Verbindung mit einem Notebook von extern (Outlook 2016) aufzubauen.
    Firewallregel eingehendes HTTPS auf Exchangeserver HTTPS ist vorhanden
    leider wird der Server nicht gefunden.
    die Einträge beim Provider sind gesetzt (activesync, autodiscover)
    Brauche ich jetzt ein öffentliches Zertifikat oder kann ich auch selbst eines erstellen?
    Zertifizierungsstelle ist unser Exchange 2010

  26. Hallo Frank,
    ich habe dasselbe Problem aber bei mir ist das noch komplizierter. Die Autodiscovery kann es meiner Ansicht nach nicht sein. Sowohl vom iphone, vom Andoid als auch vom Outlook auf Mac kann man die Accounts einrichten.

    Nur von einem Win10-VM mit Outlook 2016 nicht. Ich habe die Firewall ausgeschaltet ohne Effekt. Und wenn ich den Link in einen Browser auf der Win10-VM eingebe, dann meldet sich das Exchange, fragt die User-Daten ab und wenn man die richtig eingibt, dann kommt das wsdl als Antwort zurück.

    Nur eben das Einrichten des Accounts in Outlook geht nicht….

    Fällt dir noch was ein ?

    Gruss

    Richard

  27. Wie auch einige meiner vorredner ist es nicht mehr möglich solch eine verbindung herzustellen

    ich habe ein w7 notebook mit outlook 2016 versucht über das internet mit unserem exchange 2010 zu verbinden.
    unser autodiscover läuft, outlook anyhwere hat auch mit den alten oultook versionen immer funktioniert.

    an der firewall sehe ich auch das eine anfrage vom client ohne problem an kommt, aber outlook bricht dann mit EAS Server wrude nicht gfunden ab.

  28. Hallo Frank,

    ich bekomme das hier intern nicht zum Rennen (sind bei einem Kunden drüber gestolpert, bei dem wir es jetzt mit einer lokalen XML gefixt haben). Ich habe alle Pfade so angepasst, wie du es oben auch gemacht hast (nur halt outlook.meinedomain.de und autodiscover.meinedomain.de), habe intern in meinem DNS 2 Zonen angelegt: outlook.meinedomain.de und autodiscover.meinedomain.de und darin einen A Record ohne Hostnamen mit der internen IP meines Ex2010. Löst auch auf am Rechner.
    Outlook Anywhere ebenfalls auf outlook.meinedomain.de konfiguriert.
    Für outlook.meinedomain.de und autodiscover.meinedomain.de, sowie *.int.meinedomain.de (das ist unsere AD Domain) habe ich ne Ausnahme im Proxy gesetzt.
    Versuche ich nun als angemeldeter Benutzer Martin ein neues Exchangekonto vom Benutzer Support einzurichten, bekomm ich erstmal (korrekt) den Zertifikatshinweis, dass der Name nicht matcht (das Zertifikat ist auf *.int.meinedomain.de ausgestellt), danach versucht Outlook die Servereinstellungen abzurufen, was fehlschlägt (dann will er es unverschlüsselt probieren, was auch fehlschlägt).
    Öffne ich mein Outlook mit meinem Konto (Martin) und mache nen Autoermittlungstest, geht der einwandfrei durch (über den InternalServiceURI bei ClientAccessServer autodiscover.meinedomain.de/autodiscover/autodiscover.xml).
    Wo ist mein Denkfehler? Danke euch, Gruss, Martin

  29. Hallo Leute,
    kennt jemand einen weg wie man bei Outlook 2016 das Autodiscover abstellen kann.
    Also so das man Outlook 2016 wieder per Hand einrichten kann.
    So wie es auch bei Outlook 2013 der Fall war.

    Danke für Tipps.
    LG
    Dirk

  30. Hallo Frank,

    wir haben bei Kunden oft den Fall, dass Exchange 2010 oder Exchange 2013 im Einsatz ist. Outlook / OWA sind nicht aus dem Internet erreichbar ist. Es muss erst eine VPN-Verbindung zum entsprechenden Unternehmensnetzwerk aufgebaut werden, erst dann können User sich über Outlook oder OWA verbinden.
    Dies stellt meiner Meinung nach eine zusätzliche Hürde für Angreifer dar. Mit dem Paragidmawechsel muss der Exchange-Server unbedingt aus dem Internet direkt erreichbar sein. Ich frage mich, ob du oder auch andere nicht vor demselben Problem stehen, die Sicherheitsarchitektur komplett verändern zu müssen.

    Viele Grüße
    MB

  31. Hallo MB, das kann man elegant mit einem SSL Reverseproxy lösen. Dieser nimmt die Verbindung an und leitet intern die Pfade an den Exchange in der DMZ weiter – und nur die relevanten Pfade. Dadurch verringert sich eine Angriffsfläche gegen 0, vorausgesetzt, man hat ordentliche Passwortpolicies. Es lässt sich eine zusätzliche Hürde einbauen, wenn man Clientzertifikate ausgibt und auf dem Proxy nur Verbindungen mit Zertifikat annimmt.

  32. Hallo Martin,

    du hast natürlich recht. Eine Filterung auf Anwendungsebene kann man natürlich immer vornehmen. Ich bezweifele aber, dass dies die Angriffsfläche gegen 0 tendieren lässt. Passwörter lassen sich natürlich kontrollieren, aber Fehler in der Software nicht. Somit ist ein zusätzlich Dienst der öffentlich erreichbar ist eine zusätzliche Angriffsfläche. Den Tip mit den Clientzertifikaten werde ich mir aber merken.

    Danke dir.

    Viele Grüße
    MB

  33. Hallo,
    auch Fehler in der VPN Implementierung lassen sich nicht ausschließen, aktuell z.B. bei Cisco. Client Zertifikate lassen sich allerdings derzeit nicht für Outlook Anywhere nutzen, helfen also auch nur bedingt. Natürlich ist es richtig, dass jeder Dienst der aus dem Internet erreichbar ist, die mögliche Angriffsfläche erhöht, da bildet auch Exchange keine Ausnahme. Dieses Problem ist allerdings nicht neu, daher gibt es entsprechend viele Produkte die eine Absicherung ermöglichen, da wird sicherlich jeder fündig. Ein VPN ist auch nicht immer das Mittel der Wahl, siehe Office 365. Wie so oft, kommt es wohl auf den Anwendungsfall an :-)

    Gruß, Frank

    PS: Leider ist kein Stück Software frei von Bugs, auch die Anbieter von speziellen Sicherheitslösungen haben damit ihre Probleme. Ich erinnere mich noch an den Fall, bei dem es reichte eine Mail an eine recht hochpreisige E-Mail Security Appliance zu schicken, um die Kontrolle über die Appliance zu übernehmen.

  34. Hi Frank,

    du kannst den SSL Proxy mit Squid oder Pound aufsetzen. Bei Outlook Zugriff bevorzuge ich Pound, wenn es nur um ActiveSync und OWA geht, ist auch Squid gut. Es wird der SSL Proxy mit Zertifikat abgesichert, nicht der Exchange. Das ist das Charmante daran, du kannst den Exchange (fast) in der Grundkonfig belassen, die Clients verbinden sich mit dem Proxy.

    Gruss,
    Martin

  35. Hi Frank,
    habe nach wie vor Probleme mit nicht Domain-PCs. Autodiscover funktioniert, Split DNS löst auch richtig auf.
    Connectivity-Test ohne Probleme, Domain-PCs laufen ohne Probleme
    Beim Erstkontakt sagt Outlook2016, “ EAS angegebener Server wurde nicht gefunden. Benutzername oder Kennwort sind ungültig – deutet eher auf ein Authentifizierungsproblem hin.
    Active Sync funktioniert sonst ohne Probleme.
    Hast Du eine Idee in welchen Logs ich mehr Informationen finden kann. Aufgabe ist es auch externen MA einen Outlook-Client auf fremden Rechnern zur Verfügung zu stellen. (Office 2010 und 2013 laufen ohne Probleme auch extern)
    Danke für einen Hinweis!

    Gruß Ralf

  36. Hi Martin,
    sicherlich kann man das machen, aber warum? Ein simpler Proxy bietet keinen Mehrwert. Ein Exchange Server muss immer konfiguriert werden, daran ändert auch ein Proxy nichts (egal welcher). Zusätzlich will der Proxy konfiguriert werden. Erst einmal macht ein Proxy die Umgebung also komplexer und damit komplizierter. Gerade im Hinblick auf Pound (wird das überhaupt noch weiter entwickelt?) sehe ich keinen Vorteil, außer SSL-Offloading passiert da nicht viel, da reicht in Single Server Umgebungen auch simples DNAT. Clients verbinden sich ebenfalls nicht mit dem Proxy, der Proxy leitet denn Client nur entsprechend an die Exchange Server weiter und kümmert sich ggf. um etwas Optimierung / Absicherung, beides ist weder bei Squid noch bei Pound von Haus aus gegeben. Wenn sich Exchange Server nicht mittels DNAT im Internet erreichbar machen möchte (wer will das schon), sollte hier lieber auf entsprechende Produkte zurückgreifen, als Beispiel sei hier nur die Sophos UTM genannt. Welches Ziel verfolgst du, wenn du Squid/Pound als Proxy für Exchange einsetzt?

    Gruß,
    Frank

  37. Hi Frank, an erster Stelle meiner Gründe steht die schlichte Tatsache dass das Setup stabil, standardisierbar und kostenlos ist :)
    Was ne UTM kostet, wissen wir ja. Wenn eh sowas vorhanden ist, kann man natürlich darauf zurückgreifen.

  38. Hi Martin,
    ok, aber welches konkrete Problem löst du damit? Ich meine ein DNAT würde ebenfalls deine Anforderungen erfüllen (stabil, kostenlos, standardisierbar). Dein Proxy übernimmt ja in diesem Fall keine Aufgaben einer Firewall/UTM, es sei denn du erweiterst ihn um Funktionen. In deinem Fall würde ich behaupten wird die Angriffsfläche größer, denn auch der Proxy und dessen OS können Schwachstellen enthalten.

    Gruß, Frank

  39. Hi Frank,
    wo soll ich anfangen? :)
    a) ich kann den Proxy in einer Cloud positionieren und per VPN an mein Netz anbinden
    (=ich muss mein Netz nicht nach draussen öffnen, auch ein DNAT ist die böse Source ANY Freigabe auf der Firewall, gegen die wehre ich mich mit Händen und Füssen)
    b) der Proxy leitet nur Anfragen auf validen Pfaden weiter
    (=alles andere wird gleich gedroppt. Ausserdem kann ich auf der Firewall vom Proxy auch noch „Dinge“ tun, falls das notwendig sein sollte)
    c) Der Proxy ermöglicht mir flexibel mit Zertifikaten umzugehen
    (=ich brauch nur ein named Cert, kein SAN Cert einer Zertifizierungsstelle, die halt auch ein wenig Geld kosten)
    d) Der Proxy erlaubt mir eine Verbindung nur mit Clientzertifikaten einzurichten, was auf einer MS Infrastruktur ungleich komplexer ist, ich will nicht immer gleich ne PKI aufsetzen
    und letztlich e) der Proxy kann auch andere Dienste verbinden, wenn das benötigt wird, und wird damit auch zum zentralen Debugginginstrument, wenn mal was klemmt

    Letztlich ermöglicht mir ein SSL Reverse Proxy viele Dinge, für die ich ansonsten in vielen Infrastrukturen (besonders von sehr kleinen KMUs mit <100 Mitarbeitern) jede Menge Geld für Firewall, Intrusion Detection und Knowhow ausgeben müsste. Ich sehe hier nur Vorteile eigentlich.

    Gruss,
    Martin

  40. Hi Martin,

    in deiner Konfiguration hast du aber Squid/Pound schon deutlich angepasst, in diesem Fall kannst du natürlich von einigen Vorteilen gebrauch machen. Ob das günstiger ist, als eine entsprechende Firewall direkt zu erwerben und zu betreiben, kann ich nicht beurteilen. Exchange kommt auch wunderbar mit Named Zertifikaten zurecht. Source/Any verlagerst du dann halt in die Cloud, knacke ich den Proxy, habe ich dann ggf. Zugriff auf das restliche Netz, wenn es per VPN angebunden ist. Alternativ brauche ich den direkten Zugriff gar nicht mehr, hab ja schon den Proxy und sitze dazwischen, schön wenn er sogar SSL-Offloading übernimmt :-) Ganz lustig wird es, wenn ein Proxy für mehrere Netze/Umgebungen zuständig ist. Eine Konfiguration wie du sie schilderst erfordert einiges an KnowHow um die Sicherheit zu gewährleisten, ob das dann ein KMU ohne weiteres betreiben kann? Ich halte auch nichts davon Exchange direkt per DNAT zu veröffentlichen, ich habe allerdings auch schon diverse Bastelprojekte mit Proxies gesehen, die dann eher als Scheunentor dienen. Bei den restlichen Punkten stimme ich zu, richtig umgesetzt macht das Sinn.

    Gruß, Frank

  41. VPN hast du nur über eine Firewall auf eine dedizierte IP. In das Netz kommt keiner, auch wenn der unwahrscheinliche Fall eintritt, dass es wer schafft den Proxy zu knacken. Er müsste als zweites also den Exchange kapern. Letztlich ist eine Risikobewertung zu machen. Es gibt viele Lösungen für viele Aufgaben. :)

  42. Wenn ich im Proxy bin muss ich nur warten bis sich ein Admin einloggt. tcpdump ist bestimmt schon für Debugzwecke installiert :-) Während des Wartens lese ich solange Mails mit um mir die Zeit zu vertreiben. Warum sollte es leichter/schwieriger sein den Proxy/Exchange zu knacken? Beide Systeme können entsprechende Lücken enthalten die es möglich machen. Natürlich kann man es entsprechend abdichten, das erfordert aber auch entsprechendes KnowHow. Ich finde das gilt sowohl für Exchange als auch für entsprechende Proxylösungen. Viele Lösungen, sorgen für viele Aufgaben :-)

  43. Unterm Strich der Diskussion: wie kann man einen Exchange, deren Anwender OWA nutzen und Smartphones anbinden möchten schützen? Lücken gibt es überall, der Exchange gehört gepatched. Aber gibt es reale Szenarien außer schwache Kennwörter (von Social Engineering abgesehen)? Klar ist: wer rein will, kommt rein. Ich täte es allerdings nicht über den Exchange…

  44. Hi Frank, ganz so einfach isses dann doch nicht zum Glück ;-)
    Ich geb dir Recht: wenn man irgendwo rein will, wird es meistens einen Weg dahin geben – die Frage ist nur, wie hoch die Schwelle liegt und wie versiert der Angreifer ist. Mails mitlesen kannst du keine – ein Proxy ist kein Relay, er transportiert keine Emails. Mitsniffen kannst du auch nicht viel, da sämtliche Kommunikation SSL verschlüsselt ist. Theoretisch könntest du irgendwo zwischen Annahme der Verbindung und ausgehender Verbindung nen Memory Dump ziehen – ich wüsste hier aber schon nicht mehr wie das geht :)
    Vom Proxy auf den Exchange kommst du auch nicht, weil auch der wieder hinter einer Firewall liegt und keine direkten Durchgriffe auf RDP oder Telnet möglich sind.
    Ich bin nicht der Experte für Reverse Proxys, dafür habe ich Kollegen, aber die versichern mir glaubhaft, dass hier eine recht hohe Sicherheit gegenüber einem NAT auf der Firewall gegeben ist.
    Das Knowhow wird der Kunde nicht haben (in den meisten Fällen), wir bieten das aber standardisiert als Produkt an – für einen monatlichen Obulus. Aber das hier ist ja kein Werbeforum, sondern deine (im Übrigen extrem gute und kompetente) Website. Danke trotzdem für deine konstruktive Meinung!

  45. Hi Martin,
    doch eingentlich ist es so einfach. Der Proxy ist der klassische Man in the Middle. Der Reverse Proxy (eigentlich egal ob Forward oder Reverse Proxy) bricht die SSL Verschlüsselung auf, das ist in der von dir genannten Konfiguration ja auch der Fall, da du ein Zertifikat am Proxy konfiguriert hast (SSL Offloading). Die Verbindung ist nur vom Client bis zum Proxy verschlüsselt. Am Proxy sehe ich also den unverschlüsselten Traffic, dabei ist auch egal ob die Verbindung wieder neu verschlüsselt wird und zum Exchange Server geleitet wird (SSL Bridging). Werfe ich also am Proxy tcpdump an und entschlüssele mittels Private Key vom Proxy den Traffic, dann sehe ich die Benutzernamen und Kennwörter der Benutzer im Klartext. Benutzer und Kennwort kann ich jetzt ganz normal verwenden um mich an beispielsweise an OWA anzumelden, hier lese ich dann in Ruhe alle Mails. Nett wird es, wenn sich ein Admin anmeldet und die Remote PowerShell des Exchange Servers verfügbar ist (per Default ist sie das). Dazu muss ich gar nicht den Exchange Server erreichen, wo der steht und wie er abgesichert ist, spielt dann schlicht keine Rolle mehr. Natürlich ist es nicht unbedingt einfach in den Proxy zu kommen. Diverse Lücken in weit verbreiteten Paketen hätten das in der Vergangenheit aber ermöglicht. Vielleicht schreibe ich da mal einen kleinen Artikel zu, dann wird es etwas anschaulicher. Vielen Dank für das Lob und ein schönes Wochenende,

    Frank

  46. Hi Frank, mein Kollege meint das Zertifikat auf dem Server wird nur zur Aushandlung der Verbindung genutzt. Die Daten werden mit einem Schlüssel gesichert der nur 15 Minuten gültig ist. Danach wird ein neuer ausgehandelt. Ich lehne mich hier weit aus dem Fenster weil das so nicht mein Fachgebiet ist.

  47. Hi Martin,
    schön zu hören das PFS genutzt wird, wenn ich allerdings die Möglichkeit habe am Proxy (also innerhalb des Proxys) zu sniffen, dann kann ich ebenfalls das Master Secret lesen und weiterhin im Klartext mitlesen. PFS schützt allerdings davor, dass mitgeschnittener Traffic nachträglich mit dem private Key entschlüsselt wird, dies minimiert die Gefahr das ein Port gespiegelt wird und nachträglich analysiert wird. Die Netzwerker mögen daher PFS auch meist nicht so gerne ;-)

  48. Hi Frank,
    habe noch ein Problem beim Split DNS. Beim Get-*:
    Get-ClientAccessServer | fl autodiscover*
    Get-ActiveSyncVirtualDirectory | fl *url*
    Get-OutlookAnywhere | fl *hostname
    Get-WebServicesVirtualDirectory | fl *url*
    Get-OwaVirtualDirectory | fl *url*
    Get-OabVirtualDirectory | fl *url*
    sind alle internen und externen Urls identisch, außer die InternalNLBBypassUrl. Ein Proxy Server ist nicht aktiv. Ein Zertifikat mit den öffentlichen Namen ist auf dem IIS aktiviert. Autodiscover funktioniert (MS-Test)
    Beim Starten von Outlook 2013/2016 kommt die Meldung: Der Name des Sicherheitszertifikats ist ungültig oder stimmt nicht mit dem Name der Webseite überein‘. Als Name wird die exchange.xxx.local angezeigt.
    Wo kann ich noch was drehen, damit diese Warung verschwindet?

  49. Hi Klaus,
    was meinst du mit „als Name wird die exchange.xxx.local angezeigt“? Ist das der Name des Zertifikats oder der Servername, der nicht zum Name des Zertifikats passt?
    Bei Ex2010 findet die Kontaktaufnahme zum Exchange über die AutodiscoverServiceInternalUri statt.
    Dein Zertifikat muss installiert und auf dem Exchange für die Services IIS und SMTP aktiviert sein.
    Und was mir noch in deiner Übersicht fehlt: was ist denn mit der get-autodiscovervirtualdirectory?

  50. Name ist der FQDN des Exchange Servers, angezeit wird das öffentliche Zertikfat, welches den .local Namen NICHT enthält.
    Get-autodiscovervirtualdirectory enthält nur bei der internalUrl die öffentliche Autodiscover Url . ExternalUrl ist leer, ansonsten taucht der Name des Exchange Servers noch bei MetabasePath und ObjectCategory auf.
    Beim der EMC wird noch ein weiteres Zertifikat mit dem Friendly Name „Microsoft Exchange“ angezeigt, was zusätzlich zum öffentlichen Zertifikat den SMTP Services hat. Das Zertifikat ist nicht mit dem Schlüssel exportierbar. Die Zuweisung für SMTP ist nicht entfernbar (ausgegraut). Ich trau mich nach dem gestrigen Desaster nicht es aus dem EMC zu löschen..

  51. Ich hatte heute neu den Fall, dass Outlook 2016 nicht mehr bis zum Test des SRV Records im DNS kam. Wisst ihr da irgendwas, ob MS da mit einem Patch dran geschraubt hat?
    Bisher war mein Kenntnisstand:
    SCP im AD
    emaildomain.de/autodiscover
    autodiscover.emaildomain.de/autodiscover
    SRV Record
    local XML
    in dieser Reihenfolge.

    Ich musste den Autodiscover bei denen komplett umbauen, damit das wieder funktioniert hat (ist aber auch sehr spezielles Setup, der Exchange ist nicht in der local Domain).

  52. Ah, und Klaus: mach mal den Autoermittlungstest und schau dir danach ganz genau die XML an, die ausgegeben wird. Irgendwo hast du noch den Servernamen drinstehen.

  53. Hi Martin,
    du meinst doch Autodiscover auf https://testconnectivity.microsoft.com/ oder?
    Da gibt’s kein XML zum anschauen.
    Der Autodiscoverliefert nur eine Warnung:
    Analyzing the certificate chains for compatibility problems with versions of Windows.
    Potential compatibility problems were identified with some versions of Windows.
    Additional Details
    The Microsoft Connectivity Analyzer can only validate the certificate chain using the Root Certificate Update functionality from Windows Update. Your certificate may not be trusted on Windows if the „Update Root Certificates“ feature isn’t enabled.

    Was kann passieren wenn ich das SMTP Zertifikat (s.o.) welches nicht exportierbar ist lösche?

  54. Das Microsoft Exchange Zertifikat installiert der Exchange selber, das brauchst du mE und das hat auch nichts mit deinem Problem zu tun.

  55. ja, da ist bei mir ein Eintrag drin:

    EXCH
    EX2010.mydomain.local
    Bei den anderen EXPR und WEB sind öffentlichen Namen drin.
    Get-OutlookProvider exch liefert leere Einträge für:
    CertPrincipalName :
    Server :
    Muss ich die jetzt auch beide noch setzen für EXPR?

  56. Hi,
    ich misch mich mal kurz in die Diskussion ein :-)
    Ich hab jetzt nicht alles im Detail gelesen, aber ich nehme an, du hast kein CAS-Array konfiguriert. In diesem Fall laufen Outlook Mapi (RPC) Verbindungen immer gegen den lokalen Servernamen. In deinem Fall „EX2010.mydomain.local“, erst durch die Konfiguration einen CAS-Arrays kannst du einen anderen DNS-Namen konfigurieren. Falls dein Zertifikat nicht den lokalen Servernamen (Ex2010.mydomain.local) enthält, kommt es zu den Zertifikatswarnungen. Entweder du konfiguriert also ein CAS-Array, dann musst du also nachträglich, dann musst du allerdings die Outlook Profile neu einrichten, oder du besorgst dir ein Zertifikat mit dem lokalen Servernamen, etwa von einer internen CA.

    Gruß, Frank

  57. dann wär es wohl besser erst mal das Split DNS wieder zurückzudrehen.
    Würde es mit Ex2016 funktionieren?

  58. Hi,
    das lässt sich entsprechend zusammenbauen:

    $newdisplayname=$user.Name + “ | Firmenname“

    wird zu:

    [string]$currentdisplayname = $user.name
    $newdisplayname = $currentdisplayname.replace(„Ä“,“Ae“)
    $newdisplayname = $currentdisplayname.replace(„ä“,“ae“)
    usw…

    Allerdings müsste es grundsätzlich auch mit Umlauten funktionieren, wenn das Script aus einer PS1 Datei ausgeführt wird, würde ich mal das Encoding prüfen.

    Gruß, Frank

  59. Hallo zusammen,

    Ich habe ein Problem mit Exchange 2016 und Outlook 2016. Emails werden per Pop3 bei 1und1 abgeholt. Versendet werden die Mails über Smart Host von 1und1. Es wurde ein eigener Zertifikatsserver installiert und selbsterstelltes Zertifikat eingebunden. Klappt alles wunderbar. Autodiscover und Outlookanywhere Zonen wurden im lokalen DNS eingetragen mit dem Verweis auf den Exchange 2016. Jetzt kommt Outlook 2016 ins Spiel – Einrichten des Accounts klappt super, aber wenn man dann z. B. Outlook neu startet kommt eine Benutzerabfrage bzw. im gleiche Zug kommt auch eine Meldung von autodiscover.1and1.info -> https://hilfe-center.1und1.de/hosting/e-mail-und-office-c10082645/microsoft-outlook-c10082708/bedienung-c10082760/was-ist-autodiscover-a10795344.html. Ich habe schon mit allmögliche Registryeinträgen versucht das zu unterbinden, aber mal kommt es mal kommt es nicht. Kann mir da jemand weiterhelfen, denn ich bin hier echt am verzweifeln und musste auf Outlook 2010 zurückgehen, denn damit klappt es ohne Probleme, auch die Autodiscovereinrichtung vom Exchange.

    Gruss
    Peter

  60. Hi Frank,

    Danke für deine Antwort. Habe jetzt mit 1und1 kontakt aufgenommen und ich muss eine Subdomain mit „autodiscover.“ erstellen und unter der Subdomain einen SRV Eintrag mit _autodisocver auf den Exchange einrichten. Ich bin mal gespannt…

  61. Hi Frank,

    Wollte nur Bescheid geben, dass das so klappt wie oben beschrieben. Es kommmen keine Autodisovermeldung mehr.

    Hast du noch evtl. einen Tipp für folgende Kleinproblematik: Outlook 2016 (In Verbindung mit Exchange 2016) öffnet sich das erste mal ohne Probleme -> Man schliesst es -> Öffnet es erneut und ggf. kommt jetzt schon das Fenster „Windows-Sicherheit“ wo man Benutzernamen und PW eingeben muss. Klickt man es weg, dann steht unten rechts im Outlook Fenster „Kennwort erforderlich“. Klickt man darauf, ist man sofort mit dem Server verbunden. Wenn ich die Benutzerdaten eingebe und sie speicher, dann werden sie im Tresor vom Windowsclient fest gespeichert und die Melung kommt nicht mehr. Eine Idee warum das kommt?

  62. Guten Tag Frank,

    du hast echt eine tolle Seite, herzlichen Dank dafür.

    Habe hier einen Exchange 2016 mit dynamischer WAN IP. Habe beim Provider eine Sub-Domain angelegt und die DynDNS-Adresse dort angelegt. Welche externe IP soll ich nun im Exchange für die virtuellen Verzeichnisse eintragen? Die DynDNS oder die Subdomain?

    Aktuell verwendet ich OWA (lokaler Zugriff https://ex01), ist ein gutes Tool, eignet sich jedoch eher als Outlook-Ersatz. Auch für den Außeneinsatz ist es prima geeignet. Nun möchte ich jedoch mehreren internen Clients mit Outlook in Betrieb nehmen.

    Aktuell bereitet uns das Outlook 2013 einige Kopfzerbrechen. Sobald wir Outlook (beim angemeldeten Benutzer in der Domäne) starten, frägt das Outlook ob wir das Zertifikat bestätigen wollen, nach dem Bestätigen der Zertifikate (vom Exchange bei der Installation selbst erstelle Zertifikate) funktioniert erstmals Outlook. Sobald Outlook geschlossen und wieder gestartet wird, frägt das Outlook nach den Zugangsdaten, diese werden jedoch nicht akzeptiert und Outlook kann keine Verbindung zum Exchange aufbauen (Fehlermeldung: „Der Name kann nicht aufgelöst werden. Es steht keine Verbindung mit Microsoft Exchange zur Verfügung. Outlook muss im Onlinemodus oder verbunden sein, um diesen Vorgang abzuschließen.“).

    Ist es hier ein DNS-Problem?
    Wenn ich das Exchange aktuell nur intern verwenden möchte, muss ich trotzdem die Zertifikate von einem Anbieter ausstellen lassen?
    Wieso sollte die interne und die externe URL gleich sein, gibt es da Vorteile?

    Über ne Rückmeldung würde ich mich freuen.

    Grüß
    Vamos

  63. Hallo,

    ich habe leider auch ein kleines Problem bei der Einrichtung.
    Anfangs läuft alles prima:
    Per Mailadresse und Passwort werden die Daten automatisch über https://exchange.meinname.de
    ausgelesen. Entsprechendes SSL-Zertifikat ist vorhanden.
    Dann kommt die Serveranmeldung. Geht zwar nicht per Mailadresse, aber mit Domänen-User.

    Dann schlägt der letzte Punkt fehl: Am Email-Server anmelden
    Im darauffolgenden Fenster steht als Exchange-Server: dc2012.meinedomäne.local
    Deshalb kann er ihn dann vermutlich auch nicht mehr auflösen.
    Müsste hier nicht auch die exchange.meinname.de stehen??

    Wo kann ich dieses Problem korrigieren?

  64. Hallo,

    ich habe den Fehler gefunden.
    Man muss die Outlook-Provider auf den Zertifikatsnamen setzen:

    Set-OutlookProvider EXCH -CertPrincipalName:“msstd:exchange.meinname.de“
    Set-OutlookProvider EXPR -CertPrincipalName:“msstd:exchange.meinname.de“
    Set-OutlookProvider WEB -CertPrincipalName:“msstd:exchange.meinname.de“

    Danach läuft der Outlook-Assistent fehlerfrei durch.

  65. Hallo Andreas,

    bei mir ist es genauso wie bei dir. Nur leider habe ich keine Ahnung wie ich die 3 von dir genannten Punkte wo eintragen kann. Kannst du mir bitte helfen?

    Danke.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.