Registrieren von Kerberos-Dienstprinzipalnamen (Service Principal Names, SPNs) mithilfe von Http.sys
Diese Funktion wird in zukünftigen Versionen von Microsoft SQL Server nicht mehr bereitgestellt. Verwenden Sie diese Funktion beim Entwickeln neuer Anwendungen nicht, und planen Sie das Ändern von Anwendungen, in denen es zurzeit verwendet wird.
Wenn Sie HTTP-Endpunkte mithilfe von CREATE ENDPOINT oder ALTER ENDPOINT erstellen oder ändern, geben Sie den Authentifizierungstyp an, der zum Authentifizieren von Benutzern verwendet wird, die HTTP SOAP-Anforderungen an den Endpunkt senden. Weitere Informationen finden Sie unter CREATE ENDPOINT (Transact-SQL) und ALTER ENDPOINT (Transact-SQL).
Mithilfe von CREATE ENDPOINT ALTER ENDPOINT können Sie Endpunkte für die Unterstützung von Kerberos-Authentifizierung auf folgende Art konfigurieren:
Durch Festlegen von AUTHENTICATION=KERBEROS wird Kerberos als einziges Mittel der HTTP-Authentifizierung verwendet.
Wenn AUTHENTICATION=INTEGRATED festgelegt wird, kann die HTTP-Authentifizierung für den Endpunkt die folgenden Optionen als Teil der Authentifizierungsanfrage bereitstellen: NEGOTIATE, KERBEROS und NTLM. Für die NEGOTIATE-Option versuchen der Client und der Server, auf Kerberos basierende Authentifizierung einzurichten. Wenn Kerberos nicht vom Client unterstützt wird oder die Aushandlung nicht möglich ist, wird für die Authentifizierung auf NTLM zurückgegriffen. Damit verhindert wird, dass der Client auf NTLM zurückgreift, wenn Sie NEGOTIATE verwenden, wird empfohlen, dass der Client AUTHENTICATION=KERBEROS für den Endpunkt festlegt.
Damit die gegenseitige Authentifizierung unter Kerberos unterstützt wird, muss die Instanz von SQL Server 2005 oder SQL Server 2008 dem Konto, unter dem sie ausgeführt wird (z. B. einem lokalen Systemkonto oder einem Domänenbenutzerkonto), einen Dienstprinzipalnamen (Service Principal Name, SPN) zuordnen. Die genauen Einzelheiten für die SPN-Registrierung durch eine bestimmte Instanz von SQL Server werden durch den Typ des Dienstkontos angegeben, unter dem sie konfiguriert wurde. Wenn SQL Server unter dem lokalen Systemkonto oder Netzwerkdienstkonto ausgeführt wird, müssen die SPNs unter dem Computernamen registriert werden. Wenn SQL Server unter einem Domänenbenutzerkonto ausgeführt wird, müssen die SPNs unter dem Domänenbenutzernamen registriert werden.
Verwenden von SetSPN.exe
Um die Zuordnung eines SPNs zu dem Konto zu ermöglichen, unter dem die Instanz von SQL Server 2005 oder SQL Server 2008 ausgeführt wird, verwenden Sie das Windows-Supporttool SetSPN.exe. Dieses Tool fügt den SPN für den Computernamen, für den die Instanz von SQL Server ausgeführt wird, unter dem Benutzerkonto des Windows-Domänendiensts in Active Directory hinzu. In diesem Szenario kann das Tool SetSPN.exe zum Hinzufügen von zwei SPNs verwendet werden: ein SPN für den NetBIOS-Namen und ein SPN für den vollqualifizierten DNS-Namen.
Wenn das Tool SetSPN.exe aus der Instanz von SQL Server ausgeführt wird, die für MyComputer ausgeführt wird, werden die beiden folgenden SPNs dem Konto zugeordnet, unter dem die Ausführung der Instanz von SQL Server erfolgt. Sie müssen folgendem Verzeichnis hinzugefügt werden:
HTTP/MyComputer;
HTTP/MyComputer.fully.qualified.domain.name.com
Beachten Sie, dass ein Konto über mehrere SPNs verfügen kann, ein SPN jedoch nur für ein Konto registriert werden kann.
Wenn Sie diese beiden gleichen SPN-Namen (den NetBIOS- und den vollqualifizierten DNS-Namen) löschen möchten, verwenden Sie ebenfalls das Tool SetSPN.exe.
Weitere Überlegungen
Ähnlich wie Httpcfg.exe ist auch SetSPN.exe in Windows Server 2003 enthalten und wird installiert, wenn Sie das gleiche Verfahren wie zum Installieren von Httpcfg.exe und anderen Windows-Supporttools verwenden. Weitere Informationen finden Sie unter Konfigurieren des Kernel-Modus-HTTP-Treibers (Http.sys).
Wenn eine Instanz von SQL Server nicht als lokales Systemkonto ausgeführt wird, können nur Benutzer der integrierten Authentifizierung, die über DOMAIN ADMIN-Privilegien verfügen, die SPN-Registrierung mithilfe des Tools SetSPN.exe ändern.
Wenn eine Instanz von SQL Server als lokales Systemkonto ausgeführt wird, können nur Mitglieder der festen SQL Server-Serverrolle sysadmin die SPN-Registrierung mithilfe des Tools SetSPN.exe ändern.
Wenn es sich bei dem Dienstkonto um Local System handelt, wird der SPN in dem Active Directory-Konto des Computers hinzugefügt, ohne dass das Tool SetSPN.exe verwendet werden muss.
Syntax für SetSPN.exe
Die Syntax für SetSPN.exe lautet folgendermaßen:
setspn { -ASPN | -DSPN | -L } service_account
Argumente
-A
Fügt dem Konto den angegebenen SPN hinzu.-D
Löscht den angegebenen SPN für das Konto.-L
Listet alle SPNs auf, die für das Konto registriert sind.
Beispiele
Wenn eine Instanz von SQL Server als Domänenbenutzer (MyDomain\MySQLAccount) auf einem Computer ausgeführt wird, der den Namen MySQLHost trägt, können die folgenden Befehle zum Festlegen der entsprechenden SPNs verwendet werden:
setspn –A http/MySQLHost MyDomain\MySQLAccount
setspn –A http/MySqlHost.Mydomain.Mycorp.com MyDomain\MySQLAccount
Beachten Sie, dass ein Konto über mehrere SPNs verfügen kann (einen für jeden Dienst- oder Hostnamen), ein SPN jedoch nur unter einem Konto registriert werden kann. Wenn der gleiche SPN für mehrere Konten registriert wird, erzeugt die Kerberos-Authentifizierung einen Fehler.
Für das Konto MyDomain\MySQLAccount können z. B. die folgenden unterschiedlichen SPNs registriert sein. Die ersten beiden Befehle beziehen sich auf zwei verschiedene Dienste (http und rpc). Der letzte Befehl bezieht sich auf einen anderen Hostnamen (in diesem Beispiel wird davon ausgegangen, dass der Computer mehrere Hostnamen besitzt).
setspn –A http/MySQLHost MyDomain\MySQLAccount
setspn –A rpc/MySQLHost MyDomain\MySQLAccount
setspn –A http/MySecondHost MyDomain\MySQLAccount
Das folgende Szenario führt jedoch zu einem Kerberos-Fehler:
setspn –A http/MySQLHost MyDomain\MySQLAccountOne
setspn –A http/MySQLHost MyDomain\MySQLAccountTwo
Der Fehler tritt auf, weil zwei Instanzen von SQL Server auf einem Computer vorhanden sind, der unter zwei verschiedenen Dienstkonten (MySQLAccountOne und MySQLAccountTwo) ausgeführt wird. Das Registrieren beider SPNs (eines SPNs für jede Instanz von SQL Server) ist kein unterstütztes Szenario.
Dieser Umstand besitzt Auswirkungen, wenn mehrere Instanzen von SQL Server auf dem gleichen Computer unter verschiedenen Konten ausgeführt werden. Der SPN kann nur für ein Konto registriert werden. Wenn mehrere Instanzen von SQL Server (z. B. Inst1 und Inst2) neben anderen Anwendungen (wie z. B. IIS) gleichzeitig vorhanden sein müssen und Sie HTTP Kerberos-Authentifizierung für alle Dienste verwenden möchten, verwenden Sie eine der folgenden Optionen, um die SPN-Registrierungskonflikte zu beheben:
Lassen Sie die Ausführung aller Instanzen und Anwendungen unter dem gleichen Konto erfolgen.
Führen Sie Inst1, Inst2 und IIS z. B. als LocalSystem oder Mydomain\MyServiceAccount aus.
Registrieren Sie mehrere Hostnamen für den gleichen Computer, und führen Sie die Überwachung jeder Instanz und Anwendung auf einem anderen Host durch. In diesem Fall müssten Sie daher folgendermaßen vorgehen:
Erstellen Sie drei verschiedene Hostnamen für den Computer.
Weisen Sie jeden Host einer anderen Anwendung zu.
Registrieren Sie drei Gruppen von SPNs, eine für jede Kombination aus Hostname/Anwendung.
Problembehandlung von Kerberos-SPN-Registrierungsproblemen
Die folgenden Probleme bei der Kerberos-SPN-Registrierung treten häufig auf:
Ein SPN ist nicht registriert.
Wenn ein SPN nicht registriert ist, funktioniert die Kerberos-Authentifizierung von dem lokalen Computer aus, auf dem die Instanz von SQL Server ausgeführt wird, schlägt auf Remoteclientcomputern jedoch fehl.
Ein SPN wird mehrmals registriert.
Es sind verschiedene Szenarien denkbar, in denen ein Administrator die Dienstprinzipalnamen (Service Principal Names, SPNs) im Domänenverzeichnis mit der Auswirkung doppelt vergibt, dass die Kerberos-Authentifizierung einen Fehler erzeugt. Dabei handelt es sich z. B. um die folgenden Aktionen:
Vornehmen von Änderungen am Domänenkonto, unter dem die Instanz von SQL Server ausgeführt wird
Wenn SetSpn.exe ausgeführt wird, während eine Instanz von SQL Server als ein Domänenkonto (z. B. DOMAIN\User1) ausgeführt wird, und anschließend das Domänenkonto, das zum Ausführen von SQL Server verwendet wird (z. B. DOMAIN\User2), geändert wird, führt eine erneute Ausführung von SetSPN.exe dazu, dass der gleiche SPN in das Verzeichnis unter beiden Konten eingefügt wird.
Installieren mehrerer Instanzen von SQL Server, die unter verschiedenen Konten ausgeführt werden
Wenn Sie mehrere Instanzen von SQL Server installieren und dann jede dieser Instanzen unter einem anderen Konto ausführen, werden doppelte Konten im Verzeichnis unter jedem SQL Server-Dienstkonto erstellt, wenn SetSpn.exe für die einzelnen Instanzen ausgeführt wird. Dies gilt für Instanzen, die unter einem Domänenbenutzerkonto oder dem lokalen Systemkonto ausgeführt werden.
Entfernen und Neuinstallieren einer Instanz von SQL Server unter einem anderen Konto
Wenn Sie SQL Server unter einem Konto installieren, die SPNs registrieren, SQL Server entfernen und unter einem anderen Konto neu installieren und dann die SPNs erneut registrieren, verfügen die einzelnen Domänenkonten über die gleichen SPNs. Dies bedeutet, dass die SPNs doppelt vorhanden sind.
In jedem dieser Szenarien besteht das Problem darin, dass der HTTP-Endpunkt auf NTLM-Authentifizierung zurückgreift, bis das Problem behoben wurde. Zu diesem Zweck muss das Verzeichnis in der Regel nach doppelten oder veralteten SPNs durchsucht werden, um diese dann manuell zu entfernen.