User and Group Accounts
All Windows 2000 resources, including those accessed using a Web browser, are represented as either data or an application object that can be accessed only by authorized Windows 2000 services and users. Anyone accessing Internet Information Services does so in the context of a user account—that is, the user accesses resources by submitting to it the security credentials of a user account configured in Windows 2000.
Access to each object is controlled through an access control list (ACL), which is a list of user accounts and their access rights to the object. Every user of the server will have a user account. When you grant directory and file-level permissions through NTFS, the user account is added to the file or directory's ACL along with the permissions you grant to that user account. When a user wants to access an object, the system checks the user's security identifier (SID) associated with the user account that the user is logged on with and associated group memberships, and then compares these identities with the object's ACL to determine whether the user is allowed to complete the request.
The association of an ACL with a file or directory is possible only with the NTFS file system. For this reason, it is the recommended file system for all Windows 2000–based systems, especially those that host Web sites. Implementing NTFS on a partition gives administrators precise control over files and directories on the partition.
It is common practice—and is strongly recommended by Microsoft—that you assign permissions to groups rather than users. Generally, permissions are not given to individual user accounts because of the complexity in managing permissions this way. However, under some circumstances you may need to establish permissions for users. It is perfectly legitimate to do so (and even I do this on occasion), but you must always be mindful of exactly what you did so that you don't later experience security problems that either deny—or, worse, allow—access when you didn't intend to.
User accounts can also be further secured by strict password rules, solid policies, and an understanding of access tokens. The remainder of this section discusses these topics.
Passwords
The Internet is accessed by millions of users, only a fraction of whom are hackers. Still, there are way too many for you to not be concerned about the vulnerability of your passwords. Again, each account used by Internet Information Services is a Windows 2000 account. Your concern shouldn't just be with the security of Internet Information Services, but should be with the security of your entire system.
First, you should utilize the password generated by the system for the IUSR_computername account.Because this password is created using an algorithm, it is as difficult to guess as you can get. Change it only if your environment requires you, as the administrator, to know the password. For example, it may need to duplicate the IUSR_computername account on another server in your environment and allow them to reference each other by having the same password. For all other accounts, though, use common sense and standard strong passwords, which should have the following characteristics:
Logon Rights
Windows 2000 includes the capability to access a computer locally or remotely. Local users are also interactive users, typically those sitting at the console, but a local user can also be a service that runs from the local system. Remote users access the system from across the network using server message blocks (SMB).
When the Web service is started for a specific Web site, the service logs on to the Windows 2000 system by using the anonymous Web account. Because the Web service logs on to the local computer from the local computer, this access is considered local. Thus, the anonymous Web account must have permissions as an interactive user. Any account can be designated as an interactive account by modifying the Windows 2000 logon rights for that account or for a group to which that account belongs.
Because any user connecting to Internet Information Services is considered an interactive user, each account that is used to access a Web site must have logon rights to log on locally. Accounts that must have logon rights locally include those accessing a Web site through anonymous, basic or integrated Windows authentication. Also, as discussed in the next chapter, each account that is used to access an FTP site must have permissions as an interactive account.
Access Tokens
Each time an account logs on to a Windows 2000 system, it is given an access token, a set of properties that define its user ID, group memberships, and policies. This token is used for the entire session of an account logon and is presented to each object that the account needs to access. The properties of the access token are compared to the ACL of the object to determine whether the user should be granted access to the object.
When discussing Windows 2000 in a strict network environment, an access token is generated when a user account logs on to the system. When the logged on user attempts to access an object, this access token is compared to the ACL of the object. If the ACL for an object is changed while a user is logged on, then that the new security cannot be implemented because the user's access token is outdated. To flush the access token, the user must log off and log back on to the system (disconnect and reconnect).
When discussing Internet Information Services, the account used by the Web service to access the system is logged on when the Web service is started and is logged off when the service is stopped. The account used by the FTP service to access the system is logged on when a user logs in to the FTP service and is logged off when a user logs off the FTP service. Thus, the most efficient way to flush the access token for an account accessing either of these services is to stop and start the Web or FTP service.
Additional Password ProtectionYou cannot view the passwords of Windows 2000 user accounts. Recall that in Windows NT, all accounts appeared with 14 asterisks in the password field. Either way, not only are all passwords hidden from system administrators, but they are also disguised so that not even the number of characters can be determined. When viewing passwords typed directly into the IIS snap-in (to the MMC), the password is still hidden and always contains 10 asterisks in the password field. This is a nice, and more secure, change from Internet Information Server 4, where the number of asterisks actually represented the number of characters in the password. |
However, there are other occasions when the access token is flushed. By default, the access token used by the Web service is cached by the system for only 15 minutes. So, assume that you create a Web site that is rarely used. The anonymous Web account is configured as IUSR_Website1. When a user connects to the Web site from Internet Explorer, the account IUSR_Website1 logs on to the Web service. The user continues to surf the site for 10 minutes, still using the cached access token. After the user leaves the site, no other user connects for half an hour. After 15 minutes of no activity, the access token will expire, and a new one will have to be generated for the next user. However, if the Web site is busy, the access token can be cached indefinitely.
Access tokens are important in Internet Information Services because they modify permissions, either within IIS or within Windows 2000. For example, suppose that the user in the previous scenario tries to access a Web page that IUSR_Website1 does not have NTFS permissions to access. The user types the URL into Internet Explorer and receives the error message "Access Denied." You immediately modify the NTFS permissions to provide access to the file for the IUSR_Website1 account. However, the user is still not able to access the Web page, because his access token has now become outdated. You should stop and start the Web service for the Web site to generate a new access token and, thus, reflect the account's new permissions. The more global service, IIS, runs as a local system account and is not affected by this issue.
If 15 minutes seems either too long or too short a timeout period for your Web site, you can change the default cache setting by modifying the AccessTokenTTL registry entry.