Managing Windows Security | Microsoft IIS 6.0Administrator's Consultant

Before setting IIS security permissions, you use operating system security settings to do the following tasks:

Create and manage accounts for users and groups
Configure access permissions for files and folders
Set group policies for users and groups

Each of these topics is discussed in the sections that follow.

Working with User and Group Accounts

Microsoft Windows Server 2003 provides user accounts and group accounts. User accounts determine permissions and privileges for individuals. Group accounts determine permissions and privileges for multiple users.

IIS User and Group Essentials

You can set user and group accounts at the local computer level or at the domain level. Local accounts are specific to an individual computer and aren’t valid on other machines or in a domain unless you specifically grant permissions. Domain accounts, on the other hand, are valid throughout a domain, which makes resources in the domain available to the account. Typically, you’ll use specific accounts for specific purposes:

Use local accounts when your IIS servers aren’t part of a domain or you want to limit access to a specific computer.
Use domain accounts when the servers are part of a Windows domain and you want users to be able to access resources throughout that domain.

User accounts that are important on IIS servers include:

ASPNET A local user account used with ASP.NET. This account is used to run the ASP.NET worker process (aspnet_wp.exe) when the server is operating in IIS 5 isolation mode. The account grants the user the right to log on as a service or batch job but denies the right to log on locally or through Terminal Services.
Local System By default, all IIS and Indexing Service users log on using the local system account. This account has many access rights and privileges. The account grants the user the right to log on locally, as a service, or as a batch job. If you configure worker processes to use this account, those processes have full access to the server system.
Local Service A limited-privilege account that grants access to the local system only. The account grants the user the right to log on as a batch job. Configure worker processes to use this account only when the processes don’t need to access other servers.
Network Service When the server is running in IIS 6.0 worker process mode, Web applications use this account by default. This account provides fewer permissions and privileges than the Local System account but more than the Local Service account. Specifically, processes running under this account can log on as a service and can also access other servers using the current account credentials.
IUSR_ComputerName Internet guest account used by anonymous users to access Internet sites. The account grants the user the right to log on locally or as a batch job. If this account is disabled or locked out, anonymous users won’t be able to access Internet services. If this IIS server is in a domain, this account is a member of the Domain Users and Guests groups.
IWAM_ComputerName Web application account used with Web applications. The account grants the user the right to log on as a batch job. If this account is disabled or locked out and the server is running in IIS 5 isolation mode, out-of-process applications won’t be able to start. With IIS 6 worker process mode, this account is used only when configured for a specific application pool or pools. If this IIS server is in a domain, this account is a member of the Domain Users and IIS_WPG groups.

The IIS_WPG group is used with the Web application account (IWAM_ComputerName). This group is created at the local level and at the domain level (if applicable). At the local level, the members of this group are IWAM_ComputerName, Local Service, Network Service, and System.

Table 7-1 details key user rights assigned to IIS user and group accounts by default. You can make changes to these accounts if necessary. For added security, you can configure IIS to use different accounts from the standard accounts provided. You can also create additional accounts.

Table 7-1: Important User Rights Assigned by Default to IIS User and Group Accounts
Default User Right	ASPNET	Local Service	Network Service	IUSR	IWAM	IIS_WPG
Access this computer from the network	X	X	X	X	X	X
Adjust memory quotas for a process		X	X		X
Allow log on locally				X
Bypass traverse checking		X	X	X	X
Generate security audits		X	X
Impersonate a client after authentication	X					X
Log on as a batch job	X	X		X	X	X
Log on as a service	X		X
Replace a process- level token		X	X		X

Managing the IIS and Indexing Service Logon Accounts

The IIS and Indexing Service use the local system account to log on to the server. Using the local system account allows the services to run system processes and perform system-level tasks. You really shouldn’t change this configuration unless you have very specific needs or want to have strict control over the IIS logon account’s privileges and rights. If you decide not to use this account, you can reconfigure the logon account for IIS and Indexing Service by completing the following steps:

Start the Computer Management console. Click Start, then Administrative Tools, and finally Computer Management.
In the Computer Management console, connect to the computer whose services you want to manage.
Expand the Services And Applications node by clicking the plus sign (+) next to it and then select Services.
Right-click the service you want to configure and then choose Properties.
Select the Log On tab, as shown in Figure 7-1.

Figure 7-1: Use the Log On tab to configure the service logon account.
Select Local System Account if the service should log on using the system account (the default for most services).
Select This Account if the service should log on using a specific user account. Be sure to type an account name and password in the fields provided. Use the Browse button to search for a user account if necessary.

