Administering Internet Information Services

In previous topic discussed the issues related to sharing a folder so that users, with the Client For Microsoft Networks, can access resources on a server running the File And Print Sharing For Microsoft Networks service. That is, however, only one means by which users can access the files and folders they require. It is also possible to enable access through Internet technologies such as FTP and Web (HTTP) services.


In this topic, you will learn how to configure and manage IIS. You will discover how to configure Web and FTP sites, virtual directories, and IIS security.

Installing IIS 6.0

To decrease the attack surface of a Windows Server 2003 system, IIS is not installed by default. It must be added using the Add/Remove Windows Components Wizard from Add Or Remove Programs, located in Control Panel. Select Application Server, click Details, and then select Internet Information Services (IIS). You can control the sub-components of IIS that are installed, but unless you are very familiar with the role of subcomponents, do not remove any default components. You may, however, want to add components, such as ASP.NET, FTP or FrontPage Server Extensions.

Administering the Web Environment

When IIS is installed, a default Web site is created, allowing you to implement a Web environment quickly and easily. However, you can modify that Web environment to meet your needs. Windows Server 2003 provides the tools necessary to administer IIS and its sites.

After installation has completed, you may open the Internet Information Services (IIS) Manager console from the Administrative Tools group. By default, IIS is configured to serve only static content. To enable dynamic content, select the Web Service Extensions node. As shown in Below Figure, all the extensions are prohibited. Select the appropriate extension and click Allow.

The fundamental processes that take place as a client accesses a resource from IIS are

 The client enters a URL (Universal Resource Locator) in either of the following forms:
http://dns.domain.name/virtualdirectory/page.htm or ftp://dns.domain.name/virtualdirectory

 Domain Name Service (DNS) resolves the name to an IP address and returns the address to the client

 The client connects to the server’s IP address, using a port that is specific to the service (typically, port 80 for HTTP and port 21 for FTP)

 The URL does not represent the physical path to the resource on the server, but a virtualization of the path. The server translates the incoming request into the physical path and produces appropriate resources to the client. For example, the server might list files in the folder to an FTP client, or might deliver the home page to an HTTP client.

 The process can be secured with authentication (credentials, including a user name and password) and authorization (access control through permissions).

You can see this process in action by opening a browser and typing http://Syscare (server name). The server produces the Under Construction page to the client browser.

Configuring and Managing Web and FTP Sites

IIS installation configures a single Web site, the Default Web Site. Although IIS, depending on your server’s hardware configuration, can host thousands, or tens of thousands of sites, the Default Web Site is a fine place to explore the functionality and administration of Web sites on IIS. This Web site is accessible if you open a browser and type the URL: http://syscare.mcseweb.in. The page that is fetched is the Under Construction page.

Remember that a browser’s request to a Web server is directed at the server’s IP address, which was resolved from the URL by DNS. The request includes the URL, and the URL often includes only the site name (www.microsoft.com, for example). How does the server produce the home page? If you examine the Web Site tab of the Default Web Site Properties, as shown in below Figure, you see that the site is assigned to All Unassigned IP addresses on port 80. So the request from the browser hits port 80 on the server, which then identifies that it is the Default Web Site that should be served.

The next question, then, is what information should be served. If the URL includes only the site name (for example, www.microsoft.com or syscare.mcseweb.in), then the page that will be returned is fetched from the home directory. The Home Directory tab, as shown in Below Figure, displays the physical path to the home directory, typically c:\inetpub\wwwroot.

Which file, exactly, should be returned to the client? That is defined on the Documents tab, as shown in Below Figure. IIS searches for files in the order listed. As soon as it finds a file of that name in the local path of the home directory, that page is returned to the client and the server stops looking for other matches. If no match is found, the IIS returns an error (404–File Not Found) to the client indicating that the page could not be found.

A browser could, of course, refer to a specific page in the URL, for example http:// syscare.mcseweb.in/contactinfo.htm. In that event, the specific page is fetched from the home directory. If it is not found, a File Not Found error (404) is returned.

To create a Web site, right-click the Web Sites node or an existing Web site in IIS Manager and choose New Web Site. To configure a Web site, open its Properties. You can configure the IP address of the site. If a server has multiple IP addresses, each IP address can represent a separate Web site. Multiple sites can also be hosted using different ports for each site, or using host headers. The specifics of these options are beyond the scope of this book. You can also configure the path to the directory that is used as the home directory. And you can modify the list or order of documents that can be fetched as the default content page.

