Autodiscover V2

Exchange Administrator sollten eigentlich wissen wie Exchange - Autodiscover funktioniert. Irgendwann habe ich in meinen Proxy- und Fiddler-Logs aber neue Requests gefunden, die ich bislang nicht kannte. Über Autodiscover wurden JSON-Requests versendet und beantwortet. Hier meine bisherigen Analysen.

Autodiscover V2 wurde mit Exchange 2016 CU3 erst eingeführt.

Beispielrequests

Wenn ich die Logs im Fiddler betrachte, dann finde ich z.B. z.B. folgendes:

https://outlook.office365.com/autodiscover/autodiscover.json/v1.0/User1@uclabor.de?Protocol=Rest

Die Rückantwort ist dann eine JSON-Struktur:

{
   "Protocol":"ActiveSync",
   "Url":"https://outlook.office365.com/api"
}

Anscheinend kann ich mit einem einfachen anonymen Request nur mit Angabe der Mailadresse den Zugangspunkt zu einem Service ermitteln. Das hat meine Neugier geweckt.

Interessanterweise habe ich nie einen 403 mit der Aufforderung einer Anmeldung bekommen. Im Gegensatz zum originalen Autodiscover scheint V2 immer anonym zu arbeiten.

Outlook 2016 und Autodiscover

Zuerst habe ich die neuen Anfragen bei Microsoft Teams gesehen. Aber auch Outlook 2016 nutzt mittlerweile den Weg um die URL zu AutodiscoverV1 zu finden. Hier ein Auszug per Fiddler:

Der Request 6 ist das erste Paket von Outlook mit folgenden Details:

Eine komplett anonyme Anfrage nach dem "Protocol=autodisoverv1" mit der Antwort zur Autodiscover-URL. Der Zugriff 7 ist dann ein anonymer Zugriff, über den Outlook erst erfährt, welche Anmeldemöglichkeiten es gibt um dann im Request 8 sich mit eine Anmeldung (Bearer) die eigentliche XML-Antwort abzuholen.

Ungültige Adressen gegen Office 365

Bei der URL gibt es ja noch die Domäne und die Gültigkeit der Adressen als Parameter.

Testfall Antwort Beschreibung

Office 365 Mailbox

 

{
   "Protocol":"ActiveSync",
   "Url":"https://outlook.office365.com/api"
}

Office 365 Liefert die passende URL aus

Ungültige Adresse in meinem Tenant

Redirect auf OnPremise Umgebung

https://autodiscover.uclabor.de/autodiscover/autodiscover.json
   ?Email=noUser%40uclabor.de
   &Protocol=Rest&RedirectCount=1

Exchange Online schickt mich der Office 365 Service per Redirect auf die angebliche "On-Premises" Umgebung.

Mailadresse einer nicht registrierten Domäne

Redirect auf OnPremise Umgebung

https://autodiscover.uclabor.de/autodiscover/autodiscover.json
   ?Email=noUser%40uclabor.de
   &Protocol=Rest&RedirectCount=1

Exchange Online schickt mich der Office 365 Service per Redirect auf die angebliche "On-Premises" Umgebung.

Es ist dabei irrelevant, ob es tatsächlich einen Hybrid-Mode gibt oder nicht und es ist auch nicht wichtig, ob die Domäne in Office 365 registriert ist.

RedirectCount

Über den Parameter "RedirectCount" wird Exchange vermutlich eine Schleifenerkennung machen. Wenn nämlich der Autodiscover-DNS-Eintrag wieder auf den gleichen Server verweist, dann sollte die Umleitung unterbrochen werden. Zum Test sende ich den Request mit dem Redirectcount=1 an Office 365.

https://outlook.office365.com/autodiscover/autodiscover.json/v1.0/noUser%40uclabor.de?Protocol=Rest&RedirectCount=1

Die Antwort ist dann aber wieder ein Redirect auf die vermutete Zielseite mit einem RedirectCount=2

https://autodiscover.uclabor.de/autodiscover/autodiscover.json?Email=noUser%40uclabor.de&Protocol=Rest&RedirectCount=2

Erst mit einem Redirect=10 kommt dann die Meldung war dann ein "UserNotFound", selbst wenn der User "gültig" ist.

{
   "ErrorCode":"UserNotFound",
   "ErrorMessage":"The given User was not found"
}

