- Install and Configure Network Services for Interoperability
- Monitor, Configure, Troubleshoot, and Control Access to Printers
- Monitor, Configure, Troubleshoot, and Control Access to Files, Folders, and Shared Folders
- Monitor, Configure, Troubleshoot, and Control Access to Web Sites
- Practice Questions
- Need to Know More?
Monitor, Configure, Troubleshoot, and Control Access to Files, Folders, and Shared Folders
Before discussing the ins and outs of file, folder, and shared folder access, it's important to understand the underlying file system functions and the differences between the file systems supported by Windows 2000. There are four file systems recognized by Windows 2000: Universal Disk Format (UDF), CD-ROM File System (CDFS), File Allocation Table (FAT), and the NT File System (NTFS). However, UDF and CDFS are read-only file systems and do not truly support detailed access controls. For this reason, this section and the Microsoft exam focus on the capabilities and features of the FAT and NTFS file systems.
The File Allocation Table (FAT) File System
The FAT file system is recognized by Windows 2000 to provide legacy support for earlier Windows operating systems. It was originally designed to support disks that were much smaller than the devices in use today. Consequently, it is not very efficient when handling large disks or files. Windows 2000 is able to read partitions formatted in two version of FAT, the 16-bit version (FAT16) supported by early versions of MS-DOS, and the 32-bit version (FAT32) first introduced with Windows 95 OEM Service Release 2 (OSR2).
Because FAT predates Windows NT and Windows 2000, it does not include support for security or enhanced partition features such as compression. From a practical perspective, the biggest difference between FAT16 and FAT32 is the maximum supported partition size. This is achieved by doubling the size of the File Allocation Table from 16 bits to 32 bits. For FAT16 partitions, the maximum size is 4GB. In theory, FAT32 partitions support a maximum size of 2,047GB. However, there is a 32GB limitation on creating FAT32 partitions in Windows 2000.
The NT File System (NTFS)
Introduced in 1993 with Windows NT 3.1, the NT File System (NTFS) is designed to provide a high performance, secure file system for Windows NT Servers. Windows 2000 includes the latest version of NTFS, 5.0, which is an improvement over the original version included with NT 3.1, but the differences between NTFS and FAT are even more dramatic.
One of the significant differences between FAT and NTFS is the recoverability and compression features of NTFS. To ensure data is consistently written to the volume, NTFS uses transaction logging and advanced recovery techniques. In the event of a failure, NTFS uses checkpoint and data logging information to automatically maintain the consistency of the data on the volume. NTFS also supports selective file, folder, and volume compression, which is not available on FAT volumes. The selectivity of the NTFS compression settings allows administrators the ability to pick and choose whether specific file system objects are compressed or not. Although data compression reduces the drive space required on the volume, it puts a greater burden the system's resources. Providing the option to compress entire volumes, folders, or individual files ensures that the drive space is used as efficiently as possible, while still maintaining timely file services. For additional information on compression, refer to Chapter 6, "Managing, Configuring, and Troubleshooting Storage Use."
In an effort to provide the fastest file services available, NTFS uses smaller clusters and has been designed to require fewer disk reads to find a file on the volume. NTFS version 5.0 also supports significantly larger volumes than FATup to 2 Terabytes on a single volume. NTFS volumes include highly configurable user and group options, including the use of disk quotas to limit the amount of drive space a user can consume. Perhaps more importantly, individual files, folders, and volumes can be secured at the user and group level. This is significantly more secure than the option available on FAT, which can only be secured for shared folders, and even then permissions are limited to three settings: Read, Change, and Full Control. Securing folders and files will be discussed in greater detail in the next few sections of this chapter.
Because NTFS offers such enormous improvements over the FAT file system, Microsoft recommends that all Windows 2000 volumes be formatted with NTFS. However, there are some situations where this is not possible. For example, most multiple-boot configurations require a FAT file system on the boot partition. If it is necessary to maintain a FAT volume on the server, it is important to understand the security implications of the configuration. As you'll learn later in the "Monitor, Configure, Troubleshoot, and Control Local Security on Files and Folders" section of this chapter, FAT partitions cannot be secured when they are accessed from the server console. This is an important consideration when making the determination to support a FAT partition on a Windows 2000 Server.
Configure, Manage, and Troubleshoot a Standalone Distributed File System (Dfs)
The Distributed file system (Dfs) is a new feature of Windows 2000. This item has been created to eliminate the confusion often experienced by end-users on large networks with multiple servers and extensive lists of shared folders. In other words, having to navigate for files through many folders found on many different servers is a cumbersome activity. Dfs functionality allows you to put these shared folders in one central location. This will improve the usability of your network for your end-users.
The Dfs service is installed automatically when Windows 2000 is set up on the server. When Dfs is implemented, it is configured to represent shared folders on multiple servers. The folders are shown in a hierarchical tree structure, as shown in Figure 3.3. The first shared folder in the tree acts as the Dfs root and is the shared folder end-users use to access all folders in the Dfs configuration. Once the Dfs root is created, shared folders on the network are tied to the Dfs root using Dfs links.
Figure 3.3 Dfs shares are made up of a Dfs root and related Dfs links to shared folders.
One of the biggest considerations when designing a Dfs implementation is that there can only be one Dfs root per server. This means you must carefully choose the servers to host Dfs root objects and design your Dfs configuration around the limitations of your network. Remember that the shares' security permissions ultimately control whether a user is granted access to the shares in the Dfs structure or their files.
Dfs management is handled through the Distributed File System MMC plug-in, which can be accessed through Administrative Tools in the Control Panel. To launch the New Dfs Root Wizard from this snap-in, click Action on the menu bar, then click New Dfs Root. After starting the wizard, the choice you must make is whether to create a domain or standalone Dfs root. A domain Dfs root must be administered through Active Directory, whereas a standalone Dfs root can operate independently of directory services; this distinction is discussed in more detail in the sections that follow. Figure 3.4 shows the next configuration screen in the New Dfs Root Wizard in which you identify the server to host the Dfs root. By default, the server from which you launched the wizard is listed.
Figure 3.4 Identify the server to host the Dfs root.
If you are creating a Dfs root on another server, click Browse to search for the server on the network. After you've identified the server, click Next. You will be given the option of choosing an existing share on the server or creating a new share.
If you are creating a new share, you must identify the path to the share and the share name. To do this, of course, you must have sufficient permissions to create a share on the server.
Regardless of whether you are utilizing an existing share or creating a new one, be certain to review the security configuration for the share to verify the Dfs share users have the correct permission settings.
After clicking Next, you are presented with the Dfs root name, which by default is the name of the original share. It is also on this screen that you are able to add comments to the Dfs share's configuration. Click Next to proceed to the final screen of the wizard. Here, you are presented with the final configuration for the Dfs share, which outlines the share's configuration settings. Click Finish to complete the wizard.
On standalone Dfs roots, you cannot change the name of the root; it must be the same as the share. However, on domain Dfs roots, you are able to specify a root name that is different from the share name.
Standalone and Domain Dfs Types
There are two types of Dfs roots used in Windows 2000, standalone and domain. Domain Dfs roots are sometimes referred to as fault-tolerant Dfs roots because they use Active Directory services to distribute Dfs information to all servers in the tree. Standalone Dfs root information, on the other hand, is stored in the Registry on the hosting server. Because of this limitation, there is no backup for a standalone Dfs root. If the server hosting the Dfs root is unavailable, the information provided by the Dfs share is not accessible to users. Though it is possible to configure replicas of Dfs links associated with standalone Dfs roots on other servers, the files in the linked share must be synchronized manually, so it is not considered a truly fault- tolerant system. Standalone Dfs roots can be configured with one level of Dfs links and can reside on any supported file system. However, it is recommended that all Dfs links identify resources on NTFS volumes.
There are a few key differences between standalone Dfs roots and domain Dfs roots. Most evident is the fact that all Active Directory servers in the domain distribute information in response to requests from clients on the network. Because the information is stored as part of the Active Directory, it is replicated to every domain controller. This replication ensures that end-users are never without access to the information in the Dfs share. Because of their interaction with Active Directory, domain Dfs roots must be located on NTFS 5.0 partitions.
There is very little difference between creating a domain Dfs root and a standalone Dfs root, aside from selecting the option on the initial screen of the New Dfs Root Wizard. On the second screen of the wizard you are asked to choose the host domain for the Dfs root. After clicking Next, the configuration requirements are the same: Identify the host server, Identify the share, Name the Dfs root, and Add comments.
The differences are really seen after the Dfs root is created. As Figure 3.5 shows, right-clicking on a Dfs domain root presents a menu that includes "New Root Replica," which is not available for standalone roots. Selecting this option launches the same process for creating a Dfs root; the only difference is that is a replication of the original. Once the root replica has been created, you can enable Dfs replication between the roots. Because of the potentially high traffic volume, Dfs replication is disabled by default. To enable replication, right-click the Dfs root and select Replication Policy. You are then able to select each of the Dfs root replicas defined. Select at least two of the replicas and click Enable. Dfs root replication is handled by the File Replication Service discussed in the next section.
Figure 3.5 Select replication policy to synchronize files between replicas.
As mentioned, Dfs links are created to tie share information from different servers into a single, easy to access location. Once the Dfs root has been created, you can create Dfs links to other shared folders. In the Dfs plug-in, select the Dfs root to which will host the Dfs link, then select New Dfs Link from the Action menu. When prompted, fill in the name to be assigned to the Dfs link, the shared folder information, and any comments regarding the link. If you are uncertain of the exact name and location of the shared folder, use the Browse button to search the network. When the Dfs links have been configured, they will look to the users like other folders normally found in the share.
File Replication Service (FRS)
The Windows 2000 File Replication Service (FRS) is included during installation and was designed to handle file replication traffic for domain controllers. It is included with all Windows 2000 Server installations, though it is configured for manual startup on standalone and member servers. When a server is configured as a domain controller, FRS is set to start automatically. Although FRS is originally set up for login script and policy replication, it is the foundation for Dfs root replication on domain roots. In fact, Dfs root replication will most likely take more FRS time than Active Directory file replication. To manage Dfs root replication, FRS uses the same structure as the Knowledge Consistency Checker (KCC) defined Active Directory file replication. When a user has changed a file in a Dfs root, the change is noted in the NTFS change log, which is monitored for changes to Dfs links. When the user closes the file, the changes are updated and FRS places the file in a staging area for scheduled replication.
Although Windows 2000 Servers use FRS for file replication, it is not used for Active Directory traffic. FRS on Windows 2000 domain controllers synchronizes SYSVOL contents among servers in the domain. SYSVOL stores login scripts and system policy files, and FRS ensures the most up-to-date files exist on each server. To do this, version files are maintained, which allows FRS to determine whether the most current updates have been distributed.
Among domain controllers, FRS automatically generates a replication ring. The Active Directory topology defines the path replication updates take from domain controller to domain controller, to ensure that all servers have up-to-date information. By using a ring topology, FRS is certain to have at least two paths from one domain controller to another in the event that a domain controller is down. Because Active Directory uses a multimaster replication scheme in which all domain controllers are equal, it is imperative that all Active Directory servers are completely up-to-date.
The replication scheme is configured into sites, which represent a group of connected computers. Because of the amount of traffic involved in replication, it's important that the networks supporting a site be reliable and relatively high-speed; Microsoft recommends network speeds of at least 512Kbps. Active Directory servers requiring synchronization over slower links, such as 56Kbps WAN lines, should be configured in separate sites. The KCC is responsible for generating and maintaining the replication ring among domain controllers within a site.
Replication between servers in the same site (intra-site replication) occurs every five minutes and is trigger-based, which means that the domain controller notifies its replication partners when it has changes to send, and when the replication partners are available, they send a request to the domain controller for the update. Intra-site replication traffic is not compressed. During the installation process, intra-site replication is automatically established between domain controllers on the same site.
Replication between sites (inter-site replication) takes place only at specific times (the default is three hours), unless there is an urgent need for replication. To ensure the best transmission speeds, the transport for inter-site replication is configurable and the data is compressed. Unfortunately, inter-site communication is not configured automatically. Urgent replication is triggered for inter-site connections when a user account has been locked out due to failed login attempts, when there is a change in the domain controller's Local Security Authority (LSA), and when there is a change in the relative identifier (RID) master role owner.
Monitor, Configure, Troubleshoot, and Control Local Security on Files and Folders
The Windows 2000 environment is exceptionally dynamic and allows for a wide variety of security configurations. The building blocks for implementing security on a Windows 2000 system, whether Server or Professional, are users and groups. Because creating and managing user and group accounts is a focus of the Installing, Configuring, and Administering Microsoft Windows 2000 Professional exam number 70-210, it is not covered on the Server exam. It is important, however, that you understand how users and groups are implemented in Windows 2000 before you tackle file and folder security.
There are two levels of security that can be implemented on a Windows 2000 system: local security and share security. Local security manages access for users who log on directly to the system: in other words, the user typing on the Server's keyboard. Share security (discussed in the next section) generally applies to users who are accessing the system's resources across the network.
To begin securing access to local files and folders, you must define which users are to log on to the server locally. This is done by using security policies, which are discussed in Chapter 8, "Implementing, Monitoring, and Troubleshooting Security." For the sake of discussion in this section, it's enough to understand that limiting local access to the server itself is key to controlling local access to files and folders.
Once the determination is made as to which users and groups will be allowed to access the server locally, securing the resources becomes a question of the drive partition's file system. As mentioned earlier, one of the most significant differences between the FAT and NTFS file systems is the number and variety of security settings available. Because the FAT file system is not inherently structured to provide security, it is not possible to control access to files and folders once the user has been granted access to the server console. FAT partitions can be secured when accessed remotely, however, which will be discussed in the next section.
As mentioned, NTFS was designed to provide complete file-level security for file resources on Windows 2000 systems. It provides the ability to allow or deny specific access permissions to users and groups down to the individual files on the partition. It is preferable to use groups for any security configuration to provide for easier administration.
To provide the most secure configuration possible, denying a permission to a specific user or group overrides all other permissions. For example, if a folder's permission assignments dictate that the Accounting group be granted Full Control, but the permissions for a member of that group have been set to Deny for the Read permission, that member will not be able to see the folder or its contents. Because Deny overrides all other settings, it affects permission inheritance. It is often better not to specifically assign permissions to a user or group, rather than explicitly set deny permissions to restrict access.
One of the benefits of NTFS is that its security settings apply whether the user is accessing the resources locally or over the network. This is an important feature that ensures a user who accesses the server locally is not able to impact the server's operation. By securing access to the folders where system files are stored, or securing the files themselves, essential operating system files are protected from users deleting or modifying them. System files located on a FAT partition do not have this security, which means a user accessing the server locally can potentially render the server inoperable.
NTFS permissions are cumulative; in other words, the permissions assigned to a user are combined with the permissions assigned to any groups to which they are members to determine whether to grant the requested access to a resource. For the most part, access permissions are combined to allow access. For example, an Administrator may grant a group the Read and List Folder Contents permissions to a folder, then may grant specific users the Read, Write, and Modify permissions to files in that folder. When combined, the users will be able to review the contents of the folder, read the files, overwrite the files or change their attributes, and modify the contents of the file. Other members of the group, however, will only be allowed to view the contents of the folder and read the files.
Windows 2000 makes very little distinction between NTFS folder permissions and NTFS file permissions. In fact, there are few differences. The biggest difference is in the way Windows 2000 makes the determination on which permission to use. File permissions take precedence over folder permissions, which means that you can grant a group access to read a folder's contents, and then grant individual users permission to modify individual files in the folder. This ensures that the appropriate users are granted the highly secure, granular access to files they sometimes require. However, controlling security at the individual file level is very time consuming and is not recommended except in special circumstance. For the most part, utilizing NTFS security at the folder level is sufficient.
When determining whether to grant requests for files, Windows 2000 begins compiling security configuration settings at the root of the file tree. Progressing through the tree, permissions are inherited by the files and folders until the ultimate file is reached, unless inheritance has been disabled for a particular permission setting. When an NTFS object's security settings are modified, you can disable permission inheritance from parent objects. This means that the settings being specified will not be adjusted by other permissions higher in the tree. If you choose this setting, you are given the option of copying or removing the parent object's current settings.
The certification exam places significant focus on NTFS permission inheritance. You may have multiple questions that are nearly identical, but with one setting being different. It's important to understand how Windows 2000 will treat a particular resource request, based on the NTFS permissions settings.
By default, the owner of a file or folder can assign permissions, as can Administrators. Figure 3.6 shows the Properties dialog box for a folder on an NTFS partition.
Figure 3.6 The Security tab is used to assign permissions for NTFS folders.
The Name window identifies the users or groups that currently have permissions assignments for the folder. The Permissions section indicates the permissions that have been allowed or denied for the highlighted user. If the selection has a black check mark, it has been defined on this folder. If it has a gray checkmark, the assignment has been inherited from the parent object.
At the bottom of the dialog box, the Allow Inheritable Permissions from Parent to Propagate to This Object selection is used to specify the inheritance policy for the object. If you uncheck this selection, you are asked whether you want to copy the parent's permissions or remove them from the configuration. To add a user to the object's configuration settings, click Add. You will be presented with a list of users and groups on the server. Select the user or group, click Add, then click OK. Select the new permission assignments from the list provided or click Advanced to go to the Access Control Setting dialog box.
In addition to assigning more specific permissions, called special commissions, you can also manage auditing for the object as well as define the object's owner settings. Table 3.2 outlines the special and standard permissions available for an NTFS file or folders. Because standard permissions are actually combinations of special permissions, they are listed as such.
The standard folder permission List Folder Contents is not listed in the table. It is made up of the same permissions as Read & Execute, but is inherited differently, because it applies only to folders and is only inherited by folders. Whereas Read & Execute is inherited by both files and folders.
Table 3.2 NTFS File and Folder Permissions
List Folder/Read Data
Viewing folder contents (including subfolder names) and data in files.
Read, Read & Execute, Modify, Full Control
Viewing of file and folder standard attributes (Read Only and Hidden, for example).
Read, Read & Execute, Modify, Full Control
Read Extended Attributes
Viewing of file and folder extended attributes, which vary by file file type.
Read, Read & Execute, Modify, Full Control
Viewing of file and folder permissions.
Read, Write, Read & Execute, Modify, Full Control
Create Files/Read Data
Creating new files in the folder (folder) and modifying and overwriting existing files (file).
Write, Modify, Full Control
Create Folders/Append Data
Creating new folders (folder) and appending data to the end of a such as a database, but no other file modification, such as or overwriting (file).
Write, Modify, Full Control
Changing the file and folder attributes.
Write, Modify, Full Control
Write Extended Attributes
Changing the file and folder extended attributes.
Write, Modify, Full Control
Traverse Folder/Execute File
Moving through folders where access has not been granted (folder) and running programs.
Read & Execute, Modify, Full Control
Deleting the specified file or folder.
Modify, Full Control
Delete Subfolders and Files
Deleting subfolders and files, even if the Delete permission has not been assigned to those subfolders or files.
Changing the file and folder permissions.
Taking ownership of the file or folder.
Monitor, Configure, Troubleshoot, and Control Access to Files and Folders in a Shared Folder
As discussed earlier in the chapter, users gain access to file resources through shared folders on the server's partitions. When users attempt to gain access to the server remotely, through utilities such as My Network Places, they will be able to see the shared folders to which they have access.
The process of sharing folders is similar to the process for assigning NTFS permissions. By default, folders are not shared. The level of access granted to users is determined by their group membership. Figure 3.7 shows the Properties for a folder to be shared. Selecting the Share This Folder option seen in the folder's Properties dialog box enables you to specify the name of the share, add comments, as well as limit the number of users who are able to access the share at the same time.
Figure 3.7 Share a folder to restrict access.
Clicking the Permissions tab gives you the opportunity to change the access settings for the shared folder. Note that the default setting is to allow the Everyone group Full Control to the shared folder. Remember that, as with NTFS permissions, an explicit Deny overrides all other permissions, including any that may be inherited from other group memberships. Shared folder permissions are significantly less comprehensive than NTFS permissions. Briefly, the permissions are
ReadThis permission lets the designated user or group view the files and subfolders present, as well as their attributes. Users are able to read the contents of the files and execute programs from the folder.
ChangeThis permission allows users the ability to create subfolders within the shared folder, add files to the folder, modify the files (including changing their attributes), and do all the things allowed by the Read permission.
Full ControlGives users everything allowed under the Change permission, plus the ability to change file permissions and take ownership of files.
As with NTFS permissions, shared folder permissions are cumulative, unless a user is denied access in any of the groups to which they belong. The combination of their groups' permissions and their own will determine their total access level. Though they do not provide the most thorough security configuration, shared folders are the only way to secure network access to files and folders on FAT volumes. When the shared folder resides on an NTFS volume, it is preferable to configure the security settings either on the share or through the NTFS permissions, but not both. Because NTFS provides more thorough security options, it is generally the best choice to opt for NTFS permissions when possible. For this reason, the default configuration for share permissions (Everyone granted Full Control) is often acceptable. This limits the administrative effort required and makes it easier to ensure the correct permissions are granted to users and groups.
On a Windows 2000 Server in a domain, membersof the Administrators and Server Operators groups are able to share folders on any computer in the domain. On a standalone server, Power Users can create shares on the local partitions only. In a workgroup environment, Administrators and Power Users can create shares on the standalone server and on any Windows 2000 Professional computer which is a member of the group.
When volumes are created, Windows 2000 automatically creates special shares for administration. These shares are shown with a dollar sign ($) on the Sharing tab of the volume's properties page. For example, the root of the volume on the C drive is shared as C$. Administrative shares are also created for the system root folder, shared as Admin$, and the folder Windows 2000 users to store printer drivers, shared as Print$. All administrative shares are hidden and cannot be changed, but can be accessed by users on the network if they are granted appropriate access. By default, only Administrators are granted access to administrative shares.
Monitor, Configure, Troubleshoot, and Control Access to Files and Folders via Web Services
Windows 2000 includes Microsoft's Internet publishing product called Internet Information Services (IIS) version 5.0, which you'll learn more about in the next section. One of the new features of IIS allows you to grant access to network resources so that they can be accessed through a Web browser. This is possible because of an enhancement to HTTP, included in version 1.1, called WebDAV for Web distributed authoring and versioning. Using WebDAV and an HTTP/1.1-compliant Web browser, users with sufficient permissions are able to manipulate files and folders. This includes moving files to and from the WebDAV folder, changing the file's properties, and searching the WebDAV directory for content. Because WebDAV is integrated with both Windows 2000 and Internet Explorer 5, it includes sec-urity features from both products. This ensures that users who access the folders from the Internet are granted only the access desired by the administrator.
There are many different ways to establish a WebDAV site for users to access. For example, create a Web site in IIS specifically designated for WebDAV folder access, then create virtual directories for all folders you want to share through WebDAV. Once the Web site has been created, you can create the virtual directories either through IIS, or by choosing Web Sharing on the folder's Properties page, as shown in Figure 3.8.
Figure 3.8 Share a folder for access via WebDAV.
To share a folder to the Web site, on the Web Sharing tab, select the Web site that will host the folder, then select Share this folder. You will be prompted for an alias for the share on the Web site, IIS access permissions for the folder, and application permissions. After you've made the appropriate selections, click OK to return to the folder properties, then OK again to continue.
Using the Web Sharing tab on a folder is a quick and familiar way to share folders for access via WebDAV. Once they are created, they are managed through the Internet Services Manager in Administrative Tools.
In fact, the Internet Services Manager is used to configure security for all Web sites, including WebDAV sites. Much like NTFS, IIS can configure security from the Web site level down to the individual files. The first four security settings dictate the authentication level required for users to access the resources. Selecting Anonymous will grant anyone access to the resource, which is not recommended for WebDAV implementations. The Basic authentication setting requires passwords to access the resources, but sends them in plain text. Although this is not the most secure option, it is the most widely supported because it is part of the HTTP standard. Integrated Windows authentication relies on the Windows security system, which encrypts and hashes passwords before sending them across the network, to validate user access and works well for intranet environments. Digest authentication is a secure method for validating user authentication through a browser and is the best option if the WebDAV data is to be shared over the Internet.
In addition to controlling the authentication method used on the Web site, IIS includes security permissions for the individual files and folders that make up the Web site. When the virtual folder is configured in the Internet Services Manager, the Local Path section is used to assign permissions. On the Home Directory tab of WebDAV Properties page you are able to configure the following:
The location of the resource: as a resource on the local computer, a share located on another computer, or a redirection to a URL.
The path to the resource.
Which permissions to enable. If your Web site includes scripts such as ASP applications, the Script Source Access option will allow users to execute the scripts. Read lets users read or download the files, while Write allows users to place files in the WebDAV virtual directory. Directory browsing allows the user to view subdirectory listings if there are folders beneath the shared virtual folder. If this option is not selected and there are subfolders, they will be hidden from the users.
Whether to log visits to the site.
Whether to allow the Microsoft Indexing server to include the resource in a site index.
The application name and starting point for applications launched from the site.
The type of applications that can be launched from the site. None indicates that only static files can be accessed. Scripts Only dictates that only scripts such as ASP applications can be launched. Scripts and Executables allows all types of applications to be launched.
The extent to which the applications are separated from the server processes. This helps to minimize the impact of malicious code that may be uploaded to the site.
Because IIS is integrated closely with Windows 2000, the access it grants to users is controlled by the file system that hosts the Web site. The permissions chosen when creating the WebDAV virtual directory work with the file system to control how files within the folder are accessed by users. To simplify security administration for the virtual directory, it is recommended that you share the folder and keep the default share permissions (Full Control assigned to Everyone) in place, then utilize the more dynamic security settings available through IIS.