Tutoriel : Utiliser l’authentification Active Directory avec SQL Server sur Linux

S’applique à :SQL Server - Linux

Ce tutoriel explique comment configurer SQL Server sur Linux pour prendre en charge l’authentification Active Directory, également appelée authentification intégrée. Pour une vue d’ensemble, consultez Authentification Active Directory avec SQL Server sur Linux.

Ce didacticiel contient les tâches suivantes :

• Joindre un hôte SQL Server à un domaine Active Directory
• Créer un utilisateur Active Directory pour SQL Server pour et définir le nom de principal du service (SPN)
• configurer le service SQL Server keytab
• Sécuriser le fichier keytab
• Configurer SQL Server pour utiliser le fichier keytab pour l’authentification Kerberos
• Créer des connexions basées sur Active Directory dans Transact-SQL
• Se connecter à SQL Server à l’aide de l’authentification Active Directory

Prérequis

Avant de configurer l’authentification Active Directory, vous devez :

• Configurer un contrôleur de domaine Active Directory (Windows) sur votre réseau
• Installer SQL Server
  • Démarrage rapide : Installer SQL Server et créer une base de données sur Red Hat
  • Démarrage rapide : Installer SQL Server et créer une base de données sur SUSE Linux Enterprise Server
  • Démarrage rapide : Installer SQL Server et créer une base de données sur Ubuntu

Joindre un hôte SQL Server à un domaine Active Directory

Joignez votre hôte SQL Server Linux à un contrôleur de domaine Active Directory. Pour plus d’informations sur la façon de joindre un domaine Active Directory, consultez Joindre SQL Server sur un hôte Linux à un domaine Active Directory.

Créer un utilisateur Active Directory pour SQL Server pour et définir le nom de principal du service (SPN)

Remarque

Les étapes suivantes utilisent votre nom de domaine complet (FQDN). Si vous êtes sur Azure, vous devez créer un FQDN avant de continuer.

1. Sur votre contrôleur de domaine, exécutez la commande PowerShell New-ADUser pour créer un autre utilisateur Active Directory avec un mot de passe qui n’expire jamais. L’exemple suivant nomme le compte sqlsvc, mais le nom du compte peut être tout ce que vous aimez. Vous serez invité à entrer un nouveau mot de passe pour le compte.

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

   Remarque

   La bonne pratique de sécurité consiste à avoir un compte Active Directory dédié pour SQL Server. De cette façon, les informations d’identification de l’instance SQL Server ne sont pas partagées avec d’autres services utilisant le même compte. Toutefois, vous pouvez éventuellement réutiliser un compte Active Directory existant si vous connaissez son mot de passe (qui est obligatoire pour générer un fichier keytab à l’étape suivante). De plus, le compte doit être activé pour prendre en charge le chiffrement Kerberos AES 128 bits et 256 bits (attribut msDS-SupportedEncryptionTypes) sur le compte d’utilisateur. Pour confirmer que le chiffrement AES est activé pour le compte, localisez le compte dans l’utilitaire Utilisateurs et ordinateurs Active Directory, puis sélectionnez Propriétés. Localisez l’onglet Comptes dans Propriétés et validez que les deux cases à cocher ci-dessous sont sélectionnées.

   1. Ce compte prend en charge le chiffrement AES 128 bits via Kerberos

   2. Ce compte prend en charge le chiffrement AES 256 bits via Kerberos

