Échec de la connexion pour l'utilisateur "DOMAIN \ MACHINENAME $"

Je sais que c'est presque un double de: L'erreur «La connexion a échoué pour l'utilisateur 'NT AUTHORITY \ IUSR'» dans ASP.NET et SQL Server 2008 et la connexion a échoué pour l'utilisateur 'username' - System.Data.SqlClient.SqlException avec LINQ dans bibliothèque de projet / classe externe, mais certaines choses ne s'additionnent pas par rapport à d'autres applications sur mon serveur et je ne sais pas pourquoi.

Boîtes utilisées:

Boîte de test SQL Web Box
SQL
Box

Mon application:

J'ai une application Web ASP.NET, qui fait référence à une bibliothèque de classes qui utilise LINQ-to-SQL. Chaîne de connexion correctement configurée dans la bibliothèque de classes. Comme par Échec de la connexion pour l'utilisateur 'nom d'utilisateur' - System.Data.SqlClient.SqlException avec LINQ dans la bibliothèque de projet / classe externe, j'ai également ajouté cette chaîne de connexion à l'application Web.

La chaîne de connexion utilise les informations d'identification SQL comme telles (dans l'application Web et la bibliothèque de classes):

 <add name="Namespace.My.MySettings.ConnectionStringProduction"
        connectionString="Data Source=(SQL Test Box);Initial Catalog=(db name);Persist Security Info=True;User ID=ID;Password=Password"
        providerName="System.Data.SqlClient" />

Cette connexion a confirmé son fonctionnement en l'ajoutant à l'Explorateur de serveurs. Il s'agit de la chaîne de connexion que mon fichier .dbml utilise.

Le problème:

J'obtiens l'erreur suivante:

System.Data.SqlClient.SqlException: Login failed for user 'DOMAIN\MACHINENAME$'.

Maintenant en faisant référence à cela L'erreur «Échec de la connexion pour l'utilisateur 'NT AUTHORITY \ IUSR'» dans ASP.NET et SQL Server 2008 indique que c'est vraiment le service de réseau local et que l'utilisation de tout autre nom non-domaine ne fonctionnera pas.

Mais je suis confus car j'ai vérifié à la fois SQL Box et SQL Test Box SQL Management Studio et les deux ont NT AUTHORITY/NETWORK SERVICEsous Sécurité -> Connexions, au niveau de la base de données, ce qui n'est pas répertorié sous Sécurité -> Utilisateurs, mais au niveau de la base de données Sécurité -> Utilisateurs J'ai l'utilisateur affiché dans la chaîne de connexion.

Au niveau NTFS sur le serveur Web, les autorisations ont NETWORK SERVICE a un contrôle total.

