Microsoft Internet Information Server (IIS) 5.0 introduces a host of new features, including improved user and computer account handling, improvements in running user applications, and enhanced security features. Because more users will begin to use Windows 2000 (Win2K), which also rolls in major security enhancements, and IIS 5.0 is four to five times faster than IIS 4.0, now is a good time for an article addressing IIS 5.0's new security features. These new features let you configure application security more easily, and with new technologies such as Kerberos, the new features make using IIS security more consistent with other systems.
The first step in using IIS 5.0 is to install it on Win2K. I used Win2K Server beta 3 to test IIS 5.0. Win2K's configuration affects what you can do with IIS 5.0 and how the software's security features work. You can configure your server as a domain controller or install IIS 5.0 on an existing Win2K domain, which means that you can install IIS 5.0 on any machine in the domain.
After I installed IIS 5.0, I used Microsoft Visual InterDev 6.0 to create a new virtual directory. Win2K's FrontPage Server Extensions made the process of creating the new virtual directory on the server painless. Win2K forced me to log on through Visual InterDev and verified the user account that the OS used to create the directory. Other than my logon ID and password, I didn't have to know anything about Win2K. This matches the process in IIS 4.0 for creating a virtual directory and working with security features.
I set the security options on the server after I created the new virtual directory. To access the security settings for the virtual directory, you use the Internet Service Manager (ISM) as you do in IIS 4.0 in Windows NT 4.0. Open the ISM from the Start\Programs\/Administrative Tools folder. Select Properties for the virtual directory, and click the Directory Security tab.
The first security option is the authentication method, which controls the authentication of users who access the virtual directory against the server's security system. Screen 1 shows the Authentication Methods dialog box, which controls the various authentication methods. Select the Anonymous access check box, and click Edit. This option grants all users access to the virtual directory. After clicking Edit, you see the Anonymous User Account dialog box in which you select the account; the default account is IUSR_machinename.
The Basic authentication check box controls authorized access to the virtual directory. When you select this option, your browser uses clear-text transmission to send your user account and password to IIS 5.0. This feature is similar to Basic authentication in IIS 4.0, but with one small change: You can click Edit to display the Basic Authentication Domain dialog box, which lets you select the NT domain to authenticate users against. The default domain is the local NT domain. You can select any NT domain or other compatible domain to authenticate users against. This feature provides you with a way to control user access to Web applications by authenticating against any other OS's security system. Large organizations that have many Win2K systems, NT domains, and Novell NetWare systems will appreciate this feature.
The next option, Digest authentication for Windows domain servers, enables Digest authentication, which the Internet Engineering Task Force (IETF) defines in Request for Comments (RFC) 2069 (http://www.ietf.org/rfc/ rfc2069.txt). Digest authentication specifies the use of an encryption service to protect the user's password. Digest authentication sends a shared secret password rather than a user's password. This authentication works over TCP/IP, which lets it work through Microsoft proxy servers. Microsoft Internet Explorer (IE) 5.0 is among the few browsers that support Digest authentication, which is part of HTTP 1.1.
When a user navigates to a virtual directory with Digest authentication set, IIS 5.0 sends the browser a nonce value to challenge the browser. This request includes additional information that the browser uses in the encryption process. The browser adds the additional information that the server sends to the user ID and password and runs this string through a hash algorithm to generate a new value that the browser sends over the network. When the value that the browser sends is the same as the hash value that IIS 5.0 generates, Digest authentication authenticates the user and grants the user access to IIS resources.
When you enable Digest authentication, IIS 5.0 warns you to store account passwords in plain-text form. IIS 5.0 uses a plain-text password to generate the hashed value to compare with the browser's value. Digest authentication works because IIS 5.0 can discover the user's password on the server and the browser knows the password. IIS 5.0 compares the hash that the browser sends, without the browser or IIS having to send the password over the network.
Previous IIS versions called the last option, Integrated Windows authentication, the NT Challenge/Response authentication. This option enables the original NT Challenge/Response authentication protocol with IE 2.0 and later and lets you enable other authentication methods (e.g., Basic, Digest).
Other Security Options
IIS 5.0's Directory Security property page lets you set or change the IP address and domain-name-restrictions security settings, which work the same as the settings in IIS 4.0. The dialogs and settings are also the same.
IIS 5.0 changes the secure communications options. The software integrates Certificate Services directly with the options on the Directory Security property page. You can use the Server Certificate option to create requests for new certificates or to load an existing certificate. Clicking Server Certificate launches the Certificate Wizard, which walks you through the process of requesting or installing a certificate. Certificate Wizard is a nice change from IIS 4.0's Key Manager.
To set another level of security, you can place access permissions on a directory's files. You set the access security on the virtual directory's Directory Security property page, which opens by default when you open a site or virtual directory's properties.
IIS 5.0's directory permissions are similar to IIS 4.0's. A new directory permission in IIS 5.0, Script source access, determines whether users can view the source code for script files. When you select Script source access, you must also set Read or Write access.
To set NTFS permissions on a file or directory, you use Windows Explorer as you did in IIS 4.0. Screen 2 shows the Security properties for the MyResume.asp file. To easily change the permissions for users, select users from the Name list and change their permissions in the Permissions section. Screen 2 shows the settings after I modified the permissions for the anonymous account (IUSR_ABACO) to deny anonymous users access to the MyResume.asp file. This granularity level in setting permissions takes precedence over other settings. For instance, the virtual directory might have Read permissions, but the anonymous account can't read this file because of the access-denied settings at the file level.
You need to be careful when setting permissions directly on files that IIS hosts because you can interfere with other security settings of the Server Extensions. If you use NTFS to change the permissions, carefully test the application.
To stop an object from inheriting the permissions of its parent folder, clear the check box at the bottom of the property page. IIS 5.0 selects this check box by default.
Automating Security Settings
New features in Win2K and other Microsoft applications help you set IIS 5.0's new security settings without requiring you to sort through property pages. For the past 2 years, Microsoft has added application and OS wizards to help with setting security features. The Permissions Wizard automates the initial security settings for a virtual directory and creates a site in IIS 5.0. Using this wizard, you can set directory permissions and authentication security, and you can customize these options to fit your needs.
To start the Permissions Wizard, open the ISM, right-click the virtual directory that you want to set permissions on, select All tasks from the shortcut menu, and click Permissions Wizard. After the Permissions Wizard opens, click Next to see the Security Settings dialog box, which Screen 3 shows. This dialog box lists two options: Inherit all security settings and Select new security settings from a template.
Selecting Inherit all security settings and clicking Next displays the Windows Directory and File Permissions dialog box, which Screen 4 shows. This dialog box controls how to change the current permissions. The option Replace all directory and file permissions replaces the current permissions with new ones that you set in the Permissions Wizard. The option Leave current directory and file permissions intact, and add the recommended permissions doesn't change the current permissions but adds the new options you set in the wizard. The option Keep the current directory and file permissions doesn't make any changes to the NTFS directory and file permissions. After selecting an option, click Next to display the Security Summary list, which Screen 5 shows. Review the changes, click Next, then click Finish to apply the changes.
Selecting Select new security settings from a template in the Security Settings dialog box and clicking Next displays the Site Scenario dialog box, which Screen 6 shows. Select the scenario to apply, and click Next to display the Windows Directory and File Permissions page. The remaining steps are the same as when you select Inherit all security settings (the first option). After you click Finish, the Permissions Wizard automatically sets the security levels that the Security Summary dialog box shows. One-step configuration is nice when you need to quickly set the basic security options for a new virtual directory. After the wizard completes its work, adjust the settings to fit your needs.
The Security Foundation
Kerberos and Active Directory (AD) are the foundation for most security settings in Win2K, so IIS 5.0 can use both features to improve security. (See "Kerberos and NT 5.0," August 1997, and Michael E. Chacon, "How Kerberos Fits into the Windows NT 5.0 Security Model," October 1997, for more information about Kerberos.)
Security is a double-edged sword. Too little security gives the wrong people access to important information. Too much security forces you to spend all your time and CPU power managing and processing the security. Win2K and IIS 5.0 make working with security easier and give you more control over your systems.