Knowledgebase

Antwort / Lösung

Bitte öffnen Sie UltraSearch, wechseln Sie zu Optionen > Sonstiges > Mit einem DataCentral-Dienst verbinden und klicken Sie auf die Schaltfläche Verbindung testen. Falls die Verbindungsprüfung fehlschlägt, fahren Sie bitte mit folgenden Optionen fort:

1. Verfügbarkeit des Dienstes und Netzwerkverbindung prüfen
   Stellen Sie sicher, dass der Dienst SpaceObServer DataCentral auf dem SpaceObServer-Hostsystem ausgeführt wird und die DataCentral REST-Schnittstelle in SpaceObServer aktiviert ist.
   Öffnen Sie https://hostname:port/healthz. Der Endpunkt muss Healthy zurückgeben.
   Stellen Sie sicher, dass die DataCentral-Verbindung nicht durch eine Firewall blockiert wird. Der Standardport ist 5149.
   Öffnen Sie in SpaceObServer Start > Optionen > Indexdienst und prüfen Sie, ob der DataCentral-Server aktiviert ist und denselben Port verwendet, der auch in UltraSearch konfiguriert ist.
2. Das von DataCentral verwendete Zertifikat prüfen
   Prüfen Sie in SpaceObServer unter Start > Optionen > Indexdienst, welches Zertifikat derzeit für den DataCentral-Dienst konfiguriert ist.
   Vergleichen Sie den dort angezeigten Zertifikat-Fingerabdruck mit dem in UltraSearch konfigurierten Zertifikat bzw. Fingerabdruck.
   In UltraSearch können Zertifikatseinstellungen nur im Administrationsmodus geändert werden.
   Wenn UltraSearch ohne explizite Zertifikatsparameter installiert wurde, validiert es das DataCentral-Zertifikat standardmäßig per Fingerabdruck und speichert den Fingerabdruck der ersten Verbindung für die spätere Kommunikation.

