Tutorial: Verwenden der Active Directory-Authentifizierung für SQL Server für Linux

Gilt für: SQL Server – Linux

In diesem Tutorial wird erläutert, wie Sie SQL Server für Linux konfigurieren, um die Active Directory-Authentifizierung zu unterstützen, die auch als integrierte Authentifizierung bezeichnet wird. Eine Übersicht dazu finden Sie unter Active Directory-Authentifizierung für SQL Server für Linux.

Dieses Tutorial umfasst die folgenden Aufgaben:

• Verknüpfen eines SQL Server-Hosts mit einer Active Directory-Domäne
• Erstellen eines Active Directory-Benutzers für SQL Server und Festlegen eines SPN
• Konfigurieren der KEYTAB-Datei für den SQL Server-Dienst
• Sichern der KEYTAB-Datei
• Konfigurieren von SQL Server für die Verwendung der KEYTAB-Datei für die Kerberos-Authentifizierung
• Erstellen von Active Directory-basierten Anmeldungen in Transact-SQL
• Herstellen einer Verbindung mit SQL Server mithilfe der Active Directory-Authentifizierung

Voraussetzungen

Bevor Sie die Active Directory-Authentifizierung konfigurieren können, müssen Sie Folgendes tun:

• Einrichten eines Active Directory-Domänencontrollers (Windows) in Ihrem Netzwerk
• Installieren von SQL Server
  • Schnellstart: Installieren von SQL Server und Erstellen einer Datenbank unter Red Hat
  • Schnellstart: Installieren von SQL Server und Erstellen einer Datenbank unter SUSE Linux Enterprise Server
  • Schnellstart: Installieren von SQL Server und Erstellen einer Datenbank unter Ubuntu

Verknüpfen eines SQL Server-Hosts mit einer Active Directory-Domäne

Verknüpfen Sie Ihren Linux-Host für SQL Server mit einem Active Directory-Domänencontroller. Informationen dazu finden Sie unter Verknüpfen von eines Linux-Hosts für SQL Server mit einer Active Directory-Domäne.

Erstellen eines Active Directory-Benutzers für SQL Server und Festlegen eines SPN

Hinweis

Verwenden Sie für die folgenden Schritte Ihren vollqualifizierten Domänennamen (FQDN). Wenn Sie in Azure arbeiten, müssen Sie einen FQDN erstellen ,bevor Sie fortfahren können.

1. Führen Sie auf Ihrem Domänencontroller den PowerShell-Befehl New-ADUser aus, um einen neuen Active Directory-Benutzer mit einem Kennwort zu erstellen, das niemals abläuft. Im folgenden Beispiel hat das Konto den Namen sqlsvc. Sie können aber jeden beliebigen Namen auswählen. Sie werden aufgefordert, ein neues Kennwort für das Konto einzugeben.

   Import-Module ActiveDirectory
   
   New-ADUser sqlsvc -AccountPassword (Read-Host -AsSecureString "Enter Password") -PasswordNeverExpires $true -Enabled $true
   

   Hinweis

   Es hat sich als Sicherheitsmethode bewährt, ein dediziertes Active Directory-Konto für SQL Server zu verwenden, damit die Anmeldeinformationen für die SQL Server-Instanz nicht für andere Dienste freigegeben werden, die dasselbe Konto verwenden. Sie können jedoch als Alternative auch ein vorhandenes Active Directory-Konto wiederverwenden, wenn Sie das Kennwort für das Konto kennen. (Sie benötigen dieses, um im nächsten Schritt eine KEYTAB-Datei zu erstellen.) Außerdem sollte das Konto 128-Bit- und 256-Bit-Kerberos-AES-Verschlüsselung (Attribut msDS-SupportedEncryptionTypes) für das Benutzerkonto unterstützen können. Wenn Sie überprüfen möchten, ob das Konto für die AES-Verschlüsselung aktiviert ist, suchen Sie das Konto im Hilfsprogramm Active Directory-Benutzer und -Computer, und klicken Sie auf Eigenschaften. Suchen Sie unter Eigenschaften nach der Registerkarte Konten, und überprüfen Sie, ob die beiden folgenden Kontrollkästchen aktiviert sind.

   1. Dieses Konto unterstützt Kerberos-AES-128-Bit-Verschlüsselung

   2. Dieses Konto unterstützt Kerberos-AES-256-Bit-Verschlüsselung

