Assign administrative permissions to the Admins group, sufficient permissions to update the Web site to the Authors group, and equivalent permissions to the Browsers group. The interesting part of using local groups to assign these permissions is that you can assign global groups to these local groups to ensure consistency in your administration. For example, you might add a global group called San Diego Web Administrators to each FrontPage Admins group in each server in San Diego to ensure that those administrators can administer all their Web sites and servers.
Setting the Appropriate IIS Permissions
Although much of the access control for IIS comes from NTFS-based ACLs, additional internal options exist within IIS that you can control. Figure 2 shows additional controls within IIS to limit access. The system considers these permissions in addition to the NTFS ACLs. These special IIS permissions are
- Script source accessUsers can access the source code to files such as Active Server Pages (ASP) files.
- Read (default)Users can read the contents of static files (e.g., .htm, .txt) and send the GET command in the HTTP request. Note that this setting doesn't affect a user's ability to run scripts or executable files.
- WriteUsers can write to files and send the PUT command in the HTTP request. Note that this setting doesn't affect scripts or executable files that write to the Web site.
- Directory browsingUsers can list contents of directories.
The important thing to note here is that you shouldn't consider IIS permissions in the same light as NTFS ACLs. You apply IIS permissions first, but NTFS ACLs perform the real security work in IIS. NTFS permissions limit access file by file, on a per-user basis. IIS permissions qualify only what types of requests are permitted; therefore, they apply to all users of the resource rather than to specified users or groups. IIS permissions can't discriminate among users like NTFS ACLs do.
Determining NTFS ACLs Based on Functions
Assigning only enough permissions to accomplish the assigned function always makes good security sense. Administrators tend to overassign permissions. They use the Full Control and other administrator-type permissions far too much. These permissions can get you out of a jam for the short term, but they make pulling back later more difficult.
So, which NTFS permissions are really necessary for an IIS 5.0 Web server? You set basic permissions on the Security tab of the Web server's Properties dialog box, which Figure 3 shows. Select a group name, and click Advanced to set advanced permissions, which Figure 4 shows. Essential basic and advanced NTFS permissions are
- ModifyThis permission includes the Read and Write permissions. This combination most often applies to users who need to update content on a site. Be certain you grant this permission only to users who need that capability and never to the Anonymous account.
- List Folder ContentsThis permission is necessary for viewing files and subdirectories in a particular directory. Virtual directories are never visible.
- ReadRead permission is best used with static content, such as HTML pages and images. If you're setting permissions on a database, select both Read and Write permission.
- ExecuteThis permission is necessary for executable files, such as .dll or .exe files.
Apply sufficient permissions to give your users or groups the lowest number of permissions. If you're using Anonymous authentication, assign permissions to the IUSR_computername account. If you're using any other authentication type, assign the NTFS permissions as appropriate to an account or preferably to a local group on the Web server that contains the appropriate account.
FTP Permissions
IIS supports the FTP protocol as well as the HTTP protocol. Authentication for FTP is similar to Web server authentication, but it's significantly more limited.
Using anonymous FTP is simple. An FTP server that allows anonymous connections still challenges users for their username and password, but users only need to supply the username Anonymous and their email address as a password (although many FTP servers accept any password in the form of an email address). However, anonymous FTP isn't appropriate for every situation.
An FTP server that requires user credentials provides only marginal additional security over anonymous FTP. The biggest drawback of the FTP protocol is that the FTP username and password is always transmitted in cleartext, which introduces a credible threat that a malicious user on the network can compromise the username and password. Using your everyday account name and password to authenticate to an FTP server exacerbates this risk.
To remedy this problem, consider using a group username and password that has access to the FTP site and no other resources. This option limits risk to only the data that username and password protects. Be sure to follow your company policy regarding group accounts: Some companies prohibit or restrict the use of group accounts.
Creating an FTP Virtual Directory
You can create a directory or site that requires credentials before it grants access (e.g., to a specific directory). I suggest that you create a test user or group for this purpose, one to which you've granted no extra permissions or rights. To create an FTP virtual directory, follow these steps:
- Open the Microsoft Management Console (MMC) Internet Services Manager snap-in.
- Expand the appropriate FTP server to display the Default FTP Site.
- Right-click Default FTP Site, then select New, Virtual Directory to start the Virtual Directory Creation Wizard. Click Next.
- For the virtual directory alias, enter the name of the group or user you created previously. Click Next.
- Click Browse, then select the appropriate directory. (Be careful about what you select as the root of your virtual directory.)
- Choose whether you want to allow Read or Write permission to this directory. Click Next.
- Click Finish.
Creating a new FTP site is similar to creating a virtual directory; you can even change the default FTP port, which lets you set up more than one FTP server on the same computer. If you change the port, your end users need to know the new port number before they can connect.
Assign the Proper Permissions
Setting up Web server and FTP server permissions doesn't have to be complicated. You can establish a Web site or FTP site and use anonymous accounts, group accounts, or user accounts to restrict access. I've covered just a few of the possible new security precautions that relate to these decisions. I recommend that you avoid transmitting your user account names and passwords in cleartext whenever possible. Assign the lowest number of permissions possible, and avoid overassigning permissions as a quick fix to a problem.
End of Article
I installed these Office Server Extentions on our intranet server running IIS and wiped out IIS' previously setup default accounts. I had to reinstall the previous default accounts in IIS which had been removed.
If there is already an article about this, just let me know.
Tom Dadakis March 01, 2001