Grundlegendes zur Active Directory-Authentifizierung für SQL Server für Linux und Container
Gilt für: 
SQL Server – Linux
In diesem Artikel erfahren Sie, wie die Active Directory-Authentifizierung für SQL Server bei Bereitstellung unter Linux oder in Containern funktioniert.
Konzepte
Lightweight Directory Access-Protokoll (LDAP)
Lightweight Directory Access Protocol (LDAP) ist ein Anwendungsprotokoll, das mit verschiedenen Verzeichnisdiensten eingesetzt werden kann, einschließlich Active Directory. Verzeichnisdienste speichern Benutzer- und Kontoinformationen sowie Sicherheitsinformationen, wie etwa Kennwörter. Diese Informationen werden verschlüsselt und dann für andere Geräte im Netzwerk freigegeben.
Weitere Informationen zum Schützen von LDAP finden Sie unter Aktivieren der LDAP-Anmeldung in Windows Server.
Kerberos
Kerberos ist ein Authentifizierungsprotokoll, das zum Überprüfen der Identität eines Benutzers oder Hostcomputers verwendet wird. Sie können es sich als eine Möglichkeit vorstellen, den Client und den Server zu überprüfen.
Wenn Sie in einer heterogenen (gemischten) Umgebung arbeiten, die aus Windows- und Nicht-Windows-Servern und -Clients besteht, sind zwei Arten von Dateien erforderlich, wenn Sie mit Active Directory-basierten Verzeichnisdiensten arbeiten:
- Schlüsseltabellendateien (Keytab Files, kurz für „Key Tables“)
- Kerberos-Konfigurationsdateien (
krb5.confoderkrb5.ini)
Was ist eine Schlüsseltabellendatei?
Serverprozesse auf Linux- oder Unix-Systemen können nicht für die Ausführung von Prozessen unter einem Windows-Dienstkonto konfiguriert werden. Wenn Sie möchten, dass sich ein Linux- oder Unix-System beim Start automatisch bei Active Directory anmeldet, müssen Sie eine Schlüsseltabellendatei verwenden.
Eine Schlüsseltabelle ist eine Kryptografie-Datei, die eine Darstellung eines mit Kerberos geschützten Diensts und dessen langfristigen Schlüssel des zugehörigen Dienstprinzipalnamens im Schlüsselverteilungscenter (Key Distribution Center, KDC) enthält. Der Schlüssel stellt nicht das Kennwort dar.
Schlüsseltabellen werden für einen von zwei Zwecken verwendet:
- Authentifizieren des eigentlichen Diensts bei einem anderen Dienst im Netzwerk oder
- Entschlüsseln des Kerberos-Diensttickets eines eingehenden Verzeichnisbenutzers für den Dienst
Was ist eine krb5.conf-Datei?
Die /etc/krb5.conf-Datei (auch als krb5.ini bezeichnet) stellt Konfigurationseingaben für die Bibliotheken Kerberos v5 (KRB5) und GNU Simple Authentication and Security Layer API (GSSAPI) bereit.
Diese Informationen beinhalten die Standarddomäne, die Eigenschaften jeder Domäne (z. B. Schlüsselverteilungscenter) und die Standardgültigkeitsdauer von Kerberos-Tickets.
Diese Datei ist erforderlich, damit die Active Directory-Authentifizierung funktioniert. krb5.conf ist eine INI-Datei, aber jeder Wert im Schlüssel-Wert-Paar kann eine Untergruppe sein, die von { und } umschlossen ist.
Weitere Informationen zur krb5.conf-Datei finden Sie in der Dokumentation des MIT Kerberos-Konsortiums.
Konfigurieren von Kerberos für SQL Server für Linux
Dies sind die Werte, die Sie auf dem Hostserver benötigen, der SQL Server unter Linux ausführt. Wenn andere (nicht-SQL Server-) Dienste auf demselben Host ausgeführt werden, benötigt Ihre krb5.conf-Datei möglicherweise mehrere weitere Einträge.
Hier sehen Sie eine krb5.conf-Beispieldatei als Referenz:
[libdefaults]
default_realm = CONTOSO.COM
[realms]
CONTOSO.COM = {
kdc = adVM.contoso.com
admin_server = adVM.contoso.com
default_domain = contoso.com
}
[domain_realm]
.contoso.com = CONTOSO.COM
contoso.com = CONTOSO.COM
libdefaults: Der Wertdefault_realmmuss vorhanden sein. Dieser Wert gibt die Domäne an, zu der der Hostcomputer gehört.realms(optional): Für jeden Bereich kann derkdc-Wert festgelegt werden, um anzugeben, welche Schlüsselverteilungscenter der Computer beim Suchen nach Active Directory-Konten kontaktieren soll. Wenn Sie mehrere KDC festgelegt haben, wird das KDC für jede Verbindung durch Roundrobin ausgewählt.domain_realm(optional): Es können Zuordnungen für jeden Bereich angegeben werden. Falls nicht, geht SQL Server unter Linux davon aus, dass die Domänecontoso.comdem BereichCONTOSO.COMzugeordnet ist.
Der Kerberos-Authentifizierungsprozess
Wie bei der Kerberos-Authentifizierung unter Windows sind die ersten beiden Schritte zum Abrufen eines TGT (Ticket-granting Ticket) identisch:
Ein Client beginnt den Anmeldevorgang, indem er den Benutzernamen und das Kennwort (verschlüsselt) an den Domänencontroller (DC) sendet.
Nachdem der Benutzername und das Kennwort anhand des internen Speichers überprüft wurden, gibt der Domänencontroller ein TGT für den Benutzer an den Client zurück.
SQL Server unter Linux verwendet die Schlüsseltabellendatei, um das Kennwort für den Dienstprinzipalnamen (Service Principal Name, SPN) zu lesen, und entschlüsselt dann das verschlüsselte Blob, das zum Autorisieren der Verbindung verwendet wird. Dieser Vorgang wird in den folgenden Schritten beschrieben.
Sobald der Benutzer über das TGT verfügt, startet der Client eine Verbindung mit SQL Server, indem er den Hostnamen und Port der SQL Server-Instanz angibt.
Der SQL Client erstellt intern einen Dienstprinzipalnamen im Format
MSSQLSvc/<host>:<port>. Dies ist bei den meisten SQL Server-Clients ein hartcodiertes Format.Der Client startet den Kerberos-Handshake, indem er beim Domänencontroller einen Sitzungsschlüssel für diesen SPN anfordert. Sowohl das TGT als auch der SPN werden an den Domänencontroller gesendet.
- Nachdem der Domänencontroller das TGT und den SPN überprüft hat, sendet er den Sitzungsschlüssel zum Herstellen einer Verbindung mit dem SQL Server-SPN an den Client.
- Das verschlüsselte Blob aus dem Sitzungsschlüssel wird an den Server gesendet.
SQL Server liest das Kennwort für den SPN aus seiner Schlüsseltabelle (
mssql.keytab). Datei handelt es sich um eine Datei auf einem Datenträger, die verschlüsselte Tupel (SPN, Kennwort) enthält.SQL Server entschlüsselt das verschlüsselte Blob vom Client mit dem soeben nachgeschlagenen Kennwort, um den Benutzernamen des Clients abzurufen.
SQL Server sucht den Client in der
sys.syslogins-Tabelle, um zu überprüfen, ob der Client für die Verbindungsherstellung autorisiert ist.Die Verbindung wird entweder akzeptiert oder verweigert.
Konfigurieren von Kerberos für SQL Server-Container
Die Active Directory-Authentifizierung für SQL Server in Containern entspricht im Wesentlichen SQL Server für Linux. Der einzige Unterschied ist der SQL Server-Host-SPN. Im vorherigen Szenario lautete der SPN MSSQLSvc/<host>:<port>, da wir die Verbindung über den Namen des SQL Server-Hosts herstellten. Jetzt müssen wir jedoch eine Verbindung mit dem Container herstellen.
Für SQL Server-Container können Sie die krb5.conf-Datei im Container erstellen. Der Hostknoten, auf dem der Container ausgeführt wird, muss nicht Teil der Domäne sein, der Domänencontroller, mit dem der Container eine Verbindung herzustellen versucht, sollte für ihn aber zugänglich sein.
Da wir eine Verbindung mit einem Container herstellen, kann sich der Servername in der Clientverbindung vom Hostnamen unterscheiden. Es kann der Hostname, der Containername oder ein anderer Alias sein. Darüber hinaus besteht die Wahrscheinlichkeit, dass der verfügbar gemachte Port für SQL Server nicht der Standardport 1433.
Sie müssen den SPN verwenden, der in mssql.keytab gespeichert ist, um eine Verbindung mit dem SQL Server-Container herzustellen. Wenn der SPN in mssql.keytab beispielsweise MSSQLSvc/sqlcontainer.domain.com:8000 lautet, verwenden Sie sqlcontainer.domain.com,8000 als Verbindungszeichenfolge im Client (einschließlich sqlcmd, SQL Server Management Studio und Azure Data Studio).
SQL Server Gruppenaktualisierung
Möglicherweise fragen Sie sich, warum in der Schlüsseltabelle ein Benutzerkonto vorhanden ist, wenn Sie nur einen Dienstprinzipalnamen für die Authentifizierung benötigen.
Stellen Sie sich dazu vor, Sie verfügen über einen Benutzer adUser, der ein Mitglied einer Gruppe adGroup ist. Wenn adGroup als Anmeldung zu SQL Server hinzugefügt wird, bedeutet dies, dass adUser ebenfalls über die Berechtigung zum Anmelden bei der SQL Server-Instanz verfügt. Während noch eine Verbindung von adUser mit SQL Server besteht, entfernt ein Domänenadministrator adUser ausadGroup. AdUser sollte nun nicht mehr über die Berechtigung zum Anmelden bei SQL Server verfügen, aber er hat den Kerberos-Authentifizierungsprozess bereits bestanden und ist verbunden.
Zum Schutz vor einem Szenario, bei dem ein verbundener Benutzer nicht mehr zum Ausführen einer privilegierten Aktion (wie dem Erstellen einer Anmeldung oder dem Ändern einer Datenbank) berechtigt ist, führen wir in regelmäßigen Abständen einen Prozess namens Gruppenaktualisierung aus.
SQL Server verfügt über ein privilegiertes Active Directory-Konto, das für die Gruppenaktualisierung verwendet wird. Dieses Konto ist entweder mithilfe von mssql-conf mit der Einstellung network.privilegedadaccount konfiguriert, oder es wird standardmäßig das Computerkonto des Hostcomputers (<hostname>$) verwendet.
Die Anmeldeinformationen für das privilegierte Konto in mssql.keytab werden verwendet, um die Identität des Clients anzunehmen (in diesem Beispiel adUser). SQL Server führt einen Kerberos-Handshake mit sich selbst aus, um die Informationen zur Gruppenmitgliedschaft zu identifizieren, und vergleicht sie mit sys.syslogins, um zu überprüfen, ob adUser noch über die erforderlichen Berechtigungen verfügt, um eine Verbindung herzustellen und die angeforderten Transact-SQL-Befehle auszuführen. Wenn adUser aus adGroup entfernt wurde, wird die Verbindung durch SQL Server beendet.
Die Gruppenaktualisierung erfordert die folgenden zwei Bedingungen:
- Netzwerkkonnektivität zwischen der SQL Server-Instanz und der lokalen Active Directory-Domäne
- Bidirektionale Vertrauensstellung zwischen der Domäne, mit der SQL Server verbunden ist, und der lokalen Active Directory-Domäne. Weitere Informationen finden Sie unter Grundlegendes zu Active Directory.