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.
- External Domain Name System
records für Office 365
https://support.office.com/en-us/article/External-Domain-Name-System-records-for-Office-365-c0531a6f-9e25-4f2d-ad0e-a70bfef09ac0 - What’s the purpose of the
additional Office 365 CNAME
record
https://support.office.com/en-us/article/Whats-the-purpose-of-the-additional-Office-365-CNAME-record-19b67e2b-1b28-4432-8cca-394803fbdc87
http://go.microsoft.com/fwlink/p/?LinkId=322005
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. |
EstsProperties. |
Credentials. |
Credentials. |
Credentials. |
---|---|---|---|---|---|---|
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 |
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.
PTA URL https://autologon.microsoftazuread-sso.com
Während der Analysen zu HTTP Authentication habe ich noch einen Weg ermitteln könne, um den Status einer Domain und deren Anmeldefunktion genauer zu ermitteln. Wer für eine Domain die Funktion "Password HashSync" in Verbindung mit SingleSignOn nutzt, kann dies über folgende URL ermitteln:
https://autologon.microsoftazuread-sso.com/<upn-domain>/winauth/sso
In der URL muss die UPN-Domain eingetragen und dann einfach ein HTTP-GET ausgeführt werden. folgende drei Statuscode der HTTP-Antwort haben ich bislang ermitteln können:
- Gültige Domain für SSO und PTA .> 401
Authentication Reqired
Dabei wird als "Autorization: Negotiate" geliefert. - Nicht vorhandene Domain -> 4000 Bad Request
- Domain mit ADFS -> "204 No Content"
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.
- Autodiscover V2
- MFG Microsoft Federation Gateway
-
Create a TXT Record für Federation
https://technet.microsoft.com/en-us/library/ee423548(v=exchg.141).aspx - Get-FederationInformation
https://docs.microsoft.com/en-us/powershell/module/exchange/federation-and-hybrid/get-federationinformation?view=exchange-ps
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 |
NA |
O365Public |
EOP |
Office 365 |
Office 365 |
msxfaq.com |
msxfaq.onmicrosoft.com |
EU |
O365Public |
EOP |
Office 365 |
Office 365 |
bmi.bund.de |
bmibundde.onmicrosoft.com |
EU |
O365Public |
OnPrem |
- |
Office365 |
stadt-koeln.de |
StadtKoeln.onmicrosoft.com |
EU |
O365Public |
OnPrem |
- |
Office365 |
basf.com |
basf.onmicrosoft.com |
EU |
O365Public |
EOP |
- |
OnpremADFS |
rwe.com |
rwe.mail.onmicrosoft.com |
EU |
O365Public |
EOP |
IP-Adresse |
OnpremADFS |
microsoft.com |
corp.webtv.net |
WW |
O365Public |
EOP |
OnPrem |
OnpremADFS |
ibm.com |
ibm.onmicrosoft.com |
NA |
O365Public |
3rd Party |
- |
OnpremADFS |
suse.com |
MicroFocusInternational.onmicrosoft.com |
NA |
O365Public |
Novell |
IP-Adresse |
OnpremADFS |
cdu.de / cdu.com |
Kein Eintrag |
- |
- |
- |
- |
- |
spd.de |
spdde.onmicrosoft.com |
EU |
O365Public |
Eigen |
- |
AzureAD |
gruene.de |
gruenede.onmicrosoft.com |
EU |
O365Public |
Eigen |
- |
AzureAD |
fdp.de |
Nein |
Nein |
Nein |
comdok.de |
Nein |
Nein |
afd.de |
afdde.onmicrosoft.com |
UE |
O365Public |
EXpurgate |
OnPrem ? sfbweb.afd.de |
AzureAD |
Parliament.uk |
hopuk.onmicrosoft.com |
EU |
O365Public |
3rd Party |
IP-Adresse |
OnPrem ADFS |
mod.uk |
modgovuk.onmicrosoft.com |
EU |
O365Public |
OnPrem |
- |
Office 365 |
miele.com.br |
miele.onmicrosoft.com |
SA |
O365Public |
EOP |
- |
AzureAD Password |
|
gws.onmicrosoft.com |
AS |
O365Public |
Kein |
Kine |
AzureAD Kennwort |
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.
- Host 10 ASP.NET websites für free with Azure
http://azure.microsoft.com/en-us/develop/net/aspnet/ - Developing Windows Azure and
Web Services Jump Start
http://www.microsoftvirtualacademy.com/training-courses/developing-windows-azure-and-web-services-jump-start - How to Create and Deploy a
Cloud Service
https://azure.microsoft.com/en-us/documentation/articles/cloud-services-how-to-create-deploy/ - Create a REST service using
ASP.NET Web API and SQL Database
in Azure App Service
https://azure.microsoft.com/en-us/documentation/articles/web-sites-dotnet-rest-service-aspnet-api-sql-database/
Weitere Links
- Get-Federationdomain
- MFG Microsoft Federation Gateway
- Autodiscover V2
- PS als DNSClient
- Resolve-DnsName
https://technet.microsoft.com/en-us/library/jj590781(v=wps.630).aspx - DNS-Class
https://msdn.microsoft.com/de-de/library/system.net.dns(v=vs.110).aspx - Hey, Scripting Guy! How Do I
Query and Retrieve DNS
Information?
http://blogs.technet.com/b/heyscriptingguy/archive/2009/02/26/how-do-i-query-and-retrieve-dns-information.aspx