Unterstützung für Dienstprinzipalnamen (Service Principal Names, SPN) in Clientverbindungen im SQL Server Native Client

Gilt für: SQL Server Azure SQL-Datenbank Azure SQL Managed Instance Azure Synapse Analytics Analytics Platform System (PDW)

Wichtig

SQL Server Native Client (SNAC) wird nicht ausgeliefert mit:

• SQL Server 2022 (16.x) und höhere Versionen
• SQL Server Management Studio 19 und spätere Versionen

Der SQL Server Native Client (SQLNCLI oder SQLNCLI11) und der Microsoft OLE DB-Legacyanbieter für SQL Server (SQLOLEDB) werden für neue Anwendungsentwicklungen nicht empfohlen.

Für neue Projekte verwenden Sie einen der folgenden Treiber:

• Microsoft ODBC-Treiber für SQL Server
• Microsoft OLE DB-Treiber für SQL Server

Informationen zu SQLNCLI, das als Komponente der SQL Server-Datenbank-Engine (Versionen 2012 bis 2019) verfügbar ist, finden Sie in dieser Ausnahme für den Supportlebenszyklus.

Ab SQL Server 2008 (10.0.x) wurde die Unterstützung für Dienstprinzipalnamen (Service Principal Names, SPNs) erweitert und die gegenseitige Authentifizierung für alle Protokolle aktiviert. In vorherigen Versionen von SQL Server wurden SPNs nur für Kerberos statt TCP unterstützt, wenn der Standard-SPN der SQL Server-Instanz in Active Directory registriert wurde.

SPNs werden vom Authentifizierungsprotokoll verwendet, um das Konto zu bestimmen, in dem eine SQL Server-Instanz ausgeführt wird. Ist das Konto der Instanz bekannt, kann mithilfe der Kerberos-Authentifizierung die gegenseitige Authentifizierung von Client und Server durchgeführt werden. Ist das Konto der Instanz nicht bekannt, wird die NTML-Authentifizierung verwendet, die nur die Authentifizierung des Clients durch den Server durchführt. Derzeit führt SQL Server Native Client die Authentifizierungssuche durch und leitet den SPN von den Eigenschaften des Instanznamens und der Netzwerkverbindung ab. SQL Server-Instanzen versuchen, SPNs beim Start zu registrieren, oder sie können manuell registriert werden. Die Registrierung schlägt jedoch fehl, wenn das Konto, dass die Registrierung der SPNs vornimmt, nicht über ausreichende Zugriffsrechte verfügt.

Domänen- und Computerkonten werden automatisch in Active Directory registriert. Diese können als SPNs verwendet werden, oder Administratoren können ihre eigenen SPNs definieren. SQL Server ist einfacher zu verwalten und auch zuverlässiger, da Clients direkt den zu verwendenden SPN festlegen können.

Hinweis

Ein von einer Clientanwendung festgelegter SPN wird nur verwendet, wenn eine Verbindung mit integrierten Sicherheitsfunktionen von Windows hergestellt wird.

Tipp

Microsoft Kerberos Configuration Manager for SQL Server ist ein Diagnosetool zur Behebung Kerberos-bezogener Probleme mit der Verbindung mit SQL Server. Weitere Informationen finden Sie unter Microsoft Kerberos-Konfigurations-Manager für SQL Server.

Weitere Informationen zu Kerberos finden Sie in den folgenden Artikeln:

• Kerberos – Technische Ergänzungfür Windows

• Microsoft Kerberos

Verwendung

In der folgenden Tabelle werden die häufigsten Szenarien beschrieben, in denen Clientanwendungen die sichere Authentifizierung aktivieren können.

