Planen der Konnektivität zwischen Office 365 und SharePoint Server

 

**Gilt für:**SharePoint Online, SharePoint Server 2013, SharePoint Server 2016

**Letztes Änderungsdatum des Themas:**2017-06-20

Zusammenfassung: Planung und Vorbereitung der Konfiguration von eingehenden Verbindungen aus Office 365 in SharePoint Server-Hybridumgebung.

Dieser Artikel soll Ihnen dabei helfen, eingehende Verbindungen aus Office 365 für Unternehmen über ein Reverseproxygerät für SharePoint Server zu konfigurieren. Dies ist für die folgenden Hybridumgebungen erforderlich:

• Eingehende Hybrid-Suche (Anzeigen von Suchergebnissen von SharePoint Server in Office 365)

• Business Connectivity Services-Hybridbereitstellung

In diesem Artikel erhalten Sie die Informationen, die Sie benötigen (z. B. zu den Voraussetzungen) sowie ein Arbeitsblatt, auf dem Sie wichtige Informationen sammeln können, bevor Sie mit dem Konfigurationsprozess beginnen.

Dieses Thema hilft Ihnen:

• die Voraussetzungen und Anforderungen für eingehende Verbindungen zu verstehen,

• die Architektur Ihrer Webanwendung zu planen,

• SSL-Zertifikate zu planen,

• wichtige Entscheidungen und Informationen aufzuzeichnen.

Erfassen und Aufzeichnen von Informationen zu Arbeitsblatt und Versionsprotokoll

Arbeitsblatt. Im Planungsprozess müssen Sie Informationen und Dateien sammeln. Verwenden Sie hierzu unbedingt das SharePoint-Hybridarbeitsblatt, um Planungs- und Bereitstellungsinformationen nachzuvollziehen und mit anderen Mitgliedern Ihres Bereitstellungsteams zu teilen. Es ist von wesentlicher Bedeutung, dass Sie dieses Arbeitsblatt verwenden, um Ihre Informationen zu organisieren, bevor Sie mit dem Konfigurationsprozess beginnen.

Erstellen eines Versionsprotokolls. Wie bei jedem komplexen Implementierungsprojekt ist die detaillierte Aufzeichnung jeder Designentscheidung oder Serverkonfiguration sowie jedes Verfahrens, jeder Befehlsausgabe und jedes Fehlers eine entscheidende Referenz für Problembehandlung, Support und Sachkenntnis. Daher empfehlen wir Ihnen dringend, dass Sie Ihren Bereitstellungsprozess sorgfältig dokumentieren.

Warnung

Speichern Sie aus Sicherheitsgründen das Arbeitsblatt und das Buildprotokoll an einem Ort mit erhöhter Sicherheit, z. B. in einer gesicherten Dateifreigabe oder SharePoint-Dokumentbibliothek, und gewähren Sie nur Administratoren Zugriff, die am Bereitstellungsprozess beteiligt sind und diese Informationen kennen müssen.

Sammeln und Aufzeichnen von Informationen zu URL und Hostname

In diesem Abschnitt erfahren Sie mehr über das Aufzeichnen von Informationen zu URLs und Hostnamen in Ihrer Umgebung. Diese Informationen werden Sie dann im Zuge des Bereitstellungsprozesses verwenden.

• Zeichnen Sie den öffentlichen DNS-Domänennamens Ihres Unternehmens (z. B. adventureworks.com) auf.

• Zeichnen Sie die URL des öffentlichen Endpunkts des Reverseproxygeräts auf, die Sie für SharePoint Hybrid verwenden werden. Dies ist die Externe URL. Wenn dieser Endpunkt noch nicht besteht, müssen Sie an dieser Stelle entscheiden, wie diese URL lauten soll.

• Zeichnen Sie die IP-Adresse des externen Endpunkts des Reverseproxygeräts auf.