A URL can also include more complex path information, such as http:// www.microsoft.com/windowsserver2003. This URL is not requesting a specific page; there is no extension such as .htm or .asp on the end of the URL. Instead, it is requesting information from the windowsserver2003 directory. The server evaluates this additional component of the URL as a virtual directory. The folder that contains the files referred to as windowsserver2003 can reside anywhere; they do not have to be located on the IIS server.

To create a virtual directory, right-click a Web site and choose New Virtual Directory. The wizard will prompt you for the alias, which becomes the folder name used in the URL, and the physical path to the resource, which can be on a local volume or remote server.

FTP sites work, and are administered, similarly to Web sites. IIS installs one FTP site, the Default FTP Site, and configures it to respond to all incoming FTP requests (all unassigned addresses, port 21). The FTP site returns to the client a list of files from the folder specified in the Home Directory tab. FTP sites may also include virtual directories so that, for example, ftp:// syscare.mcseweb.in/pub may return resources from a different server than ftp:// syscare.mcseweb.in/vendor-uploads. FTP URLs and sites do not use default documents.

Complex IIS servers may host tens of thousands of sites, each with customized settings to make them tick. Losing all that configuration information could be painful, so although a normal file system backup might allow you to restore the data files after a failure, the configuration would be lost. To back up or restore IIS configuration, you must back up or restore the metabase, an Extensible Markup Language (XML) document that is used to store settings. Right-click the server node in IIS Manager and, from the All Tasks menu, choose Backup/Restore Configuration.

Securing Files on IIS

Security for files accessed by way of IIS falls into several categories: authentication, authorization through NTFS permissions, and IIS permissions. Authentication is, of course, the process of evaluating credentials in the form of a user name and password. By default, all requests to IIS are serviced by impersonating the user with the IUSR_computername account. Before you begin restricting access of resources to specific users, you must create domain or local user accounts and require something more than this default, Anonymous authentication.

Configuring Authentication Methods

You may configure the following authentication methods on the Directory Security tab of the server, a Web (or FTP) site, a virtual directory, or a file:

Web Authentication Options

 Anonymous authentication Users may access the public areas of your Web site without a user name or password.

 Basic authentication Requires that a user have a local or domain user account. Credentials are transmitted in clear text.

 Digest authentication Offers the same functionality as Basic authentication, while providing enhanced security in the way that a user’s credentials are sent across the network. Digest authentication relies on the HTTP 1.1 protocol.

 Advanced Digest authentication Works only when the user account is part of an Active Directory. Collects user credentials and stores them on the domain controller. Advanced Digest authentication requires the user to be using Internet Explorer 5 or above and the HTTP 1.1 protocol.

 Integrated Windows authentication Collects information through a secure form of authentication (sometimes referred to as Windows NT Challenge/ Response authentication) where the user name and password are hashed before being sent across the network.

 Certificate authentication Adds Secure Sockets Layer (SSL) security through client or server certificates, or both. This option is available only if you have Certificate Services installed and configured.

 .NET Passport authentication Provides a single sign-in service through SSL, HTTP redirects, cookies, Microsoft JScript, and strong symmetric key encryption.

FTP Authentication Options

 Anonymous FTP authentication Gives users access to the public areas of your FTP site without prompting them for a user name or password.

 Basic FTP authentication Requires users to log on with a user name and pass-word corresponding to a valid Windows user account.

Defining Resource Access with Permissions

Once authentication has been configured, permissions are assigned to files and folders. A common way to define resource access with IIS is through NTFS permissions. NTFS permissions, because they are attached to a file or folder, act to define access to that resource regardless of how the resource is accessed.

IIS also defines permissions on sites and virtual directories. Although NTFS permissions define a specific level of access to existing Windows user and group accounts, the directory security permissions configured for a site or virtual directory apply to all users and groups.

Below Table details Web permission levels:

Read (default): Users can view file content and properties.

Write: Users can change file content and properties.

Script Source Access: Users can access the source code for files, such as the scripts in an Active Server Pages (ASP) application. This option is available only if either Read or Write permissions are assigned. Users can access source files. If Read permission is assigned, source code can be read. If Write permission is assigned, source code can be written to as well. Be aware that allowing users to have read and write access to source code can compromise the security of you server.

Directory browsing: Users can view file lists and collections.

The Execute permissions control the security level of script execution and are as described in Below Table .

None: Set permissions for an application to None to prevent any programs or scripts from running.

Scripts only: Set permissions for an application to Scripts only to enable applications mapped to a script engine to run in this directory without having permissions set for executables. Setting permissions to Scripts only is more secure than setting them to Scripts and Executables because you can limit the applications that can be run in the directory.

