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
Estimated lesson time: 30 minutes
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.
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.
|In-place upgrade|| |
|Parallel, pristine restructure|| |
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.
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.
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.
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.