• Stellen Sie sicher, dass ein A-Datensatz (auch Hostdatensatz) in der öffentlichen DNS-Forward-Lookupzone für Ihre öffentliche Domäne besteht, der die externe URL der IP-Adresse des öffentlichen Endpunkts auf dem Reverseproxygerät zuordnet. Wenn dieser A-Datensatz noch nicht vorhanden ist, legen Sie diesen nun an.

• Stellen Sie sicher, dass ein A-Datensatz in der DNS-Forward-Lookupzone für das Intranet besteht, der den Hostnamen Ihrer SharePoint Server-Farm der IP-Adresse zuordnet. Wenn dieser A-Datensatz noch nicht vorhanden ist, legen Sie diesen nun an.

  Wichtig

  Wenn Sie interne URLs konfigurieren, um während des Bereitstellungsprozesses auf eine Webanwendung zuzugreifen, stellen Sie sicher, dass Sie für die URLs in der Intranet-DNS-Forward-Lookupzone ebenfalls einen A-Datensatz erstellen und sie in das Arbeitsblatt eintragen.

Tragen Sie die folgenden Informationen in Tabelle 3 des SharePoint-Hybridarbeitsblatts ein: Den Domänennamen der öffentlichen Unternehmens-DNS-Domäne in die Zeile Name der öffentlichen Internetdomäne. Die URL des öffentlichen Endpunkts des Reverseproxygeräts in die Zeile Externe URL. Die IP-Adresse des externen Endpunkts des Reverseproxygeräts in die Zeile IP-Adresse des externen Endpunkts.

Weitere Informationen zur Beziehung zwischen URLs und Hostnamen in einer Hybridumgebung finden Sie im Video Grundlegendes zu URLs und Hostnamen. Länge: 6 Minuten.

Planen der Architektur Ihrer Webanwendung

Dieser Abschnitt hilft Ihnen bei der Planung der Architektur der SharePoint Server-Webanwendungen, die Sie in Ihrer Hybridumgebung verwenden werden.

Eingehende Verbindungen benötigen einen sicheren Kommunikationskanal zwischen der lokalen SharePoint Server-Farm und SharePoint Online. Daten werden zwischen einer Websitesammlung in SharePoint Online und einer lokalen Webanwendung über diesen Kommunikationskanal ausgetauscht.

SharePoint Online senden Anforderungen an den Reverseproxyserver, der die Anforderungen verzögert an eine bestimmte Webanwendung in der lokalen SharePoint Server-Farm sendet, der für SharePoint-Hybrid konfiguriert ist. Wir bezeichnen das als die primäre Webanwendung.

Tipp

Unabhängig davon, wie viele Hybridlösungen Sie konfigurieren möchten, Sie verwenden meist nur eine primäre Webanwendung. Sie müssen nicht für jede weitere Hybridlösung eine neue primäre Webanwendung erstellen.

Sowohl die primäre Webanwendung als auch eine einzelne Websitesammlung in dieser primären Webanwendung müssen so konfiguriert sein, dass sie einhegende Verbindungen von SharePoint Online akzeptieren.

Der SharePoint-Administrator verbindet die Dienste und Verbindungsobjekte, die erforderlich sind, um die Hybridlösungen zu unterstützen, die mit der primären Webanwendung bereitgestellt werden. Ausgehende Verbindungen können von jeder lokalen SharePoint Server-Webanwendung aus vorgenommen werden, indem die funktionsspezifischen Konfigurationen verwendet werden.

Eine SharePoint ServerWebanwendung besteht aus einer Internetinformationsdienste (IIS)-Website, die als logische Einheit für die Websitesammlungen dient, die Sie erstellen. Jede Webanwendung wird von einer anderen IIS-Website mit einem eindeutigen oder geteilten Anwendungspool und einer eindeutigen öffentlichen URL dargestellt und kann auch so konfiguriert werden, dass sie fünf interne URLs mit Alternate Access Mapping (AAM) verwendet. Eine Webanwendung wird mit einer einzelnen Inhaltsdatenbank verbunden und so konfiguriert, dass sie eine bestimmte Authentifizierungsmethode verwendet, um eine Verbindung mit der Datenbank herzustellen. Mehrere Webanwendungen können so konfiguriert werden, dass sie verschiedene Authentifizierungsmethoden verwenden (und wahlweise AAMs), um auf eine einzelne Inhaltsdatenbank zuzugreifen.

