Modifying Permissions for Objects in an OU

When a user logs in to a Windows Server 2003 domain, the user account is authenticated; it is checked to make sure that the user has an account in the domain, and that the user is actually who he or she claims to be. This initial authentication process results only in the user gaining access to the network; there still has to be a mechanism in place to determine what access the user has to objects in Active Directory.

Security Descriptors

Every Active Directory object has a security descriptor attached to it that describes the type of access allowed by specific entities. The security descriptor is automatically created with the object. These security descriptors are what Windows Server 2003 uses to control access to Active Directory objects. This method of access control is an example of an object-based security model.

Security descriptors are structures that are made up of four components:

• Owner SID Windows Server 2003 uses the owner Security Identifier (SID) to identify users, groups, and other objects. Although we refer to a user as [e-mail], Windows Server 2003 uses a string of alphanumeric characters to uniquely identify the same object. SIDs are unique and are never reused. Even if the object is deleted and re-created with the same name, it will receive a new SID.

• Group SID This is required for POSIX and the Services for Macintosh, but is not used by Active Directory.

• DACL In Active Directory, every object has an owner. Typically, the owner will be the user or the process that created the object. The owner of the object can control who has access to the object through the use of an Access Control List (ACL). An Access Control List is the list of users who can access the object and the specific actions that the user can perform on the object. Each entry in the list is known as an Access Control entry (ACE)

• SACL The System Access Control List (SACL) stores the system security policies such as logging and auditing.

Some Active Directory objects will have an ACL that controls the entire object and will also have individual ACLs that control access to individual attributes of the object. This allows an administrator to control not only which users can see an object, but also what attributes of that object each individual user can see.

An example of this is an employee list. All users would have read access to the standard fields, such as name, location, telephone numbers, and so on, but the owner of the object would have full control for all the attributes in the listing, including some attributes that ordinary users would not know exist, such as salary history, employee rating, and the like. Access control could also be configured so that individual users could also update the common attributes of their own object.

Permissions

As you can see, access control in Active Directory can be controlled at a granular level. The access to objects is controlled by permissions. Permissions are what define the type of access that is granted to a user for an object or attribute. The owner of an object can grant any user or security group permission to do to the object whatever the owner is authorized to do with it.

Different types of objects will have different permissions, depending on the function of the object. For example, you wouldn't assign read permission to a printer.

The basic security model in Windows Server 2003 is similar to the one used in previous versions of Windows. In Windows Server 2003, you are allowed to allow or deny various levels of permissions for objects. All permissions are cumulative. This means that if a user is a member of two groups, one with read permission to an object and the other group with write permission, that user would have both read and write permission for the object.

Permissions can be allowed or denied. Similar to previous versions of Windows where No Access always overrides any other permissions, in Windows Server 2003 the Deny permission overrides any other permission that is granted to the object. An example is the situation where a user is a member of three groups, all of which have read access to a folder. If that user becomes a member of another group that has been denied any access to that folder, the single denied permission will override several allowed permissions, so the user will no longer have any access to the folder.

Although Active Directory permissions seem to be the same as the New Technology File System (NTFS) permissions that we discussed in previous chapters, there are some differences, especially in the area of implicit and explicit permissions. For example, if you deny a user access to an object, you have explicitly denied access to that object. However if you neither grant nor deny a user access to an object, by default, access is implicitly denied. In Active Directory, a user will have access to an object only if it is explicitly permitted.

Active Directory objects in Windows Server 2003 use two types of permissions: Standard and Special. The Standard permissions are the same as in previous versions of Windows:

• Read

• Write

• Create All Child Objects

• Delete All Child Objects

• Full Control

Special permissions are the components of the standard permissions. All the individual permissions that make up the write permission, such as list, read, write all properties, and so on are available separately as Special permissions. This permits a very granular level of access to an object.

Assigning Permissions to Active Directory Objects

In Windows Server 2003, the permissions for objects and their attributes are configured using the Active Directory Users and Computers snap-in. All permissions for objects are configured from the Properties window of the object, via the Security tab. However, the default in Windows Server 2003 is for the Security tab to not be displayed.

To be able to see the Security tab, follow the procedure in Step by Step 8.1.

Step by Step

8.1 Enabling the Security tab in Active Directory Users and Computers

1.	Click Start, Programs, Administrative Tools, and select Active Directory Users and Computers.
2.	From the system menu select View, and then select Advanced Features.
3.	Right-click the Computers container and select Properties from the pop-up menu. Notice in Figure 8.1 that the Security tab is now present.

Figure 8.1. Enabling Advanced Features in the Active Directory Users and Computers MMC allows you to view additional options.

After you do this, notice that it also causes several new containers to appear: ForeignSecurityPrincipals, Lost and Found, and System and NTDS Quotas.

Now that you have selected Advanced Features and turned on access to the Security tab, let's look at some of the settings that allow you to control access to Active Directory objects. We will start by going to one of the OU containers and selecting a user, and then changing the access that has been granted to the user.

