Active Directory Object PermissionsEvery object in Active Directory has an access control list (ACL), which means that you can modify the permissions on that object. This includes objects visible through the Active Directory Users And Computers administrative console as well as objects visible through the Active Directory Sites and Services administrative console, ADSI Edit, or Ldp.exe. The most common tool used to modify Active Directory object access is Active Directory Users And Computers. However, each of the previously mentioned tools can be used to perform the common task of managing object access within the directory service. Show
Access control permissions on an Active Directory object are separated into two categories: standard permissions and special permissions. Special permissions are granular options that can be applied to an object. A standard permission is made up of a group of special permissions to allow or deny a specific function. For example, the Read standard permission is made up of the Read permissions, List contents, and Read all properties special permission entries. Standard PermissionsTo view the standard permissions for any Active Directory object in the domain directory partition, access the Security page for that object’s Properties sheet in the Active Directory Users And Computers administrative console. The Security page displays the group or user names that are assigned permissions to the object. As you select a group or user entry, the associated allow or deny permissions for that entry are shown. Figure 9-3 illustrates the permissions for the Domain Admins group on the Sales organizational unit. Notice that, by default, the Allow box is checked for each permission to provide the Domain Admins group full control over the Sales OU. Figure 9-3 Viewing the Security page on an Organizational Unit object. Depending on the type of object being secured, you will notice that different permissions may be visible on the security page. For example, the following standard permissions are common with all objects:
Some Active Directory objects also have standard permissions that are applied to grouped sets of properties. For example, a user object has several read-and-write property sets such as General Information, Personal Information, Phone And Mail Options, and Web Information. Each of these property sets refers to a set of object attributes, so granting access to a single property set provides access to a set of attributes. For example, the Personal Information property set includes attributes such as homePhone, homePostalAddress, and streetAddress. Using the property sets to assign access to groups of attributes simplifies the process of assigning permissions without having to modify at the granular attribute level. Special PermissionsOne of the entries in the permissions list on the Security page is Special Permissions. In addition to being able to grant standard permissions, you can also grant special permissions to Active Directory objects. As mentioned previously, special permissions are much more granular and specific than standard permissions. To simplify management, you would typically use standard permissions on an object; however, there may be specific needs that require you to modify the special permission entries. To get access to special permissions, click Advanced on the Security page and then ensure that the Permissions page is selected. Figure 9-4 shows the interface. Table 9-2 explains the options available on the Permissions page. Figure 9-4 Viewing the Advanced Security Settings for an object. Table 9-2 Special Permissions Configuration
In many cases, the same security principals may be listed in multiple ACEs. For example, the Account Operators group has multiple Create/Delete entries for Computer objects, Group objects, User objects, Printer objects, and InetOrgPerson objects in separate ACEs. This happens whenever you specify a combination of permissions that cannot be stored within a single ACE. In this example, each ACE can only contain focus on one type of object (Computer, User, etc.), and cannot be combined into a single ACE. If you add or edit the permissions granted to a security principal, you are provided two different options for applying permissions. Figure 9-5 shows the first option, which is applying permissions to the object. Figure 9-5 Assigning special permissions to Active Directory objects. The Object tab is used to apply permissions to various object scopes:
The second option for applying permissions is to control access to the object properties. Figure 9-6 shows the interface. The Properties page is used to apply permissions for the security principal listed in the Name field to the individual properties for the object. For example, if you are applying permissions to a user object, you are given the option of assigning Read and Write permissions to each attribute available on the object class, such as general information, group membership, and personal information. Figure 9-6 Configuring an object’s property permissions. Permissions InheritanceAD DS uses a static permissions inheritance model. That is, when permissions are changed on a container object in the Active Directory structure, the changes are calculated and applied to the security descriptor for all objects in that container. Consequently, if permissions are changed higher in the Active Directory structure and these permissions are applied to all descendant objects, calculating the new ACL for each object can be a processor-intensive process. However, this initial effort means that the permissions do not need to be recalculated when a user or process tries to access the object. There are two primary methods that are used to control inheritance of permissions:
If you have designed your OU structure with the goal of delegated administration, you will have created an OU structure in which top-level administrators that require permissions to all Active Directory objects are granted permissions high in the hierarchy with delegated permissions to all descendant objects. As you move further down the hierarchy, you may be delegating permissions to other administrators who should only have control over a smaller part of the domain. For example, Figure 9-9 shows the Sales OU. Within the Sales OU are two child OUs called Eastern Sales and Western Sales. The manager who is in charge of the entire Sales division may be delegated permissions to the entire Sales OU object and all descendant objects, whereas the Eastern Sales or Western Sales managers may be delegated permissions to their own specific OU only. Figure 9-9 Delegating management of the Sales OU. In some cases, however, you may want to block higher-level administrators from having any administrative permissions to a specific child OU. For example, if you create a child OU for a branch office in your company, you may assign a local administrative group full control of the OU. However, you may not want those local administrators to have access to any executive user accounts in the OU. To limit their access, you can create an Executives OU within the branch office OU and then remove the option to include inheritable permissions from the object’s parent. This, in effect, blocks permissions inheritance at the Executives OU level. To block the inheritance of permissions on an Active Directory object, access the Advanced Security Settings dialog box for the object (shown in Figure 9-4). Then clear the Include Inheritable Permissions From This Object’s Parent option. When you clear this option, you are presented with the choice to copy the existing permissions or remove all permissions before explicitly assigning new permissions, as shown in Figure 9-10. Figure 9-10 Selecting the option to copy or remove permissions when blocking permissions inheritance. Blocking inheritance has the following implications:
Effective PermissionsAs discussed so far in this chapter, a user can obtain permissions to a specific object in Active Directory in several ways:
All of these permissions are cumulative; that is, the user is granted the highest level of permissions from any of these configurations. For example, if a user is explicitly given Read permission to an object, the user belongs to a group that is explicitly given Modify permissions, and the user belongs to a group that is given Full Control at the container level, the user will have Full Control. When a user attempts to access an object, the security subsystem examines all of the ACEs that are attached to the object. All of the ACEs that apply to the security principal (based on user account or group SIDs) are evaluated and the highest level of permission is set. However, in addition to ACEs that grant permissions, Active Directory also supports Deny permissions. Deny permissions can be applied at two levels:
Deny permissions almost always override Allow permissions. For example, if a user is a member of a group that is given Modify permissions to an Active Directory object, and the user is explicitly denied Modify permissions to the object, the user will not be able to modify the object. This is because the ACEs that deny permissions are evaluated before the ACEs that allow permissions. If one of the ACEs denies permission to the security principal, no other ACEs are evaluated for the object. The one situation in which Allow permissions do override Deny permissions is when the Deny permissions are inherited and the Allow permissions are explicitly assigned. For example, you can deny a user the permission to modify any user accounts in a container. But, if you explicitly allow Modify permissions to an object within the container, the user account will have Modify permissions on that object. As you can see, configuring security on Active Directory objects can involve managing a large number of interrelated variables. Many companies may start out with a fairly simple security design in which a small group of administrators are given all the permissions in Active Directory. Most of the time, the initial Active Directory security configuration is clearly documented. However, as time goes by, this simple initial configuration often becomes much messier. Sometimes another group of administrators is given a set of permissions for a specific task and for a specific period of time. Granting the permissions is easy to do, but often the permissions are never removed. Often these security modifications made after the initial deployment are also not clearly documented. For any Active Directory structure that has been deployed for some time, the current security configuration is likely more complex than was initially designed. Sometimes this results in users having more permissions than they should have. Fortunately, Windows Server 2008 provides a tool that can be used to easily determine the effective permissions a security principal has to any object in Active Directory. To determine the effective permissions that a security principal has on an Active Directory object, access that object’s properties through the appropriate Active Directory administrative tool. Click the Security page, click Advanced, and then click the Effective Permissions page. To determine the effective permissions for a specific user or group account, click Select and then search for the user or group name. After you have selected the name, click OK. The Effective Permissions page displays all of the permissions the security principal has to the Active Directory object. Figure 9-11 shows the interface for the Active Directory Users And Computers administrative tool. Notice that the Effective Permissions page for the Sales OU displays the overall permissions assigned to the Don Hall user object. Figure 9-11 Displaying the effective permissions for an Active Directory object. Ownership of Active Directory ObjectsEvery object in Active Directory has an owner. By default, the user who created an object is the owner. The owner of an object has the right to modify permissions on the object, which means that, even if the owner does not have full control of an object, the owner can always modify the permissions on the object. In most cases, the owner of an object is a specific user account rather than a group account. One exception to this is when an object is created by a member of the Domain Admins group; the ownership of the object is then assigned to the Domain Admins group. If the owner of the object is a member of the local Administrators group but not a part of the Domain Admins group, the ownership of the object is assigned to the Administrators group. To determine the owner of an Active Directory object, access that object’s properties using the appropriate Active Directory administrative tool. Select the Security page, click Advanced, and then select the Owner page. Figure 9-12 shows the interface for the Active Directory Users And Computers administrative tool. If you have the Modify owner permission to the object, you can use this interface to modify the owner of the object. You can chose either to take ownership for your own account or to assign the ownership to another user or group. This last option is unique in Windows Server 2003 And Windows Server 2008 Active Directory. In Microsoft Windows 2000 Active Directory, you could only take ownership of an object; you could not assign the ownership to another security principal. Figure 9-12 Viewing the ownership of an Active Directory object. Which execution mode has unrestricted access to the underlying hardware?In Kernel mode, the executing code has complete and unrestricted access to the underlying hardware. It can execute any CPU instruction and reference any memory address. Kernel mode is generally reserved for the lowest-level, most trusted functions of the operating system.
In which multi tasking mode can an operating system take control of the processor without consent from the task?Preemptive multitasking differs from non-preemptive multitasking in that the operating system can take control of the processor without the task's cooperation. (A task can also give it up voluntarily, as in non-preemptive multitasking.) The process of a task having control taken from it is called preemption.
Which method scans systems to identify common security misconfigurations and missing security updates?MBSA can be used to improve your security management process by analyzing a computer or a group of computers and detecting missing patches/updates and common security misconfigurations. After you run a MBSA scan, the tool will provide you with specific suggestions for remediating security vulnerabilities.
What creates and manages and exports for deployment security policies across multiple Windows operating systems roles and Microsoft applications?The Security Compliance Manager is a downloadable tool that helps you plan, deploy, operate, and manage your security baselines for Windows client and server operating systems, and for Microsoft applications.
|