Fehler "SSPI-Kontext kann nicht generiert werden" bei Verwendung von Windows-Authentifizierung zum Verbinden SQL Server

Gilt für:   SQL Server
Ursprüngliche KB-Nummer: 811889

Hinweis

Bevor Sie mit der Problembehandlung beginnen, sollten Sie die Voraussetzungen überprüfen und die Checkliste durchgehen.

Wenn Sie Windows-Authentifizierung verwenden, um eine SQL Server Instanz remote zu verbinden, wird die folgende Fehlermeldung angezeigt:

Der Zielprinzipalname ist falsch. SSPI-Kontext kann nicht generiert werden.

Häufig gestellte Fragen

Was ist SSPI?

Security Support Provider Interface (SSPI) ist eine Gruppe von Windows-APIs, die die Delegierung und gegenseitige Authentifizierung über alle generischen Datentransportebenen, z. B. TCP/IP-Sockets, ermöglichen. Mindestens ein Softwaremodul stellt die tatsächlichen Authentifizierungsfunktionen bereit. Jedes Modul wird als Security Support Provider (SSP) bezeichnet und als Dynamic Link Library (DLL) implementiert.

Was ist Kerberos?

Das Kerberos v5-Protokoll ist ein Sicherheitspaket nach Branchenstandard und eines der drei Sicherheitspakete in Windows-Betriebssystemen. Weitere Informationen finden Sie unter Security Support Providers (SSPs).For more information, see Security Support Providers (SSPs).

Was bedeutet der Fehler "SSPI-Kontext kann nicht generiert werden"?

Dieser Fehler bedeutet, dass SSPI versucht, die Kerberos-Authentifizierung jedoch nicht verwenden kann, um Clientanmeldeinformationen über TCP/IP oder Named Pipes an SQL Server zu delegieren. In den meisten Fällen verursacht ein falsch konfigurierter Dienstprinzipalname (Service Principal Name, SPN) diesen Fehler.

Was ist SPN?

Ein Dienstprinzipalname (Service Principal Names, SPN) ist ein eindeutiger Bezeichner einer Dienstinstanz. SPNs werden von der Kerberos-Authentifizierung verwendet, um eine Dienstinstanz einem Dienstanmeldungskonto zuzuordnen. Dieser Zuordnungsprozess ermöglicht es einer Clientanwendung, den Dienst anzufordern, ein Konto zu authentifizieren, auch wenn der Client keinen Kontonamen hat.

Ein typischer SPN für einen Server, auf dem eine Instanz von SQL Server ausgeführt wird, lautet beispielsweise wie folgt:

MSSQLSvc/SQLSERVER1.northamerica.corp.mycompany.com:1433

Das Format eines SPN für eine Standardinstanz entspricht einem SPN für eine benannte Instanz. Die Portnummer verknüpft den SPN mit einer bestimmten Instanz. Weitere Informationen zum Registrieren SQL Server Dienst-SPNs finden Sie unter Registrieren eines Dienstprinzipalnamens für Kerberos-Verbindungen.

Warum verwendet SSPI die NTLM- oder Kerberos-Authentifizierung?

Windows-Authentifizierung ist die bevorzugte Methode für Benutzer, sich bei SQL Server zu authentifizieren. Clients, die Windows-Authentifizierung verwenden, werden mit NTLM oder Kerberos authentifiziert.

Wenn ein SQL Server-Client integrierte Sicherheit über TCP/IP-Sockets auf einem Remoteserver verwendet, auf dem SQL Server ausgeführt wird, verwendet die SQL Server Clientnetzwerkbibliothek die SSPI-API, um die Sicherheitsdelegierung durchzuführen. Der SQL Server Netzwerkclient ruft die AcquireCredentialsHandle-Funktion auf und übergibt "negotiate" für den pszPackage Parameter. Dieser Prozess benachrichtigt den zugrunde liegenden Sicherheitsanbieter, die Delegierung auszuhandeln. In diesem Kontext bedeutet "Aushandeln" das Testen der Kerberos- oder NTLM-Authentifizierung auf Windows-basierten Computern. Mit anderen Worten: Windows verwendet kerberos-Delegierung, wenn dem Zielcomputer, auf dem SQL Server ausgeführt wird, ein zugeordnetes und ordnungsgemäß konfiguriertes SPN vorhanden ist. Andernfalls verwendet Windows NTLM-Delegierung. Wenn der SQL Server Client eine lokale Verbindung auf demselben Computer herstellt, auf dem sich SQL Server befindet, wird NTLM immer verwendet.

