Understanding Active Directory Object Permissions

 < Day Day Up > 



In Active Directory, every object has its own security descriptor that specifies which accounts have permission to access the object as well as what type of access is permitted. The object permissions are what provide you with the capability to control who can access individual objects or an object’s attributes within the directory. Typically, you will use permissions to assign privileges to an organizational unit; however, you can assign permissions to any single object.

Active Directory has several types of permissions; the standard permissions are composed of those that are the most commonly assigned. Table 5.2 lists the standard permissions.

Table 5.2: Active Directory Standard Permissions

Permission

Description

Full Control

Includes Change Permissions and Take Ownership, as well as all other standard permissions

Write

Provides the ability to change an object’s attributes

Read

Provides the ability to view objects, object attributes, the owner, and the Active Directory permissions

Create All Child Objects

Provides the ability to create any type of object in a container, typically an organizational unit (OU)

Delete All Child Objects

Provides the ability to remove any type of child object from a container

The standard permissions are a logical combination of special permissions. The special permissions that are available are different depending on the resource that you are attempting to secure. They include Read Attributes, Read Extended Attributes, Write Attributes, Read Permissions, Change Permissions, etc. For example, if the resource that you are trying to secure is a file on an NTFS volume, you may grant a security group the special permission of Execute File.

Note

You can access the special permissions by clicking the Advanced button from the security tab of the object’s properties window.

Prior to a user gaining access to an object, an administrator or the object owner must grant permissions to the user. These permissions are stored in the DACL.

Active Directory object permissions can be granted or denied (either implicitly or explicitly), set as standard or special permissions, and set at the object level or inherited from a parent object.

Real World Scenario: Avoiding Deny Permissions

start example

Steve is the network administrator for a large management consulting firm. There are two types of partners that run the firm: equity and nonequity partners. Nonequity partners should have access to everything that equity partners can access with the exception of the firm’s financial information. To facilitate this access, Steve decides to create a Global group named All-Partners that has all of the partners’ accounts as members. In order to assure that the nonequity partners cannot view the financial information, he creates ACEs on the FinancialData folder for each of the nonequity partner’s accounts and denies each one the Read permission.

Over time, the nonequity partners may buy in to the firm and become full equity partners. When this occurs, Steve must remove the ACE denying the individual accounts. In addition to the administrative burden of managing these permissions on individual accounts, the more ACEs on an ACL, the worse the performance will be when accessing the folder.

In order to resolve these problems, Steve creates two additional Global groups: EquityPartners and NonEquityPartners. The EquityPartners group is granted the Read permission to the FinancialData folder and the NonEquityPartners group is not. This makes maintaining these groups in the future easy and it keeps the ACL on the FinancialData folder small.

end example

Deny permissions always take precedence over any other permission. The only time you would need to use a Deny permission is when a user is granted a permission elsewhere and needs to be trumped. Users are not allowed to access an object unless they have been granted access either directly or indirectly. Therefore, with proper planning, there should be little reason to deny a permission if it was never granted in the first place. Some organizations may require the explicit denial of a permission in order to guarantee that a user or group will never have access to a resource, even if the permission is granted in the future. This situation commonly arises when specific business rules must be maintained.

If a permission is not explicitly granted, it is implicitly denied. For example, if the Sales group is granted Read permission to a user object and no other principal is stored in the DACL for the printer object, users who are not members of the Sales group are implicitly denied access. An explicit Deny is when an ACE that states a denied permission is added to the DACL that states a denied permission. For example, you may have a user named Collin who is a member of the Human Resources group. The HR group is granted the ability to create and remove child objects for a specified OU; however, Collin should not be granted this right. You can prevent Collin from performing these actions by explicitly denying the Create All Child Objects and Delete All Child Objects permissions. While all other permissions are cumulative, combining anything with a Deny permission results in the permission being denied.

There are some other types of permissions that are available for Active Directory objects. In the following list, extended rights, validated writes, and property sets are all explained:

Extended rights Extended rights are used for special operations that apply to specific types of Active Directory objects. For example, the Active Directory right Send As applied to an Exchange Server right allows for a user or group to send mail as the specified mailbox.

Validated writes A validated write is different from a Write permission in that it evaluates the content of the write and determines if the value supplied conforms with the specified semantics. An example here is the Add/Remove Self As Member permission that applies to groups. This permission allows users to add or remove themselves as members of the group, providing a more granular level of control than just the ability to add and remove anyone from the group.

Property sets A property set is a group of interrelated attributes. The added value of property sets is that access rights can be granted to a property set as a whole rather than to individual attributes, which in turn improves the responsiveness and overall performance of the access control infrastructure. In addition to performance benefits, they also simplify security management. For example, there is a property set named Domain Password, which encompasses the following Domain attributes:

  • lockOutObservationWindow

  • lockoutDuration

  • lockoutThreshold

  • maxPwdAge

  • minPwdAge

  • minPwdLength

  • Pwd-Properties

As you can see, it is easier to grant a user the ability to manage the property set than to manage each individual attribute.

In the following Design Scenario, you will design an access control strategy for Active Directory objects.

Design Scenario: Designing an Access Control Strategy for Active Directory Objects

start example

You are the network administrator for a medium-sized business management company whose main office is located in Phoenix. The company also has offices in Philadelphia and Miami. There are no network administrators or any other IT staff members located in the satellite offices. The help desk is located in Phoenix, and you have noticed that there is a large volume of incoming calls from the remote users who need to have their passwords reset. You want to reduce the burden on the help desk and allow each of the satellite offices to have more autonomy as it relates to password lockout problems. Each office is configured as its own domain. The office manager at each location is reasonably computer savvy and the decision has been made to grant the office manager the ability to unlock accounts and configure the domain passwords to the requirements of the office.

  1. Question: Which of the following actions should you complete? (Choose the best answer.)

    • Assign each office manager the Domain Password permission set.

    • Add each office manager to the Domain Admins group for their domain.

    • Create a group named OfficeMgrs in each domain and grant the group the Domain Password permission set.

    • Create a Universal group in the domain named OfficeMgrs and grant it administrative permissions at the root domain container.

Answer: Based on the available options, the best solution is to use a permission set and assign it to a group. The first option would work, but it is always recommended that you assign permissions to groups, not to users directly. The second option would not work because it is never a valid solution to grant a user administrative privileges unless they require all of them. The last option also would not work because a Universal group is not required based on the specified scenario.

end example

Along the theme of ease of management, in the next section you will learn the best ways to design your security group infrastructure.

Designing a Security Group Strategy for Active Directory

As you learned in Chapter 4, there are different group types with different levels of visibility or scope across the domain or forest. In Active Directory, when in Windows 2000 Native mode or higher, you will have access to a new group scope: Universal.

Note

If the Active Directory mode is Windows 2000 Mixed, Universal groups are not available.

A Universal group can have members that include accounts, Global groups, and Universal groups from any domain and can be assigned permissions in any domain in the domain tree or forest.

Universal groups can be used to consolidate groups whose logical membership should span domains. In order to accomplish this, you add the accounts to Global groups in their respective domain and then nest the Global groups within Universal groups. This is the recommended strategy because changes in the membership of the Global group will not cause changes in the Universal group, which typically would require replication of the global catalog to each global catalog server in the forest.

With the addition of Universal groups to the AG(G)DLP guideline discussed in Chapter 4, the recommendation becomes AG(G)UDLP, as seen in the following list:

  1. Place (A)ccounts in (G)lobal groups.

  2. Optionally nest (G)lobal groups.

  3. Place (G)lobal groups into (U)niversal Groups.

  4. Place (U)niversal groups into (D)omain (L)ocal groups.

  5. Assign (P)ermissions to the (D)omain (L)ocal group

Real World Scenario: Taking Advantage of Universal Groups

start example

