Managing Permissions for NT 5.0's Active Directory

If you're eager to investigate the new features of Windows NT 5.0, the Active Directory (AD) will probably interest you. AD is a directory service that stores information about users, servers, printers, shares, and other elements in a network. AD represents these elements as objects, each of which has one or more sets of properties. For example, an object representing a user might have the properties of office and home phone numbers. (For more information about AD objects and properties, see Sakari Kouti, "Manage Directory Resources with Active Directory Service Interfaces," November 1997.)

Users can query AD to get lists of objects and their properties. However, you might not want users to have access to all the properties of every object in AD. For example, you might not want users to have access to coworkers' home phone numbers. Although the NT 5.0 system default is to give everyone read access to all of AD's information, you can modify and add to the default permissions to limit access to certain information.

To set the permissions for objects and properties in AD, you need to know how to create and search for objects. Knowing what is possible will help you decide what objects and properties to restrict permissions for.

Creating Objects
Suppose you have a domain controller running NT 5.0 beta 1 for your domain, nt5domain. The domain's AD contains the NT server and one client (a PC running NT Workstation 5.0 beta 1). NT 5.0 comes with Microsoft Directory Service Manager, a Microsoft Management Console (MMC) snap-in. (For more information about MMC, see Darren Mar-Elia, "Microsoft Management Console," June 1998.) Directory Service Manager lets you easily access AD. Although you can use other tools to view and manipulate data in AD, they are more complicated to use.

As with Explorer, when you open Directory Service Manager, you see a two-pane window. On the left is the scope pane; on the right is the display pane. The scope pane contains a directory information tree (DIT), which provides a map for AD. The DIT starts with the root entry (i.e., the domain name) and then branches into container objects (herein referred to as containers). Containers are objects that can hold other objects of the same type, or class. The class specifies the required and optional properties of the objects in a particular category and the rules governing where those objects fit in the DIT.

The display pane shows the contents of a container. To view the contents, single-click the container in the scope pane. Containers hold other containers and noncontainer objects (herein referred to as noncontainers). A noncontainer is an object that cannot hold other objects of the same class, so noncontainers cannot hold containers or other noncontainers.

You can assign permissions to only two types of noncontainers: users and groups. A user represents one person; a group represents the members you assign it.

Screen 1 shows the default containers and noncontainers in Directory Service Manager for nt5domain. The left pane shows that the domain consists of the Computers, System, and Users containers. Although these three types of containers are common, many more types exist, such as print queue, volume, site, and organizational unit. The right pane shows the contents of the System container, which consists of user and group noncontainers.

