In its courses, Microsoft is touting delegation of authority in Active Directory as a cost-saver. That's particularly apparent in such AD classes as Course 2154, Implementing and Administering Microsoft Windows 2000 Directory Services, and Course 1561, Designing a Microsoft Windows 2000 Directory Services Infrastructure. Also, the subject turns up again and again in Microsoft's articles on Windows 2000 total cost of ownership (TCO) and return on investment (ROI).
What are the pros and cons of delegating authority in Active Directory? I'll begin to cover that topic in this article. Then I'll continue the discussion in a more interactive fashion in an upcoming
The webcast is our chance to share our experiences delegating authority in AD. What topics should we cover in the webcast? What are you doing out in the field right now? Is Microsoft right about the cost-saving benefits of this process? Or was there a misuse of power when you delegated authority? Tell us your story and ask questions by writing to firstname.lastname@example.org.
Let's start by defining some terms. "Delegation of authority" simply means giving certain users or groups rights in Active Directory. These rights are usually limited in that they either apply to an organizational unit (OU), a certain specific right at the domain level, or the right to change passwords at the domain level. Giving someone all rights at domain level basically makes them a domain administrator, which is the exact opposite of what Active Directory is trying to do with delegation of authority.
Note that what we're talking about are rights on Active Directory objects, such as users and printers, and shares published in Active Directory. We're not discussing NTFS rights associated with files, printers, and so forth. NTFS rights are typically set by whoever has control over the files, folders and printers. For example, a user typically has read permissions on a printer in Active Directory, which lets him view the printer in Active Directory. This does not necessarily mean that they have print permission to the printer, which is assigned separately by whoever controls the printer itself.
Here's a way to look at the printer object in Active Directory. It's like a link on your desktop to the printer; deleting the link on the desktop will not delete the printer itself. Be careful -- user objects in Active Directory are different, and deleting a user means that that user is gone.
There are a couple of caveats here. One is that you can get very granular with security in Active Directory, meaning you could even give a user permission only to change ZIP codes. Try to avoid this unless you have a very good reason for doing it, because it adds considerably to your administrative overhead.
For a variety of reasons, it's best to avoid assigning permissions directly to users. For example, you could create a global group, put the individual in the group, put that group in a domain local group and give the domain local group permissions. Since you always document your groups and what they're for (you do, right?), that means you can track who has permissions to do what. Your old AGDLP still works. (Remember that accounts go into Global groups, Global into Domain Local, Domain Local gets Permissions.) No, I don't nest groups, in case you were wondering.
Assigning permissions directly to users can result in headaches for you as an administrator, especially if you have a security problem and need to track what rights users have been granted. That is, unless you're a lot better than most people are at tracking assigned rights.
Giving rights to individuals can result in problems if you do something very quickly to solve an individual problem, then forget to document what you did. Also, consider what happens if you follow AGDLP and at a later time use this user's account as a template to create a new user with the same rights. In such cases, group memberships copy over, but individually granted rights do not.
How it's done
How do you delegate authority? The easiest way is by using the Delegation of Control Wizard in Active Directory. The Delegation of Control Wizard lets you assign individual or group permissions in Active Directory, from full control of an OU and all child objects in it, down to just the permission to change a user's ZIP code. You can edit security rights manually by editing the properties of, for example, an OU. But doing it this way is more difficult, time consuming and error-prone, unless you are extremely familiar with the rights listed.
This introduction to delegating authority in Active Directory is just the first step in the process of evaluating its cost-saving benefits. Now, it's your turn to share information for possible use in my upcoming webcast.
Send your experiences with this process and any questions you have about it to email@example.com. Tell us how far you might want to go delegating authority. What problems have you encountered, and how have you solved them? Or, if you didn't solve them, tell us about that, too. We would like particularly to look at who is being given delegated rights by you, whether these users include help desk personnel, power users in OUs, administrators only, or regular users. We would also like to know which rights you are delegating.
In the upcoming webcast, we will also drill down deeper into the process of delegating Active Directory, touching on topics such as auditing techniques. So send your questions to firstname.lastname@example.org, or get them together to ask during the webcast. In the meantime, I'll look forward to talking with you online about it soon. Check the SearchWindowsManageabilty webcast page for the date and time.
- Got questions about delegating authority in AD? Did you try it and have users misuse their powers or have a mysterious technical problem? Do you just plain hate AD, or vice versa? Write to Doug Paddock and SearchWindowsManageability.com at email@example.com.
- Read about upcoming webcasts on SearchWindowsManageability.com.
- Click here to pre-register for the upcoming webcast, "Delegating Authority in Active Directory - Are Your Users Ready to Become Administrators?"
This was first published in October 2002