Chapter 12
Active Directory, Part II
In This Chapter
Actively managing the Active Directory
Understanding the difference between Active Directory planning and practical uses of Active Directory
Optimizing organizational units in Active Directory
Configuring and delegating OU permissions in Active Directory
Adding and moving common Active Directory objects including users, groups, and computers
Understanding Active Directory site and domain management
B
elieve it or not, you’ve already been working with Active Directory! If you’ve followed many of my examples and steps since the beginning of the book, you’ve installed a domain controller, and thus you have installed Active Directory (see Chapter 2). If you’ve added users, as discussed in Chapter 9, then you have used Active Directory to accomplish a task. I share this with you so that you can minimize if not eliminate any Active Directory anxiety you’ve built up.This chapter is the “yang” to the “yin” of the last chapter. Whereas the last chapter was planning-centric, this chapter focuses on the practical and pragmatic aspects of Active Directory. It’s hands-on, so let’s get going.
Optimizing Organizational Units
I’ve come to believe the organizational units (OUs) are where the MCSEs and MBAs can find common ground. I talked about this coming together of business and technical perspectives in the last chapter. In this chapter, we make it happen. Ideally, your Active Directory will be, first and foremost, pragmatic. I believe that the OUs can be designed with the underlying organization in mind, be it corporations, not-for-profit organizations, or government agencies. That is, OUs can be created for different functional areas of responsibility, such as marketing, manufacturing, and legal. Another possibility that works for many firms is to create OUs by geographic location: corporate headquarters, branch offices, project sites, and even vendor sites.
Of course, if you feel the world should be run by MCSEs, you might build a complex Active Directory based on subnets, hardware locations, and other technology-based dimensions. The choice is yours. You can create an Active Directory with a focus on business functions, technology resources, or a combination of the two.
Remember that OUs may contain users, groups, and computer accounts. OUs are typically used to delegate administrative control.
OUs are best deployed if they define administrative boundaries in your domain.
To create an OU, follow these steps.
STEPS:
Creating an OU
Step 1. Select Administrative Tools, Active Directory Users and Computers on the Start menu. The Active Directory Users and Computers MMC will appear.
Step 2. Right-click the domain icon in the left pane. The secondary menu will be displayed.
Step 3. Select New, Organizational Unit from the secondary menu.
Step 4. The Create New Object - (Organizational Unit) dialog box will appear (see Figure 12-1). Name the OU.
Step 5. Click OK. The OU will appear in the left pane of the Active Directory Users and Computers MMC (see Figure 12-2).
Figure 12-2: OU displayed in Active Directory Users and Computers MMC
You may recall a secret near the end of Chapter 11 where I suggested you consider creating just one OU and putting everything in it, at least to start with. You would then critically evaluate the need for additional OUs on a case-by-case basis. But be advised that while this advice is valid, it clearly applies to small and medium-sized organizations, not full-scale enterprises. You want to be master of your own destiny with your Active Directory and create at least one OU right away. That’s because the built-in default containers shown in Active Directory Users and Computers are not very useful or practical. First, these containers are not true OUs. Second, you cannot create OUs within these default containers. Finally, you can’t apply group policy to these default containers. Take my advice and create your own OU or OUs as soon as possible.
An OU inside an OU
There are very important reasons to consider creating an OU within an OU. For example, this might make the best sense if you work in a decentralized or matrix organization. Another reason to have OUs within OUs would be a project management organization, where the embedded OU might be named after a project of limited scope and duration. To create an OU within an OU, follow these steps.
STEPS:
Creating an OU within an OU
Step 1. Select the OU in the left pane of the Active Directory Users and Computers MMC.
Step 2. Right-click the OU that you selected. The secondary menu will appear.
Step 3. Select New ➪ Organizational Unit from the secondary menu.
Step 4. The Create New Object - (Organizational Unit) dialog box will appear. Enter the name of the OU in the Name field.
Step 5. Click OK and observe that the new, embedded OU appears indented under the original OU (see Figure 12-3).
Figure 12-3: OU within an OU
OU permissions
In order to create an OU within an OU (as you did when creating Northwest inside of Marketing in the previous example), you must have the following permissions in the parent container (for example, Marketing):
■ Create Organizational Unit Objects
■ List Contents
■ Read
The List Contents right isn’t truly necessary when creating an OU within an OU. However, if you don’t provide the List Contents correctly, you would not be able to see the embedded OU you just created. Not only is out of sight the same as out of mind, it’s also out of management (can’t be managed). To assign and modify Active Directory permissions, follow these steps.
STEPS:
Managing Active Director y permissions
Step 1. In the Active Directory Users and Computers MMC, select View ➪ Advanced Features.
Step 2. Right click an object (for example, the Marketing OU). Select Properties from the secondary menu.
Step 3. Select the Security tab on the OU’s Properties sheet.
Step 4. You may now grant or deny the Full Control, Read, Write, Create All Child Objects, and Delete All Child Objects permissions.
Step 5. If you select the Advanced button, the Access Control Settings appear. You may set advanced permissions such as Special. The Access Control Settings dialog box displays permissions entries in the column-and-row format that many of us have been searching for. Many times, I have wanted to know who has access to what, and wanted the information presented in a columnar report-type format. The Access Control Settings dialog box does exactly that.
Step 6. Click OK to return to the Active Directory Users and Computers MMC. You have now modified the permissions for an Active Directory object.
On the Security tab of an OU’s properties sheet, you may select the Allow inheritable permissions from the parent to propagate to this object
checkbox. Simply stated, this allows this OU to inherit rights from its parent. Likewise, on the Access Control Settings dialog box, selected via the
Advanced button from the Security tab of an OU’s properties sheet, you can have the existing OU’s permissions propagate to any existing or future children. This is the last-will-and-testament option. To invoke this option, select the Allow inheritable permissions from the parent to propagate to this object checkbox.
And in all cases, there is no usurious inheritance tax.
Delegating control
Another cool Active Directory feature, viewed from the OU perspective, is that it allows you to delegate control of an OU to someone else. This is how you can create mini-administrator, a highly desirable new feature in Windows 2000 Server. The basic reason for delegating control is to make your life easier by having someone help you manage an OU. It is also easier to track permissions at the OU level. Follow these steps to delegate control.
STEPS:
Delegating control
Step 1. Select an OU, right click and select Delegate Control from the secondary menu. The Delegation of Control Wizard will appear (see Figure 12-4).
Figure 12-4: Delegation of Control Wizard
Step 2. Click Next. The Users or Groups screen appears (see Figure 12-5). Select the group or user that you want to delegate control to via the Add button. Click Next.
Figure 12-5: Users or Groups Selection screen
Step 3. Select the Tasks to Delegate from the list of common tasks or create a custom task to delegate (see Figure 12-6). Click Next.
Step 4. Click Finish at the Completing the Delegation of Control Wizard screen. You have now delegated the OU control you elected to delegate to a user or group.
Another approach to delegating control is to create your own Microsoft Management Console (MMC) and then assign permissions that permit a delegate to use the custom MMC. For example, create an MMC with three or four of your favorite snap-ins. In Figure 12-7, I’ve created an MMC with the Computer Management, Event Viewer, Resource Kits, and Performance Logs and Alerts snap-ins.
Figure 12-7: Custom MMC
Next, select options from the Console menu. The Options dialog box will appear. Select the Console tab and select User mode - full access (see Figure 12-8). Click OK. You have now delegated control to this MMC. Be sure to save your MMC when you exit.
Figure 12-8: Console mode
You may now distribute this MMC to other users. By setting the MMC console to User mode, the other users may not modify this custom MMC, but rather they may use it to complete system management tasks. You may have noticed that the Console mode field had several selections:
■ Author mode: Allows access to all MMC functionality including adding,
creating, and modifying the MMC. You may also navigate the entire MMC tree.
■ User mode - full access: Users have access to all MMC management
functionality and the MMC tree. However, users cannot add or remove snap-ins or change console file options. The Save commands
are disabled.
■ User mode - limited access, multiple window: This is a more restrictive
setting. Users cannot modify the MMC, open new Windows, or see areas of the console tree that weren’t visible when the MMC was last saved. Multiple windows are allowed.
■ User mode: limited access, single window: Same as the multiple window
option except that only a single window is displayed.
Advanced features
A little known secondary menu option, displayed when you right-click the domain object, is View ➪ Advanced Features. When selected, Advanced Features displays several more Active Directory components in the MMC, as seen in Figure 12-9.
Figure 12-9: Advanced Features
For example, one of the objects displayed is LostAndFound. This object is the default container for orphaned objects. Orphaned objects are created when the relationship that ties these objects to other objects is somehow lost or broken. And to be brutally honest, orphaned objects can be created with no mistake on your part. Sometimes computers just hiccup or act in inexplicable ways.
Creating Users, Groups, and Computers
This section is actually a review for those of you who diligently read Chapter 9. Because of that, I’ll quickly review how you add users, groups, and
computers.
The first steps are the same. To create a user, group, or computer, simply right-click the domain or OU in the left pane of the Active Directory Users and Computers MMC. From the secondary menu, select New. You would then select User, Group, or Computer depending on the task you want to
complete.
If you select User, the Create New Object - (User) Wizard will be displayed (see Figure 12-10). Complete each screen to create the user.
Figure 12-10: Creating a user
If you select Group, the Create New Object - (Group) Wizard appears (see Figure 12-11). Complete each field and click OK to create the group.
If you select Computer, the Create New Object - (Computer) Wizard will be displayed (see Figure 12-12). Name the computer and click OK to create the computer.
It is very important to select the Allow pre-Windows 2000 computers to use this account checkbox if you are creating a computer account for a Windows NT 4.0 Workstation machine (as an example).
Figure 12-12: Creating a computer account
You can also create custom objects such as figures. I’ve seen this done in Active Directory where an organization wanted to have a picture of a floor plan showing where each user was located. Good idea when conceived on the whiteboard during planning. Bad idea when fully implemented. Why? Because creating objects such as artwork and figures causes the Active Directory database to grow exponentially in size, resulting in poor performance.
Moving Objects
If you’ve followed the examples in both Chapter 9 and this chapter, you will notice that the user, group, and computer exist as objects just below the domain in the Active Directory. It would be better to move these to an OU. Be advised about the basic guidelines concerning moving objects such as users, groups, and computers. Object permissions move with the object, but inherited permissions do not move.
Follow these steps to move a user, group, and computer to the Marketing OU (again, assuming you’ve created that).
STEPS:
Moving a user, group and computer
Step 1. Select the object you want to move. Right-click the object to display the secondary menu. In this example, I’ve selected Raymond MacMillan, a user.
Step 2. Select Move. The Move dialog box appears.
Step 3. Select the container that you want to move the object to. In this example, I’ve selected Marketing (see Figure 12-13).
Figure 12-13: Move dialog box Step 4. Click OK.
Step 5. The object, Raymond MacMillan, has moved to the Marketing OU (see Figure 12-14). Repeat steps 1 to 4 to move a computer or group.
Figure 12-14: Moving an object
Active Directory Sites and Services
The Active Directory Sites and Services MMC, launched from the Administrative Tools group, is used to manage the replication of critical Active Directory information, including network services, domain controller, and site information. A site is really just a collection of subnets.
One rule of thumb has been that sites are LANs and separate sites represent a WAN.
The replication process is managed via the Active Directory Sites and Services MMC (see Figure 12-15). A few facts about replication might be of interest to you. First, configuring replication often means you must choose between accurate data and high performance. If replications are performed frequently, the data contained at each domain controller will be as accurate as possible. That is a good thing. But this data accuracy comes at a price. This frequent replication pattern consumes network bandwidth. The trade-off is this: accurate data versus network traffic issues.
When discussing one site, the originating domain controller with a delta change to its Active Directory database is responsible for notifying the replication partners about such changes. This occurs via a communication known as change notification. The replication partner, typically within five
minutes of receiving this message, pulls down the delta Active Directory changes. When discussing multiple sites, replication is scheduled manually. Once exception to this change notification process is that security-sensitive updates, defined as security-related attributes, are pulled down by the replication partner immediately.
Replication pathways within a single site are created via the Knowledge Consistency Checker (KCC). KCC creates pathways that are feasible within three hops. New domain controllers, when added to the network, are automatically added to the replication pathway by KCC.
Figure 12-15: Active Directory Sites and Services MMC
All replication traffic, whether within one site or across multiple sites, use Remote Procedure Calls (RPC) as the underlying transport mechanism. With multiple site communications, Simple Mail Transport Protocol (SMTP) may also be used. The RPC communication process is shown in Figure 12-16.
Figure 12-16: The RPC communication process
Windows 2000 Server Domain Controller A Windows 2000 Server Domain Controller B Remote Procedures Remote Procedures Remote Procedures Server Stub Server Stub Server RPC Runtime Library Server RPC Runtime Library
Network T Network Transport Network Transport
Because you are using RPCs in your site replication, you will need to use the RPING utility from Microsoft Exchange to assist in troubleshooting replication problems. RPING is discussed in Chapter 20.
Active Directory Domains and Trusts
The Active Directory Domains and Trusts MMC (see Figure 12-17) is launched from the Administrative Tools program groups. Its main function is to manage domain trusts and user principal name suffixes and change the domain mode. Domains are administrative units typically created to assist you in organizing and managing your network resources. Trusts create secure pathways between domains.
Specifically, you may use Active Directory Domains and Trusts to
■ Support mixed mode domain operations in mixed Windows 2000 and Windows NT domain environments
■ Configure operations to run in strict Windows 2000 native mode
■ Add/remove domain names
■ Change the domain controller that holds the domain naming operations master role
■ Create and modify domain trusts
■ Gather and observe information about domain management
Summary
This chapter brought a discussed the practical aspects of Active Directory.
Implementing Active Directory in your organization
Creating and moving objects in Active Directory
Understanding which Active Directory MMC to use under what circumstances
Delegating OU permissions in Active Directory
