Managing IIS Security | Microsoft IIS 6.0Administrator's Consultant

After setting operating system security, use IIS security to:

Set the Web server and execute permissions for content
Configure Web Distributed Authoring and Versioning (WebDAV)
Configure authentication methods
Control access by IP address or Internet domain name

Each of these topics is discussed in the sections that follow. It’s important to note that IIS 6 doesn’t use the concept of Web site operators.

Setting Web Server Permissions

Sites, directories, and files have permissions in IIS in addition to the Windows security settings. These permissions are set the same for all users. This means you can’t set different permissions for different users at the Web content level. You can, however, create secure areas of your Web site and then use Windows file and folder permissions to provide the necessary additional controls.

Understanding Web Server Permissions

The permissions you assign to Web content are applied in combination with the authentication methods and access restrictions currently being enforced for the resource. This means that user requests must meet the requirements for Web content permissions, authentication, and access before they’re executed. Keep in mind that all directories and files within the site inherit permissions set at the site level and that you can override site-level permissions by setting permissions on individual directories and files.

Web server permissions also set the permissible actions for Web Distributed Authoring and Versioning (WebDAV). WebDAV publishing allows remote users to publish, lock, and manage resources on a Web server through a Hypertext Transfer Protocol (HTTP) connection. Windows 2000, Microsoft Office 2000, and Internet Explorer 5 or later are all WebDAV-enabled. If you have WebDAV- enabled applications, use Web server permissions to determine permitted actions for these applications and their users. You’ll find more detailed information on WebDAV in the “Configuring Distributed Authoring and Versioning” section of this chapter.

You can set Web server permissions in two ways:

Globally You configure global permissions using the Web Sites Properties dialog box. When you set Web server permissions globally, you must also specify how these properties are inherited. When a site or directory has settings that conflict with permission changes you’ve made, you’re given the opportunity to override the site or directory permissions with the global permissions. If you override permissions, the global permissions are applied to the site or directory and its contents. If you don’t override permissions, the original settings for the site or directory are maintained.
Locally You configure local permissions at the site, directory, or file level. As with global permissions, local permissions for sites and directories can be inherited. Because of this, when you make permission changes that conflict with existing permissions on a subdirectory, you’re given the opportunity to override the site or directory permissions with the local permissions. If you override permissions, the local permissions are applied to the site or directory and its contents. If you don’t override permissions, the original settings for the site or directory are maintained.

IIS manages inheritance of permissions changes at the node level. Because of this, the top-level directory for a site and the individual directories within a site are seen as separate nodes. If you apply changes to a site node, the permissions are applied to the site’s root folder and to files in this folder. Changes aren’t applied to subdirectories within the site unless you specify that they should be.

Setting Web Server Permissions Globally

To manage Web server permissions globally, complete the following steps:

In the IIS snap-in, right-click the Web Sites node and then select Properties. This displays a Properties dialog box.

As shown in Figure 7-9 on the following page, select the Home Directory tab, and then use the following fields to set the Web server permissions that you want sites and directories on this computer to inherit:

click to expand
Figure 7-9: Manage Web server permissions globally using the Home Directory tab on the Web Sites Properties dialog box.

Script Source Access Allows users to access source code, including scripts in Active Server Pages (ASP). This option is available only when Read permission is also selected. If Write permission is also selected, users will be able to write to the source file.

Note

Be careful when granting Script Source Access on production servers that are on the Internet. With this permission, anyone will be able to read the contents of your scripts, and this might open your servers to mischievous users. Because of this, you should enable this feature only in a directory that requires users to authenticate themselves before being granted access.

Read Allows users to view the resource. For a directory, this grants the user access to the directory. For a file, this means the user can read the file and display it.

Write Allows users to change the resource. For a directory, this allows the user to create or publish files. For a file, this allows the user to change the content.

Note

You should grant Write permission to only a limited number of resources. If possible, you should create separate subdirectories that contain only writeable files, or you should write-enable individual files rather than entire directories. To execute application files, you must assign Read permission to all files used by the application or to the site or directory used to store these files. If the application posts content to a file on the site, you must also assign Write permission (but you should limit this to a specific file or directory).