In Step by Step 8.2, we will modify the permissions on one of the objects that we created in the exercises in Chapter 2.

Step by Step

8.2 Modifying permissions for an Active Directory object

1.	Open the Active Directory Users and Computers MMC.
2.	From the main window of Active Directory Users and Computers, click to open the Kansas City container, and then open the Users container underneath it.
3.	Right-click one of the user objects in the right pane, and then select Properties from the pop-up menu.
4.	Click the Security tab. From the Security tab, we can see what permissions have been granted for this user object. By selecting an entry in the top window, the permissions granted to that user or group will be displayed in the bottom window.
5.	Select the SELF entry in the top window. In Figure 8.2 you can see that the user has read access to most properties, but will be allowed to change personal information. Click the Advanced button. Figure 8.2. The Active Directory Users and Computers MMC showing the permissions for the user.
6.	This opens the Access Control Settings window. Click the entry SELF, and then select Edit.
7.	This opens the Permission Entry window, shown in Figure 8.3. It opens on the Object tab. This window shows the permissions that apply to this object only. In other words, any changes here will apply only to the selected user object. Figure 8.3. The Active Directory Users and Computers MMC showing the permissions for the user object.
8.	Select the Properties tab. This window shows the individual attributes that make up the user object. In other words, each individual field in the record in Active Directory for the user is displayed here, and you can control what the user can do to his object, or even whether the user can see these fields.
9.	Select the Allow check box for the Read All Properties entry. Notice that the one selection automatically selects the read permission for all the other fields for the object, as shown in Figure 8.4. Figure 8.4. The Active Directory Users and Computers MMC showing the effect of selecting the Read All Properties check box.
10.	Click OK to close the Permission Entry window. Then click OK twice to get back to Active Directory Users and Computers.

In most cases, the standard permissions will be sufficient for most object access. However, in some situations, granting one of the standard access permissions will give users more access than you think they should have. In that situation, you can assign a user Special Permissions. Special permissions are the component parts of standard permissions. They are far more granular than standard permissions. In Step by Step 8.3, we will grant a user the ability to read the Department field of user objects instead of granting the full standard permission to read most fields of the object.

Step by Step

8.3 Granting Special Permissions for an Active Directory object

1.	Open the Active Directory Users and Computers MMC.
2.	From the main window of Active Directory Users and Computers, click to open the Kansas City container, and then open the Users container underneath it.
3.	Right-click one of the user objects in the right pane, and then select Properties from the pop-up menu.
4.	Click the Security tab.
5.	Click the Add button. In the Select Users dialog box, select one of the other domain user accounts, and then click OK. Back at the user Properties dialog box, you can see in Figure 8.5 that the user you just added was automatically granted read access to most properties. Click the Advanced button. Figure 8.5. The added user is automatically granted read permissions for the user account.
6.	This opens the Access Control Settings Window. Click the entry for the added user, and then select Edit.
7.	This opens the Permission Entry window; from there select the Properties tab. Notice in Figure 8.6 that Read All Properties is selected. Figure 8.6. The Read All Properties selection is the default.
8.	Click the Clear All button. Scroll down in the window and select Read Department.
9.	Click OK to close the Permission Entry window. Then click OK twice to get back to Active Directory Users and Computers.

As mentioned earlier, the network administrator has granular control over Active Directory objects. However, it can easily become a management nightmare trying to keep up with and document the changes to specific attributes of unique objects. To help manage these types of changes, the network administrator should turn on auditing of permissions changes. We cover auditing in Chapter 16.

Permissions Inheritance

To help simplify the management of permissions in Active Directory, Microsoft has used a method called Permissions Inheritance. This allows you to set access permissions on a parent object, and then allow the permissions to be automatically propagated to the child objects. In Windows Server 2003, when the access permissions on a container are changed, the changes are inherited by both existing objects and any newly created objects within that container.

The default for Windows Server 2003 is for Permissions Inheritance to be turned on, but it can be turned off at the object or container level by de-selecting a check box on the Properties window of the object or container (see Figure 8.7).

Figure 8.7. Permissions Inheritance can be turned on or off via the check box.

When you deselect the check box, you will be presented with the following options:

• Copy Inherited Permissions This will leave any inherited permissions in place. However, no new permissions set at the parent level will be inherited.

• Remove Inherited Permissions This will remove any existing permissions that were inherited from the parent. You will need to explicitly grant any permissions desired.

Moving AD Objects

Objects can be easily moved between OUs in Active Directory. This type of task is commonly performed when a user gets transferred to a new department or location or when two departments merge and their resources such as computers and printers have to be combined into one OU.

To move a user or other object to another OU, follow the procedure in Step by Step 8.4.

Step by Step

8.4 Moving an Active Directory object

1.	Click Start, Programs, Administrative Tools, and select Active Directory Users and Computers.
2.	Click the desired domain, and then click the container of the OU in which the user you want to move is located.
3.	In the right pane of the window, right-click the name of the user to be moved, and then select Move from the pop-up menu.
4.	In the Move dialog box, select the folder to which you want to move the user, and then click OK.