Click OK.

Note

If you don’t use the local system account, you’ll need to assign privileges and logon rights to the account you use. For more information on these and other account permissions, see Chapter 8, “Understanding User and Group Accounts,” in the Microsoft Windows Server 2003 Administrator’s Pocket Consultant (Microsoft Press, 2003).

Managing the Internet Guest Account

You manage the Internet Guest account at the IIS security level and at the Windows security level. At the IIS security level, you specify the user account to use for anonymous access. Normally, you manage anonymous access at the site level, and all files and directories within the site inherit the settings you use. You can change this behavior for individual files and directories as necessary.

To change the configuration of the anonymous user account for all Web sites and directories on a Web server, 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.

Select the Directory Security tab and then click Edit in the Authentication And Access Control frame.

Note

When Anonymous Access is enabled, users don’t have to log on using a user name and password. IIS automatically logs the user on using the anonymous account information provided for the resource. If the Enable Anonymous Access check box isn’t selected, the resource is configured for named account access only. You can enable anonymous access by selecting this check box. However, you should do this only if you’re sure the resource doesn’t need to be protected.

The Username field specifies the account used for anonymous access to the resource. If you desire, type the account name you want to use instead of the existing account or click Browse to display the Select User dialog box.
Leave the password blank. You don’t need to enter a specific password when anonymous access is enabled.
Click OK twice to save your changes.

To change the configuration of the anonymous user account at the site, directory, or file level, complete the following steps:

In the IIS snap-in, right-click the Web site, directory, or file you want to work with, and then choose Properties.
Follow steps 2 to 5 in the previous listing.

At the Windows security level you perform all other account management tasks, including:

Enabling or disabling accounts
Unlocking the account after it has been locked out
Changing group membership

Managing the Web Application Account

You manage the Web application account at the Windows security and IIS security levels. At the Windows security level you perform all other account management tasks for the Web application account. These tasks include the following:

Enabling or disabling the account
Unlocking the account after it has been locked out

Changing group membership

More Info

For details on working with user and group accounts, see Chapter 8, “Understanding User and Group Accounts,” Chapter 9, “Creating User and Group Accounts,” and Chapter 10, “Managing Existing User and Group Accounts,” in the Microsoft Windows Server 2003 Administrator’s Pocket Consultant.

At the IIS security level, you use the IIS snap-in to specify the account used by applications. Applications can all use the same account or you can assign different accounts as necessary to meet individual requirements. The management technique you use depends on the processing mode of IIS.

Updating the Web Application Account in IIS 6 Worker Process Mode

Once you’ve started the IIS snap-in, you can manage the account for pooled applications by completing the following steps:

Right-click Application Pools to manage the application account globally. Or right-click the specific application pool you want to work with.
On the shortcut menu, select Properties and then, in the Properties dialog box, select the Identity tab.
As shown in Figure 7-2, you can now use a predefined account or an account you’ve created as the application account.

Figure 7-2: Set the Web application account identity as Predefined or Configurable.
The drop-down list for predefined accounts has three options: Network Service, Local Service, and Local System. To use one of these accounts, select Predefined and then make the appropriate selection.
If you want to use a different account, choose Configurable. By default, the IWAM account is selected. If you want to use this account, you don’t need to do anything further. If you want to use a different account, type the account name you want to use instead of the existing account and enter the account password. If you don’t know the name of the account, click Browse to display the Select User dialog box. Afterward, you’ll need to enter the account password.
Click OK.

Updating the Web Application Account in IIS 5 Isolation Mode

Once you’ve started the Component Services snap-in from the Administrative Tools menu, you can manage the account for pooled applications by completing the following steps:

Expand the Component Services node by clicking the plus sign (+) next to it. You should now see the Computers node.
If you’re connecting to a remote computer, right-click Computers, choose New, and then select Computer. Type the name of the computer you want to manage and then click OK. If you don’t know the computer name, click Browse, and then use the Select Computer dialog box to select a computer.
Expand the node for the computer and then expand the COM+ Applications node.
Right-click IIS Out-Of-Process Pooled Applications, select Properties, and then select the Identity tab.
As shown in Figure 7-3 on the following page, you can now use a system account or an account you’ve created as the application account.

