By Susan Harkins and Drew Wutka
Because preventing unauthorized access to your valuable data is just as important as ensuring that legitimate users have quick and easy access, Web site security has risen to the top of every Web developer's priority list. Fortunately, you can apply NT Security to Microsoft Internet Information Services (IIS) to meet both of these requirements. IIS Servers host a variety of security methods, all based on NT Security Accounts. If IIS security is new to you, this article will help you decide which method or methods will work best for you and your clients.
An overview of NT Security
Microsoft developed NT Security for NT-based operating systems. Within this system, you'll find three security systems currently in use:
- NT 4.0 Domain Security: NT 4.0 Domain is a centralized security system. Domain Users and Groups are created and authenticated from centralized locations. To access the network resources, users must possess the permissions through their user account or belong to a domain group with the necessary permissions.
- Active Directory: This is the generation following NT 4.0 Domain Security. Active Directory is the domain system for Windows 2000 Server and Windows Server 2003. It's similar to NT 4.0 Domain Security but offers more bells and whistles.
- Local Users and Groups: Unless your IIS Server is also a domain controller or a controlling computer on an Active Directory Domain, it will allow you to create local users and groups that can be used by an IIS Server's security.
One of the most important aspects of NT Security is how it authenticates each user. Many less powerful security systems store user names and passwords locally, which could allow a hacker to decrypt security settings on the local machine. NT Security never actually stores the password. When a user logs onto a computer by entering a user name and password, the computer creates a hash consisting of the user's information (user name, password, and domain name) and sends the encrypted hash through the network lines to be approved by a domain controller. When there's a match, the domain controller sends the local computer what's known as a token. Think of a token as a key that unlocks the door to various files and other resources that the user needs.
Four ways to secure a Web site
An IIS Web site can use one of four types of user security:
- Anonymous Access
- Basic Authentication
- Integrated Windows Authentication
- Digested Authentication For Windows Domain Servers
You can access these options by clicking a Web site's properties (or right-clicking a Web page and selecting Directory Security from the resulting submenu). Click the Anonymous Access And Authentication control's Edit button to display the authentication methods for a Windows 2000 Server machine, as shown in Figure A.
|There are four authentication methods.|
Anonymous Access is the most common method, and it works just like it sounds: Anyone can gain access. When a user hits a Web page, the IIS Server reviews the settings for that particular page. When the Anonymous Access setting is enabled, the IIS Server creates a token using the login credentials supplied in the IIS Server's settings. The user then has the same permissions as the Anonymous User account.
For example, if the Anonymous User account lends read-only privileges, the user can view the page but nothing more. If the Anonymous User account has read/write privileges, the user can modify the page.
The advantage of Anonymous Access is that the end user doesn't have to log on to your site. This is the obvious choice when allowing users access to unrestricted areas. You must set a method of user authentication so that the IIS Server will know who to impersonate when accessing the resources on the system (or the rest of the network). Anonymous Access can access resources not directly located on the IIS Server, but the Anonymous Access account must be a domain account with the appropriate permissions.
It's important to note that when using Anonymous Access, IIS will create a generic Anonymous Access account. We strongly recommend that you create your own and not use the generic account, because hackers can use the predefined account to gain access to your system.
Basic Authentication forces the user to log on to the Web site with a valid user name and password. It comes at a cost, because the user name and password are sent through network lines with no encryption. IIS warns the user, but that isn't much consolation. Despite the possible security hole, a few advantages make this option worth considering under the right circumstances:
- Web pages that use Basic Authentication can include the user name and password in the URL, using the form: http://MyUserName:MyPassword@www.MyWebsite.com. This feature can be handy for sending hyperlinks that automatically log on to a site.
- You can determine who is visiting a Web page using ASP's Request Object's ServerVariables collection. Not only can you grab the user's NT user name, but you can also get the password that's used to access your Web site.
- Basic Authentication allows for the use of network resources not located on the Web server itself. (Anonymous Access also provides this capability.)
Integrated Windows Authentication
Integrated Windows Authentication is similar to NT Security in that the user name and password aren't sent through the network lines as plain text. Instead, the user's machine creates a hash and then sends it through the network lines, which is a more secure method than Basic Authentication. Unfortunately, it has one major disadvantage. The method used to create a token to use the Web server's resources is good only for the local resources on the Web server. For example, if a database is on a network server other then the IIS Server, a Web site can't access the database.
Similar to Basic Authentication, the user name is available through ASP, but the password isn't. If the user logs on with a valid Windows Authentication account, Integrated Windows Authentication can rely on the user's credentials. As a result, you can secure your Web pages without forcing users to log on. Sending the logged-on user's credentials automatically is a setting within Internet Explorer's site security.
Digested Authentication For Windows Domain Servers
This method is a combination of Integrated Windows Authentication and Basic Authentication. It allows for the use of network resources off the IIS Server, just like Basic Authentication, but it also sends encrypted hashes through the network/Internet lines, like Integrated Windows Authentication does.
Unfortunately, there's a catch. This method is available only when the IIS Server is a directory server on an Active Directory domain. Thus, if you have IIS 5.0 (using Windows 2000 Server) running on an NT 4.0 domain, this security method isn't available. In addition, this method requires that you set up your Active Directory to store passwords using reversible encryption. (For more information about this security option, take a look at Microsoft's Knowledge Base Article Q222028.)
Putting options to work
Now that you know what security options are available, you may be wondering how to use this information. The first step is to select the security settings you want to use within the IIS Server. Fortunately, you can select more then one option, and the options can be set for an entire Web site, a particular folder, or even an individual file.
Use the security settings to determine who can be an author on your Web site. For example, a Web site that's available for viewing to all users will use Anonymous Access. Use Integrated Windows Authentication when some people need to modify the site. And assign read-only permission for the Anonymous Access users and read/write permission for the Web site authors' user account.
When using FrontPage extensions on your IIS Server, FrontPage will offer to control the permissions for you. We strongly recommend that you use your own security settings so that you understand exactly who has access to the files on your Web site. That way, you'll set the appropriate permissions for the resources that the Web site uses.
You can also use the security settings to provide administrative capabilities within your Web site. For example, let's suppose a Web page displays information from a database. If you want only certain users to edit the data, you can provide an Edit button that anyone can click. However, the button will submit changes to a particular Active Server page that only certain users have read access to. (Remember, users need read access to view a page and read/write permission on the database itself to edit data.)
As a result, clicking the Edit button will generate a login prompt. To proceed, the user needs a valid user name and password, unless Integrated Windows Security is used. In that case, the user's login credentials are used, and only unauthorized users will receive a login prompt.
Finally, you can use NT Security on your IIS Server to differentiate between users on your Web site. If your site uses an option other than Anonymous Access, you can determine the user's NT user name with ASP, which is useful in a tracking system.
Before you begin, here are a few things to consider. First, if all of the pages are stored locally on the IIS Server and you use ASP to connect to a database on another server, users will get an error that doesn't point specifically to the IIS security setting if you attempt to access the database.
Watch out for less advanced browsers that don't carry Web sessions from one window to the next. These browsers force users to log in each time they access a different page in a new window. The competent Web designer will warn visitors or design the site so that new pages aren't loaded into a new window (unless there's no alternative).
Remember, it's your job as the developer/designer to secure your site. Review the types of security that are available, make informed decisions about what's best for the situation, and then implement the chosen method. After that, keep yourself and your site updated.
Susan Sales Harkins is an IT consultant, specializing in desktop solutions. Previously, she was editor in chief for The Cobb Group, the world's largest publisher of technical journals.