Warum schlägt die Verbindung nicht zu NTLM fehl, nachdem Probleme mit Kerberos aufgetreten sind?

Der SQL Server Treibercode auf dem Client verwendet die WinSock-Netzwerk-API, um das vollqualifizierte DNS des Servers aufzulösen, wenn der Treiber Windows-Authentifizierung verwendet, um eine Verbindung mit SQL Server herzustellen. Um diesen Vorgang auszuführen, ruft der Treibercode die WinSock-APIs und gethostbyaddr die gethostbyname WinSock-APIs auf. Wenn integrierte Sicherheit verwendet wird, versucht der Treiber, das vollqualifizierte DNS des Servers aufzulösen, auch wenn eine IP-Adresse oder ein Hostname als Name des Servers übergeben wird.

Wenn der SQL Server Treiber auf dem Client das vollqualifizierte DNS des Servers auflöst, wird das entsprechende DNS verwendet, um den SPN für den Server zu bilden. Daher können Probleme beim Beheben der IP-Adresse oder des Hostnamens in einem vollqualifizierten DNS durch WinSock dazu führen, dass der SQL Server Treiber einen ungültigen SPN für den Server erstellt.

Beispielsweise kann der clientseitige SQL Server-Treiber als vollqualifiziertes DNS verwendet werden, um ungültige SPNs wie folgt aufzulösen:

  • MSSQLSvc/SQLSERVER1:1433
  • MSSQLSvc/123.123.123.123:1433
  • MSSQLSvc/SQLSERVER1.antartica.corp.mycompany.com:1433
  • MSSQLSvc/SQLSERVER1.dns.northamerica.corp.mycompany.com:1433

Wenn der SQL Server-Treiber einen ungültigen SPN bildet, funktioniert die Authentifizierung weiterhin, da die SSPI-Schnittstelle versucht, den SPN im Active Directory-Dienst nachzuschlagen. Wenn die SSPI-Schnittstelle den SPN nicht findet, wird die Kerberos-Authentifizierung nicht ausgeführt. An diesem Punkt wechselt die SSPI-Ebene in den NTLM-Authentifizierungsmodus, und die Anmeldung verwendet die NTLM-Authentifizierung und ist in der Regel erfolgreich. Wenn der SQL Server-Treiber einen gültigen SPN bildet, der dem entsprechenden Container nicht zugewiesen ist, versucht der Treiber den SPN, kann ihn aber nicht verwenden. In diesem Fall kann der Fehler "SSPI-Kontext kann nicht generiert werden" auftreten. Wenn das SQL Server Startkonto ein lokales Systemkonto ist, ist der entsprechende Container der Computername. Für jedes andere Konto ist der entsprechende Container das SQL Server Startkonto. Die Authentifizierung verwendet den ersten gefundenen SPN. Stellen Sie daher sicher, dass falschen Containern keine SPNs zugewiesen sind. Mit anderen Worten, jeder SPN darf nur einem Container zugewiesen werden.

Wie kann ich die Authentifizierungsmethode der Verbindung überprüfen?

Führen Sie die folgende Abfrage aus, um die Authentifizierungsmethode einer Verbindung zu ermitteln:

SELECT net_transport, auth_scheme   
FROM sys.dm_exec_connections   
WHERE session_id = @@SPID;  

Weitere Informationen finden Sie unter Ermitteln, ob ich mit SQL Server mithilfe der Kerberos-Authentifizierung verbunden bin.

Wie erstellen Sie SPNs für SQL Server?

Wenn eine Instanz des SQL Server-Datenbankmoduls gestartet wird, versucht SQL Server, den SPN für den SQL Server-Dienst automatisch mithilfe der DsWriteAccountSpn-API zu registrieren. Dieser Aufruf ist erfolgreich, wenn das SQL Server Dienstkonto lese- und schreibgeschützt servicePrincipalName in Active Directory istservicePrincipalName. Andernfalls benötigen Sie Ihren Active Directory-Administrator, um den richtigen SPN manuell mithilfe von Microsoft Kerberos Manager für SQL Server oder das integrierte Setspn-Tool zu registrieren. Weitere Informationen zum Verwalten von SPNs für SQL Server finden Sie unter Registrieren eines Dienstprinzipalnamens für Kerberos-Verbindungen.

