Feature

Description

Cross-Forest Trust and Management

Users can securely access resources in other forests without sacrificing the single sign-on and administrative benefits of having only one user ID and password maintained in the user’s home forest.

Additional security features make it easier to manage the multiple forests and cross domain trusts. A new credential manager provides a secure store of user credentials and X.509 certificates. In addition, Forest trust provides a new type of Windows trust for managing the security relationship between two forests—greatly simplifying cross-forest security administration and authentication.

Domain Rename

This feature supports changing the Domain Name System (DNS) and/or NetBIOS names of existing domains in a forest such that the resulting forest is still “well formed.” This feature is particularly useful in scenarios where a corporation must change the names of domains. For example, when a corporation undergoes a legal name change, or when companies merge and want to have a consistent nomenclature. Using Domain Rename is much more efficient than traditional methods that may involve creating a new domain and migrating all the user and computer objects to the new domain.

The identity of a renamed domain represented by its domain Globally Unique ID (GUID) and its domain Security ID (SID) will not change. In addition, a computer’s domain membership does not change as a result of the holding domain being renamed.

Although this feature provides a supported means to rename a domain, it is not viewed nor meant to be a routine IT operation. Domain Rename will cause a service interruption requiring every Domain Controller to be rebooted. Domain rename will also require that every member computer of the renamed domain must be rebooted twice.

Deactivation of Attributes and Class Definitions in the Schema

Active Directory’s flexibility has been enhanced to allow the deactivation of attributes and class definitions in the Active Directory schema, such that attributes and classes can be redefined if an error was made in the original definition. Deactivation is a reversible operation, so it will be possible to undo an accidental deactivation without side-affects. For example, if a new schema object is added to the directory incorrectly, an administrator can use this feature to deactivate the object and re-enter the correct definition for the object.

A Windows 2000 Domain Controller cannot be upgraded to a later server version if a new schema object introduced in the Active Directory schema in the later version conflicts with a user-introduced schema extension. An IT administrator can use the schema deactivate feature to move the offending schema object out of the way in order to allow the system upgrade to proceed.

This feature also allows developers more flexibility in developing to the Active Directory. If, for example, a developer includes attributes and classes as Active Directory schema extensions during development of a new application and later finds a need to change the definition of an attribute, this feature allows the developer to make such a change while preserving the identity of the attribute.

Or if a business group has replaced use of several applications that extended the Active Directory schema with a new application that uses the Active Directory schema. This feature provides the IT administrators the ability to deactivate the unused schema objects of the applications that are replaced so that they do not conflict with any new extensions that may be installed.

Support for the inetOrgPerson Class

An IT administrator can use this feature to migrate their inetOrgPerson objects from an LDAP directory to Active Directory, to compare information in Active Directory to other LDAP directories or to create inetOrgPerson objects in Active Directory. ISVs can easily port applications that are based on the inetOrgPerson class to Active Directory.

Active Directory supports definition of user objects based on the inetOrgPerson class as defined in RFC 2798. This feature includes supporting attributes to the base schema for these user objects. The User Interface (UI) that works with user objects also supports inetOrgPerson objects. Ancillary features include user password defined at user creation time, a samAccountName automatically generated if one is not provided, and the userPassword attribute can be used to set the account password using standard text.

Install Replica from Media

Instead of replicating a complete copy of the Active Directory database over the network, this feature allows an administrator to source initial replication from files created when backing up an existing DC or Global Catalog server. This feature is particularly useful when bandwidth is at a premium. For example, a company might want to place a replica DC in a remote site that has low bandwidth network connectivity. Replicating the entire directory over this link can be time consuming.

The backup files, generated by any Active Directory-aware backup utility, can be transported to the candidate DC using media such as tape, Compact Disk (CD), Digital Video Disc (DVD), or file copy over a network.

In order to use this feature, you must run the Active Directory Installation Wizard in Advanced Mode (dcpromo.exe/adv).

Improved Replication of Group Membership

