SQL Server sous Linux : Active Directory et authentification Kerberos

Vous le savez probablement, SQL Server, à compter de la version 2017, est disponible sous Linux et Docker. J’ai déjà écrit plusieurs articles et donné des conférences à ce sujet.

Si vous vous remémorez les écrans d’installation de SQL Server sous Windows (ou bien la ligne de commande de l’installation de SQL Server), vous devez spécifier le mode d’authentification. Pour rappel, l’authentification correspond à la phase de Login dans SQL Server où vous vous présentez avec une identité, vous devez prouvez qui vous êtes.

Pour SQL Server, il existe deux possibilités pour s’authentifier :

• Authentification SQL : la vérification du mot de passe est faite par SQL server. Celui-ci doit stocker à la fois le nom de connexion (le login) et le mot de passe. Lorsqu’une demande de connexion, c’est SQL Server qui a la charge de la vérification de conformité du couple Login / Password.
• Authentification Windows : Dans ce mode, l’authentification est faite par un acteur tiers, Windows dans notre cas. Soit au travers de la SAM locale soit au travers de Active Directory (NTLM ou Kerberos). Dans ce cas, SQL Server ne connait que le login et accepte la connexion car la vérification de l’identité de la connexion s’est faite au niveau infrastructure, en amont.

Cela se traduit par les options d’installation / configuration :

• Mode Windows seulement : seul les logins authentifiés Windows peuvent se connecter à SQL Server
• Mode Mixte : les connexions authentifiées par Windows et les connexions SQL sont autorisées.

Le fait que SQL Server s’exécute sous Linux ne signifie pas forcément que l’on doive exclure les clients souhaitant s’authentifier au travers d’Active Directory. L’ajout de quelques packages et quelques lignes de commandes suffisent.

Pour la démonstration, j’ai choisi d’installer (rapidement) SQL Server 2017 sur CentOS au travers du code suivant :

sudo curl -o /etc/yum.repos.d/mssql-server.repo https://packages.microsoft.com/config/rhel/7/mssql-server-2017.repo

sudo yum install -y mssql-server

sudo /opt/mssql/bin/mssql-conf setup

 

On peut confirmer que tout fonctionne au niveau du service

systemctl status mssql-server

Il est également possible de se connecter via SSMS :

 

Tout comme pour Windows, le prérequis pour joindre une machine au domaine consiste à spécifier le serveur DNS lié à votre AD. Dans mon cas, CentOS a récupéré une @IP via un serveur DHCP mais le serveur DNS paramétré dans le scope DHCP n’est pas mon contrôleur de domaine. Il me faut donc modifier légèrement ma configuration IP dans CentOS pour donner les bonnes valeurs.

sudo nano /etc/sysconfig/network-scripts/ifcfg-eth0

pour ajouter les lignes suivantes :

PEERDNS=no

DNS1=192.168.1.101

Ensuite, je positionne le bon suffixe DNS

sudo hostnamectl set-hostname SQL14CentOS.conseilit.local

hostname

On applique les modifications, puis on vérifie le tout :

sudo systemctl restart network

sudo cat /etc/resolv.conf

 

Il faut à présent ajouter quelques packages pour se joindre au domaine :

sudo yum install realmd krb5-workstation samba-common-tools sssd oddjob oddjob-mkhomedir adcli oddjob oddjob-mkhomedir adcli -y

La commande REALM permet ensuite de joindre la machine au domaine.

sudo realm join conseilit.local

cat /etc/krb5.conf

Il est possible de vérifier le bon enregistrement dans le domaine au travers de NSLOOKUP :

Tout comme il est possible de vérifier directement dans le DNS et dans Active Directory

Pour les curieux, l’OS est bien renseigné en tant que RedHat Linux …

 

On peut aussi vérifier qu’il est possible d’acquérir un ticket Kerberos de la part du serveur Active Directory :

kinit administrator@CONSEILIT.LOCAL

klist

Tout semble donc opérationnel. Cependant, il faut que le compte de service SQL soit également un compte de l’AD pour que l’authentification fonctionne.

Pour cela nous allons créer un compte de service et créer un SPN pour le service SQL. Cela s’effectue par exemple en PowerShell sur le contrôleur de domaine.

New-ADUser mssql-AccountPassword (Read-Host -AsSecureString « Enter Password ») -PasswordNeverExpires $true -Enabled $true

setspn -a MSSQLSvc/SQL14CentOS.conseilit.local:1433 mssql

setspn -L SQL14CentOS

setspn -L mssql

Ensuite, il faut obtenir le ticket kerbéros pour le compte de service, sur le serveur SQL

kinit mssql@CONSEILIT.LOCAL

klist -A

Pensez à récupérer le numéro de version dont nous aurons besoin plus tard :

kvno MSSQLSvc/SQL14CentOS.conseilit.local:1433

Pour ma part, la version 2 est retournée, je l’ai donc positionné à la suite du paramètre -k dans les lignes de code du ktutil pour créer un fichier keytab.

addent -password -p MSSQLSvc/SQL14CentOS.conseilit.local:1433@CONSEILIT.LOCAL -k 2 -e aes256-cts-hmac-sha1-96

addent -password -p MSSQLSvc/SQL14CentOS.conseilit.local:1433@CONSEILIT.LOCAL -k 2 -e rc4-hmac

wkt /var/opt/mssql/secrets/mssql.keytab

rkt /etc/krb5.keytab

list

Il faut à présent supprimer les entrées n’étant pas au format « computername$@domain.com. ». Pour la capture d’écran précédents, il ne doit rester que les entrées encadrées de rouge.

Pour supprimer les lignes : delent [slot]

J’ai opté pour une stratégie « à partir de la fin » pour éviter de supprimer les slots que je dois conserver. Pour l’exemple, regardez les 2 delent de la fin qui sont tous les deux sur le slot 1…

Attention : clear supprime toutes les entrées. Si vous supprimez trop d’information, pas de panique. Reprenez à l’étape addent …

On écrit valide le fichier keytab (commande wkt) et on vérifie que tous est correct :

wkt /var/opt/mssql/secrets/mssql.keytab

rkt /var/opt/mssql/secrets/mssql.keytab

list

quit

On donne à présent les permissions et le propriétaire du fichier keytab pour automatiser la signature dans le domaine à chaque démarrage :

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

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

sudo /opt/mssql/bin/mssql-conf set network.kerberoskeytabfile /var/opt/mssql/secrets/mssql.keytab

sudo systemctl restart mssql-server

Une fois que le service SQL a redémarré, il est alors possible de se connecter à l’instance via une authentification Windows alors que SQL server est hébergé sur Linux.

Je ne vous cacherai pas que la procédure me parait assez fastidieuse, mais parfaitement fonctionnelle. 

Happy SQL Kerberos Linux