Infrastrukturüberlegungen

Netzwerk

Proxys vermeiden

Die anfängliche Bereitstellung benötigt direkten Internetzugang. Ideal wäre kein Proxy, aber ein transparenter Proxy sollte (wenn er wirklich transparent ist) gut funktionieren. Falls ein Proxy unvermeidbar ist, müssen mindestens die folgenden Dienste/Adressen direkt erreichbar sein:

Für eine Liste der entsprechenden IP-Bereiche klicken Sie auf den folgenden Link:

Azure-IP-Bereiche und Dienst-Tags – Public Cloud

Diese Datei enthält die Compute-IP-Adressbereiche (einschließlich SQL-Bereichen), die von den Microsoft Azure-Datencentern verwendet werden. Jede Woche am Mittwoch (Pacific Time) wird eine neue XML-Datei mit den neu geplanten IP-Adressbereichen hochgeladen. Neue IP-Adressbereiche werden am folgenden Montag (Pacific Time) wirksam. Laden Sie die neue XML-Datei herunter und führen Sie die notwendigen Änderungen an Ihrem Standort vor Montag durch.

Office 365-URLs und IP-Adressbereiche

Dieser Artikel verlinkt eine Datei, die die Compute-IP-Adressbereiche enthält, die Sie in Ihre ausgehenden Zulassungslisten aufnehmen sollten, damit Ihre Computer Office 365 erfolgreich nutzen können.

Die Filterung allein nach IP-Adressen ist keine vollständige Lösung aufgrund von Abhängigkeiten von internetbasierten Diensten wie Domain Name Services (DNS), Content Delivery Networks (CDNs), Zertifikats-Sperrlisten und anderen Drittanbieter- oder dynamischen Diensten. Diese Abhängigkeiten schließen Abhängigkeiten von anderen Microsoft-Diensten wie dem Azure Content Delivery Network ein und können zu Netzwerkpfaden oder Firewall-Protokollen führen, die Verbindungen zu IP-Adressen von Drittanbietern oder Microsoft anzeigen, die jedoch nicht auf dieser Seite aufgeführt sind. Diese nicht aufgeführten IP-Adressen, sei es von Drittanbieter- oder Microsoft-eigenen CDN- und DNS-Diensten, werden dynamisch zugewiesen und können jederzeit ändern.

VLANs / WLAN- und Port-Isolation vermeiden

Für BranchCache Damit es effektiv ist, müssen die Clients direkt miteinander kommunizieren können und sollten daher nicht durch verschiedene VLANs, WLAN-Isolation oder Port-Isolation getrennt sein. Für Massenrollouts BranchCache-Server mit vorbefüllten Caches werden empfohlen. BranchCache ist auf ein einzelnes Subnetz beschränkt. Hat ein Standort mehrere Subnetze, müssen die BranchCache-Server im selben Subnetz wie die Clients platziert werden, um wirksam zu sein.

RealmJoin-Verbindungsendpunkte

RealmJoin verbindet sich mit den folgenden Hosts (über HTTPS), die in Ihren Firewall-Einstellungen berücksichtigt werden sollten:

• cdn.realmjoin.com

• x1.c.lencr.org

• client-api.realmjoin.com NEU!

• client-api-staging.realmjoin.com NEU!

• realmjoin-backend.azurewebsites.net

• realmjoin-backend-staging.azurewebsites.net

• packages.gkdatacenter.net

• nuget.realmjoin.com NEU!

• enterpriseregistration.windows.net

• gkrealmjoin.s3.amazonaws.com

• login.microsoftonline.com

• graph.microsoft.com

• realmjoinstaticcdn.azureedge.net (Benachrichtigungsdienst)

Komponenten

BranchCache

Ein häufig auftretendes Problem beim Bereitstellen von Softwarepaketen an eine große Anzahl von Geräten in einem WAN ist die Entstehung eines Engpasses und enormer Netzwerklasten beim Herunterladen von Software von einem Server zu den Geräten. Eine Lösung für dieses Problem ist die BranchCache Technologie. Es gibt zwei BranchCache-Modi, gehostet als auch für verteilt Cache. Im Modus des gehosteten Caches wird der Inhalt auf einem oder mehreren lokalen gehosteten Cache-Servernzwischengespeichert, wodurch die Netzwerklast steigt, da ein Download großer Binärdateien von einem Internetserver nicht notwendig ist. RealmJoin verwendet BranchCache im Modus des verteilten Caches:

Ein häufig auftretendes Problem beim Bereitstellen von Softwarepaketen an viele Geräte in einem WAN ist die Entstehung eines Engpasses und enormer Netzwerklasten beim Herunterladen von Software von einem Server zu den Geräten. Eine Lösung für dieses Problem ist die BranchCache Technologie.

Wenn ein Client-Gerät Softwarepakete zum ersten Mal herunterlädt, werden die Dateien in Chunks unterteilt, die deutlich kleiner sind als der ursprüngliche Inhalt, und auf dem Gerät zwischengespeichert. Wird dasselbe Paket später von einem anderen Client-Gerät im selben Netzwerk angefordert, lädt es Inhaltsinformationen statt des vollständigen Inhalts vom Server herunter. Die Inhaltsinformationen werden verwendet, um den gewünschten Inhalt auf anderen Geräten im Netzwerk zu lokalisieren. Wird er gefunden, werden statt eines Downloads vom Server die Inhalte in Form der aufgeteilten Chunks an das Client-Gerät übertragen. Wenn die angeforderte Software auf mehreren Geräten verfügbar ist, wird die Last zwischen diesen verteilt.

Der RealmJoin Publishing Server muss die Chunk-Identifikatoren bereitstellen und wird daher als einzelne Azure-VM mit Windows 2016 IIS-Server und Azure Blob Storage gehostet. Weitere Informationen zu BranchCache finden Sie in der Microsoft BranchCache-Dokumentation

Back-End

Hosting

Das RealmJoin-Back-End ist eine Azure-Webanwendung, die eine Azure SQL-Datenbank und die verfügbaren Azure-Dienste nutzt. Das Back-End wird in einem Azure-Mandanten gehostet, der ausschließlich für RealmJoin verwendet wird. Alle Kunden-Realms innerhalb dieses Mandanten sind voneinander isoliert.

RealmJoin App Publishing-Endpunkt

Um den BranchCache Mechanismus bereitzustellen, muss der Endpunkt die Chunk-Identifikatoren liefern, eine Funktion, die nur von Microsoft Internet Information Services (IIS)-Servern bereitgestellt wird. Um maximale Skalierbarkeit zu liefern, ist der Publishing-Endpunkt auf mehreren Azure-Knoten verteilt, die Windows 2016 IIS hosten und redundanten Azure Blob Storage gemeinsam nutzen.

Weboberfläche

Die Weboberfläche ist über das RealmJoin Classic-Portalerreichbar. Nach der Anmeldung mit den bereitgestellten Anmeldeinformationen kann der Administrator die Paketverteilung in seinem Mandanten verwalten und auf umfangreiche Informationen zugreifen.

Sicherheitsfunktionen

Client-Authentifizierung

Der RealmJoin-Client authentifiziert sich gegenüber Entra ID über eine gesicherte HTTPS-Verbindung und erhält ein Identifikationstoken. Mit diesem Token kann der Client seine Identität gegenüber der Microsoft Graph API und dem RealmJoin-Back-End nachweisen. Nachdem der Client identifiziert wurde, ist die Antwort des Back-Ends gegenüber dem Client RSA-signiert. Mit dem öffentlichen Schlüssel des Servers können der RealmJoin-Client und -Dienst die Identität der Back-End-Serverantwort verifizieren.