Die öffentliche URL einer Webanwendung wird in allen Links zu Websites und zu Inhalten, auf die über eine Webanwendung zugegriffen wird, als Stamm-URL verwendet. Stellen Sie sich eine Webanwendung mit der öffentlichen URL https://spexternal.adventureworks.com vor, deren interne URL https://sharepoint mit AAM konfiguriert wurde. Wenn Sie nun die interne URL https://sharepoint aufrufen, gibt SharePoint Server die Website mit der URL https://spexternal.adventureworks.com zurück, und alle Links innerhalb der Website verfügen nun über URLs, die auf diesem Pfad beruhen.

Alternate Access Mapping (AAM) wird nur benötigt, wenn Sie eingehende Verbindungen konfigurieren, die eine pfadbasierte Websitesammlung mit öffentlicher URL verwendet, die sich von der externen URL unterscheidet. Mit AAM können Sie die externe URL mit der internen URL einer SharePoint-Website in Ihrem Unternehmen verbinden. Dadurch kann SharePoint Server die Anfragen für interne URLs, die mit AAM konfiguriert sind, an die entsprechende primäre Webanwendung weiterleiten.

Weitere Informationen zu anspruchbasierten Webanwendungen finden Sie unter Create claims-based web applications in SharePoint Server.

Weitere Informationen zur Erweiterung von Webanwendungen finden Sie unter Erweitern anspruchsbasierter Webanwendungen in SharePoint.

Weitere Informationen zu Websitesammlungen finden Sie unter Übersicht über Websites und Websitesammlungen in SharePoint Server.

Wählen einer Strategie für die Websitesammlung

Bevor Sie sich entscheiden, entweder eine bereits bestehende Webanwendung zu verwenden oder eine neue zu erstellen, müssen Sie die Konfigurationsanforderungen verstehen, die Webanwendung und Websitesammlung erfüllen müssen, um die hybride Funktion zu unterstützen. Mithilfe der Informationen in diesem Abschnitt können Sie eine Strategie zur Erstellung einer neuen Webanwendung und Websitesammlung festlegen oder ermitteln, ob eine Websitesammlung in einer bereits bestehenden Webanwendung in Ihrer Hybridumgebung verwendet werden kann.

Die folgenden Abbildungen stellen den Entscheidungsfluss für die Festlegung einer Strategie für Ihre Websitesammlung dar.

Anforderungen für hybride Webanwendungen

Webanwendungen, die für hybride Funktionen verwendet werden, müssen die folgenden Anforderungen erfüllen:

• Die öffentliche URL der Webanwendung muss mit der externen URL übereinstimmen.

  Das OAuth-Protokoll stellt die Benutzerautorisierung in SharePoint-Hybridlösungen bereit. Der Host-Anforderungsheader in allen SharePoint Online-Kommunikationen zu lokalen SharePoint-Installationen enthält die URL, an die die Anforderung ursprünglich gesendet wurde. Um eingehende Anforderungen von SharePoint Online zu authentifizieren, muss der loakle SharePoint-Authentifizierungsdienst diese URL im gesamten Verkehr von SharePoint Online der öffentlichen URL der primären Webanwendung zuordnen können. Dies ist die Externe URL. Ein Vorteil der Verwendung einer Websitesammlung mit Hostname für SharePoint-Hybridumgebungen ist, dass Sie eine Websitesammlung mit Hostname so konfigurieren können, dass sie dieselbe URL als externe URL verwendet. Dadurch muss Alternate Access Mapping nicht mehr konfiguriert werden.