Szenario	Beschreibung
Eine ältere Anwendung gibt keinen SPN an.	Dieses Kompatibilitätsszenario stellt sicher, dass sich das Verhalten von Anwendungen, die für frühere Versionen von SQL Serverentwickelt wurden, nicht verändert. Wenn kein SPN angegeben wurde, verwendet die Anwendung generierte SPNs und erkennt nicht, welche Methode zur Authentifizierung verwendet wurde.
Eine Clientanwendung, die die aktuelle Version von SQL Server Native Client verwendet, gibt einen SPN im Verbindungszeichenfolge als Domänenbenutzer- oder Computerkonto, als instanzspezifische SPN oder als benutzerdefinierte Zeichenfolge an.	Das ServerSPN -Schlüsselwort kann von einem Anbieter, einer Initialisierung oder einer Verbindungszeichenfolge zu folgenden Zwecken verwendet werden: - Angeben des von der SQL Server-Instanz verwendeten Kontos. Dies vereinfacht den Zugriff auf die Kerberos-Authentifizierung. Wenn ein Kerberos-Schlüsselverteilungscenter (Key Distribution Center, KDC) vorhanden ist und das richtige Konto angegeben wurde, wird wahrscheinlich die Kerberos- anstatt der NTLM-Authentifizierung durchgeführt. Das KDC befindet sich normalerweise auf dem gleichen Computer wie der Domänencontroller. - Angeben eines SPNs, um nach dem Dienstkonto der SQL Server-Instanz zu suchen. Für jede SQL Server-Instanz werden zwei Standard-SPNs generiert, die für diesen Zweck verwendet werden können. Diese Schlüssel sind jedoch nicht unbedingt in Active Directory vorhanden. Daher ist in dieser Situation die Kerberos-Authentifizierung nicht gewährleistet. - Angeben eines SPN, der für die Suche nach dem Dienstkonto der SQL Server-Instanz verwendet werden soll. Dies kann eine beliebige benutzerdefinierte Zeichenfolge sein, die dem Dienstkonto zugeordnet wird. In diesem Fall muss der Schlüssel im KDC manuell registriert werden und den Richtlinien für einen benutzerdefinierten SPN entsprechen. Das FailoverPartnerSPN -Schlüsselwort kann verwendet werden, um den SPN für den Failoverpartnerserver anzugeben. Der Wertebereich des Kontos und des Active Directory-Schlüssels entspricht den Werten, die Sie für den Prinzipalserver angeben können.
Eine ODBC-Anwendung legt einen SPN als Verbindungsattribut für den Prinzipalserver oder Failoverpartnerserver fest.	Das Verbindungsattribut SQL_COPT_SS_SERVER_SPN kann zur Festlegung des SPN für eine Verbindung zum Prinzipalserver verwendet werden. Das Verbindungsattribut SQL_COPT_SS_FAILOVER_PARTNER_SPN kann zur Festlegung des SPN für eine Verbindung zum Failoverpartnerserver verwendet werden.
Eine OLE DB-Anwendung legt einen SPN als Initialisierungseigenschaft der Datenquelle für den Prinzipalserver oder einen Failoverpartnerserver fest.	Die Verbindungseigenschaft SSPROP_INIT_SERVER_SPN im DBPROPSET_SQLSERVERDBINIT -Eigenschaftensatz kann zur Festlegung des SPN für eine Verbindung verwendet werden. Die Verbindungseigenschaft SSPROP_INIT_FAILOVER_PARTNER_SPN in DBPROPSET_SQLSERVERDBINIT kann zur Festlegung des SPN für eine Verbindung zum Failoverpartnerserver verwendet werden.
Ein Benutzer legt einen SPN für einen Server oder Failoverpartnerserver in einem ODBC-Datenquellenamen (Data Source Name, DSN) fest.	Der SPN kann in einem ODBC DSN durch die DSN-Setupdialogfelder angegeben werden.
Der Benutzer legt einen SPN für einen Server oder Failoverpartnerserver in den OLE DB-Dialogfeldern Datenlink oder Anmeldung fest.	Der SPN kann im Dialogfeld Datenlinks oder Anmeldung angegeben werden. Das Dialogfeld Anmeldung kann mit entweder ODBC oder OLE DB verwendet werden.
Eine ODBC-Anwendung bestimmt die Authentifizierungsmethode, die zum Herstellen einer Verbindung verwendet wird.	Wenn eine Verbindung erfolgreich hergestellt wurde, kann eine Anwendung das Verbindungsattribut SQL_COPT_SS_INTEGRATED_AUTHENTICATION_METHOD abfragen, um festzustellen, welche Authentifizierungsmethode verwendet wurde. Die Werte enthalten unter anderem NTLM und Kerberos.
Eine OLE DB-Anwendung bestimmt die Authentifizierungsmethode, die zum Herstellen einer Verbindung verwendet wird.	Wenn eine Verbindung erfolgreich hergestellt wurde, kann eine Anwendung die Verbindungseigenschaft SSPROP_AUTHENTICATION_METHOD im DBPROPSET_SQLSERVERDATASOURCEINFO -Eigenschaftensatz abfragen, um festzustellen, welche Authentifizierungsmethode verwendet wurde. Die Werte enthalten unter anderem NTLM und Kerberos.

Failover

SPNs werden nicht im Failovercache gespeichert und daher nicht zwischen Verbindungen übergeben. SPNs werden bei allen Verbindungsversuchen mit dem Prinzipal und dem Partner verwendet, wenn Sie in der Verbindungszeichenfolge oder in den Verbindungsattributen angegeben sind.

Verbindungspooling

Wenn SPNs nur in einigen, aber nicht in allen Verbindungszeichenfolgen angegeben werden, kann dies zur Poolfragmentierung führen.

Anwendungen können SPNs programmgesteuert als Verbindungsattribute festlegen, anstatt Schlüsselwörter für Verbindungszeichenfolgen anzugeben. Dadurch kann die Fragmentierung beim Verbindungspooling besser gesteuert werden.