Directory Service Manager lets you add and remove containers and noncontainers to customize your AD. For example, suppose you want to add TestOU1 (a container representing your company's primary testing lab) and TestUser1 (a noncontainer representing a member of that testing lab) to nt5domain. To add the container, highlight nt5domain in the scope pane and right-click the display pane. In the pop-up menu that appears, select New organizational unit. Enter TestOU1 in the Create organizational unit dialog box, and click OK. After you refresh the display, you can add the noncontainer by highlighting the newly created TestOU1 container in the scope pane and right-clicking the display pane. In the pop-up menu that appears, select New user and enter TestUser1 as the username and first name, last name, and password. Click OK. If you want to specify properties for a container or noncontainer, you right-click on the object from either pane and select Properties from the pop-up menu. Screen 2 shows the properties for TestUser1.

You cannot put a noncontainer in more than one container. For example, you can't put a user noncontainer (MarySmith) in two containers (Systems and Users). However, you can put MarySmith in the Systems container and then create a group (DataEntryGroup), assign MarySmith as a member, and put the DataEntryGroup in the Users container.

Searching for Objects
Searching AD is easy. You use the Find tool from the NT 5.0 Start menu. The Find tool has a useful option, In The Directory, that lets you find objects based on their class and properties. This option lets you perform basic searches and more. You can search for printers in AD with a query such as: Show me all the color printers. When this search returns 400 entries, you can narrow the search by specifying that the printers must be in London. You can continue narrowing the search by specifying that the printers must be duplex capable and allow at least A3 paper size. With the option's Custom Search tool, you can find the user whose phone extension ends in 1234. With the option's Advanced search tool, you can perform Lightweight Directory Access Protocol (LDAP) queries. With such powerful search capabilities, users can easily access AD data.

If you think that these search capabilities might create the worst management nightmares you've ever faced, fear not. You can hide objects from users' searches by modifying the objects' permissions. Managing permissions is easy once you understand the basics of how to view and modify permissions.

Viewing Permissions
Before you can modify permissions, you need to find out the domain controller's default permissions for the domain, its objects, and the objects' properties. To view the permissions for nt5domain, open Directory Service Manager. Right-click nt5domain in the scope pane, and select Properties. In the nt5domain Properties dialog box that appears, select the Security tab. As Screen 3 shows, the Security tab lists various groups and users, such as Authenticated Users and Everyone. By highlighting a group or user, you can see its permissions. Groups and users will usually have at least one selected check box in the Allow column, but exceptions occur. For example, the Everyone group in Screen 3 appears to have no permissions. The text near the Advanced button, however, gives a clue that you need to investigate further.

Clicking Advanced leads you to the Access Control Settings dialog box, which specifies that the Everyone group has Special permissions for the root of the nt5domain tree. To find out what those permissions are, highlight Everyone and click View/Edit. In the dialog box that appears, you'll see two tabs: Object and Properties.

Object. As Screen 4 shows, for the Everyone group, the Object tab displays the permissions that apply to the root of the nt5domain tree and all its subobjects. According to Screen 4, members of the Everyone group can list and read all objects and their properties in entire tree.

Properties. As Screen 5 shows, the Properties tab displays the permissions for the properties of the root parent and each child. This screen lists the read and write permissions for every property of every object as applied to the entire tree.

Screens 4 and 5 show a root parent and its children, because the Object tab and Properties tab are presenting the broadest view possible. However, you can view AD objects and manage their permissions from any point in the tree. In addition, although Screens 4 and 5 show the permissions being applied to this object and all subobjects, you can view and manage the permissions being applied to narrower areas, such as user objects or subobjects only.

Modifying Permissions
After you know the default permissions, you can change them to meet your needs. If the Object tab and Properties tab include the permission you want to change, you simply select the appropriate check box. The permissions listed under the Object tab and Properties tab can be extensive, so Directory Service Manager offers several shortcuts. If you want to grant users full access to an object, you can select the Allow check box for the Full control entry in the Object tab. Directory Service Manager will then select all the Allow check boxes. Similarly, if you want to let users read or write all properties for an object, you can select the Allow check box for the Read all properties or Write all properties entries in either the Properties tab or Object tab.

If you can't find the user or group's permission you want to change, you can use the Add option in the Security window Screen 3 shows to add the desired user or group so that you can modify its permission. Here's an example of how to modify permissions so certain users cannot see an object. Suppose you want to hide the TestUser1 object, which is in the TestOU1 container, from the members of the DataEntryGroup. You can accomplish this task in eight steps:

1. Open Directory Service Manager and expand the DIT in the scope pane to show the contents of TestOU1 in the display pane.
2. Right-click TestUser1 in the display pane and select Properties.
3. Select the Security tab.
4. Check to see whether the desired permission is present. (It isn't.)
5. Click Add, and select DataEntryGroup from the Add Users and Groups dialog box.
6. Click Add, OK to close the dialog box and return to the Security tab, which now contains DataEntryGroup with the Read check box selected in the Allow column.
7. Select the Read check box in the Deny column. This action clears the Read check box in the Allow column.
8. Click Apply or OK to make the changes.

It is important to note that these instructions are based on NT 5.0 beta 1. Beta 1, interim build 1773 doesn't include the Security tab. To make the Security tab appear, you need to right-click in the display pane and choose View Advanced Features from the pop-up menu.

Imagine that you now want to hide only one property, the phone number, of the TestUser1 object from users in DataEntryGroup. Here are the steps you need to take:

1. Repeat previous steps 1 through 3.
2. Select the DataEntryGroup.
3. Clear the Read check box in the Deny column, and click Apply. This step removes DataEntryGroup from the list of displayed groups and users.
4. Click Advanced to open Access Control Settings for TestUser1. Screen 6 shows this dialog box.
5. Click Add, and select DataEntryGroup from the Add Users and Groups dialog box.
6. Click Add, OK to close the dialog box. This step opens a permissions entry window for TestUser1, similar to that shown in Screen 4 and Screen 5.
7. Click the Properties tab.
8. Change Apply onto text box to this object only.
9. Scroll down the list and select the Read Telephone-Number check box in the Deny column.
10. Click OK to return to the Access Control Settings dialog box, and click OK or Apply to make the changes.

This solution might win one battle, but not the war. Although you made one object inside the group visible, every other object is still invisible. If you do more of the same, you'll have a complex database that is difficult to manage. The best solution is to keep AD permissions simple and consistent.

Although the modification process is simple, you need to be aware of what the various permissions mean and the possible consequences of changing them. For example, suppose you deny users access to List contents for a container. You've just denied a very important permission. List contents represents whether users can view an object, not whether they can read its properties. If users can't list the contents of a group, search tools (such as Find) will not display the objects below that group in the DIT. If users can't see an object, they cannot select it to view its properties, even if you give those users permission to see those properties.

You also need to be aware of what objects are in a group before you change that group's permissions. For example, denying the Everyone and Authenticated Users groups access to objects is unwise because administrators are members of these groups. If you deny the Everyone or Authenticated Users group the ability to set permissions, administrators will have no account with which to reverse unwanted changes. The administrators only recourse will be to recover AD from backup media.

You might be wondering how the permissions you set will interact with those set for the Everyone and Authenticated Users groups. The permissions for these groups haven't been changed, so what takes precedence?

As in NT 4.0, the permissions for objects and properties are cumulative, with any Deny overriding an Allow. For example, if you allow the DataEntryGroup read access to all properties but deny the MarySmith object (a member of DataEntryGroup) read access to TestUser1's phone number, Mary will be able to read all properties except TestUser1's phone number. Conversely, if you deny the DataEntryGroup read access to TestUser1's phone number but allow the MarySmith object read access to that number, Mary won't be able to read TestUser1's phone number. Deny overrides Allow in the same way that No Access overrides standard NT 4.0 permissions. If you clear all check boxes from both the Allow and Deny columns for a user or group, clicking OK or Apply removes that user or group from the list. The user now has no permissions, so they do not need to be listed.

Finally, you need to be aware of AD's default inheritance policy. When you create objects, they automatically inherit the permissions of their parent unless you specify otherwise. For example, if you deny DataEntryGroup read access to all TestOU1 properties and leave the Apply these permissions down the tree check box in Screen 4 selected, you just made every object under TestOU1 in the DIT invisible to DataEntryGroup members. Thus, you need to be careful when creating objects and specifying their properties.

You can make objects visible again by changing their permissions. If you want to make TestUser1 (a subobject of TestOU1) visible to only DataEntryGroup members, you give DataEntryGroup Read all properties access to TestUser1 and clear the Inherit permissions from parent check box. Now when DataEntryGroup members search, the TestUser1 object is visible because it doesn't inherit its parent's permissions.

Keeping AD Manageable
Simplicity is the key to manageability. You can avoid management headaches by consistently following seven guidelines when setting AD permissions:

1. Assign AD permissions to groups whenever possible, with the members of those groups getting those rights as a whole. Create specifically named groups that you want to assign sets of permissions to, and make users members of these groups as needed.
2. Minimize overlapping object memberships in groups with conflicting permissions. Solving problems for a user is difficult if you must investigate many groups.
3. If you must assign permissions to individual users, keep those permissions to a minimum.
4. Manage permissions from the main Properties screen. You can allow and deny full read and write permissions to an object's properties from this screen. Use the Advanced button only when you need to micromanage.
5. Do not stop groups from inheriting their parents' permissions unless absolutely necessary, especially if a group is the start of a large branch. Making a branch autonomous from its parent forces you to manage two trees: the main tree and the autonomous branch.
6. If you modify the permissions of a group and do not want all the objects underneath it to have the same permission, be sure to leave the Apply these permissions down the tree check box empty. If you unintentionally leave this box selected, you can alter the permissions of an entire tree branch.
7. Use auditing at all times to keep track of changes made to AD.