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
