Syntax von Verbindungszeichenfolgen

Artikel
05/23/2023

Gilt für: .NET Framework .NET .NET Standard

Microsoft.Data.SqlClient weist ein Connection-Objekt auf, das von DbConnection sowie einer anbieterspezifischen ConnectionString-Eigenschaft erbt. Die spezifische Syntax der Verbindungszeichenfolge für den SqlClient-Anbieter ist in dessen ConnectionString-Eigenschaft dokumentiert. Weitere Informationen zur Verbindungszeichenfolgensyntax finden Sie unter ConnectionString.

Verbindungszeichenfolgen-Generatoren

Der Microsoft SqlClient-Datenanbieter für SQL Server bietet nun den folgenden Verbindungszeichenfolgen-Generator.

SqlConnectionStringBuilder

Mit den Verbindungszeichenfolgen-Generatoren können Sie zur Laufzeit syntaktisch gültige Verbindungszeichenfolgen erstellen, sodass Sie die Werte der Verbindungszeichenfolgen nicht manuell im Code verketten müssen. Weitere Informationen finden Sie in Connection String Builders (Verbindungszeichenfolgengeneratoren).

Windows-Authentifizierung

Wir empfehlen die Verwendung der Windows-Authentifizierung (mitunter als integrierte Sicherheit bezeichnet) zum Herstellen einer Verbindung mit Datenquellen, die diese unterstützen. In der folgenden Tabelle wird die Syntax der Windows-Authentifizierung gezeigt, die für den Microsoft SqlClient-Datenanbieter für SQL Server genutzt wird.

Anbieter	Syntax
`SqlClient`	`Integrated Security=true;` `-- or --` `Integrated Security=SSPI;`

SqlClient-Verbindungszeichenfolgen

Die Syntax für eine SqlConnection-Verbindungszeichenfolge wird in der SqlConnection.ConnectionString-Eigenschaft dokumentiert. Mit der ConnectionString-Eigenschaft können Sie eine Verbindungszeichenfolge für eine SQL Server-Datenbank abrufen oder festlegen. Die Schlüsselwörter der Verbindungszeichenfolge werden außerdem Eigenschaften in SqlConnectionStringBuilder zugeordnet.

Wichtig

Die Standardeinstellung für das Schlüsselwort Persist Security Info ist false. Wenn die Einstellung in true bzw. yes geändert wird, sind sicherheitsrelevante Informationen, die über diese Verbindung übertragen werden, wie Benutzer-ID und Kennwort, nicht mehr sicher. Lassen Sie Persist Security Info auf false festgelegt, um sicherzustellen, dass eine nicht vertrauenswürdige Quelle keinen Zugriff auf sensible Informationen in Verbindungszeichenfolgen hat.

Windows-Authentifizierung mit SqlClient

Alle folgenden Syntaxformen verwenden beim Herstellen einer Verbindung mit der Datenbank AdventureWorks auf einem lokalen Server die Windows-Authentifizierung.

"Persist Security Info=False;Integrated Security=true;  
    Initial Catalog=AdventureWorks;Server=MSSQL1;Encrypt=True;"  
"Persist Security Info=False;Integrated Security=SSPI;  
    database=AdventureWorks;server=(local);Encrypt=True;"  
"Persist Security Info=False;Trusted_Connection=True;  
    database=AdventureWorks;server=(local);Encrypt=True;"

SQL Server-Authentifizierung mit SqlClient

Zum Herstellen einer Verbindung mit SQL Server ist vorzugsweise die Windows-Authentifizierung zu verwenden. Wenn jedoch die SQL Server-Authentifizierung erforderlich ist, verwenden Sie zum Angeben eines Benutzernamens und Kennworts die im Folgenden beschriebene Syntax. In diesem Beispiel werden der Benutzername und das Kennwort durch Sternchen dargestellt.

"Persist Security Info=False;User ID=*****;Password=*****;Initial Catalog=AdventureWorks;Server=MySqlServer;Encrypt=True;"

Wenn Sie eine Verbindung mit Azure SQL-Datenbank oder Azure Synapse Analytics herstellen und einen Benutzernamen im Format user@servername eingeben, stellen Sie sicher, dass der Wert servername im Benutzernamen mit dem für Server= angegebenen Wert übereinstimmt.

Hinweis

Das Angeben der Windows-Authentifizierung hat Vorrang vor SQL Server-Anmeldungen. Wenn Sie sowohl die integrierte Sicherheit aktivieren als auch einen Benutzernamen und ein Kennwort angeben, werden Benutzername und Kennwort ignoriert, und die Windows-Authentifizierung wird verwendet.

Herstellen einer Verbindung mit einer benannten Instanz von SQL Server

Wenn Sie eine Verbindung mit einer benannten Instanz von SQL Server herstellen möchten, verwenden Sie die Syntax Servername\Instanzname.

"Data Source=MySqlServer\MSSQL1;"

Sie können beim Erstellen einer Verbindungszeichenfolge auch die DataSource-Eigenschaft von SqlConnectionStringBuilder auf den Instanznamen festlegen. Die DataSource-Eigenschaft eines SqlConnection-Objekts ist schreibgeschützt.

Eingeben von Änderungen der Systemversion

Das Schlüsselwort Type System Version in SqlConnection.ConnectionString gibt die clientseitige Darstellung von SQL Server-Typen an. Weitere Informationen zum Schlüsselwort Type System Version finden Sie unter SqlConnection.ConnectionString.

Herstellen einer Verbindung und Anfügen an SQL Server Express-Benutzerinstanzen

