Office 365 Trusted URLs

Jeder kennt "outlook.office365com" aber es gibt noch viele andere URLs, die Office 365 verwendet. Einige Funktionen sind aber eingeschränkt, wenn diese Ziele als "Internet" angesehen werden und entsprechend den Regeln des Browsers unterworfen sind. Daher ist es wichtig die relevanten URLs ggfls. in in die "Trusted Zone" oder sogar "Intranet" aufzunehmen.

Worum geht es?

Wer den Internet Explorer schon länger kennt, weiß um die Einstufung von URLs in entsprechende Zonen:

Der Internet Explorer unterscheidet dabei vier grundlegende Zonen und für jede Zone sind bestimmte Dinge erlaubt oder verboten sind. Ich habe hier mal einen kleinen Ausschnitt dokumentiert:

Dieser Abschnitt "Benutzerauthentifizierung" ist aber insbesondere beim der Umsetzung von Seamless Single Sign On wichtig damit Anwender sich ohne weitere Kennwortabfrage zumindest von Intern an der Cloud anmelden. Auch wenn Sie die Anmeldung per ADFS ist diese Einstellung wichtig, wenn der FQDN des ADFS-Servers nicht in ihrer internen Domäne ist. Das ist der Fall, wenn Sie ihre interne AD-Domäne nicht identisch zum DNS-Namen ihrer Firma im Internet betreiben.

Der Browser muss wissen, welchen URLs er vertraut, damit er sich dort "automatisch" anmeldet. Das trifft auch auf Dienste zu, die auf den Controls zu WinHTTP, WinINET und Windows Proxy aufsetzen.

Ist das wirklich wichtig?

Damit stellt sich natürlich die Frage, woher ein Administrator eine gültige Liste der URLs bekommt und welche wie relevant sind. Die überwiegende Anzahl der Clients wird sich um diese Besonderheit kaum Gedanken gemacht haben. Trotzdem können auch diese Anwender natürlich Office 365 nutzen. Wie elegant und umfangreich hängt aber maßgeblich von den Einstellungen im Browser bezüglich der angewendete Zone ab.

  • Skripting deaktiviert
    Wer in einer "sicheren Umgebung" surft, bei dem könnte die "Internet-Zone" stärker beschränkt sein, als dies im Standard der Fall ist, z.B. Skripte sind verboten. Hier ist es dann wichtig, dass die Office 365 URLs zumindest diese Funktion unterstützen indem Sie z.B. "Trusted Sites sind"
  • Automatische Anmeldung deaktiviert
    Wenn der Browser sich nicht per NTLM oder Kerberos am ADFS-Server oder den Office 365 SSO-Diensten anmelden kann, dann muss sich der Anwender immer wieder neu mit der Eingabe des Kennworts anmelden. Single SignOn geht anders.
  • Zone verhindert AutoLogin
    Wenn die Ziele nicht in der richtige Zone sind, dann wird der Anwender immer wieder gefragt, welches Benutzerkonto er verwenden soll.

Solche Einstellungen gelten natürlich auch für Proxy-Server, die gewisse URLs hinsichtlich des Inhalts überprüfen und ggfls. die Inhalte "bereinigen". Also sollten Sie schon zum Wohle der Benutzer sich über eine korrekte, funktionierende aber auch sichere Konfiguration Gedanken machen.

Relevant sind von Natur aus natürlich nur Dienste, die per Browser angesprochen werden. Ein Skype for Business Client oder ein OneDrive-Sync fallen also nicht darunter. Auch Zugänge für Exchange EWS, AADConnect u.a. sind nicht betroffen.

Beispiel Anmeldeseite

Die meisten Anwender hantieren nicht mit mehreren Identitäten sondern haben ihren eigenen UPN. Beim allerersten Anmelden an einem Office 365 Dienst per Browser werden Sie natürlich noch nach dem Anmeldename gefragt. Beim zweiten Aufruf schlägt der Browser aber schon den früher verwendeten Namen vor. er hat sich die Einstellung als Cookie gemerkt aber sendet das Formular nicht alleine ab und sie sehen z.B. folgendes Fenster:

In einer Firma wäre es natürlich wünschenswert auch diese Abfrage zu umgehen. Der Browser könnte einfach direkt sich durch authentifizieren. Wer dann wirklich mal einen "anderen Benutzer" verwenden will, kann immer noch eine "Private Browser"-Session starten.

Diese Funktion lässt sich einfach dadurch erreichen, dass die Seite in die "Trusted Sites" aufgenommen wird.

Quelle der URLs

