Professional Windows Server 1002003 Security A Technical Reference [Electronic resources] نسخه متنی

Using Object Permissions to Control Access

Object permissions determine the type of access that is granted to an object or an object property. Objects are files, folders, registry keys, printers, and Active Directory objects. The type of access granted is dependent on the type of object. File permissions, for example, include permissions such as read, write, execute, and delete, while Active Directory object permissions might include things such as Reset Password, Create Object, or Modify the Membership of a Group. This chapter includes a general discussion about how permissions are defined and how inheritance affects permissions, and it includes an example of defining printer permissions.Chapter 5 and Chapter 7.

Permission Basics

Who can assign object permissions? Administrators, object owners, and any user or group given the Permission right on an object can assign permissions. Users given object control over objects in the Active Directory can assign permissions on those objects.

In addition to explicit (those assigned directly on an object) object permissions, inherited permissions are also used to determine the effective permissions on an object. Inherited permissions are permissions that are not assigned directly to an object; instead, they are assigned to a parent object and passed on to their children. Inheritable permission can be blocked, so it may be quite confusing to attempt to figure out exactly what permissions are applied to an object. A child object is one that exists in a subcontainer. For example, files are child objects of folders, and subfolders are child objects of other folders. In the file system, all first-level folders are considered child folders of the root.

For example, file and folder permissions and Active Directory object permissions can be inherited from the object above them in the hierarchy. So a file in a subfolder of the volume root may inherit the permissions placed on the root. Figure 3-6 shows the C:\Accounting folder security property page. Notice that the permission boxes are shaded. This means that they are inherited permissions.

Figure 3-6. The accounting folder inherits its permissions from the drive root permissions.

Clicking the Advanced button on the Security page of an object's properties exposes the selection boxes that can enable or disable inheritance. In Figure 3-7, you can see that the check box is selected for Allow Inherited Permissions for the parent to propagate to the object and all child objects. Include these with entries explicitly defined here. This folder happens to be a top-level folderthat is, its only parent is the root of the drive. If the permissions on the root are changed, the permission on this folder also will change.

Figure 3-7. Selection of a check box controls inheritance on a folder.

[View full size image]

On the other hand, the F:\WONT\system 32 folder in Figure 3-8 and Figure 3-9 is protected from permission inheritance. The check boxes are not shaded gray, and on the Advanced property page, the Inheritance check box is not selected. Instead, explicit permissions have been set. If root permissions are changed, permissions here will not change. This is an important concept. Because of inheritance, administration of permissions is simplifiedyou can set permissions once and be assured that the same permissions will be set on all objects below. However, you can also protect sensitive subfolders' permission sets; they will not be changed when the parent object permissions change.

Figure 3-8. Folders can be protected from inheritance. Unshaded boxes mean that the permissions shown are not inherited but explicitly set on the object.

Figure 3-9. The Advanced property page will show you what permissions are inherited, and the Apply To column of the page shows if and when the current permissions will be inherited.

[View full size image]

Combining Permissions

A folder or file can have both inherited and explicit settings. Figure 3-10 indicates that permissions on myfolder for Joe Smith are "not inherited." Figure 3-11 shows the special permissions page for the user Joe Smith of the myfolder\temp folder, indicating that he has been given the Create Files/Write Data permission on this folder. He has inherited the Read and Execute permissions from the myfolder folder. The effective permissions on any folder are calculated for any user by combining explicit and inherited permissions. You can see in Figure 3-12 the effective permissions on the myfolder\temp folder for the user Joe Smith. Note that the effective permissions are a combination of the permissions explicitly given Joe on the temp folder and those inherited from the myfolder folder.

Figure 3-10. Permission may be inherited or, as is the case for the myfolder folder for Joe Smith, not.

[View full size image]

Figure 3-11. Explicit permissions can also be granted.

Figure 3-12. Effective permissions are the combination of inherited and explicit permissions.

[View full size image]

Permissions can be directly configured on an objectinstructions are provided in the chapters where each type of permission is discussed in detail. However, permissions on files, folders, registry keys, and service accounts can also be set in Group Policy and in security templates. This allows you to automate the setting of permissions across multiple machines.

Using these automated methods to apply permissions can be timesavers when large numbers of permissions must be applied to many machines. They are also useful in auditing; you can determine if permissions for a large number of files or registry keys are set the way they are supposed to be.

Best Practices for Assigning Object Permissions

