My web-app runs in IIS 6.0 under windows server 2003, and we all know that in this situation, user account "Network Service" is used by IIS.
I happen to have to allow certain user to perform some action on my web page, and that action requires administrator privilege.
The laziest solution to me seems to add "Network Service" to Administrators Group, and it actually works.
MY QUESTION is, how DANGEROUS this solution is, and in what way can it compromise the security of my web server?
This is generally "a bad idea". If this is a public facing server then this is a really bad idea.
What you should do, and this is how we approach problems such as this, is sandbox the specific admin tasks you need to carry out in another process such as a Windows service which has elevated rights.
We then host a Remoting Server in the Windows Service and communicate with the service either over a named pipe or TCP/IP (if machine to machine and this is over a back end private network).
For more information, please see this answer which I left for another user regarding a similar problem:
Windows User Account that executes only IIS7 Provisions
An even better approach would be to never have direct communication between the web application and the windows service, but go through an intermediary such as a job or message queue. Your low privileged application places request for the admin task to be carried out, your elevated privileged service reads these tasks from the queue and carries them out.
In both cases you should ensure that you don't overscope the responsibility of each task. i.e. ensure that if the task is to create a new Windows account on the server then don't allow that new account to gain more rights than it needs.
If I were to write some web function that required box-level admin, I would make that it's own application in its own app pool, lock down that application as tightly as I could, give that app pool a named account (a domain resource, if on an Active Directory), and then give that account admin privileges on the box. Keeping it in its own app pool effectively locks it down from your regular application.
NT Authority/Network Service interacts with a ton of stuff on your machine. I cannot come up with any good reason to get Network Service admin privileges.
Under no circumstances do this.
If you add Network Service to admin group, then all anonymous users accessing your Web app will be admins by default and the damage potential is massive.
Per your question
I happen to have to allow certain user to perform some action on my web page, and that action requires administrator privilege.
that's fine - use Windows authentication on that web page and make the user a normal Windows admin. Now they, and all other admins, can perform the tasks you have set up.
Related
I have an IIS-hosted website that has 11 web services each running under their own virtual application. For each, the underlying folder is a child of the hosting site's folder. All have existed for a year or more, but web service A may never have been actually tested when deployed, the others have been actively used.
We've recently decided to use Service A, made code changes and deployed. Attempting to reach the service throws a 401.3 authorization error:
You do not have permission to view this directory or page.
I've compared virtually everything I can find in IIS (App Pool settings, ASP.NET, IIS and Management Features, etc.) about Service A and it's peers with nothing seeming different.
Once I added IUSR to Service A's permissions, it responded normally. However, none of the other services have this account among their permissions, yet work fine.
Can someone shed a light on why a single virtual app that very closely mirrors ten others would need IUSR specifically listed among granted users?
The IUSR is used by the anonymous authentication. If you have enabled anonymous auth in the ServiceA, that contents is accessed by IUSR. Is the authentication setting different from ServiceA and other websites.
I've got a rather unwieldy legacy intranet app that does a lot of file manipulations across multiple network shares (file reads, moves, deletes, creates directories, etc) and I want to set up a preproduction instance. Currently the app pool is running under a domain account that has been granted access to all these scattered directories. I'm wondering if running a second instance of the site (different server) using the same domain account would be an issue.
This doesn't seem to be an easy question to formulate in a way to get a useful answer out of google. Anyone have any experience doing this? I would rather not have to create more accounts and track down all the locations that would require added permissions if I don't have to.
The aim to set different application pool identity for different application pools is to restrict the limit for application pool. Independent application pool will isolation NTFS permission from accessing the files that the web app shouldn't reach. Just in case the server are under vulnerability attack.
Of course, if you are hosting your web apps in a isolated network environment, you could share your domain account for multiple application pools.
As Lex said, consult your network administrator would get more practical answer.
We have an installer, running as administrator, which installs a web application, running as IUSR, and a windows service, running as Local Service (for now). The web application should be able to start/stop that windows service (and no other) when maintenance mode is enabled via the web interface (e.g. when an update is applied).
Question: Which options do I have?
The installer has a "Run as" option for the service, but it takes username AND password, which I don't have for IUSR. IUSR should be able to start/stop a service that runs as IUSR, right?
Can I give IUSR permission to start/stop that service somehow else (registry)?
Or will I have to create a second service that checks a file for changes, and acts upon these. But then I cannot replace this service in maintenance mode, ever, so this is a dirty hack.
I just read something that said it's much better to use integrated security here on SO, so I've switched all my connection strings over.
The error I get is "Login failed for user 'IIS APPPOOL\DefaultAppPool'."
Before I go ahead and grant this user permission, I wanted to ensure that it was the correct thing to do and I wasn't inadvertently opening the floodgates of hacker hell.
Should I grant this app pool permission to access my SQL or should I create a new app pool?
I'm writing WCF services in .NET 4.5
Do you have other sites or services on the server that use this app pool and could potentially provide a security risk for database access? If yes, create a new app pool. Do you have another site that might cause the app pool process to crash, or might have a memory leak (thus affecting other sites in the same app pool)? If yes, create a new app pool.
Other than slightly more memory usage, app pool isolation really doesn't have any serious downsides. Microsoft "generally" recommends it (although this article is about SharePoint setup, the app pool / database access concept is the same):
You need to establish which Application Pool in IIS is going to be used by the IIS Web Site. Application Pools in IIS access resources on behalf of the Web Site using an account identity that you specify. This Application Pool will be used by the web application to access its content database. Generally, you’ll want to create a new one to keep it separate from the existing Application Pools.
See this thread for some additional discussion of the pros and cons of separate app pools per site.
We have an instance of IIS6 running an intranet website with Windows Authentication and Impersonate = true so that it uses the NT credentials passed in by the clients browser.
The AppPool is set to run as a network service user: serviceAcctX so that we can undo impersonation in rare cases (to read or write a resource that the client user does not have access to)
It works perfectly when the source of the virtual directory is on a local drive. The logged in user is authenticated and page content is customized based on authorization settings.
Our infrastructure team is trying to move the virtual directory source to a file share on a remote server. We have already gotten past the issue with changing the .Net security policy by adding a full trust for that specific file share path. We have set the Connect As property to the same serviceAcctX, the same one that the AppPool is running as.
The site starts fine. However, the client user is not impersonated. The request is processed using the default serviceAcctX credentials instead of with the client's NT credentials as before.
Is there a way to have the client impersonation still work as before and still have the virtual directory on a file share? Any pointers are greatly appreciated.
I'd put this in the category of Not A Good Idea.
There are a number of potential problems that crop up and you are introducing a lot of dependent complexity.
Instead, I'd go for something a little more "offline" than this. Use File Replication to keep the files in sync between your web server(s) and remote server.
Although slightly complex, it increases the survivability of your application. Meaning, if the remote server reboots, goes down, or there is a network problem between the two, your app is still functional. Further, you are still able to have the files on the remote server.
You may have to check the "trust this computer for delegation" check box in Active Directory for the web server in order for the user's token to be passed on.