• Die Webanwendung muss für die Verwendung der integrierten Windows-Authentifizierung mit NTLM konfiguriert sein.

  Eine integrierte Windows-Authentifizierung mit NTLM ist für Webanwendungen erforderlich, die in Szenarien bereitgestellt werden, die Server-zu-Server- und App-Authentifizierungen unterstützen. Weitere Informationen hierzu finden Sie unter Planen der Server-zu-Server-Authentifizierung in SharePoint Server.

  

Anforderungen für bestimmte Konfigruationen für Websitesammlungen

Websitesammlungen, die für Hybridfunktionen verwendet werden, müssen all diesen Anforderungen entsprechen und entweder in einer Webanwendung bestehen oder in einer erstellt werden, die den Anforderungen für Webanwendungen entspricht:

• Websitesammlungen mit Hostname

  • Die Webanwendung muss Websitesammlungen mit Hostnamen unterstützen.

    Um eine Websitesammlung mit Hostname zu verwenden, muss die Webanwendung so erstellt werden, dass sie diese aktiviert. Sie können diese Funktion nicht aktivieren, nachdem die Webanwendung erstellt wurde.

    Weitere Informationen zur Erstellung einer Websitesammlung mit Hostname finden Sie unter Websitesammlungsarchitektur mit Hostnamen und Bereitstellung in SharePoint Server.

    Hinweis

    Obgleich dies eine Anforderung für Webanwendungen ist, wird sie dennoch hier aufgeführt, da sie nur für Umgebungen gilt, die über Websitesammlungen mit Hostnamen verfügen.

  • Ihr lokaler DNS-Server muss mit geteilter DNS konfiguriert werden. Sie müssen für die öffentliche Internetdomäne, die Sie für Ihre öffentliche URL verwendet haben, eine Forward-Lookupzone sowie darin einen A-Datensatz (Hostdatensatz) erstellen, der die IP-Adresse des SharePoint Server-Servers enthält sowie den Hostnamen Ihrer externen URL.

    Wichtig

    Das Reverseproxygerät muss die Hostnamen in dieser Forward-Lookupzone auflösen können, um eingehende Anfragen an die SharePoint Server-Farm weiterzuleiten.

• Pfadbasierte Websitesammlungen

  • Wenn die öffentliche URL mit der externen URL identisch ist

    Ihr lokaler DNS-Server muss mit geteilter DNS konfiguriert werden. Sie müssen für die öffentliche Internetdomäne, die Sie für Ihre öffentliche URL verwendet haben, eine Forward-Lookupzone sowie darin einen A-Datensatz erstellen, der die IP-Adresse des SharePoint Server-Servers enthält sowie den Hostnamen Ihrer externen URL.

    Wichtig

    Das Reverseproxygerät muss die Hostnamen in dieser Forward-Lookupzone auflösen können, um eingehende Anfragen an die SharePoint Server-Farm weiterzuleiten.

    Dies ist eine einfache Möglichkeit, um eine Webanwendung für ein hybrides SharePoint zu konfigurieren. Ziel ist es, das Feld Öffentliche URL in der neuen Webanwendung der URL des öffentlichen Endpunkts auf dem Reverseproxy zuzuordnen, die auch als externe URL bezeichnet wird.

  • Wenn die öffentliche URL mit der externen URL nicht identisch ist:

    In diesem Fall müssen Sie eine alternative Zugriffszuordnung (AAM) konfigurieren, um eingehende Anfragen von SharePoint Online weiterzuleiten.

    Erweitern Sie die primäre Webanwendung, und verwenden Sie die externe URL als Öffentliche URL. Erstellen Sie dann in derselben Sicherheitszone, in der sich die erweiterte Webanwendung befindet, eine interne URL (über Interne URLs hinzufügen), und verwenden Sie diese als Überbrückungs-URL. Konfigurieren Sie außerdem das Reverseproxygerät, um eingehende Anfragen von SharePoint Online an diese Überbrückungs-URL weiterzuleiten.

    Denken Sie daran, dass eine alternative Zugriffszuordnung (AAM) nur dann erforderlich ist, wenn Sie eingehende Verbindungen mit pfadbasierter Websitesammlung und öffentlicher URL konfigurieren, die nicht mit der externen URL identisch ist.

