Inside Windows Server 1002003 [Electronic resources] نسخه متنی

Strategies for OU Design

Figure 8.6 shows the default structure of a Domain naming context. The standard containers in a domain have the advantage of simplicity, but that's about it. Using them is acceptable for small organizations but they fall short of the mark if you want to compartmentalize management or group policies. If you start off using the standard containers, you'll know it's time to tailor a new design when administrators start pointing fingers at each other when directory objects or rights "mysteriously" change or when users from one department complain that they want a different desktop than users in another department.

Both of these problems, lack of management granularity and inability to target specific group policies, can be solved by aggregating Active Directory objects into separate containers then assigning different rights and policies to those containers. The only general-purpose container at your disposal in Active Directory is the

Organizational Unit (OU). The more generalized Container class is available only to the system. The Country, Organization, and Locality classes defined by LDAP are present in the Active Directory schema but are not exposed by the standard tools.

You should consider several factors as you decide where to place OUs:

• OUs represent separate management units because permissions on the OU and its child objects can be delegated.




• OUs represent separate user configuration units because group policies can be linked to them.




• OUs act as a sorting tool when constructing LDAP queries. In essence, they help keep the directory tidy, not a trivial thing when you have thousands upon thousands of objects to manage.

OU Placement

The OU container is intended to facilitate management based on the functional boundaries within an organization. Before putting in a call to HR to get the most current org charts, though, consider who uses the directory.

Users never interact with the Active Directory unless you show them how to perform searches. Even then, most searches deal with the entire forest rather than distinct domains or OUs. The only people who care about the AD structure are administrators. So, when you lay out your OUs, you want to match the operation of your IT staff, not the users. If you build it, they will come.

Management Divisions

Figure 8.7 shows the IT organization for a company with two business lines. The primary business line carries the company's principal name, Company, Inc. The second business line is a wholly owned company named Subsidiary Corp. These two business lines share common offices in a couple of cities. Other than the fact that their employees eat lunch in the same cafeteria and bank at the same credit union, they are completely separate operating entities.

This separation applies to the IT departments, as well, and with a vengeance. Not only do the Company and Subsidiary IT departments have their own staff and budgets, their administrators pride themselves on managing their systems a thousand times better than those dunderheads on the other side of the basement. The company also maintains a small corporate IT group, but those folks are forced to do five-year return-on-investment projections and distribute hefty reports in Lotus Notes instead of centrally managing technology deployments.

Administrative Functions

If you try to design the OU structure based solely on the IT organization chart, you're destined to spend many, many days in long and arduous meetings getting one ephemeral consensus after another, all of which evaporates like a mist in the morning when your plan gets to upper management.

Organizational charts don't reveal functional hierarchies, regional hierarchies, and business-line cross-matrix hierarchies that affect the way the IT department really runs. Even modern, forward-thinking companies dedicated to empowerment and individual ownership have some sort of hierarchical relationship among groups, if only to determine who gets first dibs on the parking spaces.

So, don't design in a closed office. Get out and interview people, even if you've known them for years. Determine how your IT organization divides its management duties, either vertically by business unit or horizontally by region, then put on your detective hat and search out all the administrators and their managers and see how they interact on a day-to-day basis.

While you're sleuthing, don't just look for people with job titles that say

Administrator . Look for hidden lines of responsibility. You'll find power users and department gurus outside of the formal IT structure who have wide-ranging administrative responsibilities. You may find corporate IT staffers matrixed into local organizations with a variety of administrative rights. And you are bound to find a few consultants who have administrative or management duties that are integral to daily operations but not officially recognized by management. In short, find anyone who might need or want administrative privileges in the domain or domains you are designing.

After you outline the true IT administrative hierarchy, find out how the staff members interact with each other. Define their administrative privileges then separate them into groups based on the privileges they exercise and who they administer.

Upper Level OUs

With all the information you collected about the IT administrative structure laid out in front of you, sketch two OU layers:

• An upper layer that defines IT staff administrative boundaries. For example, an oil company like Conoco might define two top-layer OUs, Upstream and Downstream, to separate the business units with autonomous IT staff.




• A second layer that defines objects requiring the same group policies or with specialized management needs. For example, you may outsource your desktop support so you would want to create a separate OUs for computer objects with permissions delegated to the outsource group.

Use the upper OUs layer to delegate administrative permissions. For instance, you might give the local administrators Full Control rights over their own OUs but no rights on any other OUs. This compartmentalizes system administration.

