SQL Server- und Windows-Authentifizierung

Herunterladen von ADO.NET

Die Authentifizierung stellt fest, welche Identität mit dem SQL Server verbunden ist. Datenbankberechtigungen bestimmen, was diese Identität nach der Verbindung tun kann. Wählen Sie die Authentifizierung für die Umgebung, in der Ihre Anwendung läuft, und konfigurieren Sie Transport Layer Security (TLS)-Verschlüsselung und Zertifikatsvalidierung unabhängig voneinander.

Der Server-Authentifizierungsmodus von SQL Server unterscheidet sich von den Zugangsdaten, die Ihr Client sendet:

  • Der Windows Authentication-Modus akzeptiert Windows-Identitäten.
  • Der gemischte Modus akzeptiert Windows-Identitäten sowie SQL Server-Benutzernamen und Passwörter.

Das Setzen einer Client-Verbindungszeichenfolge ändert nicht den Authentifizierungsmodus des Servers. Für die Serverkonfiguration siehe Authentifizierungsmodus wählen.

Authentifizierungsszenarien

Bevorzuge eine Authentifizierung, die kein von der Anwendung verwaltetes Passwort erfordert, wenn deine Umgebung es unterstützt.

Anwendungsumgebung Authentifizierungswahl
Domänenumgebung mit entsprechender Windows-Identität. Integrated Security=true. SQL Server kann auf einem anderen Computer in der vertrauenswürdigen Umgebung sein.
Linux- oder macOS-Anwendung mit einer konfigurierten Domänenidentität. Integrierte Sicherheit mit Kerberos-Voraussetzungen für Client und Server.
Lokale Entwicklung unter Windows mit LocalDB. Integrierte Sicherheit unter der Identität des lokalen Entwicklers.
Azure-gehostete Anwendung mit Microsoft Entra-Unterstützung am SQL-Endpunkt. Verwaltete Identität oder ein anderer geeigneter Microsoft Entra-Authentifizierungsmodus.
Umgebung, die SQL-Zugangsdaten benötigt. SQL-Authentifizierung mit am wenigsten privilegierten Zugangsdaten, die aus einer geschützten Konfiguration oder einem geheimen Speicher abgerufen werden.

Eine internetorientierte Anwendung benötigt keine SQL-Authentifizierung von Natur aus. Die Anmeldung des Webnutzers und die Datenbankidentität der Anwendung sind getrennte Entscheidungen.

Verbinden Sie sich mit der Windows Authentication

Verwenden Sie die Identität, unter der die Anwendung läuft:

Server=tcp:<server>,1433;Database=<database>;Integrated Security=true;Encrypt=true;TrustServerCertificate=false;MultiSubnetFailover=true;

Trusted_Connection=true ist ein Synonym für Integrated Security=true. Wenn die integrierte Sicherheit aktiviert ist, werden User ID und Password in der Verbindungszeichenfolge ignoriert. Sie wählen keinen anderen Windows-Nutzer aus.

Ein Dienst verbindet sich normalerweise unter seiner Dienstidentität, nicht als die Person, die die Weboberfläche verwendet. Erteile Datenbankberechtigungen für die beabsichtigte Service-Identität. Wenn Sie eine Delegation der Identität eines Endnutzers über Computer hinweg benötigen, konfigurieren und überprüfen Sie die Kerberos-Delegation explizit.

Plattformvoraussetzungen

Client Anforderungen und Verhalten
.NET Framework unter Windows. Verwendet natives Windows-Netzwerk und die Security Support Provider Interface (SSPI).
Modernes .NET unter Windows. Verwendet standardmäßig natives Netzwerk. Windows Negotiate wählt Kerberos aus, wenn es konfiguriert ist; es kann auf den NT LAN Manager (NTLM) zurückfallen.
Moderne .NET unter Linux oder macOS. Verwendet verwaltetes Netzwerk und .NETNegotiateAuthentication. Konfigurieren Sie den Kerberos-Client, das Realm, den Service Principal Name (SPN) und die gültigen Zugangsdaten oder den Ticket-Cache.

