Return to the Active Directory Users and Computers snap-in and right-click the OU containing the user objects that your Help desk will administer. Click the Security tab, then click Advanced, New. The dialog box will ask you to enter or scroll to the user or group account to which you want to grant permissions. Enter the name of your Help desk group and click OK. Click in the Apply onto area and select User objects to view a list of object-level permissions. Click the Properties tab and select the Allow check box for the Read pwdLastSet and Write pwdLastSet attributes, as Figure 2, page 26, shows. (If you don't see these attributes, relaunch the Active Directory Users and Computers snap-in to make them appear.) If you wish, you can also select the Allow check box for Read Lockout Time and Write Lockout Time to grant your Help desk group these rights. Repeat these steps for each OU you want the Help desk to administer.
After you make these changes, when a member of your Help desk group opens a user account in the OU, all the attributes will be shaded out except User must change password at next logon, as Figure 3 shows. If you want to let your Help desk group members disable accounts without delegating the whole User Account Control kit and caboodle to them, check the Allow box for Read accountExpires and Write accountExpires in the same permissions tab instead. Although group members won't be able to directly disable user accounts, they can obtain the same result by setting the account's expiration date to a date earlier than the current date.
Moving Objects to Different OUs
One important administrative right you want to delegate is the right to move objects in and out of OUs. However, delegating this right without compromising security requires some creativity. AD requires that you have delete permissions to move an object out of an OU. Moving an object into an OU requires create permissions. Unless you have those two rights, any attempt to move an object (by right-clicking the object and choosing Move in the Active Directory Users and Computers snap-in) will fail. Because of the way AD is designed, if you have the ability to move objects, you can also delete them—even though, in a practical sense, delete and create operations are distinct from move operations. As an administrator, you might be comfortable letting local administrators move an object—a reversible operation—but not comfortable letting them delete an object—an irreversible operation. Clearly, you have a challenge.
One common delegation scenario is to grant a site-level administrator full control over a specific OU hierarchy. For example, you might have two site-specific OUs in your domain: New York and Detroit. You grant Chip full control over the New York OU and give Maria full control over the Detroit OU. Administrators often need to move individual user accounts and occasionally need to move computer and group accounts to different OUs (e.g., employees relocate or are promoted, IT responsibilities shift). Maria has full control over her OU, so if Jack relocates to New York, she has no problem moving him out of her Detroit OU: As a site-level administrator, she has permission to delete objects in her OU. The problem is, she has no create rights within the New York OU, so she can't move the object to New York. If you have to give Maria create rights over the New York OU (and every other OU to which her Detroit users might relocate), you compromise the security advantages of a geographically limited administration model.
The solution is to create a special OU (I call it the depot OU) for which all your site-level administrators have create and delete permissions. When Jack relocates to New York, Maria moves Jack out of her Detroit OU and into the depot OU. She then tells Chip that he has jurisdiction over Jack's account, which is in the depot OU waiting to be moved. Chip then moves Jack's account from the depot OU to the New York OU.
This solution also eliminates surprise account appearances. No accounts will appear in Chip's OU unless he moved them there. Domain-level administrators can monitor the depot OU to make sure users aren't orphaned there. If necessary, you can create several different depot OUs across your organization. You still have to grant create and delete rights in several places, but much less extensively than you would have to without this solution.
Defining a Centralized Delegation Model
Now that you have the primer information and a sample solution, let's consider how you might define your delegation model. The nature of delegation makes having a well-defined model essential. Consider that Domain Administrators can delegate control over portions of the directory to others without making them administrators over the entire domain. Furthermore, anyone with the Change permissions right to an object can grant or revoke permissions for that object to anyone else he or she specifies. To extend the example from the last section, I might have full confidence in Chip's ability to manage the New York OU (e.g., create and delete objects, maintain group memberships), but I might not want him extending this level of authority to others. I might also want to prevent him from removing any rights I grant to others. But if he has the Change permissions right over his New York OU, he can do both these things. He could let the mailroom clerk delete accounts in the OU, and he could remove the central Help Desk group members' ability to reset passwords within the OU. A poorly thought out approach to delegation administration doesn't provide a secure environment because the heart of good security is a centrally defined and consistently applied security model. However, you can still give OU-level administrators a limited ability to further delegate their authority without wreaking havoc on your centrally determined delegation model.
Register
