Take the 2-minute tour ×

Below code is working fine when I am coding. I publish code in IIS and then connection is failing.

I know, When I am coding is taking my window login as credentials and In IIS it is taking AppPool Identity. How can I pass my windows login credentials to connectionstring?

Public Shared Function DbCollection(connectionString As String) As DatabaseCollection
   Dim server As New Microsoft.SqlServer.Management.Smo.Server(connectionString)
   Return server.Databases
End Function


   Login failed for user 'Domain\Computername$'. 

    Exception Details: System.Data.SqlClient.SqlException: Login failed for user
share|improve this question
Why would you want to? This kind of authentication should be made with a service account specific to this purpose. Is there a reason you want (or need) to use your windows account. I'm assuming you don't really mean YOUR credentials, but the credentials of the authenticated user. –  Joel Etherton Feb 18 '13 at 16:25
Because this application using my one user and it will be deployed on his machine only. –  James123 Feb 18 '13 at 16:29
That's still not the best reason to do this. I would still recommend using a service account for this kind of access. –  Joel Etherton Feb 18 '13 at 16:32

2 Answers 2

up vote 0 down vote accepted

I'd add to @smoore's post that a lot depends on the connection string and the configuration of sql server of allowing incoming connections. It might be set to only allow sql users, not windows ones which is looks like from the problem description. Can you give details of the connection string (anonymize/delete the user/password before pasting!) and what authentication mode is allowed by the sql server instance?

share|improve this answer
connection string is only 'sql server name' –  James123 Feb 18 '13 at 17:28
so it doesn't have "Integrated Security=true" or a "Username=;Password=;" tags? –  DiskJunky Feb 18 '13 at 18:06
Microsoft.SqlServer.Management.Smo.Server($strServer) will take of rest of the thing –  James123 Feb 18 '13 at 18:59
ah, then it would seem that the user account that is trying to connect to the sql server instance is the current windows account for the process? If running in your dev environment this is your logged in user. If you're running in IIS then this is the asp.net user account unless otherwise specified. By default, this would not be set up in SQL Server. In SQL Server's 'security' section, you'd need to create a SQL user account and configure it to allow remote connections. Only then would it be able to connect. If so, they really restrict the type of access to the DB –  DiskJunky Feb 18 '13 at 19:02

Based on error it is likely your SQL is not on the same box as IIS... Here are different possible options depending on configuration:

  • If you are not using SQL authentication and your SQL on the same box: You should be able to get the user credentials with HttpContext.CurrentUser and impersonating with those credentials, but it depends a lot on your system setup. Likely your already impersonating (default configuration in ASP.Net), but if your server is on different box than IIS than regular user's credential will not be able to float to other box (search term "NTLM one hop").
  • your database on a different server and you are already using Kerberos authentication in your organization: I think you have to be authenticating with Kerberos to impersonate on another server. Note that if such authentication is not configured/allowed it is unlikely to get turned on just for your case.
  • Database on another server using Windows authentication - you can run all SQL queries under particular user account (or RevertToSelf with whole bunch of interop to run under process' account).
  • Database anywhere and you can use SQL authentication - easiest approach as long as it is OK in your organization. Consider encrypting the connection string in config file if using this method.
share|improve this answer
+0: While in general idea of impersonating particular user is good, normally there is no need to impersonate "current user" as default for ASP.Net is "Windows auth + impersonate". Using Kerberos is likely impossible (unless it is already setup), impersonating a particular account (or reverting with RevertToSelf to process credentials) maybe easier. Using SQL authentication with encrypted password stored in Web.Config is likely easiest approach. –  Alexei Levenkov Feb 18 '13 at 16:59
I wasn't suggesting that switching his authentication to Kerberos was a solution, I was saying that if he already uses Kerberos then he can do that. I also give the poster the benefit of the doubt that maybe he really does need to use the credentials of the user, and using a service account is not acceptable. After seeing the OP's comment, I might have a different answer, but at the time I answered the question that was presented. –  Seth Moore Feb 18 '13 at 18:27
+1 - I did misread your statement about Kerberos. See if you ok with my edit - tried to make clear that there are 2 different cases in your original post (and took liberty to add my options too). –  Alexei Levenkov Feb 18 '13 at 18:55
+1 Alexei - Yes, much clearer than I had written it, and more concise. If only I could pass the points on to you for the answer! –  Seth Moore Feb 18 '13 at 19:39

Your Answer


