IIS Insider - December 2003

  • Article

By Brett Hill

What is the Network Service?

Q: In IIS 6, the worker processes that turn our web applications are set to run with the process identity assigned to Network Service'. In IIS 5, the out of process web applications was set to run as the IWAM_<servername> account, which was a normal local user account. What can you tell us about this new account that is important for security and administration?

A: Network Service is a built-in account found in the Windows Server 2003 Server. You are quite right in that it is important to note the distinction between a local user account such as the IUSR and IWAM accounts on IIS 5, and a built-in account. To understand this, you have know that all accounts on the Windows operating systems are assigned a SID (a security ID). The server identifies all accounts on the server by the SID, not the name associated with the SID that you and I interact with in the user interface. Most all accounts created on the server are local accounts and have a unique SID that identifies the account as a member of that server's user database. Since the SID is unique to the server, the SID is not valid on any other system. As a result, if you assign NTFS permissions on a file or folder to local accounts then copy that file along with permission to another computer, the target computer does not have a user account for the migrated SID, even if it has an account by the same name. This can makes content replication that includes NTFS permissions challenging.

Built-in accounts are a special class of accounts and groups created by the operating system, such as the System account, Network Service, and the Everyone group. One of the key characteristics of these objects is that they have the same, well-known SID across all systems. When you copy files that have NTFS permissions assigned to a built-in account, the permissions are valid across servers since the SID's are the same on all servers. The Network Service account in Windows Server 2003 services is specifically designed to provide applications with sufficient privileges to access the network and, in the case of IIS 6, to run web applications without requiring elevated privileges. This is great news for IIS security as no buffer overflow, malicious application reverting to the process identity, or other attack against your application results in the System context. Furthermore, back doors to the System account, such as exploiting applications loaded in Inetinfo via the InProcessIsapiApps metabase key, are not longer available.

The Network Service account was not created exclusively with IIS 6 in mind. It has most of the rights necessary to serve as the process identity for W3WP.exe, but not all. Just like the ASPNET user requires access to certain locations on an IIS 5 server in order to run ASP.net applications, the process identity W3WP.exe requires access to a similar list of locations, plus requires a couple of rights that are not assigned by default to any built-in group.

For administrative convenience, the IIS_WPG group, called the IIS worker process group, is created when you install IIS 6 and it has as members the Local System, Local Service, Network Service, and IWAM accounts. Members of the IIS_WPG have the proper NTFS permissions and user rights necessary to act as process identities for worker processes in IIS 6. The following location has rights assigned to the IIS_WPG:

  • %windir%\help\iishelp\common - Read
  • %windir%\IIS Temporary Compressed Files - List, Read, Write
  • %windir%\system32\inetsrv\ASP - Compiled Templates Read
  • Inetpub\wwwroot (or content directories) - Read, Execute

Additionally, the IIS_WPG has the following user rights:

  • Bypass traverse checking (SeChangeNotifyPrivilege)
  • Log on as a batch job (SeBatchLogonRight)
  • Access this computer from a network (SeNetworkLogonRight)

So, the Network Service account provides access to the above locations, has rights sufficient to act as the process identity for IIS 6 worker processes, and has privileges on the network.

Is IIS 5.1 in Windows 2000 Professional Limited to 10 Connections?

Q: I've heard that IIS 5.1 on Windows 2000 Pro is limited to 10 connections. This would make it unsuable for our purposes and I'm wondering if there is a registry setting or other workaround to increase the number of connections to the operating system.

A: This is one of the most frequently asked questions I've received, as a lot of people have legitimate needs to support more than 10 connections in order to develop and test systems that support multiple, simultaneous access. Nevertheless, some people simply want to use Windows 2000 Professional as a server platform for which it is not designed or licensed. I know there is a lot of talk in the newsgroups and other places about various settings that allegedly allow you to have more than 10 connections, but I have not tested any of them for a simple reason – I believe that if you need to offer server services, you need a server operating system.

It is a common misconception that 10 connections equal ten users. Often a web client will create more than one connection to a web server and so your client IIS server may be unable to support 10 users at the same time. As a result, there is a little known exception built into Windows 2000 Professional with IIS 5 installed that allows you to set a web site to accept up to 40 users. All you have to do is set the number of connections allowed to some number less than 40, and viola, you can accept up to 40 simultaneous HTTP connections. This exception is for HTTP as you are still not permitted to accept more than 10 connections through File and Print Sharing.

What Does the IIS Lockdown Tool Do with Application Mappings?

Q: When we use the IIS Lockdown tool on IIS 5, we disable the application mappings for everything but .asp files. The Lockdown tool does disable the other application mappings, but it does not remove them. Most of the security papers and books I've seen say it's a best practice to remove the application mappings you do not require and that seems to make sense. Rather than removing the mappings, the Lockdown tool maps the extensions to the program 404.dll. What is the reasoning behind keeping the extensions rather than removing them as suggested by security papers including the IIS 5 Security Checklist from Microsoft?

A: The IIS 5 Security Checklist is a decent place to start, but I would urge you to look at the excellent Improving Web Application Security: Threats and Countermeasures guide at https://msdn.microsoft.com/library/en-us/dnnetsec/html/ThreatCounter.asp for a more complete treatment of web security.

Nevertheless, you've asked a very valid question about the mechanics of the IIS Lockdown tool, which is I do recommend for use on IIS 5 servers. The action taken with by the Lockdown on the Application Mappings is just what you described, as shown below:

If your browser does not support inline frames, click here to view on a separate page.

As you can see, any request for .htr or .idc will result in 404.dll being run which will show a simple and uninformative File not Found error to the user. So why map these extensions to 404.dll instead of simply removing them? Let's say you have several files that use the outdated .ida,.idq, and .htw extensions to provide the ability to query index server and display the results. After doing a bit or research, you correctly determine that you can provide the same capability more efficiently and securely using ASP. After writing the code, you go to your application mappings and remove the extensions since .ida, idq, and .htw files are no longer required. As a result, IIS will send your .ida, .idq, and .htw files that are still on the server to the user as text. This could potentially reveal information about your server that you would not rather expose. Of course, you should remove the files from the server in first place, but mapping these extensions to 404.dll reduces your risk should you overlook one of the files, or in the event a developer uploads old content to the server.

A word of caution - you should inspect the Application Mappings periodically to make sure they have not been modified by an installation or uninstallation procedure. Web applications that use specialized files will certainly add their required extensions to the Application Mappings. In the event of the Indexing Service, simply removing the Indexing Service from the IIS server through Add/Remove Windows Components adds the original mappings for .idq, .idq, and .htw back to the Application Mappings and also leaves their associated .dll's (idq.dll and webhits.dll) in Winnt\System32. Consequently, if you do not intend to use Indexing Services, remove it before you run the IIS Lockdown tool.

Submit your questions to the IIS Insider. 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.