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

120

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.

SventoryMang
la source
Donc, pour récapituler, vous n'utilisez pas un utilisateur de base de données? Nous en créons un et pouvons basculer entre celui-ci et SA en fonction de ce que nous devons faire ...
jcolebrand
Dans la chaîne de connexion, j'utilise un utilisateur de base de données, que j'ai créé dans la zone Sécurité -> Connexions, je l'ai ajouté à la sécurité -> utilisateurs de la base de données et lui ai donné les autorisations dbo. C'est ainsi que j'ai fait toutes mes autres applications.
SventoryMang
Voici une explication claire de MSDN en utilisant le nom de la machine par défaut, en gros, vous ajoutez simplement le domaine / machine $ à sql sans lancer la recherche. blogs.msdn.microsoft.com/ericparvin/2015/04/14/…
Brett Maiwald

Réponses:

156

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.

Remus Rusanu
la source
2
Juste ce que j'ai compris, merci pour l'explication. Cependant, la question demeure, toutes mes applications sont hébergées sur mon serveur Web mais accèdent à une base de données sur des boîtes de test SQL ou SQL, ce serait un accès à distance oui? Pourtant, ils fonctionnent ... mais aucune de mes boîtes SQL n'accorde l'accès DOMAIN \ MACHINENAME $.
SventoryMang
1
Oh aussi, je m'attends à me connecter au serveur SQL en tant que connexion SQL mais j'ai publié mes chaînes de connexion, je n'utilise pas l'option Integrated Security = True, que pourrait-il être d'autre ??
SventoryMang
2
Il y a trois explications possibles: 1) ils utilisent l'authentification SQL au lieu de l'authentification intégrée (ce qui semble être la plus plausible, puisque votre exemple a un nom d'utilisateur et un mot de passe dans la chaîne de connexion) 2) ils utilisent l'authentification intégrée et s'exécutent dans un sondage d'application qui utilise une information d'identification différente ou 3) ils utilisent l'authentification intégrée mais l'application ASP emprunte l'identité de l'appelant, déclenchant ainsi une délégation contrainte: technet.microsoft.com/en-us/library/cc739587%28WS.10%29.aspx .
Remus Rusanu
2
Votre projet d'application Web doit faire référence au projet de bibliothèque de classes , pas à la DLL. Ajoutez le projet de bibliothèque de classes à la solution d'application Web, puis supprimez la référence à la DLL et ajoutez une référence au projet. De cette façon, lors du déploiement ou du test, l'application Web de vente au détail référencera la dll de la classe de vente au détail et le débogage fera automatiquement référence au débogage.
Remus Rusanu
1
Bien que tout cela soit bien beau, comment ajouter la connexion de la machine à SQL? - Ils sont tous les deux sur le même domaine, et je préférerais utiliser la sécurité intégrée. Mais simplement ajouter un compte nommé "Domain \ MachineName $" échoue complètement (comme, il n'existe pas, et l'explorateur d'objets s'étouffe et ne trouve rien de ce genre).
BrainSlugs83
33

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.

Zain Ali
la source
7
C'était la solution pour moi puisque l'application Web et la base de données sont sur la même machine. J'ai toujours l'erreur «La connexion a échoué pour l'utilisateur 'DOMAIN \ MACHINENAME $» mais l'ajout de la machine aux connexions SQL n'a pas aidé, mais l'ajout de «NT AUTHORITY \ NETWORK SERVICE» l'a fait. Bien que vous ne devriez pas utiliser le rôle db_owner à moins que cela ne soit nécessaire, normalement db_datareader et db_datawriter sont suffisants.
JimiSweden
18

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.

nZeus
la source
5
Je crois que cela ne fonctionnera que si IIS et le serveur SQL sont sur la même machine.
Rob Davis
1
Cela a fonctionné pour moi! J'ai une configuration de serveur IIS-SQL locale.
Vin Shahrdar
1
Merci beaucoup. Ce problème a commencé pour moi après la mise à niveau de mon environnement de développement local de SQL Server 2014 à 2017. Votre suggestion était la solution miracle dans cette situation.
MFry
Merci, travaillé pour moi aussi. Ce que je voudrais souligner, c'est que le message d'erreur est toujours 'Échec de la connexion pour l'utilisateur' DOMAIN \ MACHINENAME $ 'même si le pool d'applications est configuré pour s'exécuter sous l'identité du pool et que la connexion échoue même si le' DOMAIN \ MACHINENAME $ 'en fait est autorisé à se connecter. Cela me semble être un message d'erreur trompeur.
mivra
16

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.

Raj Baral
la source
Pour la question ci-dessus, cela devrait être la réponse acceptée.
makil le
14

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!

winy101
la source
3
Un milliard de remerciements à vous. Une aide énorme et énorme. Merci merci merci. C'est, j'en suis sûr, très évident mais pour les futurs gens, c'est User Id = quelque chose; Mot de passe = quelque chose;
shubniggurath
2
J'obtenais la même erreur dans le titre du message. J'ai trouvé que 'User Id = yourUserid Password = yourPassword' est ignoré lorsque "" Trusted connection = true "" est dans la chaîne de connexion à la base de données. J'ai supprimé "'trusted connection = true'" de ma chaîne et cela a résolu mon problème. Cela ne s'est produit que lorsque j'ai déplacé l'application du débogage dans VS 2012 vers iis 8.
T3.0
12

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.

Julien P
la source
11

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

simonm
la source
7
Comprenez simplement que cela changera le contexte dans lequel l'application ASP.NET s'exécute dans son intégralité. Au lieu de fonctionner sous le contexte par défaut «SERVICE RÉSEAU», il s'exécutera désormais sous le contexte de l'utilisateur utilisant l'application (c'est-à-dire Domain \ someUser). C'est correct parfois, mais comprenez simplement que ce changement n'est pas seulement une solution rapide au PO et a d'autres implications en aval qui peuvent / peuvent ne pas être souhaitées.
atconway
6

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é

Remco
la source
4

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

entrez la description de l'image ici

Arsen Khachaturyan
la source
3

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!

Philip Atz
la source
1
J'ai eu le même problème. L'erreur de SSAS est la même, mais le compte n'est pas un service réseau. Le compte est en fait: NT Service \ MSOLAP $ INSTANCENAME
cdonner
2

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.

Sarath Avanavu
la source
2

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é.

Arjan
la source
1

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.

Todd Beaulieu
la source
0

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

Un Petrov
la source
0

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

msk
la source
0

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é.

SQLMonger
la source
0
  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.
Allan Zeidler
la source
0

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. entrez la description de l'image ici

l'amour en direct
la source
0

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».

Service réseau autorisé

HockeyJ
la source