Benutzerinstanzen sind eine Funktion in SQL Server Express. Mit ihrer Hilfe können Benutzer, die mit einem lokalen Windows-Konto der untersten Berechtigungsebene (LUA) arbeiten, eine SQL Server-Datenbank anfügen und ausführen, ohne dass dafür Administratorrechte erforderlich sind. Eine Benutzerinstanz wird mit den Windows-Anmeldeinformationen des Benutzers und nicht als Dienst ausgeführt.

Weitere Informationen zum Arbeiten mit Benutzerinstanzen finden Sie unter SQL Server Express-Benutzerinstanzen.

Verwenden von TrustServerCertificate

Das Schlüsselwort TrustServerCertificate wird beim Herstellen einer Verbindung mit einer SQL Server-Instanz verwendet. Wenn TrustServerCertificate auf true festgelegt ist, verwendet die Transportschicht TLS/SSL zur Verschlüsselung des Kanals und umgeht das Durchlaufen der Zertifikatskette zur Überprüfung der Vertrauensstellung.

In Versionen vor Microsoft.Data.SqlClient 2.0 wird diese Einstellung ignoriert, wenn Encrypt auf False festgelegt ist, und das Serverzertifikat wird nicht überprüft.
Ab Version 2.0 von Microsoft.Data.SqlClient steuert die Einstellung, ob die Zertifikatsüberprüfung durchgeführt wird, wenn der Server die Verschlüsselung erzwingt. Dies gilt auch dann, wenn Encrypt auf False festgelegt ist.
Ab Version 5.0 von Microsoft.Data.SqlClient wird diese Einstellung ignoriert, wenn Encrypt auf Strict festgelegt ist. Das Serverzertifikat wird immer im Strict-Modus überprüft.

Weitere Informationen finden Sie unter Verschlüsselung und Zertifikatüberprüfung.

"TrustServerCertificate=true;"

HostNameInCertificate

Ab Version 5.0 von Microsoft.Data.SqlClient ist „HostNameInCertificate“ eine neue Verbindungsoption. Durch die Überprüfung der Serverzertifikate wird sichergestellt, dass der Common Name (CN) oder Subject Alternate Name (SAN) im Zertifikat mit dem Servernamen der Verbindung übereinstimmt. In einigen Fällen wie DNS-Aliasen entspricht der Servername möglicherweise nicht dem CN oder SAN. Der Wert für „HostNameInCertificate“ kann verwendet werden, um einen anderen erwarteten CN oder SAN im Serverzertifikat anzugeben.

"HostNameInCertificate=myserver.example.com"

ServerCertificate

Ab Version 5.1 von Microsoft.Data.SqlClient ist ServerCertificate eine neue Verbindungsoption. Der Standardwert der ServerCertificate-Verbindungseinstellung ist eine leere Zeichenfolge. Wenn Encrypt auf Mandatory oder Strict festgelegt ist, kann ServerCertificate verwendet werden, um einen Pfad im Dateisystem zu einer Zertifikatsdatei anzugeben, die mit dem TLS-Zertifikat des Servers abgeglichen werden soll. Damit das angegebene Zertifikat als gültig gilt, muss es exakt übereinstimmen. Die akzeptierten Zertifikatformate sind PEM, DER und CER. Hier sehen Sie ein Beispiel:

"Data Source=...;Encrypt=Strict;ServerCertificate=C:\certificates\server.cer"

Aktivieren der Verschlüsselung

Um die Verschlüsselung zu aktivieren, wenn ein Zertifikat noch nicht auf dem Server bereitgestellt wurde, muss die Verbindungseigenschaft Vertrauenswürdiges Serverzertifikat auf True festgelegt werden. In diesem Fall wird bei der Verschlüsselung ein selbstsigniertes Serverzertifikat ohne Überprüfung verwendet, da kein überprüfbares Zertifikat auf dem Server bereitgestellt wurde.

Die Anwendungseinstellungen können nicht zu einer Verringerung der in SQL Server konfigurierten Sicherheitsstufe führen, sie jedoch optional erhöhen. Eine Anwendung kann Verschlüsselung anfordern, indem die Schlüsselwörter TrustServerCertificate und Encrypt auf true festgelegt werden. Dadurch wird sichergestellt, dass die Verschlüsselung auch ohne bereitgestelltes Serverzertifikat erfolgt. Wenn jedoch TrustServerCertificate in der Clientkonfiguration nicht aktiviert wird, ist immer noch ein bereitgestelltes Serverzertifikat erforderlich.

In der folgenden Tabelle werden alle Fälle beschrieben.

Verschlüsseln der Verbindungszeichenfolge bzw. des Attributs	Verbindungszeichenfolge/Attribut "TrustServerCertificate"	Ergebnis
Nein/Optional	Wird ignoriert.	Keine Verschlüsselung.
Ja/obligatorisch	Nein	Die Verschlüsselung erfolgt nur, wenn ein überprüfbares Serverzertifikat vorhanden ist. Andernfalls schlägt der Verbindungsversuch fehl.
Ja/obligatorisch	Ja	Verschlüsselung wird immer durchgeführt, es wird jedoch z. B. ein selbstsigniertes Serverzertifikat verwendet.
Strict¹	Wird ignoriert.	Es erfolgt immer Verschlüsselung, und diese muss ein überprüfbares Serverzertifikat nutzen. Andernfalls tritt beim Verbindungsversuch ein Fehler auf.

¹ Strenge Verschlüsselung ist erst ab Microsoft.Data.SqlClient Version 5.0 verfügbar.

Weitere Informationen, einschließlich des Verhaltens in früheren Versionen, finden Sie unter Verschlüsselung und Zertifikatsüberprüfung.

Siehe auch

Verbindungszeichenfolgen
Verschlüsselung und Zertifikatüberprüfung
Herstellen einer Verbindung mit Datenquellen
Microsoft ADO.NET für SQL Server

Teilen über