Using NTFS and AD Integrated File Shares

The second step in setting up an infrastructure where user rights and permissions can be managed is to properly configure the IT resources to which users will have access. Data and applications stored on the company network must be both secure and accessible to those who need it. Remember that a key role in systems administration is that of the security administrator, whose primary objective is to ensure the following:

• Data confidentiality. Data internal to the company should only be accessible to users who have authorization.

• Data integrity. The data available to authorized users should be accurate and free from tampering.

• Data availability. Users authorized to view data should be able to view it when they need it.

In Windows Server 2003, the cornerstone of ensuring security of shared company data is using NTFS formatted volumes with Active Directory integrated file shares. This section details the use of these features.

Using NTFS to Set Permissions

Formatting Windows servers and workstations with the NTFS (New Technology File System) has been an industry standard for years . NTFS provides advanced features that are not found in any version of file allocation table (FAT). For example, NTFS guarantees volume consistency by using standard transaction logging and recovery techniques. If a system fails, NTFS uses its log file and checkpoint information to restore the consistency of the file system. NTFS also provides advanced features, such as file and folder encryption, disk quotas, and compression.

Most importantly, Active Directory and file and folder permissions rely on NTFS. There really is no centralized management of user rights and permissions without NTFS.

NTFS is used in Windows Server 2003 for file-level security in the operating system. Each file and folder on an NTFS formatted drive is marked by an Access Control Entry (ACE) that limits who can and cannot access the object. NTFS permissions control read, write, and several other types of access.

NTFS has been revised in Windows Server 2003 to secure, by default, critical operating system files and directories to disallow their unauthorized use. Additionally, Windows Server 2003 does not by default grant full control to the Everyone group when creating file shares.

Changing permissions on files or folders is a simple process. Remember when changing permissions to take into account that permissions on subdirectories are inherited from their parent directories. For example, to add a group to the Access Control List (ACL) of a particular folder, perform the following steps:

1. Right-click the folder for which the security will be applied and choose Sharing and Security.

2. Select the Security tab.

3. Check the Advanced button.

4. Uncheck the Allow Inheritable Permissions from the Parent to Propagate box.

5. Click Remove when prompted about the application of parent permissions.

6. In the Advanced dialog box, use the Add buttons to give access to the group who needs access to the folder.

7. Check the Replace Permission Entries on All Child Objects box, shown in Figure 5.2, and click OK.

   Figure 5.2. Changing NTFS permissions.

   

8. When prompted about replacing security on child objects, click Yes to replace child object security and continue.

9. Click OK to close the property page.

Setting NTFS Permissions

As file resources are added to the enterprise, managing permissions can become an increasing chore. The administrator's job in securing data while providing appropriate access is simplified greatly if you adhere to the following:

1. Assign object permissions to groups of users rather than individual users whenever possible. Even if a group only includes one user, this will remove organizational dependence on one particular account and make alterations much simpler if a person leaves the organization.

2. Design group permissions so that you have a minimum of duplication. If a set of users need permissions X, Y, and Z, do not create groups with permutations of the three permissions but rather three separate groups. If all of the users need these permissions then only one group is needed. The ultimate goal is to keep the number of groups to a minimum.

3. Manage permissions globally from the ACL window. Right-clicking on objects will open their Security Permissions window. Use the Advanced button to allow or deny permission to one aspect of an object rather than the whole object.

4. Allow inheritance as much as possible. Inheritance is the default; specifying that children do not inherit specific permissions from their parents will make Active Directory harder to manage.

Using Active Directory Integrated Shares

With Windows Server 2003, you have the capability to create, view, and manage permissions on any shared resource. A shared resource includes files, folders, printers, or any server resource made available, or published, to users.

Active Directory Shared Folders give you a tool for viewing a list of users connected over the network to a server share and the capability to disconnect one or all of them. Shared folders also give you the capability to see what shared files are opened by remote users and close one or all of the files.

To publish an Active Directory shared folder, follow these steps:

1. Open Active Directory Users and Computers.

2. In the console tree, right-click the folder into which you want to create a shared folder.

3. Point to New, and then click Shared Folder.

4. Type the name of the folder and the network path as shown in Figure 5.3

   Figure 5.3. Publishing a shared folder in Active Directory.

   

