4. Understanding Shadow Groups
Most management of an enterprise is implemented with groups.
Groups are assigned permission to resources. Groups can be used to
filter the scope of Group Policy objects. Groups are assigned fine-grained
password policies. Groups can be used as collections for configuration
management tools such as Microsoft System Center Configuration
Manager. The list goes on. OUs, however, are not used as frequently to
manage the enterprise, and in some cases, they cannot be used. For
instance, OUs cannot be assigned permissions to resources, nor can
they be assigned fine-grained password policies . Instead, the
primary purpose of an OU is to provide a scope of management for the
delegation of administrative permissions for the objects in that OU.
In other words, an OU of users enables you to delegate to your help
desk the ability to reset passwords for all users in the OU. OUs are
administrative containers.
The reason for this separation of purpose between OUs and groups
is that OUs do not provide the same flexibility as groups. A user or
computer (or other object) can exist only within the context of a
single OU, whereas a security principal can belong to many groups.
Therefore, groups are used for aligning identities with the
capabilities required by those identities.
Sometimes, you might want to manage using an OU when it is not
possible. For example, you might want to give all users in an OU
access to a folder. Or you might want to assign a unique password
policy to users in an OU. You cannot do so directly, but you can
achieve your goal by creating what is called a shadow
group. A shadow group is a group that contains the same
users as an OU. More accurately, a shadow group contains users that
meet a certain criterion.
The easiest way to create a shadow group is to create the group,
and then, in the OU containing the users, press Ctrl+A to select all
users. Right-click any selected user and choose Add To Group. Type the
name of the group and click OK.
TipUnfortunately, Windows does not yet provide a way to maintain
the membership of a shadow group dynamically. When you add or remove a
user in an OU, you must also add or remove the user in the shadow
group.
Several groups are created automatically on a server running Windows Server 2008 R2. These are called
default local groups, and they include well-known
groups such as Administrators, Backup Operators, and Remote Desktop Users. Additional groups are created in a
domain, in both the Builtin and Users containers, including Domain
Admins, Enterprise Admins, and Schema Admins. The following list provides a summary of
capabilities of the subset of default groups that have significant permissions and
user rights related to the management of Active Directory:
-
Enterprise Admins (Users container of
the forest root domain) This group is a member of the
Administrators group in every domain in the forest, giving it
complete access to the configuration of all domain controllers. It
also owns the Configuration partition of the directory and has
full control of the domain naming context in all forest
domains. -
Schema Admins (Users container of the
forest root domain) This group owns and has full control
of the Active Directory schema. -
Administrators (Builtin container of
each domain) This group has complete control over all
domain controllers and data in the domain naming context. It can
change the membership of all other administrative groups in the
domain, and the Administrators group in the forest root domain can change the
membership of Enterprise Admins, Schema Admins, and Domain Admins. The Administrators
group in the forest root domain is arguably the most powerful
service administration group in the forest. -
Domain Admins (Users container of each
domain) This group is added to the Administrators group
of its domain. Therefore, it inherits all the capabilities of the
Administrators group. It is also, by default, added to the local Administrators group of
each domain member computer, giving Domain Admins ownership of all
domain computers. -
Server Operators (Builtin container of
each domain) This group can perform maintenance tasks on domain
controllers. It has the right to log on locally, start and stop
services, perform backup and restore operations, format disks,
create or delete shares, and shut down domain controllers. By
default, this group has no members. -
Account Operators (Builtin container
of each domain) This group can create, modify, and delete
accounts for users, groups, and computers located in any
organizational unit in the domain (except the Domain Controllers
OU), as well as in the Users and Computers containers. Account
Operators cannot modify accounts that are members of the
Administrators or Domain Admins groups, nor can they modify those
groups. Account Operators can also log on locally to domain
controllers. By default, this group has no members. -
Backup Operators (Builtin container of
each domain) This group can perform backup and restore
operations on domain controllers as well as log on locally and
shut down domain controllers. By default, this group has no
members. -
Print Operators (Builtin container of
each domain) This group can maintain print queues on domain
controllers. It can also log on locally and shut down domain
controllers.
The default groups that provide administrative privileges
should be managed carefully because they typically have broader
privileges than are necessary for most delegated environments and
because they often apply protection to their members.
The Account Operators group is a perfect example. If you
examine its capabilities in the preceding list, you see that its
rights are very broad, indeed. It can even log on locally to a domain
controller. In very small enterprises, such rights are probably
appropriate for one or two individuals who might be domain
administrators anyway. In enterprises of any size, the rights and
permissions granted to Account Operators are usually far too
broad.
Additionally, the Account Operators group is, like the other
administrative groups listed previously, a protected
group. Protected groups are defined by the operating system and
cannot be unprotected. Members of a protected group become protected.
The result of protection is that the permissions (ACLs) of members are
modified so that they no longer inherit permissions from their OU but,
rather, receive a copy of an ACL that is quite restrictive. For
example, if Jeff Ford is added to the Account Operators group, his
account becomes protected and the help desk, which can reset all other
user passwords in the User Accounts OU, cannot reset Jeff Ford’s
password.
NoteFor these reasons—overdelegation and protection—strive to avoid
adding users to the groups listed previously that do not have
members by default: Account Operators, Backup Operators, Server Operators, and Print Operators. Instead, create custom groups to which
you assign permissions and user rights that achieve your business and
administrative requirements.
For example, if Scott Mitchell needs to perform backup
operations on a domain controller, but he should not be able to
perform restore operations that could lead to database rollback or
corruption and he should not be able to shut down a domain controller,
don’t put Scott in the Backup Operators group. Instead, create a group, assign it only the Backup Files And Directories
user right, and then add Scott as a member.
Windows and Active Directory also support special
identities, groups for which membership is controlled by
the operating system. You cannot view the groups in any list (in the
Active Directory Users And Computers snap-in, for example), you cannot
view or modify the membership of these special identities, and you
cannot add them to other groups. You can, however, use these groups to
assign rights and permissions. The most important special identities,
often referred to as groups for convenience, are
described in the following list:
-
Anonymous Logon
Represents connections to a computer and its
resources that are made without supplying a user name and
password. In versions of Windows earlier than Windows Server 2003,
this group was a member of the Everyone group. In Windows Server 2003 and later
versions, this group is no longer a default member of the Everyone
group. -
Authenticated Users
Represents identities that have been authenticated.
This group does not include Guest, even if the Guest account has a
password. -
Everyone
Includes Authenticated Users and Guest. On
computers running versions of Windows earlier than Windows Server
2003, this group includes Anonymous Logon. -
Interactive Represents users
accessing a resource while logged on locally to the computer
hosting the resource, as opposed to accessing the resource over
the network. When a user accesses any given resource on a computer
to which the user is logged on locally, the user is automatically
added to the Interactive group for that resource. Interactive
also includes users logged on through a remote desktop
connection. -
Network Represents users
accessing a resource over the network, as opposed to users who are
logged on locally at the computer hosting the resource. When a
user accesses any given resource over the network, the user is
automatically added to the Network group for that resource.
The importance of these special identities is that they enable you to provide
access to resources based on the type of authentication or connection
rather than on the user account. For example, you could create a
folder on a system that allows users to view its contents when logged
on locally to the system but does not allow the same users to view the
contents from a mapped drive over the network. This is achieved by
assigning permissions to the Interactive special identity.
Practice Administering Groups in an Enterprise
Practice Administering Groups in an Enterprise
In this practice, you perform best-practices group
management tasks to improve the administration of groups in the
contoso.com domain. To perform the exercises in this practice, you
need to have the following objects in the contoso.com
domain:
-
A first-level OU named Groups. -
A global security group named Finance in the Groups
OU. -
A first-level OU named User Accounts. -
A user account named Mike Danseglio in the User Accounts
OU. Populate the user account with sample contact information:
address, phone, and email. Reset the password of the account
so that you know it. Make sure the account is enabled and that
the user is not required to change the
password at the next logon.
In this and other practices in this training kit, you will
log on to the domain controller with user accounts that are not a
member of Domain Administrators or the domain’s Administrators
group. Therefore, you must give all user accounts the right to log
on locally to the domain controllers in your practice environment.
Follow the steps in the article, “Grant a Member the Right to
Logon Locally,” at
http://technet.microsoft.com/en-us/library/ee957044(WS.10).aspx to
grant the Allow Logon Locally right to the Administrators and
Domain Users groups. If you will use Remote Desktop Services to
connect to the domain controller—rather than logging on
locally—grant the Allow Logon Through Remote Desktop Services
right. This is for the practice environment only. In a production
environment, you should not grant users the right to log on to
domain controllers.
EXERCISE 1 Create a Well-Documented
Group
In this exercise, you create a group to manage access to the
Budget folder, and you follow the best-practices guidelines
presented in this lesson.
-
Log on to SERVER01 as Administrator and open the Active
Directory Users And Computers snap-in. -
Select the Groups OU in the console tree. -
Right-click the Groups OU, point to New, and click
Group. -
In the Group Name box, type ACL_Budget_Edit. -
Select Domain Local in the Group Scope section and
Security in the Group Type section, and then click OK. -
Click the View menu and ensure that Advanced Features is
selected. -
Right-click the ACL_Budget_Edit group and choose
Properties. -
On the Object tab, select the Protect Object From
Accidental Deletion check box and click OK. -
Open the group’s Properties again. -
In the Description box, type BUDGET (EDIT). -
In the Notes box, type the following paths to represent
the folders that have permissions assigned to this
group:
\\server23\data$\finance\budget
\\server32\data$\finance\revenue projections -
Click OK.
EXERCISE 2 Delegate Management of
Group Membership
In this exercise, you give Mike Danseglio the ability to
manage the membership of the ACL_Budget_Edit group.
-
Open the Properties dialog box of the ACL_Budget_Edit
group. -
On the Managed By tab, click Change. -
Type the user name for Mike Danseglio, mike.danseglio, and then click
OK. -
Select the Manager Can Update Membership List check box.
Click OK.
EXERCISE 3 Validate the Delegation of
Membership Management
In this exercise, you test the delegation you performed in
Exercise 2, “Delegate Management of Group Membership,” by
modifying the membership of the group as Mike Danseglio.
-
Open Command Prompt and type the following command:
runas/user:mike.danseglio
cmd.exe. -
When prompted, enter the password for Mike
Danseglio.
A new command prompt window appears, running as Mike
Danseglio. -
Type the following command on one line, and then press
Enter:
dsmod group "CN=ACL_Budget_Edit,OU=Groups,DC=contoso,DC=com"
-addmbr "CN=Finance,OU=Groups,DC=contoso,DC=com" -
Close both Command Prompt windows. -
In the Active Directory Users And Computers snap-in,
examine the membership of the ACL_Budget_Edit group and
confirm that the Finance group was added successfully.
|
