Lesson 1:Understanding Authorization

 < Day Day Up > 



Authorization is the process of determining whether an authenticated user is allowed to perform a requested action. Each time you open a file, Windows Server 2003 verifies that you are authorized to open that file. Each time you print, Windows Server 2003 verifies that you have Print permissions to that printer. In fact, Windows Server 2003 verifies your authorization to access just about every object you can imagine: files and folders, shared folders, printers, services, Active Directory directory service objects, Terminal Services connections, Windows Management Interface objects, and registry keys and values.

Understanding how authorization works for each of these different types of objects is complicated, because each type requires unique permissions. For example, you need to control whether users can read files or write to files, but for services, your concern is whether a given user can start or stop the service. Fortunately, Windows Server 2003 simplifies authorization management by using a standard model for all types of objects. This model uses access control lists, inherited permissions, and both standard and special permissions. Even the user interface for specifying permissions for each object type is similar.

After this lesson, you will be able to

  • Describe the significance of access control lists and access control entries.

  • Assign permissions to a variety of objects.

  • Calculate a user's effective permissions, given enough information about the user's group memberships and relevant access control entries.

  • Use inherited permissions to minimize the number of permissions you need to manually assign.

  • Describe the relationship between standard and special permissions.

Estimated lesson time: 45 minutes

Access Control Lists

Windows Server 2003, like all recent members of the Microsoft Windows family, keeps track of the privileges users have to resources by using a discretionary access control list (DACL). DACLs, or simply ACLs, identify the users and groups that are assigned or denied access permissions on an object. If an ACL does not explicitly identify a user, or any groups that a user is a member of, the user will be denied access to that object. By default, an ACL is controlled by the owner of an object or the person who created the object, and it contains access control entries (ACEs) that determine user access to the object. An access control entry (ACEs) is an entry in an object's ACL that grants permissions to a user or group.

Though a description of ACLs and ACEs is complex, they are very easy to manage. Figure 2.1 shows the Windows Server 2003 graphical user interface dialog box for managing permissions to a folder named Secret. The GG Boston Research security group is highlighted so that the dialog box displays the permissions assigned to that group: Read & Execute, List Folder Contents, and Read. Collectively, these permissions allow members of the GG Boston Research security group to read the contents of the folder.

Note 

All of the users and groups listed in the dialog box have an ACE defined for the folder, but that doesn't necessarily mean they have any access to the folder. If the Deny permission is assigned, that user or group will not be able to access the object-even if they have also been granted access through another group membership.

click to expand
Figure 2.1: Windows Server 2003 represents ACLs by listing the permissions assigned to users and groups

Effective Permissions

Calculating a user's effective permissions requires more than simply looking up that user's name in the ACL. ACEs can assign rights directly to the user, or they can assign rights to a security group or a special group. Additionally, users can be members of multiple groups, and groups can be nested within each other. Therefore, a single user can have several different ACEs in a single ACL. To understand what a user's effective permissions will be, you must understand how permissions are calculated when multiple ACEs apply to the user.

Permissions that are granted to a user, or the groups to which the user belongs, are cumulative. If Mary is a member of both the Accounting group and the Managers group, and the ACL for a file grants Mary's user account Read privileges, the Accounting group Modify privileges, and the Managers group Full Control privileges, Mary will have Full Control privileges. There's a catch, though. ACEs that deny access always override ACEs that grant access. Therefore, if the Accounting group is explicitly denied access to the file, Mary will not be able to open the file. Even though Mary is a member of the Managers group, and the Managers group has Full Control privileges, the Deny ACE means that all members of the Managers group will be denied access to the file.

See Also 

Groups are described in more detail later in this chapter.

If no ACEs in an ACL apply to a user, that user will be denied access to the object. In other words, not explicitly having privileges to an object is exactly the same as being explicitly denied access.

Tip 

By default, the Everyone special group is assigned permissions to most objects on the system. Users automatically become members of the Everyone group when they authenticate. This process will be described in more detail later in this chapter.

Inheriting Permissions

When you assign permissions directly to an object, you create an explicit permission. Assigning explicit permissions to every individual folder, file, registry value, and Active Directory object would be a ponderous task. In fact, managing the massive number of ACLs that would be required would significantly impact the performance of Windows Server 2003.

