Wer nutzt Office 365 und wie?

Gerade in der Anfangszeit wurde gefragt: "Wer nutzt denn schon Office 365?". Das ist relativ einfach zu beantworten, wenn es um Firmen geht, die das "allgemeine" Office 365 Angebot nutzen. Mittlerweile habe ich hier eine ganze Menge von URLs und Checks zusammen getragen, mit denen Sie zu einer DNS-Domain, die vielleicht auch als UPN verwendet wird, etwas in Erfahrung bringen können. Über den Umfang einer Office 365 Nutzung können Sie über unterschiedliche Wege mehr in Erfahrung bringen.

Vorbemerkung zum Datenschutz

Ich habe einige Zeit überlegt, ob ich diese Details zur Ermittlung von Informationen über eine Office 365 Domain  öffentlich machen soll. Da es sich aber um öffentlich zugängliche Daten handelt, die nicht durch einen "Einbruch" ermittelt werden, ist mich wichtiger, dass möglichst viele Menschen darum wissen.
Keine der Informationen erlaubt einen Rückschluss auf Personen sondern nur auf Domains, die so auch bei den NICs der Welt und per DNS-Abfragen öffentlich einsehbar sind, so dass es keine "personenbezogenen" Daten nach DSGVO sein dürften.

Was ich hier beschreibt ist letztlich das Ergebnis von Abfragen, die Office 365 Clients tagtäglich millionenfach anonym ausführen. Ich habe den Protokollen einfach etwas genauer auf die Finger geschaut. Jeder, der mit Fiddler, Charles und Co umgehen kann, wird in wenigen Minuten die gleichen Informationen erlangen und mit einem PowerShell-Script auch automatisiert abfragen können. Es ist also weder "geheim" noch "gehackt".

Sie können es einfach testen: Starten Sie einen Browser ihrer wahl und gehen Sie auf https://portal.office365.com. Geben Sie hier nun icht ihren Benutzernamen ein sondern eine beliebige "interessante" Domäne und einen ungültigen Benutzer wie z.B. invalidUser@microsoft.com, invalidUser@basf.com, invalidUser@parliament.uk, uclabor.de und klicken Sie auf "Weiter". Anhand dem nächsten Dialog können Sie z.B. erkennen, ob diese Domäne überhaupt registriert ist und wenn ja, welches Anmeldeverfahren (Cloudkennworte, ADFS-OnPrem, AzureADFS-Premium) genutzt wird. Diese "Analyse" kann Office 365 gar nicht verhindern. Ein möglicher Einbrecher kann sich ja auch ganz gefahrlosmal ihr Schloss ansehen. Ich war nur etwas überrascht, dass die APIs mehr Daten zurückliefern, als für die eigentliche Funktion erforderlich sind. Wenn ich mich mit einer Domäne anmelde, dann würde ein Check auf diese Domäne reichen. Die API müsste dann nicht die komplette Domainliste mitliefern.

Viel Spass beim näheren Blick auf Office 365 Anmeldedienste, DNS-Einträge und er möglichen Rückschlüsse.

DNS Einträge

Wer einen Office 365 Tenant beantragt und eine eigene "Domain" addiert, muss den rechtmäßigen Besitz nachweisen. Um dann auch Dienste unter der Domain zu nutzen, sind weitere Einträge erforderlich. Das Office 365 Verwaltungsportal zeigt die erforderlichen Einträge schön grafisch an.

Es ist nicht zwingend erforderlich, dass eine Firma auch wirklich alle Einträge vornimmt. Wer von Office 365 z.B. kein Skype for Business nutzt, kann sich die Einträge sparen. Der MX-Record verweist nur dann auf Office 365,. wenn man auch den Spamfilter von Office 365 nutzt und nicht eine eigene Lösung bevorzugt. Bei Exchange im Hybrid-Mode verweist Autodiscover in der Regel auch auf die "On Premises" Umgebung. Der TXT-Eintrag mit dem "MS=*" Inhalt muss eigentlich nur bei der Verifizierung vorhanden sind und könnte dann wieder entfernt werden. Die meisten Kunden lassen ihn aber dennoch drin.

Die gleichen Abfragen können Sie natürlich auch per NSLOOKUP oder PowerShell machen. Diese Daten lassen sich auch als relativ guter Indikator für Office 365 Kunden nutzen. Eine Firma kann eigentlich nicht verbergen, in welchem Maß sie Office 365 schon nutzt. Im Office 36 Portal bekommen Sie ja angezeigt, welche DNS-Einträge ein Administrator machen sollte:

Hinweis
Einige Domains haben auch eine "Wildcard"-Funktion aktiv, d.h. sie können jeden Namen mit *.<domain> abfragen und bekommen immer eine IP-Adresse als Antwort. So kann eine "lyncdiscover.firma.de"-Abfrage natürlich nur bedingt zuverlässig angesehen werden. Sicherheit bringt hier nur die aktive Abfrage der Ressource und qualitative Bewertung der Rückantwort.

Aber das sind nicht alle Einträge. Es gibt auch Einträge, die Microsoft unter der "onmicrosoft.com"-Domäne pflegt und auf den Tenant bezogen sind. Wenn Sie den Tenant-Namen "erraten", dann können Sie auf Verdacht auch das prüfen.

Bereich Abfrage mit NSLOOKUP und Ergebnis Beschreibung

Domain Proof

Resolve-DnsName -Type TXT uclabor.de | fl

Name    : uclabor.de
Type    : TXT
TTL     : 3600
Strings : {MS=ms43941090}

Firmen müssen den "Besitz" der Domäne gegenüber Microsoft belegen. Das geht über einen TXT-Record im DNS oder einen MX-Record auf einen nicht erreichbaren Server. Die meisten Firmen nutzen den TXT-Eintrag und belassen diesen auch im öffentlichen DNS.

Das Vorhandensein eines "ms=xxxx"-Eintrags zeigt, dass die Firma vermutlich ihre Domäne in Office 365 registriert hat, sagt aber noch nichts über die genutzten Dienste aus

MSOID

PS C:\> Resolve-DnsName -Type TX msoid.uclabor.de | fl

Name     : msoid.uclabor.de
Type     : CNAME
TTL      : 300
Section  : Answer
NameHost : clientconfig.microsoftonline-p.net

Name     : clientconfig.microsoftonline-p.net
Type     : CNAME
TTL      : 300
Section  : Answer
NameHost : clientconfig.microsoftonline-p.net.nsatc.net

Name     : clientconfig.microsoftonline-p.net.nsatc.net
Type     : CNAME
TTL      : 300
Section  : Answer
NameHost : aadg.windows.net.nsatc.net

Dieser Eintrag nutzen die Clients um beim Zugriff die "richtige Identitätsplattform" zu nutzen. Microsoft stellt weltweit mehrere Zugangspunkte unter dem gleichen Namen zur Anmeldung bereit und mit diesem Eintrag können Sie dafür sorgen, dass die Clients nicht den "Default Authentication Server" in den USA nutzen, sondern den aus ihrer Sicht besseren Dienst. Wer also überwiegend die Anwender in Europa hat, sollte hier die Server in Niederlande oder Irland addieren.

Dieser DNS-Eintrag ist natürlich auch ein guter Indikator für eine Office365 Installation samt Hinweis auf die Region. Allerdings scheinen nur wenige Kunden bislang diesen Eintrag zu setzen-

Mailrouting eingehend

PS C:\> Resolve-DnsName -Type MX uclabor.de | fl

Name         : uclabor.de
Type         : MX
TTL          : 3588
NameExchange : uclabor-de.mail.protection.outlook.com
Preference   : 0

Der MX-Record ist ein guter Indikator um zu erkennen, ob die Domäne schon Office 365 als Spamfilter nutzt. Wenn die Zieladressen auf etwas mit "mail.protectoin.outlook.com" verweisen, dann werden alle Mails schon "via Office 365" empfangen. Ein Rückschluss, ob die Postfächer schon auf Office 365 sind, ist damit aber noch nicht sicher möglich.