2. Legen Sie den Dienstprinzipalnamen (Service Principle Name, SPN) für dieses Konto mithilfe des Tools setspn.exe fest. Der SPN muss genau wie im folgenden Beispiel angegeben formatiert werden. Sie können den vollqualifizierten Domänennamen des Hostcomputers für SQL Server ermitteln, indem Sie hostname --all-fqdns auf de Host SQL Server ausführen. In der Regel wird der TCP-Port 1433 verwendet, es sei denn, Sie haben SQL Server so konfiguriert, dass eine andere Portnummer verwendet wird.

   setspn -A MSSQLSvc/<fully qualified domain name of host machine>:<tcp port> sqlsvc
   setspn -A MSSQLSvc/<netbios name of the host machine>:<tcp port> sqlsvc
   

   Hinweis

   Wenn Sie die Fehlermeldung Insufficient access rights erhalten, prüfen Sie zusammen mit Ihrem Domänenadministrator, ob Sie über die nötigen Berechtigungen verfügen, um einen SPN für dieses Konto festzulegen. Für das Konto, das zum Registrieren des SPN verwendet wird, benötigen Sie die Write servicePrincipalName-Berechtigungen. Weitere Informationen finden Sie unter Registrieren eines Dienstprinzipalnamens für Kerberos-Verbindungen.

   Wenn Sie den TCP-Port später ändern, müssen Sie den Befehl setspn noch einmal mit der neuen Portnummer ausführen. Außerdem müssen Sie den neuen SPN zur KEYTAB-Datei des SQL Server-Diensts hinzufügen, indem Sie die im nächsten Abschnitt beschriebenen Schritte ausführen.

Weitere Informationen finden Sie unter Registrieren eines Dienstprinzipalnamens für Kerberos-Verbindungen.

Konfigurieren der KEYTAB-Datei für den SQL Server-Dienst

Das Konfigurieren der Active Directory-Authentifizierung für SQL Server für Linux erfordert ein Active Directory-Benutzerkonto und den im vorherigen Abschnitt erstellten Dienstprinzipalnamen.

Wichtig

Wird das Kennwort für das Active Directory-Konto oder für das Konto, dem die SPNs zugewiesen sind, geändert, müssen Sie die KEYTAB-Datei mit dem neuen Kennwort und der Schlüsselversionsnummer (Key Version Number, KVNO) aktualisieren. Einige Dienste rotieren die Kennwörter möglicherweise auch automatisch. Überprüfen Sie sämtliche Richtlinien für die Kennwortrotation, die für die betreffenden Konten gelten, und passen Sie geplante Wartungsaktivitäten an diese an, um unerwartete Ausfallzeiten zu vermeiden.

KEYTAB-Einträge für den SPN

1. Überprüfen Sie die KVNO des Active Directory-Kontos, das Sie im vorherigen Schritt erstellt haben. Normalerweise lautet diese 2, aber es kann auch ein anderer Integerwert sein, wenn Sie das Kennwort des Kontos mehrmals geändert haben. Führen Sie auf dem Hostcomputer für SQL Server die folgenden Befehle aus:

   • In den folgenden Beispielen wird davon ausgegangen, dass sich user in der Domäne @CONTOSO.COM befindet. Ändern Sie den Benutzer- und Domänennamen in Ihren Benutzer- und Domänennamen.

   kinit user@CONTOSO.COM
   kvno user@CONTOSO.COM
   kvno MSSQLSvc/<fully qualified domain name of host machine>:<tcp port>@CONTOSO.COM
   

   Hinweis

   Es kann einige Minuten dauern, bis die SPNs für Ihre Domäne übernommen werden, insbesondere, wenn die Domäne groß ist. Wenn Sie die Fehlermeldung kvno: Server not found in Kerberos database while getting credentials for MSSQLSvc/<fully qualified domain name of host machine>:<tcp port>@CONTOSO.COM erhalten, warten Sie einige Minuten, und versuchen Sie es noch mal.
   
   Die obigen Befehle funktionieren nur, wenn der Server, wie im vorherigen Abschnitt beschrieben, mit einer Active Directory-Domäne verknüpft wurde.

