Win Server 2008 Directory Services, Functional Levels Overview

Following the recent release of Windows Vista, Microsoft is about to introduce its server counterpart. Built on the same code base as its predecessor, Windows Server 2008 incorporates a variety of features with which Vista users are already familiar, including its well-publicized security, networking and local manageability improvements. On the other hand, there are clearly areas where their commonality is minimal, simply due to their distinct purposes as the server and client operating systems. Besides obvious visual differences, one of more prominent examples in this category is the role in Windows-based directory services infrastructure. Exploring this subject is the main purpose of our new series of articles.

However, before we start looking into the specific details of Windows Server 2008, we examine the major changes in functionality of Windows domains and forests since the introduction of Active Directory, analyzing them in the context of domain and forest functional levels.

Functional levels constitute an extension of the concept of mixed and native mode domains, which made their debut in Windows 2000 Server based Active Directory. Their goal was to set rules and boundaries governing transition from legacy domains (utilizing Windows NT 4.0 Servers) to the new operating system platform, which completion had direct impact on availability of new or improved directory services functionality. The mixed mode allowed for having a combination of Windows NT 4.0 and 2000 Server based domain controllers. It typically resulted from a direct upgrade of a PDC in an existing domain. Its main drawback (in addition to potential risk associated with an in-place upgrade) was a lack of features dependent on having all controllers in the domain running on Windows 2000 Server computers. To change it, you had to eliminate any existing legacy BDCs and switch to the native mode.

Alternatively, you could set up a brand new native mode domain by promoting Windows 2000 Server to its first domain controller and migrating all relevant user, computer, and group accounts from the old domain. In return, you were gaining full access to the following perks:

• Enhanced security group model, allowing for the new group type (universal), group nesting, making it possible to add domain groups — both domain global and domain local types — to other groups of the same type, and extending visibility scope of domain local groups to all member servers in the same domain. Group types can be dynamically changed, as long as such conversion does not violate its inherent characteristics (e.g., resulting in a universal group containing domain local groups).
• Availability of sIDHistory attribute for security principals (users, computers and groups), which preserves permissions to Access Control List secured resources following account migration from other domains. The attribute stores the primary SID of a migrated account in its source domain.
• Full Remote Access Services capabilities, including remote access group policies with such features as assigning static IP addresses and routes to users. This is reflected by the fact that some of user dial-in options, such as “Control access through remote access policy”, “Verify caller ID”, “Assign a static IP Address”, “Apply static routes”, or “Static routes” do not appear in the account Properties dialog box in Active Directory Users and Computers console when operating in mixed mode. In addition, in native mode in a multi-domain environment, a RAS server could validate credentials of dial-in users using transitive Kerberos authentication.
• Multi-master domain topology, instead of legacy, single master model, in which a Primary Domain Controller was the only one capable of making changes to domain objects and replicating them unidirectionally to Backup Domain Controllers. Note that multi-master replication is available in mixed-mode, but limited strictly to Windows 2000 Server based domain controllers.
• Authentication via Kerberos, rather than the less-secure and -efficient NTLM. protocol across entire domain. This is contingent clients and servers being Kerberos-aware.

Following promotion of the first Windows 2000 Server to domain controller, the resulting domain mode was automatically set to mixed. The actual switch from mixed to native mode is deceivingly simple to implement with a couple of clicks in the domain Properties dialog box of Active Directory Users and Computers. Typically, however, it is preceded by lengthy, painstaking preparations, including consolidating domains and migration of their accounts, and it has significant and irreversible implications. At that point you can no longer install any legacy domain controllers or switch back to mixed mode.

The same one-way conversion principle has been incorporated into subsequent Windows server releases, with each bringing further improvements to Active Directory capabilities. The functionality present in earlier versions is then automatically included in their successors. However, since the scope of changes in some cases extends beyond individual domains to an entire forest, which, in turn, requires all domain controllers in the forest be running specific versions of the operating system, Microsoft decided to alter its original convention and came up with the new categorization of “functional levels” containing the designation of either “domain” or “forest.”

Depending on business and infrastructure requirements, risk tolerance and other environmental specifics, the process of reaching the next functional level can be implemented using a per-domain or per-forest approach (or a combination). In case of the former, functional levels of individual domains are increased first and followed by the forest level switch, while the latter reverses this order, while guaranteeing any new domain added to the forest automatically gets assigned matching functional level.

Regardless of which path you take, you must ensure all of their respective prerequisites, such as permitted operating system of domain controller versions or domain functional levels, are met. For example, it is not possible to raise forest functional level to Windows Server 2003 as long as you have any Windows Server 2003 interim level domains. These prerequisites include extending Active Directory schema to introduce new classes and attributes associated with the new operating system platform. At the same rate, it is important to realize that increasing forest and domain functional levels does not have a direct impact on OS version requirements of domain members, although it might require configuration or software updates to accommodate new functionality or address potential compatibility issues.

Next: Functional Levels