Achtung:
Ich habe bislang noch nie gesehen, dass ein AutoDV2-Client bei auf HTTP wechselt, wenn er unter https:/autodiscover.<maildomain> keine Antwort bekommt. Das Verfahren wird gerne von Firmen mit vielen Domains als auch Office 365 selbst genutzt.

Test gegen On-Premises

Was die Cloud kann, könnte ein Exchange 2016 On-Premises ja auch. Zumal die Cloud den Zugriff für einen nicht existenten Benutzer auf autodiscover.<maildomain> umleitet. Bei einem Hybrid-Mode verweist dieser Eintrag ja immer auf die lokale Umgebung. Also habe ich eine URL erstellt, mit der ich einen lokalen User abfrage.

Testfall Antwort Beschreibung

Lokaler User

 

{
   "Protocol":"Rest",
   "Url":"https://owa.msxfaq.de/api"
}

Mein lokaler Server liefert genau wie die Cloud die Daten korrekt aus

falsche Domain

 

{
   "Protocol":"Rest",
   "Url":"https://owa.msxfaq.de/api"
}

Der Fall ist etwas suspekt. Ich kann den Exchange Server mit einem User aus einer anderen Domäne abfragen und er liefert mit dennoch eine URL zurück. Schöner wäre eine Fehlermeldung, dass die Domäne hier nicht bedient wird. Allerdings könnte ein Angreifer dann natürlich auch per Brute Force prüfen, welche Domäne eine Topologie bedient.

ungültiger User

 

{
   "Protocol":"Rest",
   "Url":"https://owa.msxfaq.de/api"
}

Auch die Anfrage nach einer nicht vorhandenen Mailadresse mit einer Accepted Domain liefert ein OK mit einer URL, obwohl man sich damit nicht anmelden kann. Ein Rückschluss auf "gültige Adressen" ist nicht möglich.

Remote Mailbox

Redirect auf Office 365 mit der Target-Adresse

Wenn ich aber die On-Premises-Plattform nach einer Mailadresse frage, deren Postfach in Office 365 gehostet ist, dann bekomme ich einen Redirect in die Cloud.

Protokolle

ActiveSync und REST waren ja nun mal einfach zu erraten, aber was geht noch? Also habe ich andere Strings angehängt. Die String sind nicht case-sensibel. Folgende URL wurde mit den Parametern erweitert:

https://outlook.office365.com/autodiscover/autodiscover.json/v1.0/User1%40uclabor.de
Parameter Ergebnis Office365
Ergebnis On Premise (wenn abweichend)		 Beschreibung

?Protocol=ActiveSync

 

{
   "Protocol":"ActiveSync",
   "Url":"https://outlook.office365.com/Microsoft-Server-ActiveSync"
}

Das ist die klassische ActiveSync URL

kein Protokoll

 

{
   "ErrorCode":"MandatoryParameterMissing",
   "ErrorMessage":"A valid value must be provided 
       for the query parameter \u0027Protocol\u0027"
}

Die Fehlermeldung, dass der Parameter "Protocol" verpflichtend ist.

?Protocol=gibtesnicht

 

{
   "ErrorCode":"ProtocolNotSupported",
   "ErrorMessage":"The given protocol value \u0027imap\u0027 
        is not supported. Supported values are \u0027
        Rest,ActiveSync,Ews,Substrate,Substratesearchservice,
        AutodiscoverV1,substratesearchservice,
        substratenotificationservice,
        outlookmeetingscheduler\u0027"
}
{
   "Protocol":"gibtesnicht",
   "Url":"https://owa.netatwork.de/api"
}

Danke für den Fehler mit der Liste der erlaubten Protokolle. Da habe ich ja noch was vor mir.

On-Premises kommt aber immer eine Antwort

?Protocol=AutodiscoverV1

 

{
   "Protocol":"AutodiscoverV1",
   "Url":"https://outlook.office365.com/autodiscover/autodiscover.xml"
}

Liefert die klassische Autodiscover URL

?Protocol=REST

 

{
   "Protocol":"Rest",
   "Url":"https://outlook.office.com/api"
}

Interessant ist, dass auch ein Exchange 2016 On-Premises diese URL ausliefert

?Protocol=Ews

 

{
   "Protocol":"ews",
   "Url":"https://outlook.office365.com/EWS/Exchange.asmx"
}

Die bekannte gewohnte URL

?Protocol=outlookmeetingscheduler

 

{
   "Protocol":"outlookmeetingscheduler",
   "Url":"https://outlook.office.com/scheduling/api"
}