Hybrid Mail Domain

PS C:\> (Resolve-DnsName -Type MX carius.mail.onmicrosoft.com)[0] | fl

Name         : carius.mail.onmicrosoft.com
Type         : MX
TTL          : 10
NameExchange : carius-mail-onmicrosoft-com.mail.protection.outlook.com
Preference   : 10

Wer den Exchange Hybrid Assistent On-Prem ausführt, addierd lokal diese Adressen und über den DirSync werden diese Adressen auch in der Cloud angelegt. Microsoft veröffentlicht aber schon vorab dazu die passenden MX-Records. Dies ist also kein sicherer Indikator, dass es einen Exchange Hybrid Mode gibt

Mailrouting ausgehend

Resolve-DnsName -Type TXT uclabor.de | fl

Name    : uclabor.de
Type    : TXT
TTL     : 3600
Strings : { v=spf1 include:spf.protection.outlook.com -all}

Auch ausgehend kann man über den von Microsoft empfohlenen SPF-Eintrag ermitteln, wie die Firma hinter der Domäne ihre Mails versendet. Ein Rückschluss, ob die Postfächer schon auf Office 365 sind, ist damit aber noch nicht sicher möglich.

Autodiscover

Resolve-DnsName -Type TXT autodiscover.uclabor.de | fl

Name     : autodiscover.uclabor.de
Type     : CNAME
TTL      : 6
Section  : Answer
NameHost : autodiscover.outlook.com

Name     : autodiscover.outlook.com
Type     : CNAME
TTL      : 6
Section  : Answer
NameHost : autod.ha.office365.com

Name     : autod.ha.office365.com
Type     : CNAME
TTL      : 6
Section  : Answer
NameHost : autod.ms-acdc.office.com

Verweist der Autodiscover-Eintrag für Exchange aber schon auf die Cloud, dann können Sie sehr sicher sein, dass die Firma "komplett" in Office 365 gehostet ist, denn Autodiscover muss so lange auf die On-Prem-Server verweisen, solange Sie auch nur ein Postfach On-Premises haben. Aber man kann durchaus Hybrid mit lokalen Postfächern nutzen und Autodiscover in die Cloud verweisen lassen. Allerdings können die On-Prem User natürlich nicht aus dem Internet ihr Postfach per Autodiscover erreichen.

Skype für Business Online Client

PS C:\> Resolve-DnsName -Type TXT lyncdiscover.uclabor.de | fl

Name     : lyncdiscover.uclabor.de
Type     : CNAME
TTL      : 900
Section  : Answer
NameHost : webdir.online.lync.com
PS C:\> Resolve-DnsName -Type srv _sip._tls.uclabor.de | fl

Name       : _sip._tls.uclabor.de
Type       : SRV
TTL        : 3600
NameTarget : sipdir.online.lync.com
Priority   : 100
Weight     : 1
Port       : 443

Wenn eine Firma Lync Online/Skype für Business Online einsetzen, dann wird sie sicher auch die DNS-Einträge für "Lyncdiscover" machen. Verweisen diese auf Server von Office 365, dann können Sie sicher sein, dass alle Anwender mit Skype für Business in der Office 365 Cloud arbeiten.

Alternativ kann immer noch eine Abfrage auf die alten SRV-Records erfolgen.

Skype für Business Online Federation

PS C:\> Resolve-DnsName -Type srv _sipfederationtls._tcp.uclabor.de | fl

Name       : _sipfederationtls._tcp.uclabor.de
Type       : SRV
TTL        : 3600
NameTarget : sipfed.online.lync.com
Priority   : 100
Weight     : 1
Port       : 5061

SRV-Records sind auch die Informationsquelle zum Thema "Federation" mit Skype für Business. Ohne diesen Eintrag kann eine Firma natürlich weiterhin Skype für Business mit Partnern nutzen, wenn die Partner die entsprechenden Domänen mit Zielsystemen manuell pflegen.

Das dürfte aus meiner Sicht aber eher die Ausnahme sein, denn die Federation ist ja oft genau das, was Skype für Business interessant macht. Wer E-Mail nutzt, setzt ja auch einen MX-Record.

