SharePoint Hybrid Search: Implementierung einer unidirektional eingehenden Topologie

15. Oktober 2014
SharePoint Hybrid Search

Wie im vorangegangenen Beitrag bereits angeteasert, wird im ersten Teil dieser Blogserie die Implementierung einer hybriden SharePoint Suche im Vordergrund stehen. Grundlage ist folgender Use Case: ein Unternehmen benutzt SharePoint Online als Intranet (im vorliegenden Use Case wird der Office 365 Plan E3 verwendet). Zudem befinden sich jedoch noch verschiedene Inhalte on-Premise, welche nicht migriert werden konnten bzw. aus Compliance Gründen nicht sollten. Im besagten Use Case handelt es sich dabei um einen on-Premise Server SharePoint 2010 sowie einen NAS Fileshare.

Da die technische Umsetzung durchaus komplexerer Natur ist, wird die Beschreibung der unidirektional eingehenden Topologie in zwei Blogbeiträge aufgeteilt. Dieser Beitrag wird sich mit der Installation und Konfiguration der on-Premise Ressourcen beschäftigen: einem SharePoint Server 2013 SP1, dem neuen SQL Server 2014 sowie der Einrichtung eines Reverse Proxy.

Was wird benötigt?

Zunächst wird ein SQL Server benötigt. Im vorliegenden Use Case fiel die Wahl auf den aktuellen SQL Server 2014. Es wäre aber natürlich auch ein SQL Server 2012 oder sogar ein SQL Server 2008 R2 SP1 in Frage gekommen. Aus Performancegründen sollte hierfür auf jeden Fall ein zusätzlicher Server oder eine entsprechende Virtuelle Maschine genutzt werden. Andernfalls drohen spürbare Einbußen in der Performance und das Sucherlebnis könnte schnell zu einem unangenehmen Warteerlebnis werden.

Nachdem der SQL Server aufgesetzt wurde, steht die Installation und Konfiguration des on-Premise SharePoint Servers an. Da ein aktueller v15 Office 365 Tenant vorliegt, fällt die Wahl auch auf die aktuelle SharePoint Version: 2013. Office 365 wird regelmäßig durch Microsoft aktualisiert, weswegen empfohlen wird, den SharePoint Server ebenfalls auf dem aktuellsten Patch-Stand zu verwenden. Da es gerade in der jüngeren Vergangenheit durchaus Probleme mit Microsoft Updates gab, kann man natürlich andere interne Vorgaben besitzen. Man sollte jedoch zumindest das aktuelle Service Pack verwenden, vor allem wenn dies schon seit einigen Monaten veröffentlicht ist.

Wenn es erst kurz zuvor herausgekommen ist, sollte man jedoch auch hier Vorsicht walten lassen oder das ganze Szenario am besten erst in einer Testumgebung durchspielen. Man denke nur an die erste Version des Service Pack 1 für SharePoint Server 2013, welches nach kurzer Zeit zurückgerufen wurde, nachdem es massive Probleme mit der Suche gegeben hatte. Mittlerweile wurde dies jedoch behoben und die aktuelle Version des Service Packs 1 kann normal genutzt werden.

Nachdem der SharePoint Server installiert und auf den entsprechenden Patch-Stand gebracht wurde, sind natürlich noch einige Konfigurationen im SharePoint selbst notwendig. Zunächst wird eine separate Web Application für die SharePoint Search benötigt. Um die Sicherheit zu maximieren, bietet es sich an, hierfür eine separate IP Adresse zu verwenden. So kann man den Zugriff auf das Search Center und die Central Administration des SharePoint Servers klar voneinander trennen. Hierfür ist natürlich eine zweite Netzwerkkarte bzw. bei einer virtuellen Maschine ein zweiter Netzwerkadapter notwendig.

SharePoint Konfiguration

Zunächst beginnen wir mit der Einrichtung der benötigten Services. Über die Central Administration kann man in den System Settings in der Option Manage services on server überprüfen, ob die notwendigen Services gestartet sind.

Dabei handelt es sich um den App Management Service, den Microsoft SharePoint Foundation Settings Service, die Search Service Application sowie den User Profile Service. Diese muss man, falls sie noch auf Stopped stehen, rechts im Actionfeld starten. 

Zudem ist noch die Befüllung des SharePoint User Profile Stores notwendig. Hierfür in der Central Administration unter Manage service applications den User Profile Service anklicken und unter Synchronisation die Option Configure Synchronization Connections auswählen. 