Hinweis

Dieses Verfahren gilt nur für Situationen, in denen Sie diese Fehlermeldungen ständig und nicht zeitweise erhalten.

Es gibt verschiedene Gründe, warum Kerberos-Verbindungen fehlschlagen, z. B. falsch konfigurierte SPNs, Probleme bei der Namensauflösung oder unzureichende Rechte für SQL Server Dienststartkonten. Microsoft Kerberos Configuration Manager (KCM) ist ein Tool, mit dem die Fehlerursachen überprüft werden können. KCM bietet auch Optionen, um alle identifizierten Probleme im Prozess zu beheben.

Führen Sie die folgenden Schritte aus, um den Fehler mithilfe von KCM zu beheben.

  1. Laden Sie kerberos-Configuration Manager auf dem Computer herunter, auf dem Die Verbindungsprobleme auftreten.

  2. Starten SieKerberosConfigMgr.exe aus dem Ordner "%SystemDrive%:\Programme\Microsoft\Kerberos Configuration Manager". Verwenden Sie dann ein Domänenkonto, das über Berechtigungen zum Herstellen einer Verbindung mit dem SQL Server Computer verfügt, mit dem Sie keine Verbindung herstellen können.

  3. Wählen Sie "Verbinden" aus, und lassen Sie den Servernamen und andere Details für Ihr Szenario leer, wenn Sie KCM auf dem SQL Server Computer ausführen. Wählen Sie "Verbinden " aus, um die Analyse auszuführen. Nachdem KCM die erforderlichen Informationen abgerufen hat, wechselt es automatisch zur Registerkarte SPN und zeigt standardmäßig Informationen für SQL Server, SQL Server Reporting Services, Analysis Services und AG Listener an. Deaktivieren Sie alles außer SQL Server, um diesen Fehler zu beheben.

  4. Überprüfen Sie die Diagnose des Tools mithilfe der Spalte "Status" , und führen Sie die entsprechenden Schritte aus, um das Problem zu beheben:

    Status Weitere Informationen Aktion
    gut Das überprüfte Element ist ordnungsgemäß konfiguriert. Sie können mit dem nächsten Element in der Ausgabe fortfahren. Keine Aktion erforderlich
    Erforderliches SPN fehlt Dieser Status wird gemeldet, wenn der in der Spalte "Erforderlicher SPN" identifizierte SPN für das SQL Server Startkonto im Active Directory fehlt. 1. Wählen Sie "Korrigieren " aus, um die Informationen im Dialogfeld "Warnung " zu überprüfen.
    2. Wählen Sie "Ja " aus, um den fehlenden SPN zu Active Directory hinzuzufügen.
    3. Wenn Ihr Domänenkonto über die erforderlichen Berechtigungen zum Aktualisieren von Active Directory verfügt, wird der erforderliche SPN zu Active Directory hinzugefügt.
    4. Wenn Ihr Domänenkonto nicht über die erforderlichen Berechtigungen zum Aktualisieren von Active Directory verfügt, verwenden Sie " Alle generieren" oder " Alle generieren ", um das Skript zu generieren, das dem Active Directory-Administrator hilft, die fehlenden SPNs hinzuzufügen.
    5. Nachdem die SPNs hinzugefügt wurden, führen Sie Kerberos Configuration Manager erneut aus, um zu überprüfen, ob die SPN-Probleme behoben sind.
    TCP muss für die Verwendung der Kerberos-Konfiguration aktiviert sein Dies tritt auf, wenn TCP auf dem Clientcomputer nicht aktiviert ist. Führen Sie die folgenden Schritte aus, um das TCP/IP-Protokoll für die SQL Server Instanz zu aktivieren:
    1. Erweitern Sie in SQL Server-Konfigurations-Manager im Konsolenbereich SQL Server Netzwerkkonfiguration.
    2. Wählen Sie im Konsolenbereich "Protokolle für" aus <instance name>.
    3. Klicken Sie im Detailbereich mit der rechten Maustaste auf TCP/IP, und wählen Sie dann "Aktivieren" aus.
    4. Wählen Sie im Konsolenbereich SQL Server Dienste aus.
    5. Klicken Sie im Detailbereich mit der rechten Maustaste auf SQL Server (<instance name>), und wählen Sie dann "Neu starten" aus, um den SQL Server Dienst zu beenden und neu zu starten.
    Weitere Informationen finden Sie unter Aktivieren oder Deaktivieren eines Servernetzwerkprotokolls.
    Dynamischer Port Diese Meldung wird für benannte Instanzen angezeigt, die dynamische Ports verwenden (Standardkonfiguration). In Umgebungen, in denen Sie Kerberos zum Herstellen einer Verbindung mit SQL Server verwenden müssen, sollten Sie ihre benannte Instanz auf einen statischen Port festlegen und diesen Port beim Registrieren von SPN verwenden. Führen Sie die folgenden Schritte aus, um Ihre SQL Server Instanz für die Verwendung eines statischen Ports zu konfigurieren:
    1. Erweitern Sie in SQL Server-Konfigurations-Manager im Konsolenbereich SQL Server Netzwerkkonfiguration, erweitern Sie Protokolle für <instance name>, und doppelklicken Sie dann auf TCP/IP.
    2. Überprüfen Sie im Dialogfeld "TCP/IP-Eigenschaften " die Einstellung " Alle überwachen " auf der Registerkarte " Protokoll ".
    3. Wenn die Einstellung " Alle abhören " auf "Ja" festgelegt ist, wechseln Sie zur Registerkarte "IP-Adressen ", und scrollen Sie zum unteren Rand von Windows, um die Einstellung "IPAll " zu finden. Löschen Sie den aktuellen Wert, der in den dynamischen TCP-Ports enthalten ist, und legen Sie den gewünschten Wert im TCP-Portfeld fest. Wählen Sie "OK" aus, und starten Sie die SQL Server Instanz neu, damit die Einstellungen wirksam werden.
    4. Wenn die Einstellung " Alle abhören " auf "Nein" festgelegt ist, wechseln Sie zur Registerkarte "IP-Adressen ", und überprüfen Sie jede der IP-Adressen, die in ip1, IP2 angezeigt werden. Entfernen Sie für aktivierte IP-Adressen den aktuellen Wert, der im Feld "Dynamische TCP-Ports " enthalten ist, und legen Sie den gewünschten Wert im Feld "TCP-Port " fest. Wählen Sie "OK" aus, und starten Sie die SQL Server Instanz neu, damit die Einstellungen wirksam werden.
    Weitere Informationen finden Sie unter Konfigurieren eines Servers zum Überwachen eines bestimmten TCP-Ports.
    SpN duplizieren Sie können feststellen, dass derselbe SPN unter verschiedenen Konten in Active Directory registriert ist. 1. Wählen Sie die Schaltfläche " Beheben ", zeigen Sie die Informationen im Dialogfeld "Warnung " an, und wählen Sie "Ja " aus, wenn Sie den fehlenden SPN zu Active Directory hinzufügen können.
    2. Wenn Ihr Domänenkonto über die erforderlichen Berechtigungen zum Aktualisieren von Active Directory verfügt, wird der falsche SPN gelöscht.
    3. Wenn Ihr Domänenkonto nicht über die erforderlichen Berechtigungen zum Aktualisieren von Active Directory verfügt, verwenden Sie die Schaltfläche "Generieren " oder " Alle generieren ", um das erforderliche Skript zu generieren, das Sie an Ihren Active Directory-Administrator übergeben können, um die doppelten SPNs zu entfernen. Nachdem die SPNs entfernt wurden, führen Sie das KCM erneut aus, um zu überprüfen, ob die SPN-Probleme behoben sind.

    Hinweis

    Wenn das Domänenkonto, das KCM startet, nicht berechtigt ist, SPNs in Active Directory zu bearbeiten, können Sie die entsprechende Schaltfläche " Generieren " oder " Alle generieren " unter der SpN-Skriptspalte verwenden, um die erforderlichen Befehle zu generieren und mit Ihrem Active Directory-Administrator zusammenzuarbeiten, um die von KCM identifizierten Probleme zu beheben.

  5. Nachdem Sie alle im KCM identifizierten Probleme behoben haben, führen Sie das Tool erneut aus. Stellen Sie sicher, dass keine weiteren Probleme gemeldet werden, und wiederholen Sie dann die Verbindung. Wenn das Tool weiterhin Probleme meldet, wiederholen Sie das vorherige Verfahren.