2. Fügen Sie über ktpass für jeden SPN KEYTAB-Einträge hinzu, indem Sie in der Eingabeaufforderung eines Windows-Computers die folgenden Befehle eingeben:

   • <DomainName>\<UserName>: Active Directory-Benutzerkonto
   • @CONTOSO.COM: Verwenden Sie Ihren Domänennamen.
   • /kvno <#>: Ersetzen Sie <#> durch die KVNO, die Sie in einem vorherigen Schritt erhalten haben.
   • <StrongPassword>: Verwenden Sie ein sicheres Kennwort.

   ktpass /princ MSSQLSvc/<fully qualified domain name of host machine>:<tcp port>@CONTOSO.COM /ptype KRB5_NT_PRINCIPAL /crypto aes256-sha1 /mapuser <DomainName>\<UserName> /out mssql.keytab -setpass -setupn /kvno <#> /pass <StrongPassword>
   
   ktpass /princ MSSQLSvc/<fully qualified domain name of host machine>:<tcp port>@CONTOSO.COM /ptype KRB5_NT_PRINCIPAL /crypto rc4-hmac-nt /mapuser <DomainName>\<UserName> /in mssql.keytab /out mssql.keytab -setpass -setupn /kvno <#> /pass <StrongPassword>
   
   ktpass /princ MSSQLSvc/<netbios name of the host machine>:<tcp port>@CONTOSO.COM /ptype KRB5_NT_PRINCIPAL /crypto aes256-sha1 /mapuser <DomainName>\<UserName> /in mssql.keytab /out mssql.keytab -setpass -setupn /kvno <#> /pass <StrongPassword>
   
   ktpass /princ MSSQLSvc/<netbios name of the host machine>:<tcp port>@CONTOSO.COM /ptype KRB5_NT_PRINCIPAL /crypto rc4-hmac-nt /mapuser <DomainName>\<UserName> /in mssql.keytab /out mssql.keytab -setpass -setupn /kvno <#> /pass <StrongPassword>
   
   ktpass /princ <UserName>@CONTOSO.COM /ptype KRB5_NT_PRINCIPAL /crypto aes256-sha1 /mapuser <DomainName>\<UserName> /in mssql.keytab /out mssql.keytab -setpass -setupn /kvno <#> /pass <StrongPassword>
   
   ktpass /princ <UserName>@CONTOSO.COM /ptype KRB5_NT_PRINCIPAL /crypto rc4-hmac-nt /mapuser <DomainName>\<UserName> /in mssql.keytab /out mssql.keytab -setpass -setupn /kvno <#> /pass <StrongPassword>
   

   Hinweis

   Mit den obigen Befehlen werden für die Active Directory-Authentifizierung sowohl AES- als auch RC4-Verschlüsselungsverfahren zugelassen. RC4 ist eine ältere Verschlüsselungsmethode. Ist ein höherer Sicherheitsgrad erforderlich, können Sie die KEYTAB-Einträge auch nur mithilfe der AES-Verschlüsselung erstellen. Die letzten zwei UserName-Einträge müssen kleingeschrieben werden, da sonst die Authentifizierung der Berechtigungen fehlschlagen kann.

3. Nach dem Ausführen des obigen Befehls sollte eine KEYTAB-Datei namens „mssql.keytab“ vorhanden sein. Kopieren Sie die Datei auf den SQL Server-Computer in den Ordner /var/opt/mssql/secrets.

4. Schützen Sie die KEYTAB-Datei.

   Jeder Benutzer mit Zugriff auf diese KEYTAB-Datei kann die Identität von SQL Server in der Domäne annehmen. Stellen Sie daher sicher, dass Sie den Zugriff auf die Datei so einschränken, dass nur das MSSQL-Konto über Lesezugriff verfügt:

   sudo chown mssql:mssql /var/opt/mssql/secrets/mssql.keytab
   sudo chmod 400 /var/opt/mssql/secrets/mssql.keytab
   

5. Legen Sie mithilfe des Tools mssql-conf die folgende Konfigurationsoption fest, um das Konto anzugeben, das für den Zugriff auf die KEYTAB-Datei verwendet werden soll.

   sudo mssql-conf set network.privilegedadaccount <username>
   

   Hinweis

   Geben Sie nur den Benutzernamen an und nicht etwa „\“ oder „@“. SQL Server fügt den Domänennamen nach Bedarf intern hinzu, wenn dieser Benutzername verwendet wird.

6. Gehen Sie wie im Folgenden beschrieben vor, um die SQL Server-Instanz so zu konfigurieren, dass die KEYTAB-Datei für die Kerberos-Authentifizierung verwendet wird.

   sudo mssql-conf set network.kerberoskeytabfile /var/opt/mssql/secrets/mssql.keytab
   sudo systemctl restart mssql-server
   

   Tipp

   Optional können Sie die UDP-Verbindungen mit dem Domänencontroller deaktivieren, um die Leistung zu verbessern. In vielen Fällen schlagen UDP-Verbindungen beim Herstellen einer Verbindung mit einem Domänencontroller immer wieder fehl. Sie können deshalb in den Konfigurationsoptionen in der Datei /etc/krb5.conf festlegen, dass UDP-Aufrufe übersprungen werden sollen. Bearbeiten Sie die Datei /etc/krb5.conf, und legen Sie die folgenden Optionen fest:

   /etc/krb5.conf
   [libdefaults]
   udp_preference_limit=0
   

