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.
Related
Is it possible to pass Windows domain credentials (users) from their browser directly to MSSQL for database authentication?
Still learning ASP.NET and EF, but I have a working webapp that uses a static DB connection string in my webconfig. I'm using Windows Authentication via IIS to control access to the website, but I need to support read/write permissions in the database, per user.
It would be great if I could just use AD and assign permissions directly in SQL server, instead of having to maintain my own user table and permissions/roles.
It is possible with impersonation. You can configure it to pass the same credentials from the IIS to SQL Server, however, if SQL server is physically in another server, you might need to give some permissions to users. I have done this years ago, but couldn't do it again recently.
Im not using this, but is a interesting question.
If i set a Web Application on IIS to use Windows Authentication and Impersonate the Authenticated User and my ConnectionString to a SQLServer database use Integrated Security=true;, my application when try to connect to the database will use the User authenticated by the application?
If yes, this is a good thing?
( The database has LDAP/AD "Domain Users" permissions. Considering an Database that will be auditable where each user will have your actions logged.)
I believe E.K.'s answer is true only under a situation in which kerberos authentication is used. What you are describing is known as the 'double-hop'. Essentially, if the user authenticates to 'Server-A', the code that is running on 'Server-A' cannot turn around and use those credentials to access other network resources, such as a SQL Server on 'Server-B'. This is detailed quite a bit but here is a direct link: Blog Article
If you are running on a kerberos architected network, then you can mark a server as being a trusted delegation server. But for most people, this is not the case. If you'd like to learn more about how to do this, see this link.
Yes, the connections to the SQL Server will be under those users.
In general, it isn't good. But it depends on the situation. The following are main factors to consider :
Each user will require its own connection. Connections from different users can't be reused even if connection pooling is used. Creating of connection is relatively expensive operation. And each connection requires a little bit of memory
Each user needs to have its log in (or at least Windows group that the user is member of needs to have the log in). This can be additional maintenance to create log ins, etc. On the other hand, each such log in can be secured in a different way. Important to say is that securing objects for different users can be achieved also if a single account is used to connect to the SQL Server
Yes, it would use authenticated user and impersonate the "authenticated user" rights to access the database.
For more information do look on this link How To: Use Impersonation and Delegation in ASP.NET 2.0
The other approach is to use a service account a non-interactive windows domain account that has complete access to the database.
This allows connection pooling
Eliminates complex permission models to allow selected users to perform a delete on a set of data for example.
This does mean however that audit logic has to be added to the data layer of the application and to stored procedures that access the database to insure that the calling user is logged as part of the database access otherwise the service account would be the only account in the audit table.
By default ASP.NET uses the network service account, is this the account I should be using with ASP.NET in production? What are the best practices related to the account used by ASP.NET?
Regards
Edit: If this makes any difference, I'll be using ASP.NET on a Windows 2008 server
For production, you should create a service account that has only the bare minimum permissions in order to run the web application.
The Microsoft Patterns and Practices team provides the following guidance on this:
How To: Create a Service Account for an ASP.NET 2.0 Application
You're gonna get lots of "it depends" answers but here's my 2 cents anyway.
Consider password change management, potential damage through compromise, as well as application needs e.g. trusted connectivity.
In most scenarios Network Service comes out best in these dimensions.
it doesn't have a password, and never expires - no change management required
it cannot be used as interactive login on other machines
it can be used in trusted connections and ACL'd access to other hosts via the credential <domain>\<machinename>$
Of course your app may have different needs - but typically we use Network Service wherever possible - we run 10,000's of machines.
Unless you have some other need -- like a requirement to use integrated authentication to SQL Server for a database connection -- I would stick with the default account. It has fewer privileges than many other accounts, yet is enabled with the necessary privileges to run web applications. Caveat here: we typically don't make any privilege changes for the network service account and usually fire up a VM per production application (or set of related applications) rather than configuring multiple applications per server. If you are running multiple applications per server or make changes to the network service account's privileges for other reasons, you may want to consider using a separate service account for each application. If you do, make sure that this service account has the fewest privileges necessary to run ASP.NET applications and perform any additional tasks required.
You should use a lesser privileged account possible
1) Create a specific user account for each application
2) Create an Application Pool that runs under this account
3) The Website should be configured to run under this Application Pool.
4) In SQL Server, use Windows Authentication and give DB permissions to this User.
5) Use this User in a connection string (ie no passwords in connection string)
6) Use this User to assign permissions to other resources as required.
For my asp.net website with forms authentication, I will use Windows integrated security to access a sql database. I will give DB permissions to the ASPNET or NETWORK SERVICE. Under what circumstances would I use SQL authentication instead?
SQL authentication is also often required when your site is being hosted by an external ISP. They often do not support windows authentication or do not allow you the ability to grant permissions to windows accounts.
Use SQL Auth when you need non-Windows machines to make a DB connection.
Keep in mind that it adds another attack vector (another set of credentials to compromise the machine), so make sure you really need it before using it.
Really you use SQL Authentication when you can't use Windows Authentication. In my opinion that is about the only time. Windows authentication is more secure and can be centrally managed in places which use Active Directory. If you have people who really know how to adminstrate Active Directory and you're in a windows environment, there isn't a good reason to use sql authentication.
With Sql Authentication you have to manage the passwords etc in connection strings and that means that in order to change the account accessing the database, someone has to know how the application functions or at least where the information is stored. With Windows Authentication, all the network admin has to do is enter in the correct username and password into the IIS application settings and you're ready to rock and roll. No developer interaction required.
You have extra steps in securing the connection string information as passwords etc. should be encrypted when stored in the config files. All around there are a lot more steps in invovled in efficiently and securely using Sql Server authentication as opposed to Windows Authentication. This is espcially true if the same sql server credentials are used to access multiple databases across multiple servers.
If you want to completely manage user accounts, you should use SQL Authentication.
This way, you have complete control over user accounts. You could force them to enter private information for example.
Also, like Corbin mentioned, if clients are not running windows OS, you cannot use Windows Authentication (obviously).
Please be reminded that Windows Authentication is the recommended mode of authentication for the simple reason that it inherits the OS authentication. There are many factors that you may not use Windows Authentication as explained above.
That depends. If you are developing a in house web app and the network IT people are down the hall then use Windows authentication. If you are deploying your app to customers and you have no control of their network infrastructure then I would use SQL authentication
If you don't have control over the Active Directory (Like in a hosted situation) or there are users with operating systems other than Windows, you don't have a choice.
Is there a need to create user accounts on the fly with some script? It has to be easier to do for a sql user than the Active Directory (Probably not impossible).
Besides all of the above, consider a case like this:
The account you need to use is from Domain A.
The database is on Domain B.
Domain A and Domain B dont have a trust relationship.
You will need SQL authentication to get past this situation.
Hope this helps.
(To add more clarity): The database is NOT registered with the active directory. Then it is not posisble to use windows authentication.
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.