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
Related
I have two servers, let's say they are APPSVR (ASP.NET) and DBSVR (SQL Server). Currently, the application running smoothly with database connection using SQL Server authentication with User Id and Password.
In the future, it must be changed with Windows Authentication Integrated Security=True. I have tried to change this but can't worked (DB connection failure).
We have domain controller also and both server in the same domain. I am not sure which one that must be configured in our environment (Domain/SQL Server/IIS Manager). What's the right procedure to do this?
Is your asp.net application already running with domain user authentication?
Do you need per user login for SQL server because you set up the
access right on domain user rather than create your own access right
system on your asp.net application?
Why i am asking you this? Because You need to consider the differences between web application and desktop application. In web application, the web server contact the sql server not the user pc.
So this complicate the setup if you want the web server to use the windows authentication to login to sql server then you need to set up the web server to somehow masquerade as the domain users. You also need to consider the scenario if user are accessing the web application from the internet.
I suggest using strong application only password for sql server connection using local user rather than domain Users. For access right you can simply create a new table to store domain user login id and their access right. This set up still allow login to web application using the domain Users but the database connection is not. The Advantage is you can minimize the access to simply few or even one user application only user you need to maintain in sql server rather than every domain Users that need to be registered on sql server if you use windows authentication.
If you still need the Windows Authentication set up than you can see the info here.
We recently had to change over to using Windows Auth instead of a SQL Account to access the DB from our ASP site. The trick is to have the application pool start up with the same domain account you use to access the SQL Server and then you can just change your connection string to use Integrated Security.
The process is shown here:
https://thycotic.force.com/support/s/article/Using-Windows-Authentication-to-access-SQL-Server-Secret-Server
I have installed a new web application that access a SQL Server database in a different server. I'm using Windows Authentication and get the error of:
Login Failed for user XXX
When I try to set identity impersonate="true" in the web.config file, it just throws an error
Login Failed for anonymous user
Also, I'm using forms authentication to validate users from my website and using a different application pool.
Update: connection string Basically like this:
Data Source=myServerAddress;Initial Catalog=myDataBase;Integrated Security=SSPI;
Update:
My Virtual Directory has Anonymous Authentication and Windows Authentication enabled.
Typically ASP.NET runs as an anonomous account. In order to access a remote SQL Server using integrated authentication (SSPI), you'll need to have a bit more "permenant" presence. Easy way would be to shift the app pool to use the NETWORK SERVICE built-in account. Slightly trickier would be to use a named account. On the SQL server side of the equation you will need to give the same account -- either matching user/pass or NETWORK SERVICE -- proper permissions to your database.
Your DBA should be able to help.
It is difficult to provide you with an exact answer because you have not provided your connection string or info on your SQL Server config. Your best bet is to look at the IIS configuration and work out what user is attempting to access the different SQL Server. You then need to give this account access to the database. This is a common problem and most of the changes need to happen in SQL Server unless you can change the account that the web server is running under.
What I want to do is:
Allow anonymous users to access my ASP .NET site.
Use Windows Authentication for the site to access Sql Server. It will log in to Sql Server with a domain account set aside especially for the site (and preferably do everything under the same account).
Every article on the Web tells you to do this:
<authentication mode="Windows"/>
<identity impersonate="true"/>
in Web.config. However, I gather that this is only if you want users to log in with Windows Authentication. It has nothing to do with the server logging in to SQL Server (except that the combination of the above 2 implies that users' authentication will also be used to connect to the database). Is this correct? Given that my Windows account has access to files on the server and the database which the site is connecting to, this seems hard to test....
It seems that if I:
set the App Pool Identity to the domain account
enable Anonymous Access on the site using the domain account
use a connect string with Windows Authentication
then the site will connect to SQL Server via Windows Authentication. Also, it will use the domain account as long as impersonation is off. Is this correct?
in Web.config. However, I gather that
this is only if you want users to log
in with Windows Authentication. It has
nothing to do with the server logging
in to SQL Server
This is partially true. The impersonated account will be used to logon SQL server if delegation is setup properly. You didn't see this because in most of the environment, delegation needs to be explicitly setup. Delegation is a more powerful form of impersonation and makes it possible for the server process (in your case, IIS process) to access remote resources (in your case, SQL server) while acting as the client. For more information, you can google ASP.NET Delegation. I said it's partially true because in some simple environment, you don't even need any special configuration. The delegation is just working. For example, if you have SQL server running on the same machine as the IIS server. Another case is that you have your IIS server running on an Active Directory domain controller (very rare). In these two cases or on a machine with delegation configured properly, your above statements will be wrong.
It seems that if I:
set the App Pool Identity to the
domain account
enable Anonymous
Access on the site using the domain
account
use a connect string with
Windows Authentication
then the site
will connect to SQL Server via Windows
Authentication. Also, it will use the
domain account as long as
impersonation is off. Is this correct?
Yes, this is correct.
Given that my Windows account has
access to files on the server and the
database which the site is connecting
to, this seems hard to test....
It's easy to test if you have two domain accounts (or one domain account and one local account). Set the App Pool identity to use your DomainAccount1. Grant only DomainAccount1 to have permission to access your database. Access your web app on another machine using another accound (either domain account or local account). Test if the web app can properly access your database.
If I'm following you correctly, you are right; You do not want to use impersonation/authentication to do what you want to do. Set the App Pool identity appropriately, and assure that user account has appropriate access to SQL Server.
Instead of using a Windows Account you can create a separate Sql Login i.e. a username/pwd and use that in the connection string instead.
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.
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.