SharePoint

PS C:\> Resolve-DnsName -Type a fcarius.sharepoint.com | fl

Name     : fcarius.sharepoint.com
Type     : CNAME
TTL      : 30
Section  : Answer
NameHost : prodnet185-282edgea0001.sharepointonline.com.akadns.net

SharePoint kann man ebenfalls in der Regel über DNS-Anfragen oder HTTPS-Zugriffe ermitteln. Man braucht allerdings den Tenant-Name, der nicht zwingend mit der DNS-Domain übereinstimmt. Wenn die Firma aber schon über das Mailrouting den Tenant-Namen verrät, dann können Sie auch den Default-Sharepoint finden. Zugreifen können Sie bei korrekten Berechtigungen natürlich nicht.

Allerdings ist das dann doch eher theoretischer Natur, da Sie über die anderen Abfragen in der Regel ja schon erkennen, dass es ein Office 365 Engagement gibt

InTune

Resolve-DnsName -Type any enterpriseregistration.uclabor.de | fl

Name     : enterpriseregistration.uclabor.de
Type     : CNAME
TTL      : 240
Section  : Answer
NameHost : enterpriseregistration.windows.net
Resolve-DnsName -Type any enterpriseenrollment.uclabor.de | fl

Name     : enterpriseenrollment.uclabor.de
Type     : CNAME
TTL      : 300
Section  : Answer
NameHost : enterpriseenrollment.manage.microsoft.com

Diese DNS-Einträge sind erforderlich, wenn die Endgeräte über Intune und das Mobile Device Management von Office 365 verwaltet werden sollen.

Etwas "stören" ist natürlich, dass immer mehr Dienste den TXT-Records zur Bereitstellung von Informationen erwarten. Solange die TXT-Records noch einen Präfix wie "ms=" oder "spf=" haben, können diese noch einfach zugeordnet werden. Wenn dort aber nur BASE64-codierte Zertifikate oder Hashwerte landen, dann kann eine Auswertung nicht mehr sicher auf die Verwendung schließen.

OpenID-Information

Im Rahmen der Analysen bin ich auf eine höchst interessante URL gestoßén. Microsoft veröffentlicht unter einer URL auch die Anmeldedaten für eine bestimmte Domain. Sie können in jedem Browser ohne Authentifizierung einfach aufrufen.

https://login.microsoftonline.com/{tenant domain name}/.well-known/openid-configuration

Chrome zeugt die JSON-Datei an während der IE/EDGE einen Download startet. Hier am Beispiel von UCLABOR.DE:

Den gleichen Test können Sie natürlich für nicht existierende Domains machen.

Tenant Beispiel

Tenant ist vorhanden

Invoke-RestMethod https://login.microsoftonline.com/uclabor.de/.well-known/openid-configuration `
   | fl tenant_region_scope,cloud_instance_name

tenant_region_scope : NA
cloud_instance_name : microsoftonline.com

Ich bin mal gespannt, welche Informationen hier für andere Tenants zu sehen sind, die in anderen Regionen oder der "deutschen Cloud" liegen.

Nicht genutzte Domain

Invoke-RestMethod https://login.microsoftonline.com/carius.invalid/.well-known/openid-configuration
Invoke-RestMethod : {"error":"invalid_tenant","error_description":"AADSTS90002: Tenant carius.invalid not found. 
   This may happen if there are no active subscriptions for the tenant. 
  Check with your subscription administrator.\r\n
  Trace ID: 47c82edb-98f9-43df-896f-292d900a0000\r\n
  Correlation ID: 221a3f15-294b-404d-9dcf-527d1c713e44\r\n
  Timestamp: 2018-07-06 17:54:31Z",
   "error_codes":[90002],"timestamp":"2018-07-06 17:54:31Z",
  "trace_id":"47c82edb-98f9-43df-896f-292d900a0000",
  "correlation_id":"221a3f15-294b-404d-9dcf-527d1c713e44"} 

