Windows creates two built-in user accounts automatically: administrator and user.

Understanding Forests

An Active Directory always begins with a forest root domain, which is automatically the first domain you install. This root domain becomes the foundation for additional directory components. As the cornerstone of your enterprise-computing environment, you should protect it well. Fault tolerance and good backups are not optional—they are essential. If an administrative error or hardware failure results in the unrecoverable loss of this root structure, the entire forest becomes inoperable. Certain forest objects and services are present only at the root (e.g., the Enterprise Administrators and Schema Administrators groups, and the Schema Master and Domain Naming Master FSMO roles which we will discuss later in this chapter).

Working with the Active Directory Schema

7.

You are working with the Schema Admin snap-in and cannot make any changes. You created a network administrator equivalent account in the forest root domain but cannot modify the schema. Why?

You must be a member of the Enterprise Admin group to modify the schema.

You must be a member of the Schema Admin group to modify the schema.

You must be a Domain Admins member in each domain in the forest to modify the schema.

Only the initial Administrator account during forest creation can modify the schema.

You are a network administrator and you want to modify an attribute that is associated with one of your user accounts. How do you do this?

Open Active Directory Users and Computers and change to advanced view. This will allow you to modify the properties of the attributes in the user account for which you need to make the change.

Open Active Directory Sites and Services. Open the Properties for the site containing the attribute and make the modifications.

Open the Schema Snap-in, expand Objects, and select the User object to modify the associated attributes.

Open the Schema Snap-in, expand Attributes, and find the attribute you want to modify.

You are explaining the various attributes to a fellow network administrator. You are showing her the properties of a User account, and your new network administrator asks what the Other button means with regard to various attributes. What do you tell her?

Those attributes are multivalued attributes.

Those attributes are single-value attributes.

Those attributes are actually Object classes.

Those attributes are Index attributes.

As a network administrator, you are responsible for making sure that various attributes are indexed for optimal performances for queries. What steps do you take to make an attribute indexed?

Using the Schema snap-in, right-click the attribute you want to index and select Properties. Select Index this attribute in the Active Directory.

Using the Schema snap-in, right-click the attribute you want to index and select Properties. Select Replicate this attribute to the GC.

Using the Schema snap-in, right-click the attribute you want to index and select Properties. Select Allow this attribute to be shown in advanced view.

Using the Schema snap-in, right-click the attribute you want to index and select Properties. Select Attribute is Active.

You are working with Schema objects and you need one component that has to be supplied by a third-party. Which component is supplied by a third party so standards can be followed?

LDAP name

Common name

OID

Object GUID

You make a mistake while setting up new classes in your schema. You want to correct the mistake so you can have the appropriate name and configuration for the class. How do you do this?

You must deactivate the class that was added with the mistake and then rename it. You then can create a new class with the appropriate name and configuration.

You must delete the class that has the mistake and simply create the appropriate Class object.

You must wait 24 hours before you can delete any new classes in the schema. You can then delete the class and create the corrected Class object.

You can go in and fix the existing Class object without having to recreate the object.

You have an office with three locations separated by 56 K WAN links. You are experiencing slow queries when looking for objects in the Active Directory. You have one GC server at your main office. What can you do to improve the query performance?

Add GC servers to your other two locations.

Add DCs that are not GC servers to your other two locations.

Add a DNS server for faster resolution at your other two locations.

Add another OU to the directory to separate the locations by OU.

You have been experiencing a large amount of processor utilization on your GC server. Your network consists of one location with 2500 users. You currently have three DCs for fault tolerance and load balancing. What can you do to help with your GC server processor utilization?

Add a fourth DC to the network.

Add another GC server to the network to offload some of the traffic.

Remove one DC from the network.

Split your network into three OUs with less than 1000 users each.

You are working on updating the schema and cannot associate an attribute with a class. What can you do to resolve this?

Add yourself to the schema Admins group.

Makes sure the Schema Operations Master is online and reachable.

Reload the schema in the Schema admin tool.

Move the role of Schema Operations Master.

Domain Rename Utility

Domains can also be renamed. Using the domain rename utility (rendom.exe), you can change the NetBIOS and DNS names of a domain, including any child, parent, domain-tree, or forest root domains (from which all others branch off in the hierarchy). By renaming domains in this manner, you can thereby move them in the hierarchy. For example, you can change the name of dev.web.syngress.com to dev.syngress.com, making the web.syngress.com and dev.syngress.com domains on the same level of the hierarchy. You could even rename the domain so that it becomes part of a completely different domain tree. The only domain that you can’t reposition in this manner is the forest root domain.

Default Groups in Builtin Container

Up to 14 different built-in groups that might be located by default in the Builtin container, including:

Account Operators, which allows members to manage accounts

Administrators, which gives members full control

Backup Operators, which allows members to back up and restore files

Guests, which gives members minimal access

Incoming Forest Trust Builders, which is only available in forest root domains, and gives members permission to Create Inbound Forest Trusts

Network Configuration Operators, which allows members to manage network settings

Performance Monitor Users, which allows users to manage performance counters and use System Monitor

Performance Log Users, which allows users to manage performance counters and use Performance Logs and Alerts

Pre-Windows 2000 Compatible Access, which is used for backward compatibility.

Print Operators, which allows members to manage printers

Remote Desktop Users, which allows members to connect to servers using Remote Desktop