Integrierte Sicherheit ist kein Ersatz für die Konfiguration von Domain Trust, Domain Name System (DNS)-Auflösung, Zeitsynchronisation und dem SQL Server SPN. Unter Linux beschaffen Sie sich vor dem Starten der Anwendung ein Ticket mit den Kerberos-Werkzeugen der Plattform, z. B. kinit. Gehen Sie nicht davon aus, dass ein Windows NTLM-Fallback auf einem Nicht-Windows-Client verfügbar ist. Siehe Registrieren eines SPN für Kerberos-Verbindungen.

Um das Authentifizierungsschema für Ihre aktuelle SQL Server-Verbindung zu überprüfen, führen Sie diese Transact-SQL (T-SQL)-Abfrage aus:

SELECT auth_scheme
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;

Der Zugriff auf diese diagnostische Ansicht hängt von den Berechtigungen des Servers ab. Eine erfolgreiche Verbindung allein beweist nicht, dass Kerberos und nicht NTLM verwendet wurden.

Für Anwendungen, die die Sicherheitskontextverhandlung steuern müssen, unterstützt SspiContextProvider eine benutzerdefinierte SSPI-Implementierung. Dies ist ein fortschrittlicher Erweiterbarkeitspunkt für Szenarien wie benutzerdefinierte Kerberos oder explizite NTLM-Zugangsdaten. Es handelt sich nicht um einen Authentifizierungsmodus für Verbindungsstrings und kann nicht mit AccessToken oder AccessTokenCallbackkombiniert werden.

Benutzerdefinierte Security Support Provider Interface (SSPI) Kontextanbieter

Die abstrakte Klasse SspiContextProvider bildet die Basis für alle SSPI-Kontextanbieter. Um einen individuellen Anbieter zu erstellen, leiten Sie ihn von SspiContextProvider ab, und überschreiben Sie die Methode GenerateContext. Weisen Sie vor dem Öffnen der Verbindung eine Instanz Ihres Anbieters der Eigenschaft SspiContextProvider eines SqlConnection zu.

Die Methode GenerateContext wird während des SSPI-Authentifizierungshandshakes aufgerufen. Es empfängt den eingehenden Authentifizierungsblob vom Server, einen Puffer-Schreiber für den ausgehenden Antwortblob und ein SspiAuthenticationParameters Objekt, das Verbindungsmetadaten enthält, wie zum Beispiel:

  • Resource - Der Service Principal Name (SPN) des Servers.
  • ServerName - Der Name der Datenquelle.
  • DatabaseName - Die Zieldatenbank, falls angegeben.
  • UserId – Die Benutzer-ID, sofern sie in der Verbindungszeichenfolge angegeben ist.
  • Password - Das Passwort, sofern es in der Verbindungszeichenfolge angegeben ist.

Wichtige Überlegungen:

  • Stellen Sie die SspiContextProvider-Eigenschaft ein, bevor Sie die Verbindung öffnen. Der Versuch, es für eine offene oder sich im Verbindungsaufbau befindliche Verbindung festzulegen, löst ein InvalidOperationException aus.
  • Die Instanz SspiContextProvider ist Teil des Schlüssels, der zur Identifikation von Verbindungspools verwendet wird. Vermeiden Sie es, für jede SqlConnection eine neue SspiContextProvider-Instanz zu erstellen, da jeder neue Anbieter einen neuen Pool erstellt. Verwenden Sie für Verbindungen, die für das Pooling berücksichtigt werden sollen, dieselbe Instanz eines Anbieters.
  • Ein benutzerdefiniertes SspiContextProvider muss sich mit demselben Sicherheitskontext für dieselben Eingabeparameter authentifizieren. Wenn der Sicherheitskontext anders ist, kann eine gepoolte Verbindung mit dem falschen Sicherheitskontext für eine Verbindungsanfrage zurückgegeben werden.
  • SspiContextProvider ist mit tokenbasierter Authentifizierung nicht kompatibel. Wenn man es neben AccessToken oder AccessTokenCallback setzt, wird ein InvalidOperationException ausgelöst, unabhängig davon, welche Eigenschaft man zuerst setzt.

Example

NegotiateAuthentication erfordert .NET 7 oder neuer, daher kompiliert dieses Beispiel nicht unter .NET Framework. Für einen .NET-Framework-Anbieter implementieren Sie GenerateContext stattdessen gegen eine Plattform-SSPI-API.

