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
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
||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
|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
||Manage domain controller security
policy for all forest domains; manage domain security
policy, password policy, account lockout and Kerberos
policy for every forest domain
||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
||1 for each domain in forest
||2-3 per role
||Back up system state, including
AD, DC, Registry, Sysvol
||Extend AD Schema; deactivate
AD classes or attributes; specify attribute replication
to Global Catalog servers
||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
||Dependent on size of AD, but
enough to monitor each work shift
||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
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
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
|Business Unit Admins
||1 per business unit
||1 or more depending on size
||Implement and maintain delegation
model for business unit data management; create OU hierarchy;
create and populate administrative groups to manage OUs
||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
||1 or more per business unit;
may be based on physical location
||Minimum per role required to
||1 per organization
||Minimum required to manage servers
||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
|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
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
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.