Replicator, which is used for replication purposes

Server Operators, which allows members to manage servers

Users, which contains every user account created in the domain

The Account Operators group is used to allow members to perform group management. Users who are part of its membership have the ability to create, modify, and delete many of the accounts that are stored in Active Directory They can manage accounts in any OU except the Domain Controllers OU, or those located in the Users or Computers containers. To prevent members of this group from affecting administrator accounts, members of the Account Operators group cannot modify the Administrators and Domain Admins groups, or any accounts that are members of these groups.

Members of the Account Operators group also have certain abilities when dealing with DCs in the domain in which this group is located. They can log on locally to a DC, which means that they can physically sit at a DC and log on to it. In doing so, they could then make modifications to the DC. They also have the ability to shut down the DC, which is useful if there is a problem with the DC and no one else is available to restart the system.

The Administrators group is the most powerful of the groups in the Builtin container, and has full control over the domain. This account can access DCs over the network, back up files and directories, change system time, adjust memory quotes, create page files, load and unload device drivers, delegate responsibility to users and computers, shut down the system, and perform other tasks relating to accounts and DCs. By default, Domain Admins and Enterprise Admins groups and the Administrator account are members of the Administrators group.

The Backup Operators group is used to give members the ability to back up and restore files on DCs. It doesn’t matter what the member’s permissions on different files are, as they can back up and restore any file on the system. In addition, they have the ability to log on locally to DCs and shut down the system. Due to the level of abilities attributed to members of this group, by default there are no members when it is first created.

The Guests group is the least powerful group in the Builtin container, and has a membership that consists of accounts and groups for people who require minimal access, or haven’t logged on using their own accounts. The Guest account and Domains Guests group are members of this group. As you’ll recall, the Guest account is disabled by default, meaning that when this group is initially created it has no active users.

Because of its purpose, the Incoming Forest Trust Builders group is only available in forest root domains. Members of this group have the permission to Create Inbound Forest Trust. This permission gives them the ability to create one-way, incoming forest trusts, which can only be made between the root domains of two forests. A one-way trust means that users from one forest can access resources in another forest, but not vice versa. Because of the ability to create trusts between two domains, there are no default members in this group when it is initially created.

As its name states, the Network Configuration Operators group is used to manage changes to the network settings. The members in this group have the ability to renew and release IP addresses on servers in the domain, and modify TCP/IP settings. Because this can possibly make the server inaccessible if done incorrectly, this group has no default members, and new members should be added with caution.

Members of the Performance Monitor Users and Performance Log Users groups are used for managing performance counters on servers within the domain. Performance counters are used to monitor and measure elements of the DC, such as memory, hard disk, processor, network activity, and so on. These utilities are used by two related utilities in Windows 2000 and Windows Server 2003: System Monitor, and Performance Logs and Alerts. Both of these utilities can be accessed through the Performance console that is available under Administrative Tools in the Windows Start menu.

Members of the Performance Monitor Users group can use System Monitor to monitor performance counters. They can view counters locally or remotely, viewing them in a graphical or textual format. By doing so, they can determine if performance issues exist on servers within a domain.

Members of the Performance Log Users group also have the ability to manage performance counters, but can use the Performance Logs and Alerts utility to create and view logs, and configure alerts that will notify specific users (such as administrators) if a problem exists. For example, if the amount of free hard disk space drops below a certain level, a message can be sent to a network administrator advising of the potential problem. Members of this group can also configure certain programs to run if the values of performance counters exceed or fall below a specific setting.

The Pre-Windows 2000 Compatible Access group is used for backward compatibility for older versions of Windows. Members of this group have Read access for viewing all users and groups within the domain. Depending on the security settings chosen during the installation of Active Directory, the Everyone group might be a member of this group; however, additional members can be added that are running Windows NT 4.0 or earlier if needed.

The Print Operators group allows members to perform tasks that are necessary in the administration of printers. Users who are members of this group can manage printer objects in Active Directory, and create, share, manage, and delete printers that are connected to DCs within the domain. Because adding new printers to a server might require performing certain actions like rebooting the computer, this group also has the ability to load and unload device drivers, and shut down the system. As with other groups discussed in this section, the Printer Operators group has no members added to it when initially created.

The Remote Desktop Users group allows members to connect remotely to servers in the domain. Being able to remotely log on to the DC allows them to perform actions as if they were physically sitting at the server and working on it. Because of the power this group gives members, it has no default members.

The Replicator group is one that should never have users added to it. This group is used by the File Replication Service (FRS) and provides support for replicating data; therefore, it isn’t meant to have users as members.

The Server Operators group provides a great deal of power to its membership, which is why there are no default members when it is initially created. Members of this group can perform a number of administrative tasks on servers within the domain, including creating and deleting shared resources, backing up and restoring files, starting and stopping services, shutting down the system, and even formatting hard drives. Because members have the potential to cause significant damage to a DC, users should be added with caution to this group.

The Users group includes every user account that’s created in the domain as part of its membership. By default, the Domain Users, Authenticated Users, and Interactive groups are members of this group. By being part of this group, members are able to run applications, access local and network printers, and perform other common tasks that are necessary for normal job functions.

Introduction