To make managing permissions more efficient, Windows Server 2003 includes the concept of inheritance. When Windows Server 2003 is initially installed, most objects only have inherited permissions. Inherited permissions propagate to an object from its parent object. For example, the file system uses inherited permissions. Therefore, each new folder you create in the root C:\ folder will inherit the exact permissions assigned to the C:\ folder. Similarly, each subkey you create in the HKEY_LOCAL_MACHINE\SOFTWARE\ key will inherit the exact permissions assigned to the parent key.

Security Alert 

Explicit Allow permissions always override inherited Deny permissions.

After you set permissions on a parent object, new child objects automatically inherit these permissions. You can override this default behavior, however. Using the file system as an example, if you do not want child folders to inherit permissions, click the Advanced button on the Security tab of the folder's properties dialog box and use the Advanced Security Settings dialog box to add permissions. Then select This Folder Only in the Apply Onto list when you specify permissions for the parent folder, as shown in Figure 2.2. To specify permissions that do not apply to the parent folder, but exist only to be inherited, select Subfolders And Files Only, Subfolders Only, or Files Only. Other objects, such as the registry, provide similar functionality.

Tip 

If the Apply Onto list is dimmed, the permission was inherited from the parent. You can only change inheritance for explicit permissions.

click to expand
Figure 2.2: Permissions are inherited by default, but this behavior can be manually overridden

You can also control inheritance from the child objects. If you do not want a child object to inherit the parent's permissions, open the Advanced Security Settings dialog box and clear the Allow Inheritable Permissions From The Parent To Propagate To This Object And All Child Objects check box. You will be prompted to copy the inherited permissions to explicit permissions, or to simply discard the inherited permissions. If you choose not to copy the permissions, you will need to immediately assign explicit permissions so that users can access the object.

If you do disable inheritance on a child object and later want to re-enable inheritance, you can do so from the Advanced Security Settings dialog box of the parent folder. Simply select the Replace Permission Entries On All Child Objects check box, and Windows Server 2003 will remove all explicit permissions on all child objects and replace them with inherited permissions. This is an excellent way to recover files, folders, or registry values that users have made inaccessible by removing inherited permissions.

Standard and Special Permissions

Access control lists for the file system, registry, printers, services, and Active Directory can all be configured using both standard and special permissions. Special permissions are very granular and enable minute control over a user's access to an object. Standard permissions exist to make special permissions easier to manage. When you select a standard permission, Windows Server 2003 selects a set of special permissions that have been assigned to that standard permission.

Exam Tip 

Neither standard nor special permissions map directly to access control entries. However, for the sake of the exam, it's sufficient to understand that standard permissions are used to simplify management of special permissions.

The permissions available when you view the Security tab of a file or folder's properties dialog box are standard permissions. These include the Full Control, Modify, Read & Execute, Read, and Write standard permissions. If you grant Read & Execute standard permission, Windows Server 2003 automatically grants the List Folder/Read Data, Read Attributes, Read Extended Attributes, and Read Permissions special permissions. Similarly, if you deny the Read & Execute standard permission, the same special permissions are denied. You could choose to select those special permissions manually, but selecting the standard permission is more efficient.

File and folder permissions

As you learned in Chapter 1, file and folder permissions enable users to restrict access to content stored on NTFS volumes. You can grant access to open, edit, or delete files and folders. Files and folders also have the concept of ownership. The user who creates a file or folder is the owner of that object and by default has the ability to specify the level of access that other users have.

The following are the standard permissions that can be applied to files and folders:

  • Full Control. Users can perform any action on the file or folder, including creating and deleting files and folders, and modifying permissions.

  • Modify. Users can read, edit, and delete files and folders.

  • Read & Execute. Users can view files and execute applications.

  • List Folder Contents. Users can browse a folder.

  • Read. Users can view a file or the contents of a folder. If an executable file has Read but not Read & Execute permission, the user will not be able to start the executable.

  • Write. Users can create files in a directory, but not necessarily read them. This permission is useful for creating a folder in which multiple users can deliver files, without allowing the users to access each other's files or even see what other files exist.

  • Special Permissions. There are more than a dozen special permissions that can be assigned to a user or group. This permission shows as selected if the set of selected special permissions does not match a standard permission.