Hinweis

Denken Sie daran, dass die Externe URL die URL des Internet-Endpunkts des Reverseproxygeräts ist.

Tragen Sie Ihre Strategie für die Websitesammlung in das Arbeitsblatt in die Zeile Site collection strategy in Tabelle 2 ein.

Wählen einer vorhandenen Webanwendung oder Erstellen einer neuen Webanwendung

Sie können entweder eine vorhandene Webanwendung verwenden oder eine neue erstellen, um sie als primäre Webanwendung zu verwenden.

Wenn Sie lieber die Webanwendung unabhängig verwalten möchten, die Sie für die Hybridfunktion verwenden, oder wenn Ihre vorhandene Webanwendung nicht den im Abschnitt Auswählen einer Strategie für die Websitesammlung aufgeführten Anforderungen entspricht, sollten Sie eine neue Webanwendung erstellen.

Tragen Sie Ihre Entscheidung in die Zeile New or existing web application in Tabelle 2 ein.

Verwenden einer vorhandenen Webanwendung

Wenn Sie eine vorhandene Webanwendung als primäre Webanwendung verwenden möchten, erfassen Sie die URL der primären Webanwendung sowie die URL der obersten Websitesammlung, und tragen Sie diese in das Arbeitsblatt ein.

Tragen Sie die folgenden Informationen in Ihr Arbeitsblatt ein: Tragen Sie je nach Ihrer Strategie für die Websitesammlung die URL der primären Webanwendung in die Zeile Primary web application URL in Tabelle 5a, 5b oder 5c ein. Wenn Sie eine vorhandene Websitesammlung mit Hostname verwenden, tragen Sie die URL der obersten Websitesammlung in die Zeile Host-named site collection URL in Tabelle 5a ein.

Nachdem Sie diese Informationen eingetragen haben, wechseln Sie zu Planen von SSL-Zertifikaten.

Planen der Erstellung einer neuen Webanwendung

Wenn Sie sich entschieden haben, eine neue Webanwendung zu erstellen, erfahren Sie mehr dazu im Zuge der Konfiguration der Hybridtopologie.

Planen von SSL-Zertifikaten

SSL-Zertifikate geben die Serveridentität an und ermöglichen die Authentifizierung von verschiedenen Diensten und Verbindungen in einer SharePoint-Hybridumgebung. Sie benötigen zwei SSL-Zertifikate: ein SSL-Zertifikat des sicheren Kanals und ein STS-Zertifikat.

Weitere Informationen zur Verwendung von SSL-Zertifikaten in SharePoint-Hybridumgebungen finden Sie unter SharePoint 2013-Hybridtopologie: Zertifikat und Authentifizierungsmodell

Hinweis

Wenn Sie Ihre lokale SharePoint-Farm mit SSL schützen möchten, benötigen Sie ebenfalls ein SSL-Zertifikat für die primäre Webanwendung. Für dieses Zertifikat bestehen keine hybridspezifischen Überlegungen, sodass Sie für die Konfiguration von SharePoint Server mit SSL die bewährten Methoden anwenden können.

Hinweis

"Secure Channel" ist keine Zertifikatklasse; wir verwenden diesen Begriff, um zwischen diesem Zertifikat und SSL-Zertifikaten zu unterscheiden, die in der Umgebung verwendet werden.

Secure Channel SSL-Zertifikate

Ein Secure Channel SSL-Zertifikat bietet Authentifizierung und Verschlüsselung für den sicheren Kommunikationskanal zwischen dem Reverseproxygerät und Office 365 und dient sowohl als Server- als auch als Clientzertifikat. Es bestätigt außerdem die Identität des Reverseproxyendpunkts, der verwendet wird, um die lokale SharePoint Server-Websitesammlung zu veröffentlichen.