The domain serves as the administrative boundary of Active Directory. It is the most basic component that can functionally host the directory. Simply put, Active Directory uses the domain as a container of computers, users, groups, and other object containers. Objects within the domain share a common directory database partition, replication boundaries and characteristics, security policies, and security relationships with other domains.

Typically, administrative rights granted in one domain are valid only within that domain. This also applies to Group Policy Objects (GPOs), but not necessarily to trust relationships. Security policies such as the password policy, account lockout policy, and Kerberos ticket policy are defined on a per-domain basis. The domain is also the primary boundary defining your DNS and NetBIOS namespaces. The DNS infrastructure is a requirement for an Active Directory domain, and should be defined before you create the domain.

There are several good reasons for a multiple-domain model, although a significant number of Active Directory implementations rely on a single-domain forest model. In the early days of Windows 2000, the most common recommendation was for a so-called empty forest root model, in which the forest root domain contains only built-in objects, and all manually created objects reside in one or more child domains. Whatever the design decision reached by your organization, it is a good practice to avoid installing additional domains unless you have a specific reason for them, as each additional domain in a forest incurs additional administrative overhead in the form of managing additional domain controllers (DCs) and replication traffic. Some of the more common reasons to create additional domains include:

Groups of users with different security policy requirements, such as strong authentication and strict access controls.

Groups of users requiring additional autonomy, or administrative separation for security reasons.

A requirement for decentralized administration due to political, budgetary, time zone, or policy pressures.

A requirement for unique namespaces.

Controlling excessive directory replication traffic by breaking the domain into smaller, more manageable pieces. This often occurs in an extremely large domain, or due to a combination of geographical separation and unreliable WAN links.

Maintaining a preexisting NT domain structure.

You can think of a domain tree as a DNS namespace composed of one or more domains. If you plan to create a forest with discontiguous namespaces, you must create more than one tree. The primary Active Directory partitions, also called naming contexts, are replicated among all DCs within a domain. These three partitions are the schema partition, the configuration partition, and the domain partition.

The schema partition contains the classSchema and the attributeSchema objects that make up the directory schema. These classes and attributes define all possible types of objects and object properties within the forest. Every DC in the entire forest has a replica of the schema partition.

The configuration partition, replicated identically on all DCs throughout the forest, contains Active Directory's replication topology and other configuration data.

The domain partition contains the local domain objects, such as computers, users, and groups, which all share the same security policies and security relationships with other domains. If multiple DCs exist within a domain, they contain a replica of the same domain partition. If multiple domains exist within a forest, each domain contains a unique domain partition.

Because each domain contains unique principles and resources, there must be some way for other domains to locate them. Active Directory contains objects that adhere to a naming convention called the DN, or distinguished name. The DN contains enough detail to locate a replica of the partition that holds the object in question. Unfortunately, most users and applications do not know the DN, or what partition might contain it. To fulfill that role, Active Directory uses the Global Catalog (GC), which can locate DNs based on one or more specific attributes of the needed object. (We will discuss the GC later in this chapter.)

What is Exam 70-294?

Exam 70-294 is one of the four core requirements for the Microsoft Certified Systems Engineer (MCSE) certification. Microsoft’s stated target audience consists of IT professionals with at least one year of work experience on a medium or large company network. This means a multi-site network with at least three domain controllers, running typical network services such as file and print services, database, firewall services, proxy services, remote access services and Internet connectivity.

However, not everyone who takes Exam 70-294 will have this ideal background. Many people will take this exam after classroom instruction or self-study as an entry into the networking field. Many of those who do have job experience in IT will not have had the opportunity to work with all of the technologies covered by the exam. In this book, our goal is to provide background information that will help you to understand the concepts and procedures described even if you don’t have the requisite experience, while keeping our focus on the exam objectives.

Exam 70-294 covers the basics of managing and maintaining the Active Directory infrastructure in a network environment that is built around Microsoft’s Windows Server 2003. Objectives are task-oriented, and include the following:

Planning a strategy for placing global catalog servers, including evaluating network traffic considerations and evaluating the need to enable universal group caching.

Planning the placement of flexible operations master roles, including how to plan for business continuity of operations master roles and identifying operations master role dependencies.

Implementing an Active Directory directory service forest and domain structure, including creating the forest root domain, creating a child domain, creating and configuring Application Data Partitions, and installing and configuring an Active Directory domain controller. This objective also includes setting an Active Directory forest and domain functional level based on requirements, and establishing trust relationships such as external trusts, shortcut trusts and cross-forest trusts.

Implementing an Active Directory site topology, including configuring site links and configuring preferred bridgehead servers.

Planning an administrative delegation strategy, including planning an organizational unit (OU) structure based on delegation requirements and planning a security group hierarchy based on delegation requirements.

Managing an Active Directory forest and domain structure, including managing trust relationships, managing schema modifications, and adding or removing UPN suffixes.

Managing an Active Directory site, including configuring replication schemes, configuring site link costs, and configuring site boundaries.

Monitoring Active Directory replication failures, using tools such as Replication Monitor, Event Viewer and support tools to monitor Active Directory replication and File Replication Service (FRS) replication.

Restoring Active Directory directory services, including performing both authoritative restore and nonauthoritative restore operations.

Troubleshooting Active Directory, including diagnosing and resolving issues related to Active Directory replication, operations master role failure, and the Active Directory database.

Planning a security group strategy.

Planning a user authentication strategy, including planning a strategy for smart card authentication and creating a password policy for domain users.

