New Active Directory Features on Windows .NET Servers

This section covers the most important, and up-to-date Active Directory features that are available on the Windows .NET Server family domain controllers and may allow administrators to manage Windows .NET domains more efficiently (certainly, this will not be a complete list of features).

Domain Modes and Functional Levels

Let us first discuss certain general domain and forest functionalities that, to some degree, are common for both Windows 2000 and Windows .NET domains.

Windows 2000 domains can operate in either default mixed mode (when a domain can contain Windows 4.0 Backup Domain Controllers, BDC) or native mode (when a domain contains only Windows 2000-based domain controllers).

When a domain's mode is changed to native, the following considerations should be taken into account:

• Domain controllers (DC) no longer support NTLM replication; as a result, the domain's PDC Emulator (a DC that performs the role of Windows NT 4.0 Primary Domain Controller, PDC) cannot replicate data to Windows NT 4.0 BDCs, and Windows NT 4.0-based DCs cannot be added to the domain.

• Domain controllers provide pass-through authentication that allows users and computers using pre-Windows 2000 systems to be authenticated in any domain in the forest (notwithstanding the fact that these systems do not support the Kerberos V5 protocol). Thus, they can use transitive trusts existing in an Active Directory forest and access resources in any domain.

In Windows .NET domains, a new term, functional level, is introduced. Functional levels are defined for a domain as well as for the forest.

The following table lists three available domain functional levels and DC types supported (or that can be introduced into the domain) at these levels:

Domain functional level	Domain controllers supported
Windows 2000 mixed (default)	Windows NT 4.0, Windows 2000, and Windows .NET
Windows 2000 native	Windows 2000 and Windows .NET
Windows .NET	Windows .NET only

Two first levels correspond to the Windows 2000 modes, and aforementioned considerations for the native mode domains are applicable to the Windows 2000 native functional level, too.

Among features that require the Windows .NET domain functional level is the Domain Controller Rename option (see later). Native mode Windows 2000 domains as well as Windows .NET domains at the Windows 2000 native or Windows .NET domain functional level support the following features: universal groups; group nesting; converting group types, and the SID History option (discussed in Chapter 13, "Migration and Directory Reorganization Tools").

Forest functional levels define features available across all domains within a forest. The following table lists two available forest functional levels and DC types supported at these levels:

Forest functional level	Domain controllers supported	Domain functional levels permitted for existing or new domains
Windows 2000 (default)	Windows NT 4.0, Windows 2000, and Windows .NET	Any level
Windows .NET	Windows .NET only	Windows .NET only

There is also a special Windows .NET Interim forest functional level that is only available when a Windows NT 4.0 domain is upgraded to a new Windows .NET forest, which does not contain domain controllers running Windows 2000. (When upgrading a Windows NT 4.0 domain, you might also be interested in the Q284937 and Q298713 articles from the Microsoft Knowledge Base.)

The forest-wide features available at the Windows .NET forest functional level are listed later in this chapter.

Keep in mind the following information regarding the domain modes or forest/domain functional levels:

• It is impossible to change a domain mode from native to mixed mode or to lower a functional level without re-installing Active Directory in this domain or in the entire forest.

• Domains in a forest are not required to operate in the same mode or at the same functional level.

• The native mode or a functional level higher then Windows 2000 mixed level has no impact (except the pass-trough authentication ability) on down-level clients such as Windows 9x/ME or Windows NT (with or without the Active Directory Client extension). This is also the case with trusts between the local domain and any external domains (Windows NT 4.0, Windows 2000 or Windows .NET). However, remember that any external trust is always explicit, unidirectional (one-way), and non-transitive (except for forest trusts).

To learn how to change a domain mode or to raise a domain/forest functional level, see Chapter 5, "Installing Active Directory".

New Features for Windows .NET Domain Controllers

Any domain controller running Windows .NET provides new features described below.

Enhancements in the Administrative Tools

In Windows .NET, the standard administrative snap-ins available in Windows 2000 provide additional options that allow administrators to manage domains more effectively. Among these options are the following:

• Saved directory queries in the Active Directory Users and Computers snap-in

