Lesson 1: Windows NT and Trusts | MCSE Training Kit (Exam 70-222): Migrating from Microsoft Windows NT 4.0 to Microsoft Windows 2000 (MCSE Training Kits)

This lesson reviews the Windows NT authentication mechanism. By understanding how Windows NT domains perform user validation, you will discover some of the shortcomings inherent in the logon system and build a foundation to appreciate how the Windows 2000 Active Directory architecture removes those limitations.

After this lesson, you will be able to

Explain the Windows NT authentication process.
Recap the use of trusts, global groups, and local groups.
Understand the management limitations of the Windows NT domain architecture.

Estimated lesson time: 30 minutes

Practice: Issues in Planning the Migration

This initial practice presents a fictitious Windows NT network and asks you to plan for its migration to Windows 2000. Do your best to answer the following questions. The remainder of this lesson and the chapter will explain many of the issues that these questions will provoke.

Your corporation has six Windows NT domains that were initially set up by consultants your company hired; the results are shown in Figure 5.1. There are two account domains, two resource domains, a trusting domain that contains the Microsoft Exchange servers, and a trusting domain that contains an RRAS server, your Web services, and your DNS server.

click to view at full size.

Figure 5.1 A Windows NT corporate domain arrangement

You're planning the migration to Windows 2000. Using the information just provided, answer the following questions.

Which domains will you migrate first?
What potential problems exist when migrating two Windows NT account domains into a single Windows 2000 domain?
Draw a diagram of three potential Windows 2000 network designs to which you might migrate the Windows NT network.
If you perform an in-place upgrade of your Windows NT environment,
- What characteristic of an in-place upgrade cannot be changed without a complete reinstallation of the entire system and must therefore be resolved before the upgrade is performed?
- What would change about the domain relationships after they're upgraded?

List three pros and three cons of performing an in-place upgrade and then three pros and three cons for a complete restructure into a parallel, pristine Windows 2000 infrastructure.

	Pro	Con
In-place upgrade	_______________ _______________ _______________ _______________ _______________ _______________ _______________ _______________ _______________	_______________ _______________ _______________ _______________ _______________ _______________ _______________ _______________ _______________
Parallel, pristine restructure	_______________ _______________ _______________ _______________ _______________ _______________ _______________ _______________ _______________	_______________ _______________ _______________ _______________ _______________ _______________ _______________ _______________ _______________

List at least five questions that you would need to ask to produce a more relevant design and what you gain by answering each question.

Answers

Windows NT Domains and Trusts

A Windows NT domain uses a security regime based on access tokens. When a user logs on, a mechanism known as the Local Security Authority (LSA) uses a process called challenge/response to verify that the username and password credentials are those stored in the Security Accounts Manager (SAM) database. If the username and password pair is validated, then an access token is obtained from the security subsystem. This token contains a number of security identifiers (SIDs) that identify the owner and the groups to which the owner belongs.

These SIDS have two main purposes. The first is to audit a person's usage of the system. The second is to determine whether a user or a process invoked by the user has access to a resource. Each resource on the system is assigned a DACL that contains zero or more access control entries (ACEs). Each ACE describes a SID and its level of access to the resource. For example, a user might be granted read-only access to a file or Manage Documents permissions on a printer.

When an attempt is made to use an object, the SIDs on the access token are cross-referenced with the object assigned ACEs by a component called the Security Reference Monitor (SRM). If a match is found, another component called the object manager will give the process the requested access handle (read, write, full control, etc.) to the object.

In a Windows NT system, a primary domain controller holds a master copy of all relevant SIDs pertaining to users, groups, and computers in its SAM database. The PDC is responsible for replicating this information to all backup domain controllers in its domain. This is known as master-slave replication.

Limitations of the Windows NT architecture become evident when you have two or more Windows NT domains and want to give resource access to users from a different domain. Because each domain has a totally unique set of SID values, no other domain can understand or be aware of them. To enable one domain to become aware of another's SIDs while retaining a separate security boundary, Windows NT uses a trust mechanism.

Trusting and Trusted

A trust relationship establishes a line of authentication between domains in which a trusting domain honors the logon authentication of users from the trusted domain. Once a trust relationship is established, the trusting domain becomes aware of the SIDs from the trusted domain. Essentially the trust enables users from a trusted domain to be authenticated in the trusting domain's environment even though their user logon information isn't physically listed in the trusting domain's SAM database. As a result, administrators of the trusting domain can assign DACLs containing SID values from the trusted domain to resources in their domain. Therefore, users from trusted domains can log on to trusting domains and potentially have access to resources outside their security boundaries that reside in those trusting domains.

Using Trusts to Delegate Control

A form of delegation of control can be established by organizing networks into resource domains and account domains and by using global and local groups.

In Figure 5.2, the three resource domains RES1, RES2, and RES3 all have a trusting relationship with the ACCOUNTS domain. Administrators in the resource domains can set up local groups and give these local groups access to resources. A local group can include user accounts (and global groups) from any trusted domain but can only be granted permissions to the resources on the domain where the local group is created. In contrast, a global group can include users from only the domain in which it is created but can be given permissions to resources in any trusting domain. The administrators can then put global groups from the ACCOUNTS domain into these local groups because the resource domains are aware of the trusted global group SIDs from the ACCOUNTS domain.

Figure 5.2 Domains and trusts

This architecture allows a limited form of delegated management in that the administrators in the ACCOUNTS domain can be responsible for user management, while administrators in the resource domains can determine which groups have access to their resources.

The disadvantage of this scenario is that there's no granular delegation of management. For example, in Windows NT without the aid of third party software, you can't delegate authority to individuals in a department or other subunit of the ACCOUNTS domain to manage a particular group of users such as everyone in the finance department or to manage only the passwords of people in the sales department.

In the next lesson, you are introduced to Windows 2000 Active Directory authentication methods and how they do enable you to decentralize management.

Lesson Summary

In this lesson, you reviewed the Windows NT authentication system with its use of SIDs, trusts, and domains. You also learned about the limitations of the Windows NT domain architecture.