Thatcher is the network administrator for a large consulting company. The company’s Active Directory is made up of three domains: TJR.lan, east.TJR.lan, and west.TJR.lan. In each domain, there are human resource records that all HR personnel need to be able to modify. There are HR accounts in each of the domains and Thatcher wants to keep the ACLs short and easy to maintain. In addition, he needs to minimize replication traffic between domains.

Thatcher creates a global group in each domain—glCorpHR, glEastHR, and glWestHR—and then adds them to the dlHR domain local group in each domain. Each time membership changes in any of the Global groups, forestwide replication would be required. Also, the ACL would have three access control entries (ACEs).

To reduce replication, Thatcher creates a Universal group named uHR. He then adds the glCorpHR, glEastHR, and glWestHR Global groups to uHR. Next, Thatcher grants each of the dlHR Domain Local groups (one for each domain) the appropriate permissions on the HR data. Once that step is completed, he adds the uHR Universal group as a member the dlHR groups in each domain. Now as membership changes in the Global groups, replication will only need to occur within each domain and not between them.

end example

In the following Design Scenario, you will evaluate the scenario provided and create the appropriate groups to provide the required access.

Design Scenario: Planning an Appropriate Group Strategy

start example

You are the Windows Active Directory architect for a large toy manufacturer. Ralph needs to design a grouping strategy for the accountants in the toyshop.com domain. There are two domains: the headquarters, which is toyshop.com, and the U.S. business, which is US.toyshop.com. The company has been very successful and intends to expand into other countries in the future. You need to devise a strategy for your groups that provides the least administrative overhead with the maximum security. There are accountants in both domains and they are members of the AccountsReceivable and/or AccountsPayable Global groups in their respective domains. All accountants need access to the AccountsData share in each domain.

Question: From the following, choose the additional tasks you should complete in order to design the appropriate grouping strategy.

  • Create a Global group named glAccountants in each domain; add AccountsReceivable and AccountsPayable as members.

  • Create a Domain Local group named dlAccountsData in each domain; add the glAccountants groups as members.

  • Create a Universal group named AllAccountants; add glAccountants from each domain as members.

  • Create a Domain Local group named dlAccounts in each domain; add the Universal group AllAccountants as a member of the group.

  • Grant the Domain Local group dlAccounts in each domain the permissions to access the AccountsData folder.

  • Grant the Global group glAccountants permissions to both domains’ AccountsData share.

Answer: In order to adhere to the AG(G)UDLP guideline, you should create a domainwide Accounting group in each domain with the AR and AP groups as members. Each domain’s Global Accounting group should then be added to a Universal group, in this case named AllAccountants. In each domain, a Domain Local group should be created and granted permissions to the AccountsData share and the Universal group AllAccountants should be added to the Domain Local groups.

end example

Best Practices for Assigning Permissions to Objects

The following list includes some of the best practices that you should keep in mind when assigning permissions to Active Directory objects.

Avoid changing the default permissions on Active Directory objects. In some circumstances, unforeseen problems can occur or could lead to reduced security on the object(s).

Avoid assigning a security principal, user, or group Full Control of an object, especially an organizational unit. The Full Control permission includes the Take Ownership and the Change Permissions permission, which, if used improperly, can be exploited so that a user granted Full Control can assign another principal the permissions on the child objects in the hierarchy. As stated in Chapter 4, assign only the minimum required permissions (Principle of Least Privilege).

Limit the quantity of access control entries that apply to child objects. If you use the Apply Onto option when controlling inheritance, all of the child objects of those that you have specified will receive their own copy of the ACE. As the number of objects that receive copies increases, there can be significant performance issues across the network.

Assign the same set of permissions to multiple objects. Windows Server 2003 includes a feature called single-instancing with regard to access control lists. If several objects have identical ACLs, Active Directory will store only one instance of the ACL, thus preserving resources.

Assign access rights broadly instead of granularly. With a smaller number of access control entries, the overall system performance will increase. For example, you should use property sets rather than individual properties; doing so provides for a smaller number of ACEs. There are times when it is necessary to assign permissions to an individual property; however, you should try to minimize that granular a permission assignment.