Figure 7-3: For IIS 5 isolation mode, set the Web application account identity in the Component Services snap-in.
The options for system accounts include: Interactive User (not recommended for security reasons), Local Service, Network Service, and Local System. To use one of these accounts, choose System Account and then make the appropriate selection.
If you want to use a different account, choose This User. By default, the IWAM account is selected. If you want to use this account, you don’t need to do anything further. If you want to use a different account, type the account name you want to use instead of the existing account and enter the account password. If you don’t know the name of the account, click Browse to display the Select User dialog box. Afterward, you’ll need to enter the account password.
Click OK.

Working with File and Folder Permissions

Every folder and file used by IIS can have different access permissions. You set these access permissions at the Windows security level. The sections that follow provide an overview of permissions. You’ll learn the basics, including how to view and set permissions.

File and Folder Permission Essentials

The basic permissions you can assign to files and folders are summarized in Table 7-2. The basic permissions are created by combining special permissions, such as traverse folder and execute file, into a single easily managed permission. If you want granular control over file or folder access, you can use advanced permissions to assign special permissions individually. For more information on special permissions, see Chapter 14, “Data Sharing, Security, and Auditing,” in the Microsoft Windows Server 2003 Administrator’s Pocket Consultant.

Table 7-2: File and Folder Permissions Used by Windows Server 2003
Permission	Meaning for Folders	Meaning for Files
Read	Permits viewing and listing files and subfolders	Permits viewing or accessing the file’s contents
Write	Permits adding files and subfolders	Permits writing to a file
Read & Execute	Permits viewing and listing files and subfolders as well as executing files; inherited by files and folders	Permits viewing and accessing the file’s contents as well as executing the file
List Folder Contents	Permits viewing and listing files and subfolders as well as executing files; inherited by folders only	N/A
Modify	Permits reading and writing of files and subfolders; allows deletion of the folder	Permits reading and writing of the file; allows deletion of the file
Full Control	Permits reading, writing, changing, and deleting files and subfolders	Permits reading, writing, changing, and deleting the file

Whenever you work with file and folder permissions, you should keep the following in mind:

Read is the only permission needed to run scripts. Execute permission applies only to executables.
Read access is required to access a shortcut and its target.
Giving a user permission to write to a file but not to delete it doesn’t prevent the user from deleting the file’s contents. A user can still delete the contents.
If a user has full control over a folder, the user can delete files in the folder regardless of the permission on the files.

IIS uses the following users and groups to configure file and folder access:

Administrators Allows administrators to access IIS resources.
Creator Owner Allows the account that created a resource to access the resource.
System Allows the local system to access the resource.
Users Allows named accounts to access the resource (including the Internet Guest and Web Application accounts, which are user accounts).
Internet Guest Account Allows you to set specific permission for IUSR or the other accounts you’ve configured as Internet guests. To prevent malicious users from gaining access to files and modifying them, you can deny this account Write permission on important directories.

When you grant Read permission to these users and groups, anyone who has access to your Internet or intranet Web site will be able to access the files and folders. If you want to restrict access to certain files and folders, you should set specific user and group permissions and then use authenticated access rather than anonymous access. With authenticated access, IIS authenticates the user before granting access and then uses the Windows permissions to determine what files and folders the user can access.

As you evaluate the permissions you might want to use for files and folders used by IIS, refer to Table 7-3. This table provides general guidelines for assigning permissions based on content type.

Table 7-3: General Guidelines for Permissions Based on Content Type
File Type	File Extension	Permission
CGI scripts and executables	.exe, .dll, .cmd	Users (Execute) Administrators (Full Control) System (Full Control)
Dynamic content	.asp, .aspx, .vbs, .js, .pl	Users (Read Only) Administrators (Full Control) System (Full Control)
Include files	.inc, .shtm, .shtml, .stm	Users (Read Only, Deny Write) Administrators (Full Control) System (Full Control)
Static content	.txt, .rtf, .gif, .jpg, .jpeg, .htm, .html, .doc, .ppt, .xls	Users (Read Only, Deny Write) Administrators (Full Control) System (Full Control)

Instead of setting permissions on individual files, you should organize content by type in subdirectories. For example, if your Web site used static, script, and dynamic content, you could create subdirectories called WebStatic, WebScripts, and WebDynamic. You would then store static, script, and dynamic content in these directories and assign permissions on a per directory basis. Don’t forget to consider whether it’s prudent to specifically deny Write permission.

Viewing File and Folder Permissions

You view security permissions for files and folders by completing the following steps:

In Windows Explorer, right-click the file or folder you want to work with.
From the shortcut menu, select Properties, and then, in the Properties dialog box, select the Security tab.
In the Group Or User Names list box, select the user, contact, computer, or group whose permissions you want to view. If check boxes in the Permissions For list are dimmed, it means the permissions are inherited from a parent object.

Setting File and Folder Permissions

You can set permissions for files and folders by completing the following steps:

In Windows Explorer, right-click the file or folder you want to work with.
From the shortcut menu, select Properties, and then, in the Properties dialog box, select the Security tab, shown in Figure 7-4.

Figure 7-4: Use the Security tab to configure basic permissions for the file or folder.

Users or groups that already have access to the file or folder are listed in the Group Or User Names list box. You can change permissions for these users and groups by doing the following:

Select the user or group you want to change.

Use the Permissions For list box to grant or deny access permissions.

Note

Inherited permissions are dimmed. If you want to override an inherited permission, select the opposite permission. For example, if a user is granted a permission you don’t want them to have due to inheritance, you could override the inheritance by explicitly denying the permission in the Permissions For list box.

Click Add to set access permissions for additional users, contacts, computers, or groups. This displays the Select Users, Computers, Or Groups dialog box. You can select computer accounts and configure their permissions only if you are part of a domain.
Use the Select Users, Computers, Or Groups dialog box to select the users, computers, or groups for which you want to set access permissions. Click OK.
In the Group Or User Names list box, select the user, computer, or group you want to configure, and then use the fields in the Permissions For list box to allow or deny permissions. Repeat for other users, computers, or groups.
Click OK when you’re finished.

Working with Group Policies

Group policies are another aspect of Windows security that you need to understand. You’ll use group policies to automate key security administration tasks and to manage IIS resources more effectively. Site, domain, and organizational unit group policies can be configured only for computer, group, and user accounts that are part of a domain.

Group Policy Essentials

Group policies provide central control over privileges, permissions, and capabilities of users and computers. You can think of a policy as a set of rules that you can apply to multiple computers and to multiple users. Because computers can be a part of larger organizational groups, you can apply multiple policies. The order in which policies are applied is extremely important in determining which rules are enforced and which rules are not.

When multiple policies are in place, the policies are applied in the following order:

Windows NT 4 policies from Ntconfig.pol files
Local group policies that affect the local computer only
Site group policies that affect all computers that are part of the same site, which can include multiple domains
Domain polices that affect all computers in a specific domain
Organizational unit policies that affect all computers in an organizational unit
Child organizational unit policies that affect all computers in a subcomponent of an organizational unit

As successive policies are applied, the rules in those policies override the rules set in the previous policy. For example, domain policy settings have precedence over the local group policy settings. Exceptions allow you to block, override, and disable policy settings; a discussion of exceptions is outside the scope of this book.

Policy settings are divided into two broad categories: those that affect computers and those that affect users. Computer policies are applied during system startup. User policies are applied during logon. You configure and manage policies for sites, domains, and organizational units with the Group Policy snap-in. To access this snap-in, follow these steps:

For sites, start the Active Directory Sites And Services console from the Administrative Tools menu.
For domains, start the Active Directory Users And Computers console from the Administrative Tools menu.
In the console root, right-click the site, domain, or organizational unit in which you want to create or manage a group policy. Then, from the shortcut menu, select Properties. This opens a Properties dialog box.
In the Properties dialog box, select the Group Policy tab. As Figure 7-5 shows, existing policies are listed in the Group Policy Object Links list.

Figure 7-5: Use the Group Policy tab of the Properties dialog box to create and edit policies.
You can now create a new policy, edit an existing policy, or change the priority of a policy as follows:
- To create a new policy, click New. You can now configure the policy.
- To edit an existing policy, select the policy and then click Edit. You can now edit the policy.
- To change the priority of a policy, use the Up or Down button to change its position in the Group Policy Object Links list.

You manage local group policies for an individual computer by completing the following steps:

Open the Run dialog box by clicking Start and then clicking Run.
Type MMC in the Open field and then click OK. This opens the Microsoft Management Console (MMC).
In the MMC, click File, and then click Add/Remove Snap-In. This opens the Add/Remove Snap-In dialog box.
In the Standalone tab, click Add.
In the Add Standalone Snap-In dialog box, click Group Policy Object Editor and then click Add. This opens the Select Group Policy Object dialog box.
Click Finish to edit the local policy on your computer or Browse to find the local policy on another computer.
Click Close, and then click OK.
You can now manage the local policy on the selected computer.

