Asp.net core 3.1 webapi iis 8 not able to connect to sql server - asp.net-core-webapi

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.

Related

asp.net pages work, but classic asp gives access denied error

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!

NT AUTHORITY\ANONYMOUS LOGON Error (Double Hop)

BACKGROUND:
IIS is on One Server (7)
SQL is on another server
Active Directory is on another server (this may or may not make a difference but from what I have read it may)
We have a brand new MVC site that is using AD Permissions to grant access to the site and then to run the SP's within SQL
The site access is working correctly, but I am getting the error Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON' which I believe means I have fallen fowl to the double hop issue.
Within IIS I have an App Pool of V4.0 Integrated and Application Pool Identity
within my Application I have settings of ASP.net Impersonation Enabled and Windows Authentication Enabled all else is Disabled
And within the Delegation settings of the SQL Server and the IIS Server I have set 'Trust this computer for delegation to any service (Kerberos only)'
also if I run the following statement within SQL
SELECT auth_scheme
FROM sys.dm_exec_connections
WHERE session_id = ##SPID;
I get KERBEROS.
What am I missing? or doing wrong? Thanks
There are number of things you may want to check, do you have SPN setup on the SQL Box, these can be added via the following command:
setspn -a "<SQL_SERVER_Server_Name>:1433" "<SQL_SERVER_Service_Account>"
You may want to add both the FQDN as well as the short name. Once this is complete you will need to restart the SQL Server, not just the service.
If this does not work, can you run the following commands:
setspn -l "<AppPool Account Name>"
and
setspn -l "<SQL Server Account Name>"

ConnectionFailureException thrown in XP when using SMO with Windows Authentication

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?

Failed to generate a user instance of SQL Server due to failure in retrieving the user's local ap

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>

WMI access denied error when query remote computer from ASP.NET

I have an ASP.NET application that executes a WMI call to a remote system. The application Web.config contains <identity impersonate="true"> and <authentication mode="Windows"> options which, as I understand, should force the application code to be executed on behalf of the application user.
The problem is that I get "Access is denied" error, despite the fact I can successfully execute the my WMI request from PowerShell console on the same host under the same user to the remote server in question.
// this doesn't work
ManagementScope scope = new ManagementScope();
scope.Path.NamespacePath = "root\\virtualization";
scope.Path.Server = "vs01";
scope.Connect(); // <-- here comes exception
# this works just fine
Get-WmiObject -Namespace 'root\virtualization' -Class Msvm_ComputerSystem -ComputerName vs01
Dumping HttpContext.Current.User.Identity.Name, System.Security.Principal.WindowsIdentity.GetCurrent().Name, System.Threading.Thread.CurrentPrincipal.Identity.Name properties suggest that impersonation works as expected.
Ideas? Could the issue be some kind of .NET or IIS security?
You need to have a domain administrator enable Delegation for your web server machine. This is a security feature of Kerberos. By default an intermediate server (in this case your web server) is not allowed to pass the impersonation context of a client to the remote server unless it has been given Delegation permission. If you don't do this the remote target server will see the request coming in as Anonymous User... which if its properly secured will be denied access.
Note its a common policy to only allow an intermediate server to delegate to specific target servers (called constrained delegation), so if your web app needs to be able to call WMI on any server in your network you may have problem. Talk to your domain admin.

Resources