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.
Related
We currently use a connection string to authenticate our database credentials. Due to grown and compliance the developers are no longer allowed to "see" the database credentials that our websites use. Are solution to this problem is use Integrated Authentication. We planned on setting up a user per App Pool and then allowing that use access to the Database.
My question is: Are there any security concerns around this approach? As far has removing the DB credentials from the connection string, is there a better(easier or simpler) approach we should/could be taking?
If you need to secure and audit access to the production database then Windows Authentication is a better choice than Sql Authentication for a number of reasons:
You can control exactly who can access the database via NT groups and permissions, which means you know who specifically has access to the database. The pool of access with sql authentication is only limited by who knows the password. Given n people who know the password, tracking who did what at a certain point of time is trickier (but not impossible) given that.
Only your sysadmins need know the password for the nt identity with access to the database; in fact, much of the config can be done only knowing the username
Logins and access can be tracked at the domain level far more easily than with SQL Server logins.
What it wont give you is:
Ability to ensure that the developers can't see production data - whoever writes the app can easily include some diagnostic routines to select out data
Ensure that production data only stays in production - anyone making a backup of the production database (say to restore it to a UAT environment for testing) could easily expose production data.
Problems with this approach have already been discussed in other posts; in particular, with ASP.Net applications, you have to consider whether or not you are going to use Impersonation/Delegation (webserver can act as the NT user accessing it) or a Trusted User model (where you configure a fixed identity to access certain resources).
This is further complicated by the IIS version you are using.
If your connection string is stored in a web.config file, you could create a separate production version of that file that the deverlopers can't see. That's easier to test and setup than integrated authentication using app pools.
One word of warning though: If you restrict developers that much, it will slow down their velocity of change. Since the rest of the world does keep moving, this usually ends with the application becoming a dead legacy package. That's dangerous if you plan to grow, improve or extend.
Use of application pool's identity can be quite complicated to set up, consider trust and delegation problem.
A better option can be securing connection strings using encryption.
(A question of similar vein has been asked before but both the question and the accepted answer do not provide the detail I am looking for)
With the intention of running an asmx web service under a dedicated domain account what are the usage scenarios and/or pros and cons of using an Application Pool with the identity of the domain account versus Impersonation?
We have 3 small internal web services that run under relatively low load and we would like to switch them to running under their own domain accounts (for the purpose of integrated security with SQL Server etc). I appear to have the choice of creating dedicated app pools for each application, or having a single app pool for all the applications and using impersonation in each.
I understand app pools provide worker process isolation and there are considerations for performance when using impersonation, however those aside what else would dictate the correct option?
Typically, you will choose different identity for worker process (or do ASP.NET impersonation) because there is need to access local/network resources that needs specific permissions. Obvious dis-advantage is that your application code may run under more permissions than it may need and thereby increasing the vulnerability against malicious attacks.
ASP.NET impersonation would have more overhead because user context needs be switched for each request. I will suggest to go with separate app pool approach - only disadvantage with app pool approach is that you have process for each one of them and so there will be overhead (from OS perspective) for each process. If your applications are smaller and don't have strong memory demands then this should not be an issue,
If you want your web services to connect to SQL via Windows authentication, you will almost certainly want to set up each application with the dedicated app pool option. This requires the least amount of setup and administration.
If you go the impersonation route, you'll need to account for the "two-hop" issue. When a user calls a web service that is using impersonation, the web service can access local resources, as that user. However, if the web service tries to connect to a non-local resource (e.g., a database running on a separate server), the result will be an authentication error. The reason is that NTLM prevents your credentials from making more than one "hop". To workaround this, you would need to use Kerberos delegation. Delegation isn't difficult to set up, but it does require Domain Admin privileges, which can make things difficult in some corporate environments.
In addition, using impersonation means that you need to manage database permissions for each user that may visit your web service. The combination of database roles and AD groups will go a long way in simplifying this, but it's an extra administrative step that you may not wish to conduct. It's also a possible security risk, as certain users may end up with privileges that are greater than your web services are anticipating.
Impersonation is useful when you need a common end user experience with other Windows services that are based on Windows security.
For example, Microsoft SharePoint servers use impersonation because you can access SharePoint document libraries with web browsers and with the standard Windows shares UI (connect / disconnect to a network share, based on the SMB protocol). To ensure security is consistent between the two, in this case, you need impersonation.
Other than this kind of scenario, impersonation is most of the time not useful (but can cost a lot in terms of scalability)
Application pool pros:
You don't have to be a .Net programmer to understand what's going on.
The security aspect leaves the domain of the programmer and falls under the remit of infrastructure
Easy to change through IIS with proper saftey checks that the username is correct when setting up the app pool. I.e. It won't let you enter an incorrect username.
Impersonation pros:
Privileges can be documented and traced back through changes to configuration through source control history if configuration files are stored there.
Impersonation cons:
To change the user, you need to be familiar with .Net configuration rather than just setting up a website
Not sure I can think of much else.
My gut says to go with different application pools for each of the websites but it's your party.
I would advise you to check the following page for security details...
https://www.attosol.com/sample-aspx-page-to-show-security-details-in-asp-net/
Once you are done with this, you will see "precisely" how impersonation changes the identity.
I have an asp.net application that runs on a custom app pool which runs under a service level account. I have anonymous access turned off in web.config. The web server is part of a domain. The application access a sql server which runs on the same machine.
Currently, for all users, I impersonate the service level account to access the Database. When lots of users are accessing the site, this slows the site down as the lsass process starts using the cpu.
I am not allowed to create a sql server account, I have to work with what I have.
I am also not allowed to add each individual user to the database and give them specific access.
My question is, how can I set my application and datbase reletionship up such that I dont have to do impersonation of the Service level account and thus avoid CPU thrashing when website usage is high.
You shouldn't have to impersonate the service account. The service account is the account that needs access to the database and I suppose it already has. Have you already tried running your application without impersonating the service account when you access the database? This should work.
To perform a simple test, check the identity returned by WindowsIdentity.GetCurrent() (inside Page_Load for example). This should return the application pool identity and this is the identity that will be used to access the database.
Of course, this only works if you do not have client impersonation configured in your Web.config file. But since this is not a general practice except for some corner cases I suppose you don't use this. Client impersonation is not necessary for determining who the current user is, you should only use it when you want to access third-party systems (databases, fileshares, queues, ...) using the identity of the currently logged-on user (which is not a very scalable approach).
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.
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.