Scripts and Executables: Set permissions for an application to Scripts and Executables to allow any application to run in this directory, including applications mapped to script engines and Windows binaries (.dll and .exe files).

Auditing File System Access

Many organizations elect to audit file system access to provide insight into resource utilization and potential security vulnerabilities. Windows Server 2003 supports granular auditing based on user or group accounts and the specific actions performed by those accounts. To configure auditing, you must complete three steps: specify auditing settings, enable audit policy, and evaluate events in the security log. This Topic will explore these three processes and provide guidance to effective auditing, so that you can leverage auditing to meet business requirements without being drowned in logged events.


Configuring Audit Settings

To specify the actions you wish to monitor and track, you must configure audit settings in the file’s or folder’s Advanced Security Settings dialog box. The Auditing tab, shown in below Figure, looks strikingly similar to the Permissions tab before it. Instead of adding permissions entries, however, you add auditing entries.

Click Add to select the user, group, or computer to audit. Then, in the Auditing Entry dialog box, as shown in below Figure, indicate the permission uses to audit.

You are able to audit for successes, failures, or both as the account attempts to access the resource using each of the granular permissions assigned to the object.

Successes can be used to audit the following:

 To log resource access for reporting and billing.

 To monitor for access that would indicate that users are performing actions greater than what you had planned, indicating permissions are too generous.

 To identify access that is out of character for a particular account, which might be a sign that a user account has been breached by a hacker.

Auditing for failed access allows you:

 To monitor for malicious attempts to access a resource to which access has been denied.

 To identify failed attempts to access a file or folder to which a user does require access. This would indicate that permissions are not sufficient to achieve a business task.

Audit settings, like permissions, follow rules of inheritance. Inheritable auditing settings are applied to objects that allow inheritance.

Enabling Auditing

Configuring auditing entries in the security descriptor of a file or folder does not, in itself, enable auditing. Auditing must be enabled through policy. Once auditing is enabled, the security subsystem begins to pay attention to the audit settings, and to log access as directed by those settings.

Audit policy may be enabled on a stand-alone server using the Local Security Policy console, and on a domain controller using the Domain Controller Security Policy console. Select the Audit Policy node under the Local Policies node and double-click the policy, Audit Object Access. Select Define These Policy Settings and then select whether to enable auditing for successes, failures, or both.

You may also enable auditing for one or more computers using Active Directory Group Policy Objects (GPOs). The Audit Policy node is located under Computer Configuration, Windows Settings, Security Settings, Local Policies, Audit Policy. Like all group policies, the computers that are affected by the policy will be those contained within the scope of the policy. If you link a policy to the Servers OU and enable auditing, all computers objects in the Servers OU will begin to audit resource access according to audit entries on files and folders on those systems.

Examining the Security Log

Once audit entries have been configured on files or folders, and auditing object access has been enabled through local or group policy, the system will begin to log access according to the audit entries. You can view and examine the results using Event Viewer and selecting the Security log, as shown in below Figure.

As you can see, the Security log can be quite busy, depending on the types of auditing being performed on the machine. You can sort the events to help you identify object access events by clicking the Category column header and locating the Object Access events.

Sorting will, however, provide little assistance as you dig through the logged events. You will often be better served by filtering the event log, which can be done by choosing the Filter command from the View menu, or alternatively by selecting the Security log, then Properties from the Action or shortcut menus, and then clicking the Filter tab. The Filter tab enables you to specify criteria including the event type, category, source, date range, user, and computer. Below Figure illustrates an example of a filter applied to identify object access audit events on a specific date.

Finally, you have the option to export the Security log by selecting the Save Log File As command from the log’s context menu. The native event log file format takes a .evt extension. You can open that file with Event Viewer on another system. Alternatively, you can save the log to tab- or comma-delimited file formats, which can be read by a number of analysis tools including Microsoft Excel. In Excel, you can of course apply filters as well to search for more specific information, such as the contents of the event’s Description field.

Configuring File System Permissions

Windows servers support granular or detailed control of access to files and folders through NTFS. Resource access permissions are stored as access control entries (ACEs) on an ACL that is part of the security descriptor of each resource. When a user attempts to access a resource, the user’s security access token, which contains the security identifiers (SIDs) of the user’s account and group accounts, is compared to the SIDs in the ACEs of the ACL. This process of authorization has not changed fundamentally since Windows NT was introduced. However, the details of the implementation of authorization, the tools available to manage resource access, and the specificity with which you can configure access have changed with each release of Windows.


