Answered by:
Login failed for domain\computer$

Question
-
I have found many places where this question has been asked in the past. Unfortunately, nothing that was suggested is working for me.
I am running Windows 8.1 and SQL Server 2012. I have a WCF service that I am publishing to my local IIS. It attempts to connect to SQL Server 2012 running on my local machine. I am a member of my company's domain.
When I attempt to go to a URL in a browser for my service that runs a query against the database, I get the following exception:
System.Data.SqlClient.SqlException (0x80131904): Login failed for user '<domain>\\<computer>$'
I looked at the SQL Log in SQL Server management studio, and this is the error I get:
"Login failed for user '<domain>\<computer>$'. Reason: Could not find a login matching the name provided. [CLIENT: <local machine>]"
Error: 18456, Severity: 14, State: 5.
I have added the <domain>\<computer>$ account to my SQL Server logins. I then added that login to the database I'm trying to access. I edited the permissions and turned on db_reader, db_writer, and db_owner.
I modified the DefaultAppPool in IIS (which is the pool my WCF service is using) to use the NetworkService identity. That worked for me the last time I had this issue under Windows 8.0. It's not working for me under Windows 8.1.
I'm out of suggestions. I can't think of anything else to try, and I'm at my wits end. This always seems like it should be such an easy thing to setup, and I always spend hours randomly changing settings on SQL Server and IIS just in case things magically start working.
Anyone have any other suggestions on what I can try or where I can look to see what the real problem is?
Other notes:
- The service url I'm going to is http://localhost/BrainiationService/Brainiation.svc/Accounts
- The connection string in Web.config is: "Data Source=.;Initial Catalog=Brainiation;Integrated Security=True;Pooling=False"
Thanks,
David Cater
- Edited by David Cater Monday, October 28, 2013 10:12 PM additional info
Monday, October 28, 2013 10:10 PM
Answers
-
Hi David,
According to your error message , this is the expected behavior when accessing network resources from a service running under NT AUTHORITY\Network Service account. When the SQL Server is on the Web server, you must create a database login for the NT AUTHORITY\Network Service account.
In the SQL Server Login Properties - New Login dialog box, in the Name box, enter NT AUTHORITY\NETWORK SERVICE.
The following link should provide detailed information on this topic: http://msdn.microsoft.com/en-us/library/ms998320.aspx
Thanks,
Sofiya LiIf you have any feedback on our support, please click here.
- Proposed as answer by Neha Mahajan DBA Tuesday, October 29, 2013 4:12 AM
- Marked as answer by David Cater Tuesday, October 29, 2013 8:33 AM
Tuesday, October 29, 2013 3:56 AM -
I take it back. It looks like you were right. I had just reinstalled SQL Server because my I had basically reinstalled my OS (I had upgraded from Windows 8.1 preview to Windows 8.1, which was like a refresh). I then attached my databases. My database had a SQL user for NETWORK SERVICE (Databases > Brainiation > Security > Users), so I thought that was covered. But I hadn't added the login to SQL Server itself (Server -> Security > Logins).
I added that login, and then deleted the NETWORK SERVICE user under my database and readded it (to make sure there was no confusion about security tokens). I gave it all the appropriate permissions, and now my service can access the database.
Then, just to make sure, I removed the "techatl\catermacwin8$" security login and user. I can still access the database.
So the moral of the story is: ignore the "domain\computer$" error message in this case. It's a red herring. And ignore the part of http://msdn.microsoft.com/en-us/library/ms998320.aspx that talks about granting access to a remote server. It's really talking about NT AUTHORITY\NETWORK SERVICE, and that's the account you need to grant access to.
- Marked as answer by David Cater Tuesday, October 29, 2013 8:33 AM
Tuesday, October 29, 2013 8:33 AM
All replies
-
I'm adding an image so you can see my login info at a glance.
Monday, October 28, 2013 10:23 PM -
Hi David,
According to your error message , this is the expected behavior when accessing network resources from a service running under NT AUTHORITY\Network Service account. When the SQL Server is on the Web server, you must create a database login for the NT AUTHORITY\Network Service account.
In the SQL Server Login Properties - New Login dialog box, in the Name box, enter NT AUTHORITY\NETWORK SERVICE.
The following link should provide detailed information on this topic: http://msdn.microsoft.com/en-us/library/ms998320.aspx
Thanks,
Sofiya LiIf you have any feedback on our support, please click here.
- Proposed as answer by Neha Mahajan DBA Tuesday, October 29, 2013 4:12 AM
- Marked as answer by David Cater Tuesday, October 29, 2013 8:33 AM
Tuesday, October 29, 2013 3:56 AM -
Thanks for your response, Sofiya.
Unfortunately, that doesn't appear to be the answer. First of all, take a look at this article: http://msdn.microsoft.com/en-us/library/ms998320.aspx. Search for "Granting Access to a Remote Server". That talks about the "domain/computer$" account.
Secondly, that was actually the first thing I checked, just in case. I've attached another screenshot showing the db login for NETWORK SERVICE and the permissions I gave it to my database.
Thanks anyway,
David
Tuesday, October 29, 2013 8:16 AM -
Also, note the error message I'm getting:
"Login failed for user '<domain>\<computer>$'. Reason: Could not find a login matching the name provided. [CLIENT: <local machine>]"
It clearly states which machine it's looking for. Well, since I've already posted the image, and this is just my dev machine, I suppose I might as well post the actual message for clarity:
"Login failed for user 'TECHATL\CATERMACWIN8$'. Reason: Could not find a login matching the name provided. [CLIENT: <local machine>]"
Tuesday, October 29, 2013 8:23 AM -
I take it back. It looks like you were right. I had just reinstalled SQL Server because my I had basically reinstalled my OS (I had upgraded from Windows 8.1 preview to Windows 8.1, which was like a refresh). I then attached my databases. My database had a SQL user for NETWORK SERVICE (Databases > Brainiation > Security > Users), so I thought that was covered. But I hadn't added the login to SQL Server itself (Server -> Security > Logins).
I added that login, and then deleted the NETWORK SERVICE user under my database and readded it (to make sure there was no confusion about security tokens). I gave it all the appropriate permissions, and now my service can access the database.
Then, just to make sure, I removed the "techatl\catermacwin8$" security login and user. I can still access the database.
So the moral of the story is: ignore the "domain\computer$" error message in this case. It's a red herring. And ignore the part of http://msdn.microsoft.com/en-us/library/ms998320.aspx that talks about granting access to a remote server. It's really talking about NT AUTHORITY\NETWORK SERVICE, and that's the account you need to grant access to.
- Marked as answer by David Cater Tuesday, October 29, 2013 8:33 AM
Tuesday, October 29, 2013 8:33 AM -
Hi,
In my case, the scenario is different. I above a cluster which has two nodes say: DB01 and DB02. Currently DB01 is active and in DB02, by default, all sql services are disabled except sql browser service which is on. This service is logged on as NT AUTHORITY\Network Service. In the cluster, the user named as <domain name of DB02>\DB02$ attempts to log into database which raises the above mentioned error. I tried applying the given solution but that didn't help. Then I created the user <domain name of DB02>\DB02$ in the database in cluster, then the error was gone but gave another error related to service end point was raised. Why would this user: <domain name of DB02>\DB02$ attempt to log into the database in the cluster? Can I stop the sql browser services in DB02?
Thank you.
- Edited by Curendra Tuesday, March 6, 2018 6:46 AM
Tuesday, March 6, 2018 6:44 AM -
Facing the exact same issue as Curenda.
do we have a solution for this yet ?
Wednesday, March 21, 2018 7:15 AM