Directory Browsing Allows users to view a list of files and subdirectories within the designated directory.
Log Visits Used with server logging to log requests related for resource files.
Index This Resource Allows the Indexing Service to index the resource. Indexing allows users to perform keyword searches for information contained in the resource.

If the selected resource is part of an IIS application, you might also want to set the level of program execution that’s allowed for the application. To do this, use the Execute Permissions selection list to choose one of the following options:
- None Only static files, such as .html or .gif files, can be accessed.
- Scripts Only Only scripts, such as ASP scripts, can be run.
- Scripts And Executables All file types can be accessed and executed.
Click Apply. Before applying permission changes, IIS checks the existing permissions in use for all Web sites and directories within Web sites. Each time a site or directory node uses a different value for a permission, an Inheritance Overrides dialog box is displayed. Use this dialog box to select the site and directory nodes, which should use the new permission value, and then click OK.

Setting Web Server Permissions Locally

To set content permissions for a site, directory, or file, complete the following steps:

In the IIS snap-in, right-click the site, directory, or file that you want to work with and then select Properties.

Select the Home Directory, Directory, or Virtual Directory tab as appropriate. This displays the dialog box shown in Figure 7-10 on the following page. Then use the following fields to set the permissions for the selected resource:

Note

Read Allows users to view the resource. For a directory, this grants the user access to the directory. For a file, this means the user can read the file and display it.

Write Allows users to change the resource. For a directory, this allows the user to create or publish files. For a file, this allows the user to change the content.

Note

Directory Browsing Allows users to view a list of files and subdirectories within the designated directory.
Log Visits Used with server logging to log requests related for resource files.
Index This Resource Allows the Indexing Service to index the resource. Indexing allows users to perform keyword searches for information contained in the resource.

Figure 7-10: Manage permissions for individual sites, virtual directories, and files using the Properties dialog box for that site, virtual directory, or file.

If the selected resource is part of an IIS application, you might also want to set the level of program execution that’s allowed for the application. To do this, use the Execute Permissions selection list to choose one of the following options:
- None Only static files, such as .html or .gif files, can be accessed.
- Scripts Only Only scripts, such as ASP scripts, can be run.
- Scripts And Executables All file types can be accessed and executed.
Click Apply. Before applying permission changes, IIS checks the existing permissions in use for all sites and directories within the site you are working with. Each time a site or directory node uses a different value for a permission, an Inheritance Overrides dialog box is displayed. Use this dialog box to select the site and directory nodes, which should use the new permission value, and then click OK.

Configuring Distributed Authoring and Versioning

WebDAV is an extension to the HTTP 1.1 protocol that allows remote users to manage Web server resources. Using WebDAV, clients can:

Perform standard file operations, such as cut, copy, and paste
Create and edit files and their properties at the operating system level
Create and edit directories and their properties at the operating system level
Lock and unlock resources to allow only one person to modify a resource while allowing multiple users to read the resource
Search the contents and properties of files in a directory

Because WebDAV is integrated into IIS, all Web site directories on your IIS server are accessible for distributed authoring and versioning. This makes it easy to access and publish documents to your IIS server.

Permitting Distributed Authoring and Versioning

You control the permitted actions for WebDAV application using the standard Web server permissions. The Web server permissions that are directly applicable to WebDAV are:

Script Source Access Allows WebDAV clients to download source files for scripts.
Read Allows WebDAV clients to view and run files and subdirectories within the WebDAV directory.
Write Allows WebDAV clients to create files or directories and to write to existing files.
Directory Browsing Allows WebDAV clients to view the contents of directories.
Index This Resource If your Web server is running the Indexing Service, WebDAV clients can search the directory using special search utilities.