• Selection and modification of multiple of directory objects

• Drag-and-drop operations

• Efficient search capabilities that include new filter and find options

For detailed information, see Chapter 7, "Domain Manipulation Tools".

Active Directory Command-Line Tools

New LDAP-compliant tools, such as DsQuery.exe, DsAdd.exe, DsMod.exe, etc., allow administrators to perform batch and routine operations with directory objects. You can find the tools' descriptions in Chapter 12, "Manipulating Active Directory Objects."

Adding Domain Controllers from Backup Files

An additional domain controller in a domain can be installed from the files restored from a backup of an existing domain controller. This reduces the promotion time, as well as network replication traffic. This installation type will be described in Chapter 5, "Installing Active Directory."

Universal Group Membership Caching

All user authentication attempts are verified on a Global Catalog server to check user membership in the universal groups. This process will generate additional traffic across a WAN to a remote GC server. To eliminate the need to have a GC server in every site, you can designate a DC to cache universal group membership and update that information from a specified site. To learn how to enable caching, see Chapter 7, "Domain Manipulation Tools."

Application Directory Partitions

An application directory partition can be created by an application or administrator, who also defines the partition replication scope. This is the main distinction between this partition type and other Active Directory partitions (whose replication topology, as a rule, is generated automatically by the Knowledge Consistency Checker, KCC). The replication scope for an application partition can include any set of domain controllers in the forest.

An application partition can store any directory objects (except security principals) defined in the schema (including dynamic objects). Objects in application partitions are not replicated to Global Catalog. There are two built-in application partitions that can be used by the Windows .NET DNS servers running on domain controllers (see the next chapter for details).

To view the contents of application partitions, you can use the ADSI Edit snap-in (see Chapter 7, "Domain Manipulation Tools"). To learn how to manage application directory partitions, see Chapter 10, "Diagnosing and Maintaining Domain Controllers."

InetOrgPerson Object Class

The inetOrgPerson object class defined in RFC 2798 has been added to the Active Directory schema to make migration from third party LDAP directories to Active Directory more efficient. The objects of that class are the security principals and can be used as standard user objects.

New Features for Pure Windows .NET Domains and Forests

This section describes new features that are only available when the domain/forest functional level has been raised to Windows .NET.

Rename Options

You can rename a domain controller without first demoting it or change the DNS or NetBIOS name of any domain. Renaming a domain may result in moving it to other location in the forest infrastructure. Detailed descriptions are provided later in this chapter.

Forest Trusts

Forest trust is established between the forest root domains that operate at the Windows .NET functional level and can have a one-way as well as a two-way direction. Unlike usual external trusts, the forest trusts are transitive, i.e., they allow a user authenticated in one forest to access resources located in any domain in another forest.

Forest trusts are discussed in detail in Chapter 5, "Installing Active Directory."

Defunct Objects

Active Directory does not allow you to delete a directory object class or attribute: you can only deactivate it. A deactivated class or attribute is called defunct. It is possible to activate a deactivated class or attribute and redefine it, if there was an error when the class or attribute was initially created.

Replication Enhancements

Some replication related problems existing in Windows 2000 have been addressed in Windows .NET. Primarily, this concerns the enhanced linked value and Global Catalog replication as well as algorithms used by the Knowledge Consistency Checker (KCC) for generating replication topology in forests with large number of sites.

Linked value replication reduces network traffic when group membership is changed: only new or deleted group members are replicated instead of the entire list of group members stored in the member attribute. This is essential for groups with a large number of members.

In Windows 2000, when a new attribute is added to Global Catalog, a full synchronization of partial replicas is required, and this process affects all domains in the forest. In a Windows .NET, only the new attribute is replicated to Global Catalog servers.

Dynamic Auxiliary Classes and Dynamic Objects

It is possible to dynamically link or remove auxiliary classes to object instances as well as to object classes.

Dynamic objects are instantiated from an object class that has the auxiliary class dynamicObject. This class can also be added to an object instance by using a program or script. As a result, a dynamic object exists during the time defined by a Time-to-Live (TTL) value that is assigned at the object creation and can be renewed by a client or an application (see also Appendix B).