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

Thursday Jun 28th 2001 by ServerWatch Staff

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.

by Dan DiNicolo

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:

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.

Deploying Software via Group Policy
Since the basics of this topic were looked at in previous articles, so my intention is to look at some of the more advanced options here. For the purpose of review, the basics of group policy are outlined below.
In an AD environment, group policy allows us to distribute software to users and computers using a repackaged file format, .msi. When software is deployed using group policy, the user needs no special privileges, since the software is installed using the elevated privileges of policy. If a vendor does not provide an msi file for their software, you can use a repackaging program, such as WinInstall LE (found on the Windows 2000 CD) to create one.

The two basic options when deploying software via group policy are to either Assign or Publish it. Software can be either published or assigned to users. If assigned, the software appears to follow the user, regardless of where they log on. Shortcuts appear on the start menu, but the software isnt actually installed until they click on the shortcut. When assigned to a computer, the software is installed on that computer the next time it reboots, and is available to all users of the system. When software is published (which can only be done to users, not computers), the software is available to install from Add/Remove programs, and can also be installed by document invocation (when a user click on a file type associated with that application).

Publishing software makes it available to users, but doesnt create the illusion that it is actually installed. An application can also be published using a .zap file, if an msi does not exist or if one cannot be created. Note that if a .zap file is used, the user will require a level of privilege suitable to install the application. Also note that software deployment options are only applicable for Windows 2000-based systems, and would not be applied if a user logged on to Windows 98, for example. 

The Software Settings area of group policy is where the publishing or assigning options are set, as shown below:

When an application is deployed by group policy, the first option that must be chosen is whether the application will be published or assigned, as shown below:

You should use filtering of GPOs sparingly, as they can complicate GPO troubleshooting. The advanced elements of software deployment can be set up when you originally choose to deploy the software (by choosing Advanced published or assigned as shown above), or later by accessing the properties of the deployed software. The advanced properties allow you to control a number of elements with respect to the deployment, including the addition of upgrades or patches, modifications, as well as uninstalling packages.
There are 6 property sheets associated with advanced application deployment, and you should be familiar with them. The general tab lists basic information about the package (such as the version number), while the security tab contains the ACL for the object. The deployment tab, shown below, controls whether the application is published or assigned (which can be changed). If published, you can control whether or not the application will be installed by document invocation (this option is grayed out when you choose to assign an application).

Note the option to uninstall the application when it falls out of the scope of management. If this is chosen, and the GPO that deployed the software no longer applies (for example if a user or computer object was moved), then the software would be automatically uninstalled. The installation user interface options allow you to control how much interaction the user will have during the installation process.
The upgrades tab (shown below) allows you to automate the deployment of patches and upgrades (such as newer versions) to applications that have already been deployed via group policy. If the upgrade is made mandatory (the required option is selected) then the upgrade will be applied, and the user will only be able to use the updated version. If it were not made mandatory, then the user would be able to use both the old and new versions of the software. This is potentially useful when a new application is not backwards compatible.

The categories tab allows you to create and control the way that applications are presented in Add/Remove programs. For example, you could create categories for each type of software, such as graphics applications, word processors, and so forth. This section would allow you to group the newly published application into one of those categories in order to make it easier for a user to install the correct application.
Finally, the modifications tab (shown below) allows to further customize a package for users with special needs. For example if you wanted to deploy a language-specific dictionary for users in different offices, you could apply a modification to the package. Modifications are made in the form of .mst files (also known as transform files). For those who are interested, there is a utility provided with the Office 2000 resource kit to create .mst files.

Active Directory Forests and Trust Relationships
As I outlined in previous articles, all domains within an Active Directory forest are capable of accessing one another due to the nature of the trust relationships that are automatically created. A transitive two-way trust relationship exists between every child domain and its parent domain, and transitive two-way trust relationships exist between the roots of all trees. It should be noted that in some cases you will need to create additional trust relationships, both within and external to your forest.
For example, you might have a domain that is still running Windows NT 4, whose users you wish to be able to access a domain in your Active Directory structure. This would require an external trust, which is very similar to the trust relationships that you should be familiar with from NT 4. These trusts are one-way and intransitive, meaning that they can only be used to provide access to a single domain. In the scenario I described above, the trust relationship might look something like the diagram below:

In this particular example, users from the domain NT4DOMAIN would have access to resources in the asia.win2000trainer.com domain only. Of course, a two-way trust could be created between the two, allowing users from asia.win2000trainer.com access to resources in NT4DOMAIN. If users in NT4DOMAIN needed access to resources in all 3 of the win2000trainer.com domains, 3 trust relationships would need to be created at a minimum.

The tool used to create external trust relationships is Active Directory Domains and Trusts. This tool is used to create, manage, and verify trust relationships between domains. Note that the tools will show both internal and external trust relationships that exist. By accessing the properties of a domain, you can view the trust relationships that exist on the Trusts tab, as shown below:

Note that the domain name, relationship (internal/external), and whether the relationship is transitive will appear on this screen. Note that like NT 4, for security purposes external trust relationship information must still be entered in both domains participating. Note that external trust relationships can connect a Windows 2000 domain with NT 4 domains, Windows 2000 domains (from different forests), as well Kerberos v.5 realms.
The second type of trust relationship that can be created is referred to as a shortcut trust relationship. This type of trust is created to shorten the path that needs to be followed for the purpose of authentication. For example, if I had a forest as shown below, getting to china.asia.win2000trainer.com from europe.win2000trainer.com would require crossing 3 trust relationships, as shown below:

If users in europe.win2000trainer.com did need to regularly access resources in china.asia.win2000trainer.com, it might make sense to create a shortcut trust (as shown below) to lessen the number of trust relationships that would need to be traversed. Note that shortcut trusts are two-way transitive trusts, and that they are also created in Active Directory Domains and Trusts.

In order to verify trust relationships, you can use the edit button in Active Directory domain and trusts when a domain in the list is selected:

The will attempt a secure channel query to the other domain, and will return results as to whether it was successfully able to verify the relationship or not. Further to this, another tool that you should be aware of for verifying trust relationships is Netdom.exe, a command-line utility that can be found in the Windows 2000 resource kit.
And here ends yet another week. Next week I'll continue with a look at Kerberos, replication, AD database maintenance, and operations masters' maintenance. Thanks again to everyone who has been supporting the series, and a special thanks to all those who contacted me last week after the newsletter came out. As always, feel free to contact me with your questions and comments, noting that I ask that all technical questions be posted to my message board for the benefit everyone. Until next week, best of luck with your studies. 


Mobile Site | Full Site
Copyright 2017 © QuinStreet Inc. All Rights Reserved