Planning an OU structure, including analyzing the administrative requirements for an OU and analyzing the Group Policy requirements for an OU structure.

Implementing an OU structure, including creating an OU, delegating permissions for an OU to a user or a security group, and moving objects within the OU hierarchy

Planning a Group Policy strategy, including using Resultant Set of Policy (RSoP) planning mode, and strategies for configuring the user environment and computer environments using Group Policy.

Configuring the user environment with Group Policy, including distributing software to users via Group Policy, automatically enrolling user certificates with Group Policy, redirecting folders via Group Policy and configuring user security settings using Group Policy.

Deploying a computer environment using Group Policy, including distributing software to computers via Group Policy, automatically enrolling computer certificates with Group Policy, and configuring computer security settings using Group Policy.

Troubleshooting issues related to Group Policy application and deployment, using tools such as RSoP and the gpresult command.

Maintain installed software using Group Policy, including distributing updates to software distributed by Group Policy and configuring automatic updates for network clients using Group Policy.

Troubleshoot the application of Group Policy security settings, using tools such as RSoP and the gpresult command.

Microsoft reserves the right to change the objectives and/or the exam at any time, so you should check the web site at http://www.microsoft.com/traincert/exams/70-294.asp for the most up-to-date version of the objectives.

Functional Levels

When a Windows Server 2003 domain controller is created on a network, AD is installed with a basic set of features. Additional features can be enabled, depending on the operating systems running as domain controllers and the functional level that is configured for the domain or forest.

NOTE

Windows 2000 contained two modes: mixed and native. In Windows Server 2003, these are now called functional levels, but they remain unchanged. Just as Windows 2000 installed in mixed mode, Windows Server 2003 installs in the Windows 2000 mixed functional level. In Windows 2000, there was only one level of forest operation. Modes existed only at the domain level. With Windows Server 2003, there are domain functional levels and separate forest functional levels. In order to raise the forest functional level, the functional level of all domains in the forest must be set to the appropriate level.

Domain Functional Levels

The domain functional level determines which servers are supported in a domain and the features that are available in AD. When one or more Windows 2003 Server computers are installed on a domain, the domain functional level can be set for AD. At lower levels, older versions of Windows servers can still be used in the domain, but more advanced features for AD are sacrificed. At the highest level, only Windows 2003 Server machines can be used in the domain, and a full set of these advanced features become available. By not setting the domain functionality to an appropriate level, you may be forfeiting a number of the features you need for your network.

There are four different levels of functionality for AD:

■

Windows 2000 mixed Allows domains to contain Windows NT Backup domain Controllers (BDCs) that can interact with the PDC emulator in a Windows Server 2003 AD domain. In this level, the basic features of AD are available. However, you cannot use additional group nesting, universal security groups, or security ID histories (SIDHistory) when moving accounts between domains. Because it accommodates the widest variety of domain controllers on your network, this is the default level of functionality when a Windows Server 2003 domain controller is installed.

■

Windows 2000 native The highest mode available for Windows 2000 and the next highest level for Windows Server 2003 domain controllers. This functional level removes support for replication to Windows NT BDCs, so these older servers are unable to function as domain controllers. In this level, only Windows 2000 and Windows Server 2003 domain controllers can be used, and support for universal security groups, SIDHistory, and group nesting becomes available.

■

Windows Server 2003 interim New in Windows Server 2003, this level is used when your domain consists of Windows NT and Windows Server 2003 domain controllers. It provides the same functionality as Windows 2000 mixed mode, but is used when you are upgrading Windows NT domains directly to Windows Server 2003. If a domain has never had (and will not have) Windows 2000 domain controllers, this is the level used for performing an upgrade.

■

Windows Server 2003 The highest functionality level for AD, this level is used when there are only Windows Server 2003 domain controllers in the domain. When this level is set for the domain, a number of additional features are enabled, which we’ll discuss shortly.

If you’re upgrading from Windows 2000 Server on your network, you’re probably familiar with the first two levels. Each of these appeared in Windows 2000 and allowed control of which operating systems were supported and the features that were available in AD. Windows 2000 mixed mode provides backward-compatibility with older operating systems like Windows NT 4, allowing Windows NT BDCs to still be used in a domain. Windows 2000 native mode restricted the domain to using only Windows 2000 Server machines on the network, and it provided an expanded feature set for AD. In Windows 2003 Server, these modes are now referred to as functional levels, and they allow Windows 2003 Server to provide backward-compatibility to domain controllers using these operating systems. In addition to these functional levels, Windows 2003 also introduces two new domain functional levels that were not available in the previous versions: Windows Server 2003 interim and Windows Server 2003.

The tool used to raise domain and forest functional levels is Active Directory Domains and Trusts. To raise a domain level, right-click the domain in the left console pane and click Raise Domain Functional Level in the context menu. The Raise Domain Functional Level dialog box appears, as shown in Figure 2.13. Select the functional level that you want, and then click Raise.

Figure 2.13. Raising the Domain Functional Level

When raising the domain functional level, it is important to remember that it is a one-way change. After raising the level, you cannot lower it. For example, if you raise the domain from Windows 2000 mixed to Windows Server 2003, you cannot return the level to Windows 2000 mixed again. This means that you cannot add Windows NT BDCs or Windows 2000 domain controllers to the domain after the upgrade. If you attempt to change the domain functional level after raising it to Windows Server 2003, a dialog box similar to the one shown in Figure 2.14 will be displayed.

