System.ComponentModel.Win32Exception (0x80004005) user name or password incorrect.

Question

_{Thursday, October 26, 2017 10:48 AM}

Hi,

We have installed our application on one server and we have installed MS SQL 2012 on another server.

We are trying to run few application related services using operational ID and password.

But we are getting the below mentioned error:

System.ComponentModel.Win32Exception (0x80004005) user name or password incorrect.

Scenario 1: the operational ID used to login to both the servers is ABCDEF and both having the same password to login.

When we run the services there is no problem. everything works fine.

Scenario 2: the operational ID used to login to both the servers is ABCDEF and both having the different passwords to login.

Now when I try to start the services,I am getting the error. 

Kindly need your expert advice.

Thanks in Advance,

Vittal V

All replies (3)

_{Thursday, October 26, 2017 2:15 PM}

Without further information it is hard to tell but it could be any # of things. You mentioned application related services but you didn't clarify if these were Windows services, WCF, just console apps, etc? Each of these apps would need to have a connection string in their config to point them to the SQL database. Within that connection string you'd either specify Integrated Security=SSPI to use the current process credentials or User ID/Password to use SQL authentication. You need to ensure those credentials are valid.

For a Windows service you need to ensure it is running under an account that allows network access. If you're using Integrated Security then the account the service is running under must have login rights to the SQL database. That pretty much means using a domain account. If you are trying to use SYSTEM or similar then you need to switch. In the worst case scenario where you must run as one of the builtin accounts you'd need to give the machine running the service SQL login rights instead. But I wouldn't recommend this.

For WCF or web apps it is a similar situation. If you're using Integrated Security then it'll use the identity of the apppool it is running under. If your app is configured for Windows auth then it'll use the logged in user. 

If you're using SQL auth then provided the credentials can be used to log into SQL then you're fine. You can use SSMS to verify login permissions.

Michael Taylor http://www.michaeltaylorp3.net

_{Friday, October 27, 2017 4:27 AM}

Hi Michael,

Thank you verymuch for your reply.

The services are windows based.

We have maintained the connection string which contains DB server name,DB user and DB password.

The credentials are valid. As suggested when the server login password for the user is same we have no issues in starting the services.

We are facing the issue only when the application server and DB server password is different.

_{Friday, October 27, 2017 2:09 PM}

So are you sure the service is failing when trying to connect to the DB or are you simply seeing your service fail to start? 

I'm confused as to what you mean by login into both servers. A SQL server is going to be running under an account either created by SQL during installation in most cases. That account is local to the machine and not useable anywhere else. Your windows service running on a separate machine would either be using a domain account or perhaps NETWORK SERVICE. These accounts are completely unrelated. If you are using a domain account to run SQL and you try to use that same domain account to run your windows service then they couldn't have different passwords. 

I'm going to assume that what you mean by login is when you log into the SQL database using your windows service. In that case you will either be using Windows auth or SQL auth. If the UN/PWD is in the connection string then you're using SQL auth. The account under which the service is running is irrelevant at that point. If changing the service account causes the service to fail to start then it shouldn't be because of the SQL connection as it doesn't matter (unless you're trying to use SYSTEM or LOCAL SERVICE). If this is indeed the case then I'd wager you're not actually using the connection string you think you are. You could confirm this by changing the conn string to point to a non-existent DB. You should get a network error.

Hopefully you have logging for your service and you can identify exactly where the start process is failing. Otherwise you might want to have your DBA look at the SQL connections and auditing on the SQL server. They can confirm what account you're actually trying to connect at.

Michael Taylor http://www.michaeltaylorp3.net