One of Active Directory's (AD's) greatest strengths, in comparison with Windows NT 4.0 domains, is delegation--the ability to create a user or a group with a finely defined set of powers. Under NT 4.0, users tend to be either all-powerful (e.g., members of the Domain Admins group) or fairly powerless (e.g., members of the Domain Users group). In contrast, AD lets you create "sub-administrators"--people who have administrative power, but not as much power as a domain administrator. AD also lets you give certain people complete control over only a domain subset (i.e., an organizational unit--OU). Best of all, with its Delegation of Control Wizard, Microsoft has simplified the fairly complex task of delegation.
However, for two reasons, AD delegation has never been perfect. First, although a wizard helps you perform delegation, you don't have one for undoing delegation. Removing a power that you've granted is complex, requiring that you drill down through several layers of security GUI. Second, AD doesn't offer a way to easily determine what delegations you've put in place.
With its nifty Dsrevoke command-line tool, Microsoft has simplified both the process of documenting and the process of undelegating existing delegations. You can find Dsrevoke at the Microsoft Download Center (http://www.microsoft.com/downloads).
Dsrevoke can tell you exactly what permissions a given user or group has on a domain. In the command
you would use the format domainname\username or domainname\groupname for the user-or-group-name variable, where domainname is the domain's NetBIOS name. (I can't seem to make the DNS name work.) For example, suppose you're working in a domain named bigfirm.biz, with the NetBIOS name Bigfirm. To see the powers that a group called Test has on the local domain, you'd type
dsrevoke /report bigfirm\test
The resulting report won't provide a complete explanation of Test's powers in Bigfirm, but it will identify whether Test has any explicitly delegated powers in Bigfirm. However, the report won't show powers that Test has by virtue of being part of another group. If Test is part of a group called Bigtest, and Bigtest has some power, Test will inherit that power but the Dsrevoke report won't display it because the power isn't explicitly given to Test.
If you want to identify Test's powers in a different domain, you can use the /domain option to specify which domain to report on. This option takes either the NetBIOS or DNS name. If you need to provide Dsrevoke an administrative name and password for that domain, you can use the /username and /password options. For example, the command
would identify Test's powers on a domain called apex.com. The domain name is surrounded by quotation marks because the domain's DNS name includes a period; any special characters such as spaces and punctuation marks require quotes. This command also tells Dsrevoke to offer the user account name joeadmin and password swordfish, in the event that apex.com wants to know who's asking.
But domains can be large and can contain many OUs. You might not care about what delegated powers a group has except for its powers on a particular OU. To tell Dsrevoke not to search an entire domain but instead a particular OU in a domain, you would use the /root:ou option. You specify an OU in Lightweight Directory Access Protocol (LDAP) format.
To undo the work of the Delegation of Control Wizard, you can replace Dsrevoke's /report option with the /remove option. To remove all the Test group's powers over the Marketing OU in bigfirm.biz, you'd type
Dsrevoke will show you all the powers it found for Test in the Marketing OU, then ask "Do you want to remove the above listed ACEs?" Just press Y, and they're all gone. Unfortunately, you can't suppress this confirmation.
I would like to have seen Dsrevoke implemented as a GUI tool because of its potential power. Seeing Test's powers across the domain depicted graphically would have been convenient. However, in its current form, Dsrevoke is still a useful utility to add to your toolbox.