To publish to a directory and see a list of files in that directory, users need Read, Write, and Browse access permissions. If users need to update script files, you must also grant Script Source Access permission. To protect your Web content, you should grant these permissions only in directories that require users to authenticate themselves. For example, you could create a directory called For Publishing, configure permissions on this directory so that anonymous access isn’t allowed, and then configure the necessary authoring and publishing permissions (Read, Write, and Browse).

When you allow script source access, you need to ensure that your source code and executables are protected. Any extension designated in the application mappings for the site is considered a script source file. Files with extensions that aren’t mapped are treated as static .html or text files. Files with the .dll or .exe extension are also treated as static files, unless the Scripts And Executables permission is set, which means they could be overwritten even if Script Source Access isn’t enabled. When the Scripts And Executables permission is set, .dll and .exe files aren’t treated as static files—they’re treated as executable files, and they can only be overwritten when Script Source Access is enabled.

Accessing and Publishing Documents with WebDAV

Windows 2000 or later and Office 2000 and later products are all WebDAV- enabled, and you can connect to Web directories on IIS servers quite easily. In Windows Explorer, select My Network Places and then click the Web directory you want to work with. If the directory isn’t shown, you can connect to it by completing the following steps:

In Windows Explorer, select My Network Places and then double-click Add Network Place in the right pane. This starts the Add Network Place Wizard. Click Next.
After the wizard gathers the necessary information, ensure Choose Another Network Location is selected and then Click Next again.
In the Add Network Place Wizard, type a Universal Naming Convention (UNC) path of the WebDAV directory to which you want to connect, such as \\Corpserver01\CorpWWW, or a Uniform Resource Locater (URL) path, such as http://www.adatum.com/CorpWWW or ftp://ftp.adatum.com/CorpFTP
Click Next, type a descriptive name for the directory, and then click Next again.
Click Finish. Windows automatically accesses the directory.

Once you’ve created a network place for the WebDAV directory, you can easily publish documents to it from Office 2000 or later. Simply create a document in any Office application and then follow these steps:

Select Save As from the File menu and then, in the left column of the Save As dialog box, click My Network Places.
Select the shortcut for the WebDAV directory you want to use or type the UNC path, and then click OK.

You can also connect to WebDAV directories through Internet Explorer 5 on Windows 95 or later operating systems. Simply complete the following steps:

Start Internet Explorer 5 or later, and then display the Open dialog box by selecting Open from the File menu.
In the Open combo box, type the UNC path for the WebDAV directory to which you want to connect.
Select the Open As Web Folder check box and then click OK.

Setting Authentication Modes

Authentication modes control access to IIS resources. You can use authentication to allow anonymous access to public resources, to create secure areas within a Web site, and to create controlled access Web sites. When authentication is enabled, IIS uses the account credentials supplied by a user to determine whether or not the user has access to a resource and to determine which permissions the user has been granted.

Understanding Authentication

Five authentication modes are available. These modes are:

Anonymous Authentication With anonymous authentication, IIS automatically logs users on with an anonymous or guest account. This allows users to access resources without being prompted for user name and password information.
Basic Authentication With basic authentication, users are prompted for logon information. When it’s entered, this information is transmitted unencrypted (clear text) across the network. If you’ve configured secure communications on the server as described in the “Working with SSL” section of Chapter 8, “Managing Microsoft Certificate Services and SSL,” you can require clients to use Secure Sockets Layer (SSL). When you use SSL with basic authentication, the logon information is encrypted before transmission.
Integrated Windows Authentication With integrated Windows authentication, IIS uses standard Windows security to validate the user’s identity. Instead of prompting for a user name and password, clients relay the logon credentials that users supply when they log on to Windows. These credentials are fully encrypted without the need for SSL, and they include the user name and password needed to log on to the network. Only Internet Explorer browsers support this feature.
Digest Authentication With digest authentication, user credentials are transmitted securely between clients and servers. Digest authentication is a feature of HTTP 1.1 and uses a technique that can’t be easily intercepted and decrypted. This feature is available only when IIS is configured on a Windows Server 2003 server, and part of a Windows 2000 Server, or later, Active Directory domain. The client is required to use a domain account, and the request made by Internet Explorer 5.0 or later.
.NET Passport authentication With .NET Passport authentication, the user credentials aren’t checked directly. Instead, the server checks for a Passport Authentication ticket as one of the cookie files on the user’s computer. If the ticket exists and has valid credentials, the server authenticates the client. If the ticket doesn’t exist or the credentials aren’t valid, the user is redirected to the Passport Logon Service. Once the user logs on to the Passport service, the user is directed back to the original URL.