Figure 2.14. Attempting to Change a Domain Functional Level After Raising the Functional Level

After all domain controllers are running Windows Server 2003 and the domain functional level has been raised to Windows Server 2003, new features are automatically available. One such feature is the domain controller renaming tool, which allows you to rename a domain controller without needing to demote it first. This can be useful when you need to restructure the network or simply wish to use a more meaningful name for a particular domain controller. When you use this tool, AD and DNS entries for the renamed domain controller are automatically updated.

NOTE

You can also rename domains using the domain rename utility (rendom.exe). Using this tool, you can change the NetBIOS and DNS names of a domain, including any child, parent, domain tree, or forest root domains. By renaming domains, you can move them in the DNS hierarchy. For example, you can change the name of dev.web.syngress.com to dev.syngress.com, placing the web.syngress.com and dev.syngress.com domains on the same level of the hierarchy. You can even rename a domain so that it becomes part of a completely different domain tree. The only domain that you cannot reposition in this manner is the forest root domain.

The Windows Server 2003 domain functional level also provides a new attribute for user and computer accounts. The lastLogonTimestamp is added to user and computer objects, and it is replicated within the domain to all domain controllers, so that the last time these accounts were used to log on to the domain can be recorded. This way, a history of the user or computer account is created.

Another feature that becomes enabled when the domain functional level is raised is the ability to add a password to InetOrgPerson accounts. InetOrgPerson is an object class in AD that is used to create accounts that represent users in non-Microsoft directory services, and it is used in the same way as a user object. Other network operating systems, such as Novell NetWare, use their own implementations of a directory service, which are not always compatible with AD. InetOrgPerson is used to assist applications written for other directories or when migrating from these directory services to AD. Object classes are sets of attributes used to determine which attributes an object may have when it is created. Using the InetOrgPerson class, you can create a type of user account that is compatible with accounts from other directory services.

The features we’ve covered so for are only available in the Windows Server 2003 functional level. However, other features for the Windows Server 2003 level may also be available when lower functional levels are implemented. Windows 2000 native and Windows Server 2003 functional levels provide the ability to nest security and distribution groups in one another. Security groups are used to assign permissions and rights to groups of accounts, rather than modifying each account individually. Distribution groups are used to send bulk e-mail to large groups of users as a single entity. By nesting groups, one group can be added as a member of another group, saving the need to repeatedly add the same accounts to the membership of various groups.

Limited group nesting is available for domains running in Windows 2000 mixed mode. When this functional level is used, group nesting for distribution groups is allowed, but there is limited support for security groups. You can nest security groups only if you are adding global groups to the membership of domain local security groups. Aside from this, nesting isn’t permitted.

New & Noteworthy…

InetOrgPerson Object Class

The InetOrgPerson object class and the attributes it contains originate from RFC 2798. RFC is an acronym for Requests for Comments, and is a document that is used to specify information and/or technical specifications. RFC 2798 was created by the Internet Engineering Task Force (IETF) to address the need for a class of user that accessed directory services over the intranet or Internet. This class of user was designed to hold attributes about people who accessed the directory using the Lightweight Directory Access Protocol (LDAP) in this way.

Because of the need for this type of user class, Microsoft provided a kit that added an InetOrgPerson object class to the schema in Windows 2000. The schema is part of AD and defines the classes of objects and the attributes that can be used in AD. In Windows Server 2003, an InetOrgPerson object class is included in the AD schema as a type of user class that can be used by LDAP applications that require this type of object and when migrating to AD from other directory services. This saves administrators from needing to extend the schema to create a new InetOrgPerson object class.

Another benefit of the Windows 2000 native or Windows Server 2003 functional level is that universal security groups can be used. (Domains that have the functional level set to Windows 2000 mixed do not allow universal security groups to be created.) Universal security groups can contain accounts and groups from any domain in the forest, and they can also be assigned permissions to resources in any domain in the forest. In this situation, the group can contain user accounts, global groups, and universal groups from any domain in the forest, and it can be assigned permissions to resources in any domain. Universal distribution groups can be used at any functional level, including Windows 2000 mixed.

In summary, some features are available but limited in the Windows 2000 mixed functional level. In other cases, however, support for a particular feature isn’t available at all. Windows 2000 native or Windows Server 2003 functional levels provide the ability to convert groups. Each of these higher functional levels allows conversion between security groups and distribution groups. In addition, the Windows 2000 mixed functional level does not support SIDHistory, which allows user and computer accounts to be moved from one domain to another without affecting existing permissions. By failing to raise the functional level of a domain, you make several features unavailable to it.

Forest Functional Levels

In addition to the domain functional level, you can also set the functional level of a forest. A domain functional level is individually set for each domain. The forest functional level is set for the entire forest and thereby affects all domains within that forest. There are three different forest functional levels:

■

Windows 2000

■

Windows Server 2003 interim

■

Windows Server 2003

By default, the functional level of a forest is set to Windows 2000. The Windows 2000 forest functional level allows Windows NT, Windows 2000, and Windows Server 2003 domain controllers on the network. However, it also provides fewer features than the higher functional levels. Elevating the functional level of a forest enables additional features. At the Windows Server 2003 interim level, domain controllers running Windows NT Server 4 and Windows Server 2003 can exist within the forest. This level is used when directly upgrading from Windows NT 4 to Windows Server 2003. When the default level is raised to Windows Server 2003, additional features in AD become available.