As group members are added, changed or deleted only those changes are replicated resulting in lower network bandwidth and processor usage during replication and virtual elimination of the possibility of lost updates during simultaneous updates. In Windows 2000 Active Directory, the membership of a group is stored and replicated as a single unit. As a result, a change to a group with large membership caused the entire membership to replicate, consuming a less-than-optimal amount of network bandwidth and increasing processor load. In addition, if the membership of a group is updated simultaneously on two or more Windows 2000 domain controllers, then some of the membership updates could theoretically be lost during replication conflict resolution.

When a forest is advanced to Forest Native Mode of Windows Server 2003 family, group membership is changed to store and replicate values for individual members instead of treating the entire membership as a single unit.

When an IT administrator makes updates to security groups or mail distribution lists to a Domain Controller running in Forest Native Mode of Windows Server 2003 family, integrity of the updates are maintained.

Easier Logon for Remote Offices

The loss of connectivity between a branch office and a global catalog no longer impacts the ability of branch users to logon. Branch offices with domain controllers can provide user logon through cached credentials without first contacting the Global Catalog, improving system performance and robustness over unreliable wide area networks.

In Windows 2000, when processing a logon for a user in a native mode domain, a Domain Controller (DC) had to contact a Global Catalog (GC) server in order to expand a user’s Universal Group membership. This requirement compelled some organizations to deploy GC servers into remote offices in order to avoid logon failures if the network link that connected the remote site to the rest of the organization was disconnected.

In Windows Server 2003, DCs in a site that does not contain a GC server can be configured, through the Active Directory Sites and Services Snap-in, to cache Universal Group membership lookups when processing user logons. This allows a DC to process logons without contacting a GC and when a GC server is unavailable. Group memberships for users that log on to the DC in the site will be cached. The cache will be refreshed on a periodic basis as determined by the replication schedule. This also results in reduced bandwidth requirements for replication.

Improved Performance Features

Windows Server 2003 more efficiently manages the replication and synchronization of Active Directory information. Administrators can better control the types of information that are replicated and synchronized between domain controllers both within a domain as well as across domains. In addition, Active Directory provides more features to intelligently select only changed information for replication—no longer requiring updating entire portions of the directory.

Improved Synchronization

Features

This feature allows a company to scale their enterprise more effectively. When the Global Catalog’s Partial Attribute Set (PAS) is extended, such as for a line-of-business application deployment or any administrative action, new capabilities will minimize the impact to the administrator’s network infrastructure. This is especially important for administrators with large directories and those with global networks that include slower speed links.

With Windows 2000, the Global Catalog (GC) Partial Attribute Set requires that, upon propagation of extended PAS (addition of an attribute to the PAS), the GC initiates a full synchronization cycle of its Read-Only (RO) Naming Context (NC). This is done to become up-to-date with the attribute-extended replica image on other Domain Controllers (DC).

This feature provides a mechanism to preserve the GC synchronization state (rather than re-setting it) and minimizes the work and data replicated when an extended PAS is propagated across the enterprise

Increased Dependability

Active Directory includes several new features that increase dependability such as Health Monitoring, which allows administrators to verify replications between domain controllers, improved Global Catalog replication, and an updated Inter-Site Topology Generator (ISTG) that scales better by supporting forests with a greater number of sites than Windows 2000.

In Windows 2000, the process that automatically created replication connections between Domain Controllers in different sites could not be used when a forest contained a large number of sites. Instead, administrators had to create and maintain manual inter-site replication topologies.

In Windows Server 2003, the Inter-Site Topology Generator (ISTG) has been updated to use improved algorithms and will scale to support forests with a greater number of sites than in Windows 2000. Because all Domain Controllers in the forest running the ISTG role must agree on the inter-site replication topology, the new algorithms are not activated until the forest has advanced to Active Directory forest functionality level of Windows Server 2003 family (described in the feature Active Directory: Forest and Domain Functional Levels).

After an IT administrator advances the forest to Server Active Directory forest functionality level of Windows Server 2003 family, Active Directory will automatically use the improved ISTG to generate the inter-site replication topology.

Disabling Compression of Replication Between Sites

When a number of sites are connected with a high-speed network where bandwidth is not at a premium you can selectively disable compression of replication between Domain Controllers residing in different sites. This results in a reduction of the Central Processing Unit (CPU) utilization on the Domain Controllers and increased availability.

