Login failed for user 'DOMAIN\MACHINENAME$'
I know this is almost duplicate of : The error "Login failed for user 'NT AUTHORITY\IUSR'" in ASP.NET and SQL Server 2008 and Login failed for user 'username' – System.Data.SqlClient.SqlException with LINQ in external project / class library but some things don’t add up compared to other appliations on my server and I am not sure why.
Boxes being used:
SQL Test Box
I’ve got aASP.NET Web Application, which references a class library that uses LINQ-to-SQL. Connection string set up properly in the class library. As per Login failed for user 'username' – System.Data.SqlClient.SqlException with LINQ in external project / class library I also added this connection string to the Web Application.
The connection string uses SQL credentials as so (in both web app and class library):
<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" />
This connection confirmed as working via adding it to server explorer. This is the connection string my .dbml file is using.
I get the following error:
System.Data.SqlClient.SqlException: Login failed for user 'DOMAIN\MACHINENAME$'.
Now referencing this The error "Login failed for user 'NT AUTHORITY\IUSR'" in ASP.NET and SQL Server 2008 it says that’s really the local network service and using any other non-domain name will not work.
But I am confused because I’ve checked both SQL Box and SQL Test Box SQL Management Studio and both have
NT AUTHORITY/NETWORK SERVICE under Security -> Logins, at the database level, that isn’t listed under Security -> Users, but at the database level Security -> Users I have the user displayed in the connection string.
At NTFS level on web server, the permissions have NETWORK SERVICE has full control.
The reason why I am confused is because I have many other web applications on my Web Server, that reference databases on both SQL Box and SQL Test Box, and they all work. But I cannot find a difference between them and my current application, other than I am using a class library. Will that matter? Checking NTFS permissions, setup of Security Logins at the server and databases levels, connection string and method of connecting (SQL Server credentials), and IIS application pool and other folder options, are all the same.
Why do these applications work without adding the machinename$ to the permissions of either of my SQL boxes? But that is what the one link is telling me to do to fix this problem.
14 Solutions collect form web for “Login failed for user 'DOMAIN\MACHINENAME$'”
NETWORK SERVICE and LocalSystem will authenticate themselves always as the correpsonding account locally (builtin\network service and builtin\system) but both will authenticate as the machine account remotely.
If you see a failure like
Login failed for user 'DOMAIN\MACHINENAME$' it means that a process running as NETWORK SERVICE or as LocalSystem has accessed a remote resource, has authenticated itself as the machine account and was denied authorization.
Typical example would be an ASP application running in an app pool set to use NETWORK SERVICE credential and connecting to a remote SQL Server: the app pool will authenticate as the machine running the app pool, and is this machine account that needs to be granted access.
When access is denied to a machine account, then access must be granted to the machine account. If the server refuses to login ‘DOMAIN\MACHINE$’, then you must grant login rights to ‘DOMAIN\MACHINE$’ not to NETWORK SERVICE. Granting access to NETWORK SERVICE would allow a local process running as NETWORK SERVICE to connect, not a remote one, since the remote one will authenticate as, you guessed, DOMAIN\MACHINE$.
If you expect the asp application to connect to the remote SQL Server as a SQL login and you get exceptions about DOMAIN\MACHINE$ it means you use Integrated Security in the connection string. If this is unexpected, it means you screwed up the connection strings you use.
This error occurs when you have configured your application with IIS, and IIS goes to SQL Server and tries to login with credentials that do not have proper permissions. This error can also occur when replication or mirroring is set up.
I will be going over a solution that works always and is very simple.
Go to SQL Server >> Security >> Logins and right click on NT AUTHORITY\NETWORK SERVICE and select Properties
In newly opened screen of Login Properties, go to the “User Mapping” tab. Then, on the “User Mapping” tab, select the desired database – especially the database for which this error message is displayed. On the lower screen, check the role db_owner. Click OK.
A colleague had the same error and it was due to a little configuration error in IIS.
The wrong Application Pool was assigned for the web application.
Indeed we use a custom Application Pool with a specific Identity to meet our needs.
In his local IIS Manager -> Sites -> Default Web Site -> Our Web App Name -> Basic Settings…
The Application Pool was “DefaultAppPool” instead of our custom Application Pool.
Setting the correct application pool solved the problem.
<identity impersonate="true" /> to my web.config and it worked fine.
The trick that worked for me was to remove
Integrated Security from my connection string and add a regular
User ID=userName; Password=password your connection string in the
App.config of your libruary might not be using integrated security but the one created in
For me the problem was resolved when I replaced the default Built-in account ‘ApplicationPoolIdentity’ with a network account which was allowed access to the database.
Settings can be made in Internet Information Server (IIS 7+) > Application Pools > Advanded Settings > Process Model > Identity
In my case I had
Identity="ApplicationPoolIdentity" for my IIS Application Pool.
After I added
IIS APPPOOL\ApplicationName user to SQL Server it works.
Basically to resolve this we need to have some set up like
- Web App Running under ApplicationPoolIdentity
- Web Application connecting to databases through ADO.Net using Windows Authentication in the connection string
The connection string used with Windows authentication include either
Trusted_Connection=Yesattribute or the equivalent attribute
Integrated Security=SSPI in
My database connection is in Windows Authentication mode. So I resolved it by simply changing the Application Pools Identity from ApplicationPoolIdentity to my domain log in credentials DomainName\MyloginId
- Click on Application Pools
Select Name of your application
Go to Advanced Setting
- Expand Process Model and click Identity. Click three
dot on right end.
- Click Set… button and Provide
your domain log in credentials
For me it was resolved.
We had been getting similar error messages while processing an Analysis Services database. It turned out that the username, which was used to run the Analysis Services instance, had not been added to the SQL Server’s Security Logins.
In SQL Server 2012, the SQL Server and Analysis services are configured to run as different users by default. If you have gone with the defaults, always ensure that the AS user has access to your datasource!
Check if you have
in connection string. Try removing it which will resolve your problem.
I also had this error with a SQL Server authenticated user
I tried some of the fixes, but they did not work.
The solution in my case was to configure its “Server Authentication Mode” to allow SQL Server authentication, under Management Studio: Properties/Security.
The only point that everyone seems to have overlooked is that you may want integrated security = true. You may have the site running under a pool account. That’s all fine so and it’s still possible to hit the SQL server with the original user credential and not the pool’s. It’s called constrained delegation. If you enable it and set up an SPN windows will translate the pool’s credentials with the user’s on requests going to the final service (SQL is just one such service). You have to register the ONE AND ONLY SQL server that services SQL requests on the web server. Setting this all up is too much for me to try to accurately describe here. It took me quite a while to work through it myself.
I spent a few hours trying to fix the issue and I finally got it – the SQL Server Browser was “Stopped”. The fix is to change it to “Automatic” mode:
If it is disabled, go to Control Panel->Administrative
Tools->Services, and look for the SQL Server Agent. Right-click, and
select “Properties.” From the “Startup Type” dropdown, change from
“Disabled” to “Automatic”.
quote from here
I Had the same issue earlier,removing
Persist Security Info=True from connectionstring worked for me.