By default, both anonymous authentication and Integrated Windows Authentication are enabled for IIS resources. Because of this, the default authentication process looks like this:

IIS attempts to access the resource using the Internet Guest account. If this has the appropriate access permissions, the user is allowed to access the resource.
If validation of the credentials fails or the account is disabled or locked, IIS attempts to use the user’s current account credentials. If the credentials can be validated and the user has the appropriate access permissions, the user is allowed to access the resource.
If validation fails or the user doesn’t have appropriate access permissions, the user is denied access to the resource.

As with Web server permissions, you can apply authentication on a global or local basis. You configure global authentication modes using the master Web Sites Properties. You set local authentication modes using site, directory, or file properties. Anytime you make changes that conflict with existing settings, IIS displays a dialog box that allows you to specify which resources inherit the new settings.

Before you start working with authentication modes, you should keep the following in mind:

When you combine anonymous access with authenticated access, users have full access to resources that are accessible to the Internet Guest account. If this account doesn’t have access to a resource, IIS attempts to authenticate the user using the authentication techniques you’ve specified. If these authentication methods fail, the user is denied access to the resource.
When you disable anonymous access, you’re telling IIS that all user requests must be authenticated using the authentication modes you’ve specified. Once the user is authenticated, IIS uses the user’s account credentials to determine access rights.
When you combine basic authentication with integrated or digest authentication, Internet Explorer attempts to use integrated Windows authentication or digest authentication before using basic authentication. This means users who can be authenticated using their current account credentials won’t be prompted for a user name and password.

In addition, before you can use digest authentication, you must enable reversible password encryption for each account that will connect to the server using this authentication technique. IIS and the user’s Web browser use reversible encryption to manage secure transmission and unencryption of user information. To enable reversible encryption, follow these steps:

Start Active Directory Users And Computers. Click Start, choose Administrative Tools, and then Active Directory Users And Computers.
Double-click the user name that you want to use with digest authentication.
On the Account tab, under Account Options, select Store Password Using Reversible Encryption.
Click OK.
Repeat steps 1 to 4 for each account that you want to use with digest authentication.

Enabling and Disabling Authentication

You can enable or disable anonymous access to resources at the server, site, directory, or file level. If you enable anonymous access, users can access resources without having to authenticate themselves (provided the Windows permissions on the resource allow this). If you disable anonymous access, users must authenticate themselves before accessing resources. Authentication can occur automatically or manually depending on the browser used and the account credentials the user previously entered.

You can enable or disable authentication at the server level by completing the following steps:

In the IIS snap-in, right-click the Web Sites node and then select Properties. This displays a Properties dialog box.
Select the Directory Security tab and then click Edit in the Authentication And Access Control frame. This displays the Authentication Methods dialog box shown in Figure 7-11.

Figure 7-11: Use the Authentication Methods dialog box to enable or disable authentication methods to meet your organization’s needs. With basic authentication, it’s often helpful to set a default domain as well.
To enable anonymous access, select the Enable Anonymous Access check box. To disable anonymous access, clear this check box.
Configure the authentication methods you want to use. Keep the following in mind:
- Disabling basic authentication might prevent some clients from accessing resources remotely. Clients can log on only when you enable an authentication method that they support.
- A default domain isn’t set automatically. If you enable basic or .NET Passport authentication, you can choose to set a default domain that should be used when no domain information is supplied during the logon process. Setting the default domain is useful when you want to ensure that clients authenticate properly.
- With basic and digest authentication, you can optionally define the realm or realms that can be accessed. Essentially, a realm is a level within the metabase hierarchy. The default realm name is the computer name, which provides access to all levels within the metabase hierarchy. You could limit this by defining specific realms, such as W3SVC (for the Web Sites root) or W3SVC/1/root (for the root of the first Web instance).
- If you enable .NET Passport authentication, all other authentication settings are ignored. As a result, the server will only authenticate using this technique for the specified resource.
Click OK. Before applying changes, IIS checks the existing authentication methods in use for all Web sites and directories within Web sites. If a site or directory node uses a different value, an Inheritance Overrides dialog box is displayed. Use this dialog box to select the site and directory nodes that should use the new setting, and then click OK.