To raise the forest functional level, all domains in the forest must consist only of domain controllers running Windows Server 2003. In addition, the functional level of all domains must be set to Windows 2000 native or higher. After the functional level has been raised, all domains will have their functional level set at Windows Server 2003, even if it was set at Windows 2000 native prior to the forest level being elevated.

Like domain functional levels, forest functional levels are raised using Active Directory Domains and Trusts. As shown in Figure 2.15, this tool has an Active Directory Domains and Trusts node in the left pane. Right-click this node and click Raise Forest Functional Level in the context menu. You will see a dialog box that is similar to the one for raising the domain functional level (see Figure 2.14). Select the new functional level from the drop-down list, and then click Raise to complete the task.

Figure 2.15. Using Active Directory Domains and Trusts

As with domain functional levels, raising the forest functional level is a one-way change. After raising the level, you cannot lower it. Therefore, it is important that you decide which domain controllers exist on your network or may be added in the future prior to raising the level. If older operating systems are used for domain controllers in the forest, you will need to upgrade them before raising the level, and you will not be able to add these older systems after you make this change.

By raising the functional level to Windows Server 2003, new features become available to the forest. One such feature is the ability to create forest trusts. Forest trusts are one or two-way transitive trust relationships between two different forests. A trust relationship allows pass-through authentication, so users who are authenticated in a trusted domain can use resources in a trusting domain. Because the trust between a parent and child domain is bidirectional, meaning that both domains trust one another, users in each domain can access resources in the other domain. This expands the network, so users are able to use services and resources in both forests.

NOTE

Forest trusts are new in Windows Server 2003. They involve a great deal of complexity that does not exist in other trust relationships. It is important to note that when a forest trust exists, the Global Catalog for each forest remains separate. Much of the additional complexity stems from this fact. When a user who is logged on to a domain in one forest attempts to access resources in a domain located in the other forest, special pointers in the local forest’s Global Catalog must be present. The default settings often allow for a free exchange of users in each direction the trust allows. For maximum security, these pointers should be manually configured by an administrator, so that only specific domains or resources on each side of the trust are accessible from across the trust.

To improve the performance of replication across the network, the Windows Server 2003 level allows linked value replication. To ensure that all domain controllers have a duplicate copy of AD, directory data is replicated between them. Linked value replication improves replication by having less information copied between domain controllers. Rather than treating the entire membership of a group as a single unit of replication, linked value replication allows individual members of groups to be replicated (instead of the entire group).

When the functional level is raised to Windows Server 2003, you can make additional modifications to the schema by disabling classes and attributes. When a particular type of object or an attribute is no longer needed in an object, the class or attributes within it can be deactivated. The ability to disable schema objects was available in Windows 2000, but Windows Server 2003 provides the ability to reactivate them again when needed. If schema objects are no longer required, you can deactivate them, and then reactivate them later if the situation changes. (Although classes and attributes can be disabled, they cannot be deleted.)

Now that we’ve discussed raising the domain and forest functional levels, let’s look at the procedure for doing it. Exercise 2.2 will walk you through the process of raising both of these functional levels, so that all of the features discussed earlier are available for use.

EXERCISE 2.02

RAISING DOMAIN AND FOREST FUNCTIONALITY

The following steps should not be performed on a production network. This exercise assumes that all domain controllers in the domain are running Windows Server 2003. After raising the functional levels, you will not be able to roll back to a previous level.

1.

Select Start | Administrative Tools | Active Directory Domains and Trusts.

2.

When Active Directory Domains and Trusts opens, expand the Active Directory Domains and Trusts node and select your domain.

3.

Select Action | Raise Domain Functional Level.

4.

In the Raise Domain Functional Level dialog box, select Windows Server 2003 from the drop-down list, and then click the Raise button.

5.

A warning message will appear, informing you that this action will affect the entire domain and cannot be reversed. Click OK.

6.

After you raise the level, a message box will inform you that the action was successful. Click OK to continue.

7.

Select the Active Directory Domains and Trusts node.

8.

Select Action | Raise Forest Functional Level.

9.

In the Raise Forest Functional Level dialog box, select Windows Server 2003 from the drop-down list, and then click the Raise button.

10.

A warning message will appear, informing you that this action will affect the entire forest and cannot be reversed. Click OK.

11.

After you raise the level, a message box will inform you that the action was successful. Click OK, and then exit the utility.

Working with Active Directory Trusts

One of the many issues that need to be dealt with in any computer organization is how to protect resources. The main difficulty that administrators face is the dilemma of how to ensure that the resources of the company are not accessible by those who do not need access. The other side of that coin, equally important, is how to ensure that people who do need access are granted access with the least amount of hassle. In small companies, the issues are simpler, because multiple domains rarely exist. In today’s larger corporations and conglomerates, the issues of security are compounded. What administrators need is an easy tool to manage access across multiple domains and, often, across forests.

The tool is Active Directory Domains and Trusts. With Active Directory Domains and Trusts, an administrator can establish relationships between domains that will allow users in one domain to access the resources in another. This way, the administrator can ensure that all users who need access can have it without the hassles involved in having user accounts in multiple domains.

Several terms need to be defined in order to understand how trusts work. First, you need to understand the differences between two types of trusts:

Transitive trusts The trust relationship passes through each trusted domain so that if A trusts B and B trusts C, A trusts C.

Non-transitive trusts The trust relationship stops with the two domains between which it is created.

In addition to being transitive or non-transitive, a trust can be either one-way or two-way. A transitive two-way trust allows all domains to share resources to all users regardless of to which domain they belong. For example, you create a trust between two domains (Domain X and Domain Y). User accounts in Domain X have access to resources in Domain Y. The reverse is also true, user accounts in Domain Y have access to domain X’s resources. This is a two-way trust; the trust works in both directions. Now let’s add a new Domain Z and create a trust relationship to Domain Y. The transitive trust allows the user accounts in Domain X to access resources in Domain Z and vice versa without having to create an additional trust between Domain X and Domain Z (see Figure 5.1). This reduces the numbers of trusts that an administrator needs to create and maintain.

A non-transitive trust restricts the relationship to domains outside of the trust. It does not inherently allow other domains to pass through their authentication information to access resources outside of the trust. Once again, let’s use the example of Domain X and Domain Y. If a non-transitive trust relationship is established between Domain X and Domain Y, the user accounts in the two domains have access to resources in the other domain. If we now add a new Domain Z and create a trust between Domain Y and Domain Z, users in Domain X are not automatically allowed access to resources in Domain Z (see Figure 5.2).

We’ve been talking about two-way (bidirectional) trusts; but a trust can also be one-way (unidirectional). One-way trusts are created to allow more restrictive control over which users are allowed access to resources. For example, in Figure 5.3, a one-way trust is created between Domain X and Domain Y. Users in Domain X have access to resources in Domain Y. However, users in Domain Y do not have access to resources in Domain X. In this definition, Domain X is referred to as the trusted domain, and Domain Y is the trusting domain. A two-way trust allows users in either domain to have access to resources in the other domain.

One-way trusts must specify the direction of the trust. One-way trusts can be either incoming or outgoing, depending on whether the trust is created from the trusting or the trusted domain. Incoming trusts permit the users in the domain where the trust is created (the trusted domain) to access resources in the specified domain (the trusting domain). Users in the trusting domain do not have access, through this trust, to the resources in the trusted domain. (You can, however, create a second trust that goes the other way, to accomplish the same effect as a two-way trust.)

Outgoing trusts allow the users in the specified domain (the trusted domain) to have access to resources in the originating domain (the trusting domain). Users in the originating domain do not have access to resources in the specified domain.

Another concept and set of terms to understand in regard to trusts is:

Implicit

Explicit

Implicit trusts are trusts that are created automatically by the nature of the built-in relationships between domains within a forest. These implicit trusts are two-way and transitive. Implicit trusts automatically exist between each domain that is created and its child domain(s). An implicit trust also exists between the root domain of each domain tree and the root domains of every other domain tree in the forest.

An explicit trust is one that is created by an administrator; it does not exist automatically, but has to be explicitly created. For example, an administrator can create an explicit trust (in this case, called a shortcut trust) between any two child domains in different domain trees to provide for a direct trust (and faster authentication) between them.

Explicit trusts are also used to enable authenticate across forests. When a forest trust is created, a transitive trust is created between the forest root domains in both forests. This allows all the members in the forest to exchange authentication information with the other forest. The forest trust is also called an explicit trust between the two forests. If an additional forest trust is created between one of the original forests and a third forest, an implicit trust with the other original forest is not established to the third forest. In order for the third forest to have a trust relationship with the other forest, an explicit forest trust must be created between the two (see Figure 5.4).

News & Noteworthy…

Types of Trust Relationships

Two or more Active Directory domains are implicitly or explicitly connected using trust relationships. The authentication requests made from one domain to the other domains use these relationships. The trusts provide a seamless coexistence of resources within the forest structure. Users are granted access to the resources in the other domain(s) after being authenticated in their own domain first. Once authenticated in their own domain, they can traverse the other domains to gain access to their resources.

Test Day Tip

On the day of the test you will want to review the types of trusts as well as when to use each of the different trusts. On the exam, you might be given a scenario that will require you to determine the type of trust that will best meet the requirements in the scenario.

Because there are several new types of trust, you should ensure that you know when it is appropriate to use the different trusts.

The primary advantage of these relationships is that administrators no longer need to create multiple user accounts for each user who needs access to resources within each domain. Administrators can now add the users of the other domains to their access control lists (ACLs) to control access to a resource. To take full advantage of these relationships, the administrator must know about the various types of trust that exist, and when to use them.

Default Trusts

When the Active Directory Installation Wizard is used to create a new domain within an existing forest, two default trusts are created: a parent and child trust, and the tree-root trust. Four additional types of trusts can be created using the New Trust Wizard or the command-line utility netdom. The default trust relationships inside a Windows 2000 and Windows Server 2003 forest are transitive, two-way trusts.

A parent and child trust is a transitive, two-way trust relationship. It allows authentication requests made in the child domain to be validated in the parent domain. Because the trusts are transitive, these requests pass upwards from child to parent until they reach the root of the domain namespace. This relationship will allow any user in the domain to have access to any resource in the domain if the user has the proper permissions granted.

