[IIS 6] connection ODBC qui passe pas [Résolu]

[sevyc64]

Salut à tous,

Je rencontre un soucis sur un site intranet que je suis en train de développer en asp.net (framework 4.0).
Mon site utilise entre-autre une connexion ODBC via une source DSN système (base SAGE proprio).

Sur mon poste de développement (W7-64, IIS7.5), je ne rencontre aucun problème.
Sur le serveur de prod (WS2003-32, IIS6), la connexion ODBC est refusée avec le message "File access denied", lors du .Open sur mon objet connexion, comme si le login/mpd n'était pas bon.

Évidemment la chaine de connexion est bonne, les login et mdp passés sont corrects.
La source ODBC fonctionne correctement, avec Excel ou avec SQLServer ou elle est aussi utilisée en tant que serveur lié.

J'ai l'impression que le soucis de trouve au niveau de l'appel de la source par IIS. J'ai vérifié les droits des comptes, tant IUSR_xx que le compte "Service réseau" qui est le compte d'authentification de mon site.

Je ne sais plus ou chercher pour résoudre le problème.

Il me reste plus que ça pour basculer la prod et j'ai déjà une semaine de retard.

[JML19]

Bonsoir

As-tu regardé ce fichier ==> Logtemp.sql dans le répertoire ===> systemroot\System32\Inetsrv

Regarde (ICI) sur le support de Microsoft.

[sevyc64]

J'avais vu cette page, mais pas trop compris la finalité. A priori ça permettrait de faire un log des connexions.

Je vais essayer de le mettre en place, pour voir si ça me donne des pistes pour résoudre mon problème, sinon ça m’intéresse peu.
Mais vu que ça passe aussi par un lien ODBC, si j'ai le même problème avec celui-ci ça va pas aller.

Faut vraiment que je résous ce problème, j'ai pas de solution de repli.


EDIT :
Vérification faite, les logs sont déjà activés mais dans un fichier texte étendu, et cela ne me donne rien de pertinent comme info. Ce lien en faite pour faire les log dans une base SQL plutot qu'un fichier texte, mais j'imagine que les données stockées sont les mêmes.

[JML19]

Sur une commande open il y a une option d'appartenance il me semble.

Le compte est propriétaire de toute l'arborescence.

Je pense que le problème vient de Windows Serveur 2003.

Peux tu faire un essai de création de l'utilisateur qui te sert de login et son mot de passe comme administrateur local du serveur (dans le groupe administrateur).

[sevyc64]

Quel login, celui passé dans la DSN ?
C'est un compte propre à la base de données, qui n'a rien à voir avec les comptes utilisateurs du domaine.

La DSN, avec ce même login, fonctionne parfaitement avec Excel, SQLServer ou même une autre application .Net sur ce même serveur. Il n'y a que lorsque elle est appelée par IIS que ça passe pas.

Quant au compte de IIS, il est configuré sur "Service réseau"

[JML19]

Entre Windows 7 64 et Windows serveur 2003 il n'y a qu'une histoire de Domaine pour le reste tout est identique.

Pour configurer une Data Source Nane il faut être utilisateur du Domaine.

[sevyc64]

Pas de problème à ce niveau là.

Le serveur en question est contrôleur AD, et je suis utilisateur du domaine et temporairement administrateur aussi, le temps de la mise en prod

[JML19]

As-tu fait un essai sur une session administrateur du domaine ?

[sevyc64]

Oui il me semble, je retenterais dès que je pourrais avoir un accès physique au serveur, mais j'ai pas souvenir que le site ait marché une seule fois sur le serveur (alors que sur mon poste, il marche entièrement)

[sevyc64]

En fouillant dans les tréfonds d'un forum sur sage, j'ai trouvé.

Concernant le problème avec le driver ODBC de Sage, ça viendrait du fait que le dit-drivers demanderais des accès fichiers qui ne peuvent pas être autorisés par l'authentification du site web.

Mais peut-être que ça peut marcher pour d'autres cas.

La solution :
Mettre <identity impersonate="true" /> dans le web.config, dans la section <system.web> </system.web>

[Mat.M]

Salut pas certain mais ça peut provenir aussi des dll de MDAC qui ne sont pas assez récentes

[sevyc64]

Peut-être, mais je pense pas.

De ce que j'ai pu glané sur le net (certains ont mis à jour le MDAC sans résoudre le problème) ça se situe bien au niveau de IIS avec une source ODBC. Et IIS6 est pas mal représenté dans ce problème.

Si c’était un problème de MDAC, ma source ne marcherais pas avec Excel ou SQLServer, or elle marchait très bien, alors qu'avec IIS, non.
D'ailleurs elle ne donnais pas l'impression de ne pas marcher. Le driver refusait la connexion à la base comme lorsque l'authentification n'est pas bonne