Dieses Zertifikat muss entweder ein Platzhalter- oder ein SAN-Zertifikat sein, und es muss von einer öffentlichen Stammzertifizierungsstelle ausgegeben worden sein. Das Betrefffeld dieses Zertifikats muss den Hostnamen des externen Endpunkts des Reverseproxyservers oder eine Platzhalter-URL enthalten, die alle Hostnamen im Namespace abdeckt. Es muss außerdem mindestens eine 2048-Bit-Verschlüsselung verwenden.

Wichtig

Platzhalterzertifikate können nur eine einzige Ebene eines DNS-Namespace abdecken. Wenn Ihre externe URL beispielsweise https://spexternal.public.adventureworks.com ist, muss der Betreff Ihres Platzhalterzertifikats ".public.adventureworks.com" lauten, nicht ".adventureworks.com".

In Szenarien, in denen SharePoint Online so konfiguriert ist, dass es von SharePoint Server Informationen anfordert, wird ein SSL-Zertifikat benötigt, um folgende Aufgaben zu übernehmen:

• Verschlüsselung des Datenverkehrs über den Sicherheitskanal.

• Aktivierung des Reverseproxygeräts, sodass es eingehende Verbindungen mit der Zertifikatauthentifizierung authentifizieren kann.

• SharePoint Online erlauben, den externen Endpunkt zu identifizieren und ihm zu vertrauen.

Während der Bereitstellung installieren Sie das SSL-Zertifikat sowohl auf dem Reverseproxygerät als auch auf einer SharePoint Online Secure Store-Zielanwendung. Dies wird während der Konfiguration der Infrastruktur der Hybridumgebung konfiguriert.

Abrufen eines Secure Channel SSL-Zertifikats

Rufen Sie über eine bekannte Zertifizierungsstelle, wie DigiCert, VeriSign, Thawte oder GeoTrust, einen Secure Channel SSL-Platzhalter oder ein SAN-Zertifikat (Subject Alternative Name-Zertifikat) für Ihre lokale öffentliche Domäne ab.

Hinweis

• Das Zertifikat muss mehrere Namen unterstützten und benötigt mindestens 2048 Bit.

• Das Feld Betreff oder Antragsstellername des Zertifikats muss einen Platzhaltereintrag des Domänennamens in der externen URL enthalten. Wenn Ihre externe URL beispielsweise "https://spexternal.public.adventureworks.com" ist, sollte der Betreff Ihres Platzhalterzertifikats *.public.adventureworks.com lauten.

• Zertifikate laufen normalerweise im Einjahresrhythmus ab. Sie müssen daher unbedingt vor Ablauf die Verlängerung von Zertifikaten vorbereiten, um Dienstunterbrechungen zu vermeiden. SharePoint-Administratoren sollten sich eine Erinnerung an den Austausch des Zertifikats mit ausreichend Vorlaufzeit erstellen, um eine Unterbrechung zu verhindern.

Tragen Sie Folgendes in Tabelle 4b: Secure Channel SSL-Zertifikat des Arbeitsblatts ein: Den Namen dieses Zertifikats und den Ort, an dem Sie es gespeichert haben, in die Zeile Secure Channel Certificate location and file name. Den Anzeigenamen des Zertifikats in die Zeile Secure Channel SSL Certificate Friendly Name. Den Typ des Zertifikats (Platzhalter oder SAN) in die Zeile Zertifikatstyp. Das Ablaufdatum des Zertifikats in die Zeile Ablaufdatum. Sofern das Zertifikat die Dateinamenerweiterung PFX aufweist, das Kennwort des Zertifikats in die Zeile Kennwort des Secure Channel SSL-Zertifikats. Denken Sie daran, das Arbeitsblatt mit dem Kennwortschutz zu sichern, wenn Sie die Kennwortinformationen aktualisieren.

