IIS5, IIS6, IIS7, Apache web servers

Windows Vista Beta 2 & IIS7 beta 2

2006-05-24T00:39:00.000-07:00

Windows Vista Beta 2 and 2007 Office System Beta 2 are now available for immediate download from MSDN Subscriber Downloads.
Also IIS7 beta 2 included.

Be among the first to download Vista and Office by signing in above. Once authenticated, you can begin the download.

Note that this build of Windows Vista Beta 2 contains functionality to unlock several different versions of the software, including Windows Vista Ultimate Beta 2, Windows Vista Business Beta 2, Windows Vista Home Premium Beta 2, and Windows Vista Home Basic Beta 2. Please visit the Product Keys page within MSDN Subscriber Downloads to obtain the Windows Vista Beta 2 key(s) for the product(s) you prefer.

For more information on Windows Vista or 2007 Office System, please visit the MSDN Developer Centers for Windows Vista and 2007 Office System.

Get It First! from MSDN Subscriber Downloads.

IIS7 first impression

2006-05-16T04:43:00.000-07:00

Couple IIS7 gotchas running ASP.NET Apps
I've had a little time today playing around with IIS 7 on Vista, and there are a couple of problems that took some time to get around to get an application to run. If you're trying out IIS with your ASP.NET applications this might help you.

#1

The default installation sets up AppPools under NETWORK SERVICE, but NETWORK SERVICE is not added the Temporary ASP.NET directory in the .NET framework path. This causes ASP.NET to fail out right complaining that an invalid directory name is used.

Actually this may not be the whole of it as I tried adding NETWORK SERVICE to the permission set and adding it file full access rights. Still doesn't work. Ultimately I had to change the AppPool to run under Local System and then the app started running.

I'm not sure what else could be the problem with NETWORK SERVICE, but it works with SYSTEM. Obviously this is not a secure solution but it works for now. In any case the default installation apparently doesn't have enough permissions to run ASP.NET apps (much like .NET 1.0 did).

#2

It looks like the ASP.NET State Service is nowhere to be found. I installed IIS using default options, but no state service. I went back to Windows Component to install under IIS but I see nothing that explicitly installs this service.

At this point I had to switch back to InProc, which is fine for testing.

It's taken a few false starts to get even this far. At this point I have several apps running both in ISAPI pipeline (IIS 6 mode) or in the integrated pipeline (IIS 7 mode) and the 3 apps I threw at it were running fine. In addition I also installed a Web Connection ISAPI application on the server and that ran fine as well at least in ISAPI mode. However, in either of these cases the configuration applications did not work as it looks like ADSI configuration is either not there at all or disabled in this build.

Now I can actually play around with the new features of the integrated pipeline. The most interesting thing to me at least is the low level HTTP Module integration that allows .NET components to handle all traffic directed at the server. There are a couple of interesting things I want to try including throwing Web Connection into this area and replacing the truly hideous ISAPI/COM code that drives that particular engine.

One of the more visual changes for IIS 7 is the new management tool which replaces the MMC interface. I was looking forward to this, because as far as I'm concerned the MMC has produced nothing but horrible interfaces. The new management tool looks a lot nicer and more importantly is a lot more snappy.

Unfortunately it's a mess to use at this point. The interface is horribly busy and there are way too many options the various pages with names that are not real clear. The console mixes both IIS and ASP.NET settings which I think is part of the reason for this confusing interface as there are terminology overlaps. While there are grouping options it seems that you end up hunting around a lot for finding the right options. As bad as the IIS 6/5 MMMC interfaces were, the way they grouped the various choices together seemed reasonably logical and well organized and you get to most places with a couple of clicks.

Here the choices seem scattered about in inconsistent ways in many places. One good example, is the basic properties dialog which is not accessible through the main list but sits of on the side and context menu only. But these options are accessible only in the top level view, not when you're furtherdown.

I'm sure it's not easy to build an interface for this many options, but I think what's really needed is much better grouping of options. Some high level overview that has a manageable number of options on it into which you can drill down later.

Internet Information Services

2006-04-26T00:38:00.000-07:00

IIS, an acronym for Internet Information Services is a web application server program that handles HTTP requests, ranking second in popularity (after Apache). Its popularity is mainly due to the fact that IIS sites are so easy to implement - just a few mouse-clicks away - from a total disaster.
Easy to use, easy to hack. Indeed, the ease of installation can further tempt users to overlook careful planning, adequate fundamental security measures or patching holes when they emerge. Such a default installation is massively vulnerable and it is no wonder that attackers are finding IIS to be "the easiest pickings" of all Web servers. Something must be going on if one considers the outburst of CodeRed infection. If so, what can be done to prevent the problem? The most important aspect of any security countermeasure is, knowing what to look for and where to look for it.

The Internet Information Services is a suite of tools and services for creating, managing, and securing Web sites that is included with Windows NT operating systems (also Windows 2000, XP and .NET). The IIS services are tightly integrated with the operating system and therefore all IIS versions are Windows-dependent, namely:

IIS 5 - is associated with Windows 2000 (all versions) IIS 5.1 - is associated with Windows XP Professional IIS 6 - is associated with Windows .NET Server IIS versions 3 and 4 are designed for Windows NT 4.0, (technical support for this is expected to be terminated by the end of 2002)[1]. The IIS Versions designed for workstations (that is IIS5 in Windows 2000 Professional and IIS5.1 in Windows XP Professional) have limited functionality as compared with their server versions (IIS5 on Windows 2000 Server and IIS6 on Windows .NET Server). This limited functionality relates, for example, to a maximum of 10 concurrently handled HTTP requests, the possibility of running a single Web site only, lack of host IP-based access control list, no Connection Limit extension. Therefore, IIS workstations are not suitable for serving up fully functional web sites - this limitation continually triggers the irritating "403 Too many users" message, despite the fact that the logs show that there are fewer than 10.

(Fig.1 Whether our site is reaching its maximum popularity or our server is experiencing difficulties to handle requests?)

Since Windows .NET Server (together with IIS6) is at the moment undergoing finishing touches and unavailable for purchase as yet, we will focus below on Windows 2000 Server IIS Version 5. This is because this version is currently the most suitable to be a powerful server for a new generation of Web applications. Moreover, given the availability of downloadable patches being of vital importance for web server security, we will deal further with the English Version of Windows 2000 Server.

Getting installed with IISAll IIS services are installed in the same manner as any other Windows component - through the Control Panel: select "Add/Remove Programs", then click on "Add/Remove Windows Components". The screen will appear that allows you to install new Windows components - this requires caution, because an operating system connected to the Internet is particularly vulnerable to attacks. Therefore DO NOT install IIS together with services that are of key importance for LAN functionality or security. Locate the Internet Information Services (IIS) entry and then click on the Details button to select the necessary IIS pieces of functionality. They are:

Common Files - that is, the main files and services included with IIS, Documentation - files of the Default Web Site, files containing IIS error messages and the basic HTML documentation (C:\WINNT\Help\iisHelp directory), Internet Information Services Snap-In - an application for managing IIS from the Microsoft Management Console (MMC), World Wide Web Server - which provides Hyper Text Transfer Protocol (HTTP) services compiled in a user-friendly manner.Other IIS components that may deserve further attention are as follows:

File Transfer Protocol (FTP) Server - included in the system provides support for an FTP account. Remember however, that the FTP service lets you force anonymous logons because it does not use encryption for authentication. You should also be very restrained when considering other options that require logons (web site update, sharing files). NNTP Service - to host newsgroups. It can be utilized, for example, for client-to-server and employee communications, but it is not recommended to use the USENET features (that is the commonly available newsgroup hierarchy) because of their limitations. SMTP Service - the email server. Being an SMPT server, it provides only mail delivery functionality. It is not intended to aid in receipt of emails, but with its Collaboration Data Objects (CDO) component it is able to forward messages from WWW sites. Remember, however, to ensure that your spam-borne mailing service will be appropriately secured to avoid this nuisance i.e. preventing your server from being used to relay spam! [2] There are also components that when installed, may be risky from the security point of view and are therefore not recommended, please consider:

FrontPage 2000 Server Extensions - this is a special communication protocol that supports authoring and administering Microsoft FrontPage webs, Internet Service Manager (HTML) - is designed to configure and monitor IIS using WWW pages, Visual InterDev RAD Remote Deployment Support -this is a sub-component that assists in the development of web applications via Visual InterDev. While installing IIS remember, that any subsequently added service will imply the need for proper configuration and maintenance of its security environment otherwise problems may occur and worse, persist. On poorly secured and/or configured servers everything may happen quickly: unauthorized third party relaying, illegal contents, mail viruses and hacking attempts, potentially involving "ritual" problems, with possible legal risks for you, as the owner of the server. Depending on the scale of your web site, installation of the previously mentioned IIS components, SMPT and anonymous FTP may be enough.

(Fig. 2 Installing IIS)

The general approach involves closing down the connections to the Internet while installing web services - once installed, IIS can potentially expose your server to unfriendly forces. Of course, a complete firewall solution or a NAT device may be enough to deny incoming traffic as appropriate. In fact, further sections of this article will be devoted to some security countermeasures allowing a safe installation of IIS components while still allowing Internet connectivity and access to your WWW pages.

Security considerationsThe first step in securing your server is to download the most updated Service Pack (currently Service Pack 3 [3]) and current IIS patches (MS02-062 is the recent patch concurrent with this article [4]). The system administrator, should also download other patches as required for Windows 2000 [5] (at least consider seriously their implementation) and Internet Information Services 5.0 [6]

(Fig. 3 Windows 2000 Patches & Updates).

In addition, don't forget to register so that you will automatically receive Microsoft security bulletins [7]. This is of fundamental importance because procurement and installation of any update patches is a must from time to time in order to keep the server operating securely (hackers and viruses like to find out where "lousy software" is!). Don't forget to confirm your subscription by replying to the email with the instructions included.