Assign permissions to groups instead of user accounts. You can utilize groups to minimize administrative overhead and design flaws that can lead to a lowered overall security. You should use the AG(G)UDLP technique for the maximum blend of maintenance and security. Using groups also limits the overall quantity of ACEs on a given object. For example, you could use a single ACE to represent all managers rather than a single ACE for each user account that is a manager.

In the next section, you will learn about delegation and how you can use it in your Active Directory design to increase security.

Designing a Delegation Strategy

In a Windows NT 4 domain, in order to have the right to change a user’s password, you had to be a member of the Domain Administrators group (excluding third-party offerings). This solution posed a significant quandary: Do you give Domain Administrator permissions to users who should not normally have them, or do you require your upper-level domain administrator to take action each time a user needs to have their password reset. In most situations, neither result was acceptable. Delegation provides the ability to assign specific tasks to the appropriate users or groups without giving them any more rights than they require to perform the task you have delegated to them.

Active Directory facilitates the efficient management of its objects by allowing for the delegation of administrative control. Delegation of control is the ability to assign the responsibility of managing Active Directory objects to another user, group, or organization. By delegating control, you negate the need to have several high-level administrative accounts, because any user or group can be delegated control of an object without it being added to an administrator group.

You can delegate the permissions to create or modify objects in a specified organizational unit. For example, you can give the human resources department the ability to create and modify user accounts in Active Directory. You can also delegate the ability to modify specific attributes of an object, such as granting a group the ability to reset the passwords of users within a specific OU.

Delegating administrative control will lessen the administrative burden of managing the enterprise by distributing the administrative load across the entire organization. Taking advantage of delegation, you can increase the security of your organization by reducing the number of members in the administrative groups.

To delegate control for common administrative tasks, follow these steps:

  1. Open the Active Directory Users And Computers MMC and click the organizational unit for which you intend to delegate control.

  2. From the Action menu, select Delegate Control.

  3. The Delegation Of Control Wizard begins. On the Welcome page, click Next.

  4. From the Users Or Groups page, select the user or the group to which you want to grant permissions and then click Next.

  5. On the Tasks To Delegate page, select one or more of the following tasks to delegate:

    • Create, delete, and manage user accounts

    • Reset user passwords and force password change at next logon

    • Read all user information

    • Create, delete, and manage groups

    • Modify the membership of a group

    • Manage Group Policy links

  6. Click Next.

  7. From the Completing The Delegation Of Control Wizard page, click Finish.

In the “Delegating Permissions” Design Scenario, you will evaluate a scenario and determine the best use of delegation.

Design Scenario: Delegating Permissions

start example

You are the IT administrator of a large television marketing company that has over 15,000 employees nationwide. In addition to the offices in the U.S., there is a satellite office in Mexico City with 100 employees. The Mexican office is where all of the management training occurs, so the number of employees tends to fluctuate. There is only a single help desk support technician in the Mexico City office to support the employees who work from the office as trainers and support staff. All of the servers in all of the offices run Windows Server 2003, Enterprise Edition, and all workstations are running Windows XP Professional.

The users in the Mexico City office have been installing unauthorized software that has caused compatibility problems with one of the important line-of-business applications. You need to make sure that the users in Mexico City cannot install software themselves. Instead, only the Mexico City help desk technician should be able to install software on the workstations there. The help desk technician should also be able to create and manage all user, group, and computer accounts that are located in Mexico City.

The OU structure for the Mexico City site is displayed in the following graphic:

click to expand

  1. Question: You need to design a method to grant the Mexico City help desk technician the necessary permissions to perform his job. What should you do? Answer: You should delegate the required permissions to the Puerto Rico help desk technician account on the Puerto Rico OU.

end example



 < Day Day Up > 



MCSE. Windows Server 2003 Network Security Design Study Guide Exam 70-298
MCSE: Windows(r) Server 2003 Network Security Design Study Guide (70-298)
ISBN: 0782143296
EAN: 2147483647
Year: 2004
Pages: 168

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