[.net] Login failed for user 'DOMAIN\MACHINENAME$'

I know this is almost a 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:

Web Box
SQL Box
SQL Test Box

My Application:

I have an ASP.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.

The problem:

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.

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 Web.config file

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

Step:

1. Click on Application Pools

2. Select Name of your application

3. Go to Advanced Setting

4. Expand Process Model and click Identity. Click three dot on right end.
5. Click Set... button and Provide your domain log in credentials

For me it was resolved.

Note: In Production or IT environment, you might have service account under same domain for app pool identity. If so, use service account instead of your login.

I got this error trying to test a solution using the following

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

The way I solved was: I had to open Visual Studio and run it under another account, because the account I was using to open was not my Admin account.

So if your problem is similar to mine: pin the VS to the task bar, then use Shift and Right Click to open the menu so you can open VS as another user.

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

Check if you have

User Instance=true

in connection string. Try removing it which will resolve your problem.

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!

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.

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.

In my case I had Identity="ApplicationPoolIdentity" for my IIS Application Pool.

After I added IIS APPPOOL\ApplicationName user to SQL Server it works.

I ran across this problem when a client renamed a SQL Server. The SQL Reporting Service was configured to connect to the old server name, which they had also created an alias for that redirected to the IP of the new server name.

All of their old IIS apps were working, redirecting to the new server name via the alias. On a hunch, I checked if they were running SSRS. Attempting to connect to the SSRS site Yielded the error:

"The service is not available.Contact your system administrator to resolve the issue. System administrators: The report server can’t connect to its database. Make sure the database is running and accessible. You can also check the report server trace log for details. "

It was running on the server, but failing to connect because it was using the alias for the old server name. Re-configuring SSRS to use the new server name instead of the old/alias fixed it.

Appreciate there are a few good answers here, but as I've just lost time working this out, hopefully this can help someone.

In my case, everything had been working fine, then stopped for no apparent reason with the error stated in the question.

IIS was running as Network service and Network Service had been set up on SQL Server previously (see other answers to this post). Server roles and user mappings looked correct.

The issue was; for absolutely no apparent reason; Network Service had switched to 'Deny' Login rights in the database.

To fix:

1. Open SSMS > Security > Logins.
2. Right click 'NT AUTHORITY\NETWORK SERVICE' and Click Properties.
3. Go to 'Status' tab and set Permission to Connect To Database Engine To 'Grant'.

1. Change the App Pool Identity to Local System
2. On SQL Mgmt > Security > Logins
   1. Find NT AUTHORITY\SYSTEM double click
   2. User Mappings > Check your database and give it a role below.
   3. Remember also to create the user data base o security logins with a correct password.

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.

For me issue with 'DOMAIN\MACHINENAME$' fixed by setting DefaultApplicationPool Identity to NetworkService.

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 Web.config is!

I added <identity impersonate="true" /> to my web.config and it worked fine.

I Had the same issue earlier,removing Persist Security Info=True from connectionstring worked for me.

My issue turned out to be in the Publish settings in Visual Studio. My appsettings.json connection string was correct, but the Database connection strings in the publish settings, had integrated security = true.

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

Adding a new answer in here because previous answers weren't explaining the issue I had. Problem is that the username required in SQL is the NAME of the app pool, and not its identity.

I ran in IIS with AppPools set to the ApplicationPoolIdentity identity.

My SQL Security User name with access was called IIS APPPOOL\DefaultAppPool and it was working fine with a ASP.NET Full Framework .net application.

When launching my ASP.NET Core application, it created a new AppPool with the application name, but no CLR version and still using the same ApplicationPoolIdentity identity.

But after looking at the user name used via System.Security.Principal.WindowsIdentity.GetCurrent().Name, I realized it isn't using DefaultAppPool, but the new app pool name. So I had to add a new user called IIS APPPOOL\ApplicationName in the SQL security tab, and not the default.