Partage via

Découvrir l’authentification Active Directory pour SQL Server sur Linux et les conteneurs

  • Article

S’applique à : SQL Server - Linux

Cet article donne des informations sur le fonctionnement de l’authentification Active Directory pour SQL Server dans un déploiement sur Linux ou des conteneurs.

Concepts

LDAP (Lightweight Directory Access Protocol)

LDAP est un protocole d’application permettant d’utiliser divers services d’annuaire, parmi lesquels Active Directory. Ces services stockent des informations sur les utilisateurs et les comptes, ainsi que des informations de sécurité (par exemple des mots de passe). Ces données sont chiffrées, puis partagées avec d’autres appareils sur le réseau.

Pour savoir comment sécuriser le protocole LDAP, consultez Guide pratique pour activer la connexion LDAP dans Windows Server.

Kerberos

Kerberos est un protocole d’authentification qui permet de vérifier l’identité d’un utilisateur ou d’un ordinateur hôte. Vous pouvez le considérer comme un moyen de vérifier le client et le serveur.

Lorsque vous travaillez dans un environnement hétérogène (mixte) comportant des serveurs et des clients Windows et non Windows, vous devez utiliser deux types de fichiers avec les services d’annuaire Active Directory :

  • Fichiers keytab (abréviation de « key table », « table de clés »)
  • Fichiers de configuration de Kerberos (krb5.conf ou krb5.ini)

Qu’est-ce qu’un fichier keytab ?

Sur les systèmes Linux et Unix, les processus serveur ne peuvent pas être configurés pour exécuter des processus avec un compte de service Windows. Si vous souhaitez qu’un système Linux ou Unix se connecte automatiquement à Active Directory au démarrage, utilisez un fichier keytab.

Un fichier keytab est un fichier de chiffrement qui contient la représentation d’un service protégé par Kerberos et la clé à long terme du nom de principal du service associé dans le centre de distribution de clés (KDC, Key Distribution Center). La clé ne correspond pas au mot de passe proprement dit.

Les fichiers keytab permettent d’effectuer les opérations suivantes :

  • Authentifier le service proprement dit auprès d’un autre service sur le réseau
  • Déchiffrer le ticket de service Kerberos d’un utilisateur d’annuaire entrant sur le service

Qu’est-ce qu’un fichier krb5.conf ?

Le fichier /etc/krb5.conf (également appelé krb5.ini) fournit les entrées de configuration des bibliothèques KRB5 (Kerberos v5) et GSSAPI (GNU Simple Authentication and Security Layer API).

Parmi ces informations figurent le domaine par défaut, les propriétés de chaque domaine (par exemple les centres de distribution de clés) et la durée de vie du ticket Kerberos par défaut.

Ce fichier est indispensable au fonctionnement de l’authentification Active Directory. krb5.conf est un fichier INI, mais chaque valeur de la paire clé-valeur peut être un sous-groupe délimité par { et }.

Pour plus d’informations sur le fichier krb5.conf, consultez la documentation MIT Kerberos Consortium.

Configurer Kerberos pour SQL Server sur Linux

Il s’agit des valeurs dont vous avez besoin sur le serveur hôte exécutant SQL Server sur Linux. Si vous avez d’autres services (non SQL Server) en cours d’exécution sur le même hôte, plusieurs entrées supplémentaires peuvent être nécessaires dans votre fichier krb5.conf.

Voici un exemple de fichier krb5.conf à titre de référence :