This topic will explore the nuances and new features of Windows Server 2003’s resource access control. You will learn how to use the ACL editor to manage permissions templates, inheritance, special permissions, and how to evaluate resulting effective permissions for a user or group.

Configuring Permissions

Windows Explorer is the most common tool used to initiate management of resource access permissions, both on a local volume as well as on a remote server. Unlike shared folders, Windows Explorer can configure permissions locally and remotely.

The Access Control List Editor

As in earlier versions of Windows, security can be configured for files and folders on any NTFS volume by right-clicking the resource and choosing Properties (or Sharing And Security) then clicking the Security tab. The interface that appears has many aliases; it has been called the Permissions dialog box, the Security Settings dialog box, the Security tab or the Access Control List editor (ACL editor). Whatever you call it, it looks the same. An example can be seen in the Security tab of the Docs Properties dialog box, as shown in Below Figure

Prior to Windows 2000, permissions were fairly simplistic, but with Windows 2000 and later versions, Microsoft enabled significantly more flexible and powerful control over resource access. With more power came more complexity, and now the ACL editor has three dialog boxes, each of which supports different and important functionality.

The first dialog box provides a “big picture” view of the resource’s security settings or permissions, allowing you to select each account that has access defined and to see the permissions templates assigned to that user, group, or computer. Each template shown in this dialog box represents a bundle of permissions that together allow a commonly configured level of access. For example, to allow a user to read a file, several granular permissions are needed. To mask that complexity, you can simply apply the Allow:Read & Execute permissions template and, behind the scenes, Windows sets the correct file or folder permissions.

To view more details about the ACL, click Advanced, which exposes the second of the ACL editor’s dialog boxes, the Advanced Security Settings For Docs dialog box, as shown in below Figure. This dialog box lists the specific access control entries that have been assigned to the file or folder. The listing is the closest approximation in the user interface to the actual information stored in the ACL itself. The second dialog also enables you to configure auditing, manage ownership, and evaluate effective permissions.

If you select permission in the Permission Entries list and click Edit, the ACL editor’s third dialog box appears. This Permission Entry For Docs dialog box, shown in below Figure, lists the detailed, most granular permissions that comprise the permissions entry in the second dialog box’s Permissions Entries list and the first dialog box’s Permissions For Users list.

Adding and Removing Permission Entries

Any security principal may be granted or denied resource access permissions. In Windows Server 2003, the valid security principals are: users, groups, computers, and the special InetOrgPerson object class, which is used to represent users in certain cross-directory platform situations. To add permission, click the Add button on either the first or second ACL editor dialog box. The Select User, Computer Or Group dialog box will help you identify the appropriate security principal. Then select appropriate permissions. The interface has changed slightly from previous versions of Windows, but not enough to prevent an experienced administrator from mastering the new user interface quickly. You can remove an explicit permission that you have added to an ACL by selecting the permission and clicking Remove.

Modifying Permissions

A permission may be modified in the dialog box by selecting or clearing the Allow or Deny check boxes on the Security tab to apply permissions templates.

For a finer degree of control, click Advanced, select a permission entry and click Edit. Only explicit permissions may be edited. Inherited permissions are discussed later in this lesson.

The Permission Entry For Docs dialog box, shown in Figure (above), will allow you to modify permissions and specify the scope of the permissions inheritance, through the Apply Onto drop-down list.

New Security Principals

Windows Server 2003, unlike Windows NT 4, allows you to add computers or groups of computers to an ACL, thereby adding flexibility to control resource access based on the client computer, regardless of the user who attempts access. For example, you may want to provide a public computer in the employee lounge, but prevent a manager from exposing sensitive data during his or her lunch break. By adding the computer to ACLs and denying access permission, the manager who can access sensitive data from his or her desktop is prevented from accessing it from the lounge.

Windows Server 2003 also allows you to manage resource access based on the type of logon. You can add the special accounts, Interactive, Network, and Terminal Server User to an ACL. Interactive represents any user logged on locally to the console. Terminal Server User includes any user connected via remote desktop or terminal services.

Network represents a connection from the network, for example a Windows system running Client for Microsoft Networks.

Permissions Templates and Special Permissions

Permissions templates, visible on the Security tab in the first dialog box are bundles of special permissions, which are fully enumerated in the third dialog box, Permissions Entry For Docs. Most of the templates and special permissions are self-explanatory, while others are beyond the scope of this book. However, the following points are worth noting:

* Read & Execute: This permissions template is sufficient to allow users to open and read files and folders. Read & Execute will also allow a user to copy a resource, assuming they have permission to write to a target folder or media. There is no permission in Windows to prevent copying. Such functionality will be possible with Digital Rights Management technologies as they are incorporated into Windows platforms.