2. Définissez le nom de principal du service (SPN) pour ce compte à l’aide de l’outil setspn.exe. Le SPN doit être mis en forme exactement comme spécifié dans l’exemple suivant. Vous pouvez trouver le nom de domaine complet de la machine hôte SQL Server en exécutant hostname --all-fqdns sur l'hôte SQL Server. Le port TCP doit être 1433, sauf si vous avez configuré SQL Server pour utiliser un numéro de port différent.

   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
   

   Notes

   Si vous recevez une erreur, Insufficient access rights, vérifiez auprès de votre administrateur de domaine que vous disposez des autorisations suffisantes pour définir un SPN sur ce compte. Le compte utilisé pour inscrire un nom de principal du service doit avoir les autorisations Write servicePrincipalName. Pour plus d’informations, consultez Inscrire un nom de principal du service pour les connexions Kerberos.

   Si vous modifiez le port TCP à l’avenir, vous devez exécuter à nouveau la commande setspn avec le nouveau numéro de port. Vous devez également ajouter le nouveau nom de principal du service au service keytab SQL Server en suivant les étapes décrites dans la section suivante.

Pour plus d’informations, consultez Inscrire un nom de principal du service pour les connexions Kerberos.

configurer le service SQL Server keytab

La configuration de l’authentification Active Directory pour SQL Server sur Linux nécessite un compte Active Directory et le SPN créé dans la section précédente.

Important

Si le mot de passe du compte Active Directory est changé ou si le mot de passe du compte associé aux noms de principal de service est modifié, vous devez mettre à jour le keytab avec le nouveau mot de passe et le numéro de version de la clé (KVNO). Certains services peuvent également faire pivoter les mots de passe automatiquement. Consultez les stratégies de rotation des mots de passe pour les comptes en question et alignez-les avec des activités de maintenance planifiées pour éviter les temps d’arrêt inattendus.

Entrées keytab du SPN

1. Vérifiez le numéro de version de la clé (KVNO) pour le compte Active Directory créé à l’étape précédente. En général, il s’agit de 2, mais il peut s’agir d’un autre entier si vous avez modifié le mot de passe du compte plusieurs fois. Sur la machine hôte SQL Server, exécutez les commandes suivantes :

   • Les exemples ci-dessous supposent que user se trouve dans le domaine @CONTOSO.COM. Remplacez l’utilisateur et le nom de domaine par vos noms d’utilisateur et de domaine.

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

   Notes

   Les noms de principal du service peuvent prendre plusieurs minutes pour se propager dans votre domaine, en particulier si le domaine est volumineux. Si vous recevez l’erreur, kvno: Server not found in Kerberos database while getting credentials for MSSQLSvc/<fully qualified domain name of host machine>:<tcp port>@CONTOSO.COM veuillez patienter quelques minutes, puis réessayez.
   
   Les commandes ci-dessus fonctionnent uniquement si le serveur a été joint à un domaine Active Directory (point abordé dans la section précédente).

2. À l’aide de Ktpass, ajoutez des entrées keytab pour chaque nom de principal du service en utilisant les commandes suivantes dans une invite de commandes Windows :

   • <DomainName>\<UserName> - Compte d’utilisateur Active Directory
   • @CONTOSO.COM - Utilisez votre nom de domaine.
   • /kvno <#> - Remplacez <#> par le numéro de version de clé obtenu à l’étape précédente.
   • <StrongPassword> - Utilisez un mot de passe fort.

   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>
   

   Notes

   Les commandes ci-dessus permettent d’utiliser les méthodes de chiffrement AES et RC4 pour l’authentification Active Directory. RC4 est une méthode de chiffrement plus ancienne. Si un niveau de sécurité plus élevé est nécessaire, vous pouvez créer les entrées keytab avec la méthode de chiffrement AES uniquement. Les deux dernières entrées UserName doivent être en minuscules, sinon l’authentification d’autorisation risque d’échouer.

3. Après l’exécution de la commande ci-dessus, vous devez disposer d’un fichier keytab nommé mssql.keytab. Copiez le fichier sur l’ordinateur SQL Server, dans le dossier /var/opt/mssql/secrets.

4. Sécurisez le fichier keytab.

   Toute personne ayant accès à ce fichier keytab peut emprunter l’identité de SQL Server sur le domaine. Veillez donc à limiter l’accès au fichier de sorte que seul le compte mssql dispose d’un accès en lecture :

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

