I'm trying to use SMO in a ASP.NET web project to get a list of the server's Databases. The method I'm using seems to work fine on a Windows 7 machine, but the second I install it on an XP machine, I get a ConnectionFailureException. The code I'm using to establish the connection is:
ServerConnection connection = new ServerConnection(serverName);
Server serverConnection = new Server(connection);
string[] databases;
try
{
databases = new string[serverConnection.Databases.Count];
}
catch { databases = new string[0]; }
On the Windows 7 machine, I get an empty array of length however many databases there are, which I then add the database names to in a foreach loop, but in Windows XP, it fails in the try block, and I get:
ConnectionFailureException: Failed to connect to server localhost.
-> Login failed for user 'ComputerName\\ASPNET'.
I'm guessing this is some kind of permissions problem with the ASPNET user, but I can't seem to find anything that's solved the problem. In IIS, I unselected Anonymous Access and selected Integrated Windows Authentication, and set
<authentication mode="Windows" />
in the web.config.
Anyone have any suggestions/sage-like advice to share?
Do you want web application to impersonate a user to connect to SQL?
When you use SQL Management Studio you are connecting to SQL directly; when you are doing it from web application then you are calling it and IIS calls yours SQL. Now the question is which login IIS uses when accessing SQL - whether it impersonates you under W7 and does not doing it under XP?
For sure XP does not impersonates you and uses 'ComputerName\ASPNET' as you shown in the error message. IIS6 ASPNET impersonation setting are described here and IIS7 here. By default in both IISes impersonation is turned off but I am not sure what is your current configuration on W7. Maybe you should turn it on under IIS6?
Related
I have asp.net core 3.1 web api. When I run the project locally in Visual studio, it works fine. But when I publish it to IIS and run it, I get the error.
500 Internal Server Error","error": "A connection was successfully established with the server, but then an error occurred during the pre-login handshake. (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.)"}
Or Login failed for user domain_name\machine_name.
connection string looks like this
"ConnectionStrings": {
"ABCDB": "Server=xxx-test,80;Database=abc;Integrated Security=true;MultipleActiveResultSets=true;"
},
I have the hosting bundle installed for .net core 3.
my app runs under ApplicationPoolIdentity which is added to the database and has the permissions. My application pool is set to No Managed Code with ApplicationPoolIdentity.
The endpoints for the api which are not connecting to the database work just fine on published version but anything that is connecting to the database gives the error.
I referred to couple of links but hard luck.
https://www.loganfranken.com/blog/1345/why-your-web-application-cant-connect-to-sql-server/
IIS fails to pass windows credentials through to SQL Server for ASP.NET Core app
Why asp.net core app uses different user than AppPool identity for Windows Authentication when connecting to SQL Server?
Any help is appreciated.
Edit: The only things that works for me running the appPool under custom account(my credentialis) but does not work under appPoolIdentity on IIS
It seem that your environment needs a reset.
1- Manually check your app folder under IIS to see if any cached files or similar ones could be deleted.
2- Ideally, install it in a new folder under IIS
3- Reset the IIS
4- Make a hard refresh of the web browser
your connection string should be like this:
"ABCDB": "Data Source=xxx-test;Initial Catalog=abc;Integrated Security=SSPI;Persist Security Info=True;"
and add application pool name of your published application of security/users folder of your DB:
IIS APPPOOL\<apppool name>
Or add a new user account to you DB with user name and password. In this case you will also have to change the connection string.
I was having the same issue.
Other .NET Core 3.1 web apps are running just fine with the same authentication method (anonymous authentication) on the same IIS instance on the same server using the same connection string to the same MS SQL DB.
With this one particular .NET Core 3.1 web app, IIS is causing the app to try to authenticate to MSSQL DB with the username {DOMAIN}\{Computer Name}
The issue for me was that the connection string for the one app with the issue had "Trusted_Connection=True".
I knew that I would get this authentication interception from IIS with Integrated_Security but did not realize that Integrated_Security is synonymous with Trusted_Connection.
So the fix is to remove Trusted_Connection = True or Integrated_Security = True from the DB connection string in the app. If you need either of these two for your code to work (but are providing a username and password in the DB connection string), you should probably re-evaluate your code. Otherwise, the behavior OP and I observed should be what you want to happen and this isn't a problem.
I am setting up an existing application on a new server. It is a mix of Asp.Net and Classic Asp pages. The asp.net pages work perfectly, but the classic asp pages give the following error:
[DBNETLIB][ConnectionOpen (Connect()).]SQL Server does not exist or
access denied.
My Settings:
Windows Server 2008 x64
IIS7
SQL 2008 Express with Advanced Services
32bit application
Here are some things I've tried:
Set IIS7 AppPool to enable 32-bit applications
Enabled "Active Server Pages" extension in IIS "ISAPI and CGI Restrictions"
Installed Frontpage 2002 Extensions for IIS7 (from RTR)
Enabled Named Pipes protocol in SQL Config Mgr
My Connection String:
connectionString="Data Source=(local);Initial Catalog=System;Persist Security Info=True;User ID=System;Password=mypassword" providerName="System.Data.SqlClient"
My CLICONFG Alias:
Server Alias = System
Network Library = Named Pipes
Connection Parameters = (local)
I've successfully installed the program in this environment before without any issues. Both *.asp and asp.net are using the same connection string, so I can't see how that is a problem. The User "System" specified in the Connection String is setup as a user in SQL with all permissions granted.
Please help!! I've spent over 3 days on this.
Thanks!
I'm not so sure that classic asp understands all the parameters in your connection string. It likely ignores something it doesn't understand but the on that I think it's having the greatest trouble with is this one:
Data Source=(local)
and possibly
providerName="System.Data.SqlClient"
I would try either:
Creating a second connection string and use one for classic ASP and the other for aspx. Use this 'simple' format for classic asp:
Server=myServerAddress;Database=myDataBase;User Id=myUsername;Password=myPassword;
Change the Data Source parameter to use the actual server or instance name.
System.Data.SqlClient is a data provider for asp.net, it wouldn't work with classic asp.
Here's an example of a Classic ASP connection string for SQL Server
Provider=sqloledb;Data Source=yourServerAddress;Initial Catalog=yourDataBase;User Id=yourUserid;Password=yourPwd;
For more examples see here - look at oledb providers.
http://www.connectionstrings.com/sql-server/
Also, where are you putting your connection string? If it's in web.config then .net will be able to read it but Classic ASP won't. It needs to go in the page which wants to connect itself, in an include or in global.asa
Edit - one extra point. If you're using SQL Server Express then you need to specify this - eg:
Data Source=localhost\SQLEXPRESS
Shawnda, John and Evan make good suggestions and points.
I'll share my active live server configurations with you so you have something to test on your server. That's if you're running MSSQL on IIS 7.x and Windows 2008 Server with any flavor of SQL Server 2008.
I run 2 servers mixed .Net and ASP one Web 2008 and 2008 R2 with IIS .Net sites with ASP using a common db all sites mixed work just fine.
First tip, make your connection string a Call Function or Sub.
From what you said you have to find all the locations you have your connection string.
How we migrate will help you.
Create your function and place it into your SQL Included pages or your master scripts page that is included in all pages that need your connection string.
Function ConnOpen(SqlConn)
Dim strConnSql
Set SqlConn = Server.CreateObject("ADODB.Connection")
strConnSql = "Provider=SQLNCLI10;Server=SERVERNAME\SQLEXPRESS;Database=DBNAME;UID=USER;PWD=PASSWORD;"
SqlConn.Open strConnSql
End Function
Function ConnClose(SqlConn)
SqlConn.Close
Set SqlConn = Nothing
End Function
Follow what has been suggested and change the string.
This is how I migrate sites from databases.
I will add a new connection string as a function and test it on one of my pages.
If the new connection works I'll do a search and replace of the string.
Once you figure out which connection string works you're going to stop spending time like 3 days.
The string above is active on my .Net sites in my inc_sqlpage.asp which is included in all pages that require database connection.
You should find all your connection strings and remove and replace them with a easier to manage function.
Call ConnOpen(MyConn)
... 'your SQL
Call ConnClose(MyConn)
If after this method you still can't connect then I'll say it's your server naming or firewall if this is a new server.
Example: I do not use IP address connections only internal DNS machine names. If i changed the servername to IP I would see the same type of error.
I'm sure you have tried different settings but try the one above switching IP with Machine Name, .\ and localhost but not (local).
I found the solution!!!
Thanks everyone for your assistance. I finally found the solution!
Turns out the connection string for my classic asp pages were expecting SQL to be installed with the default instance....but I had done a named instance. The connection string had "Data Source = System" (System was an alias setup on the computer that only specified (local) as the connection....it did not specify the instance name.).
I changed the connection string to "Data Source = .\SQLEXPRESS" and it worked fine.
The connection string that was in there would have worked fine if I had selected "Default Instance" during the installation....as had been done on other servers I had installed.
Thanks again!
I cannot get my web app to connect to the database when running the app. I can connect in the SQL Server object explorer and I took the connection string from the connections properties
Here is my connection string :
<add name="Quotes.DAL.QuotesConnection"
connectionString="Data Source=(localdb)\v11.0;Initial Catalog=TestDB;Integrated Security=False;User ID=sa;Password=***;Connect Timeout=15;Encrypt=False;TrustServerCertificate=False"
providerName="System.Data.SqlClient" />
I can connect as SA and I can create the database that it points to in Management Studio. When my app tries to connect via Entity Framework I get the following error :
System.Data.SqlClient.SqlException (0x80131904): Login failed. The login is from an untrusted domain and cannot be used with Windows authentication. at System.Data.ProviderBase.DbConnectionPool.TryGetConnection(DbConnection owningObject,
I'm running Windows 7 as a home dev machine so there is no Active Directory.
Can anybody explain why this might happen?
I have found that this is probably because I have Entity Framework in another assembly. I created a new web application and its connection string works. When it try the same connection string in my DAL it fails with this same error!
Thanks
It may be because of setting Integrated Security=False, I have never set it to false. I normally use just the bare minimum Server=myServerAddress;Database=myDataBase;User Id=myUsername;
Password=myPassword; when setting up my connection strings with sql authentication, only adding things as I need them.
The other issue I see is using SA to connect to the database. This breaks almost every best practice in the book and I would recommend creating an app specific password for when you roll out the program. The reason being is the GOD ACCESS account for the server will have its password in plain text in the app.config file. Just something to keep in mind.
EDIT: After some comment discussion the connection string was in the wrong config file.
This is my first time to deploy an asp.net web site. Everything is working fine on my local computer but when i published the web site on a remote computer i get the error "Failed to generate a user instance of SQL Server due to failure in retrieving the user's local application data path. Please make sure the user has a local user profile on the computer. The connection will be closed"
(only in pages that try to access the database)
Help pleaseee
In IIS under Vista/Windows 7/Server 2008 OS,
Select the application pool and then "advanced settings." Under "process model" find "Load User Profile" and set it to true.
SQL should now load under the default app pool account.
Try the following:
Start IIS
Open Application Pools by clicking on it
Right click on DefaultAppPool and select “Select Application Pool
Defaults”
Change “Identity” property to “NetworkService”
Save and exit IIS
You have to adjust your connection string according to your hosting server.
Modify the below section of web.config according to SQL server user name and password
<connectionStrings>
<add name="DBName" providerName="System.Data.SqlClient"
connectionString="uid=; pwd=; database=; server=;"/>
</connectionStrings>
I can not seem to get sql server to recognize my credentials.
Asp.net recognizes me when I login but when I execute a sql command I get a login failed message.
The IIS server and SQL server are on different machines.
There are other applications the IIS server which are able to authenticate to the sql server. I believe the Active Directory settings are correct. I am investigating what I am doing differently.
I must be missing something.
I check the IIS settings
The web config is set to impersonate.
Below is the relevant information. If anyone has any idea as to what I missed or am doing wrong I would appreciate some help.
IIS Settings:
'Integrated Windows authentication' is checked
'Enable anonymous access" is not checked
Web Config
<authentication mode="Windows"/>
<identity impersonate="true"/>
<authorization>
<deny users="?" />
</authorization>
Page_Load Code:
Dim winId As IIdentity = HttpContext.Current.User.Identity
TextBoxMessage.Text = winId.Name + Environment.NewLine
Dim cnn As SqlClient.SqlConnection
Try
Dim sql As String = "*****"
cnn = New SqlClient.SqlConnection("Data Source=*****;Initial Catalog=****;Integrated Security=True")
cnn.Open()
Dim cmd As New SqlClient.SqlCommand(sql, cnn)
cmd.ExecuteNonQuery()
cnn.Close()
Catch ex As Exception
TextBoxMessage.Text += ex.Message
cnn.Close()
End Try
Output:
Domain\UserName
Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'.
This is key = The IIS server and SQL server are on different machines. You're facing the classic double hop issue. Think of it in this way:
You access the web application under your credentials
IIS in this case has to present who you say you are to the SQL Server
IIS says, "Why hello SQL Server, I'm passing on Tony's kerberos creds, they are legit"
SQL Server says, "Hmmm, IIS I'm not sure I trust you, I need proof that you are trusted to present these credentials to me".
Thus once you enable delegation as mentioned by Remus, your SQL Server will trust the credentials your IIS server is presenting on your behalf.
In terms of security, under delegation, it would be wise to choose:
Trust this computer for delegation for specified services only | Use Kerberos only | and then underneath the "Services to which this account can present delegated credentials" make sure you explicitly set only the server/port you need.
You also need to enable constrained delegation:
Enabling Constrained Delegation
How To: Use Protocol Transition and Constrained Delegation in ASP.NET 2.0
Windows Server 2003 Constrained Delegation (IIS 6.0)
Are your ISS server and SQL Server running on the same machine?
If not, Active Directory has to be configured to allow your IIS server to impersonate your accout towards the SQL Server. See How To: Use Protocol Transition and Constrained Delegation in ASP.NET 2.0.
Long story short: IIS server should have "trusted for delegation" checkbox checked in Active Directory.
You need to set you credentials in Application Pool.
- Open IIS
- Select Application Pools
- Enter the name, select .Net framework version and click OK
- Select the new added application pool and click on Advanced Settings..
- In the Process Model section click on Identity - choose custom account and enter the AD username, password, confirm password and click OK
- Select your application and in the Basic settings choose your application pool just created.
Hope this helps