[IIS 8] Connexion à SQL Server avec DOMAIN\MACHINENAME$ au lieu de ApplicationPoolIdentity
Bonjour à tous,
J'ai un serveur fraîchement installé sur lequel j'essai de migrer une application .Net. On passe de IIS 7 sous Windows 2008 R2 à IIS 8 sous Windows 2012.
On recréé exactement la même configuration, notamment pour le pool d'application :
- .Net 4,
- Identité : ApplicationPoolIdentity
On installe également un SQL Server sur cette machine, de sorte que l'application utilise toujours l'instance SQL Server qui est locale.
Et c'est là que les problèmes commencent. Sur la première machine, en prod, tout fonctionne parfaitement. Sur la seconde par contre, impossible d'avoir une connexion à la base de données.
Tout d'abord, l'erreur. Un classique
Citation:
Impossible d'ouvrir la base de données "xxx" demandée par la connexion. La connexion a échoué.
Échec de l'ouverture de session de l'utilisateur 'DOMAIN\MACHINENAME$'.
.
Enfin, presque classique, car la première chose qui m'étonne, c'est le nom de la session utilisateur : DOMAIN\MACHINENAME$. Normalement, vue la manière dont est configuré le pool d'application, cela devrait être quelque chose comme IIS APPPOOL\NomDuPool.
La chaîne de connexion utilisée est des plus classiques : Data Source=.\SQLEXPRESS;Initial Catalog=xxx;Integrated Security=trueD'où ma question : pourquoi cet utilisateur, et pas IIS APPPOOL\NomDuPool comme cela devrait l'être ?? J'aimerais vraiment comprendre, et savoir comment revenir sur cet utilisateur IIS APPPOOL.
Mes investigations :
j'ai l'impression que IIS croit que SQL Server est sur un autre serveur (alors que c'est bien le même). J'ai vérifié qu'en éteignant l'instance l'erreur se changeait en serveur injoignable, et non plus en BD inaccessible.
Info supplémentaire :
j'ai essayé de donner les droits nécessaire à la connexion DOMAIN\MACHINENAME$ au niveau de SQL Server. Et bien ça ne marche pas non plus. Même en créant la connexion et l'utilisateur, et en donnant les accès nécessaires à la BD, cela ne fonctionne pas. Toujours un accès impossible. Mais là n'est pas l'objet de ma question ;)