When any of these standard permissions are selected, Windows Server 2003 automatically selects one or more of the following special permissions:

Exam Tip 

You do not need to memorize special permissions for the exam. However, it is important to understand the relationship between standard permissions and special permissions.

  • Traverse Folder/Execute File. Traverse Folder, which applies only to folders, allows moving through folders to reach other files or folders, even if the user has no permissions for the traversed folders. Traverse Folder takes effect only when the group or user is not granted the Bypass traverse checking user right, which Everyone has by default. Execute File, which applies only to files, allows running program files. Setting the Traverse Folder permission on a folder does not automatically set the Execute File permission on all files within that folder.

    Tip 

    Some special permissions, such as Traverse Folder/Execute File and List Folder/Read Data, have a different effect depending on the object type to which the permission is applied.

  • List Folder/Read Data. List Folder, which applies only to folders, allows viewing file names and subfolder names within the folder. Read Data, which applies only to files, allows viewing the contents of a file.

  • Read Attributes. Allows viewing the attributes of a file or folder, such as read-only and hidden.

  • Read Extended Attributes. Allows viewing the extended attributes of a file or folder. Extended attributes are defined by programs and may vary by program.

  • Create Files/Write Data. Create Files, which applies only to folders, allows creating files within the folder. Write Data, which applies only to files, allows or denies making changes to the file and overwriting existing content.

  • Create Folders/Append Data. Create Folders, which applies only to folders, allows or denies creating folders within the folder. Append Data, which applies only to files, allows or denies making changes to the end of the file but not changing, deleting, or overwriting existing data.

  • Write Attributes. Allows changing the attributes of a file or folder, such as read- only or hidden.

  • Write Extended Attributes. Allows changing the extended attributes of a file or folder.

  • Delete Subfolders and Files. Allows deleting subfolders and files, even if the Delete permission has not been granted on the subfolder or file.

  • Delete. Allows deleting the file or folder. If you don't have Delete permission on a file or folder, you can still delete it if you have been granted Delete Subfolders and Files on the parent folder.

  • Read Permissions. Allows reading permissions of the file or folder, such as Full Control, Read, and Write.

  • Change Permissions. Allows changing permissions of the file or folder, such as Full Control, Read, and Write.

  • Take Ownership. Allows taking ownership of the file or folder. The owner of a file or folder can always change permissions on it, regardless of any existing permissions that protect the file or folder.

When you are editing file and folder permissions and you specify the Full Control standard permission, every possible special permission is added to the ACE for the user or group. When you specify the Modify standard permission, every special permission is assigned except the Change Permissions and Take Ownership special permissions. Selecting the Read & Execute standard permission adds ACEs for Traverse Folder/Execute File, List Folder/Read Data, Read Attributes, Read Extended Attributes, and Read Permissions special permissions. The standard Read permission is identical to Read & Execute, except that it lacks the Traverse Folder/Execute File special permission. Finally, the friendly Write standard permission grants Create Files/Write Data, Create Folders/Append Data, Write Attributes, and Write Extended Attributes special permissions.

Security Alert 

In the real world, you rarely have to deal with special permissions. In fact, you should avoid it whenever possible because it's more difficult to manage special permissions than standard permissions. Standard permissions are granular enough to meet all but the tightest security requirements.

To set, view, change, or remove special permissions for files and folders:

  1. Open Windows Explorer, and then locate the file or folder for which you want to set special permissions.

  2. Right-click the file or folder, click Properties, and then click the Security tab.

  3. Click Advanced, and then do one of the following:

    • To set special permissions for a new group or user, click Add. In the Name box, type the name of the user or group using the format domainname\name. When you are finished, click OK to automatically open the Permission Entry dialog box.

    • To view or change special permissions for an existing group or user, click the name of the group or user and then click View/Edit.

    • To remove a group or user and its special permissions, click the name of the group or user and then click Remove. If the Remove button is unavailable, clear the Allow Inheritable Permissions check box. The file or folder will no longer inherit permissions. Skip steps 4, 5, and 6.

  4. In the Permission Entry dialog box, click where you want the permissions applied in Apply Onto, if necessary. Apply Onto is available only for folders.

  5. In Permissions, click Allow or Deny for each permission.

  6. If you want to prevent subfolders and files within the tree from inheriting these permissions, select the Apply These Permissions check box.

