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.

• Resolve-DnsName
  https://technet.microsoft.com/en-us/library/jj590781(v=wps.630).aspx

Resolve-DnsName -Type TXT uclabor.de | fl

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

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

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

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

Resolve-DnsName -Type TXT uclabor.de | fl

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

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

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

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

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

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

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.

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

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:

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:

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

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.

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