Hier ist dann eine neue Verbindung vom Typ Active Directory einzurichten. Anschließend kann man einen regelmäßigen Timer Job konfigurieren, welcher in regelmäßigen Abständen die Daten mit dem Active Directory synchronisiert.

Nachdem dies erledigt ist, muss eine neue Web Application eingerichtet werden. Dies kann man ebenfalls in der Central Administration im Bereich Application Management durchführen. Über Manage Web Applications und New kann man die neue Web Application anlegen. Hierbei ist zu beachten, dass man SSL über Port 443 benutzt. 

Weiter oben im Blogbeitrag wurde bereits beschrieben, dass diese Web Application über eine separate IP aufgerufen werden soll. Daher sollte die URL entsprechend angepasst werden:

Abschließend ist noch zu überprüfen, dass die benötigten Service Applications für die Web Application zugeordnet sind:

Wenn die Einstellungen korrekt sind, kann man über den OK Button die Web Application erstellen. Nun muss man noch die Web Application der entsprechenden IP sowie ein Zertifikat für SSL zuordnen. Dies kann man über den Internet Information Services Manager (IIS) erledigen.

Im Connections Fenster des ISS Managers auf der linken Seite zunächst den Server anklicken (direkt unter Start Page). Anschließend auf Server Certificates klicken. 

Dort dann im Actions Menü die gewünschte Option wählen. Man kann über Create Self-Signed Certificate ein eigenes Zertifikat erstellen. Es ist jedoch eher zu empfehlen, ein Zertifikat einer öffentlichen Zertifizierungsstelle wie beispielsweise Thawte oder, wie in diesem vorgestellten Use Case, Go Daddy zu verwenden. Hierfür muss die Option Import gewählt werden. 

Wenn das Zertifikat vorhanden ist, muss es noch an die Web Application gebunden werden. Hierfür wieder auf den linken Bereich Connections im IIS unter Sites die Web Application heraussuchen, welche man zuvor im SharePoint angelegt hat. Danach wieder rechts im Action Menü auf die Bindings klicken. 

Mit Doppelklick auf das angezeigte Binding gelangt man zum Edit Site Binding Fenster. Dieses sollte anhand der folgenden Maske ausgefüllt sein:

Nun muss man noch im DNS der Domäne die entsprechenden Einträge vornehmen. Für die IP, welche man für die Web Application gewählt hat, ist der Host Name im DNS anstelle des Servernamens einzutragen (als A Eintrag).

Als nächster Schritt folgt die Einrichtung des Search Centers. In der Central Administration im Bereich Application Management auf Create site collections klicken. 

Dort darauf achten, dass es an die zuvor kreierte Web Application gebunden ist und in der Template Selection den Tab Enterprise und dort dann Enterprise Search Center auswählen. 

Nun müssen noch die notwendigen Content Sources eingebunden werden. Dabei handelt es sich um die internen Ressourcen, welche später mit dem SharePoint Online durchsucht werden können sollen. Dies kann man in der Central Administration über den Bereich Application ManagementManage service applications durchführen. 

Dort dann die Search Service Application anklicken und im anschließenden Menü Search Administration unter Crawling die Content Sources wählen. Mit New Content Sources können hier dann neue Content Sources hinzugefügt werden. 

Beim Hinzufügen der Content Sources kann man dann anschließend über Content Source Type auswählen, was man durchsuchen möchte. In unserem Use Case wäre dies beispielsweise SharePoint Sites für den zu durchsuchenden SharePoint 2010 on-Premise und File Shares für das NAS. 

Wenn die Content Sources angelegt sind, kann man zurück in die Search Administration gehen. Unter Content Sources die entsprechende Quelle anwählen und mit einem Rechtsklick im Menü den Full Crawl starten. 

Nun muss nur noch festgelegt werden, wer Zugriff auf das Search Center haben soll. Für ein Intranet bietet es sich an, hierfür eine oder mehrere AD Gruppen festzulegen.

Hierfür im Browser die Adresse des Search Centers aufrufen und sich mit einem Account anmelden, welchem man Site Collection Administrator Rechte gegeben hat. Oben rechts in den Einstellungen (kleines Zahnrad) dann auf Site Settings klicken. 

Bei User and Permissions den ersten Link People und Groups anklicken. Dort kann man dann unter New die User oder Gruppen auswählen, welche hinzugefügt werden sollen.