In the next step, setting up the computer is important enough to not be ignored [8]. The simplest way is to get HiSecWeb.exe file from the Microsoft Web site [9], unpack it to the C:\WINNT\Security\Templates and follow the instructions given in [10]. Open it in mmc.exe (using the "Security Configuration and Analysis" application to be downloaded from the Console > Add/Remove Snap-In menu) and run (being prompted to import hisecweb.inf, select "Analyze Computer Now" from Action menu, and then "Configure Computer Now." Remember that HiSecWeb is designed for dedicated Web servers and it disables all services that are not associated with web access services. The HiSecWeb package does not alter the permissions within the file structure on the system partition [11], while the WWW files are to be installed on a non-system partition, the hardening of which will be discussed later.

Post installationOnce all necessary patches and updates have been applied and the system settings chosen, you must disable access to the default Web site that has been installed concurrently with the IIS documentation. To do this, run "Internet Services Manager" (within administrative tools, that is Programs > Administrative Tools). This program is an MMC application that was been previously installed under the name "Internet Information Services Snap-In". Once started, choose a name for the server, right mouse click on "Default Web Site", and then select "Properties" from the popup menu.

In order to disable the default web site, assign it to the localhost address (that is 127.0.0.1) - in the "IP Address" box (the "Web Site" tab) delete "(All Unassigned)" and insert 127.0.0.1, and then click "OK"

(Fig. 4 assigning the default web site to the localhost address).

This will cause the default web site to only be accessed from the web browser running on the server, not from the network. It is better to leave the default web site disabled rather than remove it, as it may come in handy later. Right mouse-click on the Default Web Site and select "Stop" in popup menu (instead using the right mouse button, you may use "Action" menu). Naturally, if you plan not to use the default web site anymore, for example to check location of IIS installed files or to read IIS documentation, you can remove it (from popup menu). So far, no other changes to the IIS configuration are necessary, but you can review all tab settings. As you can simply check, directories (and even individual files) can have their own settings within the IIS configuration.

In the next step related to the IIS hardening, you should set master properties for the WWW services. Contrary to the default web site configuration, the IIS configuration is a hierarchical one, that is, any changes to the IIS configuration associated with the WWW Service Master Properties (W3SVC for short) can be inherited through the hierarchy of the embedded system components (sites, applications, directories and files). When you configure properties at the level of the IIS server, certain security-related settings will become the default settings for all web sites (the existing ones and those which are to be created). Before attempting to change settings, ensure that you make a backup copy of the metabase (i.e. the IIS configuration). To do this, in the "Internet Services Manager" application, right mouse- click the server (not the web site!) and click on "Backup/Restore Configuration". The backup IIS copy management window will appear. Click on "Create backup " , and insert the backup copy name (for example "Manufacturer's Configuration") and click OK. The backup copy has been stored to the file in the C:\WINNT\system32\inetsrv\MetaBack directory.

(Fig. 5 the first IIS configuration backup copy).

After making the backup copy, close the "Configuration Backup / Restore" and configure the W3SVC services. Right mouse click on the computer name and select "Properties". Under "Master Properties", click "Edit " next to the "WWW Service" tab. The window similar to the web site configuration will appear - it has its "Service" tab. Pay attention, that certain components are disabled (because they are consistent with individual web sites only). On the "Web Site" tab, select the "Enable Logging" check box and then select the format (I recommend that you select "W3C Extended Log File Format"). Pressing the "Properties" button can modify both the file rollover period (preferably leave "Daily") and the location of the log directory. Because a typical server can have logs measuring dozens of MB daily, it is a good idea to choose a directory on a dedicated disk, for example E:\LogFiles (remember to establish an appropriate directory on the selected partition). You may also enable local time logging (I don't recommend this), and select the scope of the logged information. My advice is to select all boxes excluding "Process accounting" on the "Extended Properties" tab. These options are useful at troubleshooting, detecting intrusions, examining traffic etc. The "Process Accounting" boxes allow one to analyze the server load resulting from individual HTTP requests, but I do not recommend that one use them during a normal operation of the server.

(Fig. 6 Details of WWW Server logins).

After enabling the logging feature (in the master properties of the W3SVC), change the Home Directory settings. In the "WWW Service Master Properties" window, select the "Home Directory" tab and then click on "Configuration ". The "Application Configuration" window will appear, it allows you to set up dynamic WWW pages that are files with specific extensions. Whenever they are called from the Web, they will be passed through the W3SVC service for execution by ISAPI applications, that is additional programs (more specifically - DLLs) installed on the WWW server. These programs are, for example, C:\WINNT\System32\inetsrv\asp.dll, ism.dll, httpodbc.dll, ssinc.dll and C:\WINNT\System32\msw3prt.dll, idq.dll and webhits.dll (within the same directory). You must remove all said programs, leaving only those using asp.dll (and also ssinc.dll if it is considered useful) - all others were used in the past for breaking into the IIS servers and infecting them with viruses (for example CodeRed that uses a known buffer overflow vulnerability contained in the idq.dll). Of course, given all these patches and updates installed previously, it is quite impossible to feel unsecure even with the entire set of ISAPI programs enabled. However, an experienced system administrator would know the old German saying, "once lost, confidence does not easily return" - particularly when the ism.dll application had "lost confidence" with its record-breaking negative events. One is advised to only leave enabled for use the asp.dll and possibly ssinc.dll - since they both also had security-related problems, but of considerably less importance and which were far more difficult to be exploited by hackers.

Files with .inc extensions will not be compiled, executed, or served with the default installation of IIS. In order to have ASP pages served, you will need to give all include files a .ASP extension and add these extensions to the Web Service Extensions list. Otherwise whenever any request is made for an .inc suffixed page, its code will be revealed for public viewing instead of executing it (even with errors, it is far better than publicizing dynamic pages code). Of course, the same procedure should be followed for any other extension scripts. Those who save ASP customization in the .txt files deserve to be given special attention from the system administrator.

In order to setup the extension service via ISAPI applications, click on the "Add" button and then fill in the boxes:

Executable: C:\WINNT\System32\inetsrv\asp.dll Extension: .inc Limit to: POST, GET, and HEAD It is a good idea to provide each extension (those default included) with the "Check that file exists" option enabled - this setting implies that if the requested file doesn't exist, the usual error processing occurs ("404 Not Found") instead of producing the ISAPI application error.

(Fig. 7 Adding ISAPI scripting environment).

The ISAPI msw3prt.dll functionality is dependent both on the IIS and "Web-based printing" setup in the group policy (defined on a local computer and the relevant GPO). It also depends on Print Spooler functionality - which was disabled while launching hisecweb.inf. When you intend to upgrade a Service Pack (sooner or later), the installer activates the Print Spooler service if it's not already running. However, if you have disabled the start-up type for this service, the service will fail to start. This is a strange but consistent requirement associated with the installation of all existing Windows 2000 upgrade packages.

The next important applications to be set up are listed in the tabs of the "Application Configuration" window. On the "App Options" tab, clear the "Enable parent paths" setting to ensure that the FileSystemObject started by an ASP application is limited to that application's defined directory. Another possible service to disable is the "Enable session state" to avoid overloading the server's memory at any ASP request. (Encourage the Webmaster to accept this change). On a cluster of Web servers (where many Web servers share the responsibility for responding to user requests), a Web page will not always function properly. This is because a single user session cannot be created on one server and then read and modified on another. With the advent of IIS 6 and its user session synchronizing support, this limitation will not longer be maintained.

On the "Process Options" tab you can either modify or disable the ASP file cache size - I would discourage you from enabling "Cache all requested ASP files" as the usage of server RAM for ASP session variables could become quite significant.

Lastly, on the "App Debugging" tab, ensure that the debugging options are unchecked and change "Send detailed ASP error messages to client" to "Send text error message to client". This will prevent potential attackers from compromising your website and then provide a simple text for error of WWW services with a possible email address included for reporting problems. With all applications set up as desired, click OK.

If at anytime during these steps you see the "Inheritance Overrides" properties box, this means that certain W3SVC components (web site etc.) have their own settings that are different from the master properties being applied. As you may remember, settings are inheritable, therefore you must decide whether to delete or maintain invariant certain settings as replicated ones. As the default web site is of concern, I suggest not to change anything, whilst for your own web sites use the documentation you are maintaining as guidance. Just click the OK button - do not touch the list! - The master properties will be modified but those previously set will remain unchanged.

(Fig. 8 Changing Master Properties; the Default Web Site settings remain unchanged)

After defining the default application settings, go to change the default WWW site settings. Select the "Directory Security" tab in the "WWW Service Master Properties" window, click on the upper button marked "Edit". The "Authentication Methods" window will appear with their enabled "Anonymous access" and "Integrated Windows authentication" options. It is advisable to uncheck the latter option in respect to commonly accessible WWW pages - it may allow "brute force" attacks from the Internet, targeted at unscrambling server (or related network) user passwords in transit. Unfortunately, this option is to be recurrently disabled, since it is activated by default whenever any new domain is opened. Also remember to uncheck the authentication options after installing SMTP and/or FTP services - this issue will be discussed later. After pressing OK, and then "Apply" you will again see the "Inheritance Overrides" window - do not enable any component belonging to the default web site (for example the .in. file localstart.asp file) and click OK again. The "Edit" button underneath allows defining of appropriate IP and domain restrictions - you might use it for a server that by default is designed for access by a selected group of users only (for example Intranet users or your company partners connected via ISDN). Remember that IP restrictions do not ensure high security level - today's IP protocol does not provide fully secure authentication of the connection source. If you want to have your server accessible from trusted sites only, take advantage of a Virtual Private Network (VPN) solution. On the "Documents" tab you can define default documents. If a domain or directory contains a file with its filename not listed here, the user will see the "403 Forbidden" error message (or the content of the entire directory if the "Directory browsing" has been enabled in the Home Directory option). It is good practice to consult the Webmaster about filenames to be placed on the list - for example, it may be required to add a name index.html.

Generally speaking, your IIS server is now fully set up. However don't forget to look at other tabs to ensure that the "Home Directory" tab has unchecked the "Read", "Write" or "Directory browsing" options, that the "Execute Permissions" (related to dynamic pages) are set to "None", and that "Log visits" is ON. As for the "Home Directory" settings, they will be re-visited after a new WWW site has been established.

Creating Web pagesWhen creating web pages, it is important to be aware of a problem when starting the work: you should provide a separate partition for WWW pages. Create separate partitions for your NT and Internet data. This suggestion is subtle but important. If you place each logical group of files or each independent directory structure on a separate partition (separate logical disk drives); you reduce the risk of contamination. For example, if you store your Web pages and your Web scripts in the same directory, hackers can break into your Web page area and easily contaminate your scripts.

This can be the same partition you use to store logs - pay attention not to store operating system programs on it (preferably no other programs if possible). Why this requirement? Unfortunately, IIS has a history of problems regarding improper access to programs outside the directory of WWW pages; and still there are many strange entries like "/scripts/../../winnt/system32/cmd.exe+/c+dir+\" found in server logs worldwide. Bugs in ".."path handling that were allowed to pass from the site directory to the operating system directories and run the programs residing under these directories were responsible for this. These bugs could be exploited to launch attacks from the sites hosted on the operating system partition. All other situations where relevant partition-related security recommendations were observed i.e. that used separate partitions for the operating system and WWW pages and with the "Default Web Site" disabled were immune to attacks despite the same IIS holes, because a potential attacker could not redirect his request between various disks. Due to a hard time learning slowly from our own mistakes - this costly experience can be avoided by following the said recommendation, (in addition to disabling the default web site, removing unnecessary ISAPI services and setting restrictive file access policies) that is one of the key IIS related security issues. It is an obvious choice, and is included as one of the options when you set up each IIS directory. Any directory you want to protect must be on a NTFS partition - for example E:\WebFiles and subdirectories of individual domains, for example E:\WebFiles\W3SVC2. Make sure you set out appropriate file access permissions: right click on the disk with your domain content and select the "Security" tab. Be aware, that IIS is particularly sensitive to the presence (or absence) of group "Everyone". Remove this hacker invitation from your server, then click "Add " and enable access for Administrators, SYSTEM and Authenticated Users. Then, still on the "Security" tab associated with Administrators and SYSTEM activate maximum permissions with "Full Control", whilst for Authenticated Users, uncheck all, leaving only "List Folder Contents". Confirm your disk security settings by pressing OK. Then mouse select the WebFiles directory, again open the "Properties" window with right mouse click and on the "Security" tab give the Authenticated Users permissions under "Read & Execute" (and also "Read" by default). It is suggested that such an entire set of file access permissions, simplified but conceptually sufficient, is as follows:

For Administrators: Full Control, For Authenticated Users: List Folder Contents, For SYSTEM: Full Control, For Authenticated Users: Read & Execute. Now, with such an "over-hardened" dedicated partition you have a certain margin for loosening restrictions on any other directory, that from time to time may share the disk with WWW sites content. If the log directory is placed on the same partition, you should add the users appropriate read access:

The log directory - Users: Read After setting the directory for all sites, you should set a subdirectory for your new site. Let's name it W3SVC2 - because it is a directory designed for the second site (W3SVC services). The same naming convention is used by the IIS service to name subdirectories containing the web site logs - of course, you may not use it if you don't wish to, but this solution can facilitate log interpreting when more web sites exist. The next thing to do is associated with the well-known "Internet Services Manager" program: run it and halt the default web site selecting the "Stop" option in the popup menu - if this has not been carried out before. Upon completion of these preparatory activities, create a new IIS web site. Right mouse click on the server name and from the popup menu, select New, and then select "Web Site" from the respective submenu. The "Web Site Creation Wizard" window will appear. Click "Next >" on the Welcome screen, then place a short description of your site (it may resemble the WWW address)

(Fig. 9 A short description of your site).

On the next screen, specify the IP address of your website (among those configured at the server - alternatively, you can use any of those available). Then the TCP port (it is recommended to use the 80 port only - using non-standard ports does not enhance security but rather makes more difficult to use web services) and, if you wish, the Web address of your site. This last box is to be filled in if you wish to have multiple sites running on a single IP address, differentiated only by their DNS names.

(Fig. 10 [...] Your Web site address).

Once again click "Next >" and locate your "elaborated" Home Directory - in this example E:\WebFiles\W3SVC2

(Fig. 11 [...] location of files).

Leave the "Allow anonymous access to this Web site" enabled and go to the last web site configuration screen to complete settings for the new web site. Here, leave the "Read" and "Run scripts" boxes enabled as they are. The first is designed to allow reading of static web site files- that is HTML, graphics, style spreadsheets, presentations, that is the files that are sent to Web users with no additional server operation required. Dynamic web pages (that is the scripts activated by ISAPI applications already set up under "Application Configuration") use the settings established in "Run scripts" - if using ASP pages is required, make sure that this box remains checked. Answering the question "Do I really need the "Execute" enabled? Is your next step. This option allows running of programs via the IIS server interface (including EXE files and DLLs, also called ISAPI applications) located in the web site - it is very likely to be exploited by enemies, because these powerful programs, if buggy, may be exploited by a hacker. Another threat but even more concerning is associated with the "Write" setting - all publicly available web sites should not be write-accessible and in this example this requirement has been fulfilled by appropriate file access restrictions settings. Enabling the Browse functionality will provide users with access to your web site as to a common FTP server. You can also enable it, if both names and contents of your files can be publicized (for example, if it is required to have an anonymous file server accessed via HTTP). Of course, you can apply such a setting for a chosen site subdirectory not to worsen aesthetic quality of your Home Page.

(Fig. 12 [...])

Finally, go to set up permissions for Internet users. After clicking on the "Next >" button, press "Finish" on the final screen - you will see the web site launched in the IIS server environment. Right click on it and select Properties tab followed by the "Home Directory" tab. The same tab is available at the settings of any web site subdirectory, so you will be able to individually set up access permissions in respect to specific directories depending on their content. The following options are seen while creating the web site:

"Script source access" allows access to dynamic pages source code via HTTP; it is better not to use this option. "Read" allows reading of web site files. If the web site or a subdirectory contain solely dynamic page scripts, you may disable this option; "Write" allows writing of files via HTTP. If your server is accessible on the Web, uncheck this option; "Directory browsing" enables a user to navigate through your WWW server directory structure (names of all files). It can be activated from a subdirectory performing the role of an anonymous file server. If you decide to enable this option, you will be likely to need to uncheck the "Enable Default Document" option on the "Documents" tab; Options "Log visits" and "Index this resource" - the first one should always be enabled, the second one not, unless the file indexing service has been installed on your server; "Execute Permissions"- when enabled, it is an equivalent to the "Run scripts" and "Execute" options together, being visible on the final screen while creating web sites. "None" corresponds to non-selecting any of the said options. "Scripts only," means the same as "Run scripts" enabled, whilst "Scripts and Executables" - corresponds to both options enabled. For directories containing static files only, (for example a directory with graphics or a file server) select "None", whilst for typical directories with ASP pages set "Scripts only"; May I suggest that you do not use the third alternative if possible "Application Protection" box - you can select a process that will be responsible for running ASP sites - preferably Medium or High to be checked. Do not enable "Low (IIS Process)", because you will be at heavy risk of possible running dynamic WWW under SYSTEM user privileges! Setting to "Medium" will place your ASP in a "pooled application" process. Selecting "High" will allow you to run an ASP "on its own" thereby enhancing security by separating web sites. Additionally; "Configuration" button allows one to modify ASP settings. If you have selected a high level of application separation (option "High" as described above), you will have access to an additional tab named "Process Options" in the "Application Configuration". This window has been already described when describing the server global configuration procedures. "Remove" (or "Create") - you can use it to create/delete ASP applications on the web site or its subdirectories. My advice is to not delete the application belonging to the web site! "Unload" button allows one to momentarily reduce server burden from ASP pages by removing ASP application from the memory The final setup component is associated with the location of web site files (it is provided in the upper portion of the window) - you can change the location of the Home Page directory or activate redirecting to another web site. Do not use the "A share located on another computer" option - this may imply a heavy overhead to the file server service and "unexplainable" lowering of your server performance. [12] [13] [14] [15] The above settings are documented in the IIS popup help facility (use Shift-F1 while previewing setup windows) and also in the Microsoft Knowledge Base [11] [16]. Moreover, the TechNet Whitepaper available at the Microsoft Web site may be helpful [17] [18].

Having completed the preview of the Home Page settings, go to enhance security parameters on the "Directory Security" tab - click on the upper button marked "Edit", then in the "Authentication Methods" window only leave enabled the "Anonymous access" option. You will need to remove the "Integrated Windows authentication" option that is unfortunately activated by default (you don't want to risk successful brute force attacks, do you?)

(Fig. 13 the final patch).

The same applies for other IIS server services - if you have installed the FTP service, enable the anonymous FTP user. In the "Internet Services Manager" application, click on "Default FTP Site" and select Properties from the popup menu. In the "Default FTP Site Properties" go to the "Security Accounts" tab and check the "Allow only anonymous connections" option. In this manner you will cause the FTP to be prevented from hacking away at usernames and passwords. If you have installed the SMTP service, also ensure that you disable this opportunity - click on "Default SMTP Virtual Server", and select Properties from the popup menu. In the "Default SMTP Virtual Server Properties" select the "Access" tab and click on "Authentication". You will see the user authentication access mode window - delete all options except for the highest one ("Anonymous access"). Of course, you can set up your services so that they will be accessible to trusted users of your network (offering them extra services, for example, accessing confidential files), but this is associated with some additional operations to enhance security of passwords involved.

What about the web sites?If you want to see your new site in the web browser, you have to add some files to it, at least a notepad-created default.html. You may manually copy the files from a CD-R, e-mail or a diskette, sent you by the Webmaster. This is an often-used solution allowing for documentation of the changes effected on the Web site. It is however possible that you would have to allow the Webmaster to save the files directly to the web site. Firstly you have to create an account for him. If the WWW server belongs to a Windows NT or an Active Directory domain, you may use a domain account. You should take note of the fact that the Ethernet card receiving HTTP tasks from the Internet must not be connected to the internal network - they have to be separate network interfaces. Then, you modify the authorizations in the file system, attributing the Webmaster the right of writing and modifying the files of the chosen web site (in our case of the E:/WebFiles/W3SVC2 directory). If you have a local area network and a WWW server belonging to the domain, you may define the access as a simple network share on the directory that contains the Web site's files (E:/Webfiles). Otherwise, you may define a new virtual FTP site (choose New -> FTP Site in the IIS server's popup menu). Your FTP 'site' has to be accessible from a trusted network only! To achieve this objective you should use the other Ethernet card installed in the server or the firmware VPN (or an IPsec tunnel) - it is important that the card's IP is not at all accessible from the Internet. While setting up a virtual FTP server you should choose this IP address. E:/WebFiles will be the home directory of the FTP 'site'. You should authorize the Webmaster to write in the directory, too, with the use of the 'Write' option on the last screen of the FTP site creation process. Additionally, the FTP server's setup should block any access coming from IP addresses not belonging to the VPN and/or the local area network. This is an extra means of security, which could save you from some consequences of the mistakes made in the process of connecting the server to the network. A more important way of securing yourself is a trusted network interface, accessible from the local area and/or VPN network, but inaccessible from the Internet. Its trust should not be based on the computer's configuration but on the topology and means of security of the network it is connected to. This is however a topic for another article. And now you can finally connect your new WWW server to the Internet!

Changes to Metabase Properties in IIS 6.0 (IIS 6.0)

2006-02-15T08:08:00.000-08:00

Appendix B: Changes to Metabase Properties in IIS 6.0 (IIS 6.0)

There are IIS 5.0 metabase properties that are no longer supported in IIS 6.0. When upgrading or migrating from an earlier version of IIS, these properties are still in the metabase, but IIS 6.0 ignores the settings. On a new installation of IIS 6.0, these properties have been removed from the metabase, and they are not available even when IIS 6.0 is running in IIS 5.0 isolation mode.

There is one IIS 5.0 metabase property — CPUResetInterval — that still exists in the IIS 6.0 metabase, but it behaves differently in IIS 6.0.

Table 1.1 lists metabase properties that have changed in IIS 6.0. If your Web sites, applications, or setup programs reference any of these IIS metabase properties, follow the recommendations described in the table to accommodate these changes and ensure compatibility with IIS 6.0.

Table 1.1 IIS Metabase Properties That Have Changed Since IIS 5.0
IIS Metabase Properties Recommendation
• AspThreadGateEnabled

• AspThreadGateLoadHigh

• AspThreadGateLoadLow

• AspThreadGateSleepMax

• AspThreadGateTimeSlice

In IIS 5.0, these metabase properties are provided for the configuration of performance features.

In IIS 6.0, these performance features are provided by other means. As a result, IIS 6.0 no longer uses these metabase properties.

Remove any references to these metabase properties from Web sites, applications, or setup programs.

For more information about improving performance in IIS 6.0, see Web Server Scalability.

• CPUAppEnabled

• CPUCGIEnabled

• CPUCGILimit

• CPUEnableActiveProcs

• CPUEnableAllProcLogging

• CPUEnableAppLogging

• CPUEnableCGILogging

• CPUEnableEvent

• CPUEnableKernelTime

• CPUEnablePageFaults

• CPUEnableProcType

• CPUEnableTerminatedProcs

• CPUEnableTotalProcs

• CPUEnableUserTime

• CPULimitLogEvent

• CPULimitPause

• CPULimitPriority

• CPULimitProcStop

• CPULimitsEnabled

• CPULoggingInterval

• CPULoggingMask

• CPULoggingOptions

In IIS 5.0, these metabase properties are provided for the configuration of processor (CPU) management features.

In IIS 6.0, processor management (CPU throttling) is provided by other means. As a result, IIS 6.0 no longer uses these metabase properties.

Remove any references to these IIS metabase properties from Web sites, applications, or setup programs.

The following metabase properties reference and implement CPU throttling in IIS 6.0:

• CPULimit

• CPUResetInterval

• CPUAction

For more information about CPU throttling in IIS 6.0, see the CPULimit Metabase Property, CPUResetInterval Metabase Property, and CPUAction Metabase Property metabase properties.

CPUResetInterval
In IIS 5.0, this property enables the monitoring of processor utilization at the Web site level. IIS 5.0 was unable to monitor individual processes for a Web site, such as multiple processes in an ASP.NET Web garden.

In IIS 6.0, this property enables the monitoring of processor utilization at the worker process level. You cannot monitor the processor utilization for individual Web sites unless there is only one Web site in the application pool.

For more information about how to configure this value for worker processes in an application pool, see the CPUResetInterval Metabase Property metabase property.

DisableSocketPooling
In IIS 4.0 and IIS 5.0, Windows Sockets (WinSock) listens for HTTP requests that use Transmission Control Protocol (TCP). WinSock uses the concept of sockets to provide TCP connectivity. As a result, IIS 4.0 and IIS 5.0 are bound to the scalability constraints of using sockets through WinSock. In IIS 5.0, socket pooling addresses these scalability problems, in cases where a large number of Web sites were configured with individual IP addresses.

In IIS 5.0, socket pooling allows for socket resources to be shared between multiple Web sites and thus provides significant improvements — up to two to three times the scaling capacity of earlier versions of IIS.

In IIS 6.0, HTTP.sys is responsible for listening for HTTP requests and provides similar functionality to the DisableSocketPooling metabase property.

To configure HTTP.sys, use Httpcfg.exe.

Note

On new installations of Windows Server 2003 and IIS 6.0, the DisableSocketPooling metabase property still exists; however, IIS 6.0 ignores the property.ReplaceThisText

HcMimeType
In IIS 5.0, this metabase property indicates which Multipurpose Internet Mail Extensions (MIME) types are supported by the compression scheme.

IIS 6.0, HTTP compression is performed in a different way, and this metabase property is no longer used.

Remove any references to this metabase property from Web sites, applications, or setup programs.

PutReadSize
In IIS 5.0, this metabase property is provided to support the Web Distributed Authoring and Versioning (WebDAV) component, but is untested and unsupported.

In IIS 6.0, this functionality is integrated with the WebDAV component. As a result, IIS 6.0 no longer uses this metabase property.

Remove any references to this metabase property from Web sites, applications, or setup programs.

For more information about WebDAV in IIS 6.0, see About WebDAV.

UNCAuthenticationPassthrough
In IIS 5.0, this metabase property enables pass-through user authentication for Universal Naming Convention (UNC) virtual root access, which is for authentication schemes that support delegation.

In IIS 6.0, pass-through authentication occurs automatically when the UNCUserName and UNCPassword metabase properties are not specified. As a result, IIS 6.0 no longer uses this metabase property.

Remove any references to this metabase property from Web sites, applications, or setup programs.

For more information, see the UNCUserName Metabase Property and UNCPassword Metabase Property metabase properties.

IIS and Built-in Accounts (IIS 6.0)

2006-02-09T06:27:00.000-08:00

IIS and Built-in Accounts (IIS 6.0)

IIS uses a number of built-in Windows accounts, as well as accounts that are specific to IIS. For security reasons, you should be aware of the different accounts and their default user privileges. It can be a security risk to change the identity of a worker process so that it runs as an account with a high level of access, such as the LocalSystem user account.

LocalSystem
The built-in LocalSystem user account has a high level of access privileges; it is part of the Administrators group. If a worker process identity runs as the LocalSystem user account, that worker process has full access to the entire system. When IIS 6.0 is running in IIS 5.0 isolation mode, this is the default user account for worker process identities. LocalSystem has one default user right, Full access.

Top of page
Network Service
The built-in Network Service user account has fewer access privileges on the system than the LocalSystem user account, but the Network Service user account is still able to interact throughout the network with the credentials of the computer account. For IIS 6.0, it is recommended that the worker process identity that is defined for application pools run as the Network Service user account, which is the default setting. The following table shows the default user privileges for the Network Service account, along with how each privilege is derived.

Privilege Source
Replace a process-level token (SeAssignPrimaryTokenPrivilege)
Explicit assignment

Adjust memory quotas for a process (SeIncreaseQuotaPrivilege)
Explicit assignment

Generate security audits (SeAuditPrivilege)
Explicit assignment

Bypass traverse checking (SeChangeNotifyPrivilege)
Through membership in the Everyone group

• Access this computer from the network (SeNetworkLogonRight)

Through membership in the Everyone group

• Log on as a batch job (SeBatchLogonRight)

Through membership in the IIS_WPG group

• Log on as a service (SeInteractiveLogonRight)

Explicit assignment

• Impersonate a client after authentication

Through membership in the IIS_WPG group

Top of page
Local Service
The built-in Local Service user account has fewer access privileges on the computer than the Network Service user account, and those user privileges are limited to the local computer. Use the Local Service user account if the worker process does not require access outside the server on which it is running. The following table shows the default user privileges for the Local Service account, along with how each privilege is derived.

Privilege Source
Replace a process-level token (SeAssignPrimaryTokenPrivilege)
Explicit assignment

Adjust memory quotas for a process (SeIncreaseQuotaPrivilege)
Explicit assignment

Generate security audits (SeAuditPrivilege)
Explicit assignment

Bypass traverse checking (SeChangeNotifyPrivilege)
Through membership in the Everyone group

• Access this computer from the network (SeNetworkLogonRight)

Through membership in the Everyone group

• Log on as a batch job (SeBatchLogonRight)

Explicit assignment

Top of page
IIS_WPG
The IIS IIS_WPG group account has the minimum permissions and user privileges that are necessary to start and run a worker process on a Web server. Application pool identities must be members of this group so the application pool can register with Http.sys. The following table shows the default user privileges for the IIS_WPG account, along with how each privilege is derived.

Privilege Source
Access this computer from the network (SeNetworkLogonRight)
Through membership in the Everyone group

Bypass traverse checking (SeChangeNotifyPrivilege)
Through membership in the Everyone group

Impersonate a client after authentication (SeImpersonatePrivilege)
Explicit assignment

• Log on as a batch job (SeBatchLogonRight)

Explicit assignment

Top of page
IUSR_ComputerName
The IIS IUSR_ComputerName user account is for anonymous access to IIS. By default, when a user accesses a Web site that uses Anonymous authentication, that user is mapped to the IUSR_ComputerName account. The following table shows the default user privileges for the IUSR_ComputerName account, along with how each privilege is derived.

Privilege Source
Access this computer from the network (SeNetworkLogonRight)
Explicit assignment

• Allow log on locally (SeInteractiveLogonRight)

Explicit assignment

Bypass traverse checking (SeChangeNotifyPrivilege)
Through membership in the Everyone group

• Log on as a batch job (SeBatchLogonRight)

Explicit assignment

Top of page
IWAM_ComputerName
The IIS IWAM_ComputerName user account is for starting out-of-process applications in IIS 5.0 isolation mode. The following table shows the default user privileges for the IWAM_ComputerName account, along with how each privilege is derived.

Privilege Source
Access this computer from the network (SeNetworkLogonRight)
Explicit assignment

• Adjust memory quotas for a process (SeIncreaseQuotaPrivilege)

Explicit assignment

Bypass traverse checking (SeChangeNotifyPrivilege)
Through membership in the Everyone group

• Log on as a batch job (SeBatchLogonRight)

Explicit assignment

• Replace a process-level token (SeAssignPrimaryTokenPrivilege)

Explicit assignment

Top of page
ASPNET
The built-in ASPNET user account is for running the ASP.NET worker process in IIS 5.0 isolation mode. The following table shows the default user privileges for the ASPNET account, along with how each privilege is derived.

Privilege Source
Access this computer from the network (SeNetworkLogonRight)
Explicit assignment

• Allow logon locally (SeInteractiveLogonRight)

Through membership in the Users group

Bypass traverse checking (SeChangeNotifyPrivilege)
Through membership in the Users group

• Deny logon locally (SeDenyInteractiveLogonRight)

Explicit assignment

• Log on as a batch job (SeBatchLogonRight)

Explicit assignment

• Log on as a service (SeInteractiveLogonRight)

Explicit assignment

Monitoring Network Activity (IIS 6.0)

2006-02-01T05:27:00.000-08:00

Monitoring Network Activity (IIS 6.0)

The primary functions of IIS 6.0 are to establish connections for clients, to receive and interpret requests, and to deliver files — all as quickly as possible. The pace at which these vital functions are performed depends, in large part, on two factors: the effective bandwidth of the link between the server and the network, and the capacity of this link and the server to support network resources.

The speed of the network interfaces also affects the pace. Some servers have two or more network interfaces, which are frequently called front-end and back-end servers. Front-end servers are client-accessible Web servers that run application server software, such as IIS, to handle traffic coming from the Internet. Front-end servers can add a layer of protection for your back-end servers, which include database servers, file servers, domain controllers, and WINS servers. Different interfaces do not necessarily run at the same speed. This is the case, for example, if a Web server is connected to a database server by means of a private network.

If more bandwidth is needed, the network must be upgraded or — in the case of shared-resource networks such as Ethernet — the network must be broken into subnets.

Bandwidth and Capacity
The main purpose of most Web servers is to manage input/output (I/O): Requests come in, and pages go out. Handling I/O requires a certain amount of bandwidth and other server resources as well. In addition to IIS 6.0, network I/O involves TCP/IP, which is implemented by Windows Server 2003 TCP/IP.

Network capacity is measured, in part, by the number of connections that the server establishes and maintains. Bandwidth is measured in several ways:

• By the rate at which bytes are transferred to and from the server.

• By the rate at which the server sends data packages, which include frames, packets, segments, and datagrams.

• By the rate at which the server sends and receives files.

Effective bandwidth varies widely and depends upon the transmission capacity of the link, the server configuration, and the server workload. The values for a single server also change as it operates in response to demand and to competition for shared network resources.

To ensure that your network has sufficient bandwidth and capacity for the network activity it must support, monitor the following performance indicators:

• Data transmission rates at the different Open Systems Interconnection (OSI) layers, because the components that transmit data reside in different layers.

• File transfer rates, because a Web page often requires multiple file transfers.

• TCP connections, because a plateau in connections established, or increases in connection failures and connection resets, can indicate insufficient bandwidth.

2006-01-31T04:07:00.000-08:00

Iisvdir.vbs: IIS virtual directory script

Product(s):
Windows Server 2003 R2
Windows Server 2003 with SP1
Updated: January 21, 2005

Iisvdir.vbs: IIS virtual directory script
Creates and deletes virtual directories of Web sites on servers running Windows Server 2003 with Internet Information Services (IIS) 6.0.

To view the command syntax, click a command:

• iisvdir /create[#BKMK_create]

• iisvdir /delete[#BKMK_delete]

• iisvdir /query[#BKMK_query]

iisvdir /create
Creates virtual directories on Web sites on servers running Windows Server 2003 with Internet Information Services (IIS) 6.0.

Syntax
iisvdir[.vbs] /create WebSite[/VirtualPath] Name PhysicalPath [/sComputer [/u [Domain\]User [/p Password]]]

Parameters
WebSite Required. Specifies the descriptive name or metabase path of the Web site.
VirtualPath Specifies a path to the virtual directory within the Web site. The virtual path does not include the name of the virtual directory.This parameter places the virtual directory in a subdirectory of the Web site. By default, the virtual directory is added to the root of the Web site. All directories in the virtual path must already exist on the Web site.
Name Required. Specifies a name for the virtual directory. You can select any name.
PhysicalPath Required. Specifies a physical directory for the virtual directory.You must specify a path on the local computer, such as C:\Project\HTML. If the specified path does not exist, then Iisvdir.vbs creates the path.
/sComputer Runs the script on the specified remote computer. Type the computer name or IP address without backslashes. By default, the script runs on the local computer.
/u [Domain\]User Runs the script with the permissions of the specified user account. This account must be a member of the Administrators group on the remote computer. By default, the script runs with the permissions of the current user of the local computer.
/pPassword Specifies the password of the user account specified in the /u parameter. If you omit this parameter, the script prompts you for the password and obscures the text you type.
/? Displays help at the command prompt.

Remarks
• To perform this procedure, you must be a member of the Administrators group on the local computer, or you must have been delegated the appropriate authority. If the computer is joined to a domain, members of the Domain Admins group might be able to perform this procedure. As a security best practice, consider using Run as to perform this procedure.

• The WebSite (or WebSite/VirtualPath), Name, and PhysicalPath parameters must always appear in the specified order on the command line. Otherwise, Iisvdir.vbs does not interpret the information correctly.

• When you use Iisvdir.vbs to create a new virtual directory, you specify only the basic properties needed to create the site and identify its contents. Iisvdir.vbs uses the same default properties that IIS uses when establishing new virtual directories, and it adheres to the same rules for inheriting properties. To configure the more advanced properties of the site, use IIS Manager.

• Virtual directory names (Name) are not required to be unique. However, when a Web site includes a virtual directory and a physical directory with the same name, then the physical directory content cannot be viewed on the Internet.

Examples
The following examples show how to use iisvdir /create in specific situations.

Top of page
To create a virtual directory at the root of the Web site
The following command creates a virtual directory called Insurance at the root of the Finance Web site on the local computer. It associates the directory with content currently stored in the C:\Projects\Insurance\Html directory.

iisvdir /create Finance Insurance c:\projects\insurance\html

In response, Iisvdir.vbs displays the following message, which indicates that the command was successful, and it also displays the basic properties of the new virtual directory:

Connecting to server ...Done.
Virtual Path = Finance/Insurance
ROOT = c:\projects\insurance\html
Metabase Path = W3SVC/1509060625/ROOT/Insurance

The WebSite, Name, and PhysicalPath parameters must appear in the specified order in the command. The following command is the same as the previous command except that the parameters are out of order:

iisvdir /create c:\projects\insurance\html Finance Insurance

This command fails and, having misinterpreted the parameters, Iisvdir.vbs reports that it cannot find a Web site called "c:."

To create a virtual directory in a Web site path
The following command creates a virtual directory called Updates on the Finance Web site of a remote server, Svr01. It uses the /s command to identify the server computer, and the /u and /p commands to run Iisvdir.vbs with the permissions of the user's Administrator account.

The command creates the new virtual directory as a subdirectory of the Finance/Insurance directory. The command uses the metabase path of the Finance Web site, W3SVC/1509060625, to identify the Web site. It indicates the virtual path, Finance/Insurance, by appending it to the Web site name.

Finally, the command associates the Updates directory with content stored in C:\Newstuff\Web on the remote computer.

iisvdir /createW3SVC/1509060625/InsuranceUpdatesC:\Newstuff\Web/s svr01/u Admin01/p p@SSw#rD2

In response, Iisvdir.vbs displays the following message, which indicates that the command was successful, and it also displays the basic properties of the new virtual directory:

Connecting to server ... Done.
Virtual Path = Finance/Insurance/Updates
ROOT = C:\Newstuff\Web
Metabase Path = W3SVC/1509060625/ROOT/Insurance/Updates

In this example, the Finance Web site and its Insurance subdirectory existed on the Svr01 IIS server before the command was issued. If the Web site or the subdirectory did not exist, the command would have failed.

Also, the Insurance subdirectory is a virtual directory. You can use Iisvdir.vbs to create virtual paths within actual or virtual directories.

To create a virtual directory to hide a physical directory
This example uses an artifact of virtual directories to hide the contents of a physical directory so that it cannot be seen on the Internet or an intranet. The command creates a virtual directory with the same name as a physical directory in the same virtual path of a Web site. As a result, Web users cannot see the contents of the physical directory.

Although this method does not secure or protect the physical directory, it does provide a measure of privacy.

The following command creates a virtual directory named Personnel at the root of the Finance Web Site. The virtual directory is associated with a physical directory, D:\IIStest\Personnel, that contains public information about the Finance department team.

iisvdir /create Finance Personnel D:\IIStest\Personnel

In response, Iisvdir.vbs displays the following message, which indicates that the command was successful, and it also displays the basic properties of the new virtual directory:

Connecting to server ... Done.
Virtual Path = Finance/Personnel
ROOT = D:\IIStest\Personnel
Metabase Path = W3SVC/1509060625/ROOT/Personnel

As a result of this command, the site has a physical directory and a virtual directory named Personnel. Users who access the Finance Web site see the contents of the Personnel virtual directory. They do not see the contents of the Personnel physical directory.

iisvdir /delete
Deletes virtual directories from the Web sites on servers running Windows Server 2003 with Internet Information Services (IIS) 6.0.

Syntax
iisvdir[.vbs] /delete Website[/VirtualPath]/Name[/s Computer [/u [Domain\]User [/p Password]]]

Parameters
WebSite Required. Specifies the descriptive name or metabase path of the Web site.
VirtualPath Specifies the path to the virtual directory. This parameter is required when the virtual directory is not located at the root of the Web site.
Name Required. Specifies the name of the virtual directory.
/sComputer Runs the script on the specified remote computer. Type the computer name or IP address without backslashes. By default, the script runs on the local computer.
/u [Domain\]User Runs the script with the permissions of the specified user account. This account must be a member of the Administrators group on the remote computer. By default, the script runs with the permissions of the current user of the local computer.
/pPassword Specifies the password of the user account specified in the /u parameter. If you omit this parameter, the script prompts you for the password and obscures the text you type.
/? Displays help at the command prompt.

Remarks
• To perform this procedure, you must be a member of the Administrators group on the local computer, or you must have been delegated the appropriate authority. If the computer is joined to a domain, members of the Domain Admins group might be able to perform this procedure. As a security best practice, consider using Run as to perform this procedure.

• Do not use Iisvdir.vbs to delete a Web site. If you do, the Web site is still listed, but it is partially removed and does not operate properly. To delete a Web site, or to correct the improper removal of an Web site by Iisvdir.vbs, use Iisweb.vbs: IIS Web site management script[/WindowsServer/en/Library/ba0e7001-3c41-40b9-b320-b6b6481c97251033.mspx].

Examples
The following examples show how to use iisvdir /delete in specific situations.

Top of page
To delete a virtual directory
The following command deletes the Insurance virtual directory from the Finance Web site on the local server. As a result, the Insurance directory and all actual and virtual subdirectories of the Insurance directory are deleted.

iisvdir /deleteFinance/Insurance

In response, Iisvdir.vbs displays the following message, indicating that the command was successful. Note that Iisvdir.vbs does not ask for confirmation before deleting the directory or its subdirectories.

Web directory Finance/ROOT/Insurance has been DELETED.

iisvdir /query
Displays the virtual directories of Web sites on servers running Windows Server 2003 with Internet Information Services (IIS) 6.0.

Syntax
iisvdir /queryWebSite[/VirtualPath] [/s Computer [/u [Domain\]User [/p Password]]]

Parameters
WebSite Required. Specifies the descriptive name or metabase path of the Web site.
VirtualPath Specifies the path to a directory within the Web site. The query lists all virtual directories under the specified directory. Without this parameter, Iisvdir.vbs lists the virtual directories at the root of the Web site.
/sComputer Runs the script on the specified remote computer. Type the computer name or IP address without backslashes. By default, the script runs on the local computer.
/u [Domain\]User Runs the script with the permissions of the specified user account. This account must be a member of the Administrators group on the remote computer. By default, the script runs with the permissions of the current user of the local computer.
/pPassword Specifies the password of the user account specified in the /u parameter. If you omit this parameter, the script prompts you for the password and obscures the text you type.
/? Displays help at the command prompt.

Remarks
• To perform this procedure, you must be a member of the Administrators group on the local computer, or you must have been delegated the appropriate authority. If the computer is joined to a domain, members of the Domain Admins group might be able to perform this procedure. As a security best practice, consider using Run as to perform this procedure.

• The query operation displays only virtual directories. Physical directories in the Web site or path do not appear.

• The query operation displays only virtual directories at the root of the Web site or in the specified subdirectory. It does not search recursively.

Examples
The following examples show how to use iisvdir /query in specific situations.

Top of page
To display the virtual directories of a Web site
The following command displays the virtual directories at the root of the Finance Web site:

iisvdir /query Finance

In response, Iisvdir.vbs displays the two virtual directories at the root of Finance. Note that these directories appear at the Finance root even though their physical locations are unrelated.

This display does not include virtual directories that are subdirectories of the site. The procedure for finding subdirectories is demonstrated in the example below, "To display virtual subdirectories."

Alias Physical Root
========================
/Personnel D:\Corpdir\FinanceWeb\People
/Insurance C:\Marketing\Insurance\HTMFiles

To display virtual subdirectories
The following command displays the virtual directories that are subdirectories of the Insurance virtual directory on the Finance Web site. The command specifies the Insurance directory by using its virtual path.

iisvdir /query Finance\Insurance

This command reveals the Current subdirectory of the Insurance virtual directory.

Alias Physical Root
=======================
/Current C:\Insurance\Monthly\200204

Remarks
• Iisvdir.vbs performs the same operations that are available from IIS Manager. You can use either tool to view and manage virtual directories.

• The computer issuing the command must be running Windows XP or a Windows Server 2003 operating system. The user must be a member of the Administrators group on any computer that the command affects.

• The computer that the command affects must be a server running Windows Server 2003 with Internet Information Services (IIS) 6.0.

• Iisvdir.vbs displays a "Connecting to server" message while it connects to the IIS service on the specified computer. This message appears whenever you use Iisback.vbs, whether on a local or a remote computer.

• Use quotation marks to enclose path elements that include spaces. Enclose only the element with spaces, not the entire path. For example, type "Default Web Site"/IISAdmin, not "Default Web Site/IISAdmin".

Application Pools in IIS 7.0

2006-01-31T01:14:00.000-08:00

IIS 7.0 Beta: Application Pools in IIS 7.0 (IIS 7.0 Beta 1)

Application pools separate applications by process boundaries to prevent an application from affecting another application on the server. In IIS 7.0, application pools continue to use IIS 6.0 worker process isolation mode. In addition, you can now specify a setting that determines how to process requests that involve managed resources: Integrated mode or ISAPI mode.

Note
In IIS 6.0, worker process isolation mode and IIS 5.0 isolation mode are set at the server level. This makes it impossible to run both isolation modes on the same server. However, in IIS 7.0, Integrated mode and ISAPI mode are set at the application pool level, which enables you to run applications simultaneously in application pools with different process modes on the same server.

Integrated application pool mode
When an application pool is in Integrated mode, you can take advantage of the integrated request-processing architecture of IIS and ASP.NET. When a worker process in an application pool receives a request, the request passes through an ordered list of events. Each event calls the necessary native and managed modules to process portions of the request and to generate the response.

There are several benefits to running application pools in Integrated mode. First the request-processing models of IIS and ASP.NET are integrated into a unified process model. This model eliminates steps that were previously duplicated in IIS and ASP.NET, such as authentication. Additionally, Integrated mode enables the availability of managed features to all content types.

Top of page
ISAPI application pool mode
When an application pool is in ISAPI mode, IIS 7.0 handles requests as in IIS 6.0 worker process isolation mode. ASP.NET requests first go through native processing steps in IIS and are then routed to Aspnet_isapi.dll for processing of managed code in the managed runtime. Finally, the request is routed back through IIS to send the response.

This separation of the IIS and ASP.NET request-processing models results in duplication of some processing steps, such as authentication and authorization. Additionally, managed code features, such as forms authentication, are only available to ASP.NET applications or applications for which you have script mapped all requests to be handled by aspnet_isapi.dll.

Be sure to test your existing applications for compatibility in Integrated mode before upgrading a production environment to IIS 7.0 and assigning applications to application pools in Integrated mode. You should only add an application to an application pool in ISAPI mode if the application fails to work in Integrated mode. For example, your application might rely on an authentication token passed from IIS to the managed runtime, and, due to the new architecture in IIS 7.0, the process breaks your application

How to configure IIS 6.0 URL Authorization

2006-01-22T06:44:00.000-08:00

How to configure IIS 6.0 URL Authorization

SUMMARY
Microsoft Internet Information Services 6.0 works with Authorization Manager in Microsoft Windows Server 2003 to provide IIS 6.0 URL Authorization. IIS 6.0 URL Authorization simplifies the administration of user access to Web objects. In IIS 6.0 URL Authorization, you maintain access control by using metabase attributes that control URL authorization. These metabase attributes are the following:
•
AzEnable
•
AzStoreName
•
AzScopeName
•
AzImpersonate
You can set these metabase attributes by using of a script. Authorization policy for IIS 6.0 URL Authorization is stored in an Authorization Manager policy store either in Active Directory or in an .xml file.To configure IIS 6.0 URL Authorization, you must create your program folder under the Default Web Site folder in IIS Manager and then disable anonymous access to the site. You must then set the wildcard configuration properties to point to the URLAuth.dll file. You must also add URLAuth.dll as a new Web service extension. Next, you must set up an authorization policy store in Authorization Manager, set up the scope for the program, add the IIS worker process to the store's Readers role, and then configure the IIS metabase to use IIS 6.0 URL Authorization for the Web program.

Back to the top
INTRODUCTION
Microsoft Internet Information Server (IIS) 6.0 is included with Microsoft Windows Server 2003. IIS 6.0 works with Authorization Manager to provide IIS 6.0 URL Authorization. As a Web program administrator, you can use IIS 6.0 URL Authorization to control access to URLs based on custom user roles, on LDAP queries, and on BizRules.To authorize user access to Web pages in IIS, you may have to manage many Discretionary Access Control Lists (DACLs) on resources that the Web programs use. Resources for Web programs may include Web page files, database records, registry keys, and more.A task is a collection of low-level operations. An operation is a low-level permission that a resource manager uses to identify security procedures. Frequently, operations are not exposed or meaningful to administrators. For example, an operation may be WriteAttributes or ReadAttributes. The purpose of the task is to determine which low-level operations are required to do some unit of work that is meaningful to administrators. Several operations may be required to perform a meaningful task. To maintain DACLs, you must know which back-end permissions are required on each object to perform meaningful tasks in the Web program. IIS 6.0 URL Authorization simplifies access management by letting you authorize user access to the URLs that make up a Web program. When a client requests a URL, IIS 6.0 URL Authorization validates the user's access based on the user roles. By using IIS 6.0 URL Authorization, you can control all user access to URLs instead of maintaining a DACL on each object. Additionally, the Web program can restrict access to resources and to operations by using the Authorization Manager role-based framework.IIS 6.0 URL Authorization is implemented as an Internet Server API (ISAPI) interceptor DLL that is configured as a wildcard extension for a program, for a virtual directory, or for a URL. When a program, a virtual directory, or a URL is configured to use IIS 6.0 URL Authorization, each request to a URL is routed to the IIS 6.0 URL Authorization ISAPI interceptor. The IIS 6.0 URL Authorization ISAPI interceptor then uses the Authorization Manager runtime to authorize access to the requested URL. For the Authorization Manager runtime to authorize access, the program location, the virtual directory location, or the URL must be associated with an Authorization Manager policy store that contains the authorization policy for the URL that is requested. After the client is authorized to access the URL, the IIS 6.0 URL Authorization ISAPI passes the request to the appropriate handler for the URL. For example, the IIS 6.0 URL Authorization ISAPI passes the request to ASP, to ASP.NET ISAPIs, or to the Static File Handler.You can use IIS 6.0 URL Authorization to control access based on information that is only available at run time. For example, if you have a Web page that only employees in a specific cost center or employees of a specific age can view, you can assign roles to the correct users based on LDAP queries. The LDAP queries verify the cost center attribute or the age attribute on a user object at run time. If employees can access some pages only on specific days of the week or only during a specific time of day, you can create a BizRule that grants access to the URL based on these values. You can create a BizRule on any value that can be asserted at run time, including IIS Server Variables.

Back to the top
Metabase attributes that IIS 6.0 URL Authorization usesIIS 6.0 URL Authorization uses the metabase attributes in the following table to set authorization on a URL, on a virtual directory, or on a program.
Attribute
Authorization
AzEnable
This attribute enables IIS 6.0 URL Authorization for the virtual directory, for the program, or for the URL that corresponds to the entry in the metabase.
AzStoreName
This attribute associates an Authorization Manager store with the virtual directory, the program, or the URL.
AzScopeName
This attribute associates the virtual directory, the program, or the URL with a scope that the AzStoreName attribute refers to in the Authorization Manager policy store in IIS 6.0 URL Authorization. If this attribute specifies either an empty string or no scope at all, the default scope of IIS 6.0 URL Authorization is used.
AzImpersonate
This attribute determines the impersonation behavior for the program. You can use this attribute to configure the Web program to impersonate the client user, the IIS worker process, or the IUSER_* account for the worker process. Each setting significantly changes the environment and the implied design of the Web program. Set the value to 0, to 1, or to 2. These values correspond to the impersonation style.0 The authenticated client is impersonated. Some programs require client impersonation, such as ASP 2.0 programs. Use this value if you want to use IIS 6.0 URL Authorization for programs that expect to run while impersonating the client, such as ASP 2.0 programs.1 The IIS worker process identity is impersonated. Use this value when the program runs as a service account, authorizes each client request itself, and performs requested operations on behalf of the client in the trusted service context.2 The anonymous user account is impersonated. Use this value if you want to use IIS 6.0 URL Authorization to authorize client access to the URL while still running the Web program as the anonymous account. This configuration limits all client access through the Web program.

Back to the top
Script to set the attributes on the IIS metabaseThe following script uses ADSI to set the metabase attributes on the IIS metabase entry for a program, for a virtual directory, or for a URL.Note This script assumes that you have already created the IIS virtual directory that corresponds to the program. For additional information about how to create an IIS virtual directory, click the following article number to view the article in the Microsoft Knowledge Base:
816568 (http://www.kbAlertz.com/Feedback.aspx?kbNumber=816568/) How to manage Web sites and Web virtual directories by using command-line scripts in IIS 6.0 ' SetUrlAuth.vbs
' Configuring UrlAuth with a virtual directory
' This script uses ADSI to configure a virtual directory in the IIS 6.0 metabase to use
' IIS 6.0 URL Authorization.
'
' This script assumes that you have already created the IIS virtual directory
' that corresponds to the program.
'
' After you run this script to verify the settings, use the Adsutil tool in
' the following way:
'
' inetpub\adminscripts\adsutil enum w3svc/1/root/MyApp
' (where MyApp is the application name)
' Use the Authorization Manager MMC snap-in to:
' Create an application that is named IIS 6.0 URL Authorization.
' Create an operation that is named AccessURL and that has an operation ID of 1.
' Create a scope that corresponds to the AzScopeName that is specified to this script.
' This scope name is used to manage access to URLs in this virtual directory.
' Make sure that the IIS worker process has read access to the
' AzMan policy store. To do this, right-click the AzMan store, click Options,
' and then click the Security tab.
Set objArgs = WScript.Arguments
If objArgs.count < 4 then
wscript.echo "Usage: SetUrlAuth VDirPath AzScopeName AzStoreName AzEnable [ImpersonationLevel]"
wscript.echo ""
wscript.echo "Example:"
wscript.echo " SetUrlAuth w3svc/1/root/MyApp MyApp msxml://d:\inetpub\wwwroot\AzStore.xml True 1"
wscript.echo ""
wscript.echo "Run with 'cscript' command in cmd.exe to avoid msg boxes"
Else
wscript.echo objargs(0)
'
' Get the interface to the virtual directory object.
'
DIM iis
set iis = GetObject("IIS://localhost" & objArgs(0))
' Set the scope name. This scope will preside over URLs that refer to this virtual directory.
' This scope must exist in the corresponding Authorization Manager store.
'
iis.AzScopeName = objArgs(1)
'
' Specify location of Authorization Manager policy store
'
iis.AzStoreName = objArgs(2)
'
' Enable IIS 6.0 URL Authorization for this virtual directory.
'
iis.AzEnable = objArgs(3)
'
' Set the Impersonation Level property.
'
If objArgs.count > 4 then
iis.AzImpersonationLevel = objArgs(4)
End if
'
' Write the settings to the metabase.
'
iis.SetInfo
End if

Back to the top
The AzImpersonationLevel attributeWhen a client requests a Web page, IIS 6.0 URL Authorization authorizes the client access based on the Authorization Manager authorization policy. The security context that the AzImpersonationLevel attribute configures to retrieve the URL data, such as an .htm file, requires the correct IIS directory security permissions and the correct NTFS file system permissions. IIS 6.0 URL Authorization makes it easier for you to maintain the IIS directory security permissions and the NTFS permissions because IIS 6.0 URL Authorization uses the trusted subsystem model.

Back to the top
The AzStoreName attributeWhen IIS 6.0 URL Authorization is configured, you can identify an Authorization Manager policy store through the AzStoreName attribute in the IIS metabase entry for the program, for the virtual directory, or for the URL. To manage the authorization policy, follow these steps:
1.
On the computer that is running IIS 6.0, click Start, click Run, type Azman.msc, and then click OK.
2.
In the console tree, right-click Authorization Manager, and then click Open Authorization Store.
3.
In the Store Name box, type the path of the authorization store location that the AzStoreName attribute identifies, and then click OK. For more information about how to open an authorization store, see the "Authorization stores and applications" topic in the Authorization Manager Microsoft Management Console (MMC) Help.

Back to the top
The AzScopeName attributeThe IIS 6.0 URL Authorization program manages IIS 6.0 URL authorization for the store that the AzStoreName attribute identifies. The AzScopeName attribute in the metabase entry is an Authorization Manager scope in the IIS 6.0 URL Authorization program. You can use this scope to manage access to the corresponding URL. When you configure a program, a virtual directory, or a URL for IIS 6.0 URL Authorization, you must crate a scope in the authorization policy store. This scope must have the same name as the name that is specified in the corresponding metabase entry's AzScopeName attribute.Authorization policy for IIS 6.0 URL Authorization is stored in an Authorization Manager policy store either in Active Directory or in an .xml file. When you use IIS 6.0 URL Authorization, you can maintain the authorization policy for URLs in the same authorization policy store as the authorization policy of Web programs that use Authorization Manager to control access to program tasks and operations. Therefore, you can manage access to URLs and to Web program resources from the same Authorization Manager MMC or from the same custom user interface. This behavior provides a common point for access control administration of URLs and of programs. Therefore, you can use the same Authorization Manager groups and the same LDAP queries to populate roles for both URL authorization and program authorization.

Back to the top
How to configure IIS 6.0 URL AuthorizationThis section describes how to set up IIS 6.0 URL Authorization for a Web program by using an example URL. The example URL is named WebApp and is installed and configured in IIS as a program in the Systemroot\InetPub\WWWroot\WebApp folder.Note Integrated Windows Authentication is required for URLs that use IIS 6.0 URL Authorization. By default, IIS Web programs and virtual directories turn on Integrated Windows Authentication. For information about how to configure Integrated Windows Authentication, see the "Integrated Windows Authorization" topic in the IIS online Help file.
Create your program folder under the Default Web Site folder, and then disable anonymous access to the site
1.
Click Start, click Run, type %systemroot%\System32\InetSrv\IIS.msc, and then click OK.
2.
In the console tree, double-click Internet Information Services, double-click the name of your computer that is running IIS, double-click Web Sites, double-click Default Web Site, right-click the folder that correspond to your Web program, and then click Properties.
3.
Click the Virtual Directory tab, and then click Create.
4.
Click the Directory Security tab, and then click Edit in the Authentication and Access Control area.
5.
Click to clear the Enable Anonymous Access check box.
6.
Click to select the Integrated Windows Authentication check box, click OK, and then click OK again.
Set the wildcard configuration properties to point to the URLAuth.dll file
1.
In IIS Manager, right-click the folder for the Web program that you created, and then click Properties.
2.
In the Properties dialog box, click the Virtual Directory tab, and then click Configuration.
3.
In the Wildcard application maps (order of implementation) area, click Insert.
4.
In the Add/Edit Application Extension Mapping dialog box, click Browse.
5.
In the Files of type list, click All files (*.*).
6.
Locate the Systemroot\System32\InetSrv folder.
7.
Click URLAuth.dll, and then click Open
8.
Click OK three times.Note You may receive an error message that is similar to the following:
This executable path is already usedIf you receive this error message, the URLAuth.dll file is already configured as a wildcard program extension mapping.
Add the URLAuth.dll file as a new Web service extension
1.
Start IIS Manager.
2.
In the console tree, double-click Internet Information Services, double-click the name of your computer that is running IIS, and then click Web Service Extensions.
3.
In the Task list in the details pane, click Add a new Web service extension.
4.
Click Add, and then click Browse.
5.
Locate Systemroot\System32\InetSrv\, click URLAuth.dll, click Open, and then click OK.
6.
In the Extension Name box, type URL Authorization.
7.
Click to select the Set extension status to Allowed check box, and then click OK.

Back to the top
Set up an authorization policy store in Authorization ManagerIn this example, you put an authorization policy store that is named MyStore.xml in the C folder.
1.
Click Start, click Run, type Azman.msc, and then click OK.
2.
In the console tree, right-click Authorization Manager, and then click Options.
3.
Click Developer mode, and then click OK.
4.
In the console tree, right-click Authorization Manager, and then click New Authorization Store.
5.
Click XML file, and then type C:\MyStore.xml in the Store name box.
6.
In the Description box, you may type information about the new store. This step is optional.
7.
Click OK.
8.
In the console tree, right-click MyStore.xml, and then click New Application.
9.
In the Name box, type IIS 6.0 URL Authorization.
10.
In the Description box, you may type information about this usage of IIS 6.0 URL Authorization. This step is optional.
11.
Click OK.
12.
In the console tree, double-click Authorization Manager, double-click MyStore.xml, double-click IIS 6.0 URL Authorization, and then double-click Definitions.
13.
Right-click Operation Definitions, and then click New Operation Definition.
14.
In the Name box, type AccessURL.
15.
In the Operation number box, type 1, and then click OK.
Set up the scope for the program
1.
In the Authorization Manager console tree, right-click IIS 6.0 URL Authorization, and then click New Scope.
2.
In the Name box, type WebApp, and then click OK.
3.
In the console tree, double-click IIS 6.0 URL Authorization, double-click Definitions, right-click Role Definitions, and then click New Role Definition. Note You can also create this role definition in the WebApp scope.
4.
In the Name box, type Viewer, and then click OK.
5.
In the console tree, double-click Role Definitions.
6.
In the details pane, right-click Viewer, and then click Properties.
7.
Click the Definition tab, click Add, and then click the Operations tab.
8.
Click to select the AccessURL check box, click OK, and then click OK again.
9.
In the console tree, double-click WebApp, right -click Role Assignments, and then click Assign Roles.
10.
Click to select the Viewer check box, and then click OK.
11.
In the details pane, right-click Viewer, and then click Assign Windows Users and Groups.
12.
In the Enter the object names to select (examples) box, type your user name, and then click OK.
Add the IIS worker process to the store's Readers roleBy default, IIS runs in the Network Service account. You can configure an IIS worker process to run in a different account. This example adds Network Service to the Readers role. Note If you use a remote authorization store such as Active Directory or a remote XML file-based store, and you run IIS in the default Network Service context, you must add the Active Directory account of the Web server that is running IIS to the store's Readers role.
1.
Click Start, click Run, type Azman.msc, and then click OK.
2.
In the console tree, right-click Authorization Manager, and then click Open Authorization Store.
3.
Click Browse, click C:\MyStore.xml, click OK, and then click OK again.
4.
In the console tree, right-click the name of the store, and then click Properties.
5.
Click the Security tab, click Reader in the Authorization manager user role list, and then click Add.
6.
In the Enter the object names to select (examples) box, type Network Service, click OK, and then click OK again.
Configure the IIS metabase to use IIS 6.0 URL Authorization for the Web program
1.
Click Start, click Run, type Cmd, and then click OK.
2.
Use the script in the "Script to set the attributes on the IIS metabase" section to create the SetUrlAuth.vbs file. Save the file to the \InetPub\AdminScripts directory. By default, the InetPub directory is in the root of the drive where IIS is installed.
3.
Type the following command, and then press ENTER:
CScript SetUrlAuth.vbs Path of virtual directory AzScopeName value AzStoreName AzEnable value [ImpersonationLevel value]For example, you might type the following:
Cscript SetUrlAuth.vbs W3svc\1\Root\WebApp WebApp msxml://C:\MyStore.xml true 1IIS 6.0 URL Authorization is now configured and running for the specified Web program. Users who are in the Viewer role can locate the pages in the program.Important If you are using an .xml file, you must append msxml:// to the command. If you are using the Active Directory Authorization Manager store, you must append msldap:// to the command.

How to access network files from IIS applications

2006-01-19T02:41:00.000-08:00

How to access network files from IIS applications

SUMMARY
This article provides information about problems with accessing files on a computer other than your Internet Information Server (IIS) server from an Internet Server API (ISAPI) extension, Active Server Pages (ASP) page, or Common Gateway Interface (CGI) application. This article lists some of the issues that are involved and some possible methods to make this work.

Although this article is written primarily in the context of accessing files on network shares, the same concepts apply to named-pipe connections as well. Named pipes are frequently used for SQL Server connections and also for remote procedure call (RPC) and Component Object Model (COM) communications. In particular, if you connect to a SQL Server across the network that is configured to use Microsoft Windows NT Integrated Security, you cannot connect because of the issues that are outlined in this article. RPC and COM may also use other communication mechanisms that have similar network authentication schemes. Therefore, the concepts in this article can apply to a wide variety of network communication mechanisms that may be used from your IIS applications.

Back to the top

Authentication and impersonation types
When IIS services an HTTP request, IIS performs impersonation so that access to resources to handle the request is limited appropriately. The impersonated security context is based on the kind of authentication performed for the request. The five different types of authentication available from IIS 4.0 are: Authentication Type Impersonation Type

Anonymous Access (no authentication) Network
Auto Password Synchronization is
ON (ON=default)

Anonymous Access (no authentication) IIS Clear Text
Auto Password Synchronization is OFF

Basic Authentication IIS Clear Text

NT Challenge/Response Authentication Network

Client SSL Certificate Mapping Interactive

Back to the top

Token types
Whether or not access to network resources is permitted is dependent on the kind of impersonation token under which the request is being processed.
• Network tokens are "NOT" permitted to access network resources. (Network tokens are named so because this kind of token is traditionally created by a server when a user is authenticated across the network. To allow the server to use a network token to act as a network client and access another server is called "delegation" and is considered a possible security hole.)
• Interactive tokens are traditionally used when authenticating a local user on the computer. Interactive tokens are permitted to access resources across the network.
• Batch tokens are designed to provide a security context under which batch jobs run. Batch tokens have network access.
IIS has the concept of a Clear Text logon. Clear Text logon is named so because of the fact that IIS has access to both the username and the password in clear text. You can control whether a Clear Text logon creates a Network token, an Interactive token, or a Batch token by setting the LogonMethod property in the metabase. By default, Clear Text logons receive an Interactive token and have access to network resources. The LogonMethod can be configured at the server, the site, the virtual directory, the directory, or the file level.

Anonymous access impersonates the account configured as the anonymous user for the request. By default, IIS has a single anonymous user account called IUSR_ that is impersonated when handling a non-authenticated request. By default IIS 4.0 has a configurable feature called "Enable Automatic Password Synchronization" that uses a security sub-authority to create the token. Tokens that are created in this manner are network tokens which do "NOT" have access to other computers on the network. If you disable Automatic Password Synchronization, IIS creates the token in the same manner as the Clear Text logon mentioned earlier. Automatic Password Synchronization is only available for accounts that are located on the same computer as IIS. Therefore, if you change your anonymous account to a domain account, you cannot use Automatic Password Synchronization and you receive a Clear Text logon. The exception is if you install IIS on your Primary Domain Controller. In this case, the domain accounts are on the local computer. The anonymous account and the Automatic Password Synchronization option can be configured at the server, the site, the virtual directory, the directory, or the file level.

You must have the correct type of token as the first step in accessing a resource on the network. You must also impersonate an account that has access to the resource across the network. By default, the IUSR_ account that IIS creates for anonymous requests exists only on the local computer. Even if you disable Automatic Password Synchronization so that you can get an Interactive token that can access network resources, the IUSR_ account typically does not have access to most network resources because this is an account that is unrecognized on other computers. If you want to access network resources with anonymous requests, you must replace the default account with an account in a domain on your network that can be recognized by all computers. If you install IIS on a Domain Controller, the IUSR_ account is a domain account and must be recognized by other computers on the network without taking additional action.

Back to the top

Problem avoidance
Following are ways to avoid problems when you access network resources from your IIS application:• Keep files on the local computer.
• Some network communication methods do not require a security check. An example is using Windows sockets.
• You can provide direct access to the network resources of the computer by configuring a virtual directory to be:
"A share located on another computer."
All access to the computer that shares the network resources is performed in the context of the person specified under the Connect As.. dialog box. This occurs no matter what kind of authentication is configured for the virtual directory. By using this option, all files on the network share are available from browsers that access the IIS computer.
• Use basic authentication or anonymous authentication without Automatic Password Synchronization.

By default, the impersonation that Internet Information Server does for basic authentication provides a token that can access network resources (unlike Windows NT Challenge/Response, which provides a token that cannot access network resources). For anonymous authentication, the token can only access a network resource if Automatic Password Synchronization is disabled. By default, Automatic Password Synchronization is enabled when Internet Information Server is first installed. In such a default configuration, the anonymous user token cannot access network resources. For more information about Automatic Password Synchronization in IIS, click the following article numbers to view the articles in the Microsoft Knowledge Base:
190005 (http://support.microsoft.com/kb/190005/) A site set up for anonymous access prompts users for password
259353 (http://support.microsoft.com/kb/259353/) Must enter password manually after you toggle password sync
• Configure the anonymous account as a domain account.

This permits anonymous requests from potential access to resources across the network. To prevent all anonymous requests from having network access, you must only make the anonymous account a domain account on the virtual directories that specifically require access.
• Configure the anonymous account with the same username and password on the computer that is sharing the network resources and then disable Automatic Password Synchronization.

If you do this you must make sure that the passwords match exactly. This approach must only be used when the "Configure the anonymous account as a domain account" mentioned earlier is not an option for some reason.
• NullSessionShares and NullSessionPipes can be used to allow access to a specific network share or to a named pipe when your request is handled with a network token.

If you have a network token and you try to establish a connection to a network resource, the operating system tries to establish a connection as a non-authenticated connection (referred to as a "NULL Session"). This registry setting must be made on the computer that is sharing the network resource, not on the IIS computer. If you try to access a NullSessionShare or NullSessionPipe with a non-network token, typical Microsoft Windows authentication is used and access to the resource is based on the account user rights of the impersonated user.
• You can potentially perform your own impersonation to create a Thread token that does have network access.

The LogonUser function and the ImpersonateLoggedOnUser function can be used to impersonate a different account. This requires that you have the Clear Text username and password of another account available to your code. LogonUser also requires that the account that calls LogonUser has the "Act as part of the operating system" privilege in User Manager. By default, most users who IIS impersonates while it handles an HTTP request do not have this user right. However, for "In Process Applications" there are a number of ways to cause your current security context to change to the LocalSystem account, which does have the "Act as part of the operating system" administrative credentials. For ISAPI DLLs that run in-process, the best way to change the security context that IIS has created to the LocalSystem account is to call the RevertToSelf function. If you are running your IIS application "Out of Process", this mechanism does not work by default because the process is running under the IWAM_ account and not the Local System account. By default, the IWAM_ does "NOT" have the "Act as part of the operating system" administrative credentials.
• Add the component that is called from the ASP page to a Microsoft Transaction Server (MTS) Server package or COM+ Server application, and then specify a specific user as the identity of the package.

Note The component runs in a separate .exe file that is outside of IIS.
• With basic/clear text authentication, we recommend that you encrypt the data by using SSL because it is extremely easy to obtain credentials from a network trace. For more information about how to install SSL, click the following article number to view the article in the Microsoft Knowledge Base:
228991 (http://support.microsoft.com/kb/228991/) How to create and install an SSL certificate in Internet Information Server 4.0
Note Do not forget that you can prevent network access for anonymous requests where password synchronization is disabled and requests are authenticated by using basic authentication (Clear Text logons) if you set the LogonMethod metabase property to "2" (indicating that a network logon is used to create the impersonation token). With this setting, the only way for requests to avoid the network token limitation is to connect to NullSessionShares or NullSessionPipes.

Do not use drive letters mapped to network shares. Not only are there only 26 potential driver letters to select from, but if you try to use a drive letter that is mapped in a different security context, problems can occur. Instead, you must always use Universal Naming Convention (UNC) names to access resources. The format must look similar to the following:
\\MyServer\filesharename\directoryname\filename
For more information about using UNC, click the following article number to view the article in the Microsoft Knowledge Base:
280383 (http://support.microsoft.com/kb/280383/) IIS Security recommendations when you use a UNC share
The information in this article pertains only to Internet Information Server 4.0. In Internet Information Server 5.0 (that is included with Windows 2000), there are significant changes to new authentication types and capabilities. Although most of the concepts in this article still apply to IIS 5.0, the details on the kinds of impersonation tokens that are generated with certain authentication schemes in this article apply strictly to IIS 4.0.

319067 (http://support.microsoft.com/kb/319067/) How to run applications not in the context of the system account
If you cannot determine what kind of logon is occurring on your IIS server to handle requests, you can turn on auditing for Logons and Logoffs. Follow these steps: 1. Click Start, click Settings, click Control Panel, click Administrative Tools, and then click Local Security Policy.
2. After you open Local Security Policy, in the left Tree View pane, click Security Settings, click Local Policies, and then click Audit Policy.
3. Double-click Audit Logon Event and then click Success and Failure. Event Log entries are added under the Security log. You can determine the kind of logon by looking at the event details under the Logon Type:

2=Interactive
3=Network
4=Batch
5=Service

IIS 7.0 Beta: Security Modules (IIS 7.0 Beta 1)

2006-01-16T03:29:00.000-08:00

Several modules in IIS 7.0 perform tasks related to security in the request-processing pipeline. In addition, there are separate modules for each of the authentication schemes, which enable you to select modules for the types of authentication you want on your server. There are also modules that perform URL authorization, and a module that performs various security checks.

The security modules in the following table are loaded by default in IIS 7.0, but you can remove them or replace them with custom modules, depending on your needs.

Module Name Description Resource
AnonymousAuthModule
Performs Anonymous authentication when no other authentication method succeeds.
Inetsrv\Authanon.dll

BasicAuthModule
Performs Basic authentication.
Inetsrv\Authbas.dll

CertificateMappingAuthenticationModule
Performs Certificate Mapping authentication using Active Directory.
Inetsrv\Authcert.dll

DigestAuthModule
Performs Digest authentication.
Inetsrv\Authmd5.dll

IISCertificateMappingAuthenticationModule
Performs Certificate Mapping authentication using IIS certificate configuration.
Inetsrv\Authmap.dll

RequestFilteringModule
Performs URLScan tasks such as configuring allowed verbs and file extensions, setting limits, and scanning for bad character sequences.
Inetsrv\Modrqflt.dll

UrlAuthorizationModule
Performs URL authorization.
Inetsrv\Urlauthz.dll

WindowsAuthModule
Performs NTLM integrated authentication.
Inetsrv\Authsspi.dll

Apache Configuration GUI for Windows

2006-01-12T07:16:00.000-08:00

ApacheConf is an Apache Configuration GUI for Windows that will help you to tune the main Apache configuration httpd.conf file. ApacheConf presents all the information in the httpd.conf file in a structured view. All of the server's directives are grouped by category (Global parameters, Main server's parameters, Directories, Virtual hosts, etc) and all these groups are represented as a tree. In this way, you can see the entire structure of the server at a glance and you can easily manage all of the server's directives, as well as the directories and virtual hosts.
You save time because you use a complete Apache Configuration GUI for Windows!A good Apache configuration GUI for Windows is a great way to introduce you to Apache and using the Apache GUI is faster and easier than configuring Apache server by hand.
Apache Configuration GUI for Windows has advanced descriptions all of the server's directives and parameters. You can easily get help about any directive at any time. It helps the beginner to quickly master the Apache web server and it will provide a real tutorial for you. For the experienced user it is an indispensable administrative tool.
Main program features
ApacheConf has a number of features that allow you to edit your httpd.conf easily and quickly, making your work more efficient and orderly.
ApacheConf - Apache Configuration GUI for Windows

Represents all the information of Apache's main configuration file in a structured view. All of the server's directives are grouped by category (Global parameters, Main server's parameters, Directories, Virtual hosts, etc) and all these groups are represented as a tree for easy access.
Editing httpd.conf file using GUI and by manually in special editor with syntax highlighting, bookmarks, line numbers.
Interaction with your Apache server. You can start, stop or restart an Apache server on local computer or on remote computer easily and quickly. In the current version ApacheConf can control remote servers working under MS Windows, *nix (Unix/Linux/FreeBsd) and Novell Netware platforms.
ApacheConf has a full description of the all the directives that might be present in httpd.conf. This gives you easy access to help in using Apache which is especially useful for beginning web administrators.
SSI Wizard.
PHP Wizard.
Quick test of configuration file on correctness.
Quick start, stop and restart an Apache web server.
Downloading and uploading a httpd.conf directly from(to) remote server via SSH or FTP connections.
ApacheConf has special managers for easily managing some of Apache's directives (LoadModule, Alias directives, ErrorDocument, language directives, charsets directives, etc).
You can quickly switch to the text source of httpd.conf and the current active directive will be selected automatically. This way you can always compare how the program represets the text from the configuration file.
Quick view of server's ErrorLog file.
ApacheConf has an easy to use wizard for creating a new default configuration file for Apache 1.3 or 2.0.
ApacheConf shows a warning message when an invalid directive is used.
Apache Configuration GUI for Windows will make web administrator's work much more effective and pleasant!

Download ApacheConf

Process for Migrating IIS Web Sites to IIS 6.0 (IIS 6.0)

2006-01-11T08:24:00.000-08:00

The process for migrating Web sites hosted on IIS consists of preparing for and performing the migration. Before performing the migration, you need to evaluate the compatibility of the software installed on your existing Web server (including software that generates dynamic content, database connections, and any non-Microsoft software) with Windows Server 2003 and IIS 6.0. You can then perform the migration manually or with the IIS 6.0 Migration tool. After the migration is complete, you must further customize the configuration of IIS 6.0. Figure 6.1 illustrates the process for migrating existing IIS Web sites to IIS 6.0.

Figure 6.1 Migrating IIS Web Sites to IIS 6.0

Tip

To migrate a Web farm, use the process described in this section to migrate Web sites from each Web server in the source Web farm. Then, use provisioning or Web site staging software to propagate the migrated content and site configuration to other Web servers in the target Web farm.

Depending on your familiarity with Windows server operating systems, IIS, and the migration process, you might require less information to complete the IIS 6.0 migration process. To facilitate the fastest possible migration, the following quick-start guide is provided. You can use this guide to help identify the steps of the IIS 6.0 migration process that you need additional information to complete, and then you can skip the information with which you are already familiar. In addition, all of the procedures that are required to complete the IIS migration process are documented in Appendix A: IIS Deployment Procedures.

Prepare for Migration
1.
Identify which Web site and application components to migrate.

2.
Determine compatibility with Windows Server 2003.

3.
Determine application compatibility with worker process isolation mode by evaluating the following:

• The benefits of worker process isolation mode

• The application changes that are required for worker process isolation mode

• The management and provisioning script changes that are required for worker process isolation mode

• The results of lab tests that were completed to verify application compatibility with worker process isolation mode

4.
Determine application compatibility with the Microsoft .NET Framework on Windows Server 2003.

5.
Select one of two methods for migration:

• Using the IIS 6.0 Migration Tool

• Completing the migration process manually

6.
If you are using the IIS 6.0 Migration Tool, identify the following:

• Tasks that are automated by the migration tool

• Subsequent tasks that must be performed manually

Top of page
Deploy the Target Sever
1.
Install Windows Server 2003.

2.
Install and configure IIS 6.0.

Top of page
Migrate Web Sites with the IIS 6.0 Migration Tool
1.
Install the IIS 6.0 Migration Tool.

2.
Verify that clients are not accessing Web sites.

3.
Run the migration tool.

4.
Verify that the migration tool ran successfully.

5.
Migrate additional Web site content that is in the following two locations:

• Outside the home directory of the Web site

• Inside virtual directories

6.
Modify IIS metabase properties that reference the systemroot folder.

Top of page
Migrate Web Sites Manually
1.
Verify that clients are not accessing the Web sites.

2.
Create Web sites and virtual directories.

3.
Migrate Web site content to the target server.

4.
Configure Web site application isolation settings by completing the following tasks, if appropriate:

• Document the current application isolation settings on the source server.

• Configure application isolation settings in IIS 5.0 isolation mode.

• Configure application isolation settings in worker process isolation mode.

5.
Modify IIS 6.0 metabase properties that reference the systemroot folder.

Top of page
Configure IIS 6.0 Properties
1.
Configure IIS 6.0 properties that reference local user accounts.

2.
Configure Web service extensions.

3.
Configure Multipurpose Internet Mail Extensions (MIME) types.

4.
Migrate server certificates for Secure Sockets Layer (SSL).

5.
Migrate Microsoft FrontPage® users and roles.

6.
Configure IIS 6.0 to host ASP.NET applications by completing the following tasks:

• Configure IIS to use the correct version of the .NET Framework.

• Configure the .NET Framework.

• Review how ASP.NET applications run in each application isolation mode.

• Migrate Machine.config attributes to their equivalent IIS 6.0 metabase property settings.

7.
Determine whether to run the IIS Lockdown Tool and UrlScan.

Top of page
Perform Application-Specific Migration Tasks
1.
Modify application code for compatibility with Windows Server 2003 and IIS 6.0 by doing the following:

• Modify references to Windows platform components and application programming interfaces (APIs) that are no longer supported in Windows Server 2003.

• Modify references to IIS 6.0 metabase properties that have changed or are no longer supported in IIS 6.0.

• Modify applications to be compatible with worker process isolation mode.

2.
Install additional software required by applications.

3.
Migrate Microsoft Transaction Server (MTS) packages, Component Object Model (COM) objects, and COM+ applications that are required by applications.

4.
Modify data source names (DSNs) and Open Database Connectivity (ODBC) connections required by applications.

5.
Create IP addresses that are used by applications.

6.
Create users and groups that are used by applications.

7.
Create registry entries required by applications on the target server.

Top of page
Complete the Migration
1.
Verify that the Web sites and applications migrated successfully.

2.
Back up the target server.

3.
Enable client access.

Using the Adsutil.vbs Administration Script (IIS 6.0)

2006-01-10T05:37:00.000-08:00

Adsutil.vbs is an IIS administration utility that uses Microsoft Visual Basic Scripting Edition (VBScript) with Active Directory Service Interfaces (ADSI) to manipulate the IIS configuration. This script should be run using CScript, which is installed with Windows Script Host.
Important
You must be a member of the Administrators group on the local computer to run scripts and executables. As a security best practice, log on to your computer using an account that is not in the Administrators group, and then use the runas command to run your script or executable as an administrator. From the command prompt, type runas /profile /user:mymachine\administrator cmd to open a command window with administrator rights and then type cscript.exeScriptName (include the script's full path and any parameters).
Usage
Cscript.exe adsutil.vbs COMMAND [...]
Cscript.exe adsutil.vbs COMMAND [ [...]]
Command
Description
GET Path
Display chosen parameter.
SET Path Value
Assign a new value.
ENUM Path "/P"
Enumerate all parameters for the path. /P Enumerate the paths only (no data).
ENUM_ALL "/P"
Enumerate all parameters. /P Enumerate the paths only (no data).
DELETE Path
Delete the path or parameter.
CREATE Path [KeyType]
Create the path and assign it the KeyType.
APPCREATEINPROC Path
Create an in process application.
APPCREATEOUTPROC Path
Create an out-of-process application.
APPDELETE Path
Delete the application (if present).
APPUNLOAD Path
Unload an out-of-process application.
APPGETSTATUS Path
Get status of the application.
FIND Path
Find the paths where a parameter is set.
START_SERVER Path
Start the Web site.
STOP_SERVER Path
Stop the Web site.
PAUSE_SERVER Path
Pause the Web site.
CONTINUE_SERVER Path
Unpause the Web site.
HELP
Print all available commands.
Top of page
Notes
•
is the path of the node for which you are setting the property, combined with the name of the property that you are setting. For example, if you want to set the ServerComment for Web server number 1, the command would be as follows:
adsutil SET w3svc/1/ServerComment "Web Server Number 1"
The next time IIS Manager is opened, it will reflect the name of the Web server as "Web Server Number 1."
•
The switch "-s:server name" can be used after any command to execute the command on a remote computer. (See first example below.)
Top of page
Examples
•
Cscript.exe adsutil.vbs GET W3SVC/1/ServerBindings -s:remotecomputer1
•
Cscript.exe adsutil.vbs SET W3SVC/1/ServerBindings ":81:"
•
Cscript.exe adsutil.vbs CREATE W3SVC/1/Root/MyVdir "IIsWebVirtualDir"
•
Cscript.exe adsutil.vbs START_SERVER W3SVC/1
•
Cscript.exe adsutil.vbs ENUM /P W3SVC

IIS 7.0 Beta: Protocol Listeners (IIS 7.0 Beta 1)

2006-01-08T23:56:00.000-08:00

Protocol listeners receive protocol-specific requests, send them to IIS for processing, and then return responses to requestors. For example, when a client browser requests a Web page from the Internet, the HTTP listener, HTTP.sys, picks up the request and sends it to IIS for processing. Once IIS processes the request, HTTP.sys returns a response to the client browser.

By default, IIS 7.0 provides four protocol listeners to listen for protocol-specific requests: HTTP.sys, NET.TCP, NET.PIPE, and NET.MSMQ. HTTP.sys was introduced in IIS 6.0 as an HTTP-specific protocol listener for HTTP requests. HTTP.sys remains the HTTP listener in IIS 7.0, but includes support for Secure Sockets Layer (SSL). The other three default protocol listeners support Indigo services and applications.

IIS 7.0 Beta: Configuration Files

2006-01-08T04:51:00.000-08:00

(IIS 7.0 Beta 1)

Related Links
• IIS 7.0 Beta: Organization of IIS 7.0 Configuration Data
• IIS 7.0 Beta: Inheritance in IIS 7.0 Configuration
• IIS 7.0 Beta: General Attributes Inherited by IIS Section Elements

[This is preliminary documentation and subject to change.]

IIS 7.0 configuration is integrated with the .NET Framework configuration subsystem, which is based entirely upon XML-encoded data stored in text files. At runtime, the XML data in the configuration files is used to create an in-memory configuration for IIS 7.0 and other services that have settings in common with IIS.

The table below describes the configuration files that contain settings for deploying IIS and the inheritance status of each file within the configuration file hierarchy. For more information on inheritance, see IIS 7.0 Beta: Inheritance in IIS 7.0 Configuration.

Configuration File Name Description
Machine.config
Contains settings for the whole server. Settings in Machine.config are inherited by all other .NET configuration files, including IIS configuration files.

ApplicationHost.config
Contains settings for IIS and other services that have settings in common with IIS. Inherits settings from Machine.config.

Web.config (root-level)
Contains settings shared by all ASP.NET applications on a server. Inherits settings from Machine.config and ApplicationHost.config.

Web.config (application-level)
Contains settings that apply to an ASP.NET application. Inherits from Machine.config, ApplicationHost.config, the root-level Web.config, and other application-level Web.config files placed higher tree for the application.

Configuration Files and Locations
The file that contains IIS settings, as well as settings that are common to IIS and other .NET services, is named ApplicationHost.config. There is one ApplicationHost.config file for each server. The default root for ApplicationHost.config is located at systemroot\system32\inetsrv\ ApplicationHost.config.

The root Web.config file is located at systemroot\Microsoft.NET\Framework\versionNumber\CONFIG\Web.config. This file exists for each version of the .NET Framework that is present on the server. The root Web.config file contains settings that are inherited by all ASP.NET applications that run a specific version of the .NET Framework.

Each application on the server has its own Web.config file, which contains ASP.NET application elements that can e set using IIS configuration tools. The application-level Web.config file applies configuration settings to the directory in which it resides, as well as to all child directories.

Settings in child directories can override or modify settings specified in the Web.config file in the parent directory, unless the settings are locked at the parent Web.config level.

The overridden settings are stored in a Web.config file at the level where those settings take effect.

How to configure IIS 6.0 URL Authorization

2006-01-07T02:43:00.000-08:00

View products that this article applies to.
Article ID : 326020
Last Review : June 8, 2004
Revision : 1.0
This article was previously published under Q326020
On This Page
SUMMARY
INTRODUCTION
Metabase attributes that IIS 6.0 URL Authorization uses
Script to set the attributes on the IIS metabase
The AzImpersonationLevel attribute
The AzStoreName attribute
The AzScopeName attribute
How to configure IIS 6.0 URL Authorization
Create your program folder under the Default Web Site folder, and then disable anonymous access to the site
Set the wildcard configuration properties to point to the URLAuth.dll file
Add the URLAuth.dll file as a new Web service extension
Set up an authorization policy store in Authorization Manager
Set up the scope for the program
Add the IIS worker process to the store's Readers role
Configure the IIS metabase to use IIS 6.0 URL Authorization for the Web program
REFERENCES
APPLIES TO

SUMMARY
Microsoft Internet Information Services 6.0 works with Authorization Manager in Microsoft Windows Server 2003 to provide IIS 6.0 URL Authorization. IIS 6.0 URL Authorization simplifies the administration of user access to Web objects. In IIS 6.0 URL Authorization, you maintain access control by using metabase attributes that control URL authorization. These metabase attributes are the following:
• AzEnable
• AzStoreName
• AzScopeName
• AzImpersonate

You can set these metabase attributes by using of a script. Authorization policy for IIS 6.0 URL Authorization is stored in an Authorization Manager policy store either in Active Directory or in an .xml file.

To configure IIS 6.0 URL Authorization, you must create your program folder under the Default Web Site folder in IIS Manager and then disable anonymous access to the site. You must then set the wildcard configuration properties to point to the URLAuth.dll file. You must also add URLAuth.dll as a new Web service extension. Next, you must set up an authorization policy store in Authorization Manager, set up the scope for the program, add the IIS worker process to the store's Readers role, and then configure the IIS metabase to use IIS 6.0 URL Authorization for the Web program.
Back to the top

INTRODUCTION
Microsoft Internet Information Server (IIS) 6.0 is included with Microsoft Windows Server 2003. IIS 6.0 works with Authorization Manager to provide IIS 6.0 URL Authorization. As a Web program administrator, you can use IIS 6.0 URL Authorization to control access to URLs based on custom user roles, on LDAP queries, and on BizRules.

To authorize user access to Web pages in IIS, you may have to manage many Discretionary Access Control Lists (DACLs) on resources that the Web programs use. Resources for Web programs may include Web page files, database records, registry keys, and more.

A task is a collection of low-level operations. An operation is a low-level permission that a resource manager uses to identify security procedures. Frequently, operations are not exposed or meaningful to administrators. For example, an operation may be WriteAttributes or ReadAttributes. The purpose of the task is to determine which low-level operations are required to do some unit of work that is meaningful to administrators. Several operations may be required to perform a meaningful task. To maintain DACLs, you must know which back-end permissions are required on each object to perform meaningful tasks in the Web program.

IIS 6.0 URL Authorization simplifies access management by letting you authorize user access to the URLs that make up a Web program. When a client requests a URL, IIS 6.0 URL Authorization validates the user's access based on the user roles. By using IIS 6.0 URL Authorization, you can control all user access to URLs instead of maintaining a DACL on each object. Additionally, the Web program can restrict access to resources and to operations by using the Authorization Manager role-based framework.

IIS 6.0 URL Authorization is implemented as an Internet Server API (ISAPI) interceptor DLL that is configured as a wildcard extension for a program, for a virtual directory, or for a URL. When a program, a virtual directory, or a URL is configured to use IIS 6.0 URL Authorization, each request to a URL is routed to the IIS 6.0 URL Authorization ISAPI interceptor.

The IIS 6.0 URL Authorization ISAPI interceptor then uses the Authorization Manager runtime to authorize access to the requested URL. For the Authorization Manager runtime to authorize access, the program location, the virtual directory location, or the URL must be associated with an Authorization Manager policy store that contains the authorization policy for the URL that is requested. After the client is authorized to access the URL, the IIS 6.0 URL Authorization ISAPI passes the request to the appropriate handler for the URL. For example, the IIS 6.0 URL Authorization ISAPI passes the request to ASP, to ASP.NET ISAPIs, or to the Static File Handler.

You can use IIS 6.0 URL Authorization to control access based on information that is only available at run time. For example, if you have a Web page that only employees in a specific cost center or employees of a specific age can view, you can assign roles to the correct users based on LDAP queries. The LDAP queries verify the cost center attribute or the age attribute on a user object at run time. If employees can access some pages only on specific days of the week or only during a specific time of day, you can create a BizRule that grants access to the URL based on these values. You can create a BizRule on any value that can be asserted at run time, including IIS Server Variables.

Back to the top

Metabase attributes that IIS 6.0 URL Authorization uses
IIS 6.0 URL Authorization uses the metabase attributes in the following table to set authorization on a URL, on a virtual directory, or on a program. Attribute Authorization
AzEnable This attribute enables IIS 6.0 URL Authorization for the virtual directory, for the program, or for the URL that corresponds to the entry in the metabase.
AzStoreName This attribute associates an Authorization Manager store with the virtual directory, the program, or the URL.
AzScopeName This attribute associates the virtual directory, the program, or the URL with a scope that the AzStoreName attribute refers to in the Authorization Manager policy store in IIS 6.0 URL Authorization. If this attribute specifies either an empty string or no scope at all, the default scope of IIS 6.0 URL Authorization is used.
AzImpersonate This attribute determines the impersonation behavior for the program. You can use this attribute to configure the Web program to impersonate the client user, the IIS worker process, or the IUSER_* account for the worker process. Each setting significantly changes the environment and the implied design of the Web program. Set the value to 0, to 1, or to 2. These values correspond to the impersonation style.

0 The authenticated client is impersonated. Some programs require client impersonation, such as ASP 2.0 programs. Use this value if you want to use IIS 6.0 URL Authorization for programs that expect to run while impersonating the client, such as ASP 2.0 programs.

1 The IIS worker process identity is impersonated. Use this value when the program runs as a service account, authorizes each client request itself, and performs requested operations on behalf of the client in the trusted service context.

2 The anonymous user account is impersonated. Use this value if you want to use IIS 6.0 URL Authorization to authorize client access to the URL while still running the Web program as the anonymous account. This configuration limits all client access through the Web program.

Back to the top

Script to set the attributes on the IIS metabase
The following script uses ADSI to set the metabase attributes on the IIS metabase entry for a program, for a virtual directory, or for a URL.

Note This script assumes that you have already created the IIS virtual directory that corresponds to the program. For additional information about how to create an IIS virtual directory, click the following article number to view the article in the Microsoft Knowledge Base:
816568 (http://www.kbAlertz.com/Feedback.aspx?kbNumber=816568/) How to manage Web sites and Web virtual directories by using command-line scripts in IIS 6.0
' SetUrlAuth.vbs
' Configuring UrlAuth with a virtual directory
' This script uses ADSI to configure a virtual directory in the IIS 6.0 metabase to use
' IIS 6.0 URL Authorization.
'
' This script assumes that you have already created the IIS virtual directory
' that corresponds to the program.
'
' After you run this script to verify the settings, use the Adsutil tool in
' the following way:
'
' inetpub\adminscripts\adsutil enum w3svc/1/root/MyApp
' (where MyApp is the application name)
' Use the Authorization Manager MMC snap-in to:
' Create an application that is named IIS 6.0 URL Authorization.
' Create an operation that is named AccessURL and that has an operation ID of 1.
' Create a scope that corresponds to the AzScopeName that is specified to this script.
' This scope name is used to manage access to URLs in this virtual directory.
' Make sure that the IIS worker process has read access to the
' AzMan policy store. To do this, right-click the AzMan store, click Options,
' and then click the Security tab.
Set objArgs = WScript.Arguments
If objArgs.count < 4 then
wscript.echo "Usage: SetUrlAuth VDirPath AzScopeName AzStoreName AzEnable [ImpersonationLevel]"
wscript.echo ""
wscript.echo "Example:"
wscript.echo " SetUrlAuth w3svc/1/root/MyApp MyApp msxml://d:\inetpub\wwwroot\AzStore.xml True 1"
wscript.echo ""
wscript.echo "Run with 'cscript' command in cmd.exe to avoid msg boxes"
Else
wscript.echo objargs(0)
'
' Get the interface to the virtual directory object.
'
DIM iis
set iis = GetObject("IIS://localhost" & objArgs(0))
' Set the scope name. This scope will preside over URLs that refer to this virtual directory.
' This scope must exist in the corresponding Authorization Manager store.
'
iis.AzScopeName = objArgs(1)
'
' Specify location of Authorization Manager policy store
'
iis.AzStoreName = objArgs(2)
'
' Enable IIS 6.0 URL Authorization for this virtual directory.
'
iis.AzEnable = objArgs(3)
'
' Set the Impersonation Level property.
'
If objArgs.count > 4 then
iis.AzImpersonationLevel = objArgs(4)
End if
'
' Write the settings to the metabase.
'
iis.SetInfo
End if
Back to the top

The AzImpersonationLevel attribute
When a client requests a Web page, IIS 6.0 URL Authorization authorizes the client access based on the Authorization Manager authorization policy. The security context that the AzImpersonationLevel attribute configures to retrieve the URL data, such as an .htm file, requires the correct IIS directory security permissions and the correct NTFS file system permissions. IIS 6.0 URL Authorization makes it easier for you to maintain the IIS directory security permissions and the NTFS permissions because IIS 6.0 URL Authorization uses the trusted subsystem model.

Back to the top

The AzStoreName attribute
When IIS 6.0 URL Authorization is configured, you can identify an Authorization Manager policy store through the AzStoreName attribute in the IIS metabase entry for the program, for the virtual directory, or for the URL.

To manage the authorization policy, follow these steps: 1. On the computer that is running IIS 6.0, click Start, click Run, type Azman.msc, and then click OK.
2. In the console tree, right-click Authorization Manager, and then click Open Authorization Store.
3. In the Store Name box, type the path of the authorization store location that the AzStoreName attribute identifies, and then click OK.
For more information about how to open an authorization store, see the "Authorization stores and applications" topic in the Authorization Manager Microsoft Management Console (MMC) Help.

Back to the top

The AzScopeName attribute
The IIS 6.0 URL Authorization program manages IIS 6.0 URL authorization for the store that the AzStoreName attribute identifies. The AzScopeName attribute in the metabase entry is an Authorization Manager scope in the IIS 6.0 URL Authorization program. You can use this scope to manage access to the corresponding URL. When you configure a program, a virtual directory, or a URL for IIS 6.0 URL Authorization, you must crate a scope in the authorization policy store. This scope must have the same name as the name that is specified in the corresponding metabase entry's AzScopeName attribute.

Authorization policy for IIS 6.0 URL Authorization is stored in an Authorization Manager policy store either in Active Directory or in an .xml file. When you use IIS 6.0 URL Authorization, you can maintain the authorization policy for URLs in the same authorization policy store as the authorization policy of Web programs that use Authorization Manager to control access to program tasks and operations. Therefore, you can manage access to URLs and to Web program resources from the same Authorization Manager MMC or from the same custom user interface.

This behavior provides a common point for access control administration of URLs and of programs. Therefore, you can use the same Authorization Manager groups and the same LDAP queries to populate roles for both URL authorization and program authorization.

Back to the top

How to configure IIS 6.0 URL Authorization
This section describes how to set up IIS 6.0 URL Authorization for a Web program by using an example URL. The example URL is named WebApp and is installed and configured in IIS as a program in the Systemroot\InetPub\WWWroot\WebApp folder.

Note Integrated Windows Authentication is required for URLs that use IIS 6.0 URL Authorization. By default, IIS Web programs and virtual directories turn on Integrated Windows Authentication. For information about how to configure Integrated Windows Authentication, see the "Integrated Windows Authorization" topic in the IIS online Help file.

Create your program folder under the Default Web Site folder, and then disable anonymous access to the site
1. Click Start, click Run, type %systemroot%\System32\InetSrv\IIS.msc, and then click OK.
2. In the console tree, double-click Internet Information Services, double-click the name of your computer that is running IIS, double-click Web Sites, double-click Default Web Site, right-click the folder that correspond to your Web program, and then click Properties.
3. Click the Virtual Directory tab, and then click Create.
4. Click the Directory Security tab, and then click Edit in the Authentication and Access Control area.
5. Click to clear the Enable Anonymous Access check box.
6. Click to select the Integrated Windows Authentication check box, click OK, and then click OK again.

Set the wildcard configuration properties to point to the URLAuth.dll file
1. In IIS Manager, right-click the folder for the Web program that you created, and then click Properties.
2. In the Properties dialog box, click the Virtual Directory tab, and then click Configuration.
3. In the Wildcard application maps (order of implementation) area, click Insert.
4. In the Add/Edit Application Extension Mapping dialog box, click Browse.
5. In the Files of type list, click All files (*.*).
6. Locate the Systemroot\System32\InetSrv folder.
7. Click URLAuth.dll, and then click Open
8. Click OK three times.

Note You may receive an error message that is similar to the following:
This executable path is already used
If you receive this error message, the URLAuth.dll file is already configured as a wildcard program extension mapping.

Add the URLAuth.dll file as a new Web service extension
1. Start IIS Manager.
2. In the console tree, double-click Internet Information Services, double-click the name of your computer that is running IIS, and then click Web Service Extensions.
3. In the Task list in the details pane, click Add a new Web service extension.
4. Click Add, and then click Browse.
5. Locate Systemroot\System32\InetSrv\, click URLAuth.dll, click Open, and then click OK.
6. In the Extension Name box, type URL Authorization.
7. Click to select the Set extension status to Allowed check box, and then click OK.

Back to the top

Set up an authorization policy store in Authorization Manager
In this example, you put an authorization policy store that is named MyStore.xml in the C folder. 1. Click Start, click Run, type Azman.msc, and then click OK.
2. In the console tree, right-click Authorization Manager, and then click Options.
3. Click Developer mode, and then click OK.
4. In the console tree, right-click Authorization Manager, and then click New Authorization Store.
5. Click XML file, and then type C:\MyStore.xml in the Store name box.
6. In the Description box, you may type information about the new store. This step is optional.
7. Click OK.
8. In the console tree, right-click MyStore.xml, and then click New Application.
9. In the Name box, type IIS 6.0 URL Authorization.
10. In the Description box, you may type information about this usage of IIS 6.0 URL Authorization. This step is optional.
11. Click OK.
12. In the console tree, double-click Authorization Manager, double-click MyStore.xml, double-click IIS 6.0 URL Authorization, and then double-click Definitions.
13. Right-click Operation Definitions, and then click New Operation Definition.
14. In the Name box, type AccessURL.
15. In the Operation number box, type 1, and then click OK.

Set up the scope for the program
1. In the Authorization Manager console tree, right-click IIS 6.0 URL Authorization, and then click New Scope.
2. In the Name box, type WebApp, and then click OK.
3. In the console tree, double-click IIS 6.0 URL Authorization, double-click Definitions, right-click Role Definitions, and then click New Role Definition.

Note You can also create this role definition in the WebApp scope.
4. In the Name box, type Viewer, and then click OK.
5. In the console tree, double-click Role Definitions.
6. In the details pane, right-click Viewer, and then click Properties.
7. Click the Definition tab, click Add, and then click the Operations tab.
8. Click to select the AccessURL check box, click OK, and then click OK again.
9. In the console tree, double-click WebApp, right -click Role Assignments, and then click Assign Roles.
10. Click to select the Viewer check box, and then click OK.
11. In the details pane, right-click Viewer, and then click Assign Windows Users and Groups.
12. In the Enter the object names to select (examples) box, type your user name, and then click OK.

Add the IIS worker process to the store's Readers role
By default, IIS runs in the Network Service account. You can configure an IIS worker process to run in a different account. This example adds Network Service to the Readers role.

Note If you use a remote authorization store such as Active Directory or a remote XML file-based store, and you run IIS in the default Network Service context, you must add the Active Directory account of the Web server that is running IIS to the store's Readers role. 1. Click Start, click Run, type Azman.msc, and then click OK.
2. In the console tree, right-click Authorization Manager, and then click Open Authorization Store.
3. Click Browse, click C:\MyStore.xml, click OK, and then click OK again.
4. In the console tree, right-click the name of the store, and then click Properties.
5. Click the Security tab, click Reader in the Authorization manager user role list, and then click Add.
6. In the Enter the object names to select (examples) box, type Network Service, click OK, and then click OK again.

Configure the IIS metabase to use IIS 6.0 URL Authorization for the Web program
1. Click Start, click Run, type Cmd, and then click OK.
2. Use the script in the "Script to set the attributes on the IIS metabase" section to create the SetUrlAuth.vbs file. Save the file to the \InetPub\AdminScripts directory. By default, the InetPub directory is in the root of the drive where IIS is installed.
3. Type the following command, and then press ENTER:
CScript SetUrlAuth.vbs Path of virtual directory AzScopeName value AzStoreName AzEnable value [ImpersonationLevel value]
For example, you might type the following:
Cscript SetUrlAuth.vbs W3svc\1\Root\WebApp WebApp msxml://C:\MyStore.xml true 1
IIS 6.0 URL Authorization is now configured and running for the specified Web program. Users who are in the Viewer role can locate the pages in the program.

Important If you are using an .xml file, you must append msxml:// to the command. If you are using the Active Directory Authorization Manager store, you must append msldap:// to the command.

IIS 7.0 Beta: XML-Based Configuration Files (IIS 7.0 Beta 1)

2006-01-04T09:04:00.000-08:00

IIS 7.0 configuration files, named ApplicationHost.config, contain XML-encoded data with containment logic that is consistent throughout the settings schema. Configuration elements that contain settings for features as diverse as application pools, server bindings, custom-error mapping, and application debugging are all specified using the same containment structure and XML language.

Whether you use graphical tools or scripts, the IIS settings schema makes configuration data easy to navigate, parse, and set accurately. Because the same logic applies to settings from the server level down to the file level, you need to understand only one XML-based settings scheme to set any element at any level.

For example, suppose you wanted to set Windows authentication. You can set the same elements and attributes for Windows authentication at any of the following configuration levels using the same tools:

• On the Web server (in the ApplicationHost.config file)

• On an application root virtual directory (on a root-level Web.config file)

• Or at any level in an ASP.NET application (in an application-level Web.config file)

For detailed information on IIS 7.0 configuration files and the organization of configuration data, see the topics under IIS 7.0 Beta: Configuration Hierarchy.

Isolation of IIS Settings
The highest level that an IIS process model setting can be stored is in the ApplicationHost.config file. Process model settings cannot be stored in the Machine.config file. The isolation of IIS process model settings from the machine settings effectively prevents faulty process model settings from having an impact on Windows Server performance.

HcDoDynamicCompression

2006-01-03T02:12:00.000-08:00

The HcDoDynamicCompression property specifies whether responses to requests for dynamic content, such as such as dynamic content, such as scripts in ASP pages and ISAPI extensions are compressed. Setting HcDoDynamicCompression to true, indicates that dynamic content is compressed when requested by a client. If dynamic compression is enabled, each request for dynamic content that contains the "Accept-Encoding: gzip" or "Accept-Encoding: deflate" header causes the content to be compressed, so long as the compression scheme specified in the header is enabled in IIS. If the request does not contain this header, or the header specifies a compression scheme that is not enabled in IIS, the content is not compressed.

Important Because dynamic content is by definition always changing, IIS does not cache compressed versions of dynamic content. Dynamic compression consumes considerable CPU time and memory resources, and should only be used on servers that have slow network connections, but CPU time to spare.

At the individual compression scheme level (IIS Admin Object Hierarchy), the HcDoDynamicCompression property determines which compression schemes IIS will support for dynamic content; gzip, deflate, or both.

You can either enable compression of dynamic content server-wide, and then disable it at specific locations as needed, or, you can disable compression of dynamic content server-wide, and then enable it only at the locations you specify.

To enable dynamic content compression server-wide, set the HcDoDynamicCompression property to true at the IIS Admin Object Hierarchy level. You can then disable dynamic content compression settings for an individual Web site or site element, for example, a virtual directory or file, by using the DoDynamicCompression property at the individual site or site element level.

To disable dynamic content compression server-wide, set the HcDoDynamicCompression property to false at the IIS Admin Object Hierarchy level. You can then enable dynamic content compression settings for an individual Web site or site element, for example, a virtual directory or file, by using the DoDynamicCompression property at the individual site or site element level.

If you change the value of this property at the IIS Admin Object Hierarchy level, the World Wide Web Publishing Service (WWW service) must be restarted before the change takes effect.

Schema Attributes
Attribute Name Value
ADSI/WMI Data Type
BOOL

ABO Data Type
DWORD_METADATA

Schema Default
FALSE

Internal Default
FALSE

Upper Bound
0

Lower Bound
Not specified

Internal ID
2213

Friendly ID
MD_HC_DO_DYNAMIC_COMPRESSION

Property Attributes
NO_ATTRIBUTES

User Type
IIS_MD_UT_SERVER

Configurable Locations
You can configure this property at the following locations in the IIS metabase.

Metabase Path IIS Admin Object Type
/LM/W3SVC/Filters/Compression/gzip

/LM/W3SVC/Filters/Compression/deflate
IIsCompressionScheme

/LM/W3SVC/Filters/Compression/Parameters
IIsCompressionSchemes

Flags
There are no flags for this property.

Requirements
Client: Requires Windows XP Professional, Windows 2000 Professional, or Windows NT Workstation 4.0.

Server: Requires Windows Server 2003, Windows 2000 Server, or Windows NT Server 4.0.

Product: IIS