Das folgende Beispiel zeigt einen benutzerdefinierten SSPI-Kontextanbieter, der NegotiateAuthentication verwendet, um die Authentifizierung durchzuführen:

using System;
using System.Buffers;
using System.Net.Security;
using Microsoft.Data.SqlClient;

class CustomSspiContextProvider : SspiContextProvider
{
    private NegotiateAuthentication? _auth;

    protected override bool GenerateContext(
        ReadOnlySpan<byte> incomingBlob,
        IBufferWriter<byte> outgoingBlobWriter,
        SspiAuthenticationParameters authParams)
    {
        _auth ??= new NegotiateAuthentication(
            new NegotiateAuthenticationClientOptions
            {
                Package = "Negotiate",
                TargetName = authParams.Resource,
            });

        byte[]? blob = _auth.GetOutgoingBlob(
            incomingBlob, out NegotiateAuthenticationStatusCode statusCode);

        if (statusCode is not NegotiateAuthenticationStatusCode.Completed
            and not NegotiateAuthenticationStatusCode.ContinueNeeded)
        {
            return false;
        }

        if (blob is not null)
        {
            outgoingBlobWriter.Write(blob);
        }

        return true;
    }
}

Weisen Sie den Anbieter einer Verbindung zu, bevor Sie sie öffnen:

using var connection = new SqlConnection(
    "Server=myServer;Database=myDatabase;Integrated Security=true;Encrypt=True;");
connection.SspiContextProvider = new CustomSspiContextProvider();
connection.Open();

Sicherheitsüberlegungen

Beachten Sie bei der Implementierung eines benutzerdefinierten SSPI-Kontextanbieters die folgenden Sicherheitsaspekte:

  • Validiere alle Eingaben. Validiere immer eingehende Blobs und Authentifizierungsparameter, bevor du sie bearbeitest. Nicht wohlgeformte oder unerwartete Daten sollten abgelehnt werden, indem false von GenerateContext zurückgegeben wird.
  • Zugangsdaten schützen. Das Objekt SspiAuthenticationParameters könnte empfindliche Werte wie UserId und Passwordenthalten. Protokollieren, persistieren oder übertragen Sie diese Werte nicht ungesichert.
  • Verwenden Sie etablierte Authentifizierungsbibliotheken. Wann immer möglich, delegieren Sie die Authentifizierungslogik an gut getestete Bibliotheken wie NegotiateAuthentication, anstatt kryptografische Protokolle selbst zu implementieren.
  • Ressourcen entfernen. Wenn Ihr Anbieter nicht verwaltete Ressourcen oder Authentifizierungskontexte zuweist, implementieren Sie IDisposable, und sorgen Sie für eine ordnungsgemäße Bereinigung. SqlClient entsorgt die Instanz SspiContextProvider nicht. Entfernen Sie den Anbieter, wenn Ihre Anwendung ihn nicht mehr benötigt.
  • Beschränke das Authentifizierungspaket. Verwenden Sie nur Authentifizierungspakete, die für Ihre Umgebung geeignet sind (zum Beispiel Negotiate oder Kerberos). Geben Sie nur vertrauenswürdige Eingaben und Konfigurationen an das Authentifizierungspaket weiter.
  • Testen Sie gründlich. Überprüfen Sie, ob Ihr Anbieter unter allen erwarteten Bedingungen korrekt funktioniert, einschließlich Token-Verlängerung, Verbindungspooling und Failover-Szenarien.

Microsoft validiert oder prüft keine benutzerdefinierten SspiContextProvider Implementierungen und garantiert auch nicht die Sicherheit von Verbindungen, die über einen benutzerdefinierten Anbieter authentifiziert wurden. Alle Schwachstellen, die durch eine benutzerdefinierte Implementierung eingeführt werden, liegen in deiner Verantwortung.

Anmeldetypen

Ein Login gewährt Identitätszugriff auf den Server. Ein Datenbankbenutzer stellt eine Identität innerhalb einer Datenbank dar. Weisen Sie den vorgesehenen Login oder die Gruppe einem Datenbankbenutzer zu und gewähren Sie dann nur die erforderlichen Berechtigungen über Datenbankrollen.

