70-240 in 15 minutes a week: Group Policy (Part 2), ASD, and Trusts

Welcome to article number 17 in my 70-240 in
15 minutes a week series. This week's article covers part two
of group policy management, followed by a look at software
distribution settings and advanced forest management concepts.
This includes a closer look at linking, delegation, inheritance
and filtering, advanced software deployment options, and domain
trusts. Next week the Active Directory section will continue,
covering Kerberos, replication, AD database maintenance, and
operations masters' maintenance.
The material to be covered in this article includes:

The section completes the discussion on group policy that was
started in last week's article.
Group policy objects are stored in Active Directory, and are
usually associated with at least one object, such as a site,
domain, or OU. However, GPOs can be applied to multiple objects,
an idea referred to as linking. For example, I could link a
group policy object already linked to the Sales OU to another OU
(like Marketing), as shown below:
Article 17 in Dan DiNicolo's 70-240 in 15 minutes a week series covers part two of group policy management, followed by a look at software distribution settings and advanced forest management concepts. This includes a closer look at linking, delegation, inheritance and filtering, advanced software deployment options, and domain trusts.

Although it is possible to link a GPO
from one domain to an object in a different domain, this is not
recommended, due to the fact that a domain controller from the domain
where the GPO resides will need to be contacted during policy
application.

The ability to create GPOs, edit GPOs, and link group policy objects can
be controlled using object permissions, group membership, and though the
Delegation of Control Wizard. In order to create a GPO, a user must be a
member of the built-in group called Group Policy Creator Owner group
(only the domain administrator is a member by default), as shown below:

In order to manage group policy links
for an object (adding, removing, etc), the user must have both the
gPLink and gPOoptions permissions read and write permissions for an
object. Most commonly, these permission are given by using the
Delegation of Control Wizard, choosing the options show below:

Finally, the ability to actually edit
the GPO's settings are controlled by the ACL on the GPO. Don't
confuse this with the ACL belonging to the object that the GPO is
applied to. You can get to the GPO's ACL by clicking on the Properties
button when a GPO is selected, as shown below:

By giving someone both read and write
access (at a minimum), the user would then be allowed to edit GPO
settings. The ability to control not only who can edit GPOs, but also
who can link and create them is a powerful capability give the
administrator maximum flexibility in delegating the administration of
group policy.

Group Policy Inheritance

As mentioned many times in previous articles, group policy settings are
applied in the order Local, Site, Domain, OU. This order controls which
settings end up actually applying to a user or computer. Remember that
all settings merge together by default, and that in the event of
conflicting settings, the one applied latest will apply.

You may have noticed what many do when first looking at group policy
application - this means that an administrator with control of only a
single OU could possibly override settings set by a domain
administrator. This is absolutely true, since OU settings will
ultimately override those set at the domain level in the event of a
conflict. However, this behavior can be controlled via two settings,
Block Inheritance and No Override.
The Block Policy Inheritance setting may seem even worse. If an OU
administrator were to set this on her OU, then all policies coming from
'above' would be completely blocked by default. That is, she could
refuse to inherit any policy settings from the local, site, or domain
levels. Note that this feature is also a powerful capability, in that if
you didn't want any domain policies to apply to your developers, for
example, you could simply block inheritance of policy at the Developers
OU, as shown below:

For those who feel uncomfortable with
Block Inheritance, worry not. Another setting that can be set on a GPO
in No Override, and No Override always beats Block Inheritance. As such,
if I created a policy at the site level set to No Override, and the
administrator of the Developers OU set the OU to Block Inheritance, the
settings contained in the domain policy would still be applied
regardless. Note that other policies without No Override enabled would
still be blocked in this scenario. The No Override setting is set using
the Options button on a GPO, as shown below:

One last thing that you need to know
about GPOs is that they can be filtered. That is, you can control
exactly who a GPO will apply to by set the appropriate permissions in
the GPO's ACL. For example, let's say that you had an OU called
Sales, and you wanted a GPO to apply to all users in the OU except for a
user called SalesAdmin. By default, the GPO is always applied to all
Authenticated Users, who have the Apply Group Policy and Read
permissions set to allow. For out SalesAdmin user, we could prevent the
GPO settings from being applied by giving him the Deny Apply Group
Policy permission, as shown below:

However, you should also recognize
that it provide a powerful way to control policy application to users
and groups, since GPOs cannot be linked to these types of objects.