Is there really a problem running a application under full trust as long as it is possible to control the configuration of the machine?
Define "ok"
Full Trust means that the application can pretty much do anything it wants, however it's limited by the application pool it runs under, for example, if you run it as Network Service it's not going to be able to access C:\windows, but it could use impersonation to login as the administrator account (if you also had the password) and then run wild.
Full trust gives the application a lot of power:
From http://msdn.microsoft.com/en-us/library/tkscy493.aspx
Specifies unrestricted permissions.
Grants the ASP.NET application
permissions to access any resource
that is subject to operating system
security. All privileged operations
are supported. This setting is named
Unrestricted in the
AspNetHostingPermissionLevel
enumeration.
So I would say avoid it if at all possible, especially if using code from other sources.
I view it as the equivalent to running Windows apps as Admin.
Be sure to read the comment from blowdart with regards to how ACL's affect permissions
I guess what I meant is that while it is not the same as running as Admin, it's a case of "more permissions than required" - I always keep in mind as a rule of thumb you should only ever give the minimum required for the application to function.
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.
(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.
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.
We are receiving an application from a third party that will eventually be installed in our production environment.
As part of the setup, they want us to make Machine\ASPNET an Administrator account.
This seems to me like bad practice, but I need specific reasons if I am going to push back on this.
What are the implications of running Machine\ASPNET as an administrator?
Additional details:
This will be deployed under IIS6 on Windows Server 2003
This is a three tier application. I believe they want the Machine\ASPNET user as administrator on the middle tier, where the WCF services will be deployed.
As you've guessed, making the ASPNET account a member of the Administrators group is a really, really bad idea.
This is because a successful exploit against your third party app (or against any other web app running as ASPNET) would gain administrative access to the machine. This is the principal reason why web app accounts are generally low-privileged.
Instead of granting ASPNET admin rights, you could request from your third party what specific rights they require. You could then grant ASPNET just those rights. This would limit what a succesful exploit could accomplish.
For example, if the app needs read/write access to the registry under HKLM, you could grant ASPNET access to it. Thus an exploit could clobber the registry, but not the file system.
If a vendor is giving this advice you’ll normally find they’ve put doing the job properly in the “too hard basket”. Most likely they’re struck permissions issues and just recommended granting the broadest possible access rights to solve the problem rather than applying the proper due diligence and investigating the route cause.
As others have said, go back and pressure them for more details. There’s a very good reason the ASPNET account operates with limited rights; the onus is on the vendor to properly explain why good security practice should be compromised to run their product.
I would agree this is a very bad idea, if for some reason there was a security breach on the site an attacker could pretty much do what they want with the server.
You need to find out why the user needs to be an admin, get an exactly list of actions that the user needs to perform and just give permission for these tasks. If they can't give you a proper list then just reject it, it shows that they don't know their application very well and that should enough of a worry.
When I access file whith UNC file path from asp.net, I found the following problem. Logon failure: unknown user name or bad password. Pls help me.
The problem may not be with the UNC nature of the path you're trying to access, but with the security credentials. If, for example, you are running your asp.net application under the System account, then you won't be able to access network shares because System is a local account (not a domain account).
I suggest you check in inetmgr under which user your application pool is running (under the Identity tab). Try using a domain account that can access that share.
The solution is held under the impersonation and delegation functionality of asp.net. There are certain constructs which provide a token based security scheme to call a file.copy operation for example with the target being a UNC location. You can check it here.
The account "in charge" when the file access request is issued simply must be lacking credentials to access the share / resource found at the UNC location.
You first need to determine which account is effectively used, as this may vary, and provide the relevant privileges. By default most programs, including .NET programs (to a lesser extent) will run in the security context of the account which launched the program, however this doesn't hold, in many situations, for example if the program is a service of sorts, or if it uses some DCOM objects, or if it impersonate some other accounts etc... Also .NET has a relatively sophisticated system of delegation/impersonation.
One way to diagnose this issue is to add auditing at the level of the UNC file/directory. Upon failure this will leave a event which should show the login name of the account which tried to access the share.