*Write and Modify: The Write permissions template applied to a folder allows users to create a new file or folder (when applied to a folder) and, when applied to a file, to modify the contents of a file as well as its attributes (hidden, system, read-only) and extended attributes (defined by the application responsible for the document). The Modify template adds the permission to delete the object.

*Change Permissions: After modifying ACLs for a while, you might wonder who can modify permissions. The answer is, first, the owner of the resource. Ownership will be discussed later in this lesson. Second, any user who has an effective permission that allows Change Permission can modify the ACL on the resource. The Change Permission must be managed using the ACL editor’s third dialog box, Permission Entry For Docs. It is also included in the Full Control permission template.


Inheritance

Windows Server 2003 supports permissions inheritance, which simply means that per-missions applied to a folder will, by default, apply to the files and folders beneath that folder. Any change to the parent’s ACL will similarly affect all contents of that folder. Inheritance enables you to create single points of administration, managing a single ACL on a branch or resources under a folder.


Understanding Inheritance

Inheritance is the result of two characteristics of a resource’s security descriptor. First, permissions are, by default, inheritable. As previously shown in Figure, the permission Allow Users to Read & Execute is specified to Apply to: This folder, subfolders, and files. That alone, however, is not enough to make inheritance work. The other half of the story is that new objects, when created, are set by default to “Allow Inheritable Permissions From The Parent To Propagate To This Object...” the check box visible in the same figure.

So a newly created file or folder will inherit the inheritable permissions from its parent, and any changes to the parent will affect the child files and folders as well. It is helpful to understand this two-step implementation of inheritance because it gives us two ways to manage inheritance: from the parent and from the child.

Inherited permissions are displayed differently in each dialog box of the ACL editor. The first and third dialog boxes (Security tab and Permissions Entry For Docs) show inherited permissions as dimmed check marks, to distinguish them from permissions that are set directly on the resource, called explicit permissions, which are not dimmed. The second dialog box (Advanced Security Settings) shows, for each permission entry, from what folder the permission entry is inherited.

Overriding Inheritance

Inheritance allows you to configure permissions high in a folder tree. Such initial per-missions, and any changes to those permissions, will propagate to all the files and folders in that tree that are, by default, configured to allow inheritance.

Occasionally, however, you might need to modify permissions on a subfolder or file, to provide additional access or restrict access to a user or group. You cannot remove inherited permissions from an ACL. You can override an inherited permission by assigning an explicit permission. Alternatively, you can block all inheritance and create an entirely explicit ACL.

To override an inherited permission by assigning an explicit permission, simply check the appropriate permissions box. For example, if a folder has an inherited Allow Read permission assigned to the Sales Reps group, and you do not want Sales Reps to access the folder, you can select the box to Deny Read.

To override all inheritance, open the resources Advanced Security Settings dialog box and clear Allow Inheritable Permissions From The Parent To Propagate To This Object... You will block all inheritance from the parent. You will then have to manage access to the resource by assigning sufficient explicit permissions.

To help you create an explicit permissions ACL, Windows gives you a choice when you choose to disallow inheritance. You are asked whether you want to Copy or Remove permissions entries, as shown in Below Figure.

Copy will create explicit permissions identical to what was inherited. You can then remove individual permissions entries that you do not want to affect the resource. If you choose Remove, you will be presented with an empty ACL, to which you will add permissions entries. The result is the same either way; an ACL populated with explicit permissions. The question is whether it is easier to start with an empty ACL and build it from scratch or start with a copy of the inherited permissions and modify the list to the desired goal. If the new ACL is wildly different than the inherited permissions, choose Remove. If the new ACL is only slightly different than the result of inherited permissions, it is more efficient to choose Copy.

When you disallow inheritance by deselecting the Allow Inheritable Permissions option, you block inheritance. All access to the resource is managed by explicit per-missions assigned to that file or folder. Any changes to the ACL of its parent folder will not affect the resource; although the parent permissions are inheritable, the child does not inherit. Block inheritance sparingly because it increases the complexity of managing, evaluating, and troubleshooting resource access.

Reinstating Inheritance

Inheritance can be reinstated in two ways: from the child resource or from the parent folder. The results differ slightly. You might reinstate inheritance on a resource if you disallowed inheritance accidentally or if business requirements have changed. Simply re-select the Allow Inheritable Permissions option in the Advanced Security Settings dialog box. Inheritable permissions from the parent will now apply to the resource. All explicit permissions you assigned to the resource remain, however. The resulting ACL is a combination of the explicit permissions, which you might choose to remove, and the inherited permissions. Because of this dynamic, you might not see some inherited permissions in the first or third ACL editor dialog boxes. For example, if a resource has an explicit permission, Allows Sales Reps Read & Execute, and the parent folder has the same permission, when you choose to allow inheritance on the child, the result will be that the child has both an inherited and an explicit permission. You will see a check mark in the first and third dialog boxes; the explicit permission obscures the inherited permission in the interface. But the inherited permission is actually present, which can be confirmed in the second dialog box, Advanced Security Settings.

The second method for reinstating inheritance is from the parent folder. In the Advanced Security Settings dialog box of a folder, you may select the check box, Replace Permission Entries On All Child Objects With Entries Shown Here That Apply To Child Objects. The result: all ACLs on subfolders and files are removed. The permissions on the parent are applied. You might see this as “blasting through” the parent’s permissions. After applying this option, any explicit permission that had been applied to subfolders and files is removed, unlike the method used for reinstating inheritance on the child resources. Inheritance is restored, so any changes to the parent-folder ACL are propagated to its subfolders and files. At this point, you might set new, explicit per-missions on subfolders or files. The Replace Permissions option does its job when you apply it, but does not continuously enforce parent permissions.


Effective Permissions

It is common for users to belong to more than one group, and for those groups to have varying levels of resource access. When an ACL contains multiple entries, you must be able to evaluate the permissions that apply to a user based on his or her group memberships. The resulting permissions are called effective permissions.

Understanding Effective Permissions

The rules that determine effective permissions are as follows:

*File permissions override folder permissions: This isn’t really a rule, but it is often presented that way in documentation, so it is worth addressing. Each resource maintains an ACL that is solely responsible for determining resource access. Although entries on that ACL may appear because they are inherited from a parent folder, they are nevertheless entries on that resource’s ACL. The security subsystem does not consult the parent folder to determine access at all. So you may interpret this rule as: The only ACL that matters is the ACL on the resource.

*Allow permissions are cumulative: Your level of resource access may be determined by permissions assigned to one or more groups to which you belong. The Allow permissions that are assigned to any of the user, group, or computer IDs in your security access token will apply to you, so your effective permissions are fundamentally the sum of those Allow permissions. If the Sales Reps group is allowed Read & Execute and Write permissions to a folder, and the Sales Managers group is allowed Read & Execute and Delete permissions, a user who belongs to both groups will have effective permissions equivalent to the Modify permissions template: Read & Execute, Write and Delete.

*Deny permissions take precedence over Allow permissions: A permission that is denied will override a permission entry that allows the same access. Extending the example above, if the Temporary Employees group is denied Read permission, and a user is a temporary sales representative, belonging to both Sales Reps and Temporary Employees, that user will not be able to read the folder.

*Explicit permissions take precedence over inherited permissions: A per-mission entry that is explicitly defined for a resource will override a conflicting inherited permission entry. This follows common-sense design principles: A parent folder sets a “rule” through its inheritable permissions. A child object requires access that is an exception to the rule, and so an explicit permission is added to its ACL. The explicit permission takes precedence.

Evaluating Effective Permissions

Complexity is a possibility, given the extraordinary control over granular permissions and inheritance that NTFS supports. With all those permissions, users and groups, how can you know what access a user actually has?

Microsoft added a long-awaited tool to help answer that question. The Effective Per-missions tab of the Advanced Security Settings dialog box, shown in Below Figure, provides a reliable approximation of a user’s resulting resource access.

To use the Effective Permissions tool, click Select and identify the user, group, or built-

in account to analyze. Windows Server 2003 then produces a list of effective permis

sions. This list is an approximation only. It does not take share permissions into

account, nor does it evaluate the account’s special memberships, such as the following:

i. Anonymous Logon

ii. Batch

iii. Creator Group

iv. Dialup

v. Enterprise Domain Controllers

vi. Interactive

vii. Network

viii. Proxy

ix. Restricted

x. Remote Interactive Logon

xi. Service

xii. System

xiii. Terminal Server User

xiv. Other Organization

xv. This Organization
An ACL can contain entries for the Network or Interactive accounts, for example, which would provide the opportunity for a user to experience different levels of resource access depending on whether the user was logged on to the machine or using a net-work client. Because the user in question is not logged on, logon-specific permissions entries are ignored. However, as an extra step, you can evaluate effective permissions for a built-in or special account such as Interactive or Network.

Resource Ownership

Windows Server 2003 includes a special security principal called Creator Owner, and an entry in a resource’s security descriptor that defines the object’s owner. To fully manage and troubleshoot resource permissions, you must understand these two parts of the security picture.

