Which security groups and role groups should you assign to Group1 and Group2?

DRAG DROP
Your network contains a single Active Directory domain named contoso.com. You plan to deploy a
new Exchange Server 2010 Service Pack 1 (SP1) organization. You identify the administrative model
for the Exchange organization as shown in the following table.

You need to identity which groups must be assigned to Group1 and Group2 to support the planned
administrative model. The solution must minimize the number of rights assigned to each group.
Which security groups and role groups should you assign to Group1 and Group2?
To answer, drag the appropriate security groups or role groups to the correct group in the answer
area.

Answer:

Explanation:

Group 1 needs to be able to do the following:
Restore mailboxes
Stop and Restart both Servers and Services
Create mailbox database
Install Operating System Updates
Manage Certificates
I don’t agree with the need for this group to be a member of the Account Operators group. This is a
domain account that allows local logon to domain controllers and they can create user account
accounts. Group 1 as I read the question needs to logon to exchange servers and manage the local
exchange server. Therefore I think they just need to be members of the Administrative Group on
each Exchange Server.
Group 2 needs to be able to do the following:
Create mail – enabled users
Create distribution lists
Delete distribution lists

In order for group 2 to complete their tasks they will need to have recipient management role and
the Organization Role
Account Operators is a local group that grants limited account creation privileges to a user.
Members of this group can create and modify most types of accounts, including those of users, local
groups, and global groups. They can also log on locally to domain controllers. However, Account
Operators can’t manage the Administrator user account, the user accounts of administrators, or the
group accounts Administrators, Server Operators, Account Operators, Backup Operators, and Print
Operators. Account Operators also can’t modify user rights. The Recipient Management
management role group is one of several built-in role groups that make up the Role Based Access
Control (RBAC) permissions model in Microsoft Exchange Server 2010. Role groups are assigned one
or more management roles that contain the permissions required to perform a given set of tasks.
The members of a role group are granted access to the management roles assigned to the role
group. For more information about role groups, see Understanding Management Role Groups.
Administrators who are members of the Recipient Management role group have administrative
access to create or modify Microsoft Exchange Server 2010 recipients within the Exchange 2010
organization.
Help Desk – The Help Desk management role group gives members permissions that are typically
required by members of a help desk, such as modifying users’ details such as their address and
phone number.
Organization Management
The Organization Management role group is synonymous with the
Exchange Full Administrator role in Exchange 2003 and the Exchange Organization Administrators
role in Exchange 2007. Essentially, membership of this management role group gives the user the
ability to perform pretty much any task in Exchange 2010, with the main missing task being the
ability to perform mailbox searches; that itself is achieved via the Discovery Management role group.
Domain Admins – This group is automatically added to the corresponding Administrators group in
every domain in the forest. It has complete control over all domain controllers and all directory
content stored in the domain and it can modify the membership of all administrative accounts in the
domain.
The permissions granularity issue was improved in Exchange 2007. The Exchange Full Administrator
role
found in Exchange 2000 and Exchange 2003 became known as the Exchange Organization
Administrators role in Exchange 2007 and still gave administrators full access to all Exchange objects
in the entire organization.
The Exchange View-Only Administrators role also remained, giving administrators read-only access
to the entire Exchange organization.
There were effectively three new additions to the Exchange 2007 roles:
Exchange Recipient Administrators – Allowed administrators to modify Exchange settings on users,
groups, contacts and public folders
Exchange Public Folder Administrators – Was introduced in Exchange 2007 Service Pack 1 and as its
name suggests allowed administrators to manage public folders
Exchange Server Administrators – Allowed administrators to fully manage a particular Exchange 2007
server as long as they were also a member of the local Administrators group on that server
Although the permissions model in Exchange 2007 was a vast improvement over those models found
in earlier versions of Exchange, it still wasn’t able to satisfy a lot of the administrative scenarios
found in various organizations. Essentially, the roles in Exchange 2007 still offered too much
administrative power to administrators in a decentralized Exchange organization and it was
therefore difficult to limit the permissions available to certain administrators. Although it was

possible to implement a split permissions model in Exchange 2007 by modifying Access Control Lists
(ACLs), this was a complex procedure that could sometimes result in errors and issues that were
difficult to troubleshoot.
The design of Exchange 2010 has needed to take into account the more demanding and granular
permissions requirements of organizations. Exchange 2010 now supports a model where specialist
users can be granted specific Exchange permissions required to perform their duties. For example,
there may be the scenario where a compliance officer within a company needs to conduct a search
across all employees’ mailboxes for legal reasons, or perhaps a member of the Human Resources
department needs to update user information in Active Directory that is seen on the properties of
users’ mailboxes. In these example cases, the relevant specialist user should only be given the rights
to perform the required task and should not be assigned, for example, additional rights that could
allow them to affect the overall configuration of the Exchange environment.
Management Role Groups – In Exchange 2010, Microsoft has made the task of assigning a series of
common permissions to administrative and specialist users very easy by providing 11 default
management role groups. By placing a user or group into a management role group, the
management roles associated with that management role group are assigned accordingly thereby
giving the user or group the relevant permissions.
The term role holder is used by Microsoft to denote the administrative or specialist user that is
added to the management role group. These 11 default management role groups are created during
Exchange 2010 setup.
Specifically, these management role groups are created when Exchange 2010 setup runs the Active
Directory preparation steps that can be performed individually by running the Exchange 2010
setup.com program with the /PrepareAD switch. The management role groups can be seen in the
Microsoft Exchange Security Groups
Organizational Unit (OU) that is created in the root domain during the Exchange setup process. You
can see this OU and the groups within it in Figure 1. Note that of the 16 groups shown in Figure 1,
only 11 are management role groups; these are highlighted.

A member of LOCAL\Administrators is a far cry from a BUILTIN\Administrators, and here are the two
primary reasons why:

One – BUILTIN\Administrators is not stored locally to a single DC – its membership is in the Active
Directory, in the CN=Builtin,DC=domain,DC=com container. The contents of this container are
replicated to all domain controllers. Therefore, adding a user to a member of this group on one DC
makes them a member of the group on all DCs. (A member server has a local accounts database
called a SAM that is not visible to the domain.)
Two – Since BUILTIN\Administrators gives local Administrator permissions to its members – they can
do anything on any DC in the domain. Anything. Making themselves a Domain Administrator is a
trivial exercise.
A final note of caution: it is now widely recognized that forests are the security boundaries in Active
Directory, not domains (regardless of what the original Windows 2000 Server A/D documentation
said). Domains are simply administrative boundaries. As a corollary to item two above, once a
person is a domain administrator, it is fairly easy to become an enterprise administrator.