IIS Insider - August 2003
By Brett Hill
IIS 6.0 Introduces New Users and Groups and Their Default Permissions
Q: I have used IIS for years and am in the process of moving my web sites to IIS 6.0 (new servers, not upgrades). I would like to lock down the security, but I don't want to lock it down so much that the system can no longer process the files. I also see that Windows Server 2003 & IIS 6.0 add new users and groups such as the ASPNET user and the IIS_WPG group, which I want to make sure I include in the security setting for new web sites. Please tell me what I should be setting the permissions to when I create a new web site. I can then add on additional settings as needed. For reference, here is a list of the default permissions that are assigned to the wwwroot folder:
Administrators (Group - Administrator): Full IIS_WPG (Group - IWAM_ServerName, Local Service, Network Service & System): Read & Execute Interactive: List Folder Contents IUSR_ServerName: List Folder Contents Network: List Folder Contents Network Service: List Folder Contents OWS_123456789_admin (Group - Administrators Group): List Folder Contents OWS_987654321_admin (Group - Administrator): List Folder Contents System: Full Control Users (Group - ASPNET, Authenticated Users Group, Interactive): Read & Execute
As you can see there are a lot of permissions and some of them are redundant. I need to create new home folders for other web sites and I want to make sure that permissions are exactly what I need.
A: The answer to what should your permissions be is the fewest possible considering your permissions requirements. In order to deliver static content and scripts, IIS needs only the NTFS read permission. Anything else you add is driven by your business requirements.
The listing you provided looks to me like a clean installation of IIS 6 server with FrontPage 2002 extensions installation. It's important to note that every time you add a service or product, the required permissions, and in some cases users and groups, change on the server. First, let's take a look at the permissions assigned to wwwroot for a default installation of IIS 6 on Windows Server 2003, without FrontPage Server Extensions. They are:
Administrators Full Control System Full Control IIS_WPG List Folder Content, Read & Execute, Read Users - List Folder Content, Read & Execute, Read Internet Guest Account Deny Write
The difference between the IIS 6 defaults I've listed and those you provided is that on your server, you've installed FrontPage Server Extensions (FPSE) 2002. As you can see, the permissions are quite different. FPSE has added:
Network - List Folder Contents Network Service - List Folder Contents Interactive List Folder Contents OWS_<suffix> - List and special permissions according to role. Internet Guest Account List Folder Contents
You are correct in that there is some overlap in these settings. One of the most significant changes are the permissions for the Internet Guest Account permissions where
Deny Write is removed and List Folder Contents is added. As a result, anonymous web users have the same permissions as the Network and Interactive group. Since the IUSR account will always be a member of one of either the Network or Interactive groups, the listing for the IUSR account technically is not required. Additionally, the Network Service Group is a member of the IIS_WPG, so it does not need to be specifically called out.
The way that FPSE employs permissions can be confusing. It is intended to work around a problem that can occur in the event that a user authenticates first to a web site with a user account, and then browses to other content that allows anonymous access only via NTFS permissions. In this case, the user can be denied access; when really you'd like for them to be able to read the content. Fortunately, in Windows Server 2003, you can instruct FSPE to local user groups for permissions instead of the built-in Network and Interactive groups. For details, carefully read http://www.microsoft.com/resources/documentation/sts/2001/all/proddocs/en-us/admindoc/owsj03.mspx.
Finally, the ASPNet user is not on an IIS 6 server by default but is loaded when you install ASP.net. The ASPNet user is not used unless you run ASP.net in Worker Process Isolation Mode for IIS 5 compatibility; otherwise, applications run under the Network Services account by default. For more details about ASP.net and IIS 6, see the IIS 6 Resource Guide at http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/webapp/iis/iis6perf.mspx.
What are Web Gardens?
Q: IIS 6.0 has a feature called Web Gardens that allows you to configure Application Pools to use more than one worker process. When does IIS create the additional worker process and is there anything we need to know about before we implement web gardens?
A: When you create an application pool, you are telling IIS 6 to create a worker process in order to deliver the contents of the web sites, files and folders, that are assigned to that application pool. You can configure an application pool to launch multiple worker processes rather than a single worker process which in some circumstances can help with scalability. This is a feature called Web Gardens, a smaller version of the Web Farm concept. Instead of having multiple computers delivering identical content (a web farm), you have a single computer with multiple processes delivering the same content.
When you configure an IIS 6 application pool as a web garden, you simply indicate that it should run more than one worker process in Maximum number of worker processes setting on the Performance tab of the Application Pool properties. When set to a value greater than 1, each request will launch a new instance of a worker process up to the maximum number of processes you designate. Subsequent requests will be sent in a round robin fashion to the worker processes.
Web gardens can be quite useful in a situation where you have an application that is resource constrained in some way. For example, if you have a slow connection to a database, you can potentially increase throughput for users by having more than one worker process, thereby increasing the number of connections to the database.
While in some cases, the use of Web Gardens can be quite helpful; however, be aware that session information in each worker process is unique. Because requests are routed to the application pool worker processes in a round-robin fashion, Web Gardens are not likely to be useful in application where session information is stored in process.
In a few situations, having multiple worker processes running the same application creates resource contention. For example, if your worker processes are all attempting to log information to a log file or use a resource and that usage was not designed for multiple, simultaneous access, then you may have contention issues.
If these conditions do not apply, then Web Gardens are one of those features that may be exactly what you need and can be a real benefit.
Basic Authentication Versus Integrated Windows Authentication
Q: I have an Intranet site where I want the authenticated users to access a directory hosted on another server. I have mapped the remote server content to drives on the web server and for testing allowed Everyone Full Control on Share and NTFS permissions. Our application, then accesses the content by referencing the drive letters.
When we configure the directory for Integrated Windows authentication, all users are unable to access the remote location, but if we use Basic authentication and specify the domain, the users can access the remote content. My question is why does Integrated Windows authentication fail to remember the credentials of the user for accessing the remote server when Basic authentication can?
A: Despite appearances, this is not an issue about Integrated Windows authentication failing to remember the credentials. One of the key ongoing issues in securing any site or server is the balance between functionality and security. Basic authentication results in a local logon type, also called an interactive logon. This type of credential can be delegated to another server. Consequently, access to remote systems can succeed with credentials obtained through Basic authentication. The same is true for accessing a SQL server. You can authenticate a client using Basic authentication and forward the credentials a SQL server configured to use SQL authentication. However, when you authenticate to an IIS server using Integrated Windows, the result is type of logon called a Network logon. This kind of logon is far more secure than Basic, but the credentials cannot be forwarded to another server, unless Kerberos is used in the intranet. In the event that Kerberos is used (when properly configured), the user's credentials can be delegated throughout the forest (See Microsoft Knowledge Base article 326089).
In order to provide a convenient and reliable method for accessing remote content regardless of the kind of authentication used, when you configure a virtual directory to access remote content, you are prompted to provide a username and password that is valid on both the IIS server and the remote server. Then, when you access the virtual directory, the request is transitioned to the specified user, which can then access the remote content regardless of how the user was authenticated.
Unless you can use Kerberos, I would suggest that you modify your application to use standard virtual directories rather than mapped drives. This will provide reliable access to the remote content. Additionally, use of mapped drives is not recommended because mapped drives are part of the user profile that creates the mappings. If another person logs on the IIS server, the mapped drives will not be present, which will disconnect your application.
Submit your questions to the IIS Insider. A response is not guaranteed; however, selected questions along with the answers will be posted in a future IIS Insider column.
For a list of previous months questions and answers on IIS Insider columns, click here.
We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as is," without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages.