What are some basic types of Active Directory objects that serve as security principals choose all that apply?

Moving Objects with Active Directory Users and Computers

Active Directory Users and Computers can be used to move user, computer, and group accounts to other locations of the directory. With this tool, objects can be moved within a domain. It can’t, however, be used to move objects to other domains.

Active Directory Users and Computers is the only tool that allows you to move accounts using a GUI. Because it’s a graphical tool, you can move Active Directory objects using your mouse. Select an object by holding down your left mouse button, drag the object to a different container or OU, and release the left mouse button to drop it into the new location.

In addition, you can also move objects within the directory by right-clicking on the object, and selecting Move from the context menu. A dialog box will appear asking you to choose the container or OU the object should be moved to. As seen in Figure 2.44, the

Move dialog box displays a tree that represents the directory tree. By browsing the folders in this tree, you can select the container you want the object moved to, and then click OK to being the move.

When using Active Directory Users and Computers, multiple objects can be selected and moved to other locations. You can select these objects as you would files in Windows Explorer, by dragging your mouse over the objects to be moved.You can also select a series of objects by holding down the Shift key as you click on objects, or select a number of individual objects by holding down the Ctrl key as you click on them. After selecting the objects to be moved, perform the actions we just discussed to move them to another container or OU.

Security Features

Windows 2000 offers a number of new security features that were not previously available in Windows NT. Many of the features we’ll discuss next were implemented in Windows 2000 and have been updated in Windows Server 2003. In addition, new features have been added that make Windows Server 2003 the most secure Windows server product Microsoft has ever marketed.

Windows 2000 Server was the first version to provide encryption of data over the network and in the file system. IPSec allows encryption of data across the network. EFS uses a public key system to encrypt data on hard disks. Encryption ensures that unauthorized parties are unable to view the data if they gain access to it.

Windows 2000 was also the first version to provide built-in support for smart cards. Smart cards are generally the size of a credit card and have the ability to store data. When a smart card is inserted into a smart card device, it provides information that can be used for authentication and other purposes. With smart cards, the security of a network can be greatly enhanced because it is necessary to physically possess the card to log on.

A major advance that first appeared in Windows 2000 was Kerberos authentication. Kerberos version 5 is an industry-standard security protocol that uses mutual authentication to verify the identity of a user or computer, as well as the network service that is being accessed. In Windows 2000 Server and later, Kerberos is the default authentication service.

With Kerberos, each party to a transaction proves that they are who they claim to be through the use of tickets. A Kerberos ticket is encrypted data that is issued for authentication. Tickets are issued by a Key Distribution Center (KDC), which is a service that runs on every domain controller. When a user logs on, the user authenticates to AD using a password or smart card. Because the KDC is part of AD, the user also authenticates to the KDC and is issued a session key called a ticket granting ticket (TGT). The TGT is generally good for as long as the user is logged on and is used to access a ticket-granting service that provides another type of ticket: service tickets. A service ticket is used to authenticate to individual services by providing a ticket when a particular service is needed.

As mentioned earlier in this chapter, AD is a directory service that was first introduced in Windows 2000 Server. Because AD was not available when Windows NT 4 was released, it cannot be installed on a Windows NT server. Once AD is installed on Windows 2000 Server or Windows Server 2003, the server becomes a domain controller that can be used for authentication and management of user accounts and other objects in AD.

When AD is installed, a number of features and tools become available. There are three graphical tools that can be used with Windows 2000 Server or Windows Server 2003:

■

Active Directory Users and Computers This utility allows you to administer user and computer accounts, groups, printers, OUs, contacts, and other objects stored in AD. Using this tool, you can create, delete, modify, move, organize, and set permissions on these objects.

Active Directory Domains and Trusts This utility allows you to manage domains and the trust relationships between them. Using this tool, you can create, modify, and delete trust relationships; create and remove user principal name (UPN) suffixes; raise the domain mode (Windows 2000 Server only); and raise domain and forest functional levels (Windows Server 2003 only).

Active Directory Sites and Services This utility allows you to create and manage sites, and control how the directory is replicated within a site and between sites. Using this tool, you can specify connections between sites and how they are to be used for replication.

EXAM WARNING

Active Directory Users and Computers, Active Directory Domains and Trusts, and Active Directory Sites and Services are tools that are installed with AD. These tools are not available on servers that have not been configured as domain controllers. They are the primary tools for interacting with AD, and they allow you to configure different aspects of the directory.

A new feature in Windows Server 2003 is that AD allows you to select multiple user objects, so that you can change the attributes of more than one object at a time. After selecting two or more user objects in Active Directory Users and Computers, you can bring up the properties and modify some of the attributes that are common to each of these objects. This makes it faster to manage users, because you do not need to make changes to one account at a time.

Windows Server 2003 AD also provides the ability to drag and drop objects into containers. To use this feature, select an object with your mouse, hold down your left mouse button to drag the object to another location (such as an OU), and release the button to drop the object into the container. This ability also makes it easy to add user and group objects to groups. Dragging and dropping a security principle’s object (user, computer, or group) into a group adds it to the group membership.

In addition to these graphical tools, Windows Server 2003 also provides a number of command-line utilities for managing AD. Using these tools, you can perform management tasks through the textual interface of the command prompt. These tools allow administrators to manually enter commands to run operations from a command prompt or use the commands in batch files and scripts that can be scheduled to run at specific times.

Another new Windows Server 2003 feature is that domain controllers can be created from backups. Backups are used to copy data to other media, such as tapes, and can be used to restore lost data if problems arise. For example, if the hard drive on a server fails, you can use the backup to restore the data to a new drive and have the server up and running again. This same process can be used to restore AD to a new domain controller, so you do not need to replicate the entire directory across the network. Allowing domain controllers to be added to an existing domain through the use of backups is of great benefit when you are setting up a new domain controller across a slow WAN link from the nearest existing domain controller.

Using Active Directory Administrative Tools

☑

Active Directory Users and Computers allows you to administer user and computer accounts, groups, printers, organizational units (OUs), contacts, and other objects stored in Active Directory. Using this tool, you can create, delete, modify, move, organize, and set permissions on these objects.

Active Directory Domains and Trusts is used to manage domains and the trust relationships between them. Using this tool, you can create, modify, and delete trust relationships between domains, set the suffix UPNs, and raise domain and forest functional levels.

The Active Directory Sites and Services tool is used to create and manage sites, and control how the directory is replicated within a site and between sites. Using this tool, you can specify connections between sites, and how they are to be used for replication

Directory Information Search

With Active Directory, users have the ability to search for objects such as other users or printers. To help a user who is searching the database for an object, the GC answers requests for the entire forest. Because the complete copy of every object available is listed in the GC, searches can be completed quickly and with little use of network bandwidth.

When you search the entire directory, the request is directed to the default GC port 3268. The GC server is also known to other computers on the network because of SRV records in the DNS. That is how a node on the network can query for a GC server. There are SRV records specifically for GC services. These records are created when you create the domain.

When users search for information in Active Directory, their queries can cross WAN links, depending on the network layout. Each organization is different. Figure 2.2 shows an example layout with GC servers in the corporate office in Chicago and a branch office in Seattle. The other two sites do not have GC servers. When queries are initiated at the Chicago branch office, the queries use the corporate office GC server. With a high-speed fiber connection, bandwidth isn't an issue.

The branch office in New York has a slow link but less than 10 users. These users will use the GC in Chicago as well. Even though the pipe between these locations is only 56 K, the minimal number of users doesn't warrant having a GC server in New York. The Seattle office has a T1, which is decent connectivity, but there are more than 100 users in this location. Considering that, searches will be more efficient with a GC server locally. We will look at sites later in the chapter, but Figure 2.2 will help you get a basic understanding of how the query process works.

Managing Exchange 2000/2003 and 2007 Mailbox-Enabled User Objects in a Coexistence Environment

Which tool (the ADUC snap-in or EMC) should you use to manage mailbox-enabled user objects within a coexistence environment? The choice is actually pretty straightforward; just follow the set of guidelines laid out in Table 3.1.

Table 3.1. Tools to Manage Exchange 2000/2003 and 2007 Mailboxes in a Coexistence Environment

Warning

Although you have the option of managing Exchange 2007 Mailbox and Mail-enabled users using the ADUC snap-in, it isn’t supported and will result in Exchange 2007 mailboxes that might not be fully functional. In addition, you should opt to use the Exchange 2007 tools to move Exchange 2000/2003 user mailboxes.

Creating and managing Organizational Units

OUs are created within the ADUC console. To create a new OU, perform the following tasks:

Log on to a DC and Open Server Manager.

Expand the nodes Roles | Active Directory Domain Services | Active Directory Users and Computers.

Right-click on the domain name (e.g., contoso.com) and select the option New → Organizational Unit. The New Object—Organizational Unit window will appear.

Give the OU a meaningful name and ensure that the option to Protect container from accidental deletion is selected (see Figure 4.36). This option prevents you from accidentally deleting OUs which may contain hundreds or thousands of users, computers, and groups. As a best practice, always choose to protect the OU when creating it.

Click OK to create the OU.

The OU should now be displayed under the domain in ADUC. If you attempt to delete the OU, you will receive an error message, as seen in Figure 4.37, informing you that the OU is protected. To delete the OU, you will need to open the OU properties by right-clicking on it and then disabling the protection option selected during creation.

Additionally, you can delegate the administrative functions of an OU to other users such as administrators who may be responsible for a specific business unit. Perform the following tasks to delegate permissions to an OU:

Log on to a DC and open Server Manager.

Expand the nodes Roles | Active Directory Domain Services | Active Directory Users and Computers | <your domain name>.

Right-click the OU that you want to delegate permissions to and choose the option Delegate Control. This will launch the Delegation of Control Wizard. Click Next to continue.

Add the administrator(s) whom you want to delegate permissions to (see Figure 4.38); Then click Next.

Select the permissions that you want to give the administrator over the OU (see Figure 4.39); then click Next.

Verify the delegation summary and click Finish to delegate permissions.

In the aforementioned example, the financeadmin1 account should have the ability to manage users and groups within the Finance OU. The financeadmin1 will not have rights to manage users and groups in other OUs within the domain.

Active Directory and DNS Requirements

Windows Server 2003 uses an AD user account as a service account to run the cluster service. All cluster nodes must use the same service account, and all cluster nodes must be members of the same AD domain. In Windows Server 2003, the public IP addresses of the cluster nodes must be within a nonrouted IP subnet. In this way, the cluster nodes will belong to the same AD site. Using separate service accounts for each cluster is considered a best practice; otherwise, a disabled user account would affect all clusters at once.

The cluster service account must be a domain user account that is a member of the local Administrators group on all cluster nodes. The user should not be a member of the Domain Admins group for security reasons. The cluster service account does not need any Exchange organization permission. See the Exchange Server 2007 section titled, “Permission Frequently Asked Question,” on Microsoft TechNet for additional details.

In Windows Server 2008, the cluster does not use an AD user account as a service account; the cluster service runs under the Local System account of the cluster nodes. Another change is that clusters running Windows Server 2008, by default, use Kerberos authentication and not NT LAN manager (NTLM) authentication, which was the case in Windows Server 2003. These are two examples of the increased security in Windows Server 2008. The security model used by Windows Server 2008 clusters is described in Microsoft Knowledge Base Article 947049.

All nodes of an Exchange Server 2007 cluster must be members of the same AD domain, and the same AD site. This is the case, regardless of whether Exchange is installed on Windows Server 2003 or Windows Server 2008. Exchange Server 2007 requires that all cluster nodes are members of the same AD site. CCR only talks to servers holding the HT role if they are located in the same AD site. After a lossy failover, CCR would not be able to take advantage of messages stored in the transport dumpster of HT servers in AD site A if the cluster Node B would be a member of AD site B. This is the reason why Exchange requires that all nodes of the cluster are within the same AD site, although Windows Server 2008 would support nodes of a cluster that are assigned to different AD sites.

The ideal configuration is an AD integrated DNS zone, allowing secure dynamic updates for DNS records. Otherwise you have to create a DNS A record for each cluster node and the CMS.

Using the RSoP Wizard

You can use the RSoP Wizard to create an RSoP query on your Windows Server 2003 server. You begin by adding the RSoP snap-in to an empty MMC console. You can also access RSoP through the Active Directory Users and Computers console and the Active Directory Sites and Services console.

To access RSoP planning through the Active Directory Users and Computers MMC and start the RSoP Wizard, do the following:

Select Start | Programs | Administrative Tools | Active Directory Users and Computers.

Right-click the name of the domain or OU and select All Tasks.

Choose Resultant Set of Policy (Planning).

To access RSoP planning through the Active Directory Sites and Services MMC and start the RSoP Wizard, do the following:

Click Start | Programs | Administrative Tools | Active Directory Sites and Services.

Expand the Sites node in the left pane.

Right-click the name of a site and select All Tasks.

Select Resultant Set of Policy (Planning).

To start the RSoP Wizard from a stand-alone RSoP MMC, right-click Resultant Set of Policy in the left pane and select Generate RSoP Data (or select it from the Action menu). The Wizard will display the query results in the RSoP snap-in. You can save, change, or refresh your RSoP queries. You can create more than one query by adding the RSoP snap-in to your console. The information that RSoP gathers comes from the CIMOM database through Windows Management Instrumentation (WMI).

NOTE

The RSoP Wizard differs depending on which method you use to open RSoP. When you open the RSoP Wizard through the Active Directory Users and Computers or Active Directory Sites and Services console (under Administrative Tools), you can use only planning mode. When you open the Wizard from the RSoP MMC, the first selection you make is whether to use logging or planning mode.