An additional transitive, two-way trust is created to simplify the navigation, the tree-root trust. This is especially needed in large organizations that might have multiple levels of child domains. The tree-root trust is a trust that is created between any child domain and the root domain. This provides a shortcut to the root. This trust relationship is also automatically created when a new domain tree is created.

Shortcut Trust

Shortcut trusts are transitive in nature and can either be one-way or two-way. These are explicit trusts that you create when the need exists to optimize (“shortcut”) the authentication process. Without shortcut trusts in place, authentication travels up and down the domain tree using the default parent and child trusts, or by using the tree-root trusts. In large complex organizations that use multiple trees, this path can become a bottleneck when authenticating users. To optimize access, the network administrator can create an explicit shortcut trust directly to the target domain (see Figure 5.5).

Figure 5.5. Shortcut Trust

These trusts are used when user accounts in one domain need regular access to the resources in another domain. Shortcut trusts can be either one- or two-way.

One way shortcut trusts should be established when the users in one domain need access to resources in the other domain, but those in the second domain do not need access to resources in the first domain.

Two-way trusts should be created when the users in both domains need access to the resources in the other domain. The shortcut trust will effectively shorten the authentication path, especially if the domains belong to two separate trees in the forest.

Realm Trust

Realm trusts are explicit trusts that are created to join a Windows Server 2003 domain to a non-Windows Kerberos v5 realm. This allows you the flexibility of creating a trust for your non-Windows networks to interoperate with the security services based on other Kerberos v5 implementations, such as with UNIX. This extension of security can be switched from one-way or two-way trusts and from transitive to non-transitive.

External Trust

An external trust is used when you need to create a trust between domains outside of your forest. These trusts can be one- or two-way trusts. They are always non-transitive in nature. This means that you have created an explicit trust between the two domains, and domains outside this trust are not affected. You can create an external trust to access resources in a domain in a different forest that is not already covered by a forest trust (see Figure 5.6).

Figure 5.6. External Trust

Exam Warning

You will always need to create an external trust when connecting to a Windows NT 4.0 or earlier domain. These domains are not eligible to participate in Active Directory. These trusts must be one-way trusts. If you have worked with Windows NT 4.0, you will remember that the only trusts allowed were non-transitive one-way trusts.

After the trust has been established between a domain in a forest and a domain outside the forest, the security principals from the domain outside the forests will be able to access the resources in the domain inside the forest. Security principals can be the users, groups, computers, or services from the external domain. They are account holders that are each assigned a security identifier (SID) automatically to control access to the resources in the domain.

The Active Directory in the domain inside the forest will then create foreign security principal objects representing each security principal from the trusted external domain. You can use these foreign security principals in the domain local groups. This means that the domain local groups can have members from the trusted external domain. You use these groups to control access to the resources of the domain.

The foreign security principals are seen in Active Directory Users and Computers. Since the Active Directory automatically creates them, you should not attempt to modify them.

Forest Trust

A forest trust can only be created between the root domains in two forests. Both forests must be Windows Server 2003 forests. These trusts can be one- or two-way trusts. They are considered transitive trusts because the child domains inside the forest can authenticate themselves across the forest to access resources in the other forest.

Exam Warning

Although the trust relationship is considered transitive, this only applies to the child domains within forests. The transitive nature of the trust exists only within the two forests explicitly joined by a forest trust. The transitivity does not extend to a third forest unless you create another explicit trust (see Figure 5.4).

Forest trusts help manage the Active Directory infrastructure. They do this by simplifying the management of resources between two forests by reducing the required number of external trusts. Instead of needing multiple external trusts, a two-way forest trust between the two root domains will allow full access between all the affected domains. Additionally, the administrator can take advantage of both the Kerberos and NTLM authentication protocols to transfer authorization data between forests.

Forest trusts can provide complete two-way trusts with every domain within the two forests. This is useful if you have created multiple forests to secure data within the forest or to help isolate directory replication within each forest.

Creating, Verifying, and Removing Trusts

Trust relationships are created and managed using the Active Directory Domains and Trusts utility in the Administrative Tools menu. To create or manage trusts, you must be a member of the Domain Admins group or the Enterprise Admins group in the Active Directory, or have the appropriate authority delegated to you.

Most administrators will use the RunAs command to manage trusts. This is generally accepted as a security best practice.

Exercise 5.01

Creating a Transitive, One-Way Incoming Realm Trust

1.

Open Active Directory Domains and Trusts by clicking Start | Programs | Administrative Tools, and then selecting Active Directory Domains and Trusts.

2.

In the console tree, right-click the domain node. Select Properties in the context menu.

3.

On the Trusts tab, click the New Trust button.

4.

When the New Trust Wizard opens, click Next.

5.

On the Trust Name page, enter the target realm's name and click Next.

6.

On the Trust Type page, select Realm Trust and click Next (see Figure 5.7).

Figure 5.7. Trust Types

7.

On the Transitivity of the Trust page, click Transitive, and then click Next (see Figure 5.8).

Figure 5.8. Transitivity of Trust

8.

On the Direction of Trust page, click One-way: incoming, and then click Next (see Figure 5.9).

Figure 5.9. Direction of Trust

9.

On the Summary page, review the information, and then click Finish.

This wizard will allow you to also create non-transitive trusts and two-way and one-way outgoing realm trusts. Alternatively, you can use the netdom command to create a realm trust.