La raison pour laquelle je suis confus est que j'ai de nombreuses autres applications Web sur mon serveur Web, qui référencent des bases de données sur SQL Box et SQL Test Box, et elles fonctionnent toutes. Mais je ne trouve pas de différence entre eux et mon application actuelle, à part que j'utilise une bibliothèque de classes. Cela importera-t-il? La vérification des autorisations NTFS, la configuration des connexions de sécurité au niveau du serveur et des bases de données, la chaîne de connexion et la méthode de connexion (informations d'identification SQL Server), le pool d'applications IIS et d'autres options de dossier sont identiques.

Pourquoi ces applications fonctionnent-elles sans ajouter le nom de machine $ aux permissions de l'une ou l'autre de mes boîtes SQL? Mais c'est ce que le seul lien me dit de faire pour résoudre ce problème.

NETWORK SERVICE et LocalSystem s'authentifieront toujours en tant que compte correspondant localement (builtin \ network service et builtin \ system) mais les deux s'authentifieront en tant que compte de machine à distance.

Si vous voyez un échec comme Login failed for user 'DOMAIN\MACHINENAME$'cela signifie qu'un processus exécuté en tant que SERVICE RÉSEAU ou en tant que LocalSystem a accédé à une ressource distante, s'est authentifié en tant que compte d'ordinateur et s'est vu refuser l'autorisation.

Un exemple typique serait une application ASP s'exécutant dans un pool d'applications défini pour utiliser les informations d'identification de SERVICE RÉSEAU et se connecter à un serveur SQL distant: le pool d'applications s'authentifiera en tant que machine exécutant le pool d'applications, et ce compte d'ordinateur doit-il être autorisé à accéder .

Lorsque l'accès est refusé à un compte d'ordinateur, l'accès doit être accordé au compte d'ordinateur. Si le serveur refuse de se connecter à «DOMAINE \ MACHINE $», vous devez accorder les droits de connexion à «DOMAINE \ MACHINE $» et non au SERVICE RÉSEAU. Accorder l'accès au SERVICE RÉSEAU permettrait à un processus local s'exécutant en tant que SERVICE RÉSEAU de se connecter, et non distant, puisque le processus distant s'authentifiera comme, vous l'avez deviné, DOMAINE \ MACHINE $.

Si vous vous attendez à ce que l'application asp se connecte au serveur SQL distant en tant que connexion SQL et que vous obtenez des exceptions concernant DOMAIN \ MACHINE $, cela signifie que vous utilisez la sécurité intégrée dans la chaîne de connexion. Si cela est inattendu, cela signifie que vous avez foiré les chaînes de connexion que vous utilisez.

Cette erreur se produit lorsque vous avez configuré votre application avec IIS et que IIS accède à SQL Server et tente de se connecter avec des informations d'identification qui ne disposent pas des autorisations appropriées. Cette erreur peut également se produire lors de la configuration de la réplication ou de la mise en miroir. Je vais passer en revue une solution qui fonctionne toujours et qui est très simple. Allez dans SQL Server >> Sécurité >> Connexions et faites un clic droit sur NT AUTHORITY \ NETWORK SERVICE et sélectionnez Propriétés

Dans l'écran nouvellement ouvert des propriétés de connexion, allez dans l'onglet «Mappage des utilisateurs». Ensuite, dans l'onglet «User Mapping», sélectionnez la base de données souhaitée - en particulier la base de données pour laquelle ce message d'erreur est affiché. Sur l'écran inférieur, vérifiez le rôle db_owner. Cliquez sur OK.

Dans mon cas, j'avais Identity="ApplicationPoolIdentity"pour mon pool d'applications IIS.

Après avoir ajouté un IIS APPPOOL\ApplicationNameutilisateur à SQL Server, cela fonctionne.

Fondamentalement, pour résoudre ce problème, nous devons en avoir mis en place comme

• Application Web exécutée sous ApplicationPoolIdentity
• Application Web se connectant aux bases de données via ADO.Net à l'aide de l'authentification Windows dans la chaîne de connexion

La chaîne de connexion utilisée avec l'authentification Windows inclut l' Trusted_Connection=Yesattribut ou l'attribut équivalent Integrated Security=SSPIdans le Web.configfichier

Ma connexion à la base de données est en mode d'authentification Windows. Je l'ai donc résolu en changeant simplement l' identité des pools d' applications d' ApplicationPoolIdentity en mon journal de domaine dans les informations d'identification DomainName \ MyloginId

Étape:

1. Cliquez sur Pools d'applications

2. Sélectionnez le nom de votre application

3. Aller aux paramètres avancés

4. Développez le modèle de processus et cliquez sur Identité . Cliquez sur trois points à l'extrémité droite.
5. Cliquez sur le bouton Définir ... et fournissez les informations d'identification de votre domaine.

Pour moi, c'était résolu.

Remarque: dans un environnement de production ou informatique, vous pouvez avoir un compte de service sous le même domaine pour l'identité du pool d'applications. Si tel est le cas, utilisez un compte de service au lieu de votre connexion.

L'astuce qui a fonctionné pour moi a été de supprimer Integrated Securityde ma chaîne de connexion et d'ajouter une User ID=userName; Password=passwordchaîne de connexion régulière dans le App.configde votre bibliothèque n'utilisant peut-être pas la sécurité intégrée, mais celle créée dans l' Web.configest!

Un collègue a eu la même erreur et cela était dû à une petite erreur de configuration dans IIS.
Un pool d'applications incorrect a été attribué à l'application Web.

En effet, nous utilisons un pool d'applications personnalisé avec une identité spécifique pour répondre à nos besoins.

Dans son gestionnaire IIS local -> Sites -> Site Web par défaut -> Nom de notre application Web -> Paramètres de base ... Le pool d'applications était "DefaultAppPool" au lieu de notre pool d'applications personnalisé.

La définition du pool d'applications correct a résolu le problème.

J'ai ajouté <identity impersonate="true" />à mon web.config et cela a bien fonctionné.

Pour moi, le problème a été résolu lorsque j'ai remplacé le compte intégré par défaut «ApplicationPoolIdentity» par un compte réseau qui était autorisé à accéder à la base de données.

Les paramètres peuvent être définis dans Internet Information Server (IIS 7+)> Pools d'applications> Paramètres avancés> Modèle de processus> Identité

Pour moi, problème avec "DOMAIN \ MACHINENAME $" résolu en définissant DefaultApplicationPoolIdentity sur NetworkService.

Nous avions reçu des messages d'erreur similaires lors du traitement d'une base de données Analysis Services. Il s'est avéré que le nom d'utilisateur, qui était utilisé pour exécuter l'instance Analysis Services, n'avait pas été ajouté aux connexions de sécurité de SQL Server.

Dans SQL Server 2012, les services SQL Server et Analysis sont configurés pour s'exécuter en tant qu'utilisateurs différents par défaut. Si vous avez choisi les valeurs par défaut, assurez-vous toujours que l'utilisateur AS a accès à votre source de données!

Vérifiez si vous avez

User Instance=true

dans la chaîne de connexion. Essayez de le supprimer, ce qui résoudra votre problème.

J'ai également eu cette erreur avec un utilisateur authentifié par SQL Server

J'ai essayé certains des correctifs, mais ils n'ont pas fonctionné.

La solution dans mon cas était de configurer son "Mode d'authentification serveur" pour permettre l'authentification SQL Server, sous Management Studio: Propriétés / Sécurité.

Le seul point que tout le monde semble avoir négligé est que vous souhaiterez peut-être une sécurité intégrée = vrai. Vous pouvez avoir le site en cours d'exécution sous un compte de pool. Tout va bien et il est toujours possible d'accéder au serveur SQL avec les informations d'identification de l'utilisateur d'origine et non celles du pool. C'est ce qu'on appelle la délégation contrainte. Si vous l'activez et configurez un SPN, les fenêtres traduiront les informations d'identification du pool avec les demandes de l'utilisateur envoyées au service final (SQL n'est qu'un de ces services). Vous devez enregistrer le SEUL ET UNIQUE serveur SQL qui traite les requêtes SQL sur le serveur Web. Configurer tout cela est trop pour moi d'essayer de décrire avec précision ici. Il m'a fallu un certain temps pour y travailler moi-même.

J'ai passé quelques heures à essayer de résoudre le problème et je l'ai finalement compris - le navigateur SQL Server était "arrêté". Le correctif est de le changer en mode "Automatique":

S'il est désactivé, accédez à Panneau de configuration-> Outils d'administration-> Services et recherchez l'Agent SQL Server. Cliquez avec le bouton droit de la souris et sélectionnez «Propriétés». Dans la liste déroulante "Type de démarrage", passez de "Désactivé" à "Automatique".

citation d'ici

J'ai eu le même problème plus tôt, la suppression Persist Security Info=Truede connectionstring a fonctionné pour moi.

J'ai rencontré ce problème lorsqu'un client a renommé un serveur SQL. Le service de rapport SQL a été configuré pour se connecter à l'ancien nom de serveur, pour lequel ils avaient également créé un alias pour celui redirigé vers l'adresse IP du nouveau nom de serveur.

Toutes leurs anciennes applications IIS fonctionnaient, redirigeant vers le nouveau nom de serveur via l'alias. Sur une intuition, j'ai vérifié s'ils exécutaient SSRS. La tentative de connexion au site SSRS a généré l'erreur:

"Le service n'est pas disponible. Contactez votre administrateur système pour résoudre le problème. Administrateurs système: le serveur de rapports ne peut pas se connecter à sa base de données. Assurez-vous que la base de données est en cours d'exécution et accessible. Vous pouvez également consulter le journal de suivi du serveur de rapports pour plus de détails. . "

Il s'exécutait sur le serveur, mais ne se connectait pas car il utilisait l'alias de l'ancien nom de serveur. La reconfiguration de SSRS pour utiliser le nouveau nom de serveur au lieu de l'ancien / alias l'a corrigé.

1. Changer l'identité du pool d'applications en système local
2. Sur SQL Mgmt> Sécurité> Connexions
   1. Trouvez NT AUTHORITY \ SYSTEM double-cliquez
   2. Mappages d'utilisateurs> Vérifiez votre base de données et attribuez-lui un rôle ci-dessous.
   3. N'oubliez pas également de créer la base de données utilisateur des connexions de sécurité avec un mot de passe correct.

J'ai eu cette erreur en essayant de tester une solution en utilisant ce qui suit

string cn = "Data Source=[servername];Integrated Security=true;Initial Catalog=[dbname];";

La façon dont j'ai résolu était la suivante: je devais ouvrir Visual Studio et l'exécuter sous un autre compte, car le compte que j'utilisais pour ouvrir n'était pas mon compte Admin.

Donc, si votre problème est similaire au mien: épinglez le VS à la barre des tâches, puis utilisez Maj et Clic droit pour ouvrir le menu afin que vous puissiez ouvrir VS en tant qu'autre utilisateur.

J'apprécie qu'il y ait quelques bonnes réponses ici, mais comme je viens de perdre du temps à travailler sur cela, j'espère que cela peut aider quelqu'un.

Dans mon cas, tout fonctionnait bien, puis s'est arrêté sans raison apparente avec l'erreur indiquée dans la question.

IIS fonctionnait en tant que service réseau et le service réseau avait été précédemment configuré sur SQL Server (voir les autres réponses à cet article). Les rôles de serveur et les mappages d'utilisateurs semblaient corrects.

Le problème était; sans aucune raison apparente; Le service réseau était passé à «Refuser» les droits de connexion dans la base de données.

Pour réparer:

1. Ouvrez SSMS> Sécurité> Connexions.
2. Cliquez avec le bouton droit sur 'NT AUTHORITY \ NETWORK SERVICE' et cliquez sur Propriétés.
3. Allez dans l'onglet «Statut» et définissez Permission to Connect To Database Enginesur «Accorder».