Divide and Conquer

Are you role-playing with your network? If not, you’re missing a powerful way to make it more secure.

• By Roberta Bragg
• March 01, 2004

My usual answer to the question of whether you can develop an administrative hierarchy for an AD-based network is a resounding Yes!—with qualifications. I’d have to explain the tortuous route you’d have to follow, warn you of the dangers along the way. I’d have to sigh and show you the lack of documentation on AD permissions and how this would hamper your progress, and detail the testing that might lead to failure. I might have to point you to third-party products that claim to do the job.

Today, however, I think I can provide you with a little bit more hope. There’s some astounding new documentation that can help. It won’t make role definition for network administration as well codified as the building trades, but it might just give you a way to get the job done.

Permissions and Privileges
Windows NT has a simplistic way of determining what anyone can do on a single computer or within the domain. A user account is given specific rights on the system by virtue of membership in default groups (such as Administrators or Backup Operators) or is assigned a limited number of user rights and permissions to access objects by virtue of membership in custom groups or direct assignment. Not all user rights provided to default groups are available for individual assignment.

Windows 2000 introduced a more granular system and Windows Server 2003 goes even further, exposing more user rights. You can also assign or deny user rights to individuals and groups. More importantly, once AD is installed, your ability to create administrative task-based roles for users is unlimited. By assigning AD object permissions to custom security groups, you can create totally unique administrative roles with unparalleled diversity. For example, you can give help desk operators the ability to reset user passwords without making them full-blown administrators. By combining this ability with a properly designed Organizational Unit (OU) infrastructure, you can limit the use of a delegated authority to some subset of users or computers. Extend the concept to your entire forest and you can create roles for managing replication or domain creation.

Several of us, when we first grasped this ability to fine-tune administration and secure roles (for example, the help desk operator can reset passwords but not create accounts; the forest infrastructure admin can create a new domain but not a new user), were literally speechless; our brains whirred with the possibilities. Then reality set in. You could use the Delegation of Control Wizard to assign the Reset Password permission or grant Full Control over users in a specific OU; but this granularity meant there was an enormous number of AD permissions available for assignment. Clearly, this was going to be a steep learning curve. My article, “Active Directory Object Permissions 101,” in the October 2001 issue, gives the basics of AD object permissions and also my frustration with the lack of documentation on what each permission means.

Delegate and Separate
The white paper, “Best Practices for Delegating Active Directory Administration,” and its appendices, at www.microsoft.com/downloads, has some answers. It took Microsoft more than two years to respond to my plea for help, but I’m still grateful for the results. The document doesn’t answer all my questions, but it does lay out a comprehensive plan for architecting a role-based administrative infrastructure. I recommend you download and fully digest the document, then plan and implement a solution workable for your environment. To get an idea of the approach it takes, read on.

As any good remodeler knows, big jobs are really only a series of interlinked small jobs. Dividing up the job into the right parts and finding the right people to do them is half the battle. Delegating specific chores to certain individuals or groups can also have other benefits, such as reliability and accountability. If my pipes in the new office burst and drench it, I may call the contractor to complain, but it’s the plumber he or she hired who will be blamed for the problem. If one group is responsible for managing AD replication and replication fails, you’ll know who to call. When people have the authority to manage a smaller aspect of a job, they may do it better. When they know they can be held accountable, there’s an even better chance they’ll take the job seriously.

To best administer an AD network, divvy up the chores. The first division is between service administrators and data administrators.

Service Admins Vs. Data Admins
Service administrators have responsibility for the AD infrastructure, security and management as a whole. In an unaltered AD network, service administrators are members of the Enterprise Admins, Schema Admins and Domain Admins groups. They may also simply be administrators of some service application, such as DNS, that impacts the entire forest. Within the service administration group, responsibilities are also divided. For example, few administrators need to be members of the Schema Admins group or Enterprise Admins group, but there may be many domain administrators, especially in a large AD environment with many domains.

Data admins have responsibility for managing the information in AD. They manage users, computers and groups. They’re responsible for managing these accounts in AD, as well as the actual computers and the data stored on them. Data admins are also administrators for specific applications or application servers such as file servers and database servers.

But the lines drawn between service administration and data administration aren’t entirely enforceable, nor clear cut. Service admins can take over management of the data administration space. You can deny them access to these privileges, but service admins can take the privileges back. In addition, service administrators must manage the user and computer accounts of service administrators; manage computers such as their administration workstations; and manage critical infrastructure systems such as domain controllers and DNS servers. Data administrators, however, can be prevented from gaining privileges beyond their well-defined responsibilities. You can read more about service and data administration in the Best Practices document I referred to earlier.

Cutting up the Service Administrator Pie
While the default service administrator groups might appear to provide the roles necessary for AD administration, I think you’ll be happier with a more granular approach. The Best Practices guide defines the roles listed in Table 1. Take a look, not at the role title, but at what tasks each role should be doing. Can you see how administration or security will benefit by this approach? Try thinking of it this way: for each two tasks, is there a reason why you might not want the same person to do both? Think security, but also think accountability. For example, by splitting replication management from replication monitoring, you’ll probably get better results. It’s always better to have someone outside a group monitoring its activity. The same process supports security monitoring. If the role definitions are lacking, the document invites you to develop your own list. The only thing missing is an auditor’s role. Who’s going to watch over the folks that perform these administrator functions?