Beheben des Fehlers ohne Kerberos-Configuration Manager

Wenn Sie KCM nicht verwenden können, führen Sie die folgenden Schritte aus:

Schritt 1: Überprüfen der Namensauflösung mit dem Ping-Befehl

Der Schlüsselfaktor, der die Kerberos-Authentifizierung erfolgreich macht, ist die gültige DNS-Funktionalität im Netzwerk. Sie können diese Funktionalität auf dem Client und auf dem Server mithilfe des Ping Eingabeaufforderungshilfsprogramms überprüfen. Führen Sie auf dem Clientcomputer den folgenden Befehl aus, um die IP-Adresse des Servers abzurufen, auf dem SQL Server ausgeführt wird (wobei der Name des Computers lautetSQLServer1):

ping sqlserver1

Führen Sie den folgenden Befehl aus, um festzustellen, ob das Ping-Dienstprogramm das vollqualifizierte DNS von SQLServer1aufgelöst hat:

ping -a <IPAddress>

Zum Beispiel:

C:\>ping SQLSERVER1

Pinging SQLSERVER1 [123.123.123.123] with 32 bytes of data:

Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128

Ping statistics for 123.123.123.123:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum =  0ms, Average =  0ms 
C:\>ping -a 123.123.123.123

Pinging SQLSERVER1.northamerica.corp.mycompany.com [123.123.123.123] with 32 bytes of data:

Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Ping statistics for 123.123.123.123:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum =  0ms, Average =  0ms