[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 : la valeur default_realm doit être présente. Elle spécifie le domaine auquel appartient l’ordinateur hôte.

  • realms (facultatif) : pour chaque domaine, la valeur kdc peut être définie de façon à indiquer quels centres de distribution de clés l’ordinateur doit contacter lors de la recherche de comptes Active Directory. Si vous avez défini plusieurs centres de distribution de clés, celui de chaque connexion est sélectionné par tourniquet (round robin).

  • domain_realm (facultatif) : les mappages de chaque domaine peuvent être fournis. Si ce n’est pas le cas, SQL Server sur Linux suppose que le domaine contoso.com correspond au domaine CONTOSO.COM.

Processus d’authentification Kerberos

Les deux premières étapes pour obtenir un ticket TGT (Ticket-Granting Ticket) sont les mêmes que pour l’authentification Kerberos sur Windows :

  • Un client commence le processus de connexion en envoyant son nom d’utilisateur et son mot de passe (chiffré) au contrôleur de domaine.

  • Après avoir vérifié le nom d’utilisateur et le mot de passe par rapport à son stockage interne, le contrôleur de domaine renvoie au client un ticket TGT pour l’utilisateur.

SQL Server sur Linux utilise le fichier keytab pour lire le mot de passe du nom de principal du service (SPN, Service Principal Name). Il déchiffre ensuite l’objet blob chiffré, dont il se sert pour autoriser la connexion. Les étapes suivantes décrivent ce processus.

  • Une fois l’utilisateur en possession du ticket TGT, le client démarre une connexion à SQL Server en spécifiant le nom d’hôte et le port de l’instance SQL.

  • Le client SQL crée en interne un nom de principal du service au format MSSQLSvc/<host>:<port> Format codé en dur dans la plupart des clients SQL Server.

  • Le client commence l’établissement d’une liaison Kerberos en demandant au contrôleur de domaine une clé de session pour ce nom SPN. Le ticket TGT et le nom SPN sont envoyés au contrôleur de domaine.

Diagramme montrant l’authentification Active Directory pour SQL Server sur Linux – Ticket-Granting Ticket et nom de principal du service envoyés au contrôleur de domaine.

  • Une fois que le contrôleur de domaine a validé le ticket TGT et le nom SPN, il envoie la clé de session au client pour se connecter au nom SPN SQL Server.

Diagramme montrant l’authentification Active Directory pour SQL Server sur Linux – Clé de session retournée au client par le contrôleur de domaine.

  • L’objet blob chiffré de la clé de session est envoyé au serveur.

Diagramme montrant l’authentification Active Directory pour SQL Server sur Linux – Clé de session envoyée au serveur.

  • SQL Server lit le mot de passe du nom SPN à partir de son fichier keytab (mssql.keytab), un fichier sur le disque contenant des tuples (nom SPN, mot de passe).

  • QL Server déchiffre l’objet blob chiffré du client avec le mot de passe qu’il vient de rechercher, pour récupérer le nom d’utilisateur du client.

  • SQL Server recherche le client dans la table sys.syslogins pour vérifier qu’il est bien autorisé à se connecter.

  • La connexion est acceptée ou refusée.

Diagramme montrant l’authentification Active Directory pour SQL Server sur Linux – Connexion acceptée ou refusée.

Configurer Kerberos pour des conteneurs SQL Server

L’authentification Active Directory pour SQL Server dans les conteneurs est quasiment identique à celle pour SQL Server sur Linux. La seule différence est le nom SPN de l’hôte SQL Server. Dans le scénario précédent, il s’agissait de MSSQLSvc/<host>:<port> parce que nous étions connectés avec le nom de l’hôte SQL Server. Maintenant toutefois, nous devons nous connecter au conteneur.

Dans le cas des conteneurs SQL Server, vous pouvez créer le fichier krb5.conf à l’intérieur du conteneur. Le nœud hôte exécutant le conteneur n’a pas besoin d’être membre du domaine, mais il doit être en mesure d’atteindre le contrôleur de domaine auquel le conteneur essaiera de se connecter.

Étant donné que nous nous connectons à un conteneur, le nom du serveur dans la connexion cliente peut être différent du simple nom d’hôte. Il peut aussi s’agir du nom du conteneur ou d’un autre alias. En outre, il y a de bonnes chances que le port exposé pour SQL Server ne soit pas le port 1433 par défaut.

Vous devez utiliser le nom SPN qui est stocké dans mssql.keytab pour vous connecter au conteneur SQL Server. Par exemple, si le nom SPN dans mssql.keytab est MSSQLSvc/sqlcontainer.domain.com:8000, vous devez utiliser sqlcontainer.domain.com,8000 comme chaîne de connexion dans le client (notamment sqlcmd, SQL Server Management Studio et Azure Data Studio).

Diagramme montrant l’authentification Active Directory pour les conteneurs SQL Server.

Actualisation du groupe SQL Server

Vous vous demandez peut-être pourquoi il existe un compte d’utilisateur dans le fichier keytab alors que vous avez seulement besoin d’un nom de principal du service pour vous authentifier.

Supposons que vous disposiez d’un utilisateur adUser, membre d’un groupe adGroup. Si adGroup est ajouté comme session à SQL Server, alors adUser possède également l’autorisation de se connecter à l’instance SQL. Lorqu’un adUser est encore connecté à SQL Server, un administrateur de domaine peut supprimer adUser de adGroup. Même si adUser ne dispose plus de l’autorisation de se connecter à SQL Server, il est connecté, car il a déjà passé le processus d’authentification Kerberos.

Nous exécutons régulièrement un processus appelé actualisation du groupe pour vous protéger contre le scénario dans lequel un utilisateur connecté n’est plus autorisé à effectuer une action privilégiée (par exemple la création d’une connexion ou la modification d’une base de données).

SQL Server possède un compte Active Directory privilégié qu’il utilise pour actualiser le groupe. Ce compte est configuré à l’aide de mssql-conf avec le paramètre network.privilegedadaccount ou correspond par défaut au compte de l’ordinateur hôte (<hostname>$).

Les informations d’identification du compte privilégié situées dans mssql.keytab sont utilisées pour emprunter l’identité du client (adUser dans cet exemple). SQL Server procède à l’établissement d’une liaison Kerberos avec lui-même pour identifier les informations d’appartenance au groupe. Il les compare à sys.syslogins pour vérifier si adUser dispose toujours des autorisations nécessaires pour se connecter et exécuter les commandes Transact-SQL demandées. Si adUser a été supprimé de adGroup, SQL Server met fin à la connexion.

L’actualisation du groupe a les deux prérequis suivants :

  • Connectivité réseau entre l’instance SQL Server et le domaine Active Directory local.
  • Confiance bidirectionnelle entre le domaine auquel SQL Server est connecté et le domaine Active Directory local. Pour plus d’informations, consultez Comprendre Active Directory.

Contenu connexe