(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.
Related
I'm new to this old stuff... I've set up my COM+ application (Classic ASP) on Windows Server 2012, but could only get it to run by unchecking "Enforce access checks for this application" in the application properties. It now runs okay, but any time the application tries to hit the database in any way, I get nothing. I've checked access to the necessary folders (as far as I know) and the user (local user, in the identity tab) has read/write access. Any ideas? And is more information needed?
As you probably already know, Windows Server releases are an ever-changing minefield of permission issues (aka user identity issues). What worked under 2008 may no longer under 2012.
The components in a classic ASP solution pretty much all have the potential to be running as different identities in the context of Windows.
Typical examples of unexpected identities are System, Network Service, and IUSR.
Where these options bite are, for example:
In IIS your web site has an assigned app pool in which it runs. The app pool has a user identity assignment;
In IIS, your virtual folders map to physical folders under Windows and there is access security there;
With COM you get a further identity option to set - this is the 'run-as' identity, which is the effective user that executes the COM components for you.
With a database such as MS SQL Server, you get the concept of user connection security which can be set to use Windows user authentication (trust the windows user) or userid/pwd required. So if you use, for example ADODB, in your code you must supply a connection string that you have to match to the connection settings the DB expects and will allow.
From your description I assume that you have the IIS site up and running, and your issue is confined to DB access from the COM components. You need to establish how the COM components connect to the DB and check that the DB will accept the credentials in use. If you are using Windows Authentication for the DB then you need to confirm for sure the run-as identity that is in use. In my setup we create a dedicated Windows user that we set aside specifically to use for COM so that we can be absolutely sure of the identity, and in our most verbose logging from the COM components we capture the run-as identity just to confirm it is all wired up correctly.
We do the same with dedicated Windows users for the IIS app pool user too. In general you are better off being sure which identity is in use by assigning it yourself rather than taking the default. Additionally, the defaults such as Network Service seem to have a diminishing amount of privs in Windows overall.
Word of caution - on the other hand do not give your dedicated users more access than they need, for example making them members of the Administrator group when you are frustrated or feeling your way through permission issues. Sure, assign these on a very temporary basis to confirm that access privs are the issue, but be sure to remove such assignments as soon as you possible can.
EDIT: I had this half written when your comment came in. You say that there was a missing component - I had not considered that potential as you seemed to be saying that the config worked but COM did not. Well done for solving your issue. I will leave this answer in place as some of what I have written could be useful for future folks walking the same or similar path.
I have four different Application Pools, each one for a different web site, all running as Network Service.
Is this a normal configuration to have?
Can it cause problems between the different applications?
If you've configured each site's Anonymous Authentication to use "Application Pool Identity" then requests will run as the Network service account.
If this isn't a shared server, i.e. you're not allowing your customers or users to upload content or deploy ASP.NET applications, and you and your team are the sole deployers/mamagers then this isn't a terrible thing to do.
That said, if one site becomes compromised then it will be possible to attackers to compromise the other sites. If the Network Service account only has read access then the attack would be limited to data theft, otherwise they'll be able to do much more damage.
Unless you have a very good reason to, it is always a good idea to configure your application pools to run as Application Pool Identity. IIS will synthesise an account for you when the application pool is running. You should configure your public facing www folders to give appropriate permissions to an account known as IIS AppPool\[POOL_NAME] where [POOL_NAME] is the name of the application pool for the site.
You may wish to have a read of one of my previous answers related to this to help you understand this mechanism:
What are all the user accounts for IIS/ASP.NET and how do they differ?
And see also:
Application Pool Identities
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.
I'm working on an web application using ASP.NET 4.0, C#, and IIS7. The web application is a content management system that defines multiple user roles, such as editor and administrator. These users and roles are managed by the asp.net membership framework, and the associated database tables are integrated into the web app's database using aspnet_regsql. Finally, the web app is running under the ApplicationPoolIdentity. Thus, the web app runs under the virtual account "IIS AppPool\" which it does not share with any other application.
The site is designed such that user accounts are handed out by the administrator (there is no public sign-up page), although this detail may be irrelevant. In any case, the administrator should have the power to create and delete users and edit any of the content on the site. Editors, on the other hand, should be capable of editing only assigned sections of the site. Finally, anonymous visitors to the site should only be capable of viewing the content, with no option to edit.
The question is: Would it be insecure to just give read and write access in the SQL Server database to the IIS AppPool\ virtual account and give functionality to different user roles in the underlying business logic for the web application?
I wouldn't think so, but due to the necessity of the integrity of the data, I thought it might be a good idea to seek the opinion of another developer.
If (and only if) this does pose an unforeseen security risk, would it be a better idea to use impersonation, store multiple connection strings in the web.config file with SQL authentication, or track user privileges in the database itself?
The question is: Would it be insecure
to just give read and write access in
the MSSQL database to the IIS AppPool\
virtual account and give functionality
to different user roles in the
underlying business logic for the web
application?
This is how it's usually done, and for most business cases this is enough. There are insecurities in every application so you have to do the best you can to avoid buffer overflows, script injections and SQL injections, scrub your input, etc.
If (and only if) this does pose an
unforeseen security risk, would it be
a better idea to use impersonation,
store multiple connection strings in
the web.config file with SQL
authentication, or track user
privileges in the database itself?
Using impersonation is not uncommon, and very easy if you're using Windows Authentication. It's an administration headache, since users have to be added via database security in addition to the application database. Multiple connection strings is probably the least extensible and favorable of the approaches, not to mention it would hurt performance on a busy site.
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.