As mentioned earlier, the upgrade to Active Directory can be gradual and performed without interrupting operations. If you follow domain upgrade recommendations, it should never be necessary to take a domain offline to upgrade domain controllers, member servers, or workstations.
In Active Directory, a domain is a collection of computer, user, and group objects defined by the administrator. These objects share a common directory database, security policies, and security relationships with other domains. A forest is a collection of one or more Active Directory domains that share the same class and attribute definitions (schema), site and replication information (configuration), and forest-wide search capabilities (global catalog). Domains in the same forest are linked with two-way, transitive trust relationships.
To prepare for upgrades in a domain containing Windows 2000 domain controllers, it is recommended that you apply Service Pack 2 or later to all domain controllers running Windows 2000.
Before upgrading a domain controller running Windows 2000 to Windows Server 2003, or installing Active Directory on the first domain controller running Windows Server 2003, ensure that your server, your forest, and your domain are ready. You can use the /checkupgradeonly parameter in the Winnt32 command-line tool to check the upgrade compatibility of the server.
Reference Points
For more information on Windows Server 2003 command-line tools and on upgrading domain controllers, see the Windows Server 2003 on-screen Help and Support Center.
Working with Remote Installation Services
All editions of the Windows Server 2003 family, with the exception of Web Edition, have Remote Installation Services (RIS), a change and configuration management feature that was also included with Windows 2000. RIS enables you to set up new client computers remotely, without the need to physically visit each client machine. You can use RIS to install operating systems on remote boot-enabled client computers by connecting the computer to the network, starting the client computer, and logging on with a valid user account.
If your network uses RIS with Windows NT Server 4.0, you should make the RIS server the first computer that you upgrade to Windows Server 2003. You won’t be able to use RIS later unless it is upgraded first because of design changes in the way that Active Directory performs authentication. Upgrading the RIS server to Windows Server 2003 gives it the ability to communicate with the remaining Windows NT Server 4.0 domain controllers, as well as with Windows Server 2003 domain controllers.
Note that the Start menu is different for administrators on Windows Server 2003.
Deployment Resources
To deploy domain controllers running Windows Server 2003, it is recommended that you use the Windows Server 2003 Deployment Kit, which is available from the Microsoft Windows Resource Kits Web site at http://www.microsoft.com/windows/reskits/.
The online deployment kit includes case studies and the necessary information for deploying Windows Server 2003 Active Directory in networks that have domain controllers running Windows NT Server 4.0 or Windows 2000.
If your network includes branch offices, see "Designing the Site Topology" at the Microsoft Windows Resource Kits Web site at http://www.microsoft.com/windows/reskits/. This online guide helps you plan Active Directory deployment when there are branch office sites connected with slow network links.
Renaming Domain Controllers
The ability to rename domain controllers running Windows Server 2003 provides you with the flexibility to make changes in a Windows Server 2003 domain whenever the need arises. Rename a domain controller to:
-
Restructure your network for organizational and business needs.
-
Make management and administrative control easier.
When you rename a domain controller, you must ensure that there will be no interruption in the ability of clients to locate or authenticate to the renamed domain controller, except when the domain controller is restarted. This is required for renaming the domain controller.
Another requirement for renaming a domain controller is that the domain functional level must be set to Windows Server 2003. The new name of the domain controller is automatically updated to DNS and Active Directory. Once the new name propagates to DNS and Active Directory, clients are then able to locate and authenticate to the renamed domain controller. DNS and Active Directory replication latency may delay client ability to locate or authenticate to the renamed domain controller. The length of time this takes depends on specifics of your network and the replication topology of your particular organization.
During replication latency, clients may not be able to access the newly renamed domain controller. This might be acceptable for clients that try to locate and authenticate to a particular domain controller since other domain controllers should be available to process the authentication request.
Working with Domain Trust
All trusts within a Windows 2000 or Windows Server 2003 forest are transitive and two-way. Therefore, both domains in a trust relationship automatically trust each other. This means that if Domain A trusts Domain B and Domain B trusts Domain C, users from Domain C (when assigned the proper permissions) can access resources in Domain A.
Trust Protocols
A domain controller running Windows Server 2003 authenticates users and applications using one of two protocols: Kerberos V5 or NTLM. The Kerberos V5 protocol is the default protocol for computers running Windows 2000, Windows XP Professional, or Windows Server 2003. If any computer involved in a transaction does not support Kerberos V5, the NTLM protocol will be used.
With the Kerberos V5 protocol, the client requests a ticket from a domain controller in its account domain to the server in the trusting domain. This ticket is issued by an intermediary trusted by the client and the server. The client presents this trusted ticket to the server in the trusting domain for authentication.
When a client tries to access resources on a server in another domain using NTLM authentication, the server containing the resource must contact a domain controller in the client's account domain to verify the account credentials.
Trusted Domain Objects
Trusted domain objects (TDOs) are objects that represent each trust relationship within a particular domain. Each time a trust is established, a unique TDO is created and stored (in the SYSTEM container) in its domain. Attributes such as a trust’s transitivity, type, and its partner domain name are represented in a TDO.
Forest trust TDOs store additional attributes in order to identify all of the trusted namespaces from its partner forest. These attributes include domain tree names, UPN suffixes, SPN suffixes, and SID namespaces.
Nontransitive Trust and Windows NT 4.0
A nontransitive trust is restricted by the two domains in the trust relationship and does not flow to any other domains in the forest. A nontransitive trust can be a two-way trust or a one-way trust.
Nontransitive trusts are one-way by default, but you can also create a two-way relationship by creating two one-way trusts. Nontransitive domain trusts are the only form of trust relationship possible between:
-
A Windows Server 2003 domain and a Windows NT domain.
-
A Windows Server 2003 domain in one forest and a domain in another forest (when not joined by a forest trust).
Using the New Trust Wizard, you can manually create the following nontransitive trusts:
-
External trust. A nontransitive trust created between a Windows Server 2003 domain and a Windows NT domain, or a Windows 2000 domain or Windows Server 2003 domain in another forest. When you upgrade a Windows NT domain to a Windows Server 2003 domain, all existing Windows NT trusts are preserved intact. All trust relationships between Windows Server 2003 domains and Windows NT domains are nontransitive.
-
Realm trust. A nontransitive trust between an Active Directory domain and a Kerberos V5 realm. For more information about Kerberos V5 realms, see “Kerberos V5 Authentication” in the Windows Server 2003 on-screen Help and Support Center.
External Trust and Windows NT 4.0
You can create an external trust to form a one-way nontransitive relationship with domains outside of your forest. External trusts are sometimes necessary when users need access to resources located in a Windows NT 4.0 domain or in a domain located within a separate forest that is not joined by a forest trust.
When a trust is established between a domain in a particular forest and a domain outside of that forest, security principals from the external domain can access resources in the internal domain. Active Directory creates a "foreign security principal" object in the internal domain to represent each security principal from the trusted external domain. These foreign security principals can become members of domain local groups in the internal domain. Domain local groups can have members from domains outside of the forest.
Directory objects for foreign security principals are created by Active Directory and should not be manually modified. You can view foreign security principal objects from Active Directory Users and Computers by enabling Advanced Features. For information about enabling Advanced Features, see "To View Advanced Features" in the Windows Server 2003 on-screen Help and Support Center.
To create an external trust, you must have Enterprise Admin or Domain Admin privileges for the domain in the Windows Server 2003 forest, and Domain Admin privileges for the domain outside the forest. Each trust is assigned a password that must be known to the administrators of both domains in the relationship. For more information on how to create an external trust, see "To Create an External Trust" in the Windows Server 2003 on-screen Help and Support Center.
Note that in Windows 2000 mixed domains, external trusts should always be deleted from a Windows Server 2003 domain controller. External trusts to Windows NT Server 4.0 or 3.51 domains can be deleted by authorized administrators on the Windows NT Server 4.0 or 3.51 domain controllers. However, only the trusted side of the relationship can be deleted on Windows NT Server 4.0 or 3.51 domain controllers. The trusting side of the relationship (created in the Windows Server 2003 domain) is not deleted, and although it will not be operational, the trust will continue to display in Active Directory Domains and Trusts. To remove the trust completely, you will need to delete the trust from a Windows Server 2003 domain controller in the trusting domain. If an external trust is inadvertently deleted from a Windows NT Server 4.0 or 3.51 domain controller, you will need to recreate the trust from any Windows Server 2003 domain controller in the trusting domain.
For more information about trust types, see the Windows Server 2003 on-screen Help and Support Center.
How Some Windows NT Tasks are Performed in Windows Server 2003
The following table lists common tasks for configuring Active Directory. The user interface for performing these tasks is different in Windows Server 2003 from the way it was in Windows NT Server 4.0.
Task
|
User Interface in Windows NT Server 4.0
|
User Interface in Windows Server 2003
|
Install a domain controller
|
Windows Setup
|
The Active Directory Installation Wizard
|
Manage user accounts
|
User Manager
|
Active Directory Users and Computers
|
Manage groups
|
User Manager
|
Active Directory Users and Computers
|
Manage computer accounts
|
Server Manager
|
Active Directory Users and Computers
|
Add a computer to a domain
|
Server Manager
|
Active Directory Users and Computers
|
Create or manage trust relationships
|
User Manager
|
Active Directory Domains and Trusts
|
Manage account policy
|
User Manager
|
Active Directory Users and Computers
|
Manage user rights
|
User Manager
|
Active Directory Users and Computers
|
Manage audit policy
|
User Manager
|
Active Directory Users and Computers
| Table 4 Some User Interface Differences between Windows NT Server 4.0 and Windows Server 2003
On servers running Windows NT Server 4.0 and earlier, read access for user and group information is assigned to anonymous users so that existing applications, including Microsoft BackOffice®, SQL Server™, and some non-Microsoft applications, function correctly.
In Window 2000 and Windows Server 2003, members of the Anonymous Logon group have read access to this information only when the group is added to the Pre-Windows 2000 Compatible Access group.
Using the Active Directory Installation Wizard, you can choose if you want the Anonymous Logon group and the Everyone security groups to be added to the Pre-Windows 2000 Compatible Access group by selecting the Permissions compatible with pre-Windows 2000 server operating systems option. To prevent members of the Anonymous Logon group from gaining read access to user and group information, choose the Permissions compatible only with Windows Server 2003 operating systems option.
When upgrading a domain controller from Windows 2000 to Windows Server 2003, if the Everyone security group is already a member of the pre-Windows 2000 Compatible Access security group (indicating backward compatibility settings), the Anonymous Logon security group will be added as a member of the pre-Windows 2000 Compatible Access security group during the upgrade.
You can manually switch between the backward compatible and high-security settings on Active Directory objects by adding the Anonymous Logon security group to the pre-Windows 2000 Compatible Access security group using Active Directory Users and Computers.
Note that if you select the Permissions compatible only with Windows Server 2003 operating systems option while promoting a domain controller and you find that your applications are not functioning correctly, try resolving the problem by manually adding the special group Everyone to the Pre-Windows 2000 Compatible Access security group and restarting the domain controllers in the domain. Once you have upgraded to applications compatible with Windows Server 2003, you should return to the more secure Windows Server 2003 configuration by removing the Everyone group from the Pre-Windows 2000 Compatible Access security group and restarting the domain controllers in the affected domain.
|