This book does not describe individual special permissions for other types of objects, nor how to edit them. However, the user interface for editing special permissions for other objects is similar to that for files and folders.

Active Directory permissions

If you are familiar with other user databases, you will probably be surprised to learn that every object within Active Directory can have unique permissions assigned. Just as each folder and file in a file system has its own permissions, each organizational unit (OU) and user in Active Directory has permissions. This isn't the case with the local user database present in Windows Server 2003 member computers. However, Active Directory is much more than a simple user database, and configuring object permissions is important not only for security reasons, but to ease management of Active Directory.

The most common permissions-related task is to delegate administrative control over portions of Active Directory. This reduces the workload placed on a single administrator because other members of the support team can manage portions of Active Directory without handing them the keys to the corporate network. The most efficient way to assign permissions to objects in Active Directory is to open the Active Directory Users And Computers console, right-click the object, and then click Delegate Control. You can also assign permissions to objects by using ADSI Edit. To use ADSI Edit, open a blank Microsoft Management Console (MMC) console and add the ADSI Edit snap-in.

Following are the standard permissions that can be applied to Active Directory objects:

  • Full Control. Users can perform any action on the Active Directory object, including creating and deleting new child objects and modifying permissions.

  • Read. Users can view all object properties, the object permissions, and the object's contents (if any).

  • Write. Users can edit object properties.

  • Create All Child Objects. If the object is a container, such as an organizational unit, users can create any type of child object in the container. You can use special permissions to limit the types of objects that a user can create. For example, special permissions can be used to allow a user to create users, but not groups or computers.

  • Delete All Child Objects. If the object is a container, such as an organizational unit, users can delete any type of child object in the container. You can use special permissions to limit the types of objects that a user can delete. For example, special permissions can be used to allow a user to delete users, but not groups or computers.

  • Special Permissions. There are more than twenty special permissions that can be assigned to a user or group. This permission shows as selected if the set of selected special permissions does not match a standard permission.

As with other types of objects, selecting standard permissions selects one or more special permissions. The special permissions that can be assigned to Active Directory objects are quite complex, however. While many environments require very granular control over Active Directory permissions, the details of each special permission are not likely to be covered in this exam.

It's important to understand access control on Active Directory objects. However, you should avoid changing the permissions whenever it is not absolutely required by your applications or your environment's security requirements. If you do need to modify the permissions, do so carefully. A user who intentionally or accidentally changes Active Directory objects, or the permissions assigned to those objects, can quickly affect many users and applications on the network.

Specifying too many explicit permissions on Active Directory objects can cause performance problems, particularly in environments with multiple domain controllers. Active Directory objects, and the ACEs associated with the assigned permissions, must be replicated between domain controllers. Therefore, the more permissions you assign, the longer replication will take, and the more significant impact replication will have on your network.

Registry permissions

The registry stores the bulk of configuration information for both the operating system and applications. Being able to control registry permissions is important. In some cases, you should restrict permissions to prevent users from modifying registry keys that could present a security vulnerability or cause other problems on their computers. In other cases, you may want to grant users additional permissions to parts of the registry to allow them to run applications that they could not otherwise run. You can assign permissions to the values and keys in the registry by using the registry editor. To edit permissions within the registry editor, right-click the registry key, and then select Permissions.

Following are the standard permissions that can be applied to registry keys and values:

  • Full Control. Users can perform any action on the registry key or value, including creating and deleting new values and subkeys.

  • Read. Users can view values and subkeys, but cannot create, delete, or edit them.

  • Special Permissions. There are more than ten special permissions that can be assigned to a user or group. This permission shows as selected if the set of selected special permissions does not match a standard permission.

Service permissions

Service permissions are among the least frequently used permissions, but they can be useful in some environments. If your organization has separate groups that manage various services on a computer, you can grant the members of those groups the ability to control only the permissions that they manage. For example, you could grant the team responsible for managing your Web site access to restart the World Wide Web Publishing Service without allowing them to stop the Terminal Services service.

