Security Advisor

Divide and Conquer

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

What administrative tasks are required to administer an Active Directory-based network securely? Who should perform them? Can you design an administrative infrastructure that delegates these responsibilities appropriately? Are the roles you create securable? Or is it likely that you’ll have to provide someone with more power than they need?

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?

Table 1. Service Administrator Roles
Role # of Roles # of Admins Tasks
Forest
Configuration Operators
1 2-3 Create, delete child domains; manage trusts; create, delete, manage cross-reference objects; transfer, seize forest-wide operations masters roles; modify LDAP settings; raise forest functional level
Domain
Configuration
Operators
1 for each domain in the forest 2-3 per domain Add, remove replica domain controllers (DCs); transfer, seize domain operation master roles; protect, manage default Domain Controllers OU; protect, manage System container content; restore AD from backup
Security Policy Administrators 1 2-3 Manage domain controller security policy for all forest domains; manage domain security policy, password policy, account lockout and Kerberos policy for every forest domain
Service Admin
Managers
1 As few as possible Manage and modify Service Administrator group memberships and accounts
Domain Controller Administrators 1 per physical location that houses DCs. One to manage branch office locations remotely. Dependent on number of DCs Install, modify software, service packs and hotfixes; configure directory service settings in Registry; maintain, backup event logs; configure service control manager; manage directory service files and Sysvol; start, shut down domain controllers
Backup Operators 1 for each domain in forest 2-3 per role Back up system state, including AD, DC, Registry, Sysvol
Schema
Administrators
1 1-2 Extend AD Schema; deactivate AD classes or attributes; specify attribute replication to Global Catalog servers
Replication
Management Administrators
1 Minimum number required to react to replication issues. Create, manage, delete sites; associate subnets to sites; create, manage, delete site links and site-link bridges; modify replication schedule; create, delete manual connections; force replication between DCs; force full replication synchronization
Replication
Monitoring
Operators
1 Dependent on size of AD, but enough to monitor each work shift Monitor replication
DNS Administrators 1 Smallest number to cover operations Install DNS server service; configure DNS; configure forest root zone, domains on DCs as appropriate

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.

Table 2. Data Administrator Roles
Role # of Roles # of Admins Tasks
Business Unit Admins 1 per business unit 1 or more depending on size of data Implement and maintain delegation model for business unit data management; create OU hierarchy; create and populate administrative groups to manage OUs in hierarchy
Account Admins 1 or more per business unit Minimum number necessary Create accounts; populate attributes; manage, delete and maintain accounts
Help Desk Operators 1 for every business unit needed to provide support to a subset of user accounts or all user accounts under its administration Account support for Account Admin role; tasks such as password reset; unlocking user accounts; modifing user attributes such as phone numbers that aren’t security sensitive
Workstation Admins 1 or more per business unit; may be based on physical location Minimum per role required to manage workstations Manage workstations
Server Operators 1 per organization Minimum required to manage servers Manage servers
Resource Admins 1 per common service or resource hosted on one or more servers

Minimum number needed per role

Manage resource (database, files, application), and set of servers the resource is hosted on. (Management of service vs. server may or may not be separate roles)
Security Group Admins 1 role per business unit Minimum needed per role Manage security groups required for business unit
Application Specific Admin 1 per AD-integrated application Minimum needed per role Manage application data in the AD

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.

comments powered by Disqus

Redmond Tech Watch

Sign up for our newsletter.

I agree to this site's Privacy Policy.