Leider ist die Dokumentation von Microsoft zu den URLs alles andere als vollständig. Es gibt zwar von Microsoft eine Liste der Office 365 URLS und IP-Adressen, aber diese nicht leider nicht vollständig. Microsoft dokumentiert das sogar:


Quelle: Additional endpoints not included in the Office 365 IP Address and URL Web service
https://docs.microsoft.com/en-us/office365/enterprise/additional-office365-ip-addresses-and-urls

Einige Adressen kann Microsoft tatsächlich nicht benennen, z.B. den Namen ihres ADFS-Servers, wie es auf der gleichen Seite beschrieben ist:

Aber alle die anderen URLs sollte Microsoft schon in einer Konfiguration mit aufführen. In dem gleichen Artikel werden nur vier Bereich für "Trusted Sites" aufgeführt:

Laut diesem Dokument ist es ein Name für Authentication und dann drei Einträge für Teams, SharePoint/OneDrive und Yammer. Allerdings fehlen mir dennoch einige URLs, die allesamt auch mit dem Browser angesprochen werden, z.B. Exchange Web Access, aber auch Flow, Delve, SQL-Server und einige andere.

URL Liste für "Trusted Sites"

Ich habe also URL genommen, die ich so kenne und letztlich aus verschiedenen Quellen zusammen stibitzt habe. Die Liste ist aber sicher nicht vollständig, da Microsoft gerne neue Dienste addiert aber auch alte URL vielleicht auch wieder abschaltet..

Es bietet sich an nur DNS-Namen zu verwenden, IP-Adressen können sich ändern und nur auf DNS-Namen können Sie auch Zertifikate für HTTPS erhalten.

Sie können einige URLs auch weiterhin aus den von Microsoft veröffentlichten Listen beziehen. Hier mal ein einfacher Code um die URLs und den "ServiceAreaDisplayName" als Tabelle auszugeben.

(Invoke-RestMethod `
   -uri https://endpoints.office.com/endpoints/Worldwide?ClientRequestId=b10c5ed1-bad1-445f-b386-b919946339a7) `
| select serviceAreaDisplayName,urls `
| %{`
   foreach ($url in $_.urls){ `
      [pscustomobject][ordered]@{Service = $_.serviceAreaDisplayName;URL=$url}`
   }`
}

Allerdings finde ich dort auch "facebook.com", "dropbox.com" und andere URLs, die ich eher nicht als "Trusted Site" addieren möchte.

Eine 100% komplette Liste habe ich leider noch nicht gefunden aber mit den URLs hier komme ich eigentlich gut aus

Funktion und Quelle URLs Zone

Azure Seamless SignOn

aadg.windows.net.nsatc.net
autologon.microsoftazuread-sso.com

Intranet

Authentication and identity FQDNs aus

https://docs.microsoft.com/en-us/office365/enterprise/additional-office365-ip-addresses-and-urls

secure.aadcdn.microsoftonline-p.com

Intranet

Office 365 Login Page

https://login.microsoftonline.com

 

Teams URL

https://*.lync.com
https://*.teams.microsoft.com
https://*.broadcast.skype.com
https://broadcast.skype.com
https://quicktips.skypeforbusiness.com
https://*.teams.skype.com
https://*.teams.microsoft.com
https://*.sfbassets.com
https://*.skypeforbusiness.com

Trusted Site

SharePoint/OneDrive

Hier sind die URLs für "meinen Tenant" wichtig. Aber bitte nicht alle URLs freigeben und damit beim Gastzugriff auf andere Tenants die Türen zu weit öffnen.

https://<tenantname>.sharepoint.com
https://<tenantname>-my.sharepoint.com
https://<tenantname>-files.sharepoint.com
https://<tenantname>-myfiles.sharepoint.com

Trusted Site

Yammer

https://*.yammerusercontent.com
https://*.yammer.com
https://*.assets-yammer.com

Trusted Site

Exchange

https://outlook.office.com
https://outlook.office365.com
https://*.outlook.office.com"
https://r1.res.office365.com
https://r3.res.office365.com
https://r4.res.office365.com

Trusted Site

Azure

Wenn Sie selbst Webseiten in Azure hosten und deren FQDN nicht per Default zu "Intranet" passenden

<ihre namen>
Bitte keine IP-Adressen

Trusted Site

Liste kann fortgesetzt werden

 

 

Allerdings gibt es noch jede Menge andere URLs, von denen ich noch nicht sicher weiß, ob sie "besondere" Berechtigungen benötigen. Einige sind doch sehr umfangreich und auch in anderen Blogs tauchen URLs sowohl unter "Trusted Sites" als auch "Intranet" auf.

Weitere URLs