You might expect to modify service permissions by using the Services console. There's no user interface for modifying permissions in the Services console, however, so you have to use the System Services node in a security template. Security templates are discussed in more detail in Chapter 3, 'Deploying and Troubleshooting Security Templates.'

Following are the standard permissions that can be applied to services:

  • Full Control. Users can perform any action on the service, including starting and stopping the service, modifying the service's permissions, and specifying whether a service starts automatically.

  • Read. Users can view the status, permissions, and dependencies of a service.

  • Start, Stop, And Pause. As you would expect, users can start, stop, and pause the service.

  • Write. Users cannot directly start or stop a service; however, they can specify whether the service is disabled, set to start manually, or starts automatically when the server reboots.

  • Delete. Users can delete the service.

  • Special Permissions. There are more than ten special permissions that can be assigned to a user or group. This permission shows as selected if the set of selected special permissions does not match a standard permission.

Printer permissions

Controlling access to printers is useful for specifying users who can manage the printers and the print queue. You can assign permissions to printers by using Printers And Faxes, viewing the printer's properties, and clicking the Security tab. The following are the standard permissions that can be applied to printers:

  • Print. The user can connect to a printer and send documents to the printer. By default, the Print permission is assigned to all members of the Everyone group.

  • Manage Printers. The user can perform the tasks associated with the Print permission and has complete administrative control of the printer. The user can pause and restart the printer, change spooler settings, share a printer, adjust printer permissions, and change printer properties.

  • Manage Documents. The user can pause, resume, restart, cancel, and rearrange the order of documents submitted by all other users. The user cannot, however, send documents to the printer or control the status of the printer. By default, the Manage Documents permission is assigned to members of the Creator Owner special group to allow users to manage their own print jobs. When a user is assigned the Manage Documents permission, the user cannot access existing documents currently waiting to print. The permission will only apply to documents sent to the printer after the permission is assigned to the user.

  • Special Permissions. There are only six special permissions for printers. Besides the standard permissions, there are permissions for Read Permissions, Change Permissions, and Take Ownership.

By default, members of the Administrators and Power Users groups have full access to printers, which means that the users are assigned the Print, Manage Documents, and Manage Printers permissions.

Share permissions

Use Windows Explorer to specify permissions for shared folders. To do so, right-click the shared folder, select Sharing And Security, and then click the Permissions button. The following are the standard permissions that can be applied to shared folders:

  • Full Control. Users can read, write, and change permissions on files and folders within the share if allowed to do so by file and folder permissions.

  • Change. Users can read and write to files and folders within the share if allowed to do so by file and folder permissions.

  • Read. Users can read files and folders within the share if allowed to do so by file and folder permissions.

Share permissions are simpler than other types of permissions, and there is no need for special share permissions. Share permissions are considered an additional layer of security above and beyond file and folder permissions. In most cases, you should rely on file and folder permissions to secure the file system, regardless of whether it will be accessed locally or across a network. Share permissions are primarily used on servers with FAT32 volumes, since FAT32 volumes lack the file system security of NTFS.

Practice: Denying Access Using Group Membership

In this practice, you will observe the method Windows Server 2003 uses to calculate effective permissions.

Exercise: Use Windows Explorer to Deny a User Access to a File

