A key example of the power of Windows 2000's Active Directory (AD) that I frequently refer to is the ability to let non-administrators (e.g., Help desk staff) reset forgotten passwords without granting these users sweeping administrative authority—a necessity in Windows NT. In addition, AD lets administrators monitor this sensitive activity. As a security administrator working with Win2K, it's important that you understand how to delegate password reset authority. I’ll use the example of a Help desk, but you can adapt these principles to many other situations.
For this exercise, it’s important to realize that all Win2K users and groups are just AD objects, which, like all Win2K objects, have an ACL. For the first time, the OS lets you control user access the same way you control file access. So, for example, in Win2K, you simply open the Properties dialog box for any AD object and select the Security tab to see the object’s ACL. Screen 1 shows an organizational unit's (OU's) ACL. To keep things manageable, remember to define permissions in AD at the OU level and avoid making changes to the ACLs of individual users and groups. This concept should be familiar to those who have administered file servers; permissions are easier to maintain if you define them at the directory level instead of on individual files. OUs in AD correspond to folders in your file system, and permissions flow from parent folders down to child files and folders.
Identifying Users
To begin, you need to identify two types of users. First, identify
those users you want to delegate to reset passwords on behalf of other users, and use
Active Directory Users and Computers to place these delegated users in a group in your
domain. If the list of delegated users directly corresponds to an existing user group,
such as HelpDeskStaff in this example, you can use that group. Second, identify those
standard users that the delegated users will have password reset authority over. However,
you won’t be placing these standard users in a group. Instead, you must define the
standard users in terms of OUs. So, for example, imagine that you want your Help desk
staff to have password reset authority over the marketing, manufacturing, and human
resources departments. Typically, you’ll already have OUs built for these
departments. If so, you can grant HelpDeskStaff the authority to reset passwords for those
OUs using Win2K's Delegation of Control Wizard.
Delegation of Control
To use the delegation wizard, open Active Directory Users and
Computers and select the Marketing OU. Right-click the OU, select Delegate Control, and
click Next. At this point, the wizard asks you to select a user or group that you want to
delegate control over this OU. Add the HelpDeskStaff group, as Screen 2 shows, and click Next. The wizard will ask you which tasks you want to delegate.
Check Reset passwords on user accounts, as Screen
3 shows. The wizard presents a summary of your request, as Figure 1 shows. When
you click Finish, the wizard actually adds an entry in the Marketing OU's ACL. We can
examine the OU's ACL to see what happened. Open the Marketing Properties dialog box and
select the Security tab, as Screen 1 shows. Notice that the HelpDeskStaff group now
appears, but this window can’t display the low-level permission that you just granted
to this group. To see that setting, you must press the Advanced button, which displays the
information you see in Screen 4. Notice in the Apply to column that this permission is limited to user
objects. As a result, all user objects in this OU will inherit this permission. To learn
more about Win2K permissions and inheritance, see my article, "NTFS Access Control Security Enhancements," May 2000.
Property Permissions
AD permissions are slightly different from file permissions.
Whereas file permissions have one dimension that controls file access, AD objects have
several discrete properties. For instance, a user object might have a username, telephone
number, email address, and account restrictions. Consequently, AD ACLs have two tabs, as Screen 5 shows. The Object tab controls what actions you can perform on the AD object itself.
The Properties tab controls read and write access to individual properties within the
object. This level of control gives you granularity in how you grant access to objects.
You can grant everyone read access to public information, such as a user’s email
address and phone number, but restrict access to more sensitive properties.
Handling forgotten passwords is just one example of how you can use AD to delegate authority with fine granularity. Endeavor to always modify permissions at the OU level, grant authority to groups, and avoid administering individual object ACLs and granting access to individual users. In future columns, I’ll show you how to monitor these password resets and create a custom Microsoft Management Console (MMC) for Help desk staff to streamline their work.
