Salut j'ai publier une application web asp.net sur le server IIS en local, j'utilise sql serveur 2014 pour 

comme sgbd. Le problème est que l'application publier n'arrive pas à se connecter avec sql server alors que avec visual studio cela marche impecablement.  L'application publiée affiche le message suivant apres exécution:

Impossible d'ouvrir la base de données "PhytoDB" demandée par la connexion. La connexion a échoué.Échec de l'ouverture de session de l'utilisateur 'AUTORITE NT\Système'.

J'ai cherché sur internet malheureusement toutes les solutions proposées ne se rapprochent pas trop de mon problème.

Si vous pouvez m'aider je serais honnoré.

Hola !

L'utilisateur 'Authority NT\System" fait parti des comptes auto-générés par Windows. Et à ma connaissance, il n'est pas trop possible d'y toucher.

Ce qu'il semble être plus faisable par contre, c'est :

1) De vérifier que le process qui tente d'accéder à la base est bien lancé en administrateur. Ca peut potentiellement régler le problème.

2) De regarder les permissions et l'appartenance (dans le sens ownership, peu importe la traduction en Français j'en ai aucune idée).
Le groupe ou utilisateur propriétaire possède toute les permissions relatives au fichier.
Il est possible de voir les permissions d'un utilisateur spécifique en allant dans les propriétés, dans l'onglet sécurité. Et dans les options avancé, on y trouve le propriétaire du fichier. C'est donc là bas qu'on ira faire des modifications.

Donc changer les permissions pour, par exemple, le groupe "Administrators" (si tant est que le process soit lancé en tant qu'admin). Si modification impossible, changer la propriété de l'objet de façon à mettre "Administrators" en tant que propriétaire puis tenter de modifier les permissions de nouveau.

@Sillimon, on ne règle pas un problème en créant d'énormes trou de sécurité. 

SQL Server dispose de 2 modes d'authentification différents, les comptes Windows et les comptes SQL Server.

Le mode d'authentification utilisé est fonction des paramètres dans la chaine de connexion.

Soit vous êtes en authentification "compte SQL Server" et vous devez mettre les informations de connections (login, password) dans la chaine de connexion, soit vous utilisez un compte Windows  et l'authentification se fait via un échange implicite entre SQL Server et le token de sécurité de votre processus (contenant plus ou moins le compte Windows sous lequel le processus tourne).

Le type d'authentification que votre application doit utiliser est fonction de la politique de sécurité qui doit être suivi, donc très largement en amont de la conception de l'application. Avoir ce problème au moment de la publication montre un très gros défaut méthodologique depuis l'analyse même des besoins. Votre chargé de la sécurité informatique aurait dû être mis dans la boucle depuis bien longetmps. Il devrait vous signaler le problème dès l'expression du besoin.

Les 2 modes d'authentifications n'ont pas les mêmes caractéristiques et il faut savoir lequel correspond à votre modèle de sécurité.

Les messages d'erreurs correspondent à une authentification par compte Windows, et par sécurité, le compte "Authority NT\System"

dispose de très très peu de droits et lui en donner rendra la sécurité "lock down by default" totalement inopérant => trous de sécurité.

Soit utilisez l'authentification par compte SQL-Server, soit configurez IIS pour que votre application Web utilise un compte Windows dédié ayant juste les droits nécessaires au bon fonctionnement de votre application.