Before there were NTFS permission settings, permissions were set at the share level. Although you still have the capability to set permission at the share level, it is preferable to use NTFS-level security. Setting NTFS permissions is the best practice because it inherently secures subdirectories. Share-level security does not protect subdirectories easily.

Share-level Security

Configure share-level security to be open to all domain users, but then set stricter security on the NTFS level. This allows primary security to be administered by NTFS permissions without share level security vulnerabilities.

Using Allow/Deny Permissions

There are some special points to consider when setting up permissions on files, folders, resources, or shares. The concept of enabling a permission is fairly self explanatory. For example, if the Read permission is Allowed for a user or group on a particular file or folder, that user or group will be able to read the contents of the file or folder. If inheritance is set, that read permission will flow down the directory structure from where it was assigned.

The Deny permission is often a trickier concept to comprehend. As a result, access problems can be caused inadvertently by the misuse or misunderstanding of how this permission setting works.

When permissions are set on a parent container, for example a parent level folder in a shared folder tree, groups or users are granted a certain level of permissions. By doing this, the Access Control Entry (ACE) for that folder restricts access to those individuals defined as members of the groups listed in the ACE. The restriction implicitly denies access to users not defined in the ACE. In this scenario, there is no need for an explicit Deny permission setting.

Deny settings are only used to override an allowed permission that is already set. This situation might occur when allowed permissions are inherited from a parent folder setting. Even this situation might not require explicitly making a Deny setting, as you can break the chain of inheritance and start a new ACE on the subfolder in question by replacing the inherited settings that exclude the group or user you want to exclude.

Explicit Permissions Take Precedence

Explicit permissions take precedence over inherited permissions, even inherited deny permissions.

Never Deny the Everyone Group Access to an Object

Never deny the Everyone group access to an object; the Everyone group also includes Administrators. Instead, exclude the Everyone group from the ACE in question.

Deny permission settings on parent level folders can also be overridden in this fashion. Inherited Deny permissions do not prevent access to a subfolder if that subfolder has an explicit Allow permission entry.

Assigning User Rights and Privileges

In addition to granting users permission to resources, Windows Server 2003 introduces the concept of user rights or privileges . Privileges are similar to permissions in that they involve controlling access. Where permissions involve access to objects such as files, folders, and printers, privileges grant access to operating system functionality.

The exact list of available rights that you can configure depends on the operating system to which a user will be assigned rights. Some common examples of controllable privileges in Windows Server 2003 and Windows XP are the capability to back up files and directories, log on through Terminal Services, and create a pagefile.

For a complete list of configurable user rights or privileges, open the local policy editor for the operating system on which you want to grant or restrict access. You can also view user rights and privileges through the Group Policy Editor.

Granting user rights is a fairly straightforward process. You have to choose whether rights will be granted at the workstation level via the Local Policy Editor, or at the domain level via the Group Policy Editor. Assigning rights locally will only affect users of that particular workstation. Assigning rights using a domain Group Policy will affect all users or computers in the particular Active Directory container to which the group policy object is linked. Using the Group Policy Editor will be covered in the following section, "Using Group Policy to Administer Rights and Permissions."

To assign a particular privilege, for example to grant the ability to load device drivers to the Power Users group on a local workstation, perform the following steps:

1. Type secpol.msc at the Run line, and click OK.

2. Expand Local Policies, and then expand User Rights Assignments.

3. In the right pane, double-click Load and Unload Device Drivers, as shown in Figure 5.4.

   Figure 5.4. Managing user rights.

   

4. Click Add User or Group.

5. Type Power Users in the dialog box, and click OK.

6. Click OK again to complete the configuration.

Assign User Rights to Group Accounts Rather Than Individual User Accounts

As is the case with assigning permissions, it is always a advisable to assign user rights to group accounts rather than individual user accounts.

User Privileges Override File and Directory Permissions

Whether you are troubleshooting an access control issue, or you are designing an access control solution, it is important to keep in mind that user privileges override file and directory permissions.

Some privileges can override permissions set on an object. For example, a user logged on to a domain account as a member of the Backup Operators group has the right to perform backup operations for all domain servers. However, this requires the capability to read all files on those servers, even files on which their owners have set permissions that explicitly deny access to all users, including members of the Backup Operators group. A user rightin this case, the right to perform a backuptakes precedence over all file and directory permissions.