Das ist anscheinend eine neue API. die aber auch "On-Premises" angeboten wird.

?Protocol=Substrate

 

{
   "Protocol":"Substrate",
   "Url":"https://outlook.office.com"
}

Selbst ein lokaler Exchange Server kennt dieses Protokoll.

?Protocol=Substratesearchservice

 

{
   "Protocol":"Substratesearchservice",
   "Url":"https://outlook.office365.com/autosuggest"
}
{
   "ErrorCode":"NotAvailable",
   "ErrorMessage":"Substratesearchservice is not 
      available on On-Prem deployments."
}

Zu dem Therma "Substrate" gibt es nur wenig Quellen. In einem Ignite-Vortrag bezieht sich der Begriff auf Monitoring der Exchange Online Plattform.

Als Substrate

?Protocol=substratenotificationservice

 

{
   "Protocol":"substratenotificationservice",
    "Url":"https://substrate.office.com/insights"
}
{
   "Protocol":"substratenotificationservice",
    "Url":"https://owa.uclabor.de/api"
}

 

Ich kann über den Weg allerdings nicht ermitteln, ob die Mailadresse "korrekt" ist.

IMAP und Co?

Ich habe gehofft, irgendwo bei Microsoft einmal eine Dokumentation zu diesem neuen Autodiscover-Prozess zu finden. Ich wurde aber bislang nicht fündig. Wie sie oben auch entnehmen können, Reagieren Exchange Online und Exchange On-Premises unterschiedlich.

  • Exchange Online
    Die Anfrage nach einem "?Protocol=imap" oder ähnlich wird mit einer Fehlermeldung quittiert, in der die Liste der gültigen Protokolle geliefert wird. IMAP oder etwas anderes "ähnliches" ist nicht dabei
{
   "ErrorCode":"ProtocolNotSupported",
   "ErrorMessage":"The given protocol value \u0027imap\u0027 
        is not supported. Supported values are \u0027
        Rest,ActiveSync,Ews,Substrate,Substratesearchservice,
        AutodiscoverV1,substratesearchservice,
        substratenotificationservice,
        outlookmeetingscheduler\u0027"
}
  • Exchange On-Premises
    Sie können hier jedes Protokoll abfragen und bekommen immer eine positive Antwort, die aber immer den gleichen Inhalt hat
{
   "Protocol":"gibtesnicht",
   "Url":"https://owa.netatwork.de/api"
}

Insofern könnten Sie glauben, dass Exchange On-Premises ihnen einen IMAP-Antwort liefert. Dem ist aber nicht so.

Auf der Seite "email-autodiscover/settings.json.sample" (https://GitHub.com/gronke/email-autodiscover/blob/master/settings.json.sample) gibt es sogar eine JSON-Struktur, die nach einer IMAP-Konfiguration aussieht.

Meine Einschätzung ist aber, dass "Autodiscover V2" aktuell keine IMAP4/POP3 Unterstützung hat. Die Clients, die heute schon Autodiscover V2 nutzen, suchen damit sowieso nach einem Exchange Server. Für IMAP und POP haben die meisten Clients schon ihre eigene Erkennungslogik, indem Sie einfach ein paar Hostnamen und Ports ausprobieren.

Abfrage per Skript

Meine Testserie habe ich einfach per Browser gemacht. Sie können die Abfragen natürlich auch per Powershell oder wegn mir auch CURL und WGET durchführen.

Invoke-RestMethod `
   -Uri ‘https://autodiscover.netatwork.de/autodiscover/autodiscover.json?Email=onpremUser@netatwork.de&Protocol=EWS’
 
Protocol Url
-------- ---
EWS      https://owa.netatwork.de/EWS/Exchange.asmx
CURL -lv "https://outlook.office365.com/autodiscover/autodiscover.json/v1.0/[EMAIL Address]?Protocol=ActiveSync" -A "Apple-iPhone9C1/1501.530400009"

Damit eignet sich diese Abfrage natürlich bedingt auch für die Ermittlung einer unbekannten Umgebung. Wenn ich eine richtige Mailadresse gefunden habe, die auch in Office 365 gehostet wird, dann bekomme ich die korrekte Antwort. In allen anderen Fällen bekomme ich einen Redirect auf einen Hostname, der On-Premises stehen kann oder muss. Ich habe aber damit nicht viel mehr gewonnen, als ich heute schon über eine Domäne z.B. per DNS ermitteln kann.

Weitere Links