Pourquoi SQL Server via un VPN retombe-t-il encore sur NTLM ?

Votre connexion fonctionne, l’ouverture de session est acceptée et SQL Server utilise NTLM alors que tout le monde attendait Kerberos. Ce résultat n’est pas un défaut du VPN, car un tunnel ne fournit qu’un chemin ; le schéma a été déterminé par le nom demandé par le client, le principal enregistré dans l’annuaire et le ticket que le client a réellement pu obtenir. Trois conditions doivent être réunies en même temps, et la session elle-même indique laquelle a cédé. Lisez cela avant que quiconque modifie un nom de principal de service.

La session nomme le schéma que vous avez réellement obtenu

Le schéma d’authentification appartient à une connexion et non à un serveur ou à un tunnel, la vérification doit donc s’exécuter dans la session qui vous intéresse. Exécutez la requête ci-dessous depuis le même client, outil et compte qui ont produit le rapport, et notez le nom cible et le transport à côté du résultat.

SELECT session_id, auth_scheme, net_transport, client_net_address, login_name
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;

Une ligne provenant d’une fenêtre SSMS locale sur l’hôte de la base de données décrit une tout autre connexion, et c’est pourquoi la requête doit s’exécuter côté client. Enregistrez la sortie avec un horodatage, car la prochaine personne qui la lira demandera quand elle a été prise. Lorsque plusieurs applications partagent un point de terminaison, prélevez un échantillon de chacune, car une différence de source de données entre deux applications constitue souvent toute l’histoire.

Première condition : le nom correspond-il au SPN ?

Kerberos authentifie un service nommé, le client demande donc à l’annuaire un ticket pour un principal précis. Pour le fournisseur TCP, la forme documentée est MSSQLSvc/ suivie du nom d’hôte pleinement qualifié et, pour une instance par défaut, du port. Une instance nommée enregistre MSSQLSvc/db01.corp.example:SQLPROD, où le suffixe est le nom de l’instance au lieu d’un numéro. Atteindre l’écouteur via un alias, un CNAME qui se résout ailleurs ou une adresse IP nue modifie le nom demandé, et une demande sans principal correspondant n’a aucun ticket à renvoyer.

C’est pourquoi une application fonctionne sur un réseau et retombe sur un autre : une réponse DNS, un enregistrement d’alias ou une entrée hosts ont changé le nom utilisé par le client. Comparez le nom demandé à ce que contient l’annuaire avant de toucher à l’enregistrement.

Deuxième condition : le SPN est-il sur le bon compte ?

Un SPN doit appartenir au compte qui exécute le service SQL, pas au compte du client et pas, par accident, à un objet ordinateur. SQL Server peut enregistrer ses propres SPN au démarrage lorsque son compte de service dispose de l’autorisation de les écrire, ce qui est pratique et explique aussi comment un doublon apparaît après un changement de compte de service.

Interrogez l’annuaire pour le nom attendu, puis listez ce que le compte possède réellement. Quel objet détient l’entrée importe plus que la présence du nom quelque part dans la forêt. Une incohérence signifie que l’ouverture de session n’a jamais été le problème, et le guide SPN de Microsoft documente les formats et les cas où un administrateur de domaine doit créer l’entrée.

setspn -Q MSSQLSvc/db01.corp.example:1433
setspn -L CORP\svc-sql01

Ajouter une autre entrée n’est pas une expérience sûre. Un doublon ou un enregistrement conflictuel peut casser des clients qui fonctionnaient, inspectez donc la propriété avant la modification et revérifiez-la ensuite.

Troisième condition : le client peut-il seulement obtenir un ticket ?

Un SPN correct est inutile si le client ne peut pas joindre un contrôleur de domaine ou n’a pas de contexte d’informations d’identification exploitable. L’échange a besoin du KDC et du DNS à travers le VPN, et un tunnel qui n’achemine que le port SQL échoue précisément à cette étape. La joignabilité doit être testée depuis la même machine et le même compte, pas depuis le pare-feu qui les précède.

Inspectez le cache de tickets sur la machine et sous le compte qui exécute l’application. Une liste à l’échelle de la machine depuis une fenêtre élevée ne dit rien d’un service exécuté sous un autre utilisateur, et un cache vide pour cet utilisateur est une constatation et non une gêne.

klist
klist -li 0x3e7

Décidez ensuite ce qu’un repli peut faire. Si la stratégie exige Kerberos, NTLM doit être refusé explicitement, car un repli silencieux transforme une erreur de configuration en une connexion fonctionnelle qui enfreint l’exigence. Si NTLM reste acceptable pour certaines applications, nommez-les et cessez de traiter chaque session NTLM comme un incident.

Changer le lanceur est une variable, pas un correctif

Lancer SSMS sous une autre information d’identification peut guérir une identité sortante involontaire, ce qui est une véritable classe de problème. Cela ne prouve rien sur le nom cible, l’enregistrement ou le chemin du ticket, et ne change pas ce que le serveur a accepté.

Gardez la comparaison maîtrisée : même point de terminaison, même fournisseur, un contexte d’exécution connu, puis une nouvelle connexion dont vous inspectez le schéma. Confirmez l’ouverture de session acceptée et ses autorisations de base de données séparément, car l’accès et l’authentification échouent pour des raisons différentes.

Lorsque Kerberos est exigé, notez pourquoi le premier chemin a échoué, appliquez une correction et réexécutez la requête depuis le même client. Une requête réussie après un changement de lanceur est une preuve d’accès, et ce n’est pas encore la preuve que l’exigence d’authentification a été satisfaite.