dcsimg

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

By ServerWatch Staff (Send Email)
Posted Jun 28, 2001


by Dan DiNicolo
http://www.win2000trainer.com

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:
 
- Group policy linking, delegation, inheritance, and filtering.
- Deploying Software via group policy
- Active Directory forests and trust relationships
 
 
Group Policy Part 2
 
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.

Page 1 of 3


Comment and Contribute

Your name/nickname

Your email

(Maximum characters: 1200). You have characters left.