132
votes

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.

25
So to recap, you're not using a database user? We create one and can toggle between it and SA depending on what we need to do...jcolebrand
In the connection string I am using a database user, which I created in the Security -> Logins area, added it to the Security -> users of the database, and gave it dbo permissions. Which is how I did all my other apps too.SventoryMang
Here's a clear explanation from MSDN using the default machine name, basically you just add the domain/machine$ to sql without hitting search. blogs.msdn.microsoft.com/ericparvin/2015/04/14/…Brett Maiwald

25 Answers

161
votes

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.

35
votes

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.

22
votes

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.

18
votes

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

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

18
votes

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!

12
votes

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.

11
votes

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

6
votes

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

4
votes

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

enter image description here

3
votes

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!

2
votes

Check if you have

User Instance=true

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

2
votes

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.

1
votes

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.

1
votes

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.

0
votes

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

0
votes

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

0
votes

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.

0
votes
  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.
0
votes

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. enter image description here

0
votes

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

Network Service Allowed

0
votes

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.

0
votes

I had the \MACHINE$ account a part of the sysadmin role on the SQL server, and it didn't help. The server was on the same computer and IIS. App Pool identity was set to Network Service.

What helped me was changing App Pool from Integrated to Classic mode.

0
votes

You can use Network Service or Authenticated User.
Then give the Server Roles => public and sysadmin
Then give the User Mapping => select your database and
check public and db_owner.

0
votes

I'm using .NET Core 3.1 with a separate service id (AD) to connect to Database, it was working from Visual Studio 2019 but not in the Test or Production Server.

Made below changes which worked out for me, also find the connection details

"Server=ServerName;Database=dBName;Integrated Security=True;Trusted_Connection=True;User Id=DOMAIN\\ServiceId;Password=**********;MultipleActiveResultSets=True"

Then.. Change the Application Pool with Identity runs on the service id.

enter image description here

0
votes

I had all the settings (AppPool identity, AppPool on website, login for AppPool, etc.) correctly specified, but when I created the AppPool login with PowerShell, I forgot to grant connect permission (-GrantConnectSql) on the user, which by default is disabled.

Add-SqlLogin -ServerInstance "." -LoginName $AppPoolUser -LoginType "WindowsUser" -Enable -GrantConnectSql

In order to fix this manually:

  • Open SSMS
  • Connect to the server
  • Navigate to Security > Logins
  • Open the AppPool user's properties
  • Under the tab "Status"
  • Set "Permission to connect to database engine" to "Grant"