Note: Drag and Drop

Starting in Windows Server 2003, you can use drag and drop to move objects in Active Directory.

This procedure is identical for users, groups, computers, and shared folders.

There are a couple of conditions relating to permissions that you need to be aware of when moving Active Directory objects:

• Permissions that were inherited from the previous OU will no longer apply. All the permissions applicable in the new OU will apply.

• Any permissions that were granted specifically to the object will remain the same.

Note: Dsmove

To move or rename objects from the command line, use the dsmove utility. This utility is discussed in Chapter 2 in the section "Moving or Renaming Objects with dsmove."

The Active Directory Users and Computers snap-in cannot be used to move users between domains. For interdomain moves, use the Active Directory Migration Tool (ADMT). The ADMT is used to move objects from one domain to another. The ADMT is located in the \I386\ADMT folder of the Windows Server 2003 Server CD-ROM.

Effective Permissions

With all the permissions and special permissions in Active directory, it can get confusing trying to figure out who has access to what, and exactly what access they have.

Windows Server 2003 includes the Effective Permissions tool. This tool automatically looks at a user's permissions and the permissions of the groups of which the user is a member to calculate the effective permissions for an object in Active Directory.

To determine the Effective Permission on an object, the user using the tool must have the Read Membership permission on all objects in Active Directory. In a Windows Server 2003 domain running in pre-Windows 2000 access compatibility mode, all domain users have this permission by default. If the domain is running in Windows Server 2003 mode, only the domain administrators will have the necessary permissions.

Exam Alert: Permissions for Effective Permissions

During the Dcpromo process, you are prompted as to whether you want to set permissions compatible with pre-Windows 2000 server operating systems. This selection adds the Everyone group to the Pre-Windows 2000 Compatible Access group, and thereby grants the Everyone group read access to most Active Directory objects. If you do not select this option, the Pre-Windows 2000 Compatible Access group is created, but it is empty. In this case, only domain administrators can use the Effective Permissions tool for Active Directory objects.

To view the effective permissions for an object, follow the procedure outlined in Step by Step 8.5.

Step by Step

8.5 Viewing the Effective Permissions of an Active Directory object

1.	Open Active Directory Users and Computers and navigate to the object for which you want to view permissions.
2.	Right-click the object, select Properties from the pop-up menu, and click the Security tab in the resulting dialog box.
3.	From the Security tab, click the Advanced button.
4.	The Advanced Security Settings dialog box appears. Select the Effective Permissions tab.
5.	The Effective Permissions tab appears, as shown in Figure 8.8. This page allows you to display the effective permissions of the object for a user or group. Click the Select button. Figure 8.8. The Advanced Security Settings dialog box, showing the Effective Permissions tab.
6.	The Select User or Group dialog box appears. Enter the desired user or group and then click the OK button.
7.	This returns you to the Advanced Security Settings dialog box. The Effective Permissions for the user are shown. Click OK here and in the Object Properties dialog box to quit.

Note: More Info

For more information on Effective Permissions (also know as the TGGAU attribute), consult the Microsoft Knowledge Base at http://support.microsoft.com/kb/331951.

Remember: When assigning permissions, even though Windows Server 2003 gives you the capability to configure permissions at a granular level, use this capability only when absolutely necessary. As we discussed previously, when you're working with users and groups, it is far easier to manage permissions when they are assigned at a group level. This allows you to add or remove members of the group, instead of having to try to configure each user the same way. The same philosophy applies to configuring permissions on individual attributes of objects. Whenever possible, control access to the individual attributes of objects at the container level so that you have to perform the configuration only once.

Another advantage of configuring permissions changes at the group or container level is that it can be done using the Delegation of Control Wizard. This wizard makes it very easy to make permissions changes to Active Directory objects and containers. We will be looking at this wizard in the next section.

Challenge

You are a system administrator who is responsible for managing all Active Directory resources for your company. One of the department heads has stopped by your office and expressed concerns that a secretary in his department has too much access to user accounts in the Active Directory. He feels that she should not have access to the home telephone number field in the user account.

While you don't recall granting this individual access to that specific attribute, she was granted access to some fields for updating purposes. You need to verify what access she does have.

How would you accomplish this in Windows Server 2003? On your own, try to develop a solution that would involve the least amount of downtime and expense.

For a possible solution, follow the procedure outlined here.

1.	Open Active Directory Users and Computers and navigate to the user for which you want to view permissions.
2.	Right-click the object, select Properties from the pop-up menu, and click the Security tab in the resulting dialog box.
3.	From the Security tab, click the Advanced button.
4.	The Advanced Security Settings dialog box appears. Select the Effective Permissions tab.
5.	The Effective Permissions tab appears. Click the Select button.
6.	The Select User or Group dialog box appears. Enter the name of the user you think has too much access, and then click the OK button.
7.	This returns you to the Advanced Security Settings dialog box. The Effective Permissions for the user are shown. Scroll down in the window to see if the user has been granted access to the Home Phone Number attribute.