|
Introduction
IIS 4.0 allows you to have multiple web sites on one machine. Though IIS 3.0 has this capability, IIS 4.0 expands the functionality of multiple web sites by adding additional characteristics to sub-directories, and allow for multiple applications. Special considerations need to be made when designing and administrating multiple web sites on a single machine, including when to use sub-directories, when to use virtual directories, how to handle security, and the handling of multiple applications.
In this issue we will be explaining the mapping of URL from the HTTP protocol to the Windows file system and the role that IIS 4.0 plays. Along with this explanation, we will give a suggestion for directory structure, application scope, and shed some light on security. We take the approach that you will want to have multiple web sites on the machine, or at least have multiple sub-nets.
Web Site Design
Web sites should be singular entries that are self-supporting. Each web site should be able to be moved to a different machine for load balancing, or just transportation purposes. In order to do this, they should be self-supporting, have their own security, and their own application scope. If you are an Internet Service provider, you will want to be able to design, move, and have the user update their web site without interfering with other sites on the same machine. We will try to address issues that you can consider when allocating space and running security for multiple web sites.
The HTTP protocol uses URLs to request files from the web server. Since most of these files are contained on the file system, IIS needs to translate the URL to the full path name of the file. The Internet Information Server does this translation on every request. However it is up to the administrator to configure the server so that the right URLs are mapped to the right directories.
To properly design the file system structure on a machine that hosts multiple web sites, you need to understand the difference between a home directory, a virtual root, and a sub-directory. You also need to understand when to use virtual directories and when to use sub-directories.
Home Directory
A URL that just contains a domain name is requesting the home directory, sometimes called the root directory. For instance, the URL below is requesting the default file in the home directory.
http://www.myserver.com
The minimal amount of work that the administrator needs to do to assist the web server in mapping URLs to directories is to map the home directory. For example the home directory of this web site could be mapped to:
c:\inetpub\wwwroot
Now that you understand what a home directory is, let us talk about how to create one in IIS 4.0. The home directory is the starting location of the web site in IIS 4.0 and is created when you create a web site. IIS 3.0 didn't require a home directory, but IIS 4.0 does. Here is how to create a new web site and specify the home directory:
From MMC:
- Select the server that you want to create the web site on.
- Right Click and choose Create New | Web Site.
- The New Web Site Wizard appears and you are asked to enter a web site description.
- Enter a description and press Next.
- The next page of the Wizard ask for the TCP/IP information, leave the default setting for now and press Next. You can always change these setting later.
- The third page asks for your the home directory, enter in the directory and press Next.
- The forth page queries you about the access permission. Select the proper entries and press Finish.
Sub-Directories
Sub-Directories are directories that inherit the URL mapping from the file system structure. For example, if this directory existed:
c:\inetpub\wwwroot\sales
Then this URL would also exists:
http://www.myserver.com/sales
Sub-directories do not need to be defined to the web server by the system administrator. Because of this, just creating the sub-directory with Explorer will create the directory. There is no need to make any modification in the IIS 4.0 configuration.
Virtual Roots
Virtual directories are sub-directories of a URL that are mapped to file system directories that might not inherently exist on the file system. For example if you wanted your site to contain the following URL:
http://www.myserver.com/marketing
And this directory didn't exist:
c:\inetpub\wwwroot\marketing
You could create a virtual directory that mapped the URL to:
c:\inetpub\marketing\website\external
Virtual directories make the web site appear as if it has a different directory structure than it actually has on the file system. Here is how to create a virtual directory in IIS 4.0:
From MMC:
- Select the web site that you want to create the virtual directory in.
- Right Click and choose Create New | Virtual Directory.
- The New Virtual Directory Wizard appears and you are asked to enter an alias to the virtual directory.
- Enter an alias and press Next.
- The next page of the Wizard ask the physical directory location of the virtual directory, enter the physical directory information and press Next.
- The third page queries you about the access permission. Select the proper entries and press Finish.
What is the difference between virtual directories and sub-directories?
In IIS 3.0 the difference between virtual directories and sub-directories was significant. In IIS 3.0, sub-directories inherited the properties of the parent directories and virtual directories could have different properties. For instance if you made the home directory read-only and you created a sub-directory called scripts - that sub-directory would be read-only also. If you wanted the scripts directory to have read and execute permissions so that you could run ASP files, you would need to make it a virtual directory.
In IIS 4.0, sub-directories inherit the properties of the parent directory upon creation, but these properties can later be changed. In IIS 4.0 you can create a sub-directory called scripts and change its properties so that it has scripting permission without creating a virtual directory. Here is how to change the permissions of a sub-directory.
From MMC:
- Select the sub directory whose permissions you want to change.
- Right Click and choose Properties from the drop down menu.
- The Properties for Dialog appears.
- Choose the Directories tab.
- Select the proper permissions and press OK.
When to Use Virtual Directories
Virtual directories should only be used when sub-directories can not be used. Here is where we get into personal opinion. Because sub-directories take no web server, and they have all the functionality of virtual directories in IIS 4.0, they should be used whenever possible. Plus sub-directories organize all files into a central location for the web site.
Virtual directories should be used when all the files in the virtual directory does not fit on the physical disk. For instance, if you have a web site that is bigger then 2 Gigs, you might not be able to fit all of it on one disk. In this case, you will need to separate the web site into multiple virtual directories on the directory on each disk. For performance you can also divide your web site up onto multiple disks. In theory, random access across multiple disk drive should be faster then the same number of accesses on the same disk.
If you have multiple web sites and you are sharing information, virtual directories can be used to accomplish this task. For instance if you are sharing graphics, both web sites could have a virtual directory called graphics that is mapped to the same physical disk location. This would be impossible to do with sub directories. Updates to the files in the graphics directory would effect both sites. There is also a performance consideration here, two sites sharing the same files would allow NT to do more memory caching of those files than if they where in separate directories.
One of the main differences between IIS 3.0 and IIS 4.0 is Application Scope. In IIS 3.0, the scope of the application covered the whole machine. In IIS 3.0, if you had two web sites running on the machine, they both shared the same application. In IIS 4.0, you can have more then one application in each web site, and many applications scopes on the whole machine. In order for each web site to be a singular entity you need to understand how to assign each web site it's own application scope.
For instance, in IIS 3.0 if you have the web site http://www.myserver.com and http://www.myofferserver.com and the user linked from one of the servers to the other, he would be within the same application scope. Which means that if you had two global.asa files, one for each web site, only the first global.asa would be called and the second would not. The one called would be the global.asa that corresponded to the first web site that you entered on that machine.
IIS 4.0 gives you the ability to have an application scope start anywhere that you have a directory. The scope then extends to all files in that directory and all files in the subdirectory below. The subdirectory rule however only pertains if there isn't another application scope defined in any of the subdirectories themselves. This means that you can have an application defined for http://www.myserver.com and one for http://www.myoffers.com.
Creating an Application
From MMC:
- Expand the tree until you can see the directory or web site that you want the application to start.
- Select the directory or web site and right click.
- Chosse Properties from the drop down list.
- Select the Virtual Directory tab if you are on a virtual directory and the Home Directory tab if you are on a web site.
- Click on Create.
- Click on OK to exit the properties dialog.
All users exist within the application scope of the web site that they are viewing. However, each user has his own session variables. So the Session scope is per user. However, just like IIS 3.0, Sessions in IIS 4.0 are restricted to the scope of the application. It only becomes apparent in IIS 4.0 though because of the ability to have multiple applications.
Example One
Let us say that you have an Application created on the root of your web site:
http://www.myserver.com
that root is mapped to:
c:\inetpub\wwwroot\www.myserver.com
That means that anyone coming into this particular web site will be issued a Session cookie, and that pages within the root could share session variables with pages in all the sub-directories and virtual roots within that web site, such as:
http://www.myserver.com/dir1
http://www.myserver.com/vroot1
This might be one of the easiest and most useful configurations for any web site. With this setup, you can have Active Server pages in any subdirectory and they will be able to get Session information that was assigned by all other page in the web site. However this is not all the IIS 4.0 can do, so let us examine the possibilities
Example Two
For example two, we will take example one and create another application within the web site. Make sure that you understand example one before proceeding. Create a directory as a sub-directory of:
c:\inetpub\wwwroot\www.myserver.com
call it scripts.
When you create a subdirectory out of the root of the web site, you can access files in that subdirectory using the root URL and the name of the subdirectory like this:
http://www.myserver.com/scripts
Now create an application on the script directory. Now we have two application scopes. One started in example one that includes all files in the web site root and all other files in sub directories that are not scripts. And another application scope that includes all files in the scripts directory and all files that are in sub-directories of the scripts directory.
When you go to the root directory of your application, a session is created and your browser is issued a cookie, just like if you went to the root directory in example one. If you then go to the scripts directory, another session is created and you receive another cookie. Session variables set in the root directory are not apparent to the Active Server page in the scripts directory since there is a different session state. Actually, there are now two session states for that user. If the user goes back to the root directory and the session has not expired then the first session will be picked up and used. The information that was set will still be set is this case.
One of the problems with the word security is that it means different things to different people. In this issue we will be referring to security as the ability to restrict access to pages on the web server. In the IIS context, security can also refer to SSL encryption, which we will not be addressing. This next section on security depends on the web files being on a NTFS file system and will not work if your files are on a FAT file system.
Most of us run anonymous security configurations and do not think much about web security. However, if you are going to secure your web site, you will want to design the file structure to make administrating security easy. You also need to take into consideration multiple web sites on the same machine, each might have different security requirements that need your attention.
Allow Anonymous
By setting Allow Anonymous in IIS 4.0, every request is made using the anonymous user. This means that the request takes on the permission of the anonymous user, by default IUSR_MACHINENAME. Every directory that the anonymous user has permission to access can be viewed by anyone making a request to the web server.
Notice that IIS 4.0 never allows anyone to view files on the web server that does not have a local account on that machine, or in the domain that the machine is registered. Even with Allow Anonymous checked, IIS 4.0 uses a local user to access the files, IUSR_MACHINENAME. This means even though you have Allow Anonymous checked you can still restrict what files are viewed on the web server. In other words you can restrict access to certain files without creating a separate login for every user, you only need to create logins for those users that need access to restricted files. To restrict access to certain files you need to change the NT file system ACLs. Here is how to change your ACLs:
- Open Explorer by clicking on Start | Programs | Windows NT Explorer.
- Find the directory that you want to administer and click on it.
- While that directory is highlighted right click and select Properties.
- Click on the Security tab.
- From the Security tab click on the Permissions button.
- Using the Add or Remove buttons add and remove users until they correct permissions are set.
- Click on OK.
Now that you have changed your ACLs and restricted access to some files, there is no way to access the files unless you support either NT challenge/response or Basic Authentication.
Authentication
On the first request to a page the client (browser) tries to get the page without sending it's authentication information. If IIS 4.0 has Allow Anonymous checked and the anonymous user, IUSR_MACHINENAME has permissions to the file then the file is returned to the client. This happens regardless if NT Challenge/Response is checked. In other words, if both NT Challenge/Response and Allow Anonymous are checked then the client will use the anonymous user if the anonymous user has permissions to the file.
If the anonymous user doesn't have permissions to the file then a 401 'Access Denied' error message is returned and the client is notified of the authentication schemes that can be used. The client then chooses an authentication scheme and submits a request to the server with the authentication information. The server takes the authentication information and maps that information to a local or domain user. The mapping is as simple as using that login passed in the authentication to match a login on the domain or local box. The password is then used to validate the login.
If the local or domain user has access to that file then the file is returned to the user, otherwise a 401 'Access Denied' error message is returned. Which user can read which file is set at the file level with the file system ACLs. What authentication scheme the web server will accept is set in IIS 4.0. Here is how to set the authentication schemes in IIS 4.0:
From MMC:
- Click on the directory or web site whose permission you want to change.
- While highlighted right click and choose Properties from the drop down menu.
- Choose the Directory Security tab.
- From within the Password Authentication Group choose Edit.
- Check the Authentication setting you want.
- Click OK.
- Click OK.
Since IIS 4.0 supports two authentication schemes you get to choose which ones you use. Both have their advantages and disadvantages.
Currently Internet Explorer is the only browser that supports NT Challenge/Response. Both Netscape and Internet Explorer support Basic Authentication. So, if you need to handle a wide scope of people as in the case with an Internet site, you will need to use Basic Authentication. If you have an Intranet site and want to use authentication and everyone has Internet Explorer you can use NT Challenge/Response.
Basic Authentication sends the login name and password as clear text, in other words the name and password are not encrypted. This means that someone with software that can sniff your TCP/IP packets could obtain the user name and password used to login in to the pages. Since IIS 4.0 maps the user name and password directly to the local system accounts or the domain accounts, knowing the user name and password means that someone knows the local permission or domain permissions also. NT Challenge/Response encrypts the name and password based on a hand shake technique that goes on between the browser and the server.
One thing to notice is that Internet Explorer can handle both NT Challenge/Response and Basic Authentication, and if both are activated, Internet Explorer will choose NT Challenge/Response. This means that if you want to enable your site for both Internet Explorer and Netscape, enabling NT Challenge/Response prevents the clear text exposure of Basic Authentication when Internet Explorer is used.
Site Design
If you have to do a lot of web site authentication where different groups of users have exclusive access to different sections of the site you might want to design the site to handle that. When setting ACLs on the file system you can specify to change permission on all the files in the current directory and all the files on all sub-directories. This means that you can easily assign authentication that inherits from the parent.
For example, if everyone has permissions to the first page and some sub-directories, then set the ACLs on the home directory as Everyone and check the box Replace Permissions on Subdirectories. Then move to a sub-directory that needs to be restricted, assign the permissions, and check Replace Permissions on sub-directories. This overrides the first set of settings and restricts users in that branch of the tree. Do this with all restricted sub-directories wherever the permissions are different than the parent. This also works when adding new directories since the new directory initially inherits its' permissions from the parent.
Consider creating groups of user account within the domain to make administration easier. For instance, if you want to have everyone except marketing, make a marketing user group from within the user manager. Then set the permission of the file system using this new group. Now if someone is hired into the marketing department, you will only need to add them to the group and you will not need to modify the file system on the web server. Here is how to create a user group in the user manager:
From the DeskTop:
- Click on Start | Programs | Administrative Tools | User Manager for Domains. The User Manager will open. You will need to be an administrator on the local machine to change the local permissions or an administrator on the domain to create a group within the domain.
- From the menu bar click on User | Select Domain
- Type in the Domain name of the domain that the web server is on. In some case you will already be in the correct domain.
- Click on OK.
- Click on User | New Global Group.
- Type in the group name, a short description, and use the Add Button to add as many user accounts as needed to the group.
- Click on OK and the group is created.
Authenication and Proxies
The NTLM/CR protocol will not work thru an HTTP proxy which conforms to either HTTP/1.0 or HTTP/1.1. The result is that if one configures IIS for both basic and NTLM authentication, Netscape will work and IE will just hang when used from the other side of the proxy. Neither IE nor IIS will attempt a fallback.
The technical reason for the failure is that the NTLM/CR authentication protocol requires multiple steps in a single persistent connection thru the proxy (or to the origin server). The HTTP proxy treats persistent connection (if it supports it at all, this is not required) on a hop-hop basis and the proxy has the option of completely isolating the client from the server on a per request basis.
Take note here that your connection when using NT Challenge/Response authentication must be:
Connection: keep-alive
IIS 4.0 let's you turn off the contentious connection option in the Performance tab. Do not uncheck the HTTP Keep-Alives Enabled if you are using NT Challenge/Response authentication.
Scenario One
You want everyone visiting your Internet site to have full access to all the pages.
Solution:
Check Allow Anonymous and turn off NT Challenge/Response and Basic Authentication. Make sure that IUSR_MACHINENAME has permission to access the files using the file system ACLs. In other words leave the default Everyone/Full Control.
Scenario Two
You want everyone visiting your Internet site to have full access to some of the pages and you want all the employees of your company running Internet Explorer to have access to the web server statistics.
Solution:
Check Allow Anonymous and turn on NT Challenge/ResponseFor the pages that you want everyone to be able to visit make sure that the file ACLs allow IUSR_MACHINENAME to access the files. For the files that you only want company employees to access remove IUSR_MACHINENAME but leave the rest of the domain. This solution to the scenario assumes that all the people in your company have an account on the same domain that the web server is on. Notice also by allowing only turning on NT Challenge and Response users can only access your site with Internet Explorer and not Netscape.
Scenario Three
Your web site is completely restricted and it is divided into three sections: accounting, marketing, and management. Each department only wants the people in the rest of the department to be able to see their section of the site. For example, marketing can only see pages in marketing's section of the web site.
Solution:
Turn off Allow Anonymous and turn on NT Challenge/Response. Then create three domain account groups each group containing all the user accounts for each department. Modify the ACLs on each section of the web site to include only the group that owns that section.
|