You can enable or disable authentication at the site, directory, or file level by completing these steps:

In the IIS snap-in, right-click the site, directory, or file that you want to work with and then select Properties. This displays a Properties dialog box.
Select the Directory Security tab and then click Edit in the Authentication And Access Control frame. This displays the Authentication Methods dialog box shown previously in Figure 7-11.
Follows steps 3-5 as listed in the previous procedure.

Configuring IP Address and Domain Name Restrictions

By default, IIS resources are accessible to all IP addresses, computers, and domains, which presents a security risk that might allow your server to be misused. To control use of resources, you might want to grant or deny access by IP address, network ID, or domain. As with other Web server settings, you can apply restrictions through the master Web Sites properties or through the properties for individual sites, directories, and files.

Granting access allows a computer to make requests for resources but doesn’t necessarily allow users to work with resources. If you require authentication, users still need to authenticate themselves.
Denying access to resources prevents a computer from accessing those resources. Therefore, users of the computer can’t access the resources—even if they could have authenticated themselves with a user name and password.

You can establish or remove restrictions globally through the Web Sites node by completing the following steps:

In the IIS snap-in, right-click the Web Sites node and then select Properties. This displays a Properties dialog box.
Select the Directory Security tab and then click Edit in the IP Address And Domain Name Restrictions frame This displays the IP Address And Domain Name Restrictions dialog box shown in Figure 7-12.

Figure 7-12: You can grant or deny access by IP address, network ID, and domain.
Select Granted Access to grant access to all computers and deny access to specific computers, groups of computers, or domains.
Select Denied Access to deny access to all computers and grant access to specific computers, groups of computers, or domains.

Create the Access list. Click Add and then, in the Access dialog box, specify Single Computer, Group Of Computers, or Domain Name. The settings you can specify for each option are as follows:

For a single computer, type the IP address for the computer, such as 192.168.5.50.
For groups of computers, type the subnet address, such as 192.168.0.0, and the subnet mask, such as 255.255.0.0.

For a domain name, type the fully qualified domain name (FQDN), such as eng.microsoft.com.

Note

When you grant or deny by domain, IIS must perform a reverse Domain Name System (DNS) lookup on each connection to determine whether the connection comes from the domain. These reverse lookups can severely increase response times for the first query each user sends to your site.

If you want to remove an entry from the Access list, select the related entry in the Access list and then click Remove.
Click Apply.

You can establish or remove restrictions at the site, directory, or file level by completing these steps:

In the IIS snap-in, right-click the site, directory, or file that you want to work with and choose Properties. This displays a Properties dialog box.
Select the Directory Security tab and then click Edit in the IP Address And Domain Name Restrictions frame. This displays the IP Address And Domain Name Restrictions dialog box shown previously in Figure 7-12.
Select Granted Access to grant access to all computers and deny access to specific computers, groups of computers, or domains.
Select Denied Access to deny access to all computers and grant access to specific computers, groups of computers, or domains.
Create the Access list. Click Add and then, in the Access dialog box, specify Single Computer, Group Of Computers, or Domain Name. The settings you can specify for each option are as follows:
- For a single computer, type the IP address for the computer, such as 192.168.5.50.
- For groups of computers, type the subnet address, such as 192.168.0.0, and the subnet mask, such as 255.255.0.0.
- For a domain name, type the FQDN, such as eng.microsoft.com.
If you want to remove an entry from the Access list, select it and then click Remove.
Click Apply.