Forest and Domain Functional Levels

There are certain features in Active Directory, such as Group Membership Replication Improvements and Inter-site Replication Topology Generator, that cannot be activated until the Domain Controllers (DCs) in a forest are upgraded to the Windows Server 2003 family.

Forest and Domain Functional Levels is a feature which provides a versioning mechanism that can be used by Active Directory core components to determine what features are available in a forest or domain. It is also used to prevent computers running pre-Windows Server 2003 family operating system Domain Controllers (DCs) from joining a forest or domain that has Active Directory features activated that only apply to the Windows Server 2003 family operating system.

In order to take advantage of the advanced functionality of Windows Server 2003 domains features, an IT administrator can advance the forest or domain functional level to Windows Server 2003 family after all of the DCs in the forest or domain have been upgraded to run the Windows Server 2003 family operating system. This feature is accessed from the NTDSUTIL utility.

Forest and Domain Upgrade with ADPrep

Active Directory has added improvements regarding security and application support. Before the first Domain Controller running the Windows Server 2003 operating system can be upgraded in an existing forest or domain, the forest and domains have to be prepared for these new features. ADPrep is a new tool to aid forest and domain upgrades. The ADPrep tool is not needed when upgrading from Windows NT 4 or when a clean installation of Active Directory is made on servers running the Windows Server 2003 family operating system.

To prepare the forest, the administrator has to run adprep /forestprep on the schema operations master. To prepare a domain, the administrator has to run adprep /domainprep on the infrastructure operations master in each domain.

Lightweight Directory Access Protocol

The Lightweight Directory Access Protocol (LDAP), an industry standard, is the primary access protocol for Active Directory. LDAP version 3 was defined by the Internet Engineering Task Force (IETF). Microsoft is committed to incorporating changes to this standard within Active Directory. Administrators, application developers and 3rd party ISVs benefit by being able to take advantage of the latest advances to the LDAP standard.

Windows Server 2003 family includes several enhancements to the Lightweight Directory Access Protocol (LDAP) client and server implementation:

·          Support for Dynamic Entries: Active Directory can store dynamic entries according to the Internet Engineering Task Force (IETF) standard protocol RFC 2589. Entries in the directory can be assigned Time-To-Live (TTL) values that determine when the entries will be automatically deleted.

·          Transport Layer Security (TLS) support: Connections to Active Directory over LDAP can now be protected using the IETF standard TLS security protocol, as specified in RFC 2830.

·          Support for the Digest Authentication mechanism. Connections to Active Directory over LDAP can now be authenticated using the DIGEST-MD5 SASL authentication mechanism as specified in RFC 2829.

·          Virtual List Views (VLV): When an LDAP query has a large result set, it is inefficient for a client application to pull down the entire result set from the server. VLV allow a client application to “window” through a large result set without having to transfer the entire set from the server. The VLV protocol was defined by the LDAP extensions Working Group of IETF.

·          Support for Dynamic Auxiliary classes: Active Directory now supports dynamically associating an auxiliary class (which adds the attributes that are defined by the auxiliary class) with individual object instances. In Windows 2000, an auxiliary class could only be statically associated with a structural class definition in the schema, which meant that all instances of that structural class got the attributes from the auxiliary class added to them.

·          Support for “fast bind” and connection re-use: At the request of numerous ISVs and application developers we have enhanced Active Directory to support fast binds and connection re-use. Many web applications use Active Directory as an authentication store. Fast binds allow a web, or any other application, to request simple authentication verification from Active Directory without generating Windows-specific authorization information resulting in increased performance of these applications.  An application may also re-use an initial connection to the directory for multiple queries on behalf of different users. This also results in increase performance since the application does not have to re-establish a connection for each query. These enhancements are of particular importance to web applications that are servicing tremendous numbers of Internet-based queries.

Metadirectory Support

Microsoft Metadirectory Services (MMS) helps companies to integrate identity information from multiple directories, databases and files with Active Directory. MMS provides an organization with a unified view of identity information, enables the integration of business processes with MMS and helps to synchronize identity information across an organization.

DirSync Control Improvements

