Le VPN se connecte, mais SQL Server refuse l’authentification Windows

Les tunnels montent, les serveurs répondent au ping, et la connexion à la base de données échoue toujours avec une erreur d’authentification. Cette combinaison est courante sur les liaisons VPN et signifie rarement que le réseau est cassé, car un écouteur joignable et une connexion acceptée sont deux résultats différents. L’identité qui a satisfait la passerelle n’est pas forcément celle que le client de base de données présente. Déterminer quel compte est arrivé, c’est toute la tâche.

Le symptôme : serveur joignable, connexion refusée

Un délai d’attente vous dit que le paquet n’a jamais atteint un écouteur. Une erreur d’authentification vous dit que l’écouteur a répondu et a refusé les informations d’identification. Ces deux messages vous envoient vers des équipes différentes, et les confondre coûte une journée sur des règles de pare-feu qui n’ont jamais été le problème.

Quand l’erreur est un échec de connexion, arrêtez de regarder les ports. La question restante est de savoir quelle identité Windows le client a présentée, si le serveur a accepté cette identité et si elle s’est résolue en un utilisateur de base de données disposant d’une autorisation.

Deux identités, un tunnel

Le compte VPN s’authentifie auprès de la passerelle et, dans la plupart des déploiements, s’arrête là. Le client de base de données présente séparément un jeton Windows, pris dans le processus qui l’exécute, ou une connexion SQL si la chaîne de connexion en demande une. Un utilisateur VPN local à la passerelle n’a aucune relation avec le domaine qui héberge SQL Server, et le tunnel n’en crée pas.

Connecter une machine personnelle à un VPN ne l’intègre pas non plus au domaine. Renommer un compte local et aligner son mot de passe sur celui d’un utilisateur du domaine n’est pas une procédure d’enrôlement, et cela produit un jeton que le contrôleur de domaine n’acceptera pas comme cet utilisateur.

Certains clients natifs d’accès distant de Windows peuvent réutiliser les informations d’identification VPN pour des ressources réseau lorsque leur profil est configuré ainsi. Ce comportement appartient à un client et à un profil précis, pas aux connexions VPN en général, donc vérifiez-le pour le client utilisé au lieu de le supposer.

Lisez le mode demandé par le client

La chaîne de connexion décide quel chemin d’authentification le client emprunte. La sécurité intégrée utilise le jeton Windows ; une paire utilisateur et mot de passe sélectionne une connexion SQL. Ce sont des modes distincts dans la configuration du serveur, et un seul peut être activé pour une tentative de connexion donnée.

Server=tcp:sql.lab.example,1433;Database=ops;Integrated Security=SSPI;Encrypt=True;TrustServerCertificate=False;

Passer à une connexion SQL parce que la connexion Windows a échoué est un contournement qui masque la question de l’identité, et il exige de toute façon la création d’une nouvelle connexion et d’un mot de passe. Si le déploiement impose l’authentification Windows, gardez le mode et corrigez le chemin d’identité. Une connexion SQL a aussi besoin de ses propres autorisations, donc le contournement achète un second compte à maintenir.

Vérifiez aussi quelle application se connecte. Un service exécuté sous un compte système, une tâche planifiée et une fenêtre de requête interactive peuvent présenter trois jetons différents sur la même machine, et seul le dernier correspond à ce que l’utilisateur voit lorsqu’il exécute whoami.

Demandez au serveur ce qu’il a réellement vu

Le serveur peut vous dire quelle connexion il a résolue et comment la connexion s’est authentifiée. Exécutez la requête dans la session étudiée, car une connexion réussie distincte de l’administrateur ne prouve rien sur le client qui échoue.

SELECT ORIGINAL_LOGIN() AS original_login,
       SUSER_SNAME() AS current_context;
SELECT auth_scheme, net_transport
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;

La première ligne distingue la connexion qui a ouvert la session du contexte de sécurité en vigueur maintenant, et ces deux éléments diffèrent sous emprunt d’identité. La seconde nomme le schéma d’authentification, de sorte que KERBEROS, NTLM et SQL deviennent des faits visibles au lieu de suppositions. Une connexion qui signale NTLM là où vous attendiez Kerberos est un problème de résolution de noms ou de SPN, pas un problème de mot de passe.

Le numéro d’erreur précise encore. L’état 5 signifie généralement que le nom de connexion n’a pas été résolu du tout, l’état 8 signifie généralement que le mot de passe ne correspondait pas, et l’état 11 signifie que les informations d’identification ont été acceptées mais que l’accès au serveur a échoué. Demandez l’état à l’administrateur plutôt que le message entier, car le message seul est volontairement vague.

Quand l’identité arrive et que Kerberos échoue encore

Si le serveur voit l’identité Windows visée et que l’authentification intégrée échoue encore, c’est l’échange lui-même qui pose problème. Kerberos a besoin du nom principal de service enregistré pour le compte de service SQL et d’un client qui demande le service par un nom correspondant. Se connecter par adresse IP ne peut pas correspondre à un SPN fondé sur un nom, et un alias ne peut correspondre que s’il est lui aussi enregistré. Vérifiez d’abord le nom saisi par le client, car une connexion qui fonctionne par nom d’hôte et échoue par IP décrit exactement ce problème.

Demandez à l’administrateur de revoir l’identité enregistrée et le compte de service plutôt que de créer des SPN en double par tâtonnements. Les enregistrements en double produisent des pannes intermittentes plus difficiles à diagnostiquer que le problème d’origine.

Une fois l’authentification fonctionnelle, la connexion a encore besoin d’un utilisateur de base de données et d’autorisations. Une connexion VPN réussie, une connexion Windows réussie et l’autorisation de lire une table donnée sont trois résultats distincts, et chacun mérite sa propre vérification avant la clôture du ticket.