STS -Zertifikate

Das STS-Zertifikat der lokalen SharePoint-Farm benötigt ein Standardzertifikat, um eingehende Token validieren zu können. In einer SharePoint-Hybridumgebung fungiert Azure Active Directory als vertrauenswürdiger Tokensignaturdienst und verwendet das STS-Zertifikat als Signaturzertifikat. Azure Active Directory kann jedoch das Standard-STS-Zertifikat von SharePoint Server nicht als Signaturzertifikat verwenden, da es die Vertrauenskette des Standardzertifikats nicht überprüfen kann.

Daher müssen Sie das Standard-STS-Zertifikat auf jedem Server in der lokalen SharePoint-Farm mit einem der folgenden Zertifikate ersetzen:

• Ein Zertifikat einer öffentlichen Zertifizierungsstelle (CA), der Azure Active Directory vertraut

• Ein selbstsigniertes Zertifikat

Das Standard-STS-Zertifikat wird später ersetzt, wenn Sie die Identitätsverwaltungsstruktur konfigurieren.

Wichtig

• Das Zertifkat benötigt mindestens 2048 Bit.

• Sie müssen das STS-Zertifikat auf jedem Web- und Anwendungsserver in der SharePoint Server-Farm ersetzen.

• Zertifikate laufen normalerweise im Einjahresrhythmus ab. Sie müssen daher unbedingt vor Ablauf die Verlängerung von Zertifikaten vorbereiten, um Dienstunterbrechungen zu vermeiden.

Wenn Sie ein selbstsigniertes Zertifikat verwenden möchten, erstellen Sie dieses während der Bereitstellungskonfiguration. Die einzelnen Schritte zur Erstellung eines neuen selbstsignierten Zertifikats für SharePoint finden Sie im Thema Konfigurieren der Server-zu-Server-Authentifizierung von SharePoint Server in SharePoint Online.

Abrufen eines STS-Zertifikats

Rufen Sie Ihr STS-Zertifikat ab, bevor Sie mit der Konfiguration beginnen.

Tragen Sie Folgendes in das Arbeitsblatt in Tabelle 4a: STS-Zertifikat ein: Anzeigename des STS-Zertifikats Pfad\Dateiname des STS-Zertifikats (*.PFX-Datei) Kennwort des STS-Zertifikats Pfad\Dateiname des STS-Zertifikats (*.CER-Datei) Antragstellername Startdatum des STS-Zertifikats Enddatum des STS-Zertifikats

Aufzeichnen der Konten für Konfiguration und Tests

Die Einrichtung einer SharePoint-Hybridumgebung erfordert mehrere Benutzerkonten sowohl in Ihrem lokalen Active Directory als auch im Office 365-Verzeichnis (ein aktives Azure Active Directory-Verzeichnis, das im Office 365-Verzeichnis bereitgestellt wird). Diese Konten verfügen über unterschiedliche Berechtigungen und Gruppen- oder Rollenmitgliedschaften. Einige der Konten werden verwendet, um Software bereitzustellen und zu konfigurieren, und einige werden benötigt, um bestimmte Funktionen zu testen und zu garantieren, dass die Sicherheits- und Authentifizierungssysteme wie erwartet arbeiten.

• Eine umfassende Erläuterung der benötigten Konten, einschließlich Hinweise zu Rollen- und Identitätsanbietern, finden Sie unter Erforderliche Konten für die Konfiguration und das Testen der Hybridlösung.

• Tragen Sie die erforderlichen Kontoinformationen wie beschrieben in das Arbeitsblatt ein.

• Rufen Sie nach Abschluss dieses Schritts diesen Planungsartikel wieder auf.

Nächste Schritte

An dieser Stelle sollten Sie das Arbeitsblatt für eingehende Verbindungen ausgefüllt haben und bereit sein, mit der Konfiguration zu beginnen. Fahren Sie nun mit dem Auswählen einer Konfigurationsroadmap fort.