Nun können Sie Active Directory-basierte Anmeldeinformationen in SQL Server verwenden.

Erstellen von Active Directory-basierten Anmeldungen in Transact-SQL

1. Stellen Sie eine Verbindung mit SQL Server her, und erstellen Sie neue Active Directory-basierte Anmeldeinformationen:

   CREATE LOGIN [CONTOSO\user] FROM WINDOWS;
   

2. Überprüfen Sie danach, ob diese Anmeldeinformationen in der Systemkatalogsicht sys.server_principals aufgeführt werden:

   SELECT name FROM sys.server_principals;
   

Herstellen einer Verbindung mit SQL Server mithilfe der Active Directory-Authentifizierung

Melden Sie sich über Ihre Domänenanmeldeinformationen bei einem Clientcomputer an. Nun können Sie eine Verbindung mit SQL Server herstellen, ohne Ihr Kennwort über die Active Directory-Authentifizierung erneut eingeben zu müssen. Wenn Sie Anmeldeinformationen für eine Active Directory-Gruppe erstellen, kann jeder Active Directory-Benutzer, der Mitglied dieser Gruppe ist, auf die gleiche Weise eine Verbindung herstellen.

Der genaue Verbindungszeichenfolgenparameter, den die Clients benötigen, um die Active Directory-Authentifizierung verwenden zu können, ist davon abhängig, welchen Treiber Sie verwenden. Beispiele dazu finden Sie in den folgenden Abschnitten.

sqlcmd auf einem in die Domäne eingebundenen Linux-Client

Melden Sie sich mithilfe von ssh und Ihren Domänenanmeldeinformationen bei einem in die Domäne eingebundenen Linux-Client an:

ssh -l user@contoso.com client.contoso.com

Stellen Sie sicher, dass das Paket mssql-tools installiert wurde, und stellen Sie dann mithilfe von sqlcmd eine Verbindung her, ohne die Anmeldeinformationen anzugeben:

sqlcmd -S mssql-host.contoso.com

Im Gegensatz zu SQL Windows können Sie die Kerberos-Authentifizierung für lokale Verbindungen in SQL Linux verwenden. Dafür ist jedoch die Bereitstellung des FQDN des Linux-Hosts für SQL Server erforderlich. Die Active Directory-Authentifizierung funktioniert nicht beim Herstellen einer Verbindung mit ., localhost, 127.0.0.1 usw.

SSMS auf einem in die Domäne eingebundenen Windows-Client

Melden Sie sich mithilfe Ihrer Domänenanmeldeinformationen bei einem in die Domäne eingebundenen Windows-Client an. Vergewissern Sie sich, dass SQL Server Management Studio installiert ist, und stellen Sie dann eine Verbindung mit Ihrer SQL Server-Instanz her (z. B. mssql-host.contoso.com), indem Sie im Dialogfeld Mit Server verbindenWindows-Authentifizierung angeben.

Active Directory-Authentifizierung mit anderen Clienttreibern

In der folgenden Tabelle werden die Empfehlungen für andere Clienttreiber beschrieben:

Clienttreiber	Empfehlung
JDBC	Verwenden Sie die integrierte Kerberos-Authentifizierung, um eine Verbindung mit der SQL Server-Instanz herzustellen.
ODBC	Verwenden Sie die integrierte Authentifizierung.
ADO.NET	Verwenden Sie die Syntax der Verbindungszeichenfolge.

Zusätzliche Konfigurationsoptionen

Wenn Sie Hilfsprogramme von Drittanbietern wie PBIS, VAS oder Centrify verwenden, um den Linux-Host mit der Active Directory-Domäne zu verknüpfen, und erzwingen möchten, dass der SQL Server die OpenLDAP-Bibliothek direkt verwendet, können Sie die Option disablesssd wie folgt mithilfe von mssql-conf konfigurieren:

sudo mssql-conf set network.disablesssd true
systemctl restart mssql-server

Hinweis