3. Authentifizierung und SPN-Konfiguration prüfen
   Testen Sie in UltraSearch die Verbindung zur IP-Adresse des SpaceObServer-DataCentral-Hosts. Wenn die Verbindung über die IP-Adresse funktioniert, aber nicht über den Servernamen, hängt das Problem typischerweise mit Kerberos/SPNs zusammen. Bei Verbindungen über die IP-Adresse wird in der Regel NTLM verwendet, bei Verbindungen über den Hostnamen bevorzugt Kerberos.
   Wenn die Verbindungsprüfung mit dem Hostnamen Die Verbindung konnte nicht aufgebaut werden zurückgibt, können Sie
   1) NTLM (IP-Adresse nutzen) als Authentifizierungsmethode nutzen (aus Sicherheitsgründen nicht empfohlen; funktioniert nicht, wenn NTLM per Gruppenrichtlinie deaktiviert ist)
   2) GGfs. das Passwort des Dienstkontos neu setzen um einen AES-Schlüssel sicherzustellen
   3) Kerberos funktionsfähig machen, indem Sie die SPN-Konfiguration in Ihrem Active Directory korrigieren (siehe unten).
   
   Unter welchem Konto läuft der DataCentral-Dienst?
   - Lokales System / Netzwerkdienst: In der Regel ist keine SPN-Konfiguration nötig, die vorhandenen HOST/-SPNs des Computerkontos decken auch HTTP/ ab. Registrieren Sie keine HTTP/-SPNs für den Servernamen an einem anderen Konto, das führt genau zu diesem Fehler.
   - Dediziertes Domänenkonto: Registrieren Sie die HTTP-SPNs für dieses Dienstkonto (nicht für das Computerkonto). Beachten Sie dabei den folgenden Hinweis.
   
   Wichtig: Ein expliziter HTTP/-SPN für den Servernamen wirkt sich auf den ganzen Host aus.
   Solange kein eigener HTTP/-SPN existiert, löst Active Directory HTTP/servername über den HOST/-SPN des Computerkontos auf. Registrieren Sie HTTP/servername am Dienstkonto von DataCentral, erhalten Clients ab dann für jeden HTTP- bzw. HTTPS-Dienst auf diesem Host ein Kerberos-Ticket für das Dienstkonto von DataCentral. Andere HTTP-basierte Dienste, die unter dem Computerkonto laufen, können dann nicht mehr per Kerberos authentifiziert werden, z. B. die Windows-Remoteverwaltung (WinRM/PowerShell-Remoting), IIS-Websites oder WSUS. setspn -S und setspn -X warnen dabei nicht, da kein doppelter SPN entsteht. Dienste mit einer anderen Dienstklasse, z. B. Dateifreigaben (CIFS/) oder Remotedesktop (TERMSRV/), sind nicht betroffen.
   Laufen auf dem Host weitere HTTP-basierte Dienste, verwenden Sie stattdessen einen eigenen DNS-Namen für DataCentral (siehe unten).
   
   SPNs prüfen und korrigieren
   Das Ändern von SPNs erfordert Schreibrechte auf das Attribut servicePrincipalName des Kontos (z. B. Domänen-Admin oder delegiert).
   1) Verwenden Sie setspn -L <Dienstkonto>, um die aktuell gesetzten SPNs zu prüfen. Benötigt wird ein SPN für jeden Namen, über den UltraSearch den Server anspricht, z. B. HTTP/servername und HTTP/servername.domain.tld sowie ggf. DNS-Aliase. Der Port (z. B. 5149) ist nicht Teil des SPN.
   2) Prüfen Sie mit setspn -Q HTTP/servername und setspn -Q HTTP/servername.domain.tld, ob diese SPNs bereits einem anderen Konto zugeordnet sind. setspn -X listet doppelte SPNs in der Domäne auf.
   3) Ist ein SPN einem falschen Konto zugeordnet, entfernen Sie ihn dort mit setspn -D <SPN> <falsches Konto>.
   4) Verwenden Sie setspn -S <SPN> <Dienstkonto>, um einen fehlenden SPN hinzuzufügen. Meldet setspn -S einen doppelten SPN, ist dieser bereits einem anderen Konto zugeordnet (siehe 2 und 3).
   5) Löschen Sie auf dem UltraSearch-Client die zwischengespeicherten Kerberos-Tickets mit klist purge (oder melden Sie sich ab und wieder an) und wiederholen Sie die Verbindungsprüfung.
   Kerberos setzt außerdem voraus, dass der Client Mitglied der Domäne (bzw. einer vertrauten Domäne) ist und die Systemzeit von Client und Server um höchstens 5 Minuten abweicht.
   
   Eigenen DNS-Namen für DataCentral verwenden (empfohlen bei Domänenkonto)
   Mit einem eigenen DNS-Namen, z. B. sosdatacentral.domain.tld, erhält DataCentral einen eigenen HTTP/-SPN. Der HTTP/-SPN des Servernamens bleibt beim Computerkonto, und die übrigen HTTP-basierten Dienste des Hosts funktionieren weiter per Kerberos. Dafür muss der neue Name im Zertifikat von DataCentral enthalten sein, und UltraSearch muss DataCentral über diesen Namen ansprechen.
   1) Legen Sie im DNS einen A-Eintrag (keinen CNAME) an, der auf die IP-Adresse des DataCentral-Servers zeigt, z. B. per PowerShell auf dem DNS-Server: Add-DnsServerResourceRecordA -ZoneName domain.tld -Name sosdatacentral -IPv4Address <IP-Adresse>. Bei einem CNAME bildet der Client den SPN aus dem Zielnamen, also wieder aus dem Servernamen. Prüfen Sie die Namensauflösung auf dem Client mit Resolve-DnsName sosdatacentral.domain.tld.
   2) Wurden zuvor HTTP/-SPNs für den Servernamen am Dienstkonto registriert, entfernen Sie diese mit setspn -D HTTP/servername <Dienstkonto> und setspn -D HTTP/servername.domain.tld <Dienstkonto>.
   3) Registrieren Sie die SPNs für den neuen Namen am Dienstkonto mit setspn -S HTTP/sosdatacentral <Dienstkonto> und setspn -S HTTP/sosdatacentral.domain.tld <Dienstkonto>.
   4) Stellen Sie ein Zertifikat mit dem neuen Namen aus, z. B. über Ihre Unternehmens-CA. Das vom SpaceObServer-Installer erzeugte Zertifikat enthält den neuen Namen nicht. Das Zertifikat muss den neuen Namen als alternativen Antragstellernamen (SAN) enthalten (sosdatacentral.domain.tld, ggf. zusätzlich sosdatacentral), für die Serverauthentifizierung zugelassen sein und einen privaten Schlüssel haben. Importieren Sie es in den Zertifikatspeicher Lokaler Computer > Eigene Zertifikate und geben Sie dem Dienstkonto Leserechte auf den privaten Schlüssel.
   5) Wählen Sie das neue Zertifikat in SpaceObServer unter Optionen > Indexdienst aus und starten Sie den DataCentral-Dienst neu.
   6) Tragen Sie in UltraSearch (Administrationsmodus) sosdatacentral.domain.tld als DataCentral-Server ein und aktualisieren Sie den Zertifikat-Fingerabdruck.
   7) Löschen Sie auf dem Client die Kerberos-Tickets mit klist purge und prüfen Sie die Verbindung. klist sollte danach ein Ticket für HTTP/sosdatacentral.domain.tld anzeigen.
   8) Optional: Prüfen Sie mit Test-WSMan -ComputerName servername.domain.tld -Authentication Kerberos, ob die Remoteverwaltung des Hosts wieder per Kerberos funktioniert. Ohne -Authentication sendet Test-WSMan eine anonyme Anfrage und sagt über Kerberos nichts aus.
   Danach erreicht UltraSearch DataCentral per Kerberos nur noch über den neuen Namen. Über den Servernamen erhält der Client ein Ticket für das Computerkonto, das DataCentral unter dem Domänenkonto nicht annehmen kann.
   
   

Wenn die Verbindungsprüfung erfolgreich ist, folgen Sie bitte diesen Schritten:

1. Vorhandensein von Scan/Index prüfen 
   Wenn die Suche keine Ergebnisse liefert, prüfen Sie, ob der Ordner, in dem Sie suchen, bereits von SpaceObServer/DataCentral gescannt und indiziert wurde.  
   Prüfen Sie bei Inhaltssuchen, ob der Volltextindex für den Scan aktiviert ist.  
   Prüfen Sie auch, ob ein UltraSearch-Ausschlussfilter aktiv ist.
2. Protokolle auf dem DataCentral-Server prüfen
   Prüfen Sie das Windows-Ereignisprotokoll auf Fehler von SpaceObServer Agent und SpaceObServer DataCentral.
   Wenn eine Datei durchsuchbar sein sollte, aber nicht gefunden wird, wurde sie möglicherweise aufgrund eines im Ereignisprotokoll angezeigten Indizierungsproblems nicht indiziert.