SQL Server unterstützt Windows-Konto-Logins, Windows-Gruppen-Logins und SQL-Logins. Eine Windows-Gruppe ermöglicht es Administratoren, die Mitgliedschaft zu verwalten, ohne für jede Person einen separaten SQL Server-Login zu erstellen. Anmeldungen mit Zertifikaten und asymmetrischen Schlüsseln, die zum Signieren von Code verwendet werden, sind keine Identitäten für interaktive Verbindungen.

Nutzer der enthaltenen Datenbank und Microsoft Entra-Verantwortliche haben unterschiedliche Anforderungen an die Bereitstellung. Siehe die Authentifizierungsdokumentation der Principals und des Endpunkts, anstatt davon auszugehen, dass jeder Benutzer einen SQL-Login benötigt.

Authentifizierung im gemischten Modus

Verwenden Sie SQL-Authentifizierung nur auf einem Endpunkt, der so konfiguriert ist, dass sie akzeptiert wird. Stellen Sie User ID und Password bereit, deaktivieren Sie die integrierte Sicherheit, und lassen Sie die Zertifikatsvalidierung aktiviert. Authentication=Sql Passwordwählt explizit SQL-Passwortauthentifizierung aus; es wählt nicht die Microsoft Entra-Passwortauthentifizierung.

Das folgende .NET-Konsolenbeispiel verwendet Microsoft.Data.SqlClient. Legen Sie SQL_SERVER, SQL_DATABASE, SQL_USER_ID und SQL_PASSWORD über Ihre Entwicklungsumgebung oder Ihren Mechanismus zur Injektion von Geheimnissen fest. SQL_SERVER sollte einen Endpunkt für das Transmission Control Protocol (TCP) enthalten, wie z. B. tcp:sql-server.contoso.com,1433. Drucken Sie weder das Passwort noch die vollständige Verbindungszeichenfolge.

using Microsoft.Data.SqlClient;

static string Required(string name) =>
    Environment.GetEnvironmentVariable(name)
    ?? throw new InvalidOperationException($"Set {name} before running.");

var options = new SqlConnectionStringBuilder
{
    DataSource = Required("SQL_SERVER"),
    InitialCatalog = Required("SQL_DATABASE"),
    Authentication = SqlAuthenticationMethod.SqlPassword,
    UserID = Required("SQL_USER_ID"),
    Password = Required("SQL_PASSWORD"),
    Encrypt = SqlConnectionEncryptOption.Mandatory,
    TrustServerCertificate = false,
    MultiSubnetFailover = true
};

using var connection = new SqlConnection(options.ConnectionString);
await connection.OpenAsync();
using var command = new SqlCommand("SELECT DB_NAME();", connection);
Console.WriteLine(await command.ExecuteScalarAsync());

Die Abfrage druckt den verbundenen Datenbanknamen. Verwenden Sie SqlConnectionStringBuilder, anstatt Zugangsdaten in eine Zeichenfolge zu verketten. Der Builder entgeht Verbindungsstring-Werten; er entscheidet nicht, welche Server, Datenbank oder welche Berechtigungen deine Anwendung erlauben soll.

Behalte Persist Security Info=false, das ist Standard. Lagere Produktionsgeheimnisse in einem geschützten Geheimspeicher, beschränke, wer sie lesen darf, und rotiere sie. Verwenden Sie keine Administrator- oder Datenbankbesitzer-Identität für routinemäßige Anwendungsanfragen.

Microsoft Entra und Service-Einschränkungen

Integrated Security=trueauthentifiziert eine Windows-Identität mit SQL Server. Authentication=Active Directory Integratederwirbt ein Microsoft Entra-Token. Diese sind nicht austauschbar.

Azure SQL-Datenbank verwendet SQL- oder Microsoft Entra-Authentifizierung anstelle der üblichen integrierten Windows-Authentifizierung. Die SQL-Datenbank in Microsoft Fabric unterstützt nur Microsoft Entra-Identitäten; SQL-Authentifizierung und Logins werden nicht unterstützt. Verwenden Sie den Microsoft Entra-Artikel für tokenbasierte Verbindungen.

Verwandte Inhalte

  • Zuletzt aktualisiert um