Objectives
This chapter covers the following Microsoft-specified objectives for the Designing a Microsoft Windows 2000 Directory Services Infrastructure exam:
Design and plan the structure of organizational units (OU). Considerations include administration control, existing resource domains, administrative policy, and geographic and company structure.
Develop an OU delegation plan.
Plan Group Policy object management.
Plan policy management for client computers.
An integral part of designing an Active Directory Services infrastructure is the design and use of organizational units. OUs were designed to be flexible enough to allow organizations to mold them to specific structures, such as IT administration, organizational structures, or even to take the place of existing resource domains. Additionally, OUs are an integral part of the management of client computers through Group Policy.
Outline
Preparing for an OU Delegation Plan
Developing an OU Delegation Plan
The Application of Group Policies
Creating a Group Policy Management Plan
Scope of Group Policy Management
Study Strategies
Don't concern yourself so much with the gory details and the internal technical workings of OUs and GPOs. You need to focus on the big picture—the design of each of these structures for different organizations. Before you take the exam, consider a few companies you know well and design a hypothetical OU and GPO strategy for them. Go as far as to interview a few key people about how they run the network and divvy up administrative tasks.
Make sure you do the exercises at the end of this chapter. They do a good job of walking you through different delegation strategies.
In your test environment, create multiple GPOs that cause something different and visible to happen, such as removing the Run menu option or changing the background. Apply these at different levels of the SDOU hierarchy. Turn on and off blocking and no override and see how that affects users within the hierarchy. Look at the security properties of the GPOs and modify the ACL and see how that affects its application.
Soak up as much additional information about OU and GPO design strategies as possible. The outside resources suggested at the end of this chapter will give you a good starting point for additional information. The Microsoft TechNet Web site is full of additional readings, as is the Windows 2000 Web site. This is one of the core chapters for the exam, so spend quite a bit of additional time here making sure you understand the concepts.
As we discussed previously, a well-known shortcoming of Windows NT was its inability to grant specific levels of administrative control to non-administrators. For example, large organizations that outsource specific areas of IT find themselves in a dilemma when deciding how to allow that outsourced company enough administrative power to perform their service, and still maintain control over the network. With Windows NT, the choices were to add the outsourced company employees to the Domain Admins group, or do the work for them. Neither accomplished the business goals.
The organizational unit (OU) in Windows 2000 not only fixes that problem, but also provides a method of partitioning the domain namespace into a manageable hierarchy of users, computers, groups, shares, printers, and other objects. With such a functional hierarchy, companies now have a structure through which they can delegate a very granular form of administration to a security principle. For example, an administrator can grant Joe Smith—a regular user—the ability only to create new UserID's in a specific OU.
This chapter focuses on the planning and design of the organizational unit structure. We'll highlight the flexibility of OU design by discussing the various OU models, by geographic location, company structure, and operational structure. OUs are primarily used to delegate administrative control, so we'll spend some time discussing how to develop an OU delegation plan. Finally, since Group Policy objects are typically associated with OUs in an organization, we'll discuss some aspects of Group Policy management.
Design and plan the structure of organizational units (OU). Considerations include administration control, existing resource domains, administrative policy, and geographic and company structure.
After you have your domain structure designed, you must consider how to implement the OU structure. OUs are container objects in a domain that can hold other container objects or leaf objects, such as users, groups, and printers. There are several benefits in using OUs, such as the ability to organize directory objects, delegation of administrative authority, and anchoring Group Policy objects. We will discuss each of these benefits, as well as additional planning, design, and management features associated with OUs, throughout this chapter.
Because of the granularity of Windows 2000 security, administrative control can be granted on a per-user, per-object, per-attribute basis. Using a combination of OUs and Access Control Lists (ACLs), you can create an environment that mirrors the way the network is administered. To go even further, you can now extend the administrative control outside the boundary of the domain administrator, allowing the core IT administration team to focus on strategy and network health rather than resetting passwords.
Note
Physical Limitations on OUs . Microsoft suggests your OU hierarchy not go deeper than 12–15 levels; however, there is no true limitation to its depth.
There are several important OU-related facts you must understand before you begin to organize your OU structure:
OUs are not security principals. You cannot treat OUs like security principals and try to base access control off of them. NetWare folks: This is drastically different from NDS OUs! In Windows 2000, access control is the job of Security Groups, such as Domain Local, Global, and Universal groups.
Users do not navigate the OU structure. The structure of OUs will be transparent to users. You should create the OU structure with administration in mind—not users.
OUs have less effect on performance than Group Policy. There is very little processing overhead related to nested OU structures. Microsoft does, however, recommend that you not exceed 12–15 OUs levels in your hierarchy. If you find you need more than that, rethink your design!
GPOs attached to OUs may degrade performance. If you find degrading performance, check the number of GPOs you have within your OU structure; they require much more processing overhead than do OUs.
DNS namespace does not reveal your OUs. OUs are not used to partition the DNS namespace, and therefore are not exposed to the DNS community. OUs can be addressed only by one of the query methods for the directory: ADSI, LDAP, or MAPI.
OUs cannot span domains. OUs are contained entirely within one domain and cannot contain objects from other domains.
The following sections focus on planning the OU structure for an organization.
To effectively plan an OU structure, you must examine the company's organizational structure and its administrative model. You might recall that this sounds very similar to the elements you considered with domain design. It is. The difference lies with the rules you followed with domain design—mainly, if you didn't have a reason to create a domain, you likely have a reason to create an OU. Remember also that OUs are created within each domain, so even if you did have a reason to create a domain, you may still have a reason to create additional partitions within its structure.
The following list highlights some of the reasons you'll likely create OUs:
All of these are valid reasons for creating OUs; however, the four highlighted in the following sections represent the best reasons.
In Windows NT, to delegate administrative tasks you likely created resource domains. To do the same thing in Windows 2000, you simply create an OU and delegate specific ( granular) administrative tasks within that OU. You group users, groups, printers, shares, and so on together so a single administrator may control them. By creating a tree of OUs within your organization and delegating the administrative control for parts of it, you can delegate authority even down to the average end-user level.
The scope of delegated administration is very flexible. Generally speaking, though, you can delegate permission to do the following:
Reset passwords only.
Create and delete child objects—users, groups, printers, and so on.
Change attributes on a particular object, such as the first and last name on a user.
Of course, you can delegate many more tasks, but these are the most common.
Because Group Policy objects can be assigned at the site, domain, and OU levels, users or other directory objects that have like policies can be organized into OUs. Group policies allow you to do the following:
Control security options.
Assign or publish software.
Assign logon/logoff (user) and startup/shutdown (computer) scripts.
As you work with the IT administrative structure within the organization, Group Policy must be considered and probably should be considered close to the top of the list. The fact that software can be distributed via these GPOs to the OUs to which the GPOs are attached can significantly reduce the management and administration of software standards throughout the organization.
OUs are very good for controlling how objects in the directory partition are organized. A good example is with printers. To give users an easy way to find printers, you could create a domain-wide Printers OU. Because the OU itself contains an ACL to control access to it and its objects, you can control which users see the contents of a particular OU when they perform searches. So for example, it is possible to control which users can view specific types of printers (such as color printers) through OU nesting and permissions.
Note
Permissions and Rights . A design decision made by Microsoft confuses a lot of people, especially professionals moving from the NetWare and NDS world. OUs cannot be used to administer rights to objects. Conversely, they can be used to control access to their contents during queries.
The use of resource domains to delegate administrative authority within a Windows NT network was an expensive but necessary evil. Because that is no longer a necessity, companies moving to Windows 2000 need to determine what to do with existing resource domains. One (not-so-trivial) option is to collapse resource domains into OUs. Although this task is not easy and may require the assistance of a Microsoft or third-party migration utility, the end result is at least one fewer domain to manage, which means fewer trusts to manage, which means more sleep for administrators!
You should understand a couple of things before you begin the OU structure. First, because objects within an OU structure are configured by default to inherit Access Control Entries (ACEs, the specific security entries that make up an ACL) from their parent object, moving an object from one OU to another may cause changes to the ACL of the object and result in certain accessibility issues. Second, since GPOs are assigned at the OU level and apply by default to every object within that OU, moving an object from one to another may change the group policies applied to it and therefore cause security problems and other unexpected changes.
Note
ACEs and ACLs . Access Control Lists (ACLs) are structures attached to objects to control access to them. They consist of Access Control Entries (ACEs), which are the individual users or groups permitted access to that object and the associated permissions. Both ACEs and ACLs will be covered throughout this chapter.
It is recommended that you examine both the inherited ACEs and GPOs associated with each OU before you attempt to move objects between them.
Keep in mind that as with everything else with Windows 2000, there are several useful ways to create your OU structure. Because of this, we are going to stick with the general guidelines and let you fill in the specifics based on any given situation.
To build a meaningful OU structure, you must consider the current domain structure of the organization and how the IT group is structured within the domains. These very high-level guidelines set the stage for more specific guidelines, as included in the following sections.
As mentioned previously, your OU structure can be as deeply nested as you see fit—there are no physical limitations on this. However, realistically the structure should not exceed 15 levels, and LDAP queries begin to degrade at a depth of five levels. If you find your OU structure is consistently exceeding these soft boundaries, you need to reconsider your domain structure and take another look at the administrative structure of the organization.
You should name
OUs with descriptive names that reflect the structure that they represent. For example, if in the domain eastus.wayfront.com the WayFront organization has Sales, Services, and Administration departments, they might form their OU structure according to those departments, and name them Sales, Services, and Administration. These names are relatively static, which is the key to naming OUs. OUs that represent structures within the organization that are likely to change—such as OUs for special projects—become an issue when a particular project comes to an end and you are faced with deleting the OU and restructuring its objects.
To make a long story short, model OUs after something that is not likely to change. The following two sections illustrate how and where to discover these areas of business.
The way the company is organized represents its organizational structure. If you've seen an organizational chart for the company, you've gained insight as to how the company is organized and how it operates within its geographic scope. Remember the previous chapters on this stuff?
It is best to begin with the organizational chart because it typically defines the functional divisions of the company and says something about how its employees work. Figure 12.1 illustrates a hypothetical organizational chart for a WayFront domain.
Depending on the administrative requirements within each of these functional areas, they may be represented by one or more OUs each.
There are three types of administrative models within an IT organization: centralized, decentralized, and hybrid. We discussed each of these models at length previously in this book. This is where you need them. Within each division (or region or branch or other unit)of a company, IT resources must be managed in some way, shape, or form. In the case of WayFront, the remote satellite offices are managed by their corresponding regional office. Close scrutiny of the administration model for this office will help you understand how the OUs need to be structured. Keep in mind that you not only must consider how resources are managed, but also need to consider Group Policy.
In this case, the east region headquarters IT staff manages all of the remote satellite office resources from the east region headquarters. They do, however, grant delegation of control to specific users and allow them to do password resets for all users in the site. Based on this model, they could use the OU structure illustrated in Figure 12.2.
Figure 12.2 points out the most significant influences to its design, which are the following:
Overall administrative control resides with the IT administrative group at the east region headquarters.
Specific applications for each functional group need to be published via Group Policy.
A special group of users is delegated the administrative ability to reset passwords for the entire remote office.
By creating an OU hierarchy within domains within domain trees within a forest, you really have a ton of flexibility and are able to closely mirror the organizational and administrative structure of a company. By using OUs rather than domains where possible, you are also able to eliminate a lot of the complexity associated with managing multiple domains.
Because Windows 2000 and Active Directory remove the 40MB SAM database limitation, organizations that introduced additional resource domains can now be implemented as a single domain with geopolitical boundaries—such as continents, countries, regions, states, and cities—set up as OUs. Appropriate administrative control can then be handed back to appropriate individuals or groups as a delegation. You must consider the rules for creating a domain before you decide you want to use exclusively OUs.
The following sections expand upon the flexibility of Windows 2000 OUs.
Any company—large and geographically dispersed, or small and centralized—can choose to implement a single Windows 2000 domain. Large companies that may have a presence across the United States can partition that domain using OUs based on geographic location. A company that fits this model is Components Galore, Inc. (CGI), a national company with offices in several cities in several states. Figure 12.3 illustrates just one way CGI could implement OUs.
Figure 12.3. Components Galore designed its first- and second-level OU structure according to geographic location.
Using this model, CGI can simply add a second-level OU when a new office is opened up in a specific region. The first-level OUs can be used to assign regional group policies or even delegate control over an entire region. They may also be used for nothing but a placeholder in the hierarchy.
Keep in mind that this model can be used for multinational models as well. However, there often is a difference in preferred languages to contend with from one country to the next. When this situation arises, you must create additional domains because (as discussed in Chapter 11, "Designing the Active Directory Structure" ) character sets, currency, and so on, are focused at the domain level.
Countries, cities, states, regions, and other geographic disciplines tend not to move or change, so your first-level OUs remain static. This is one of the general recommendations in developing the OU structure. Another advantage is the fact that administrators have a good idea where an OU's objects are physically located if they are broken down by location. This is important now and again when a physical computer may need to be located or a user calls in with a question.
Sometimes the geography of a company doesn't match the organizational diagram and therefore may be difficult for administrators and users to comprehend. In this case, what typically ends up happening is confusion concerning to which business function a user, printer, or other resource actually belongs.
Some companies are organized more by business function or department. In cases like this, the OU structure should be focused on these areas more than on geographic boundaries. Such a company typically categorizes its business as functional practices or divisions, and each of these practices or divisions likely has one or more subcomponents, typically in the form of departments. eMagic operates in this fashion, and organizes its single-domain OU structure as in Figure 12.4.
Figure 12.4. The eMagic company organizes itself by functional practice. Each functional practice has one or more subpractices.
eMagic can expand its business by adding more functional practice areas and by adding departments or subpractices within each of these practice areas.
Well-established business functions typically do not change, so the first-level OU structure should remain static.
Many companies will use the first two levels of the OU structure to reflect the IT administration model itself. For example, a company that uses decentralized IT administration throughout the country might structure its OU model to reflect the IT hierarchy, as in Figure 12.5.
You may have noticed in Figure 12.5 that SpeedThought uses an IT model that is focused on specific departments—in this case, Sales and Services. Under the second-level OUs then could be further divisions within each department that break out of the IT administration model. For example, the IT Sales OU could be further divided into Outside Sales and Inside Sales, and the IT Services OU could be further divided into Professional Services and Technical Services.
Figure 12.5. The SpeedThought organization uses the first- and second-level OUs to reflect its IT administrative hierarchy throughout the company.
Some of the larger corporations organize by cost centers, which typically represent separate business units. The OU structure is flexible enough to accommodate this model as well. The giant MG Motor Corporation (MGMC) is just such a company. They have literally hundreds of business units to accommodate several different lines of business in the auto market. Their OU structure (scaled down for this illustration) might resemble Figure 12.6.
This model would work well in a conglomerate where each business unit is treated separately from the rest of the organization.
There are more disadvantages to using this model, even if each business unit is managed autonomously. Administrators run into the same issues as with other models, such as not knowing where resources physically reside. There is also a good chance that users from different departments or different functional units may be grouped into one OU but require different software or have different desktop restrictions that make Group Policy assignment complex. Finally, the names of business units often change in today's business environment.
Similar to the cost center model represented as a business unit model, organizations whose business revolves around project-based work, such as a building contractor or a consulting company, may choose to structure their OUs accordingly. Figure 12.7 represents the NewStrategy Consulting Company, which uses this OU approach.
Using project-based OU structures breaks a major recommendation in OU design—that OUs should remain relatively static. The definition of a project states that it has a definite start and end time. What happens to the resources when a project ends? They must be reassigned to other OUs. What happens if a consultant is part of many projects at the same time? Just about all the other disadvantages related to OU structures apply here as well, such as administrators having no idea where geographically or departmentally a resource exists. To make a long story short, don't use project-based OUs at the top level. They can be used as a lower-level structure if the company is organized in such a way, but keep in mind that they will require a lot of administration.
The best approach you can take at planning the OU structure is to determine exactly how the company runs its business through the administrative eyes of IT. You will most likely create a hybrid of two or more of these models according to the company. Look at the organizational chart. Is there a separate chart for each location? If so you may consider using geographic locations for the top level or two. The most important thing to remember, though, is that the OU structure should be developed according to how the company administers and delegates control of IT resources within the operational and organizational structures. Don't just start creating OUs. You must sit down with the IT administrative staff and plan it out. What is the administrative model? How many locations are there? What are the core business units? Do they exist at each location? Is there IT staff at each location? In each region? These questions and more like them are the ones you need to answer during the planning process.
Don't forget about the Group Policy thing either. If you plan to use Group Policy to distribute software or lock down user workstations, you must consider how you plan to do that through the OU structure.
The OU structuring options we discussed in this section are popular options for beginning the overall OU design, but are not exhaustive by a long shot. Again, the flexibility is tremendous, which gives you the ability to mold the OU structure as tightly as you want around the business and IT administration model of the company.
You create an OU structure to do a lot of things: organize objects with like requirements, apply group policies, delegate administrative control, logically structure the directory to reflect the organization, and so on. Deciding what OUs to create, how to create them, and what you should associate with each OU itself can be a daunting and time-consuming task. The following sections discuss the OU itself and what you should include in your design specifications to ensure a smooth implementation.
By the time you sit down to actually design the OU structure, you should have a high-level plan in your head. You should have the company IT administrative organizational chart in hand, along with other organizational charts for each division or segment of the company. For each OU you create, you must be able to answer the following three questions:
Why are you creating the OU?
Who will perform administration on the OU?
What permissions will the OU administrator require?
The following sections explain why these questions are important.
You must have a good reason for creating the OU. Remember, OUs at the first few levels should remain relatively static. If someone asks you why you are creating a specific OU at a specific level, you should be able to explain, right? For example, you create an OU named Midwest Region at the top level. Chances are you created this OU as a placeholder for the second and third (and deeper) levels of OUs to create a logical structure. You probably didn't create it to delegate administration or distribute software to specific sales employees.
Each OU should have a manager associated with it. The OU configuration window contains a Managed By tab on which you can select an administrator from the directory to be "in charge" of that OU. As you (presumably the domain administrator) delegate the administration of the OU structure throughout the domain, you must determine what level of access the OU managers will have over that OU. The OU manager is responsible for performing the following OU-level tasks:
Performing additions, deletions, and modifications to all objects within the OU
Determining whether OU permissions should be inherited from parent OUs
Determining whether OU permissions should be propagated to next-level OUs
Delegating next-level OU authority to other administrators
The domain administrator can always take ownership of any OU in the domain.
Each OU manager must have a certain level of control over that OU. When you delegate the administration to the next-level administrator, you control the level of administrative power he or she has over that OU. You do this by using the Delegation of Control Wizard to modify the ACL on the target OU. This process is handled by granting a user or group permissions for the OU. You cannot grant another user OU permissions because the OU is not a security principal.
Keep in mind that whatever permissions you grant the OU administrator apply for all objects within that OU and will also apply for any additional OUs produced under that one.
You must consider delegating to OU administrators the ability to perform the following tasks:
Create, delete, and manage user accounts
Reset passwords on user accounts
Read all user information
Create, delete, and manage groups
Modify the membership of a group
Manage Group Policy links
A plethora of custom, granular, single-task options, such as adding users to the OU
It is important that you understand here that delegation, although a powerful concept, can turn around and bite you. Be careful that too much delegated authority doesn't wind up in the wrong hands.
The following sections discuss the OU hierarchy and specifically what should exist at each level. Some of this may be a bit repetitive from the previous sections, but repetition of this kind of information can do you nothing but good!
Let's start from the very top. In an international company, the first-level OUs will likely end up as continent names. If you follow best practices, however, these divisions of the namespace should be handled by domains. Domains, as you should recall, should be used when multinational character sets or languages need to be implemented. Also, domains are a security and replication boundary, and networks between countries are usually not fast enough to sustain intra-domain replication.
Whether your first-level partitioning is a domain or an OU, the same primary rule still applies—that is, the name should be static and stable. This means it should not change and should be able to withstand a company reorganization.
It is also important that you keep in mind that first-level OUs do not have to represent the physical geography of the company. For example, if a company has two locations, one in Indiana and one in Washington, but the administration for both is done from Indiana, there is no need to create separate OUs. This will be a very difficult concept to grasp because your first instinct is to separate by physical geography. Remember, the OU structure is there for you to model the administrative structure of the organization. If you want to use geographic-based OUs, you can certainly do so; just keep in mind the purpose of OUs.
In a large company, the second-level OUs often end up being countries if that company operates internationally, or cities if that company operates in one country only.
Of course, each of the second-layer OUs must be a child of a first-layer parent, as you saw in some of the previous figures. One additional thing about second-layer OUs when using the country as a name: It is recommended that you use the ISO 3166 standard two-character country code to name the OU. This is just a recommendation, not a requirement.
Note
Why Not States for Second-Level OUs? . States aren't prohibited from being used at the second level, of course—it just works out most often that states are not used at this level. For a multinational company, often the first layer OU ends up being the continent and the second layer the country. In a national company, often the first layer OU ends up being the state or region, and the second layer the city.
If you choose to integrate individual U.S. states at this level (because most states are as large as some foreign countries), you should follow the U.S. Postal Code two-character format because individual states are not represented in ISO 3166. If you do this, be keenly aware of potential ISO 3166 / U.S. Postal Code conflicts, such as Canada and California (CA), Columbia and Colorado (CO), Albania and Alabama (AL), and so on.
Note
ISO 3166 Country Codes . For more information and a complete listing of the ISO 3166 country codes, please visit http://www.din.de/gremien/nas/nabd/iso3166ma/ codlstp1.html.
It is likely that you won't place any or many resources in the first two levels of OUs because you'll want to drill down a few more layers to integrate the business model. The remaining levels of OUs should be defined according to the company model within the second-level OU. For example, an international company whose first-level OU is based on continent and second-level OU is based on country may look like Figure 12.8. TrainingKit Incorporated is a multinational company with decentralized IT administration. Within each region, TrainingKit operates in a centralized administration model and uses Group Policies to publish software for each department. They have a need to allow departmental administrators the ability to reset passwords for that department's users only. The subsequent OUs may look something like Figure 12.9.
Figure 12.8. TrainingKit Incorporated is an international company with a hybrid administration model. The corporate office is in Paris, France.
Figure 12.9. TrainingKit needs the ability to publish department-specific applications to its users and to allow departmental based representatives the ability to reset passwords.
Again (I can't say this enough), OUs are flexible! You can implement them in any of a thousand different ways to reflect your organization.
It is important after looking at Figure 12.9 to reiterate that OUs carry very little overhead in terms of performance. In fact, there is no theoretical limit as to the number of nested OUs you can create. Microsoft does recommend that you keep the number of nested OUs to 15 or fewer, and there is no reason you shouldn't be able to do so. The best OU design involves fewer levels and more OUs per level (breadth rather than depth). Group Policy objects that are associated with OUs do cause some administrative overhead, however, so you should take that into consideration during the design process. Also, LDAP searches for objects within a domain (or forest for that matter) begin to degrade at about five levels deep. According to Microsoft, this degradation increases exponentially the deeper you go.
So you now have somewhat of an idea how to design the OU structure for an organization. Now let's focus our attention of the development of an OU delegation plan.
Before jumping right in, though, it is that important you completely understand the Active Directory security model.
We've been discussing delegation of administrative authority throughout this chapter, but what does it really mean? Active Directory provides a method for secure access down to the object attribute level. This means you can expose this granular level of security through OU delegation. We used the example about allowing a specific user or user group the ability to reset passwords only within a specific OU. That is a perfect example of object attribute level security. Those users are only able to modify the password attribute for the user accounts within the OU. Before we get into the delegation of authority, we'll review the security aspects necessary to make it happen.
Active Directory is composed of three main security components: Security principals, security identifiers, and security descriptors. Each of these components plays a key and very specific role in Active Directory security. Table 12.1 explains each of these security components.
Table 12.1. Active Directory Security Components
The security descriptor structure for each object contains the parts illustrated in Figure 12.10, which are explained in the following list:
Owner SID. . The SID of the owner of the object. The owner is responsible for granting access permissions and rights for the object. By default, the SID owner is the creator of the object.
Group SID. . Used to integrate Windows 2000 with non-Microsoft operating systems.
Discretionary ACL (DACL). . The DACL contains the access control permissions for an object and its attributes. It also contains the SIDs that determine who can access the object. These permissions and rights are represented as ACEs, which are explained in the following section.
System ACL (SACL). . The SACL contains a list of events that can be audited for an object.
A client will be able to view objects only in the directory that he has the ability to view. For example, if an administrator wishes to hide the objects in an OU from all users, he can remove the Authenticated Users and Everyone groups from the ACL on the OU. Because the ACL of an object is published with the object in the Global Catalog, only users with permission to view the object can do so.
ACEs are part of both the DACL and the SACL on the security descriptor. They define the "line items" that have specific permissions or rights to an object. Access is controlled through the ACEs and can be either granted or denied. When access is denied, the ACE used to deny access is at the top of the DACL and takes precedence over all other ACEs that grant access to the same object, attribute, or set of attributes. ACEs that both grant and deny access to objects contain the following components:
Globally Unique Identifier (GUID). . Identifies the type of object or attribute.
SID. . Identifies the Active Directory security principal of the ACE.
A set of access rights. . Can be at the object, object attribute, or set of object attributes levels.
Flags. . Control inheritance of the ACE by its child objects.
Every object in the directory has one and only one owner. The user who creates the object is by default the owner of that object, and has the authority to control how the object is accessed and by whom. The owner does not have to be represented in the object's DACL.
The important thing to consider about object ownership is that the owner has full control of the object. She can also delegate the ability to grant permissions to other (presumably administrators) to conserve administrative effort. One such delegation is the take ownership right. The user who is granted the take ownership right can then "seize control" of the object and have full control over its permissions. Once ownership is taken from the original owner, the original owner can perform operations on the object only as allowed by the DACL on that object.
Domain administrators always have the take ownership right over any object in Active Directory.
One of the more important processes to consider during the OU structuring process is inheritance. Objects that are created in OUs inherit the permissions that are granted (via ACEs) to the parent object. Because OUs can be nested inside other OUs, child OUs inherit permissions from parent OUs. By carefully considering this process during design, you can eliminate the need to grant permissions to individual objects within the directory.
When a permission is assigned to an OU (or any other container in Active Directory), it can be applied to the container object only, to the object and all of its children, to its children only, or only to specific children.
Figure 12.11. Right-click an OU and click on the Security tab to view the ACL, ACEs, and Inheritance options. Inherited permissions appear with a grayed check box, as in this figure.
Permissions are determined at the time of creation and are composed of a combination of the schema definition for that object type and that object's parent's permissions. You can choose to block inheritable permissions on a specific object or OU by deselecting a check box on that object. Once you do this, changes to the parent permissions that normally would be inherited by the object would be blocked.
Figure 12.11 illustrates the DACL, ACEs, and inheritance-blocking elements for an Active Directory object.
Okay. You now have enough information to begin delegating administrative control through OUs. You should now have an idea of how the security features work, and should understand how to design an OU structure. Planning the delegation portion uses both of these principles.
Note
Security Tab . You must select Advanced Features from the View tab in the Active Directory Users and Computers utility before you can view the Security tab on objects.
As stated previously, delegation of administration is the process of decentralizing administrative responsibility to other administrators or specific and trusted end-users. The ability to grant attribute-level control through individual OUs is a powerful security concept in Active Directory, and it eliminates the need to create multiple domains for the sake of administration.
As you develop the OU delegation plan, you need to do the following:
Define the type of access administrators will have to OUs.
Understand how you can delegate administrative control.
Understand the tools for delegation.
Each of these tasks will be addressed in the sections that follow.
To form an effective delegation plan, you need to understand what it is you can delegate. Table 12.2 describes the options for delegating administrative tasks.
Table 12.2. Common Options for OU-Level Delegation of Administration
Keep in mind that since you can delegate down to object attribute-level permissions, there are literally thousands of delegation options in Active Directory. The ones listed in Table 12.2 are general and common and should serve as enough of an example for you to grasp the concept.
A critical part of defining the OU structure is defining the delegation plan. This section falls after the section on designing the OU structure in this book only because it made sense to break out delegation so we could focus on it. In the real world, you will put this section to use as you design the OU structure, not afterward.
Crucial to the success of your OU design is defining the type of access and actions that can be performed on objects in every OU. This process will not be easy if your OU structure does not cascade nicely, which is why it is so important to plan and scrutinize it. The goal of your design is to have the ability to delegate control at the OU level.
The following list builds on a previous listing of questions an administrator should be able to answer regarding an OU design. This list takes those questions and converts them to requirements. To define the type of access administrators will have on OUs, you must do the following:
Determine the level of administration IT should retain. You must also decide at what level you will delegate administration to other administrators or users.
Determine to whom to delegate what. This information will help form the roadmap for OU ownership and level of authority granted to administrators and non-administrators.
Determine the owner of each OU. Each OU has an owner that is responsible for its upkeep. By default, the owner is whoever creates the object.
Determine how to handle inheritance. By default, all objects within an OU inherit the permission from the parent object. This may be "turned off" if inheritance is not required.
Build a flexible delegation model. Because each unique object exists only once in the directory, you must build flexibility into your OU structure so you can, for example, grant to a user who may administer one OU the proper permission, while denying that same user access to two other OUs.
Map administrative roles to authority. Always make use of the built-in Windows 2000 security groups before creating additional groups.
Ideally, domain administrators should be responsible only for the following:
Developing the initial OU structure
Repairing mistakes (this is where that take ownership right comes in real handy)
If you follow these recommendations, you can keep the Domain Admins membership to a minimum. Additional OU creation can be handled by "down-level" administrators or even specified end-users. Of course, you never want to stick an end-user who doesn't understand what he is doing in a position of power, controlled or not.
Top-level OUs should be created by delegating full control. Bottom-level OUs should be created for delegating per object-class control. If you have divisions of your company that require their own OU structure, you can perform Step by Step 12.1 to allow delegated creation of the OUs below the top level.
If your organization doesn't have divisions or business units that require full control of additional OUs, the domain administrators can complete the OU structure and retain full control—and administrative responsibility—for the entire organization.
Groups with full control can decide whether additional OUs are required to further refine the administrative control within each division, business unit, or other logical partition within the company. To do this, they need to examine the object classes that will be created in the directory. Common object classes include users, group, printers, OUs, and shares.
For each object class, you should consider the following:
Which groups need full control over a specific object class? Groups with full control can create, delete, and modify objects and object attributes of that class.
Which groups need to be able to create objects of a specific class? By default, the creator of an object is the owner of the object.
Which groups should be only allowed to modify specific attributes of existing objects of a specific object class?
For each case where you decide to delegate control, you will need to create a local group that will be allowed to perform the desired function, add the pertinent user objects to that group, and grant that group the specific right on the highest OU possible. Typically, that OU will be the OU that contains objects the users are granted permission to manage.
Note
Creating Computer Accounts . To reduce administrative overhead, you can modify the ACL on the default computer's container and allow all users the right to add computer accounts to the domain.
There are three tools you can use to delegate control on objects in Active Directory:
Delegation of Control Wizard
Security tab of the Object Properties window
DSACLS.EXE command-line utility
The following sections describe these utilities in more detail.
You can launch the Delegation of Control Wizard by right-clicking an object and selecting Delegate Control from the context menu. The wizard walks you through the following straightforward process:
Select the user or group to which you want to delegate administrative control.
Select the tasks to delegate. You can select from a predefined list of common tasks, or choose to create a customized task list.
If you select from the list of common tasks, you are done.
If you selected to customize the task list, you must indicate the scope of the task you wish to delegate. You can choose to delegate control of the object itself, including all objects within the object and creation of new objects, or you can choose from a list of available objects in the folder.
Finally, you must select the permissions you wish to delegate. You can display general permissions, object specific permissions, and create/delete child object permissions.
The Delegation of Control Wizard essentially provides a step-by-step approach to modifying the ACL on the object. You can choose to directly modify the ACL as well.
To open the Security tab (refer to Figure 12.11), you must have selected to view Advanced Features from the MMC's View menu. This provides a more advanced method of performing the job the Delegation of Control Wizard performs. Additionally, you have the ability to control inheritance of access rights from the parent object.
So far we've really not considered the inner workings of Group Policy as a deciding factor in the OU design. The truth of the matter is that there are two key design influences that affect the structure of OUs: delegation of administration and GPO placement. Group Policy Object (GPO) management can be delegated in much the same way as OU management, and consideration of it is vital to the success of your entire site, domain, and OU hierarchy. The remainder of this chapter will focus on the structure and components of Group Policy and how it influences the design of the OU structure.
Windows 2000 Group Policies are conceptually very simple to understand. You modify a setting and apply that setting to a user or computer, which inherits it. Unfortunately, it is not the concept you will be tested on. Instead, you will be tested on your knowledge of how GPOs work relative to the rest of the Active Directory installation. The GPO concepts are quite simple, but how they are used can be extremely complicated and difficult to follow. They can be inherited from site, domain, and OU (SDOU) levels within the Directory, can be blocked at some levels and filtered through security groups and ACLs at others, and can be managed by several groups of administrators throughout the organization. In short, there is a lot to know and understand about them.
Note
Do You SDOU? . Microsoft uses the terminology SDOU to represent Sites, Domains, and Organizational Units. When you see this terminology throughout this chapter, it refers to one or more sites, domains, or OUs in Active Directory. GPOs can be applied to only these types of objects.
As you continue through the rest of this chapter, keep in mind the following information about GPOs:
A GPO is a standalone object. Even if you right-click an OU and create a new GPO through the properties context menu, you are still creating an object that may stand on its own.
GPOs are linked to one or more SDOU objects within Active Directory. This process occurs automatically when you create a new GPO using the process described in the previous bullet.
GPOs by default affect all users and computers within the SDOU objects to which they are applied.
User and computer objects by default may inherit GPO data from each OU level of the SDOU object hierarchy, but only one site's and one domain object's GPOs may apply to any user or computer object.
GPOs physically reside at a domain level, except for when they are focused at the site level. In this case, they are physically located on the domain controller hosting the forest root domain.
Group Policy Objects contain the Group Policy settings that you create using a Group Policy editor. They store policy information in the following two locations:
Group Policy Container (GPC). . Used for policy data that is small in size and does not change frequently. GPCs are Active Directory objects that contain sub-containers for machine and user Group Policy information. GPCs have version properties, which are used to ensure that its information is synchronized with the GPT, and status information, which is used to determine whether the GPO is enabled or disabled.
Group Policy Template (GPT). . Used for policy data that is large in size and may change frequently. GPTs are implemented as file and folder structures in the system volume (SYSVOL) of domain controllers.
GPO data storage is split into two different locations because of the amount of information that must be stored. You do not want to store logon scripts, registry settings or software installation options in Active Directory because to do so would fill it with a large amount of data, the application of which could bring the system to its knees. Instead, that data is stored in the SYSVOL, which is replicated to all domain controllers throughout the domain, and SDOU objects to which the GPO is linked and references to the GPT location are stored in Active Directory as GPC objects.
To view information in the GPC, use the Active Directory Services Interface Editor (ADSIedit) and expand the Policies object (see Figure 12.12). Each of the GUID's listed under this object represent GPC's for the GPOs defined throughout the environment. If you have not defined any GPOs in your environment, there will still be two entries listed here, one for the default domain policy, and one for the default domain controller policy.
To view the GPT information, navigate to the drive hosting the SYSVOL data on a domain controller in a domain. Change to the <sysvolroot>sysvolsysvol<domain name> folder. When you create GPOs, the 128-bit GUID generated to that GPO is used to create a directory under the preceding path to represent that GPO's GPT. Navigate through this directory structure and you will find policy information for administrative templates, scripts, user-specific settings, machine-specific settings, and more. See Figure 12.13.
To create a GPO, you use the Group Policy Editor (GPE). You can launch this application in a number of ways, but the most popular is to invoke it when linking a GPO to a site, domain, or OU. Remember, to link a new or existing GPO to a SDOU, you select the Group Policy tab on the properties dialog box of the object you wish to link it to. From this interface, you can do the following:
Create a new GPO and link it to this object. . By selecting the New button, you invoke the GPE and may define new policy settings. This option automatically links the new GPO with the SDOU object you are focused on.
Edit an existing GPO. . By selecting a GPO and clicking the Edit button, you launch the GPE to edit an existing GPO.
Link an existing GPO to this object. . By clicking the Add button, you can choose from domain/OU level GPOs, Site level GPOs, or all GPOs to link to the SDOU object.
Remove a GPO from the SDOU object and/or remove the GPO from existence. . By clicking on the Delete key, you can either remove the GPO from the SDOU object, or remove it for good from all objects.
Display GPO options. . By clicking the Options button, you can force the GPO to be applied to all children, even if the children explicitly block policy inheritance, and you can disable the policy from being applied.
Display the GPO properties. . By clicking on Properties, you can choose to disable the user policies or the computer policies from being processed. You can also modify the GPO ACL, and display which OUs are using (linked to) the GPO throughout the site.
There is also a customizable Group Policy MMC snap-in available in the MMC. When you add this snap-in to an MMC, you focus it on a particular GPO.
Suppose you have a group of users that requires a specific Windows desktop setting, such as a screensaver and desktop wallpaper combination. Rather than going to each desktop and manually configuring the settings, you could group the user objects into an OU and apply a Group Policy object. All users within the OU receive the policy by default, and that's that—or is it?
What happens when there are multiple conflicting policies applied to the same object? What happens in the case where one or two or ten of the users within an SDOU object shouldn't get the policy? What happens when that almighty administrator with delegated authority decides users don't need locked-down desktops and undoes a corporate-wide policy? Thankfully, Microsoft asked these questions during development of the Group Policy technology! We'll address situations representative of these questions in the sections that follow. First, let's take a closer look at inheritance.
Like Group Policy, inheritance is conceptually very simple to understand. If a parent has something, then all of its children, its children's children, and so on, implicitly have that something as well. It's much like heredity where human traits are passed on from generation to generation. In Group Policy, only configured settings are inherited by child objects; all other settings are ignored. There are three standard scenarios:
A parent object has a value set, and one or more of its children does not.
A parent has a value set, and one or more of its children has a nonconflicting value set for that same object.
A parent has a value set, and one or more of its children has a conflicting value set for that same object.
In the first scenario, a child that does not have configured values for a setting will inherit its parent's values. There are exceptions to this rule that will be discussed shortly.
In the second scenario, a child that has nonconflicting values for a setting will inherit its parent's values and apply its own. Consider user logon scripts a good example here. Administrators may associate logon scripts with top-level OUs to map standard drive letters, and with child OUs to map departmental drive letters. In this case, the same setting is configured in each GPO and applies sequentially (in hierarchical order) on the client.
Note
DENY Always Wins…Still . Just as the "No Access" NTFS permission always takes precedence on file and folder security, a parent GPO that denies access to something—such as the Run Menu command—will always be applied.
Finally, a child that has conflicting settings will not inherit its parent's settings. In this case, the child OU settings prevail and are applied to all of its children. A good example here would be disabling the Run menu item. If the Run menu item is set to "on" on the parent, but an administrator with delegated authority wishes to disable it, the two settings will conflict, and by virtue of being the closest to the user or computer object, the child OU setting wins.
So what happens if in your OU structure you have entire child OUs that don't need a policy assigned to its parent, grandparent, or other higher-level structure? Administrators can block policy inheritance by selecting a check box on the Group Policy properties page of an SDOU object. Policy inheritance stops at the point of blockage. In Figure 12.14, you see the logical flow of inheritance through the SDOU structure. If you were to block inheritance at the middle OU level, then your inheritance path would resemble that shown in Figure 12.15.
Figure 12.14. Group Policy inheritance begins at the site level and flows down through a single domain and that domain's OU structure.
Figure 12.15. When inheritance is blocked, GPOs linked to SDOUs above the blockage point are not inherited. GPOs linked at the blockage SDOU and below are inherited.
There is one thing to remember here: If you choose to block policy inheritance, you block inheritance of all GPOs linked to objects above the one with blocking enabled.
The problem, of course, with allowing administrators to block policy
inheritance at a child level is that you run the chance of corporate standard high-level policies being disregarded. Because you can delegate the ability to manage and manipulate GPOs to OU administrators, you give them the authority to "overrule" you when it comes to applying policy. Suppose, for example, you create a GPO to remove the Run menu option and link it to the mytoys.com domain. By doing this, you effectively remove the Run menu from every computer in that domain. Because you have a lot of users with differing requirements, you need to have a well-established OU structure based on varying levels of IT administration and geographic location. An OU administrator for the Sales OU four layers deep can block policy inheritance, create a GPO that allows the Run menu, and just like that—your security is compromised.
Do you honestly think Microsoft would allow such a thing to happen? Of course not. Administrators can check the No Override option on a GPO to force its application regardless of blockage or conflicting policies, as illustrated in Figure 12.16.
The problem with what we have discussed so far is that a given GPO applies to all users and/or computers within the SDOU to which the GPO is linked. To combat this problem, we get to the real reason these policies are called "Group" Policies.
Because all objects in Active Directory have an ACL associated with them, there must be a way to allow or deny access to a GPO, which is itself an object. In fact, there is.
In the rare cases where you have members of a SDOU that require different policy settings, you can use Windows 2000 security groups to control the application of GPOs. Figure 12.17 displays the ACL with ACEs for a particular GPO. By default, the security group Authenticated Users is allowed the Apply Group Policy permission. This permission permits the group and its members to receive GPO settings. If you have a subset of users that should not get the settings of a policy, you can simply create a security group for them, and add the security group as an ACE with Deny Apply Group Policy to the GPOs ACL. This group's membership will not be permitted to receive that particular GPOs settings.
You can conceivably take this approach right down to the user and/or computer level, although adding individual user accounts to ACLs is not recommended.
One thing you may assume is that group policies only apply at logon time. In fact there are several different occasions when GPOs apply themselves to the objects they are linked to. For starters, remember that there are two types of GPOs: those that are linked to computers, and those that are linked to users. These two types can be included in a single GPO, which can make things quite confusing. We will discuss how to make them less confusing in a bit. Regardless of where they are defined, Group Policies are applied at the following times:
Computer GPOs can be applied at startup time before the user is logged on, and at shutdown after the user is logged off.
User GPOs can be applied during user logon and logoff.
There is an additional configurable Refresh setting that GPO administrators can choose to enable. There are several issues that need to be considered before this option is implemented, but it will actually refresh policies while a user is logged on and going about his business.
By default, both user and computer policies are refreshed every 90 minutes. You must take this into consideration now when making radical changes to GPOs that are in use on the network. Such changes may cause client computers to function differently and cause confusion and help desk calls, which is contrary to the Group Policy goal.
Figure 12.18 illustrates the Group Policy computer configuration area of the default Group Policy administrative template. Notice all the other settings you can make per GPO on this screen, some of which are explained in the following list:
Disable Background Refresh of Group Policy. You can enable this option to completely disable the automatic refresh of the GPO. By doing this, computer policies will apply only at startup/shutdown, and user policies will apply only at logon/logoff.
Group Policy Refresh Interval for Domain Controllers. You can use a separate value for the refresh setting on domain controllers.
Group Policy Slow Link Detection. You can choose not to apply Group Policies over slow WAN links: This area allows you to define what a slow WAN link is.
You can set the refresh interval to a value between 0 and 64,800 minutes (45 days). Be aware that if you choose the 0 setting, the GPO will attempt to update every 7 seconds. This is not ideal in a production situation because of the amount of traffic it would cause, not to mention the fact that a user's screen might flicker every 7 seconds as the policy refreshes! Because of this, Microsoft recommends not refreshing GPOs more frequently than the default value of 90 minutes.
It is highly recommended that you devise some sort of method of notifying the users when a significant policy update is occurring. You could, for example, create a script that opens a window on the client to explain the update.
GPOs are not limited to Active Directory. Local computers have a scaled-down version of a GPO that is applied before any other GPO—it is called the Local Group Policy Object (LGPO). LGPOs can contain only security settings, scripts, and software policies. You cannot deploy applications using LGPOs. LGPOs consist only of the GPT section since they are not contained within Active Directory. They are not stored on the SYSVOL either, but rather in %systemroot%system32grouppolicy. LGPOs are processed even if the block policy inheritance on the parent SDOU is checked, and, if there is a conflict between an Active Directory GPO and an LGPO, the Active Directory GPO will prevail.
You might see the terminology LSDOU; it refers to the order in which policy objects are applied and includes the LGPO, which is always first. In the next section, we introduce the 4LSDOU terminology, which includes Windows NT 4.0 system policies, which are applied even before LGPOs.
You can't really mix GPOs with Windows NT system policies—they are two different animals. You can, however, place Windows NT system policies on the SYSVOL to allow your down-level policies to be applied to down-level clients. This is especially useful during an upgrade.
Remember these two things when dealing with Windows NT system policies:
If you have any older Windows NT 4.0-style system policies and need to implement their functionality once their target clients are upgraded to Windows 2000, you must convert them (manually) to GPOs; the upgrade process will not do it for you.
You cannot use the GPE to modify Windows NT 4.0 style system policies. You must use the native tools.
We've been hinting at it all along, but haven't really laid it out for you. The following describes how policies—old and new—are applied according to a couple of scenarios.
If you have a standalone Windows 2000 client or member server, policies are applied as follows:
Windows NT 4.0 policy file (ntconfig.pol)
LGPOs
If you have a Windows 2000 client or member server operating in a mixed-mode environment, policies are applied as follows:
Windows NT 4.0 policy file (ntconfig.pol)
LGPOs
Site GPOs
Domain GPOs
OU GPOs applied hierarchically until the user or computer object is reached.
Finally, if you are operating in a pristine Windows 2000 native-mode environment, policies are applied as follows:
As you can imagine, keeping track of everything that goes on within the SDOU structure can be quite challenging. The fact that you can delegate control of OUs and GPOs and at varying levels makes it that much more difficult. That is why planning is so incredibly important to the successful implementation of Active Directory.
Group Policy is a very powerful tool, and as such should be used with restraint. The more you use GPOs, the more apt you are to turn what seemingly may be a good solid plan into complete and total chaos. As with DNS and domain design, OU design and delegation, and site and subnet structuring, you need to sit and thoroughly plan out your use of Group Policy. When you do the plan (you must consider all of the above together) to ignore the integration of each would spell almost certain doom!
To reiterate, the following are the things you must understand at the very least as you begin to plan the structure and management of Group Policies:
Group Policies can be used to configure just about everything about a user's computer and/or working environment.
Policies are contained in a GPO, which is comprised of an Active Directory based GPC and a file and folder (SYSVOL) based GPT. GPOs are then linked to SDOUs throughout the directory.
When a GPO is applied to an SDOU, it applies to all SDOUs and leaf objects within it.
You can block policy inheritance on a SDOU, and can configure individual GPOs to forcefully apply by specifying no override.
You can control access to GPOs through the use of security groups (and security principals). If a subset of users should not get a policy they would otherwise get, you can Deny the Apply Group Policy permission in an ACE on the GPO ACL.
GPOs are processed first at the local machine (LGPO), then at the site level, then at the domain level, and finally throughout the OU hierarchy.
OUs are anchored at the domain level, and are not inherited throughout the domain hierarchy. GPOs from one domain, however, can be linked to OUs in another domain.
Policies that don't conflict are cumulative. If policies do conflict, the one that is applied closest to the object prevails.
Computer GPOs are applied at computer startup and shutdown, whereas user GPOs are applied at user logon and logoff.
The default refresh rate is 90 minutes for both user and computer-based GPOs. This can be changed to a number of minutes between 0 and 64,800 (45 days).
Computer policies always take precedence over user policies.
GPOs are not applied to security groups. Security groups can be used only to configure who has access to have a GPO apply to them. By default, the Authenticated Users group allows all GPOs to apply to all users and computer to which it is applied.
To configure a Group Policy, you need the following:
A Windows 2000 domain controller
Read/Write permissions to the SYSVOL on a domain controller
Read/Write/Modify permissions to the SDOU to which your GPO will apply
As mentioned previously, there are two elements that greatly influence the OU design structure: the delegation of control and GPO placement. We discussed delegation of control earlier in this chapter when we designed the OU structure. Now to add to that, we need to look at how different GPO strategies influence that design. In reality, you would look at both of these at the same time.
There are several design factors again that apply here with GPO placement and design. You need to consider how to handle each of these, as you'll see in the next several sections. The design factors that influence the scope of Group Policy management are as follows:
The IT Administration type (centralized, decentralized, or hybrid)
Delegation of administrative control
Performance
Structure of policy types
The sections that follow detail each of these design factors.
So what do we mean when we say administration type? What does it represent? It represents a hierarchy of administration in most cases. You might have a central corporate IT staff with smaller IT staffs around the country responsible over those locations, one large IT staff responsible for all facets of administration, or a unique derivation of both. Whatever the case may be, the OU structure is focused at providing a hierarchical structure for IT administration and delegation and it always fits into one of the three types of administration.
Group policies are used for a number of reasons. They are used to define client desktop and user specific settings, to roll out and manage software applications, to configure logon/logoff and startup/ shutdown scripts, and more. The one thing all these features have in common is they are all IT administrative functions. It would make sense then that they would be created and applied according to how the IT administrative staff operates.
There are two common ways to structure your GPO design: monolithic or layered. Each has pros and cons and each maps to a type of administration.
Note
Two Structures? Why Not Three? . You can consider the hybrid type administration a form of decentralized administration.
In a monolithic design, the goal is to place all the policy settings for a group of users or computers in an SDOU object into a single GPO for that object. The problem with this approach is twofold: first, you don't have much flexibility in your administrative delegations, and second, the nature of these GPOs makes them general—and there would no doubt end up being an onslaught of GPOs at deeper OU levels to either block or change policies for special cases. The advantage of this design, though, is very quick logon processing time. During the logon process, all GPOs to be applied are applied in order of precedence, one at a time. For example, if a user logs on and must apply seven GPOs, she would have to wait while Active Directory opened a GPO, read its contents, applied its settings, and closed it, seven synchronous times. The advantage, then, with the monolithic design is that there is (conceivably) only one GPO to open and process. Figure 12.19 illustrates the monolithic design.
This approach would be best for a centrally controlled IT infrastructure.
The layered design uses a top-down approach and should be the model implemented in a distributed IT environment. You place purpose-based OUs at each level of the SDOU hierarchy and rely on both inheritance (implicit) and explicit settings for each object. Using a layered design provides administrators with the flexibility to delegate certain parts of administrative control to other areas. They could, for example, create the top-level base GPOs that apply throughout the organization and then delegate the control of OU-based GPOs and leave their design in the hands of a next-level administrator, who could tailor GPOs to fit the functional needs of his users.
The primary advantage to using a layered approach is that changes to GPOs generally will have to be done only on one or a few GPOs and can be inherited by the rest of the organization. The disadvantage is the logon performance hit. Figure 12.20 illustrates the layered design.
Each of the preceding models is definitely something you can implement. The monolithic model, however, does not play well in a distributed environment because of its inherent lack of flexibility in terms of administrative delegation. It's pretty safe to assume that most companies will implement their OUs and GPOs in a layered approach. This approach allows centrally controlled organizations to force policy down from the top level using the No Override option, but it also allows them to loosen their grip and entrust confidants down the OU structure to perform anything from a single, simple task such as resetting user passwords for a specific OU to creating an elaborate substructure of OUs and GPOs to suit their needs.
Figure 12.20. The layered approach focuses on flexibility and delegation of administration more than it does on speed.
The amount of control the central "governing" IT body decides to relinquish to the subordinate administration staff is dependent upon its comfort level with the administration staff—not limitations with technology. This is an important concept to remember.
It may be necessary to enforce critical GPOs created and managed at the top of the Active Directory hierarchy upon all subordinate SDOUs throughout the environment. To do this, you check the No Override Group Policy option. Microsoft recommends that you limit the use of this function and its counterpart—Block Policy Inheritance—because overuse of these options could have an adverse affect on the overall Group Policy process.
Your OU design could be 400 levels deep and your logon performance wouldn't be affected as much as it would if you had to process 10 GPOs. There is no scientific proof of these numbers, but it is true that GPOs are responsible for causing the most lag in logon time. As discussed earlier, each GPO must be processed synchronously, which means they stack up. If a user account resides in an OU 10 levels deep and eight of those SDOU structures have associated GPOs, that client must wait while eight GPO files are opened, processed, applied, and closed—one at a time. The moral of this story is that you should keep a watchful eye on user logon performance as your GPO depth grows.
In some cases, you can use security groups to filter the effect of GPOs. Remember that GPOs are objects and hence have an associated ACL. By adding users who don't need specific policies to a security group, and then disallowing the application of that GPO to that security group, you can eliminate some overhead.
GPOs are rooted at the domain level. This means they are stored on domain controllers in a specific domain. GPO links are replicated to global catalog servers and thus can be applied to any computer or user in the forest. That said, you should be aware of the performance hit you'll take in retrieving the GPO from another domain—especially if that domain is separated by a slow WAN link.
Another strategy you can use to increase performance is to disable the unused portion of all GPOs. Each GPO consists of two distinct sections: the user configuration section and the computer configuration section. One of the best design practices is to create GPOs according to function—that is, to create separate GPOs for user and computer settings. You can break down this even further, as we'll discuss in the next section. To disable a section of a GPO, access its properties page and select the appropriate check box. Figure 12.21 displays the properties box for sitegpo.
Figure 12.21. The properties window for a GPO named sitegpo. You can choose to disable either the unused portions of the computer or user configuration settings on this page.
The result of disabling the appropriate section is that it takes approximately half the time to process only half the GPO—in other words, the disabled part is totally ignored.
The final area we need to discuss regarding the scope of Group Policy management is in the structure of the policy types within a GPO. GPOs can contain a single or multiple policy types, such as software installation policies, logon scripts, user settings policies, computer settings policies, and so on.
In a single policy-type structure, many GPOs may be generated to provide the same functionality as a single GPO using a multiple policy type structure. Figure 12.22, for example, illustrates how multiple policy-focused GPOs can be associated with a single GPO. One of the benefits of this model is the organization of GPOs. With a good standard naming convention, similar policies can appear together in the GPO listing. That doesn't sound like too big a benefit until you have 30 or 40 of them to manage. The downfall of the single policy structure is the performance hit your users are likely to take.
The policies in Figure 12.22 are not necessarily linked directly to the Accounting OU object, but apply nonetheless.
In a multiple policy structure, you attempt to place all policies in a single GPO and apply it to an appropriate SDOU object. Figure 12.23 illustrates the Accounting OU with this scenario in mind. Although it looks simpler to manage, consider who is managing it. This is a good configuration for a small, centrally managed company, but not for a distributed company because all administrators would need to access and potentially modify the same GPO.
Figure 12.23. The Accounting OU now contains only one directly linked OU that contains all settings for its users and computers.
One thing to keep in mind here is the recommendation that you split policy settings by user and computer. This would increase the number of required accounting GPOs to two: one for the computer settings and one for the user settings.
Many Group Policy functions are focused at managing desktop computer environments. Using GPOs, administrators are able to configure a desktop computer once and have that configuration continually enforced. The following key Group Policy settings enable organizations to work toward reduced cost of ownership in the areas of both desktop and server administration. They are the cornerstones to Group Policy:
Administrative Templates. . Administrative templates are a set of registry-based interfaces that allow administrators to configure the application settings, desktop appearances, and behavior of services on all desktop computers that get the policy.
Security. . Administrators can configure security options on the local computer, clients on the network, and on the network itself.
Software Installation. . Through the use of Windows Installer and Group Policy, administrators can deploy, maintain, and remove software throughout the entire network.
Scripts. . Administrators can specify startup and shutdown computer scripts as well as logon and logoff scripts for users and apply them to few or many computers throughout the environment.
Folder Redirection. . Administrators can force client computers to store specific folders, such as My Documents, on a network share.
SMC is in the process of implementing Windows 2000 across its corporate network. The site, DNS, and domain designs have been completed and it wishes to continue the design process with OUs and Group Policy.
SMC currently runs on Windows NT in a single-domain environment and maintains high-speed WAN links between the three racetracks it manages. The Windows 2000 domain design consists of a single-domain structure with three sites. DNS servers exist in each site and manage a single Active Directory integrated zone.
Throughout the implementation of Windows NT at SMC, administration was controlled centrally by the corporate IT staff. Although this process was effective, SMC employees began to become frustrated because the IT staff could not provide services in the required amount of time.
The current system is a Windows NT network with a single domain. All administration is controlled centrally by the SMC IT administration staff. External offices do not have the capability to manage any of their local resources.
"We don't want to give administrators at other offices full domain administrative permissions because we have standards in place here and are concerned that they will deviate from standards."
The envisioned system is one that will allow for centralized administration with delegated control for certain business areas. It will also allow us to incorporate our standard hardware, software, and security settings and enforce those among the network.
"I would like to extend our administrative capabilities to our other offices, but I still want to maintain ultimate control over the network. I'd like them to be able to manage certain areas of and have flexibility with their environments, but not impact the rest of us."
Centralized management with delegation is key. All objects in the directory must be easy to understand and manage.
"We must be able to maintain the entire network from our corporate data center. That means there should not be a thing I don't have access to. I also want to be able to drive corporate standards throughout the organization."
"I have support staff in every building we occupy. Right now, their hands are tied when they need to make even a simple change on a server because they have to wait for someone here to make the change for them and replicate it out. I would like for them to be able to at the very minimum be able to reset passwords for users they assist."
User logon performance is a problem currently, so that is high on the priority list to fix. Network bandwidth between locations is adequate for most operations; however, use of the expensive links should be kept to a minimum unless necessary.
"Our remote users sometimes complain of logon lag time. We have servers at every location so it's hard to diagnose where the problem lies. That problem needs to be addressed during our upgrade."
We discussed a lot of concepts in this chapter, but the most important one to take with you is this: The OU and Group Policy structure should be designed according to the IT administration type first, and the company organizational model second. Before you touch a server, you need to have an OU and GPO plan in place, preferably on paper, and approved by all administrative parties involved in the process. For each level of the OU hierarchy, you need to associate an administrator who will have ultimate control over that section of administration.
You should consider the development of both the OU and GPO structure at the same time to avoid any restructuring or less than optimal implementation of either.
Table 12.3 provides some best practice recommendations in designing both the OU and GPO structure for an organization.
One final note: In case you didn't get it yet—planning is crucial. The domain structure must be correct the first time because it is next to impossible to restructure domains without adversely affecting your users.With OUs and GPOs you have a bit more breathing room because it is fairly easy to restructure; however, getting it right the first time will save you a lot of time and save your company money to say the least!
Table 12.3. Best Practices in OU and GPO Design
| Task | Description |
|---|---|
| Choose the right OU model. | Take caution in choosing the OU model you implement and make sure it accurately reflects the IT administration model as well as the operational structure of the organization. |
| Keep OU design simple. | Reasons to create OUs are as follows:
|
| Delegate administration. | Keep the following in mind as you develop the delegation of administration plan:
|
| Remain consistent in your design. | Consistency is key to keeping things simple. If you have an environment with multiple domains, consider using the same OU model throughout. |
| Plan the location of user and computer objects within the OU structure. | This has a huge impact on the overall OU and Group Policy structure. |
| Plan the Group Policy structure. | The Group Policy structure should be considered all the way through the domain and OU design process. The best-case scenario for the Group Policy structure is to have it flow with your domain and OU structure. |
| Determine GPO management scope. | Determine whether to use single policy-focused GPOs or GPOs that include multiple policies. Determine how to delegate administration over GPOs, and determine whether to use a layered or monolithic design. |
| Keep an eye on performance. | GPOs can degrade performance because they must be processed one at a time. Optimize performance by disabling unused portions of GPOs, using security groups to filter the effects of GPOs, and limit cross-domain references to GPOs. |
In this exercise, you will utilize the Active Directory Users and Computers utility to create a small organizational unit structure and create and apply customized Group Policy objects to specific containers.
You will create an OU structure to model the administrative needs of a fictional company. This company has a centralized headquarters and four offices, one in each quadrant of the U.S. Each office requires its own administration. Each office has several departments that require specific desktop settings and software.
Estimated Time: 45 Minutes
Open the Active Directory Users and Computers MMC utility and expand the domain tree in the left console pane.
With the domain name highlighted, right-click anywhere in the right console pane and select New, Organizational Unit.
Type
Eastas the name of the OU.Repeat Steps 2 and 3 for the North, South, and West OUs. Each should be a child of your domain object.
Note
North and South . The North and South OU structure is not required throughout this exercise. It is there simply to get you comfortable through repetition at creating the OU and GPO structures.
In the left console pane, right-click the East OU and select New, Organizational Unit.
Name the OU
Department 1and click OK.Repeat Steps 5 and 6 so that each top-level OU contains two departments: Department 1 and Department 2. When complete, your left console pane (fully expanded) should be similar to that of Figure 12.24.
Right-click the Department 1 OU under the East OU and select New, User. Name the user
EastDept1and assign it a password ofpassword.Repeat Step 8 until you have a single user account in each of the second-level department-based OUs.
At this point, you have an environment that simulates a real company with decentralized IT administration across four regions of the United States. Each of these regions contains two departments. You have no user accounts in the top-level OUs, and all user accounts in the bottom-level OUs. Realistically, you may have users strewn about the entire structure, but for this demonstration that is not necessary.
To create a Group Policy object and automatically link it to the East OU, right-click East and select Properties, then the Group Policy tab.
Click New to create and link a new GPO. Name the GPO
East and West Base User Policy, as in Figure 12.25.Note
Base Policies . In this exercise, both the East and West offices require the same base settings, and both the North and South offices require the same settings, but different than those of East and West. Remember too that you should split the user and computer settings into different GPOs.
Click the Edit button to launch the Group Policy Editor.
Right-click the GPO container at the top of the left console pane and select properties.
Disable the Computer portion of the policy by enabling the appropriate check box, as illustrated in Figure 12.26. Click Yes to confirm the pop-up message. Click OK to close the Properties dialog box.
The users in both East and West offices are not allowed to have the Run menu on their computers. To disable the Run menu, drill down the User Configuration, Administrative Templates, and Start Menu&Task Bar hierarchy.
In the right console pane, double-click Remove Run Menu from Start Menu.
Click Enabled and then click OK. Notice the updated Setting column entry for this option.
Close the Group Policy Editor.
While still on the Group Policy tab for the East OU, click New to create an additional GPO. Name this one
East and West Base Computer Policy.Click the Properties button while this GPO is highlighted. Disable the User configuration settings by selecting the appropriate check box and clicking OK. (Click Yes in response to the ensuing message.) Click OK.
Click Edit to launch the Group Policy editor.
Under the Computer Configuration, drill down through Windows Settings, Security Settings, and Event Log, and select Settings for Event Log.
In the right console pane, double-click Retain System Log.
Enable this policy setting and increase the number of days to 10 (see Figure 12.27). Click OK. This setting is dependent on the retention method for system log, so you are presented with a window (see Figure 12.28) to let you know of the additional setting. Accept by clicking OK.
Figure 12.27. Increasing the retention time for system event logs ensures that events will not be overwritten until 10 days after they occurred.
Figure 12.28. As a result of increasing the retention time for the system log, you must set the retention method to By Days.
Note
Verifying the Changed System Log Setting . The default system log setting is 7 days, so you will be able to tell the GPO was applied by checking to see if it is set to 10 after you log on.
Close the Group Policy Editor.
Close the Group Policy properties page.
Right-click the West OU and select properties. Click on the Group Policy tab.
To link to the existing GPOs, click the Add button.
Navigate to the east.<yourdomain> object using the drop-down list (see Figure 12.29). Once there, you should see the two GPOs you just created.
Add both of them to your West OU. You cannot multiple select here, so you'll have to add one, then repeat the process to add the other.
If you wish, repeat Steps 10–30 to create two additional GPOs for the North and South OUs. Replace East and West with North and South where appropriate. This will not be required for the additional exercises.
To test the functionality of the OUs, log on to the Windows 2000 domain using one of the user accounts you created. You can use the same workstation to test all accounts. East and West should have no Run menu under Start, and a 10-day retention time on the system event log.
In this exercise, you will use the Delegation of Control Wizard to delegate the ability to reset passwords on user accounts in an OU. This is a continuation of Exercise 12.1.
Estimated Time: 30 Minutes
In the Active Directory Users and Computers MMC utility, right-click the East OU and select New, Group.
Change the group scope to Domain Local and type to Security by selecting the appropriate radio buttons.
Name the group
East Department 1 OU Managersand click OK.Right-click the East OU's Department 1 OU and select New, User.
Name the user
Eastadminand give a password ofpassword.Right-click the Eastadmin user and select Add Members to Group. Select the group you created in Steps 2 and 3 and click OK. Close the results box.
Note
Use of the Security Group . You created the security group so you can delegate administration to a group and not a lone user. You placed the security group in an OU structure you manage so you can keep track of who is a member.
To delegate the ability to allow members of the new security group to reset passwords only in East Department 1, right-click the East's Department 1 OU.
Select Delegate Control to launch the Delegation of Control Wizard. The wizard starts (see Figure 12.30).
Click Next to begin the delegation process. Click Add and select the East Department 1 OU Managers security group to the bottom pane (see Figure 12.31).
Click OK and then Next.
Enable the radio button to create a custom task to delegate (see Figure 12.32). Click Next.
Select the option for Only the Following Objects in the Folder. Scroll to the bottom of the list and check User Objects (see Figure 12.33). Click Next.
Scroll down the permissions options until you find Reset Password and enable it (see Figure 12.34). Click Next.
You have successfully delegated fine-grained administrative control! Notice the nice summary on this window (see Figure 12.35). Click Finish.
The user EastAdmin now has the authority to reset passwords in the East's Department 1 OU only (which equates to his own and that of eastdept1). To test, log on to a server or workstation with the administration tools, navigate to a user object in the East, Department 1 OU, right-click the user and select "Reset Password." Type a new password and click OK. You should be able to do this.
Navigate to the West's Department 1 OU and try the same thing with the westdept1 user. You should get an error when you attempt to complete the process.
The purpose of organizational units is to partition the domain namespace into a manageable hierarchy of users, computers, groups, shares, printers, and other objects. With this partitioning and its nested capabilities, administrators no longer have to create additional domains or add users who need to perform minor administrative functions to the Domain Admins group. See "Introduction." | |
When you create an OU, you should be able to answer why you are creating the OU, who will perform administration on the OU, and what permissions the OU administrator will require. See "OU Associations." | |
There are various options for creating OUs. You can create OUs to delegate complete administration over a specific partition of domain namespace, delegate control over specific objects in the OU, delegate permissions to create or delete specific objects only, and more. See Table 12.2, "Common Options for OU-Level Delegation of Administration," for a complete description. | |
There are three methods available for delegating administrative authority: the Delegation of Control Wizard, the Security tab on the target object, and the DSACLS.EXE command-line utility. See "Delegation Tools." | |
The security descriptor is comprised of the following four objects: the owner SID (security identifier of the owner of the object); the group SID (used to integrate Windows 2000 with non-Microsoft operating systems); the discretionary access control list (DACL), which contains ACEs that describe permissions to that object; and the system Access Control List, which contains a list of events that can be audited for the object. See "Security Descriptors." | |
A GPO contains the Group Policy settings that you specify for application on a site, domain, or OU. It is a virtual container that stores its data in the Group Policy Container (GPC) and the Group Policy Template (GPT). See "Considering Group Policy." | |
Computer GPOs apply when a computer starts up (before a user logs on) and when it shuts down. User GPOs apply at user logon and logoff time. Both GPOs are set to refresh automatically every 90 minutes by default. This refresh time is controllable on a per-GPO basis. See "When Group Policies Apply." | |
Although there is no physical limitation, Microsoft recommends that your OU nesting hierarchy not exceed 15 levels. OUs create very little processing overhead, but if they have GPOs attached to them they degrade exponentially in performance. Additionally, if your OU structure ends up being more than 15 levels, you need to rethink your design. See "Organizational Units." | |
Group Policy Templates (GPTs) are file and folder structures that include all Group Policy information for a GPO. They are stored on the SYSVOL of the domain controllers in the domain in which the GPO is anchored. They are replicated to all domain controllers in the domain. See "Group Policy Objects." | |
Group Policy Containers (GPCs) are Active Directory-based objects that store a subset of GPO information. They include subcontainers for Machine and User Group Policy information and have the following properties: version information and status information. See "Group Policy Objects." |
C. To force your baseline GPOs on all objects in the environment, create an OU structure and then apply your base GPOs to the domain object or top-level OU. Specify the No Override option so that no other conflicting or policy inheritance blocking OUs will overwrite the base GPO. See "No Override." NoteApplying GPOs to the Domain Level . The Domain Admins and Enterprise Admins groups by default contain an ACE in every GPO DACL that does not allow them to partake in GPO processing. This is why you can get away with domain-wide mandatory policies, and not restrict your administrative capabilities. | |
B, C. To delegate administrative authority, create a security group for each administrative team requiring the same level of permissions. You can then either use the Delegation of Control Wizard to give the security group the appropriate permissions over the object, or navigate directly to that object and add the security group and appropriate permissions as an ACE to the object's DACL. An object's SACL is used for auditing and not permissions, and a GPO is used to deliver Group Policy settings for users and/or computers. See "Delegation of Control." | |
A, B. The GPO structure is split into two parts: user configuration and computer configuration. Startup and logon processes (scripts) are configured for computers and users, respectively. So you would create a GPO for a logon script in the user configuration section, and a GPO for a startup script in the computer configuration section. You could create both of these scripts using the same GPO; however, that goes against best practices in keeping the user settings and computer settings in separate GPOs. You should modify policy refresh settings only when you need policies to refresh more or less frequently during the time a user or computer is operational. This will not affect startup/logon settings. See "Structure of Policy Types." | |
A, B, D, F. To optimize the performance of your OU and GPO structure, you should conform to some rules. Specifically, limit the use of cross-domain GPO links. GPOs are anchored at the domain level, so any links to objects in another domain require a connection to the global catalog server. You should also limit your OU nesting to fewer than 15 levels and 5 levels if GPOs are attached to those OUs. GPOs cause the degradation in performance, whereas OU nesting has very little effect on performance. Finally, you should split your GPOs into user GPOs and computer GPOs; take advantage of disabling the user settings on computer GPOs, and computer settings on user GPOs to optimize processing time. See "Performance." | |
B. Because the CIO will be using multiple computers, that automatically rules out options A and D. To allow him access to his files from anywhere on the network, you should create an OU for him and add his user account to it. You then associate the appropriate GPOs with that OU. The GPOs would connect him to his data, display his Windows settings, and make his software available. Option C is incorrect because it does nothing about his data and Windows settings. See "Application of Group Policy and the corresponding Case Study." | |
B. By default, GPOs applied closest to the user object that conflict with other GPOs will prevail. To force a policy upon child objects, you must specify the No Override option. By doing this, administrators can force that policy on child objects even if they are configured to block policy inheritance or have a conflicting setting. See "No Override." | |
B. Because the User Admins are the only group with the clearance to create user accounts in the domain, they must have that permission throughout the domain and should be added to the domain objects ACL accordingly. To allow the departments managers to modify the user account properties only for its users, you should create an OU for that department and delegate permission to modify user properties to a security group you create for the department's managers. You can use the Delegation of Control Wizard for this, or you can manually modify the ACL of the OU. See "Delegation of Control." | |
C. When a Group Policy setting is created, it is stored in a virtual container called a Group Policy Object (GPO). The GPO actually stores its data in two other containers: the Group Policy Container (GPC) and the Group Policy Template (GPT). The Group Policy scripts refer to the logon/logoff and startup/shutdown scripts that are defined within GPOs but are not created at the time of GPO creation. See "How GPOs Work." | |
A. The machine local policy is applied immediately and is followed by the site, domain, and OU hierarchy. Using this model, the settings applied closest to the client computer are the final settings if there is a conflict. The easiest way to remember this ordering is the term LSDOU (local, site, domain, OU). See "Local Group Policies." | |
A. The domain should reflect the name of the company, and you should assume that because there was no mention of multiple sites that the default site was sufficient. The OU structure for this organization needs to be one top-level OU per department because of the varying needs of each. This way, you can associate GPOs with each OU to address the needs of individual departments. Since there are plans to further delegate control in each department, this model is flexible enough to handle that change or addition. The Domain Admins will, by virtue of being Domain Admins, have administrative power over all OUs in the domain. There is no need to add the IT administrators to another group, unless you don't want them to have domain administration permissions. See "Flexibility in OU Design," and refer to Chapter 11 for detailed information on domain design. |
White Paper. Windows 2000 Group Policy.
White Paper. Introduction to Windows 2000 Change and Configuration Management.
Microsoft TechNet Articles:
"Windows 2000: Designing and Deploying Active Directory Service for the Microsoft Internal Corpnet." Available on March 2000 and later TechNet CDs.
"Designing the Active Directory Structure." Available on July 1999 and later TechNet CDs.
"Using the Delegation of Control Wizard." Available on June 1999 and later TechNet CDs.
"Designing the Active Directory." Available on August 1999 and later TechNet CDs.
Nielsen, Morten Strunge. Windows 2000 Server Architecture and Planning Coriolis, 1999. Chapters 8 and 9.
Cone, Boggs, Perez. Planning for Windows 2000. New Riders, 1999. Chapter 6.
Lowe-Norris, Allistar G. Windows 2000 Active Directory. O'Reilly and Associates, 2000. Chapter 9. (This chapter is also available on Microsoft TechNet.)
Microsoft Windows 2000 Server Resource Kit. Microsoft Press, 2000. Chapter 9.