Unterstützung von Dienstprinzipalnamen (SPN) in Clientverbindungen
Ab SQL Server 2008 wurde die Unterstützung für Dienstprinzipalnamen (Service Principal Names, SPNs) erweitert und die gegenseitige Authentifizierung über alle Protokolle hinweg 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. Die Authentifizierungssuche wird derzeit vom SQL Server Native Client ausgeführt. Der SPN wird vom Instanznamen und den Netzwerkverbindungseigenschaften abgeleitet. Instanzen von SQL Server 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. Die sichere Authentifizierung in SQL Server 2008 ist einfacher zu verwalten und auch zuverlässiger, da Clients direkt den zu verwendenden SPN festlegen können.
.gif "Hinweis") Hinweis |
|---|
Ein von einer Clientanwendung festgelegter SPN wird nur verwendet, wenn eine Verbindung mit integrierten Sicherheitsfeatures von Windows NT hergestellt wird. |
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 Server entwickelt 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 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 zu folgenden Zwecken verwendet werden:
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 aufgehoben werden, aber Verbindungszeichenfolgen, die vom Verbindungspooling verwendet werden, verwenden die Verbindungszeichenfolgenwerte für Poolingzwecke.
Serververhalten früherer Versionen
Das neue Verbindungsverhalten ist clientseitig implementiert und 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 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.
Eine Liste der Anforderungen finden Sie unter Konfigurieren von Verbindungsservern für die Delegierung.
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 zur Aktualisierung 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:
Informationen zu Beispielanwendungen, die dieses Feature veranschaulichen, finden Sie unter Überlegungen zum Installieren der SQL Server-Beispiele und -Beispieldatenbanken.