Einige Hilfsprogramme wie realmd richten die SSSD ein, wohingegen andere Tools wie PBIS, VAS und Centrify dies nicht tun. Wenn das Hilfsprogramm, das verwendet wird, um die Active Directory-Domäne zu verknüpfen, nicht SSSD einrichtet, empfiehlt es sich, die Option disablesssd auf true festzulegen. Dies ist zwar nicht zwingend notwendig, weil die SQL Server-Instanz versucht, SSSD für Active Directory zu verwenden, bevor sie auf den OpenLDAP-Mechanismus zurückgreift, aber Sie würden dadurch die Leistung verbessern, weil die Instanz dann direkt OpenLDAP-Aufrufe durchführt und den SSSD-Mechanismus umgeht.

Wenn Ihr Domänencontroller LDAPS unterstützt, können Sie erzwingen, dass alle Verbindungen der SQL Server-Instanz mit den Domänencontrollern über LDAPS erfolgen. Führen Sie den Bash-Befehl ldapsearch -H ldaps://contoso.com:3269 aus, um zu überprüfen, ob der Client den Domänencontroller über LDAPS kontaktieren kann. Wenn Sie festlegen möchten, dass SQL Server nur LDAPS verwendet, führen Sie Folgendes aus:

sudo mssql-conf set network.forcesecureldap true
systemctl restart mssql-server

Dann wird LDAPS vor SSSD verwendet, wenn der Active Directory-Domänenbeitritt auf dem Host über das SSSD-Paket erfolgt ist und die Option disablesssd nicht auf TRUE festgelegt wurde. Wenn sowohl disablesssd als auch forcesecureldap auf TRUE festgelegt sind, wird das LDAPS-Protokoll gegenüber Aufrufen der OpenLDAP-Bibliothek bevorzugt, die von der SQL Server-Instanz ausgeführt werden.

Vorgehensweise ab Version SQL Server 2017 CU 14

Ab SQL Server 2017 (14.x) CU 14 können Sie auch die Option enablekdcfromkrb5 verwenden, um zu erzwingen, dass die SQL Server-Instanz anstelle eines DNS-Reverse-Lookups für den KDC-Server die krb5-Bibliothek für die KDC-Suche verwendet. Voraussetzung dafür ist, dass die SQL Server-Instanz mithilfe eines Drittanbieters mit dem Active Directory-Domänencontroller verknüpft und die Option disablesssd auf TRUE festgelegt wurde, sodass OpenLDAP-Aufrufe für die allgemeine Active Directory-Suche verwendet werden.

Dies kann in Szenarios nützlich sein, in denen Sie die Domänencontroller, mit denen die SQL Server-Instanz kommuniziert, manuell konfigurieren möchten. Sie können den OpenLDAP-Bibliotheksmechanismus mithilfe der KDC-Liste in der Datei krb5.conf verwenden.

Legen Sie zuerst disablesssd und enablekdcfromkrb5conf auf TRUE fest, und starten Sie dann die SQL Server-Instanz neu:

sudo mssql-conf set network.disablesssd true
sudo mssql-conf set network.enablekdcfromkrb5conf true
systemctl restart mssql-server

Konfigurieren Sie anschließend wie folgt die KDC-Liste in der Datei /etc/krb5.conf:

[realms]
CONTOSO.COM = {
  kdc = dcWithGC1.contoso.com
  kdc = dcWithGC2.contoso.com
}

Es wird zwar nicht empfohlen, aber es ist trotzdem möglich, Hilfsprogramme wie realmd zu verwenden, die SSSD einrichten, während der Linux-Host der Domäne beitritt, wenn Sie die Option disablesssd auf TRUE festlegen, sodass die SQL Server-Instanz OpenLDAP-Aufrufe anstelle von SSSD für Aufrufe im Zusammenhang mit Active Directory verwendet.

Hinweis

Die Anmeldung bei SQL Server mithilfe eines FQDN (z. B. CONTOSO.COM\Username) wird nicht unterstützt. Verwenden Sie das Format CONTOSO\Username.

Anmeldungen bei SQL Server aus lokalen Domänengruppen werden nicht unterstützt. Verwenden Sie stattdessen globale Sicherheitsdomänengruppen.

Zugehöriger Inhalt

• Verschlüsseln von Verbindungen mit SQL Server unter Linux
• Grundlegendes zur Active Directory-Authentifizierung für SQL Server für Linux und Container
• Problembehandlung für Active Directory-Authentifizierung für SQL Server für Linux und Container

Zur SQL-Dokumentation beitragen

Wussten Sie schon, dass Sie SQL-Inhalte selbst bearbeiten könnten? Hierdurch helfen Sie nicht nur mit, unsere Dokumentation zu verbessern, sondern Sie werden auch als Mitwirkender an der Seite aufgeführt.

Weitere Informationen finden Sie unter Mitwirken an der SQL Server-Dokumentation.