Windows IIS 6.0 Complete Guide| IIS 6.0 Tutorial
Internet Information Services:
Internet Information Services (IIS) 6.0 is a powerful Web server that provides a highly reliable, manageable, and scalable Web application infrastructure for all versions of Windows Server 2003. IIS helps organizations increase Web site and application availability while lowering system administration costs. IIS 6.0 supports the Microsoft Dynamic Systems Initiative (DSI) with automated health monitoring, process isolation, and improved management capabilities.
Starting the IIS:
You can use Run as through the user interface (UI) or as a command-line tool. The Run as feature that is built into the UI is a shortcut that you access by right-clicking some programs (files with the .exe file name extension), some Control Panel items (files with the .cpl file name extension), and Microsoft Management Console (MMC) (files with the .msc file name extension) snap-ins.
To use the Run as feature to run IIS Manager as an administrator
•
From the Start menu, point to Administrative Tools, right-click Internet Information Services (IIS) Manager, and then click Run as.
The runas command provides the same capabilities as the built-in Run as feature.
To use the runas command to run IIS Manager as an administrator
1.
From the Start menu, click Run.
2.
In the Open box, type cmd, and then click OK.
3.
At the command prompt, type the following:
runas /User:Administrative_AccountName “mmc %systemroot%system32inetsrviis.msc”
To use the runas command to run a command-line script as an administrator
1.
From the Start menu, click Run.
2.
In the Open box, type cmd, and then click OK.
3.
At the command prompt, type the following:
runas /profile /User:MyMachineAdministrator cmd
A new command window, which has administrative rights, opens.
4.
In the new command window, type the following at the command prompt:
cscript.exe ScriptName (include the script’s full path and any parameters)
Starting and Stopping Services and Sites
Infrequently, you might make configuration changes in IIS 6.0 that require you to restart IIS before the changes can take effect. For example, if you change the application isolation mode in which your server is running, such as when you change from worker process isolation mode to IIS 5.0 isolation mode or vice versa, you need to restart IIS. If you make this configuration change by using IIS Manager, you are prompted to restart IIS after you click OK to confirm the change. If you make this configuration change by using a command-line utility, such as Adsutil.vbs, you can use the IISReset command-line utility to complete the change. Both methods — using the Restart IIS command in IIS Manager or using a command-line utility — allow you to stop, start, and restart IIS Internet services, as well as restart your computer.
When you restart the Internet service, all sessions connected to your Web server (including Internet, FTP, SMTP, and NNTP) are dropped. Any data held in Web applications is lost. All Internet sites are unavailable until Internet services are restarted. For this reason, avoid restarting, stopping, or rebooting your server.
For a list of features designed to improve IIS reliability and remedy the need to restart IIS, see the Alternatives to Restarting IIS section in the Restarting IIS topic in the IIS 6.0 Operations Guide, which is accessible from IIS Manager.
Saving Your Configuration to Disk
As a safeguard, if you must stop or restart IIS, save your configuration to disk before you perform the restart. Your configuration is automatically saved if you enable the edit-while-running feature (this feature is not enabled by default). Alternatively, you can manually save your configuration to disk.
If You Receive an Error Stating That IISReset Is Disabled
If the IISReset command-line utility is disabled, then the command-line or IIS Manager calls that require IISReset.exe fail and return an error stating that IISReset is disabled. Actions that fail include the Restart IIS command in IIS Manager and Service Control Manager (SCM) recovery configuration actions that use the IISReset command-line utility (for example, the default IIS Admin SCM recovery path). However, SCM recovery actions that do not use the IISResetcommand-line utility continue to function (for example, the default World Wide Web Publishing Service [WWW service] SCM recovery path that restarts the WWW service).
Creating a Website and FTP site
IIS creates a default Web site on your computer during installation. You can use the LocalDrive:InetpubWwwroot directory to publish your Web content, or you can create any directory or virtual directory you choose. Because the FTP service is not installed by default, you must first install and start the File Transfer Protocol (FTP) service to create an FTP site.
Creating a Web or FTP site by using IIS Manager does not create content but merely creates a directory structure and configuration files from which to publish the content. .
Log Files
Logging in IIS 6.0 differs from logging in previous versions of IIS in several ways. The redesigned IIS architecture, which allows for multiple worker processes, affects how the IIS core components handle logging. In addition, IIS 6.0 provides new logging features and log file formats.
Events Are Logged by HTTP.sys
In IIS 5.0, all logging is done by the Inetinfo.exe component and is accomplished using Component Object Model (COM) modules that are written for logging. This system is effective in IIS 5.0 because there is only one server process model, Inetinfo.exe. However, in IIS 6.0, logging is done by the HTTP protocol stack (HTTP.sys). IIS 6.0 passes user-mode events to HTTP.sys through application programming interfaces (APIs), and then the user-mode events are logged by HTTP.sys.
HTTP.sys handles logging for two main reasons. When IIS 6.0 is running in worker process isolation mode, each worker process can perform its own logging and a site applications can spread across multiple application pools. If Inetinfo.exe performed logging in this environment, multi-instance or synchronization problems could occur. Such problems can be avoided because HTTP.sys performs logging. In addition, in IIS 6.0, requests can be served completely from the HTTP.sys kernel-mode cache without ever passing through Inetinfo.exe, so logging from HTTP.sys ensures that cached responses are recorded.
The log file format for which HTTP.sys does not perform logging is only Open Database Connectivity (ODBC) logging
W3C Centralized Logging
W3C centralized logging is a global configuration on the server where all Web sites write data to a single log file. This single log file uses the W3C Extended log file format and can be viewed in a text editor, unlike centralized binary logging, which writes data in a binary format and requires a parsing tool to view the data. W3C centralized logging is available in Windows Server 2003 Service Pack 1 or later
Substatus Error Code Logging
To reduce the possibility that a malicious user might use the information provided by substatus error codes to attack the Web server, substatus error codes are not returned to the client in IIS 6.0. Instead, administrators using the World Wide Web Consortium (W3C) Extended log file format can record substatus error codes when requests fail. Substatus error code logging is turned on by default for the W3C Extended log file format.
IIS Centralized Binary Logging
Centralized binary logging is a process in which IIS creates a single log file that contains binary, unformatted log data for all of the Web sites hosted on a server. In contrast, the other available IIS logging methods create one formatted, human-readable log file per Web site. Centralized binary logging provides organizations with a way to record detailed information about all of their Web sites, using a minimum of system resources.
HTTP.sys Error Logging
HTTP.sys sometimes generates its own errors that, because of the IIS 6.0 architecture, are not recorded with the worker-process-driven events. To account for these errors, IIS 6.0 supports HTTP.sys error log files. One example of an event that would trigger a log file entry in the HTTP.sys error log file is a connection time-out.
Remote Logging
You can write log data to a remote share over a network using a full, Universal Naming Convention (UNC) path. For example, you can specify \ServernameLogFiles as the storage directory for your log files, where Servernamerepresents the name of the remote server, andLogFiles represents the name of the directory where the log files are stored.
Tools for troubleshooting IIS
The following tools are useful for troubleshooting problems that occur with IIS 6.0:
•
WFetch (WFetch.exe). This tool allows you to generate customized HTTP requests and view request and response data.
•
File Monitor (FileMon.exe). This tool allows you to view and capture real-time file system activity.
•
Registry Monitor (RegMon.exe). This tool allows you to view and capture real-time system registry activity.
•
IIS Request Monitor. This tool captures information about HTTP requests in IIS worker processes, which can help you isolate and understand problems when worker processes become slow or unresponsive.
•
Secure Socket Layer (SSL) Diagnostic Tool (SSLDiag). This tool helps you identify configuration problems in the IIS metabase, certificates, or certificate stores when running Web sites that use SSL.
•
Authentication and Access Control Diagnostics (authdiag.exe). This tool allows you to review, test, and correct problems with authentication and authorization.
•
IIS 6.0 Enterprise Tracing for Windows. This tool allows you to trace HTTP requests as they move through various components in your server architecture. IIS components provide informational events and error events (if applicable) to the ETW architecture as requests enter and exit each component. You can view the event data to see exactly where in the IIS architecture a request failed or became unresponsive.
•
Network Monitor. This network tracing utility allows you to view activity in the network stack. Network Monitor is included with Windows Server 2003.
•
System Monitor. This tool allows you to view and collect system performance data. System Monitor is included with Windows Server 2003.
•
HRPlus. This tool provides error lookup functionality.
•
Microsoft Debugging Tools for Windows. This tool allows you to debug and diagnose application problems.
Creating New Web Sites:
A single web server can host multiple web sites. Before multiple sites can be hosted, however, one of three methods has to be implemented. (See the following section entitled “Hosting Multiple Web Sites on a Single Web Server.”) By default, any new web site created will be stopped and won’t be able to respond to requests for pages.
Exercise : Creating a New Web Site
In this exercise, you will create a new web site, provide content, and test the server to verify that content is viewable.
1. Click Start | All Programs | Administrative Tools | Internet Information Services Manager to open the IIS Manager MMC.
2. Right-click the Web Sites node and select New | Web Site.
3. Click Next to begin the Web Site Creation Wizard.
4. In the Description field, type WebsiteName.com and click Next.
5. Accept the default of All Unassigned for the IP address and Port 80 for the port.Do not enter a host header.
Click Next.
6. For the Web Site Directory, navigate to the Web folder which contains web site to be displayed.
Click Next.
7. Uncheck the permission to run scripts and verify that Read is the only permission present. Click Next.
8. Click Finish to complete the operation.
9. Right-click the Default Web Site and select Stop.
10. Right-click the WebsiteName.com web site and select Start.
11. Open Internet Explorer and type http://yourserver into the navigation bar to
view the web site.
Hosting Multiple Web Sites on a Single Web Server
There are three methods to hosting multiple web sites on a single web server:
• Assign a unique IP address to each site
• Assign a unique port number to each site
• Assign host headers to each site
Each of these methods has some sort of drawback, so it is important that you evaluate what is most important before selecting a method. The settings are on the Web Site tab of the properties page. Assigning a unique IP address to each site is the easiest of the three methods. However, you need to either configure a single network card with multiple IP addresses or install a new network card for each web site. An IP address has to be specified when a new web site is created, but All Unassigned is the default option. All Unassigned then assigns all IP addresses associated with the server to the web site. If an IP is selected that is in use by another site on the same server, the web site will be created in a stopped state. To start the site, either the other site has to be stopped or a unique IP has to be assigned. Assigning a unique port number to a site is more a security procedure than a method
of supporting multiple sites on a single server. By default, all web sites use port 80. Any traffic coming into the server on port 80 is automatically directed to the web site. If a unique port number is used for a site, only traffic coming into the server on that port number will be directed to the site. The problem with this is that Internet Explorer and other browsers automatically request pages on port 80, and any other port has to be specified in the address bar of the browser by the user. If a second web site was configured to use port 6767, for example, users would need to type www.WebsiteName.com:6767 to access the site. If you want your users to check e-mail on a publicly accessible web site, but you want the site to remain hidden from the public, you could create the web site on a different port number than 80 and then require your users to enter the port number in the address field to access the site. Excellent for keeping a particular site hidden, not so excellent as a method of hosting two sites on the same server. Host headers require a bit more administration to use, and are not as popular a method because they don’t support SSL encryption and are unable to be used by earlier versions of browsers that don’t support HTTP 1.1. To use host headers, you must configure DNS and IIS.
To configure host headers:
Part 1 – Configure IIS
1. Click Start | All Programs | Administrative Tools | Internet Information Services.
2. Expand the Web Sites node and select the Default Web Site. Right-click the
Default Web Site and select Properties.
3. On the General tab, select the IP address from the drop-down list. Click Advanced.
4. In the Advanced Web Site Configuration Properties page, select the Default IP
address and click Edit.
5. Enter a value for the Host Header. Click OK and close the Web Site Properties.
Part 2 – Configure DNS
1. Click Start | All Programs | Administrative Tools | DNS.
2. Navigate to the appropriate zone.
3. Add a CNAME record in the zone. For the Alias name, enter the Host Header
value. For the Fully Qualified Name of the target host, enter the FQDN of the
web server.
Monitoring Web Sites & It’s Log
The IIS Manager includes logging and monitoring options. To configure monitoring, open the web site properties and click the Web Site tab. The Enable Logging check box is selected by default, which automatically turns logging on. The default format for logging is W3C Extended Log File Format, but additional formats can also be used, such as Microsoft IIS Log File Format, NCSA Common Log File Format, or ODBC Logging. When logging is enabled, events are written to the application log in Event Viewer. To view additional logging options for the W3C Extended Log File Format, as shown in Figure , click the Properties button. Notice that logging can be scheduled or based upon a preset file size. Also, there is an option to use local time for all logging. When users
request pages from the web site, they transmit their own system time to the web site. If local time is not used, it is possible for events that occur very late in the day would be logged in the following day’s log file, based on the time of the remote system. Also, when IIS is installed, additional counters are automatically added to System
Monitor. These counters are used in the same way that other counters are used, and they can either be monitored in real time or stored as a log file.
Figure Logging Properties of the W3C Extended Log File Format
Configure Authentication and Restrictions:
All users of a web site actually have to authenticate to the domain before being able to access information, even anonymous users. By default, browsers attempt to access resources anonymously. If anonymous users are allowed access to the web site, they are authenticated to the IUSR account. (Go ahead, check your AD Users and Computers, it’s there!) The IUSR account is an Internet user account created just for the purpose of allowing
anonymous access and has very limited permissions granted. Anonymous users can be prevented from accessing your entire site or only specific directories. For example, you might run a personal web page where you post a letter to your family with recent pictures and so on. But you might also have a link on your personal web page to Outlook Web Access, which you use when you’re on the road. Anyone with nothing better to do can access your personal web page, but they must have a valid user account in your Active Directory to log on to your Outlook Web Access directory. In this case, the anonymous user has been removed from the proper directory, and users must be a member of the appropriate group before they can log on and check e-mail. If you wanted to go one step further, you could remove the anonymous user from your entire site, and users would have to be authenticated to your Active Directory to even view the letter and pictures. To restrict a site, right-click the web site and select Properties, then click the Directory Security tab. Click Edit in the Authentication section to display the authentication options, as shown in below Figure 1. Notice that anonymous access is allowed by default, and all requests will be authenticated to the IUSR account. The following authentication methods can also be used:
• Integrated Windows authentication
• Digest authentication for Windows domain servers
• Basic authentication
• .NET Passport authentication
Integrated Windows Authentication When this type of authentication is selected, a domain user account must be present for the user attempting to access the web site. The user is authenticated against the Active Directory in which the IIS server is a member. The user also must be a member of the appropriate groups to have access to the
content and directories located on the web server. When a user attempts to access a web site, they are prompted for their user name and password, as shown in below Figure 2. If the user is already logged onto the domain in which the web server is located, they are not prompted for a user name and password as their current domain account is used automatically. Integrated Windows authentication uses either Kerberos or NTLM as the
Figure 1 The Authentication Methods properties page
authentication protocol, depending on the capabilities of the client, ensuring that passwords are not passed over the Internet in clear text. Integrated Windows authentication is most commonly used in intranets.
Figure 2 User name and password prompt when attempting to access a secured site
Digest Authentication Digest authentication is used when Integrated Windows authentication is not supported, and is most commonly used over the Internet. An MD5 algorithm is transmitted instead of the actual password, and the values are compared against the password in Active Directory. Users must still have a valid user account in Active Directory to be authenticated using this method.
Basic Authentication Basic authentication is the most widely supported and the most commonly used form of web authentication. Passwords are sent in clear text across the Internet and verified against the domain in which the IIS server is a member. Accounts on a different domain can also be used by entering a domain in the appropriate field or by clicking Browse and selecting the desired domain. Basic authentication is supported by nearly all browsers and all operating systems, which is why it is so commonly used. Using basic authentication ensures that nearly everyone visiting the site will be able to log on and authenticate in order to use web resources.
.NET Passport Authentication .NET Passport is Microsoft’s baby and the method they have come up with to authenticate users to multiple web sites by using a single e-mail account. .NET is natively supported in Windows XP and Windows Server 2003, and you’ve most likely seen the pop-ups to register a .NET Passport with your user
account. Microsoft has switched all of their secure directories and sections on their web site to .NET Passport, and so you have probably been forced already to establish a .NET Passport account. On the up side, using .NET Passport really does mean that a single e-mail address will work for multiple sites. .NET Passport was created with e-commerce in mind to make signing on and shopping easier and faster. .NET Passport supports all the good web stuff as well, such as SSL, cookies, and JavaScript, and is compatible with IE 4 and higher, Netscape 4 and higher, and Opera 7.11 and higher.
Configuring IP and Domain Restrictions
In addition to requiring users to authenticate to the site, certain users can be blocked from accessing the web site by their IP address or their domain name. This technique is especially useful to prevent hackers from gaining access to the web server. Access can be either blocked or allowed based on a source IP or domain name, as shown in below
Figure 3. Let’s say you are configuring a secure site that only your own network and one of your clients is going to be authorized to use. You will first enable Integrated Windows authentication and make sure that each user has a valid user account in your Active Directory. But you can go one step further. You can enter the network ID of the client and the network ID of your own internal network, and allow access to only those specific blocks
Figure 3 Allowing access to a specific IP address
of IP addresses. Using this in conjunction with user names and passwords makes a very secure web site indeed.
To enter a specific IP address or a network ID, click Edit to bring up the IP Address and Domain Name Restrictions page. Then click Add and enter a single IP or network ID or domain name, as shown in Figure 3. Be aware that if a domain name is entered, a reverse DNS lookup will be required for every user attempting to access the site, which can significantly slow performance. (You are even warned about this behavior when
you click the option.)
Use Secure Sockets Layer (SSL) and Certificates
If Secure Sockets Layer (SSL) is configured to be required for a particular site or directory, all users attempting to access the site or directory are required to use HTTPS, and all information transferred between the client and the web server is encrypted. E-commerce sites should use SSL at a bare minimum to protect credit card transactions, viewing of account data, user logons, and other personal services. To enable SSL, click Edit under Secure
Communications and select Require Secure Channel (SSL). Windows Server 2003 servers built and used only in the United States also have the option to require 128-bit encryption, also known as strong encryption, rather than the standard 40-bit encryption. It is illegal to export 128-bit encryption outside of the United States. Certificates can also be used as a method to protect the web site and to authenticate users and allow access. Before certificates can be used, a certificate authority must be installed and configured. See Chapter 17 for more information on certificate authorities. By configuring the appropriate certificate settings in the Directory Security properties
page, and by installing and issuing certificates, an extremely secure web site can be built.