Die gleiche API nutzt wohl auch die Seite https://www.whatismytenantid.com. In der Antwort steht nämlich auch die GUID des Tenants zur Domain. Da Sie so aber auch die GUID des Tenant bekommen, könnten Sie auch ermitteln, ob zwei bekannte Domänen zum gleichen Tenant gehören. Ich habe aber noch keinen Weg gefunden, über die TenantID eine Liste der enthaltenen Domänen oder sogar eine Gesamtliste von Office 365 Tenants zu erhalten. Sie müssen also schon die Domäne wissen, nach der sie fragen.

Information aus der Anmeldung

Sie haben sich sicher schon einmal in einem Browser auf https://portal.office365.com oder https://manage.windowsazure.com oder anderen Seiten von Office 365 angemeldet. Haben Sie hier mal mit einem Benutzernamen variiert? ich habe da sehr unterschiedliche Reaktionen beobachtet, die einen direkten Rückschluss auf die Anmeldung erlauben.

Folgende Konstellationen sind möglich:

Konfiguration Ausgabe

Domain ist nicht in Office 365 als UPN genutzt. In dem Fall zeigt die Anmeldemaske einen entsprechenden Hinweise an.

Domain wird zur Anmeldung per Password Hash, Passthrough Authentication  oder AzureAD Password genutzt. Die Anmeldemaske erwartet die Eingabe eines Kennwort, welches AzureAD dann verifiziert.

Domain wird per ADFS zu einem eigenen ADFS-Server umgeleitet.

Domain wird mit AzureAD Premium und ADFS von Office 365 genutzt. Beachten Sie dabei die URL, welche auf login.microsoftonline.com bleibt. Nur das Layout passt sich an.

Sie können allein mit einem Browser diese Anmeldung "simulieren". Natürlich geht das auch per Browser, denn der Zugriff auf die eigentliche Anmeldeseite erfolgt ja über einen "Form Post", den Sie auch per PowerShell ausführen können. Beim ersten Zugriff auf einem Service werden sie ja auf die gemeinsame Anmeldeseite umgeleitet. Der Request sieht in etwas so aus:

https://login.microsoftonline.com/common/oauth2/authorize?
   client_id=xxx
   &response_mode=form_post
   &response_type=code+id_token
   &scope=openid+profile
   &state=OpenIdConnect.AuthenticationPropertiesxx-xxx-xxx
   &nonce=xxx.xxx
   &redirect_uri=https%3a%2f%2fwww.office.com%2f
   &ui_locales=de-DE
   &mkt=de-DE
   &client-request-id=xxx-xxx-xxx-xxx-xxx
   &msafed=0
   &sso_reload=true

Eine klassische OAUTH-Anmeldung, die im Browser dann eine Eingabe von Benutzername und Kennwort erwartet. Wenn Sie dann auf "Weiter" drücken, dann wird es interessant: ich habe mit Fiddler die Anmeldung mitgeschnitten und eine sehr interessante URL gefunden, wenn ich den Benutzernamen eingegeben und OK gedrückt habe:

Die Url "https://login.microsoftonline.com/common/GetCredentialType" habe ich mir in Fiddler dann mal genauer angeschaut

Ich habe dann mit PowerShell und Invoke-Restmethod experimentiert, welche Felder gesendet werden müssen und welche Antwort geliefert wird. Der erste Aufruf lieferte schon Daten:

Invoke-RestMethod `
   -Uri https://login.microsoftonline.com/common/GetCredentialType `
   -method POST `
   -ContentType "application/json; charset=UTF-8" `
   -Body '{"Username":"invalidUser@carius.de"}' Username       : invalidUser@carius.de
