La Voie Du Code

La sagesse populaire veut que dans une chaîne de connexion à SQL Server, Integrated Security=SSPI est “plus ou moins” équivalent à Integrated Security=Yes. C’est ce que je croyais jusqu’au jour où j’ai essayé de faire communiquer un middle tier avec un SQL Server situé sur un serveur ne faisant pas partie du même domaine, en utilisant la sécurité intégrée Windows (integrated security) et le protocole TCP/IP. Comme de bien entendu la première tentative échoue lamentablement avec le message “Cannot generate SSPI context”. Après un googlage intensif, la solution semble être l’utilisation des “named pipes”. Cool, allons-y. Juste pour l’histoire, ma chaîne de connexion ressemble à :

Database=la_base;Server=np:le_serveur;Integrated Security=SSPI;

Le préfixe np: suffit à indiquer au client SQL Server que l’on veut une connexion en named pipes. Et là, ça ne marche vraiment plus du tout. Et après un autre googlage de derrière les fagots, eurêka! En vérité, les named pipes n’utilisent pas SSPI (explication en anglais ici), et le fait de spécifier Integrated Security=SSPI perturbe sérieusement le client SQL Server. En fait Integrated Security=True résoud le problème :

Database=la_base;Server=np:le_serveur;Integrated Security=True;

Moralité : il y a tellement d’informations à ingurgiter que l’on s’empresse de prendre pour argent comptant certaines simplifications, jusqu’au jour où l’horrible vérité vous rattrappe et vous fait perdre quelques heures…