Here's the situaiton. I'm working on developing a new website to access an old database. This is a DoD installation so there's lots of security around.
The current application is written in classic ASP, VBScript and some javascript. The new systems is ASP.NET.
Accessing the database in the old system meant hitting the server with your own credentials (domainname\username). Now I'm trying to test some of the early development I've done. When I used Cassini (under VS2008), I had no trouble getting to the database because ourdomain\myusername registered with the SQL Server instance as a trusted connection. Due to security aspects that I have to write, Cassini can't serve as a test server anymore - I have to use IIS (we have security card readers here). Cassini can't handle them.
So when I went through all the problems of getting the appropriate accounts added to Administrators on my local pc so that I could debug in VS2008 while using IIS, I tried to connect to the database and I was rejected because MYPC\ASPNET was not a trusted connection.
Altering the existing database is out of the question. Hard coding usernames and passwords for access to the database is out of the question.
I asked the DBA if he could add MYPC\ASPNET to of the domain groups so that SQL Server could see it as a trusted connection (since MYDOMAIN\MYNAME was in a group that was seen as a trusted connection). He tells me that is not technically possible.
In the end there are going to be three or four machines (mine, another developer, the eventual live web server and a future test web server) who's ASPNET accounts are going to be hitting our two SQL servers (live and test).
What do I have to do to make the existing SQL server see me as Friend and not Foe? I looked at impersonation but I get the impression it's not compatible with our system - the business rules make a call to a common routine to create a SqlConnection object and open it (maybe even a SqlTransaction object to go with it) and this object is used for the rest of the business rules and data-access layer until it's done. It didn't look like impersonation would persist once the SqlConnection was opened (and passed, ByRef back to the calling routine)
Thanks in advance for any advice.
You have two options:
Run your web application in an application pool configured to run in the context of a domain account
Use impersonation and configure your web application to use windows authentication only
Use Impersonation
As has already been suggested you should use impersonation.
However if your SQL Server is running on a different machine than your web server then impersonation will not suffice as the credentials of the user will not be delegated to the SQL Server (server hop). In that case you will have to either enable delegation in the AD or create a non-Windows login on your SQL Server and use that instead (this will not work if your SQL Server actually uses the Windows login for access control to tables etc.).
Sounds like you want to impersonate the client who is accessing your web site correct? Have you tried to use impersonation or are you assuming it won't work?
Edit
As Albert points out, impersonation requires the user to be authenticated using Windows authentication. You will want to disable Anonymous Access, and enable Windows Authentication in IIS Management tool.
Related
I have a .net web app hosting in IIS6 with Windows Authentication and anonymous access disabled. The web app is making connection to a SQL Server that is in the same domain, but on a different machine.
I want to have the IIS Worker process acount I_USR_... to be granted access to the SQL Server.
Will this work ?
(Is there a one to one trust ? Or should I make some extra effort to make the trust work ?)
(edit)
On this page I read:
IUSR_ must be in the domain, and given proper access to the SQL Server; or, you must disable anonymous access on the site / application - which will allow IIS to pass the users' credentials to SQL Server. Not doing either of these things will result in an error.
This can work if you provide SQL access to the identity of the application pool.
There is no way you can pass your users' credentials to the SQL even with impersonation.
You should be fine either by allowing that domain account access on the SQL Server box or creating a SQL Server account and use that to query the database.
More information on Connection Strings and Trusted Connections here: http://www.connectionstrings.com/sql-server-2008
It would be a good idea to set up a sql user account or a domain account specific for you connection.
Having the same account helps with connection pooling:
http://msdn.microsoft.com/en-us/library/8xx3tyca.aspx
To get this to work, you must configure Active Directory to establish trust between your web server and the database server. This is called delegation. It is something you must actively configure for each server, because it is inherently unsafe to allow a process to take someone's credentials and use it all over the network.
More info here:
http://msdn.microsoft.com/en-us/library/ff647404.aspx
A slightly more readable version:
http://www.databasejournal.com/features/mssql/article.php/3696506/Setting-Up-Delegation-for-Linked-Servers.htm
I have an asp.net web app which works fine in Windows XP machine in a domain. I am porting it to a Windows 7 stand alone machine. The app uses a web service which makes a call to sql server. The web server (IIS 7.5) and SQL Server are on the same stand alone machine.
I enabled Windows authentication for the website and web service. The web service uses a trusted connection connection string. The web service credentials uses System.Net.CredentialCache.DefaultCredentials. I noticed username, password and domainname are blank after the call! The webservice and web site use the 'Classic .NET AppPool' with NetworkServices identity.
I am getting an exception "NT AUTHORITY\ANONYMOUS LOGON" in the database call in the web service. I am assuming it's related to the blank credentials.
I am expecting ASPNET user to be the security token to the database. Why is this not happening? Did I miss a setting?
(Usually this happens when sql server and web server are on two different machines in a domain, delegation & double hopping, but in my case everything is on a dev box)
It sounds like you're experiencing the "double hop" problem. It basically means that you're not allowed to forward the clients privileges to a third party, usually a sql server on another machine.
I've answered this before, perhaps that answer will help you further.
Your problem seems to be related to the web service passing the correct credentials to SQL server.
There are a few layers of security for you to check. But the first and easiest is to make sure you have disabled any security other than Windows Integrated. IIS will always use the simplest security protocol. So if you have Anonymous and Windows Integrated enabled then you web site will always choose Anonymous.
Next each site in IIS7+ runs under an app pool which can have separate security. Then under all that the IIS Windows Service runs under a specific account.
Buy default you shouldn't really have much problem with app pool and IIS security as it pretty much works out of the box, but it's worth checking.
One more thing I would check is the named pipes in SQL. My knowledge isn't vast but I know that named pipes can be used for communication on the same server between various applications, IIS and SQL being two of them.
If names pipes is disabled through the SQL configuration manager then I would have expected a different error, but it's worth enabling.
Hope this helps.
Mike
What's the preferred (best practice) means of connecting an ASP.Net Website to a database? I doubt it's as simple as using Trusted-Connection and giving the NT-Authority accounts access.
What do y'all do? Assuming a clean install of SQL Server (2008), what do you do to configure access to the database for a website?
I usually run ASP.NET app pool as a separate account (not NT AUTHORITY\NETWORK SERVICE) and use Windows authentication to access the SQL Server. This method has the advantage of not storing the password in config files.
Steps:
Create a user account to run your ASP.NET application on.
Create an application pool in IIS and run it on the created account.
Assign NTFS permissions that your application needs to the account.
Grant permission to login on SQL Server.
Assign the appropriate database roles to the created login.
This will work for many apps. For more complex security environments, you might need more sophisticated strategies.
I used to use trusted connections, but ended up feeling that that sometimes I ended up having to grant too many privileges to the service account used for the connection/app pool. Now I use SQL Server accounts and set up the application to encrypt the connection strings during Application_Start if they aren't already encrypted. In fact I encrypt any section that may contain user credentials. I use an appSetting to determine whether the encryption code runs so I don't encrypt my settings in the development environment.
I also use SQL Server accounts, just find it simpler to do and to troubleshoot.
Best practice says to keep my web app and database on separate machines, but when doing that it seems I can't get a clear explanation on how best to make this connection. Whil windows auth is the recommended authentication, I don't see how to make a trusted connection . Must I use impersonation to have my application connect to a db server?
Are most people simply using SQL authentication in this case?
Both machines are on a virtual cloud network.
If both computers are in the same domain, I'd use Windows Authentication for the SQL connection. To set it up:
Create a domain account to use for the app.
Give the id the absolute minimum priveleges necessary to host the site on the web server. For example, it must have read access to the web site itself, write access only to folders updated by the web site, etc.
Change IIS so that the domain account is used to run the app. In IIS6 & IIS7, you do this through the application pool. In IIS5, you have to change the settings in the machine.config or in the web.config for the ProcessModel.
All calls to the database will be done through this domain account; you won't have to setup impersonation. In fact, if you are using SQL authentication today, the only change you need to make is to the database connection string; no code changes are needed.
I am having a problem with deploying a ASP.NET V2 web application to our deployment environment and am having trouble with the sql server setup .
When I run the website I get a Login failed for user 'MOETP\MOERSVPWLG$'. error when it tries to connect to the database.
This seems to be the network service user which is the behaviour I want from the application but I don't seem to be able to allow the network service user to access the database.
Some details about the setup. IIS 6 and SQL Server 2005 are both setup on the same server in the deployment environment. The only change from the test setup I made is to point the database connection string to the new live database and of course copy everything over.
My assumption at this point is that there is something that needs to be done to the SQL server setup to allow connections from asp.net. But I can't see what it could be.
Any Ideas?
It sounds like you're able to connect to the database alright and you're using integrated windows authentication.
With integrated windows authentication your connection to your database is going to use whatever your application pool user identity is using. You have to make sure that the user identity that asp.net is using is on the database server.
If it is a fresh install not everything may be setup. Check SQL Server Configuration Manager, http://msdn.microsoft.com/en-us/library/ms174212.aspx. Step by step instructions http://download.pro.parallels.com/10.3.1/docs/windows/Guides/pcpw_upgrade_guide/7351.htm.
The user name you've indicated in your post is what the Network Service account on one machine looks like to other machines, ie "DOMAIN\MACHINENAME$".
If you are connecting from IIS6 on one machine to SQL Server on another machine and you are using Network Service for the application pool's process identity then you need to explicitly add 'MOETP\MOERSVPWLG$' as a login to the SQL Server, and map it to an appropriate database user and role. Type that name in exactly as the login name (minus quotes, of course).
Make sure there is a login created for the user you are trying to log in as on the sql server.
There's a few different things it could be.
Are you using integrated windows authentication? If so, you need to make sure the user ASP.net is running as can talk to the database (or impersonate one that can).
Does the web server have permission to talk to the database? Sometimes a web server is deployed in a DMZ.
If you are using a SQL Server login, does that same login exist on the production server with the same permissions?