If I have an ASP.NET web app using impersonation and a SQL Server connectionstring with Integrated Security = true, does the identity of the IIS application pool of the app play any role?
Does the identity need to be set to some specific user (LocalSystem, NetworkServices or a domain user)? This is on Windows 2003.
If the SQL Server is on a different box than IIS then the identity of the IIS application pool has to be trusted for constrained delegation. See How To: Use Protocol Transition and Constrained Delegation in ASP.NET 2.0. If the IIS app is running as NETWORK SERVICE or SYSTEM then the IIS machine account has to be trusted for constrained delegation. The linked resource has all the steps to set this up.
If the SQL Server is on the same machine as IIS then there isn't any requirement afaik.
Related
My applications use data from one SQL server on our network. The SQL server is on separate machine from the IIS server that hosts my applications. I am using integrated security, Windows authentication, and impersonation in the web.config. Now I need to connect to another SQL box that does work with the impersonated account. So how do I pass proper identity to each of the SQL servers to get data from each? The web.config only allows one impersonation.
I'm trying to connect and getting an error like:
Login failed. The login cannot be used with Windows Authentication
I'm using mirrored local accounts on SQL Server and web server because I'm simply trying to use a trusted connection between machines not on the same domain. It seems like something that would be fairly common, but after days of trying to find an answer that applied to my situation, I do not recognize that any of the answers were applicable... that or the fact that I'm only a .NET developer and not a sysadmin or DBA means I have it and just don't know it.
Here's what I can say:
CMS web server: ASP.NET 4.0 web app running on Windows Server 2008, IIS7, on corporate DMZ
CMS database server: SQL Server 2008 R2 on a domain server
For various reasons that I won't go in to, encrypting the credentials is not sufficient.
The database port that the application needs to connect on is not the standard port and is set up to listen on a different port.
Setting up DB mirroring isn't an option and doesn't really address the requirements (in my way of thinking)
Also, FYI if this is helpful to know:
Content entry happens on internal web server which publishes content to same DB that is accessed by the DMZ web server.
Content server is set up to have the website run the app pool in integrated mode with a windows domain user that has been set as a service account using the -ga switch and given all the appropriate rights and everything runs perfect.
External web server, without domain access, using mirrored accounts (same username and password set up on the SQL Server machine and web machine).
Local account on the web server set as a service account using -ga switch and running as the app pool identity for my app.
On the SQL Server box, created local user with identical creds and given same permissions that the domain user identity has
Connecting to SQL Server via MGMT studio installed on web server with the SQL Server user creds works fine.
Now, if I put in the username in to the connection strings, everything is perfect. As soon as I put the trusted_connection=yes in the connection string like I did with the domain server connection strings, I get the trust error.
So if my connection string is like this, it works fine:
Server=myServerAddress;Database=myDataBase;Username=MyUser; Password=MyPassword;
If I change my connection string to either of these, it fails:
Server=myServerAddress;Database=myDataBase;Trusted_Connection=True;
or
Data Source=myServerAddress;Initial Catalog=myDataBase;Integrated Security=SSPI;
I'm working with one of the client's network admins and he's not necessarily a DBA and doesn't have experience with configuring web apps. So it's possible that we're missing something and any advice or ideas would help. What am I missing?
If using SQL credentials are not an option, then you should use Active Directory and create a one-way trust (have DMZ server domain trust your internal domain), create a service account in your internal domain which your DMZ application can use, and grant that account access to the database. Then it will be able to generate SSPI context.
What is the disadvantage of having Local System set in app pool instead of Network Service in IIS7 of Windows server 2008?
Local system is a more priviledged account than the Network service and should be avoided if possible.
See the Services and Service Accounts Security Planning Guide for further information on how to configure the application accounts from a security perspective.
Also see these related questions on the security aspects:
What are the security risks in running a Windows Service as “Local
System”?
Why running a service as Local System is bad on
windows?
The difference between the 'Local System' account and the 'Network Service' account?
I have setup 3 VMs:
(A) Active Directory in Windows 2008 R2.
(B) Microsoft SQL Server 2008 Express in Windows XP SP3.
(C) IIS in Windows XP SP3.
Both the SQL Server and IIS are joined in the Domain but the host PC is not. I've also created a domain administrator user with administrator privileges in the SQL Server. I can ping/access all the VMs from each other and from the PC hosting the VMs. I can connect to the SQL Server VM using Windows Authentication in SQL Server Management Studio inside the IIS VM with no problem.
I created a very simple application in ASP.Net application hosted in the IIS VM that opens a database connection in the SQL Server VM. I've set the web site to authenticate via Windows Authentication only. Here is my connection string:
Server=DATABASE;Database=HAP;Trusted_Connection=True;
Here is code:
SqlConnection connection = new SqlConnection(ConfigurationManager.ConnectionStrings["ConnectionString"].ConnectionString);
using(connection) {
connection.Open();
}
I've also set "Trust this computer for delegation to any service (Kerberos Only)" in AD for the IIS VM.
It throws "Login failed. The login is from an untrusted domain and cannot be used with Windows authentication." exception. If I change the connection string to this:
Server=DATABASE;Database=HAP;User ID=sa;Password=connectsql;
the application works fine.
I really need it to authenticate via Windows Authentication and not via SQL Server Authentication.
Note:
IIS prompts the user for his Windows credentials.
It's unclear to me whether you intend the application to authenticate as the logged in use, or whether you simply want to have the asp.net worker process be authenticated via AD.
If you want the user to authenticate with their account, then you need to set "imperasonate=true" in the web config. This will have performance ramifications, but that may be ok.
If you just want to authenticate via the worker process, then you need to set the identity of the worker process to a domain account.
We have an ASP.NET 3.5 application running on Windows 2003. For migration purposes this application connects through ODBC to a very old version of SQL Server 4.21. It always worked until one day stop to work (server doesn't exists or access denied) on all the servers. After a week of research we realize that the problem is the account that run the application pool used in the web application (network service), if we change this account to "local service" or "local system" the connection works, but with these account many other problems appear. with "local system" account all works, but we think is not secure to use an account with admin privileges.
The goal would be:
Make the connection work with the application pool running with Network service account
Know why if it worked for a few months with network service, stop to work.
Maybe we need to grant some privileges to an odbc library or something like that, maybe some security update from windows update was causing the problem.
Some clues:
The web application is running through IIS under Windows 2003. This Windows 2003 is
over an Active Directory domain
The SQL Server is over a NT domain. (NT 3.51)
The ODBC system DSN is using "SQL Server" driver, with TCP/IP or Named Pipes on client
configuration.
The connection to the database use a SAL account, not a trusted connection.
The connection always worked, and stop to work at 24/02/2011 on all servers and
developers workstations
Any thoughts?
You can connect to SQL running as the network service account. On the SQL end, make sure that you have granted access to the DB for "\$". If you are in domain EMEA and the machine's name is "machine1", then the user to grant access to is "EMEA\machine1$".