C:\> 

Wenn der Befehl ping -a <IPAddress> in das richtige vollqualifizierte DNS des Computers aufgelöst wird, auf dem SQL Server ausgeführt wird, ist auch die clientseitige Auflösung erfolgreich.

Verwenden Sie für detaillierte Diagnosen entweder das Cmdlet "Test-NetConnection " oder "Test-Connection", um die TCP-Konnektivität gemäß der powerShell-Version zu testen, die auf dem Computer installiert ist. Weitere Informationen zum PowerShell-Cmdlet finden Sie unter Cmdlet Overview.

Hinweis

Zu den Namensauflösungsmethoden können DNS-, WINS-, Hosts- und Lmhosts-Dateien gehören. Weitere Informationen zu Problemen bei der Namensauflösung und zur Problembehandlung finden Sie unter den folgenden Links:

Überprüfen Sie, ob Aliase für das Ziel SQL Server in SQL Server-Konfigurations-Manager und im SQL Server-Clientnetzwerkdienstprogramm vorhanden sind. Wenn ein solcher Alias vorhanden ist, stellen Sie sicher, dass er ordnungsgemäß konfiguriert ist, indem Sie Servernamen, Netzwerkprotokoll, Portnummer usw. überprüfen.

Schritt 2: Überprüfen der Kommunikation zwischen Domänen

Stellen Sie sicher, dass die Domäne, bei der Sie sich anmelden, mit der Domäne des Servers kommunizieren kann, auf dem SQL Server ausgeführt wird. Es muss auch eine korrekte Namensauflösung in der Domäne vorhanden sein.

  1. Stellen Sie sicher, dass Sie sich bei Windows anmelden können, indem Sie dasselbe Domänenkonto und Kennwort wie das SQL Server Dienststartkonto verwenden. Der SSPI-Fehler kann beispielsweise in einer der folgenden Situationen auftreten:

    • Das Domänenkonto ist gesperrt.
    • Sie haben den SQL Server Dienst nicht neu gestartet, nachdem das Kennwort des Kontos geändert wurde.
  2. Wenn sich Ihre Anmeldedomäne von der Domäne des Servers unterscheidet, auf dem SQL Server ausgeführt wird, überprüfen Sie die Vertrauensstellung zwischen den Domänen.

  3. Überprüfen Sie, ob sich die Domäne, zu der der Server gehört, und das Domänenkonto, mit dem Sie eine Verbindung herstellen, in derselben Gesamtstruktur befinden. Dieser Schritt ist erforderlich, damit SSPI funktioniert.