5. Vous devez définir l’option de configuration suivante avec l’outil mssql-conf pour spécifier le compte à utiliser pour l’accès au fichier keytab.

   sudo mssql-conf set network.privilegedadaccount <username>
   

   Notes

   Entrez uniquement le nom d’utilisateur, et non nomdomaine\nomutilisateur ni nomutilisateur@domaine. SQL Server se charge d’ajouter le nom de domaine au nom d’utilisateur le cas échéant.

6. Suivez les étapes ci-dessous pour configurer SQL Server de façon à commencer à utiliser le fichier keytab pour l’authentification Kerberos.

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

   Conseil

   Désactivez éventuellement les connexions UDP au contrôleur de domaine pour améliorer les performances. Dans de nombreux cas, les connexions UDP échouent régulièrement lors de la connexion à un contrôleur de domaine. Vous pouvez donc définir des options de configuration dans /etc/krb5.conf pour ignorer les appels UDP. Modifiez /etc/krb5.conf et définissez les options suivantes :

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

À ce stade, vous êtes prêt à utiliser les connexions basées sur Active Directory dans SQL Server.

Créer des connexions basées sur Active Directory dans Transact-SQL

1. Connectez-vous à SQL Server et créez une connexion Active Directory :

   CREATE LOGIN [CONTOSO\user] FROM WINDOWS;
   

2. Vérifiez que la connexion est maintenant répertoriée dans l’affichage catalogue système sys. server_principals :

   SELECT name FROM sys.server_principals;
   

Se connecter à SQL Server à l’aide de l’authentification Active Directory

Connectez-vous à une machine cliente avec vos informations d’identification de domaine. Vous pouvez maintenant vous connecter à SQL Server sans entrer à nouveau votre mot de passe grâce à l’authentification Active Directory. Si vous créez une connexion pour un groupe Active Directory, chaque utilisateur Active Directory qui est membre de ce groupe pourra se connecter de la même façon.

Le paramètre de chaîne de connexion à spécifier pour que les clients utilisent l’authentification Active Directory dépend du pilote que vous utilisez. Considérez les exemples dans les sections suivantes.

sqlcmd sur un client Linux joint à un domaine

Connectez-vous à un client Linux joint à un domaine à l’aide de ssh et de vos informations d’identification de domaine :

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

Vérifiez que vous avez installé le package mssql-tools, puis connectez-vous à l’aide de sqlcmd sans spécifier d’informations d’identification :

sqlcmd -S mssql-host.contoso.com

À la différence de SQL Windows, l’authentification Kerberos fonctionne pour la connexion locale dans SQL Linux. Toutefois, vous devez toujours fournir le nom de domaine complet de l’hôte SQL Linux, et l’authentification Active Directory ne fonctionnera pas si vous tentez de vous connecter à ., localhost, 127.0.0.1, etc.

SSMS sur un client Windows joint à un domaine

Connectez-vous à un client Windows joint à un domaine en utilisant vos informations d’identification de domaine. Assurez-vous que SQL Server Management Studio est installé, puis connectez-vous à votre instance de SQL Server (par exemple, mssql-host.contoso.com) en spécifiant l’authentification Windows dans la boîte de dialogue Se connecter au serveur.

Authentification Active Directory à l’aide d’autres pilotes clients

Le tableau suivant décrit les suggestions pour d’autres pilotes clients :

Pilote client	Recommandation
JDBC	Utiliser l'authentification intégrée Kerberos pour se connecter à SQL Server.
ODBC	Utiliser l’authentification intégrée.
ADO.NET	Syntaxe de la chaîne de connexion.

Options de configuration supplémentaires

Si vous utilisez des utilitaires tiers tels que PBIS, VAS, ou Centrify pour joindre l’hôte Linux au domaine Active Directory et que vous souhaitez forcer SQL Server à utiliser la bibliothèque OpenLDAP directement, vous pouvez configurer l’option disablesssd avec mssql-conf comme suit :

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