Creator Owner

When a user creates a file or folder (which is possible if that user is allowed Create Files/Write Data or Create Folders/Append Data, respectively), the user is the creator and initial owner of that resource. Any permissions on the parent folder assigned to the special account Creator Owner are explicitly assigned to the user on the new resource.

As an example, assume that a folder allows users to create files (allow Create Files/ Write Data), and the folder’s permissions allows users to Read & Execute, and Creator Owner Full Control. This permission set would allow Maria to create a file. Maria, as the creator of that file, would have full control of that file. Tia can also create a file, and would have full control of her file. However, Tia and Maria would only be able to read each other’s files. Tia could, however, change the ACL on the file she created. Full Control includes the Change Permission.

Ownership

If for some reason Tia managed to modify the ACL and deny herself Full Control, she could nevertheless modify the ACL, because an object’s owner can always modify its ACL, preventing users from permanently locking themselves out of their files and folders.

It is best practice to manage object ownership so that an object’s owner is correctly defined. This is partly because owners can modify ACLs of their objects, and also because newer technologies, such as disk quotas, rely on the ownership attribute to calculate disk space used by a particular user. Prior to Windows Server 2003, managing ownership was awkward. Windows Server 2003 has added an important tool to simplify ownership transfer.

An object’s owner is defined in its security descriptor. The user who creates a file or folder is its initial owner. Another user can take ownership, or be given ownership of the object using one of the following processes:

*Administrators can take ownership: A user who belongs to the Administrators group of a system, or who has otherwise been granted the Take Ownership user right, can take ownership of any object on the system.

To take ownership of a resource, click the Owner tab of the Advanced Security Settings dialog box, as shown in Below Figure. Select your user account from the list and click Apply. Select the Replace Owner On Subcontainers And Objects check box to take ownership of subfolders and files.

*Users can take ownership if they are allowed Take Ownership permission: The special permission Take Ownership can be granted to any user or group. A user with an Allow Take Ownership permission can take ownership of the resource and then, as owner, modify the ACL to provide sufficient permissions.

*Administrators can facilitate the transfer of ownership: An administrator can take ownership of any file or folder. Then, as owner, the administrator can change permissions on the resource to grant Allow Take Ownership permission to the new owner, who then can take ownership of the resource.

*Restore Files And Directories user right enables the transfer of ownership: A user with the Restore Files And Directories rights may transfer owner-ship of a file from one user to another. If you have been assigned the Restore Files And Directories right, you can click Other Users Or Groups and select the new owner. This capability is new in Windows Server 2003, and makes it possible for administrators and backup operators to manage and transfer resource ownership without requiring user intervention.

Files and Folders

1. Setting Up Shared Folders
2. Configuring File System Permissions
3. Auditing File System
4. Administering Internet Information Services

Setting Up Shared Folders

We would not have networks, or our jobs, if organizations did not find it valuable to provide access to information and resources stored on one computer to users of another computer. Creating a shared folder to provide such access is therefore among the most fundamental tasks for any network administrator. Windows Server 2003 shared folders are managed with the Shared Folders snap-in.


Sharing a Folder

Sharing a folder configures the File And Printer Sharing For Microsoft Networks service (also known as the Server service) to allow network connections to that folder and its subfolders by clients running the Client For Microsoft Networks (also known as the Workstation service). You certainly have shared a folder using Windows Explorer by right-clicking a folder, choosing Sharing And Security, and selecting Share This Folder.

However, the familiar Sharing tab of a folder’s properties dialog box in Windows Explorer is available only when you configure a share while logged on to a computer interactively or through terminal services. You cannot share a folder on a remote system using Windows Explorer. Therefore, you will examine the creation, properties, configuration, and management of a shared folder using the Shared Folders snap-in, which can be used on both local and remote systems.

When you open the Shared Folders snap-in, either as a custom MMC console snap-in or as part of the Computer Management or File Server Management consoles, you will immediately notice that Windows Server 2003 has several default administrative shares already configured. These shares provide connection to the system directory (typically, C:\Windows) as well as to the root of each fixed hard disk drive. Each of these shares uses the dollar sign ($) in the share name. The dollar sign at the end of a share name configures the share as a hidden share that will not appear on browse lists, but that you may connect to with a Universal Naming Convention (UNC) in the form \\servername\sharename$. Only administrators can connect to the administrative shares.