Take another moment to look at the number of each role type recommended by Microsoft. Note that, in general, forest-wide roles can be single entities, while domain-based roles may require one for each domain in the forest. See how few actual administrators for each role are recommended? That number may depend on the size of your implementation, but the idea won’t. Use the fewest administrators possible.

These Microsoft-recommended roles can be implemented by establishing custom groups for each role, or by using a combination of default administrative groups and custom groups. All duties defined in the table can be managed by existing roles; but establishing specific roles that allow a group to do its job and no other requires custom groups, the assignment or removal of permissions and assignment, or the removal of user rights.

In my opinion, a clean break with most default groups is called for. There are two reasons for this. First, if assistance is needed, or experienced AD administrators are recruited from other companies, there will be less confusion if default groups maintain their default privileges and operational abilities. Second, if custom Windows groups are created, one for each role, and assigned only the privileges and user rights needed to do specific jobs, assigned admins can only perform the duties they’re supposed to be able to perform. This is always a good thing.

The one exception to this is the use of the Schema Admins group for the Schema Admin role. Membership in this group only confers the additional responsibilities defined for this role. It’s also possible to keep this group empty of members until it is needed, thus preventing accidental use of its privileges.

Microsoft also recommends making new custom groups for most roles, and agrees with me on making an exception of the Schema Admins group. But Microsoft also recommends using the default Backup Operators group instead of creating a new custom group. I disagree with them here. In the role separation proposed by Microsoft, the backup of AD is managed by one role—Backup Operators—and the restore function by the Domain Configuration Operators.

This is an excellent use of the security principle “separation of duties” (see my January column, “Separation, No Anxiety,” for more information on this concept). By default, however, the Backup Operators group has backup and restore privileges. I recommend creating a new Backup group to fulfill the newly defined Backup Operators role and only giving it backup—not restore—privileges.

Distributing the Data Administration Load
Defining roles for data administrators is less straightforward. While the management of AD and its components is task-defined, managing the data in AD is more dependent on the data in it and how well developed your OU infrastructure is. Each organization will be different, but Microsoft has provided some excellent recommendations. Division of duties is based on separation by business unit and presumes you’ve structured your OUs to support business units. It shouldn’t surprise you that the Business Unit Admins role supervises the delegation structure for each business unit.

Data administrator roles are defined in Table 2. Note that the number of roles is now based on business units, not domains or forests; and that most sport “minimum number required” under the “Number of Admins” column. As you review these roles, think about separation of duties, least privilege, and plain old common sense. It makes sense, for example, to separate workstation operators from server operators. Servers may contain more sensitive information, and certainly very different applications, than workstations. Specialization makes the job faster and produces more reliable results. Security is always served when you can limit responsibilities; the less you have to know, the easier it is to do the job correctly. Errors and omissions are often the holes that allow malicious code and malicious people to waltz right in and do damage.

Matching Permissions and Privileges
Microsoft recommends creating an OU for each business unit, for storing the security groups designated to provide the data administration roles. A separate OU within that OU is recommended for all user accounts. In addition, an elaborate plan for data administration implementation using multiple OUs is detailed in the document. You’ll want to study this model, but then design a model that fits your final delegation of administration design. The objective, of course, is to provide the infrastructure to support the delegation of control (authority) for each data administration role.

Assignment of the permissions necessary to provide data and service administrator groups the ability to perform their roles is accomplished by using the Delegation of Control wizard at the domain or OU level. Without a well-planned OU infrastructure, you can’t hope to appropriately delegate control to match your desired data administration design. In addition to delegation, don’t forget necessary resource permissions like ACLs on files and application-level permissions. The appendices of the delegation document provides information on AD permissions for each role. If you develop your own roles, you’ll have some more discovery work to do.

The Right Tool for the Job
You wouldn’t think of using a screwdriver to hammer in a nail—nor should you attempt to implement your administration design without the right tools. In addition to the normal complement of user, computer, permissions and security policy tools, detailed knowledge of two tools is very necessary to implementing and managing these roles. First, the Delegation of Control Wizard allows you to assign permissions within AD. This is used to provide the new data and service administrator groups you create the AD permissions required to do their jobs. Second, dsrevoke.exe can be used to determine what permissions a security role has within OUs, and also to remove those permissions. Dsrevoke.exe can be downloaded from the www.microsoft.com
/downloads site. A search for dsrevoke will discover the dsrevoke.doc and derevoke.exe files. Download both. The dsrevoke.doc file provides the syntax for the dsrevoke command-line tool.

Dsrevoke.exe can report on or revoke OU permissions currently assigned to a security principal. For example, you can list all the permissions on all OUs assigned to the Help Desk group. The tool can also revoke these permissions. Dsrevoke.exe is simple to run. For example, open a command prompt and enter:

Dsrevoke /report "mybigdomain\Help Desk"

You’ll get a report of the OU ACLs held by the mybigdomain\Help Desk group. Use the name of your domain and user group. You must be an Administrator to run dsrevoke. Additional syntax allows you to enter a domain name and credentials if you wish to run reports on additional domains.

Get a Thorough Inspection
You should get someone to inspect your plans for administrative role definitions. Remember, the more eyes on a security design, the more chances you have to make it a secure design. It’s going to be a complex undertaking that you’re not going to want to rip out and start all over again.