Windows 2000 Active Directory supports a Lightweight Directory Access Protocol (LDAP) control, called DirSync control, to retrieve changed information from the directory. This feature provides a method to imbue the DirSync control with the ability to perform access checks like those performed on normal LDAP searches.

WMI Providers for Replication and Trust Monitoring

Monitoring of trusts and Active Directory replication is made easier through the use of Windows Management Instrumentation (WMI). This feature provides WMI classes to monitor whether Domain Controllers are successfully replicating Active Directory information among themselves. Because many Windows 2000 components, such as Active Directory replication, rely on inter-domain trust, this feature also provides a method to monitor that trusts are functioning correctly.

IT administrators or independent software developers can also use this feature to write scripts or applications that monitor the health of Active Directory replication and inter-domain trust.

Application Directory Partitions

Some directory information does not need to be made globally available. This feature provides the capability to host data in Active Directory without significantly impacting network performance by providing control over the scope of replication and placement of replicas.

Active Directory services will allow the creation of a new type of Naming Context (NC), or partition, referred to as Application Partition. This NC can contain a hierarchy of any type of objects except security principals (users, groups and computers), and can be configured to replicate to any set of Domain Controllers in the forest, not necessarily all in the same domain.

This means that dynamic data from network services such as Remote Access Service (RAS), RADIUS, Dynamic Host Configuration Protocol (DHCP) and Common Open Policy Service (COPS) can reside in a directory so that applications can access them uniformly with one access methodology. Developers will be able to use this feature to write applications data to dedicated application directory partitions rather than to a domain partition.

Lingering Objects Removal Mechanism

This feature prevents inconsistency between various replicas of the Active Directory that may lead to security issues and reduces growth of the Active Directory database size. Lingering objects may exist in the Active Directory due to a long unavailability of a Domain Controller during which the tombstone life time of the objects has expired and the tombstone objects were removed from the Active Directory. This feature provides the ability to delete lingering objects in the Active Directory.

Prevent Overloading Domain Clusters

This feature prevents overloading a first Active Directory Domain Controller introduced in a domain that already contains a large number of upgraded domain members running Windows 2000 and Windows Server 2003 family.

This feature is useful when a Windows NT4 domain contains domain members running Windows 2000, Windows XP Professional and Windows Server 2003 family. When a Primary Domain Controller (PDC) is upgraded to Windows 2000 Service Pack 2 or Windows Server 2003 family it can be configured to emulate the Windows NT4 DC behavior. The domain members running Windows 2000 and Windows Server 2003 family will not distinguish upgraded DCs from Windows NT4 DCs. To accommodate special needs of IT administrators, the domain members running Windows 2000 Service Pack 2 and Windows Server 2003 family can be configured to inform a DC running Windows 2000 Service Pack 2 and Windows Server 2003 family to not emulate Windows NT4 DC behavior when responding to such domain members. This configuration is performed through the Registry Editor.

Remove non-X500 compliant RDN Restrictions

In Active Directory, the naming attribute (also known as the Relative Distinguished Name, RDN, attribute) is defined in the schema for each class. For example, the user class uses the Common Name (CN) as the naming attribute. Classes that do not define a naming attribute inherit the naming attribute from their parent class. After a naming attribute is selected, it cannot be changed. Active Directory also has the requirement that RDNs must be unique within a container, resulting in the inability to have two users with the same RDN to be in the same container.

This feature has been enhanced in the Windows Server 2003 family to allow the ability to delete inetOrgPerson (which uses CN as the naming attribute in the default schema) and re-create it using any Unicode string attribute as the naming attribute. Instead of CN, any other attribute can be used as the naming attribute.

If, for example, there are several users in the Same OU that have the same name, this feature would enable the administrator to choose an identifying attribute for the users that will guarantee that there are no naming collisions. This is also useful in a situation where directories are being merged, as in a corporate acquisition. If a company has acquired another business that is running another Lightweight Directory Access Protocol (LDAP) directory that uses a different naming attribute for their inetOrgPerson objects, the administrator can use this feature to modify the naming attribute and then migrate the inetOrgPerson objects from the LDAP directory to Active Directory.