To share a folder on a computer, connect to the computer using the Shared Folders snap-in by right-clicking the root Shared Folders node and choosing Connect To Another Computer. Once the snap-in is focused on the computer, click the Shares node and, from the shortcut or Action menu, choose New Share. The important pages and settings exposed by the wizard are

*The Folder Path page Type the path to the folder on the local hard drives so, for example, if the folder is located on the server’s D drive, the folder path would be D:\foldername.

*The Name, Description, and Settings page Type the share name. If your net-work has any down-level clients (those using DOS-based systems), be sure to adhere to the 8.3 naming convention to ensure their access to the shares. The share name will, with the server name, create the UNC to the resource, in the form \\servername\sharename. Add a dollar sign to the end of the share name to make the share a hidden share. Unlike the built-in hidden administrative shares, hidden shares that are created manually can be connected to by any user, restricted only by the share permissions on the folder.

*The Permissions page Select the appropriate share permissions.

Managing a Shared Folder

The Shares node in the Shared Folders snap-in lists all shares on a computer and provides a context menu for each share that enables you to stop sharing the folder, open the share in Windows Explorer, or configure the share’s properties. All the properties that you are prompted to fill out by the Share A Folder Wizard can be modified in the share’s Properties dialog box, illustrated in Beow Figure

The Properties tabs in the dialog box are

*General: The first tab provides access to the share name, folder path, description, the number of concurrent user connections, and offline files settings. The share name and folder path are read-only. To rename a share, you must first stop sharing the folder then create a share with the new name.

*Publish: If you select Publish This Share In Active Directory (as shown in Below Figure), an object is created in Active Directory to represent the shared folder.

The object’s properties include a description and keywords. Administrators can then locate the shared folder based on its description or keywords, using the Find Users, Contacts and Groups dialog box. By selecting Shared Folders from the Find drop-down list, this dialog box becomes the Find Shared Folders dialog box shown in Below Figure

*Share Permissions: The Share Permissions tab allows you to configure share permissions.

*Security: The Security tab allows you to configure NTFS permissions for the folder.

Configuring Share Permissions

Available share permissions are listed in Below Table. While share permissions are not as detailed as NTFS permissions, they allow you to configure a shared folder for fundamental access scenarios: Read, Change, and Full Control.

Read: Users can display folder names, file names, file data and attributes. Users can also run program files and access other folders within the shared folder.

Change: Users can create folders, add files to folders, change data in files, append data to files, change file attributes, delete folders and files, and perform actions permitted by the Read permission.

Full Control: Users can change file permissions, take ownership of files, and perform all tasks allowed by the Change permission.

Share permissions can be allowed or denied. The effective set of share permissions is the cumulative result of the Allow permissions granted to a user and all groups to which that user belongs. If, for example, you are a member of a group that has Read permission and a member of another group that has Change permission, your effective permissions are Change. However, a Deny permission will override an Allow permission. If, on the other hand, you are in one group that has been allowed Read access and in another group that has been denied Full Control, you will be unable to read the files or folders in that share.

Share permissions define the maximum effective permissions for all files and folders beneath the shared folder. Permissions can be further restricted, but cannot be broadened, by NTFS permissions on specific files and folders. Said another way, a user’s access to a file or folder is the most restrictive set of effective permissions between share permissions and NTFS permissions on that resource. If you want a group to have full control of a folder and have granted full control through NTFS permissions, but the share permission is the default (Everyone: Allow Read) or even if the share permission allows Change, that group’s NTFS full control access will be limited by the share per-mission. This dynamic means that share permissions add a layer of complexity to the management of resource access, and is one of several reasons that organizations cite for their directives to configure shares with open share permissions (Everyone: Allow Full Control), and to use only NTFS permissions to secure folders and files. See the “Three Views of Share Permissions” sidebar for more information about the variety of perspectives and drivers behind discussions of share permissions.


Managing User Sessions and Open Files

Occasionally, a server must be taken offline for maintenance, backups must be run, or other tasks must be performed that require users to be disconnected and any open files to be closed and unlocked. Each of these scenarios will use the Shared Folders snap-in.

The Sessions node of the Shared Folders snap-in allows you to monitor the number of users connected to a particular server and, if necessary, to disconnect the user. The Open Files node enumerates a list of all open files and file locks for a single server, and allows you to close one open file or disconnect all open files.

Before you perform any of these actions, it is useful to notify the user that the user will be disconnected, so that the user has time to save any unsaved data. You can send a console message by right-clicking the Shares node. Messages are sent by the Messenger Service using the computer name, not the user name. The default state of the Messenger service in Windows Server 2003 is disabled. The Messenger service must be configured for Automatic or Manual startup and must be running before a computer can send console messages.