Use the lower layer or layers to distribute group policies (more on this in a moment) and separate out departments that need administrative permissions on their own equipment, groups, or users. Often managers are willing to trust a central IT group for managing equipment but splinter off user and group management to their own department personnel.

It doesn't take a Wharton MBA to figure out that you want to push management responsibility as low in the organization as possible. Design to achieve centralized control of the directory structure with localized control of directory objects. In a nutshell, this means that a few top-level administrators can create or modify OUs at the root of the domain, whereas local administrators can create, modify, delete, and change permissions for objects in those OUs.

Decentralized Operations

Figure 8.8 shows the top-level OUs structure for a domain that encompasses a good chunk of the western United States, Mexico, and a bit of Central America. The company has two business lines; a wholly owned subsidiary shares facilities in two of the company offices and has separate facilities in two remote cities.

The company has several departments with quasi-independent computing staff. The HR department, for example, insists that the confidential nature of the data on their servers and local hard drives (they still don't quite trust the network) makes it imperative that only members of their own administrative staff manage their resources.

The upper container structure for this domain divides along geographic lines because each office has its own IT staff. Departments with independent computing staff get separate containers under their office. This permits local IT personnel to administer the subordinate containers instead of relying on a central IT group. The Salt_Lake OU is an example of the opposite situation. The local IT staff would be perfectly content being in the Phoenix OU, but the Phoenix staff didn't want them to have administrative rights.

The design puts nearly all the OUs at or near the top of the directory. No performance penalty accrues for having a wide directory structure. In fact, the opposite is true. You should avoid going too deep with your OU structure. The indexing and caching features in the Active Directory engine can handle 10 levels with ease. Going deeper is possible but not recommended. If you are having trouble maintaining a shallow container structure, you might want to consult with Microsoft field engineers to determine an optimal configuration for your situation.

Centralized Operations

The OU structure in the previous example would change radically if the company had an omnipotent central IT department with closely bound office staff subject to frequent audits and performance appraisals. In such a case, you could eliminate an entire upper stratum of the directory. Figure 8.9 shows an example.

The container layout for a highly centralized IT organization distributes management rights among autonomous groups in the central IT organization. These containers hold the users, groups, computers, printers, and shared folders controlled by that group regardless of the office where they are located. The directory is replicated everywhere, so a container such as User Support can hold user objects from Phoenix, Houston, and Mexico City. Notice that the administrators in the Subsidiary business unit didn't trust the central IT group and insisted on having a separate namespace joined to the forest with a Tree Root trust.

Lower Level OUs

TheChapter 12, "Managing Group Policies," covers group policies in detail. Here is what we need to know at this point to aid in making design decisions. Group policies are a set of instructions that modern Windows clients (Windows 2000 and XP) download from their logon server and apply to their local Registry and security databases. There are 13 different policy types in Windows Server 2003. The operations supported by these policy engines are as follows:

• sRegistry updates (known as Administrative Templates)




• Security updates




• Logon/Logoff scripts




• Software distribution




• Folder redirection




• Disk quota management




• Wireless network management




• Restricted software selection




• Public key distribution




• IPSec policy management




• Internet Explorer management




• Remote Installation Services management




• Quality of Service (QoS) management

Group Policy Links

Group policies are linked to containers in Active Directory. This is how clients determine which policies affect them. Group policies can be linked to the following containers, listed in order of least precedence to highest:

• Sites




• Domains




• Organizational Units

Policies flow down the Active Directory tree. In other words, users and computers inherit policies linked to their parent OUs and to any superior OUs, then the domain, then their local site.

The list of policies that apply to a particular user or computer is called a

Resultant Set of Policies , or RSoP. Windows Server 2003 includes a new feature that displays the RSoP for a user or computer. Figure 8.10 shows how policies inherit in a tree and what an RSoP display looks like.

Here's a rule of thumb: The closer a group policy object sits in relation to a user or computer in the Active Directory tree, the higher the precedence of the policies in the group policy object. For instance, a "Hide The 'My Computer' Icon" policy linked directly to the OU holding a user object will override a "Don't Hide The 'My Computer' Icon" policy linked to an OU higher in the tree.

As we'll see in Chapter 12, "Managing Group Policies," you can block policy inheritance at a particular OU so that objects below that point don't experience the effects of policies linked to sites, domains, and other OUs higher in the tree. You can also override a policy block so that administrators in subordinate OUs cannot stop their users from getting policies dictated by central IT management.

Group Policy Components

Group policies have two distinct components that work together to deliver the policy instructions to the client for processing.

• Group Policy Container

  (GPC) .
  The GPC is an Active Directory object that defines a policy name, the client-side extension used to process the policy, where the instructions for the policy resides, and what container the policy is linked to. The GPC is located in the cn=Policies,cn=System,dc=<domain_name>,dc=<root> container in the Domain naming context. You can use the AD Users and Computers in Advanced View to see this container. Figure 8.11 shows an example of a policy that contains a software distribution policy, which puts additional information into Active Directory.

  Figure 8.11. AD Users and Computers showing Policies container.

  

  
  



• Group Policy Template (

  GPT ) .
  The GPT is a set of instructions associated with a particular group policy. For example, a Logon policy would have a GPT consisting of a script. An Administrative Template (Registry) policy would have a GPT consisting of an entry in a file called Registry.pol. Clients download these GPT files and process them locally. The GPT files for a particular policy are located in the \Windows\Sysvol\Sysvol\<domain_name>\<policy_name> folder. The Sysvol contents are replicated among domain controllers via the

  File Replication Service , or FRS.

These two group policy components, taken together, are called a

Group Policy Object , or GPO. Microsoft's use of the term GPO was unfortunate because you typically think of objects as being entries in Active Directory, whereas the GPO is an umbrella term for a directory object and a set of template files.

When you create a new group policy, you link it to an OU, domain, or site. The next time computers in that container start up, or users in that container log on, they download the policy. Administrative Template policies are applied in a volatile fashion so they do not tattoo the Registry like NT System Policies.

Group Policy Tools

Group policies are created and configured using the Group Policy Editor (GPE). You open the GPE by opening the Properties window for the container where you want to link the policy then selecting the Group Policy tab. Figure 8.12 shows the default group policies linked to the Domain container.

When you add or change a policy in the GPE, the system immediately creates or updates the associated GPC object and GPT files. There is no "Are you sure you want to do this?" warning.

Group Policies and OU Design

You will find yourself using policies extensively to control users and computers in an Active Directory domain, so it's important to take them into account when you lay out the lower OU levels. For example, the Sales manager might want every desktop in her department nailed down tight so that the salespeople focus on their quotas instead of fooling with their PCs. On the other hand, the field construction superintendent might consider even mild desktop restrictions to be too confining.

Figure 8.13 shows an example OU design based around applying group policies. All designs are different, but here is the basis for the design decisions in the example:

• Users .
  This container holds the accounts for all users in the Phoenix office except for HR and field personnel, who attach to the network via a WAN link to the Phoenix LAN. Putting all users in a single container makes it possible to delegate administrative control of the container as well as define group policies. The subordinate container for Sales accommodates a request for a different group policy. In theory, each department could have its own OU with policies tailored for its specific needs.




• Groups .
  You cannot assign group policies to groups, only users and computers, but this container reflects a certain tidiness on my part. I like keeping group objects in a separate container to make them easy to find. There is no performance penalty for putting groups in different containers from their members.




• Field .
  This container provides a place to put objects for remote locations such as job sites and temporary quarters. The separate container accomplishes two things. First, group policies for field personnel are usually much less restrictive than office policies. Second, field operations often have local technicians who are not full-fledged administrators. The separate container provides a way to assign them limited administrative rights over their users and machines.




• IS and HR .
  These containers provide discrete management units that satisfy the need for autonomy on the part of the staff. The danger, of course, is that the department administrators in the HR container will somehow bollix up their part of the directory and no one from the main IT group will be able to rescue them.




• Printers and Shared_Folders .
  These containers place items that users search for near the top of the container structure. The fewer containers a user has to negotiate to find a shared item in the directory, the more likely they are to use it. If you don't make directory access drop-dead simple, you'll never wean users away from browsing.




• Hardware .
  This container puts Computer objects into two separate containers, one for workstations and one for servers, where they can be managed as distinct units. The desktop administrators or break/fix technicians can be given admin rights over the Workstation container, whereas only network administrators have rights over the Server container. There is no operational advantage to putting Computer objects in the same container as their users. It's much easier to find objects in a container that isn't cluttered with different object classes.

After you draw out the lower-level design, start getting input from your colleagues, administrators in other parts of the organization, and management. Plan on this stage taking a while, even in a small organization. You might want to set up a small lab environment so that you can walk through typical operations.

Simplified OU Structure

If you work in a smaller organization, or you are a consultant with a practice that focuses on small and medium-sized companies, you may find the design in Figure 8.13 to be a bit too much. Figure 8.14 shows a directory for a smaller organization.

When IT staff is limited, local department gurus and power users tend to take on more administrative duties. For this reason, the design in