Remarque

Certains utilitaires, tels que le realmd, sont configurés pour SSSD, tandis que d’autres outils tels que PBIS, VAS et Centrify ne configurent pas SSSD. Si l’utilitaire utilisé pour joindre le domaine Active Directory ne configure pas SSSD, il est recommandé de configurer l’option disablesssd sur true. Bien que ce ne soit pas indispensable, étant donné que SQL Server tentera d’utiliser SSSD pour Active Directory avant de revenir au mécanisme OpenLDAP, il est plus efficace de le configurer afin que SQL Server effectue des appels OpenLDAP directement en ignorant le mécanisme SSSD.

Si votre contrôleur de domaine prend en charge LDAPS, vous pouvez forcer toutes les connexions de SQL Server sur les contrôleurs de domaine à être sur LDAPS. Pour vérifier que votre client peut contacter le contrôleur de domaine via LDAPS, exécutez la commande Bash ldapsearch -H ldaps://contoso.com:3269. Pour définir SQL Server pour utiliser uniquement LDAPS, exécutez la commande suivante :

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

Cette opération utilise LDAPS sur SSSD si la jonction du domaine Active Directory sur l’hôte a été effectuée via le package SSSD et que disablesssd n’a pas la valeur true. Si disablesssd est défini sur true et que forcesecureldap est aussi défini sur true, il utilisera le protocole LDAPS sur les appels de la bibliothèque OpenLDAP effectués par SQL Server.

Publier SQL Server 2017 CU 14

À compter de SQL Server 2017 (14.x) CU14, si SQL Server a été joint à un contrôleur de domaine Active Directory à l’aide de fournisseurs tiers et est configuré pour utiliser des appels OpenLDAP pour la recherche générale Active Directory en définissant disablesssd sur true, vous pouvez également utiliser l’option enablekdcfromkrb5 pour forcer SQL Server à utiliser la bibliothèque krb5 pour la recherche KDC au lieu de la recherche DNS inversée pour le serveur KDC.

Cela peut être utile pour le scénario dans lequel vous souhaitez configurer manuellement les contrôleurs de domaine auxquels SQL Server tente de communiquer. Et vous utilisez le mécanisme de la bibliothèque OpenLDAP à l’aide de la liste KDC dans krb5.conf.

Tout d’abord, définissez disablesssd et enablekdcfromkrb5conf sur true, puis redémarrez SQL Server :

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

Configurez ensuite la liste KDC dans /etc/krb5.conf comme suit :

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

Bien qu’il ne soit pas recommandé, il est possible d’utiliser des utilitaires, tels que realmd, qui configurent SSSD lors de la jonction de l’hôte Linux au domaine, tout en configurant disablesssd sur true pour que SQL Server utilise des appels OpenLDAP à la place de SSSD pour les appels associés à Active Directory.

Remarque

Un compte de connexion SQL Server qui utilise un FQDN (par exemple, CONTOSO.COM\Username) n’est pas pris en charge. Utilisez le format CONTOSO\Username.

Les comptes de connexion SQL Server des groupes locaux de domaine ne sont pas pris en charge. Utilisez à la place des groupes de domaine de sécurité globaux.

Contenu connexe

• Chiffrer les connexions à SQL Server sur Linux
• Découvrir l’authentification Active Directory pour SQL Server sur Linux et les conteneurs
• Résoudre les problèmes liés à l’authentification Active Directory pour SQL Server sur Linux et les conteneurs

Contribuer à la documentation SQL

Saviez-vous que vous pouvez modifier le contenu SQL vous-même ? Dans ce cas, non seulement vous nous aidez à améliorer notre documentation, mais vous êtes également cité en tant que contributeur à la page.

Pour plus d’informations, consultez Guide pratique pour contribuer à la documentation SQL Server