Group policies for passwords, account lockout, and auditing are essential to your Web server’s security. Guidelines for password policies are as follows:

Set a minimum password age for all accounts. I recommend 2-3 days.
Set a maximum password age for all accounts. I recommend 30 days.
Set a minimum password length. I suggest the minimum be set at eight characters to start.
Enable secure passwords by enforcing password complexity requirements.
Enforce password history. Use a value of 5 or more.

Guidelines for account lockout polices include the following:

Set an account lockout threshold. In most cases accounts should be locked after five bad attempts.
Set account lockout duration. In most cases you’ll want to lock out accounts indefinitely.
Reset the lockout threshold after 30 to 60 minutes.

Guidelines for auditing include the following:

Audit system event success and failure
Audit logon event success and failure
Audit failed object access attempts
Audit successful and failed policy changes
Audit successful and failed account management
Audit successful and failed account logon

Techniques for managing these policies are examined in the sections that follow. For more detailed information on policy management, see Chapter 4, “Automating Administrative Tasks, Policies, and Procedures,” in Microsoft Windows Server 2003 Administrator’s Pocket Consultant.

Setting Account Policies for IIS Servers

You can set account policies by completing the following steps:

Access the group policy container you want to work with as described in the section of this chapter entitled “Working with Group Policies.” Expand the Computer Configuration node, then Windows Settings, then Security Settings, and finally Account Policies.
As shown in Figure 7-6, you can now manage account policies. For domains, sites, and organizational units, you’ll have Password Policy, Account Lockout Policy, and Kerberos Policy nodes. For local computers, you’ll have Password Policy and Account Lockout Policy nodes only.

Figure 7-6: Set policies for passwords and general account use.
To configure a policy, double-click its entry or right-click it and select Properties. This opens a Properties dialog box for the policy.
For a local policy, the Properties dialog box is similar to the one shown in Figure 7-7 on the following page. The policy for the computer is displayed. Use the fields provided to configure the local policy. Skip the remaining steps; they apply to global group policies.

Figure 7-7: With local policies, you’ll see the current policy setting.
For a site, domain, or organizational unit, the Properties dialog box is similar to the one shown in Figure 7-8.

Figure 7-8: Define and configure global group policies using the Properties dialog box.
All policies are either defined or not defined—that is, they’re either configured for use or not configured for use. A policy that isn’t defined in the current container could be inherited from another container.
Select or clear the Define This Policy Setting check box to determine whether a policy is defined.
Policies can have additional fields for configuring the policy. Often, these fields have the following option buttons:
- Enabled Turns on the policy restriction
- Disabled Turns off the policy restriction

Setting Auditing Policies

Auditing is the best way to track what’s happening on your IIS server. You can use auditing to collect information related to resource usage, such as file access, system logon, and system configuration changes. Whenever an action occurs that you’ve configured for auditing, the action is written to the system’s security log, where it’s stored for your review. You access the security log from Event Viewer.

You can set auditing policies by completing the following steps:

Access the group policy container you want to work with as described in the section of this chapter entitled “Working With Group Policies.” Expand the Computer Configuration node, Windows Settings, Security Settings, and Local Policies. Then select Audit Policy.
You can now have access to the following auditing options:
- Audit Account Logon Events Tracks events related to user logon and logoff.
- Audit Account Management Tracks account management. Events are generated anytime user, computer, or group accounts are created, modified, or deleted.
- Audit Directory Service Access Tracks access to the Active Directory service. Events are generated whenever users or computers access the directory.
- Audit Logon Events Tracks events related to user logon, logoff, and remote connections to network systems.
- Audit Object Access Tracks system resource usage for files, directories, shares, printers, and Active Directory objects.
- Audit Policy Change Tracks changes to user rights, auditing, and trust relationships.
- Audit Privilege Use Tracks the use of user rights and privileges, such as the right to back up files and directories, but doesn’t track system logon or logoff.
- Audit Process Tracking Tracks system processes and the resources they use.
- Audit System Events Tracks system startup, shutdown, and restart, as well as actions that affect system security or the security log.
To configure an auditing policy, double-click its entry or right-click it and select Properties. This opens a Properties dialog box for the policy.
Select Define These Policy Settings, and then select the Success check box, the Failure check box, or both. Success logs successful events, such as successful logon attempts. Failure logs failed events, such as failed logon attempts.
Click OK when you’re finished.