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.
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:
Outlook 2016:
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:
- Exchange 2010: Zertifikate von Let’s Encrypt nutzen (Teil 1)
- Exchange 2010: Zertifikate von Let’s Encrypt nutzen (Teil 2)
Hi,
auch wenn das Thema alt ist und ohne alle Kommentare gelesen zu haben, ein einfacher Workaround für interne Exchange Server (die auch nur aus dem LAN oder per VPN erreichbar sind):
in der Hosts Datei die IP des Exchange-Server eintragen
10.0.0.2 autodiscover.domain.de
damit lässt sich das Konto zumindest im Outlook verbinden :)
VG
Irgendwer
Das habe ich auf dem Terminalserver auf dem sich der neue Benutzer anmeldet gemacht – leider bekomme ich das Outlook 2016 nicht für diesen User konfiguriert …
Andere Benutzer die früher angelegt waren, arbeiten ganz normal mit dem Exchange Konto der internen Domain *.local
Warum erkennt Outlook nach Löschung des Profils den Exchangeserver nicht mehr automatisch so wie früher?
VG Marcus
Hallo,
Ich habe ein großes Problem mit Outlook 2010 und Exchange 2016.
Alle notwendigen Updates für Outlook 2010 sind installiert.
Folgendes Szenario:
W2K8R2 Clients mit Outlook 2010, Internetzugang erfolgt über einen Proxyserver.
Die Virtuellen Verzeichnisse für den Exchange 2016 sind außer autodiscover :
mail.domain.de
autodiscover.mail.domain
DNS Forward Zonen sind entsprechend eingerichtet.
In den IE Proxyausnahmen ist mail und autodiscover enthalten.
Nun das Problem:
Bei aktiviertem Proxy in den IE Einstellungen kommt Fehlermeldung „Standard E-Mail Order konnte nicht geöffnet werden….“
Mache ich den Hacken in den IE Einstellungen für Proxyserver verwenden ganz raus, kann ich eine Verbindung über MapiOverHttps zu einem Exch2016 Postfach herstellen. Wenn ich über den IE https://mail.domain.de/owa eingebe, und der Proxy ist aktiviert, komme ich ganz normal auf die neue OWA Seite. Wenn ich im IE Ausnahmen für den Proxy setze, ist es doch das gleiche, als wenn ich den Proxyserver deaktiviere, zumindestens für die Ausnahmen.
Habt Ihr eine Idee zu meinem Problem?
Viele Grüße
Thomas
Guten Abend Peter,
ich habe etwas den Eindruck, dass dir etwas unklar ist, worum es sich bei autodiscover handelt. Es ist ein Webdienst, der per DNS über die E-Mailadresse den Exchangeserver finden soll(automatische Suche) für eine Anschließende Anmeldung. Das heißt, dass die externen Web-Seiten https://autodiscover.domain.de/autodiscover/autodiscover.xml oder auch für die Subdomain https://autodiscover.xy.domain.de/autodiscover/autodiscover.xml dorthin führen müssen, wo auch die OWA-Seite veröffentlicht wird wie etwa: https://outlook.domain.de/owa (dieselbe IP-Adresse wie bei Autodiscover, da es derselbe IIS-Server ist).
Was SMTP nach draußen betrifft, so hat das mit Autodiscover nichts zu tun. Zwar wird das auch über DNS geregelt, aber gültige und genutzte E-Maildomänen müssen als erste am Exchange als akzeptierte Domänen eingerichtet sein, welches für beides gilt Domain.de und xy.domain.de. Dann ist es erforderlich, dass anders herum ein MX-Eintrag für die Domänen im DNS zum Server/E-Mailgateway führen müssen.
Wenn aber die Sub-Domain nicht am Exchange gehostet wird, dann ist es erforderlich, um dennoch zu senden, dass der Exchange-Server per SPF-Eintrag im DNS zum Senden legitimiert wird. Das kann nur der Domain-Verwalter (admin von xy.domain.de) umsetzen. Durch SPF-Einträge werden die Server inzwischen autorisiert, um senden zu dürfen. Ansonsten wäre es ein Nährboden für reines Relaying und die Verwendung von geklauten E-Mailadressen durch x-beliebige Mailserver.
Mein Tipp also: Versuche mal ein MX-Lookup und in Absprache mit dem Admin des Domain-Providers herauszufinden, ob es für die Subdomain existierende SPF-Einträge gibt und ob der Exchange hinzugefügt werden kann.
Viele Grüße
joco
Hallo guten Morgen,
schon etwas älter dieser Beitrag, aber ich habe diesbezüglich ein Problem mit dem autodisvocer nach außen.
Hatte das wie oben beschrieben vor, hab auch bei meinem Provider ein CN Eintrag setzten lassen auf mail.domain.de -> ip (domain.lokal)
Habe auch ein öffentliches Zertifikat welches auf *.domain.de ausgestellt ist.
Mein Problem ist das ich keine neune Zone domain.de der bestehenden Zone domain.lokal hinzufügen kann, der Grund ist, dass die EMails von den Subdomain z.B. mail@xy.domain.de nicht auf unserem lokalen Server verwaltet werden. Wenn ich nun die Zone domaine.de anlege erzählt mir mein Exchange 2010 natürlich die EMailadresse mail@xy.domain.de gibts bei mir nicht.
Gibt es eine Möglichkeit dem Exchange 2010 so einzustellen das Mails an subdomain ins Netz gehen ?
Gruß
Peter
Hallo Peter,
du vermischst da eventuell 2 Dinge, Autodiscover und Relaydomains. Ich würde dir sehr empfehlen, deine Frage im Forum nochmal zu stellen. https://www.frankysweb.de/community/
Hallo Frank,
wir haben im Dienst eine Exchange 2010-Umgebung mit ca .3500 Postfächern (Standard und verknüpfte Postfächer, werden in Kürze eine Koexistenz mit Exchange 2016 aufbauen. Die Autoermittlung (autodiscover) ist selbstverständlich auch für unsere Exchange 2010-Postfächer konfiguriert und führt per DNS auf einen Forefront-TMG und danach intern auf das Exchangesystem. Aus Support- und Lifecyclegründen wird auch der TMG durch den Loadbalancer F5 abgelöst.
Die Probleme mit Outlook Anywhere bei Outlook 2016 und Exchange 2010 sind bei uns also kein Autodiscover-Problem, sondern ein Authentifizierungsproblem. Während in Outlook 2010 noch unterschieden werden konnte in den Verbindungseinstellungen hinsichtlich Standard- und NTLM-Authentifizierung, so schlägt Outlook Anywhere über Autodiscover mit Outlook 2016 von extern bei Standardauthentifizierung fehl. Das ist bei Outlook 2010 nicht so, obwohl es nicht manuell konfiguriert wurde.
Das wird in Kürze vermutlich anders laufen, da am Exchange 2016 und Loadbalancer F5 die formularbasierte Authentifizierung eingerichtet wird, welches wohl zwingend erforderlich ist.
Dennoch sind diese Einschränkungen der Konfigurationsmöglichkeiten bei Outlook 2016 ärgerlich und wirken wie ein Torso der vorherigen Outlook-Versionen.
Viele Grüße
Hallo zusammen,
habe gerade ein ähnliches Problem, bei dem ich schon seit zwei Tagen mir die Zähne ausbeisse.
Folgender Sachverhalt:
Vorher:
– Kunde war vorher bei 1&1 Mail
– hat einen internen Exchange Server 2013 und dieser hatte bis dato per PopCon die Mails vom 1&1 abgeholt
– die Mitarbeiter arbeiten alle auf dem Terminalserver mit Outlook, funktionierte auch bisher ohne Probleme
Neu:
– A Record mail.kundexyz.de auf die statische IP
– MX Record von 1&1 umgestellt auf mail.kundexyz.de
– autodiscover bei 1&1 angelegt CNAME auf mail.kundexyz.de
– SRV autodiscover auch bei 1&1 angelegt zeigt auf mail.kundexyz.de
– dann auf dem Kunden DNS Server Split-DNS angelegt mail.kundexyz.de > IP lokale Exchange
– autodiscover.kundexyz.de -> IP lokale Exchange
– SRV autodiscover unter mail.kundexyz.de und im kundexyz.local angelegt
– neues Wildcard Zertifikat *.kundexyz.de beantragt und auf dem Exchange Server eingespielt
– alle Externe/Interne URLs auf https://mail.kundexyz.de geändert (übernommen von autodiscover whitepaper)
Soweit funktioniert alles mails kommen an und gehen auch raus.
Das Problem was ich jetzt habe ist, das die Anwender beim Outlook starten jedes mal die Zertifikatsmeldung/Sicherheitshinweis bekommen das Aussteller/Datum gültig sind aber der Name nicht passt.
Wenn ich aber ein neues Outlook Profil anlege, dann bekomme ich diese Meldung nicht. Schön und gut, aber die Mitarbeiter wollen kein neues Profil da sonst alle Einstellung usw. nochmal vornehmen müssen….
Nach dem man aber das Zertifikat mit Ja bestätigt (muss man halt bei jedem Outlook start machen), dann geht es ganz normal weiter und alles funzt.
Nun gibt es aber einige User die leider nicht mehr auf freigegebene Kalender ändern können sprich anlegen/löschen usw.. aber sehen tun sie alles, es kommt eine Meldung das keine Berechtigung hat für diesen Kalender, obwohl es vorher ging und alle Berechtigungen vom freigegebenen User gesetzt wurde…
Ich habe die Befürchtung das irgendwo noch was fehlt, irgendwas übersehe ich gerade? DNS Eintrag fehlt? Oder muss ich noch den Parameter set-outlookprovider certprincipalname setzen? So wie ich das verstehe muss man das nicht oder?
Bitte helft mir, ich komme einfach nicht weiter…. :-(
Vielen Dank im Voraus…
Hey flo,
ich habe genau das gleiche Problem. Hast Du eine Lösung gefunden?
Beste Grüße
Hallo zusammen, bin gerade auch ein bischen am Verzweifeln, habe einen Exchange Server 2010 (SBS2011) und ein Outlook 2016, das extern ist. Intern funktioniert alles tadellos. auch die Iphone Funktionieren und lösen über Autodiscover auf. Keine Zertifikats meldung oder ähnlichem.
Beim Einrichten des Outlook 2016 Clients, melde ich mich per Autodiscover einmal mit derm Domän\Usernamen an und es kommt die Meldung alles okay. Outlook neugestartet,
Dann erhalte ich folgende Meldung, Die Ordnergruppe kann nicht geöffnet werden. Bevor Sie Ihre Ordner mit Ihrer Outlook-Datendate (.ost) Syschroniesieren können, müssen Sie eine Verbindung mit Exchange mit Ihrem Aktuellen Profil herstellen.
Profil habe ich schon zig fach gelöscht.
Auch unterschiedliche User habe ich versucht.
Vielleicht hat jemand irgendeine Idee dazu
Habe das gleiche Problem seit ich Exchange 2010 SP3 auf Rollup 25 gepatched habe.
Fälschlicherweise ist .Net 4.7.2 mit gepatched worden, welches für Exchange 2010 nicht supportet wird. Allerdings konnte ich dies wieder deinstallieren und danach war der .Net Build wieder auf 3.5..
Trotzdem kriege ich Outlook 2013/2016 via Autodiscover nicht mehr hin. Er kann zwar alles auflösen, jedoch beim öffnen erscheint dbenfalls die Meldung “ Die Ordnergruppe kann nicht geöffnet werden….
Hallo Franky,
Ich bin gerade etwas am verzweifeln. Und zwar folgende Problematik, interner Exchange 2010 der auf 2016 migriert wird.
Es gibt Emails mit domain.de (Die auch funktionieren nach Umzug auf 2016) und dann noch vertrieb.domain.de und Berlin.domain.de (bei beiden funktioniert Outlook nach Umzug nicht mehr OWA JA)
Ich tippe stark auf Autodiscover wie muss Autodiscover für Subdomains konfiguriert werden gibt es da eine gute Lösung, hast du sowas schon mal konfiguriert?
Mein Ansatz wäre die Domains im DNS Anlegen und dann einen Autodiscover (A-Record) anlegen. Zusätzlich noch einen CName auf die Hauptdomain setzen wegen dem Zertifikat oder geht das nicht und ich brauch zwingend auch die Subdomains drauf?
Grüße
Hi Frank,
Ich bin bl….. hatte einen Schreibfehler im FQDN (0 statt O). Puh, viel Arveit für nix, habe aber wieder was über autodiscover gelernt und einen abderen Fehler in der Config der Virtual Directories gefunden hnd behoben.
Microsoft Connectivity Test läuft für Outlook Connectivity wenn ich die DynDNS Adresse manuell als RPC Proxy Server eingebe. Nur Fehler dass dem Zertifiakt nicht vertraut wird, aber das habe ich ja selbst erstellt. Outlook Autodiscover geht nicht, da er nach autodiscover.domain.com sucht und der Name ist ja nicht veröffentlicht.
Ich weiß nicht mehr weiter.
Mmmhhh,
bin jetzt ein Stück weiter. Erhalte eine Zertifikatewarnung, dass Name im Zertifiakt und Website nicht übereinstimmen. Mein Exchangeserver meldet sich mit server.domain.local. Dieser Name ist auch im vom Echange 2010 von mir erstellten Zertifikat. Extern ist der Exchange über eine dyndns Adresse domain.dyndns.bz zu erreichen. Diese Adresse ist nicht im Zertifikat. Macht das ein Problem obwohl ich Outlook 2016 mit einme Client innerhalb der Domäne anbinden will?
Nachtrag:
https://autodiscover.xyz.dyn.bz gibt mir Zertifikatfehler. Hilft das Weiter. Sollte autodiscover.xyz.dyn.bz auch im Zertifikat enthalten sein?
Hallo Frank,
meine Konfiguration:
Exchange 2010 und Outlook 2013 Clients. Ich nutze Dyndns „xyz.dyn.bz“ und meine domain „firma.com“ und habe vor Jahren durch deine klasse Anleitung ein Zertifikat selbst erstellt. Läuft alles bisher.
Nun das Problem:
Umstellung eines Clients auf Outlook 2016 geht nicht. Im Zertifikat hatte ich damals auch „autodiscover.firma.com“ mit aufgenommen wie von Dir vorgeschlagen. Outlook 2016 meldet nun dass keine Anmeldung am Email Server möglich ist. Microsoft Connectivity Analyser mit Test „Exchange Active Sync“ läuft ok durch, wenn ich „Ignore Trust SSL“ anklicke. Sollte doch so sein, da ich ein eigenes Zertifiakt habe.
Im Outlook Anmeldung geb ich als Email server mein xyz.dyn.bz an. Hoffe das ist richtig.
Es klappt aber nicht. Was mache ich da falsch?
Benötigt Outlook 2016 ein kommerzielles SSL-Zertifikat und mein selbst ausgestelltes Zertifikat geht nicht mehr?
Das manche Provider inzwischen den Autodiscover kapern ist leider wirklich lästig.
In unserem Fall auch 1und1.
Leider hatte das Anlegen einer autodiscover.unseredomain.tld Subdomain mit CNAME auf den tatsächlichen Autodiscover-Host nicht den erhofften erfolg. Im MS Remote Connectivity Analyzer erschien bei der Methode über http redirect immer wieder dieser 1and1.info Eintrag, welcher für die massiven Probleme verantwortlich zu sein schien.
Letzlich hat es bei uns geholfen für die Subdomain autodiscover.unseredomain.tld einen Host-A Eintrag auf 127.0.53.53 zu setzen und somit bewusst ein anderweitiges Auflösen, Weiterleiten etc zu verhinden.
Daraufhin schlagen jetzt zwar die ersten 3 Methoden fehl, das Autodiscover funktioniert nun aber über einen SRV-Record für _autodiscover._tcp.unseredomain.tld welcher auf den Hostname des Exchange verweist.
Seither sind die nervigen Popups und defekten Outlook 2016 Profile wie es momentan aussieht Geschichte.
Hallo Manfred,
Ich habe noch mehrere SBS-Server 2011 mit einer ähnlichen Konfiguration wie Deine im Einsatz. Einzig das Outlook Anywhere lasse ich zu, so das ich keine VPN konfigurieren muss. Ich vermute das einer der DNS-Namen (welche der SBS-Server verwendet) nicht mit dem Zertifikat übereinstimmt.
Ich habe bei psw.net ein dreier-Zertifikat gekauft und eingebunden (remote.domain.local / autodiscover.domain.local / owa.domain.local). Seither löst auch Outlook 2016 ohne Problem auf.
Gruss Dave
Hallo Davide,
keine öffentliche CA wird mehr Zertifikate auf .local ausstellen.
Gruß, Frank
Hallo Frank,
Du hast natürlich Recht, die Zertifikate habe ich auf die öffentlichen Adressen ausgestellt. owa.domain.ch, remote.domain.ch und autodiscover.domain.ch. Die .local Adressen verwende ich natürlich nur als internen Domainnamen, wobei gemäss Deinem Best Practice man dies auch nicht mehr tut. Aber die Wahl des Domainnamen datiert aus dem letzten Jahrhundert (1999)…. ;-)
Gruss Dave
Hallo Frank,
danke für die zahlreichen sehr guten Informationen hier ! Für meine Exchange-Konfiguration bin ich leider nicht fündig geworden, habe mir schon die Finger wund gegoogelt. Alle Hinweise, Anleitungen beziehen sich auf die Standard-Konfiguration „Exchange ist aus dem Internet erreichbar und nimmt selber den E-Mail-Austausch vor“. Meine betreuten Exch. sind alle aus Sicherheitsgründen NICHT aus dem Internet erreichbar. Und jetzt gibt es ein Problem in Verbindung mit Outlook 2016, d.h über VPN bekomme ich keine Verbindung mit Outlook 2016 angelegt. Intern im LAN funktioniert es aber mit Zertifikat-Fehler. Vielleicht gibt es jemanden, der in so einer Konstellation Autodiscover + Zertifikate + evtl. DNS so konfiguriert hat, dass es interm im LAN und extern via VPN funktioniert ?!?
Meine Konfiguration:
– SBS2011 mit Exchange 2010 SP3 Rollup18 (also fast aktuell)
– POPcon
– Versand via Smarthost des Providers ALL-INKL.COM oder MITTWALD oder 1UND1 oder DF oder …
– von extern nur via VPN Zugriff auf den Server, Fritzbox mit FritzFernzugang oder ShrewSoft
– bis Outlook 2013 kein Problem auch dank manueller Konfigurationsmöglichkeit
– AD mit Domäne FirmaKurzname.local
– E-Mail-Domäne heisst anders: FirmaLangname.de
– Zertifikat vom SBS2011 selber erzeugt, ausgestellt für remote.FirmaLangname.de, ausgestellt von FirmaKurzname-Servername-CA
– SBS2011 DNS bisher nur mittels Assistent eingerichtet, d.h. so ziemlich alles auf Standard.
Und nun ? Über Rat wäre ich sehr froh.
Viele Grüße
Manfred
Hallo Manfred,
du musst nur die Zertifikate, Exchange URLs und damit auch Autodiscover konfigurieren. Solange via VPN die DNS Einträge auflösbar sind, gibt es auch keine Probleme mit dem VPN.
Gruß,
Frank
Hallo Frank,
Danke für den Whitepaper-Hinweis, den SRV-Record habe ich sowohl intern wie auch extern beim Hoster erstellt und auf die Domain autodiscover.firma1.ch hingewiesen. Leider ohne Erfolg, beim starten vom Outlook 2016 (ausser Haus) zeigt er immer noch ein Zertifikatsfehler an, das autodiscover.firma1.ch nicht mit autodiscover.firma2.ch übereinstimmt. Irgendwie scheint der externe SRV-Eintrag nicht zu greifen.
Werde wohl oder übel wohl ein neues Zertifikat mit allen Domains erstellen müssen. Aber danke für Deine tolle Arbeit!
Gruss Dave
Hallo Davide,
lösche den DNS Eintrag für autodiscover.firma2.ch. Ein neues Zertifikat ist, wie schon erwähnt, nicht nötig.
Gruß,
Frank
Ich habe den Beitrag bei meinen Favoriten hinzugefügt, da er perfekt und einfach die Autodiscover-Problematik beschreibt. Merkwürdigerweise habe ich eine Installation, wo mir das Autodiscover einen Strich durch die Rechnung macht.
Ich habe einen Exchangeserver wo eine Bürogemeinschaft von zwei Firmen besteht. Der Server hatte ich ursprünglich für die Firma1 installiert. Alle Exchange-Eintrage verweisen auf owa.firma1.ch oder autodiscover.firma1.ch.
Das funktioniert auch für die Firma1. Wenn nun aber ein Benutzer der Firma2 mit einer Mailadresse der Firma2 von extern zugreifen möchte, kommt die Outlook-Meldung das der Informationsspeicher nicht zur Verfügung steht.
Eine genauere Untersuchung hat ergeben, das der Name auf dem Zertifikat mit dem Namen der Webseite nicht übereinsteimmt. Er sucht nach autodiscover.firma2.ch und ich habe natürlich das Zertifikat für autodiscover.firma1.ch eingerichtet.
Muss ich nun ein Zertifikat für 4 Domains anlegen? Also owa.firma1.ch, owa.firma2.ch, autodiscover.firma1.ch und autodiscover.firma2.ch? Oder gibt es einen einfacheren Weg?
Gruss Dave
Hallo Davide,
nein du musst nicht alle Domänen in das Zertifikat aufnehmen. Das Stichwort heißt SRV-Record und ist im Whitepaper beschrieben:
https://www.frankysweb.de/exchange-2016-umfangreiches-whitepaper-zu-autodiscover/
Gruß, Frank
Toller Beitrag!
Ich habe ein aktuelles Problem mir Autodiscover bei der Migration von 2010 auf 2016.
SCP am 2010er ist exch2010.subdomain.domain.com
Split DNS:
subdomain.domain.com (kein Autodiscover Record)
domain.com (autodiscover.domain.com vorhanden – zeigt auf den Exch2010)
Im aktuellen SSL Zertifikat (Self Signed) ist nur autodiscover.domain.com vorhanden – Cert wird via GPO verteilt
Kann ich dem SCP am 2010 und 2016 auf autodiscover.domain.com drehen? Oder muss es autodiscover.subdomain.domain.com sein?
Oder kann ich den Hostnamen im SCP für 2010 und dann auch 2016 lassen?
Hallo Mike,
der Hostname im SCP kann auf autodiscover.domain.com gestellt werden, dies würde ich sogar bevorzugen.
Gruß, Frank
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.
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.
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?
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
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?
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…
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
Hi Peter,
zu 1und1 kann ich leider nichts sagen, aber ein ähnliches „Problem“ hatte ich bei Strato:
https://www.frankysweb.de/exchange-autodiscover-und-strato-webhosting/
Gruß, Frank
dann wär es wohl besser erst mal das Split DNS wieder zurückzudrehen.
Würde es mit Ex2016 funktionieren?
Lieber entsprechend konfigurieren, das wäre einfacher.
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
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?
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
Das Microsoft Exchange Zertifikat installiert der Exchange selber, das brauchst du mE und das hat auch nichts mit deinem Problem zu tun.
Hi Klaus, nein, ich meine den Autoermittlungstest von Outlook (STRG Taste und rechte Maustaste bei laufendem Outlook auf das Outlook Symbol im Systemtray).
https://blogs.technet.microsoft.com/austria/2011/01/02/outlook-wie-sie-ihre-outlook-konfiguration-testen-knnen/
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.
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..
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).
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?
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?
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?
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…
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. :)
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 :-)
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!
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
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.
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 ;-)
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
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
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.
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
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
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.
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
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
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
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
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.
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
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
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.
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
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
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
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
Renzstr.
8
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?
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
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
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.
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
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.
Hi,
kann es sein das die Authentifizierungseinstellungen unterschiedlich sind?
Gruß, Frank
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
Hallo Jo,
Frank meint die Authentifizierung die bei den virtuellen Directorys eingestellt ist.
Gruß Pad
Wichtig: Der Exchange Server 2010 muss mit dem SP3 ausgestattet sein, da dies die eine Voraussetzung für die Anbindung von Outlook 2016 ist.
Nachtrag:
statt autodiscover.example.de. sollte dann der Host vom Exchange drinnen stehen :)
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
Sollt doch auch ohne den autodiscover Host Eintrag klappen. Dann würde auch ein normales Zertifikat reichen. Dazu muß aber im DNS ein Eintrag gemacht werden.
_autodiscover._tcp.example.de. IN SRV 5 25 443 autodiscover.example.de.
Oder habe ich das falsch verstanden?
https://support.microsoft.com/de-de/kb/940881
wynni
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
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
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
Hi,
whats the Output for get-clientaccessservice | fl *autodiscover* ?
I think there will be an internal URL right?
regards, Frank
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
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
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)
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
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
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
Ach so. Vielen Dank für die Aufklärung!
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
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