Display        : invalidUser@carius.de
IfExistsResult : 0
ThrottleStatus : 1
Credentials    : @{PrefCredential=1; HasPassword=True; RemoteNgcParams=; SasParams=}
EstsProperties : @{DesktopSsoEnabled=True; UserTenantBranding=; DomainType=3}
apiCanary      : AQABAAAAAADX8GCi6Js6SK82TsD2Pb7r90CiZ1qlB4KxeJQfxs61BYvAZFiAjN-ciOtpNF-VpULfZg7-ciN0V_2KdjakbYmQTva43p
                 F3K5BWnd3vTZdqJhHQthHNJWH28dp1ri01Su3PQmpY3m2R6TKKw8RLcLjO7hIpNEm1rFQsPHGs6HJteSqiL__PAP6yArOaAULL-8n6
                 ri4rRO4sK1mESeD4L4tcFEE3X7g0rb7y1SfqIUs-1yAA

Damit habe ich dann natürlich noch mal die Testserie mit den vier Anmeldetypen gemacht:

DomainType

IfExistsResult

EstsProperties.
Domaintype

EstsProperties.
UserTenantBranding

Credentials.
PrefCredential

Credentials.
HasPassword

Credentials.
FederationRedirectUrl

Nicht registrierte Domain

1

1

<leer>

1

True

<nicht vorhanden>

PasswordHashSync Domain

0

3

<leer>

1

True

<nicht vorhanden>

ADFS Domain

0

4

<leer>

4

True

https://adfs.netatwork.de/adfs/ls/?Username=invalidUser%40netatwork.de&wa=wsignin1.0&wtrealm=urn%3afederation%3aMi
crosoftOnline&wctx=}

AzureADFS Domain

0

3

Locale                 : 0
BannerLogo             : https://secure.aadcdn.microsoftonline-p.com/
   <guid>/logintenantbranding/0/bannerlogo?ts=<nummer>
TileLogo               : https://secure.aadcdn.microsoftonline-p.com/
   <guid>/logintenantbranding/0/tilelogo?ts=<nummer>
Illustration           : https://secure.aadcdn.microsoftonline-p.com/
   <guid>/logintenantbranding/0/illustration?ts=<nummer>
BoilerPlateText        : Sie melden sich am Active Directory von FIRMA an.
KeepMeSignedInDisabled : False

1

True

<nicht vorhanden>

Es ist also sehr einfach mit einem einzelnen Aufruf gegen diese URL zu prüfen, ob die Domäne mit Office 365 registriert ist und welches Anmeldeverfahren genutzt wird. Allerdings gibt es durchaus noch Lücken. So ist der "Domaintype =2  aktuell noch nicht aufgetreten.