Schritt 3: Überprüfen SQL Server SPNs mithilfe der SQLCheck- und Setspn-Tools

Wenn Sie sich lokal beim SQL Server Computer anmelden können und Administratorzugriff haben, verwenden Sie SQLCheck aus dem Microsoft SQL Networking GitHub-Repository. SQLCheck stellt die meisten Informationen bereit, die für die Problembehandlung in einer Datei erforderlich sind. Weitere Informationen zur Verwendung des Tools und zu den gesammelten Informationen finden Sie auf der Startseite des Tools. Sie können auch die Seite mit den empfohlenen Voraussetzungen und Prüflisten überprüfen. Nachdem Sie die Ausgabedatei generiert haben, überprüfen Sie die SPN-Konfiguration für Ihre SQL Server Instanz im Abschnitt SQL Server Informationen der Ausgabedatei.

Beispiel für die Ausgabe:

Suggested SPN                                               Exists  Status              

----------------------------------------------------------  ------  ------------------- 

MSSQLSvc/testsqlsvr.corp.com:2000                           True    Okay                

MSSQLSvc/testsqlsvr.corp.com                                True    Okay                

MSSQLSvc/testsqlsvr:2000                                    False   SPN does not exist. 

MSSQLSvc/testsqlsvr                                         False   SPN does not exist. 

Verwenden Sie die obige Ausgabe, um die nächsten Schritte zu ermitteln (siehe Beispiele unten), und verwenden Sie das Setspn-Tool , um die erforderlichen Abhilfemaßnahmen zur Behebung von SPN-Problemen zu ergreifen.

Szenario Vorgeschlagene Aktion
SPN ist nicht vorhanden Fügen Sie die erforderlichen SPN(s) für Ihr SQL Server-Dienstkonto hinzu.
Doppelte SPNs Löschen Sie den SPN, der für Ihren SQL-Dienst unter dem falschen Konto registriert ist.
SPN unter falschem Konto Löschen Sie den registrierten SPN für Ihren SQL-Dienst unter dem falschen Konto, und registrieren Sie dann den SPN unter dem richtigen Dienstkonto.

Hinweis

  • Sie können den Abschnitt SQL Server Informationen der Ausgabedatei des SQLCheck-Tools überprüfen, um das Dienstkonto Ihrer SQL Server Instanz zu finden.

  • Setspn ist ein integriertes Tool in neueren Versionen von Windows, mit dem Sie SPNs in Active Directory lesen, hinzufügen, ändern oder löschen können. Mit diesem Tool können Sie überprüfen, ob SQL Server SPNs gemäß "Dienstprinzipalnamen für Kerberos-Verbindungen registrieren" konfiguriert sind. Weitere Informationen finden Sie im Setspn-Tool und in Beispielen zur Verwendung.

  • Weitere Informationen zu Szenarien, in denen SQL Server SPNs automatisch registriert und eine manuelle SPN-Registrierung erforderlich ist, finden Sie unter Registrieren eines Dienstprinzipalnamens für Kerberos-Verbindungen.

Schritt 4: Überprüfen der Kontoberechtigung für SQL Server Startkonto auf dem verknüpften Server

Wenn Sie "Identitätswechsel" als Authentifizierungsoption auf der Seite "Sicherheit" Ihres verknüpften Servers verwenden, ist SQL Server erforderlich, um eingehende Anmeldeinformationen an remote SQL Server zu übergeben. Dem SQL Server Startkonto, in dem der verknüpfte Server definiert ist, sollte das Konto als vertrauenswürdig für das Delegierungsrecht in Active Directory zugewiesen sein. Weitere Informationen finden Sie unter Aktivieren der Vertrauenswürdigung von Computer- und Benutzerkonten für die Delegierung.

Hinweis

Dieser Schritt ist nur erforderlich, wenn Sie Probleme im Zusammenhang mit verknüpften Serverabfragen behandeln.

Siehe auch