Einrichtung und Konfiguration eines Reverse Proxy

Für die Einrichtung einer unidirektional eingehenden Hybridtopologie wird als sicherer Endpunkt für den eingehenden Datenverkehr ein Reverse Proxy benötigt. Technet nennt hierfür lediglich drei unterstützte Reverseproxygeräte: Windows Server 2012 R2 mit Web Application Proxy, das Forefront TMG 2010 und BIG-IP von F5 Technologies. Diese Liste erscheint auf den ersten Blick ausgesprochen kurz, erhebt jedoch selbst keinen Anspruch auf Vollständigkeit. Weitere Reverseproxygeräte sollen im Laufe der Zeit hinzugefügt werden, sobald sie getestet wurden.

Deswegen sollte man vielmehr auf die notwendigen Requirements achten und anhand dessen bewerten, ob die präferierte Lösung für die Aufgabe geeignet ist. Das Forefront Thread Management Gateway ist beispielsweise eine Technologie, welche Microsoft aus seiner Produktpalette gestrichen hat, wodurch gerade in diesem Bereich (Unified Thread Management(UTM)/ „Firewall“) eine beachtliche Anzahl von Anbietern neu auf den Markt gekommen sind oder zumindest eine erheblich größere Verbreitung genießen als zuvor.

Folgende Voraussetzungen müssen für das Hybridszenario erfüllt sein:

  • Unterstützung der Clientzertifikatsauthentifizierung mit einem Platzhalter- oder SAN-SSL-Zertifikat
  • Unterstützung für OAuth 2.0 Pass-Through-Authentifizierung
  • Annahme von Traffic auf TCP Port 443
  • Bindung eines Platzhalters - oder SAN-SSL-Zertifikats an einen veröffentlichten Endpunkt
  • Weiterleitung des Traffics an eine SharePoint 2013 on-Premise Farm

Für unseren Use Case wird eine UTM Appliance 9.2 der Firma Sophos verwendet. Die Einrichtung erfolgt über die WebAdmin Oberfläche.

Im Bereich Web Server Application → Reverse Application Firewall muss man zunächst bei Real Webservers einen neuen Eintrag anlegen. Als Host wird hierbei der DNS Eintrag gewählt, welchen wir weiter oben nach der Einrichtung der Web Application angelegt haben. Als Type muss Encrypted (HTTPS) ausgewählt werden, wobei 443 als Port automatisch gesetzt wird. 

Anschließend wird unter Virtual Webservers ein neuer virtueller Webserver eingerichtet. Hierfür muss eine öffentliche IP vorhanden sein, welche vorher entsprechend im Public DNS eingetragen werden muss.

Achtung: Diesen Schritt sollte man entweder vorbereiten, oder eine Wartezeit einkalkulieren, denn bis derartige Einträge vom Provider übernommen worden, können teilweise 24 oder mehr Stunden vergehen.

Auch hier wird als Type Encrypted (HTTPS) und Port 443 verwendet. Zudem wird hier das Zertifikat ausgewählt (welches man, falls nicht schon vorhanden, zuvor auf der UTM einbinden muss). 

Als Domain wählt man den Namen, welchen man im Public DNS für die Public IP eingetragen hat und bei Real Webservers wählt man via Klick den Webserver aus, welchen man im Schritt zuvor eingerichtet hat. Als Firewall Profil reicht es, hier die Basic Protection auszuwählen. Im aufklappbaren Teil Advanced ist noch die Option Pass Host Header auszuwählen. 

Wenn beide Einträge korrekt eingetragen und in der UTM aktiviert  wurden, ist die Einrichtung des Reverse Proxy abgeschlossen. Dies kann man austesten, indem man sich von außerhalb des Netzes via Browser im Search Center anmeldet. Wenn dies über HTTPS funktioniert, das Zertifikat gültig ist und man sich erfolgreich im Search Center authentifizieren kann, kann man zu den nächsten Schritten übergehen.

Die noch ausstehenden Schritte für die Einrichtung der (unidirektional eingehenden) hybriden SharePoint Suche sind die Konfiguration des Identitätsmanagements sowie die Einrichtung und Modifikation der hybriden Suche im Office 365/SharePoint Online. Diese beiden Themen werden dann im nächsten Blogbeitrag weiter ausgeführt werden 

Neuen Kommentar schreiben