Unterstützung von Dienstprinzipalnamen (SPN) in Clientverbindungen

Artikel
05/23/2023

Gilt für: SQL Server

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 NTLM-Authentifizierung verwendet, die nur die Authentifizierung des Clients durch den Server durchführt. Die Authentifizierungssuche wird derzeit vom OLE DB-Treiber für SQL Server durchgeführt. Der SPN wird vom Instanznamen und den Netzwerkverbindungseigenschaften abgeleitet. 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 Konten können als SPNs verwendet werden. Administratoren können auch eigene 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:

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 OLE DB-Treiber für SQL Server verwendet, gibt in der Verbindungszeichenfolge einen SPN als Domänenbenutzerkonto oder Computerkonto, als instanzabhängigen SPN oder als benutzerdefinierte Zeichenfolge an.	Das ServerSPN -Schlüsselwort kann von einem Anbieter, einer Initialisierung oder einer Verbindungszeichenfolge verwendet werden, um die folgenden Werte anzugeben: - Angeben des von der SQL Server-Instanz verwendeten Kontos. Diese Einstellung 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 die Kerberos-Authentifizierung in dieser Situation nicht gewährleistet. - Angeben eines SPN, der für die Suche nach dem Dienstkonto der SQL Server-Instanz verwendet werden soll. Dieser Wert 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 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.
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.
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. Mithilfe dieser Methode 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, und ist daher kein spezifisches Verhalten 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 Methode 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 die standardmäßig vom Anbieter erstellten SPNs 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? Dieses Konzept gilt für sowohl den Prinzipalserver als auch seinen Failoverpartner, wenn Datenbankspiegelung verwendet wird. 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.

OLE DB-Syntax, die SPN unterstützt

Informationen zur Syntax finden Sie in den folgenden Artikeln:

Dienstprinzipalnamen (SPN) in Clientverbindungen (OLE DB)

Weitere Informationen

OLE DB-Treiber für SQL Server-Features
Registrieren eines Dienstprinzipalnamens für Kerberos-Verbindungen

Teilen über