Assigning object permissions requires careful planning to ensure that the access a user ultimately has is correct. Best practices for object permissions are as follows:

Use deny permission to exclude a subset of a group that has allowed permissions or to exclude a special permission when full control has been granted.

Use security templates.

Avoid chaining default permissions on file system objects.

Don't deny the Everyone group access to an object.

Apply permissions high in the tree and use inheritance to propagate.

Printer Permissions and Ownership

A logical printer is the GUI representation of the physical device, and you can create as many as you want for each physical printer. Printer permissions and printer ownership are configured directly on the printer object. In Windows Server 2003, as in Windows 2000 and Windows NT, printer permissions are allowed or denied. Permissions are discussed in the next sections:

Print

Print documents; read permissions.

Manage Printer

Stop, pause, or start printing; delete an item from the printer queue; change the priority of print jobs; read and change permissions. In other words, this permission gives the owner complete control.

Manage Documents

Pause printing; delete an item from the printer queue.

To set printer permissions, follow these steps:

Open the Printers and Faxes console.

Right-click on the printer you want to manage and select Properties from the shortcut menu.

Select the Security tab, as shown in Figure 3-13.

Figure 3-13. The Security tab of the printer object.

Add or remove a group using the Add or Remove buttons or select a group to assign permissions.

To assign permissions, select the permission from the Permissions box or click the Advanced button.

If you click the Advanced button:

Use the Apply Onto drop-down box to select This printer only, Documents only, or Printer and documents.

Select the user group, as shown in Figure 3-14. Click the Edit button and then select the desired permissions.

Figure 3-14. Additional "special" permissions are set from the Advanced properties page.

Click OK twice to return to the Security page.

Click OK to close the property pages.

Making Choices and Restricting Permissions

The default permissions applied to printers may be okay in some environments. While printer access is not generally perceived to be an area for security concern, you need to evaluate the risk based on what the printer is used for and whether or not you believe the printer is accessible to a hostile environment.

Restrict Printer Access

If a printer is used to print checks, securities, or other documents with monetary value, it may be appropriate to restrict the ability to print to authorized personnel. Color printers and plotters and other printers that are expensive to operate are another class of devices to which access should be restricted. If these printers are expensive to operate, then it makes sense to restrict print access to reduce cost.

Modify Default Permissions

The CREATOR OWNER group (meaning the one who created the object and owns it) has, by default, the read, manage documents, and change permissions and takes ownership permission on documents only. This is a reasonable setting because it allows the person sending a document to the printer to see the document in the queue and delete the document, pause, and restart printing of the document. They cannot manage documents that are not theirs. They cannot change the document's priority, eitherthat is, they cannot make their document print before another in the queue. However, users do not need this setting to print, so you could argue that they should not have it. In this case, a print operator takes responsibility for managing all documents.

The Everyone group has the right to print. This is fine in a trusted environment for generic document printers, but in an untrustworthy or hostile environment, it should be removed. However, you must ensure that all groups of users that do need to print have permission to do so.

Administrators, server operators, and print operators have the manage printer right. They can manage all documents, change priority, load new drivers, and so forth. In a restricted environment, create custom groups for classes of printers, assign these groups the right to manage printers, and remove the defaults. For example, just as you may not want all users to be able to print to the check printer, you may not want all administrators, server operators, and print operators to be able to manage the check printer.

Rights and Permissions Factoids

To evaluate rights and permissions, keep these facts in mind:

Rights may override permissions. You may have Allow permissions on a file, but if you do not have the right to access this computer from a network and cannot log on locally, you will not be able to access the file.

Explicit permissions take precedence over inherited permissions, even inherited Deny permissions. Inherited Deny permissions do not prevent access to an object if the object has an explicit permission entry.

While permissions applications, inheritance, and general practices are the same, each object type, file, folder, registry key, printer, and Active Directory object has differences.

Built-in groups represent administrative roles. However, some user rights assigned to these groups can be removed, and others can be added. Do not rely on your understanding of what a member in these groups can or cannot do. Check the Local Security Policy.

Build custom roles by following the model used for built-in roles. Create a group, assign the group rights and permissions, and add user accounts to the group.

Assign rights and permissions to groups, not individual accounts.

Computers also have rights, and access to resources can be managed by modifying these rights. For example, you can deny a computer access to another computer over the network.

Role-based access control is supported by creating and managing roles composed of user rights and object permission settings.