SPNs in Verbindungszeichenfolgen können durch Festlegen der entsprechenden Verbindungsattribute überschrieben werden, aber Verbindungszeichenfolgen, die vom Verbindungspooling verwendet werden, verwenden die Verbindungszeichenfolgenwerte für Poolingzwecke.

Downlevelserver-Verhalten

Das neue Verbindungsverhalten wird vom Client implementiert; daher ist es nicht spezifisch für eine Version von SQL Server.

Verbindungsserver und Delegierung

Beim Einrichten von Verbindungsservern wird der @provstr -Parameter von sp_addlinkedserver verwendet, um den SPN für den Server und Failoverpartner festzulegen. Diese Vorgehensweise hat den gleichen Vorteil wie das Festlegen von SPNs in Clientverbindungszeichenfolgen: Es ist einfacher und zuverlässiger, Verbindungen mit Kerberos-Authentifizierung herzustellen.

Delegierung über Verbindungsserver erfordert die Kerberos-Authentifizierung.

Verwaltungsaspekte von SPNs, die von Anwendungen angegeben werden

Berücksichtigen Sie die folgenden Faktoren bei der Entscheidung, ob SPNs in einer Anwendung (über Verbindungszeichenfolgen) oder programmgesteuert über Verbindungseigenschaften (anstatt sich auf den standardmäßig vom Anbieter erstellten SPN zu verlassen) angegeben werden.

• Sicherheit: Legt der angegebene SPN geschützte Informationen offen?

• Zuverlässigkeit: Zur Aktivierung von Standard-SPNs muss das Dienstkonto der Instanz von SQL Server über ausreichende Privilegien zum Update von Active Directory auf dem Schlüsselverteilungscenter verfügen.

• Benutzerfreundlichkeit und Speicherorttransparenz: Wie wirkt es sich auf die SPNs einer Anwendung aus, wenn die Datenbank in eine andere Instanz von SQL Server verschoben wird? Dies gilt für sowohl den Prinzipalserver als auch seinen Failoverpartner, wenn Sie die Datenbankspiegelung verwenden. Wie wirkt es sich auf Anwendungen aus, wenn eine Serveränderung bedeutet, dass SPNs geändert werden müssen? Werden die Änderungen verwaltet?

Angeben des SPN

Sie können einen SPN in Dialogfeldern und Code angeben. In diesem Abschnitt wird erläutert, wie Sie einen SPN angeben können.

Die maximale Länge für einen SPN beträgt 260 Zeichen.

Die Syntax, die SPNs in Attributen für Verbindungszeichenfolgen und Verbindungen verwenden, lautet wie folgt:

Syntax	BESCHREIBUNG
MSSQLSvc/fqdn	Der vom Anbieter erstellte Standard-SPN für eine Standardinstanz, wenn ein anderes Protokoll als TCP verwendet wird. fqdn ist ein vollqualifizierter Domänenname.
MSSQLSvc/fqdn:port	Der vom Anbieter erstellte Standard-SPN, wenn TCP verwendet wird. port ist eine TCP-Portnummer.
MSSQLSvc/fqdn:InstanceName	Der vom Anbieter erstellte Standard-SPN für eine benannte Instanz, wenn ein anderes Protokoll als TCP verwendet wird. InstanceName ist ein Instanzname von SQL Server.
HOST/fqdn HOST/MachineName	Der SPN, der integrierten Computerkonten zugeordnet wird, die automatisch von Windows registriert werden.
Username@Domain	Direkte Spezifikation eines Domänenkontos. Username ist der Name des Windows-Benutzerkontos. Domain ist ein Windows-Domänenname oder ein vollqualifizierter Domänenname.
MachineName$@Domain	Ein Computerkonto wird direkt angegeben. (Wenn der Server, zu dem Sie eine Verbindung herstellen, unter den Konten LOCAL SYSTEM oder NETWORK SERVICE ausgeführt wird, kann ServerSPN zum Einrichten der Kerberos-Authentifizierung im Format MachineName$@Domain angegeben werden.)
KDCKey/MachineName	Ein vom Benutzer angegebener SPN. KDCKey ist eine alphanumerische Zeichenfolge, die den Regeln für einen KDC-Schlüssel entspricht.

SPNs, die ODBC und OLE DB-Syntax unterstützen

Informationen zur Syntax finden Sie in den folgenden Themen:

• Dienstprinzipalnamen (SPN) in Clientverbindungen (ODBC)

• Dienstprinzipalnamen (SPN) in Clientverbindungen (OLE DB)

Weitere Informationen

SQL Server Native Client-Funktionen
Registrieren eines Dienstprinzipalnamens für Kerberos-Verbindungen