Ich habe noch keine Quelle gefunden, die alle möglichen Konstellationen beschreibt. Insbesondere andere Cloud-Dienste (DECloud, 123Vianet, UKGOV, USMIL etc. könnten andere Werte liefern. Wenn Sie Domains mit anderen Rückgaben finden, bin ich um einen Hinweis dankbar und erweitere die Tabelle.

Exchange Autodiscover und Federation

Normalweise ist ein Aufruf von "Autodiscover" nicht ohne Anmeldung möglich. Aber auf der Seite Autodiscover V2 habe ich beschrieben dass über diesen REST-Service eine gewisse Information über ein Postfach erhalten werden könnte. Wer einen Exchange Hybrid-Mode etabliert, wird in der Regel auch das eine Free/Busy-Federation eingerichtet. Dazu ist die Konfiguration des MFG Microsoft Federation Gateway erforderlich. Die Einrichtung bedeutet nicht zwingend, dass es einen Exchange Hybrid Mode gibt, denn das Microsoft Federation Gateway kann auch genutzt werden, wenn zwei Exchange Organisationen On-Premises eine Federation miteinander einrichten. Allerdings ist es schon sehr wahrscheinlich für einen Office 365 Hybrid-Mode, wenn die Domain in Office 365 registriert ist. Auf einem Exchange "On-Premises"-Server können Sie dazu ganz einfach ausführen.

[PS] C:\>Get-FederationInformation uclabor.de


RunspaceId            : ceb7207b-c2c2-4458-9ae0-bf65f1171be9
TargetApplicationUri  : outlook.com
DomainNames           : {fcarius.onmicrosoft.com, uclabor.de, fcarius.mail.onmicrosoft.com}
TargetAutodiscoverEpr : https://autodiscover-s.outlook.com/autodiscover/autodiscover.svc/WSSecurity
TokenIssuerUris       : {urn:federation:MicrosoftOnline}
Identity              :
IsValid               : True
ObjectState           : Unchanged

Sie erhalten zu einer Domain sogar die Liste aller Domänen. Insofern ist dies eine sehr gute Quelle für weitere Analysen. Um aber zuerst einmal zu verstehen, was das Commandlet macht, musste ich mit Fiddler erst mal mitschneiden. und dazu den Exchange Server auch erst mal dazu bringen, über den Proxy zu gehen:

Set-ExchangeServer -InternetWebProxy http://localhost:8888
Get-FederationInformation uclabor.de 
Set-ExchangeServer -InternetWebProxy $null

Interessant fand ich schon, dass hier nur Autodiscover-Anfragen genutzt werden.

Nach einigen Versuchen habe ich einen einzelnen HTTP-POST-Request extrahiert, mit dem ich unter Nutzung einer bekannten Domain und einer eingerichteten Federation auch alle anderen Domänen ermitteln kann.

([xml](Invoke-WebRequest `
   -Method post `
   -Uri https://autodiscover-s.outlook.com/autodiscover/autodiscover.svc `
   -ContentType "text/xml; charset=utf-8" `
   -Body '<?xml version="1.0" encoding="utf-8"?>
   <soap:Envelope xmlns:exm="http://schemas.microsoft.com/exchange/services/2006/messages"
                  xmlns:ext="http://schemas.microsoft.com/exchange/services/2006/types"
                  xmlns:a="http://www.w3.org/2005/08/addressing"
                  xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
                  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                  xmlns:xsd="http://www.w3.org/2001/XMLSchema">
   <soap:Header>
      <a:Action soap:mustUnderstand="1">http://schemas.microsoft.com/exchange/2010/Autodiscover/Autodiscover/GetFederationInformation</a:Action>
      <a:To soap:mustUnderstand="1">https://autodiscover-s.outlook.com/autodiscover/autodiscover.svc</a:To>
      <a:ReplyTo>
         <a:Address>http://www.w3.org/2005/08/addressing/anonymous</a:Address>
      </a:ReplyTo>
   </soap:Header>
   <soap:Body>
      <GetFederationInformationRequestMessage xmlns="http://schemas.microsoft.com/exchange/2010/Autodiscover">
         <Request>
            <Domain>uclabor.de</Domain>
         </Request>
      </GetFederationInformationRequestMessage>
   </soap:Body>
</soap:Envelope>')).Envelope.Body.GetFederationInformationResponseMessage.Response.Domains.domain

fcarius.onmicrosoft.com 
uclabor.de 
fcarius.mail.onmicrosoft.com 

Die Abfrage erfolgt komplett anonym und sie können damit auch andere Domänen abfragen. Ich habe mir natürlich überlegt, ob dies schon ein Risiko darstellen kann. Schließlich kann jeder mit dem Wissen um eine Domain durchaus eine vollständige Domänenliste von Office 365 Domains zum Tenant erhalten.

Interessant finde ich, dass ich auch die Domänenliste von Firmen erhalten, die gar keine Exchange Federation über das Microsoft Federation Gateway eingerichtet haben.

Domain-Profilierungsskript Get-O365TenantInfo

Mit all der Vorarbeit gibt es schon einen schönen Blumenstraße von Tests, über die ich eine erste Aussage über die Office 365 Nutzung einer Domain erhalten kann.

In einer ersten Version reicht hier mir eine PowerShell-Lösung mit einfacher Bildschirmausgabe:

Ich kann natürlich per Pipeline auch eine Liste von Domains vorne einkippen und die Ausgabe mit Export-CSV in eine Datei schreiben lassen.

Das Skript ist noch kein öffentlicher Download. Es gibt noch zu viele "Sonderfälle" und Fehlersituationen, die noch nicht abgefangen werden. Ich programmiere hier ja nicht anhand einer bekannten vorgegebenen API sondern versuche Aufrufe nachzustellen, die ich per Tracing und Analyse glaube gefunden zu haben. Zudem prüfe ich Werte die MX, LyncDiscover, AuthEndpoint aktuell nur gegen die angefragte Domäne. Sinnvoll wären natürlich Tests gegen jede gefundene Domäne, da die Ergebnisse je Domains ja abweichend sein könnten.

Exemplarische Informationen

Ich habe einfach mal ein paar " bekannte" Firmen aber auch Behörden abgefragt und interessante Einblicke erhalten, wer denn alles schon Office 365 in welcher Tiefe nutzt.

Getestete Domain DNS-Domains Region Instanz MX Lyncdiscover AuthEndpint

uclabor.de

fcarius.onmicrosoft.com
uclabor.de
fcarius.mail.onmicrosoft.com

NA

O365Public

EOP

Office 365

Office 365

msxfaq.com

msxfaq.onmicrosoft.com
msxfaq.com
msxfaq.mail.onmicrosoft.com

EU

O365Public

EOP

Office 365

Office 365

bmi.bund.de

bmibundde.onmicrosoft.com
bmi.bund.de

EU

O365Public

OnPrem

-

Office365

stadt-koeln.de

StadtKoeln.onmicrosoft.com
stadt-koeln.de

EU

O365Public

OnPrem

-

Office365

basf.com

basf.onmicrosoft.com
basf.com
basfad.basf.net
.. (total 77 Domains)

EU

O365Public

EOP

-

OnpremADFS

rwe.com

rwe.mail.onmicrosoft.com
service.rwe.com
rwenpower.com
npower-renewables.com
.. (total 109 Domains)

EU

O365Public

EOP

IP-Adresse

OnpremADFS

microsoft.com

corp.webtv.net
microsoft.onmicrosoft.com
surface.com
bungie.com
navic.tv
middleeast.corp.microsoft.com
microsoft.com
.. (Total 254 Domains)

WW

O365Public

EOP

OnPrem

OnpremADFS

ibm.com

ibm.onmicrosoft.com
ibm.com
JP.ibm.com
cf.ibm.com
.. (total 266 Domains)

NA

O365Public

3rd Party

-

OnpremADFS

suse.com

MicroFocusInternational.onmicrosoft.com
microfocus.com
suse.com
netiq.com
MicroFocusInternational.mail.onmicrosoft.com
attachmate.com
borland.com
attachmatewrq.com
wrq.com
cobolportal.com
liant.com
novell.com
gwava.com
gwava.eu

NA

O365Public

Novell

IP-Adresse

OnpremADFS

cdu.de / cdu.com

Kein Eintrag

-

-

-

-

-

spd.de

spdde.onmicrosoft.com
spd.de

EU

O365Public

OnPrem

-

Office 365

Parliament.uk

hopuk.onmicrosoft.com
hopuk.mail.onmicrosoft.com
intranet.parliament.uk
parliament.uk
tmg.parliament.uk
email.parliament.uk
mail.tours.parliament.uk
mail.education.parliament.uk

EU

O365Public

3rd Party

IP-Adresse

OnPrem ADFS

mod.uk

modgovuk.onmicrosoft.com
mod.gov.uk
modgovuk.mail.onmicrosoft.com
mod.uk
ovs.mod.gov.uk

EU

O365Public

OnPrem

-

Office 365

Die Liste könnte noch endlos fortgesetzt werden.

Abfrage per Browser?

Interessant wäre natürlich auch eine Version als Webseite, bei der eine interessierte Person nur die UPN-Domain eingibt und ein passender Bericht generiert wird. Azure erlaubt es einem Entwickler bis zu 10 Webseiten kostenfrei zu hosten. Was liegt hier dann näher als diese Auswertungen über einen WebService bereit zu stellen anstatt per NSLOOKUP alle einzelnen Befehle abzusetzen?

Diese "Selbstauskunft" plane ich zu starten, wenn die Ergebnisse des PowerShell-Scripts ausreichend stabil sind. Eine Webseite wäre dann überall zu erreichen und da gibt es schon einige gesteigerte Anforderungen an DoS-Schutz, Throttling u.a.

Weitere Links