Welcome to the fifth installment of Internet Information Services 6.0 on Windows Server 2003. This series of articles discusses IIS 6.0 on Windows Server 2003 and is designed to be both a refresher for the IT professional familiar with designing and administrating IIS 4.0 and IIS 5.0, and for newcomers looking to get their feet wet.
This installment of our Internet Information Services 6.0 on Windows Server 2003 series provides an introductory overview of the NTFS file system and explains its importance to IIS 6.0.
This installment provides an introductory overview of the NTFS file system.
NOTES FROM THE FIELD — For those wondering why we opted to do an entire chapter related to the NTFS file system in a series of articles about IIS 6.0, the reason is a fairly simple one: A big part of the reputation that Internet Information Server 4 on Windows NT4 and Internet Information Services 5 on Windows 2000 have earned comes from an inherent lack of security. While Microsoft is to blame for a bulk of it, IIS administrators have earned a place in the blame trail as well.
IIS 5 on Windows 2000 is installed automatically on a default installation of the operating system, but a knowledgeable administrator should perform a custom installation of Windows 2000 Server to keep unnecessary features and services from being installed where they are not needed. The original line of thinking with regard to the default availability of IIS 5 on Windows 2000 was to have all of the available functionality of services ready to offer to end users, as needed, on all of the Windows 2000 servers at all times.
While IIS 6.0 on Windows Server 2003 is not available out of the box by default, it can be turned on by the administrator. Although the default configuration of IIS 6.0, once enabled, is quite locked down and will initially offer up only static Web content, an administrator with just enough knowledge to be dangerous can enable additional services and features without knowing all of the drawbacks of his actions.
By providing information on better ways to work and best practices to further lock down the IIS 6.0 application and the server operating system, administrators can add to Microsoft’s Secure Computing Initiative rather than reducing its effectiveness.
To aid in the effort, this article aims to offer a better understanding of the NTFS file system.
How the IIS 6.0 server is configured affects the level and type of access to the system. If the server is a domain member, permissions can apply to users and groups in the domain and any trusted domains, as well as all of the local user accounts and local groups on the system itself. If the IIS 6.0 server is set up as a stand-alone server that is a member of a workgroup, it is usually only the local user accounts and local groups on the system itself that will specifically allow or deny access to the server.
NTFS is used to set the appropriate access levels for data and the type of access to that data.
NOTES FROM THE FIELD — External access to a public IIS server available via the internet is normally handled by two users on the local machine: IUSR_ and IWAM_, unless restricted access is allowed only to the particular Web server, in which case only specified users with their own accounts can access the system. The proper use and configuration of these two default access accounts is also important and will be outlined in a future article.
Access to a particular folder on an NTFS partition for users in a group called IISUSERS may be set to “ALLOW – READ” or “DENY – WRITE.” This means that IISUSERS are allowed to read all of the information provided to them via that particular folder, but they are not allowed to write to the folder at all.
They might also be denied permission to write to the folder in the first place by simply not having been granted the permission at all.
If access to the folder is set to “ALLOW – READ” only and nothing else, all of the IISUSERS would be able to do nothing more than read the data in the folder; they would have been implicitly denied access to write to the folder through the IISUSERS group. What this also means is that if any of those users belonged to another group that allowed them write access, they would be granted that right. To ensure all of the users in the IISUSERS group are explicitly denied a certain access (write, in the case of this example), you must explicitly deny them write access via the IISUSERS group.
Any DENY setting is going to take precedence over any and all ALLOW settings, even over cumulative group settings. Users that are members of multiple groups have all of their access permissions combined, and they are given the maximum level of access to the resource based on the combined settings. As an example, a user named JOEUSER who is a member of the Domain Users group may have READ rights to the folder on an NTFS partition, called DOCS, and may have READ/WRITE access to the same folder because he is also a member of the ACCTS group. Consequently, JOEUSER may have the MODIFY right specifically assigned to him directly though his user account.
The effective sum of all of these permissions is the cumulative total, which in this case is MODIFY.
If JOEUSER has all of the above permissions to the DOCS folder and was also a member of the group CTRUSR, which had a permission setting of DENY – READ&EXECUTE, the only permissions JOEUSER would have to the DATA folder would be WRITE because DENY access control entries take precedence over ALLOW.
File and folder permissions are set through Access Control Lists (ACL) on the object. The entries listed, such as READ, are called Access Control Entries (ACE).