In this exercise, you will use Windows Explorer to configure permissions on a file on Computer1.

  1. Log on to the cohowinery.com domain on Computer1 using the Administrator account.

  2. Use the Active Directory Users And Computers console to create global security groups named GG Boston Accounting and GG Boston Managers.

  3. Use the Active Directory Users And Computers console to create a user account with the user name mgibson. Mary's full name is Mary Gibson. Assign the user account a complex password, and make Mary a member of the Administrators group.

    Note 

    We're making Mary a member of the Administrators group so that Mary can log on to a domain controller interactively.

  4. Start Windows Explorer by clicking Start, pointing to All Programs, pointing to Accessories, and then clicking Windows Explorer.

  5. Select the root of drive C, and then create a new folder named TK70-299. Double- click the new folder.

  6. On the File menu, click New, and then select Text Document to create a new file in the C:\TK70-299 folder. Name the file ACLTest.txt.

  7. Right-click the ACLTest.txt file, and then click Properties.

  8. Click the Security tab, and then click the Add button.

    The Select Users, Computers, Or Groups dialog box appears.

  9. Type Mary in the Enter The Object Names To Select field, and then click Check Names.

    Mary is replaced by the full user name, as shown in Figure 2.3.

    click to expand
    Figure 2.3: The ACEs assigned to Mary's account, and her group memberships, will determine the effective permissions

  10. Click OK.

    At the ACLText.txt Properties dialog box, notice that Mary Gibson has only Read and Read & Execute permissions.

  11. Click the Add button, and then add the Accounting group.

  12. Click the Accounting group, and then select the Modify check box in the Allow column.

  13. Click the Add button again, and then add the Managers group.

  14. Click the Managers group, and then select the Full Control check box in the Allow column.

  15. Click OK to return to Windows Explorer.

  16. Log off, and then log on to Computer1 again using the user name mgibson.

  17. Start Windows Explorer and navigate to the C:\TK70-299\ folder.

  18. In the right pane, double-click ACLTest.txt. The file should open in Notepad. Type Mary can edit this file. Save and close the file.

  19. Log off, and then log on to Computer1 again using the Administrator account.

  20. Start Windows Explorer. Right-click the ACLTest.txt file and click Properties.

  21. Click the Security tab, and then click Accounting. Select the Full Control check box in the Deny column, as shown in Figure 2.4.

    click to expand
    Figure 2.4: Deny ACEs override all ACEs that grant permissions

  22. Click OK.

    You are warned that you are setting a deny permissions entry that will override grant entries.

  23. Click Yes to return to Windows Explorer.

  24. Log off, and then log on again using the user name mgibson.

  25. Launch Windows Explorer and navigate to the C:\TK70-299\ folder.

  26. In the right pane, double-click ACLTest.txt.

    Notepad will open, but the contents of the file will not be displayed. Instead, you will see an Access Is Denied message.

  27. Click OK, and log off from the computer.

Lesson Review

The following questions are intended to reinforce key information presented in this lesson. If you are unable to answer a question, review the lesson materials and try the question again. You can find answers to the questions in the 'Questions and Answers' section at the end of this chapter.

  1. Sam is a member of both the IT group and the Administrators group. Sam is attempting to access a file with the following permissions:

    • Administrators: Grant Full Control

    • IT: Grant Modify

    What are Sam's effective privileges to the file?

    1. Full Control

    2. Modify

    3. Read & Execute

    4. Read

    5. Write

    6. None

  2. Sam is a member of both the IT group and the Administrators group. Sam is attempting to access a file with the following permissions:

    • Administrators: Grant Full Control

    • IT: Deny Full Control

    What are Sam's effective privileges to the file?

    1. Full Control

    2. Modify

    3. Read & Execute

    4. Read

    5. Write

    6. None

  3. Which of the following is a standard permission for a file or folder?

    1. Read Attributes

    2. Delete

    3. Read & Execute

    4. Take Ownership

Lesson Summary

  • Files and folders, shared folders, printers, services, Active Directory objects, Terminal Services connections, Windows Management Interface objects, and registry keys and values have similar, but not identical, authorization methods.

  • An access control list (ACL) defines who can access an object and what actions the users can take with the object. An ACL consists of multiple access control entries (ACEs). An ACE defines how a specific user or group is allowed to access an object.

  • ACEs can either grant or deny access. If a user, through group membership, has both Grant and Deny ACEs for a single object, the Deny ACE always takes precedence.

  • Explicit permissions are assigned directly to an object, while inherited permissions propagate to an object from its parent object. Using inherited permissions greatly simplifies managing permissions.

  • When editing permissions for most types of objects, Windows Server 2003 presents standard permissions. Standard permissions consist of one or more special permissions and serve to simplify permission management. Standard permissions are usually sufficient to provide the level of control you need over access to an object. Special permissions should only be assigned when you have extremely granular access control requirements.



 < Day Day Up > 



MCSA(s)MCSE Self-Paced Training Kit Exam 70-299 (c) Implementing and Administering Security in a M[.  .. ]twork
MCSA/MCSE Self-Paced Training Kit (Exam 70-299): Implementing and Administering Security in a MicrosoftВ® Windows Server(TM) 2003 Network (Pro-Certification)
ISBN: 073562061X
EAN: 2147483647
Year: 2004
Pages: 217

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net