Chapter 2 - Network Security and Domain Planning

Network security refers to the protection of all components — hardware, software, and stored data — of a computer network from damage, theft, and unauthorized use. A computer security plan that is well thought out, implemented, and monitored makes authorized use of network computers easy and unauthorized use or accidental damage difficult or impossible.

Microsoft included security as part of the initial design specifications for Windows NT, and it is pervasive in the operating system. The security model includes components to control who accesses which objects (such as files and shared printers), which action an individual user can take on an object (such as write access to a file), and which events are audited.

Security over a Windows NT network incorporates domains and trust relationships to provide the most secure networking operating system available.

This chapter provides:

An overview of the Windows NT security model and architecture. 

A description of how the features of the security model control access to resources. 

An overview of auditing security events. 

A description of how domains work to implement security over the network. 

Considerations for planning your domain structure, including a description of the Microsoft domain model. 

Troubleshooting. 

This chapter presumes a good understanding of Windows NT domains. For background information about domains, see "Managing Windows NT Server Domains" in the Microsoft Windows NT Server 4.0 Concepts and Planning Guide. 

Security Model Architecture

Figure 2.1 on the facing page shows the components of the Windows NT security model, which include:

Logon processes, which accept logon requests from users. These include the initial interactive logon, which displays the initial logon dialog box to the user, and remote logon processes, which allow access by remote users to a Windows NT server process. 

Local Security Authority (LSA), which ensures that the user has permission to access the system. This component is the center of the Windows NT security subsystem. It generates access tokens, manages the local security policy, and provides interactive user authentication services. LSA also controls audit policy and logs the audit messages generated by the Security Reference Monitor. 

Security Account Manager (SAM), also known as the directory database, which maintains the user-accounts database. This database contains information for all user accounts and group accounts. SAM provides user validation services, which are used by LSA.

Security Reference Monitor, which checks that the user has permission to access an object and perform whatever action the user is attempting. This component enforces the access validation and audit generation policy defined by LSA. It provides services to both kernel and user modes to ensure the users and processes attempting access to an object have the necessary permissions. This component also generates audit messages when appropriate. 

 

Figure 2.1 Windows NT Security Components 

Together, these components are known as the security subsystem. This subsystem is called an integral subsystem, not an environmental subsystem, because it affects the entire Windows NT operating system.

The Windows NT security model is designed for C2-level security, as defined by the U.S. Department of Defense. Some of the most important requirements of C2-level security are:

The owner of a resource (such as a file) must be able to control access to the resource.

The operating system must protect objects so that they are not randomly reused by other processes.

For example, the system protects memory so that its contents cannot be read after it is freed by a process. When a file is deleted, users must not be able to access the data from that file. 

Each user must identify himself or herself by typing a unique logon name and password before being allowed access to the system. The system must be able to use this unique identification to track the activities of the user. 

System administrators must be able to audit security-related events. Access to this audit data must be limited to authorized administrators. 

The system must protect itself from external interference or tampering, such as modification of the running system or of system files stored on disk. 

For more information about C2-level security, see "Security Considerations and C2 Security Rating," later in this chapter.

Controlling Access

Windows NT Server provides control of what network computer users can and cannot do, while still giving them access to the resources they need. You can allow some users to connect to a resource (such as a printer) or perform an action (such as changing a file) while preventing others from doing so. You can even control access to system functions, such as setting a computer's system clock. This can be done for users working at the computer in which the resource is located and for users connecting to the resource over the network.

The following features allow and restrict access:

User accounts 

User rights 

User groups 

Subjects and impersonations 

Security information about objects (permissions) 

Implementing security over a network also involves the use of domains and domain controllers, which are presented in the section "Windows NT Server Domains" later in this chapter.

User Accounts

An individual who participates in a domain must have a user account to log on to the network and use domain resources, such as files, directories, and printers.

An administrator creates a user account by assigning a user name to an account, specifying the user's identification data, and defining the user's rights on the system. The account includes user information, group memberships, and security-policy information. Windows NT Server then assigns a unique security identifier (SID) to the new account.

Each SID is unique for all time. For example, suppose Sally, who has a Windows NT account, leaves her job at a company but later returns to a different job at the same company. When Sally leaves, the administrator deletes her account, and Windows NT no longer accepts her security ID as valid. When Sally returns, the administrator creates a new account, and Windows NT generates a new security ID for that account. The new security ID does not match the old one, so nothing from the old account is transferred to the new account.

When a user logs on, Windows NT creates a security-access token. This includes a security ID for the user, other security IDs for the groups to which the user belongs, and other information, such as the user's name and the names of the groups to which that user belongs. Every process that runs on behalf of this user will have a copy of his or her access token. For example, when Sally starts Notepad, the Notepad process receives a copy of Sally's access token.

Windows NT refers to the security IDs within a user's access token when he or she tries to access an object. The security IDs are compared to the list of access permissions for the object to ensure that the user has sufficient permission to access the object.

For more information about access tokens, see Chapter 6, "Windows NT Security Model," in the Microsoft Windows NT Workstation 4.0 Resource Guide. 

User Rights

User rights are rules that determine the actions a user can perform. Unless the computer is a domain controller, they are computer-specific policies. If it is a domain controller, the computer policy extends to all domain controllers in the domain.

Note In the current release of Windows NT, the set of user rights is defined by the system and cannot be changed. Future versions of Windows NT may allow software developers to define new user rights appropriate to their application.

User rights can be assigned to individual user accounts, but are usually (and more efficiently) assigned to groups. Predefined (built-in) groups have sets of user rights already assigned. Administrators usually assign user rights by adding a user account to one of the predefined groups or by creating a new group and assigning specific user rights to that group. Users who are subsequently added to a group automatically gain all user rights assigned to the group account.

There are several user rights that administrators of high-security installations should be aware of and possibly audit. Of these, you might want to change the default permissions for two rights: Log on locally and Shut down the system.

User RightGroups assigned this right by defaultRecommended change

Log on locally
Allows a user to log on at the computer, from the computer's keyboard.

Administrators, Backup Operators, Everyone, Guests, Power Users, and Users

Deny Everyone and Guests this right.

Shut down the system (SeShutdownPrivilege)
Allows a user to shut down Windows NT.

Administrators, Backup Operators, Everyone, Power Users, and Users

Deny Everyone and Users this right.

The rights in the following table generally require no changes to the default settings, even in the most highly secure installations.

RightAllowsInitially assigned to

Access this computer from the network

A user to connect to the computer over the network.

Administrators, Everyone, Power Users

Act as part of the operating system
(SeTcbPrivilege)

A process to perform as a secure, trusted part of the operating system. Some subsystems are granted this right.

(None)

Add workstations to the domain (SeMachineAccountPrivilege)

Nothing. This right has no effect on computers running Windows NT.

(None)

Back up files and directories
(SeBackupPrivilege)

A user to back up files and directories. This right supersedes file and directory permissions.

Administrators, Backup Operators

Bypass traverse checking (SeChangeNotifyPrivilege)

A user to change directories and to access files and subdirectories, even if the user has no permission to access parent directories.

Everyone

Change the system time
(SeSystemTimePrivilege)

A user to set the time for the internal clock of the computer.

Administrators, Power Users

Create a pagefile
(SeCreatePagefilePrivilege)

Nothing. This right has no effect in current versions of Windows NT.

Administrators

Create a token object
(SeCreateTokenPrivilege)

A process to create access tokens. Only the Local Security Authority can do this.

(None)

Create permanent shared objects
(SeCreatePermanentPrivilege)

A user to create special permanent objects, such as \\Device, that are used within Windows NT.

(None)

Debug programs
(SeDebugPrivilege)

A user to debug various low-level objects, such as threads.

Administrators

Force shutdown from a remote system
(SeRemoteShutdownName)

A user to shut down a remote computer.

Administrators

Generate security audits
(SeAuditPrivilege)

A process to generate security-audit log entries.

(None)

Increase quotas
(SeIncreaseQuotaPrivilege)

Nothing. This right has no effect in current versions of Windows NT.

(None)

Increase scheduling priority
(SeIncreaseBasePriorityPrivilege)

A user to boost the execution priority of a process.

Administrators, Power Users

Load and unload device drivers
(SeLoadDriverPrivilege)

A user to install and remove device drivers.

Administrators

Lock pages in memory
(SeLockMemoryPrivilege)

A user to lock pages in memory so they cannot be paged out to a backing store, such as Pagefile.sys.

(None)

Log on as a batch job

Nothing. This right has no effect in current versions of Windows NT.

(None)

Log on as a service

A process to register with the system as a service.

(None)

Log on locally

A user to log on at the computer from the computer keyboard.

Administrators, Backup Operators, Guests, Power Users, Users

Manage auditing and security log
(SeSecurityPrivilege)

A user to specify what types of resource access (such as file access) are to be audited, and to view and clear the security log. This right does not allow a user to set system auditing policy using Audit on the User Manager Policy menu. Members of the Administrators group can always view and clear the security log.

Administrators

Modify firmware environment variables
(SeSystemEnvironmentPrivilege)

A user to modify system- environment variables stored in nonvolatile RAM on systems that support this type of configuration.

Administrators

Profile single process
(SeProfSingleProcess)

A user to perform profiling (performance sampling) on a process.

Administrators, Power Users

Profile system performance
(SeSystemProfilePrivilege)

A user to perform profiling (performance sampling) on the system.

Administrators

Replace a process-level token
(SeAssignPrimaryTokenPrivilege)

A user to modify a process's security-access token. This is a powerful right, used only by the system.

(None)

Restore files and directories
(SeRestorePrivilege)

A user to restore backed-up files and directories. This right supersedes file and directory permissions.

Administrators, Backup Operators

Shut down the system
(SeShutdownPrivilege)

A user to shut down Windows NT.

Administrators, Backup Operators, Power Users, Users

Take ownership of files or other objects
(SeTakeOwnershipPrivilege)

A user to take ownership of files, directories, printers, and other objects on the computer. This right supersedes permissions protecting objects.

Administrators

Grouping Users with Similar Needs

Administrators typically group users according to the network access their jobs require. For example, most accountants working at a certain level will probably need access to the same servers, directories, and files. By using group accounts, administrators can simultaneously grant rights and permissions to multiple users. Other users can be added to an existing group account at any time, instantly gaining the rights and permissions granted to the group account.

There can be two types of group accounts:

A global group consists of several user accounts from one domain, which are grouped together under an account name. A global group can contain user accounts from only a single domain : the domain in which the global group was created. Global signifies that the group can be granted rights and permissions to use resources in multiple (global) domains. A global group can contain only user accounts (not other groups). A global group cannot be created on a computer running Windows NT Workstation or on a computer set up as a member server.

For more information about member servers see "Windows NT Server Domains" later in this chapter. 

A local group can include user accounts and global groups from one or more domains, grouped together under one account name. Users and global groups from outside the local domain can be added to the local group only if they belong to a trusted domain. Local signifies that the group can be granted rights and permissions to use resources in only a single (local) domain. A local group can contain users and global groups, but it cannot contain other local groups. 

When working with groups, use these guidelines:

It is best to grant rights and permissions to local groups and to use the global group as the method of adding users to the local groups.

Global groups are the best method for simultaneously adding many users to another domain. The necessary rights and permissions are provided by the local group to which the global groups are added.

Global groups are the most efficient way to add users to local groups.

Global groups can be added to local groups in the same domain or in trusting domains, or to computers running Windows NT Workstation or Windows NT Server as a member server in either the same domain or a trusting domain. 

Windows NT Server has built-in both local and global user groups. For more information about built-in groups, see "Working with User and Group Accounts" in the Microsoft Windows NT Server 4.0 Concepts and Planning Guide.

Subjects and Impersonation

One objective of the Windows NT security model is to ensure that the programs that a user runs have no more access to objects than the user does. That is, if a user is granted only read access to a file, then when he or she runs a program, that program cannot write to the file. The program, like the user, is granted read-only permission.

A subject is the combination of the user's access token and the program that is acting on the user's behalf. Windows NT uses subjects to track and manage permissions for the programs users run.

When a program or process runs on the user's behalf, it is said to be running in the security context of that user. The security context controls what access the subject has to objects and system services.

To accommodate the client/server model of Windows NT, there are two classes of subjects within the Windows NT security architecture:

A simple subject, which is a process that was assigned a security context when the corresponding user logged on. It is not acting in the capacity of a protected server, which may have other subjects as clients. 

A server subject, which is a process implemented as a protected server (such as the Win32 subsystem), and which has other subjects as clients. In this role, a server subject typically has the security context of those clients available for use when acting on their behalf. 

When a subject calls an object service through a protected subsystem, the subject's token is used within the service to determine who made the call and to decide whether the caller has sufficient access authority to perform the requested action.

Windows NT allows one process to take on the security attributes of another through a technique called impersonation. For example, a server process typically impersonates a client process to complete a task involving objects to which the server does not normally have access.

Security Information for Objects (Permissions)

All named objects in Windows NT and some unnamed objects can be secured. A security descriptor describes the security attributes for an object. An object's security descriptor includes four parts:

An owner security ID, which indicates the user or group who owns the object. The owner of an object can change the access permissions for the object. 

A group security ID, which is used only by the POSIX subsystem and ignored by the rest of Windows NT. 

A discretionary access control list (ACL), which identifies the users and groups who are granted or denied specific access permissions. Discretionary ACLs are controlled by the owner of the object. 

A system ACL, which controls the auditing messages the system will generate. System ACLs are controlled by the security administrators. 

For details and background information about security in Windows NT 4.0, see Chapter 6, "Windows NT Security," in the Microsoft Windows NT Workstation Resource Guide.

Types of Objects

The permissions that can be granted or denied for an object depends on the type of object. For example, you can specify permissions, such as Manage Documents and Print for a printer queue, and specify Read, Write, Execute for a directory.

Permissions of an object are also affected by whether that object is a container object or a noncontainer object. A container object is one that logically contains other objects; a noncontainer object does not contain other objects. For example, a directory is a container object that logically contains files and other directories. Files are noncontainer objects. This distinction between container and noncontainer objects is important because objects within a container object can inherit certain permissions from the parent container.

Note NTFS supports ACL inheritance from directory objects to file objects that are created within the directory. For more information about NTFS, see "Disk and File System Basics" and "Choosing a File System" in the Microsoft Windows NT Workstation Resource Guide. 

Access Control Lists and Access Control Entries

Each ACL is made up of access control entries (ACEs), which specify access or auditing permissions to that object for one user or group. There are three ACE types: two for discretionary access control and one for system security.

The discretionary ACEs are AccessAllowed and AccessDenied. These explicitly grant and deny access to a user or group of users. The first AccessDenied ACE denies the user access to the resource, and no further processing of ACEs occurs.

Note There is an important distinction between a discretionary ACL that is empty (one that has no ACEs in it) and an object without any discretionary ACL. In the case of an empty discretionary ACL, no accesses are explicitly granted, so access is implicitly denied. For an object that has no ACL at all, there is no protection assigned to the object, so any access request is granted.

SystemAudit is a system security ACE that is used to keep a log of security events (such as who accesses which files) and to generate and log security audit messages.

Access Masks

Each ACE includes an access mask, which defines all possible actions for a particular object type. An access mask can be compared to a menu, from which you select permissions to grant or deny.

Specific types include access options that apply specifically to an object type. Each object type can have up to 16 specific access types. Collectively, the specific access types for a particular object type are called the specific access mask. These are defined when the object type is defined.

For example, Windows NT files have the following specific access types:

ReadData 

WriteData 

AppendData 

ReadEA (Extended Attribute) 

WriteEA (Extended Attribute) 

Execute 

ReadAttributes 

WriteAttributes 

Standard types apply to all objects and consist of these access permissions:

SYNCHRONIZE, which is used to synchronize access and to allow a process to wait for an object to enter the signaled state. 

WRITE_OWNER, which is used to assign a write owner. 

WRITE_DAC, which is used to grant or deny write access to the discretionary ACL. 

READ_CONTROL, which is used to grant or deny read access to the security descriptor and owner. 

DELETE, which is used to grant or deny delete access. 

Generic types are broad types of access used when protecting an object. Exact implementation of these is determined by the application defining an object. For example, an application that defines a voice-annotation object might define specific access rights by using VOICE_PLAY and VOICE_EDIT for playing and editing the object. It might set up a generic mapping structure in which GENERIC_EXECUTE maps to VOICE_PLAY and GENERIC_WRITE maps to both VOICE_PLAY and VOICE_EDIT.

The following table shows the generic types that are mapped from specific and standard types.

Generic typeMapped from these specific and standard types

FILE_GENERIC_READ

STANDARD_RIGHTS_READ
FILE_READ_DATA
FILE_READ_ATTRIBUTES
FILE_READ_EA
SYNCHRONIZE

FILE_GENERIC_WRITE

STANDARD_RIGHTS_WRITE
FILE_WRITE_DATA
FILE_WRITE_ATTRIBUTES
FILE_WRITE_EA
FILE_APPEND_DATA
SYNCHRONIZE

FILE_GENERIC_EXECUTE

STANDARD_RIGHTS_EXECUTE
FILE_READ_ATTRIBUTES
FILE_EXECUTE
SYNCHRONIZE

Specific and standard types appear in the details of the security log. Generic types do not appear in the security log. Instead, the corresponding specific and standard types are listed.

Access Control Inheritance

When you create new objects within a container object, the new objects inherit permissions by default from the parent object.

In the case of files and directories, changing the permissions on a directory affects that directory and its files but does not automatically apply to existing subdirectories and their contents. They will do so if you select the Replace Permissions On Existing Files check box and the Replace Permissions On Subdirectories check box in the Directory Permissions dialog box.

Access Validation

When a user tries to access an object, Windows NT compares security information in the user's access token with the security information in the object's security descriptor.

A desired access mask for the subject is created, based on the type of access the user is attempting. This desired access mask, usually created by a program that the user is running, is compared with the object's ACL. (All generic access types in the ACL are mapped to standard and specific access types.) Each ACE in the ACL is evaluated as follows:

1.

The security ID in the ACE is compared with the set of security IDs in the user's access token. If a match is not found, the ACE is skipped.

Further processing is based upon the type of the ACE. AccessDenied ACEs are ordered (and therefore processed) before AccessAllowed ACEs. 

2.

If access is denied, the system checks whether the original desired access mask contained only a ReadControl and WRITE_DAC. If so, the system checks whether the requester is the owner of the object. If so, then access is granted. 

3.

For an AccessDenied ACE, the actions in the ACE access mask are compared with the desired access mask. If any access is found in both masks, access is denied. Otherwise, processing continues with the next requested ACE.

4.

For an AccessAllowed ACE, the actions in the ACE are compared with those listed in the desired access mask. If all accesses in the desired access mask are matched in the ACE, no further processing is necessary, and access is granted. Otherwise, processing continues with the next ACE. 

5.

If the contents of desired access mask are still not completely matched at the end of the ACL, access is implicitly denied. 

Auditing Security Events

Windows NT includes auditing features you can use to collect information about how your system is being used. These features also allow you to monitor events related to system security, to identify any security breaches, and to determine the extent and location of any damage. The level of audited events is adjustable to suit the needs of your organization. Some organizations need little auditing information, while others are willing to trade some performance and disk space for detailed information they can use to analyze their system.

Note When you enable auditing, remember that there is a small performance overhead for each audit check the system performs.

Windows NT can track events related to the operating system itself and to individual applications. Each application can define its own auditable events. Definitions of these events are added to the Registry when the application is installed on your Windows NT computer.

Audit events are identified to the system by the event source-module name (which corresponds to a specific event type in the Registry) and an event ID.

The security log in Event Viewer can list events by category and by event ID. The following categories of events are listed in the security log. (Those in parentheses are found in the Audit Policy dialog box in User Manager.)

CategoryMeaning

Account Management (User and Group Management)

These events describe high-level changes to the user-accounts database, such as User Created or Group Membership Change. Potentially, a more detailed, object-level audit is also performed. (See the "Object Access" category, below).

Detailed Tracking (Process Tracking)

These events provide detailed subject-tracking information, such as program activation, handle duplication, and indirect object access.

Logon/Logoff
(Logon and Logoff)

These events describe a single logon or logoff attempt, whether successful or unsuccessful. Included in each logon description is an indication of what type of logon (that is, interactive, network, or service)was requested or performed.

Object Access
(File and Object Access)

These events describe both successful and unsuccessful accesses to protected objects.

Policy Change
(Security Policy Changes)

These events describe high-level changes to the security policy database, such as assignment of privileges or logon capabilities. Potentially, a more detailed, object-level audit is also performed. (See the "Object Access" category, above).

Privilege Use
(Use of User Rights)

These events describe both successful and unsuccessful attempts to use privileges. The category also includes information about when some special privileges are assigned. These special privileges are audited only at assignment time, not at the time of use.

System Event (System)

These events indicate something occurred that affects the security of the entire system or audit log.

For more information about auditing security events, see "Windows NT Security" in the Microsoft Windows NT Workstation Resource Guide, and "Monitoring Events" in the Microsoft Windows NT Server 4.0 Concepts and Planning Guide.

Windows NT Server Domains

A domain is a logical grouping of network servers and other computers that share common security and user-account information. Within domains, administrators create one user account for each user. Users then log on to the domain, not to individual servers in the domain.

The term domain does not refer to a single location or specific type of network configuration. Computers in a single domain can share physical proximity on a small LAN or can be located in different parts of the world. They communicate over any of various physical connections, such as dial-up lines, ISDN, fiber, Ethernet, token ring, frame relay, satellite, and leased lines.

The domain structure provides the following advantages for maintaining a secure network:

Single Logon Procedure 

Network users can connect to multiple servers by logging on to a single network. 

Universal Resource Access 

The user needs only one domain user account and password to use network resources.

Centralized Network Administration 

A centralized view of the entire network from any workstation on the network provides the ability to track and manage information on users, groups, and resources in a distributed network. This single point of administration for multiple servers simplifies the management of a Windows NT Server – based network. 

For detailed information about domains, see "Managing Windows NT Server Domains" in the Microsoft Windows NT Server 4.0 Concepts and Planning Guide.

The Directory Database

The directory database, SAM, stores all security and user-account information for a domain. The master copy of the directory database is stored on the primary server and is regularly replicated to backup servers to maintain centralized security. When a user logs on to a domain, the Windows NT Server software checks the user name and password against the directory database.

Domain Controllers

Domain controllers are computers running Windows NT Server that use one shared directory to store security and user-account information for the entire domain; they comprise a single administrative unit. Within a domain, domain controllers manage all aspects of user/domain interactions. Windows NT domain controllers use the information in the directory database to authenticate users logging on to domain accounts. There are two types of domain controllers:

The primary domain controller (PDC), which tracks changes made to domain accounts and stores the information in the directory database. A domain has one PDC. 

A backup domain controller (BDC), which maintains a copy of the directory database. This is periodically synchronized with the directory database on the PDC. A domain can have multiple BDCs. 

For more information about domain controllers, see "Managing Windows NT Server Domains" the Microsoft Windows NT Server 4.0 Concepts and Planning Guide.

Member Servers

Computers running Windows NT Server can be configured as member servers, which do not store copies of the directory data base and therefore do not authenticate accounts or receive synchronized copies of the directory database. These servers are dedicated to specific tasks, such as print or file servers, or to high-volume applications, such as databases.

Trust Relationships

Windows NT Server directory services provide security across multiple domains through trust relationships. A trust relationship is a link that combines two domains into one administrative unit that can authorize access to resources on both domains.

There are two types of trust relationships:

In a one-way trust relationship, one domain trusts the users in the other domain to use its resources. More precisely, one domain trusts the domain controllers in the other domain to validate user accounts to use its resources. The resources that become available are in the trusting domain, and the accounts that can use them are in the trusted domain. If user accounts located in the trusting domain need to use resources located in the trusted domain, that requires a two-way trust relationship.

A two-way trust relationship is two one-way trusts: Each domain trusts user accounts in the other domain. Users can log on to their domain account from computers in either domain. Each domain can have its own accounts and resources. Global user accounts and global groups can be used from either domain to grant rights and permissions to resources in either domain.

Note Using resources located on any domain, trusting or otherwise, is always subject to permissions associated with the resources.

Through File Manager, users from the trusted domain can be given rights and permissions to objects in the trusting domain, as if they were members of the trusting domain. Users in the trusted domain can browse resources in the trusting domain, subject to account privilege.

For example, suppose the London domain trusts the Topeka domain of a corporate network. User EmilyP, who is a member of the Topeka domain, wants to access Myfile.txt, which is a file located on a computer in the London domain running Windows NT Server. When EmilyP attempts to log on to the server in London, her user account information is not transferred to the London domain's user database. Because London trusts Topeka, the London domain has access to user information in the Topeka domain's user-account database.

Domain Security Policies

Windows NT Server and Windows NT Workstation settings can provide different levels of security for user actions on the domain or computer, respectively.

You can define three security policies that apply to the domain as a whole:

The Account policy controls how user accounts use passwords.

The Audit policy controls the types of events the security log records. 

The Trust Relationships policy controls which domains are trusted and which domains are trusting domains. A trust relationship requires two or more single domains. This policy is available in a single-domain model (in which only one domain exists) only if the domain administering the computer is a domain controller. 

The User Rights policy controls access rights given to groups and user accounts. User rights are applied at the domain level, and affect overall domain security.

For more information about the account policy, the audit policy, and the trust relationships policy, see "Managing Windows NT Server Domains" and for more information about the user-rights security policy, see "Working With User and Group Accounts," in the Microsoft Windows NT Server 4.0 Concepts and Planning Guide 

Computer Accounts and Secure Communications Channels

Each computer running Windows NT Workstation and Windows NT Server that participates in a domain has its own account in the directory database, called a computer account. A computer account is created when the computer is first identified to the domain (rather than to a workgroup) during network setup at installation or when the administrator uses Server Manager to define the computer account.

When a computer running Windows NT Workstation or Windows NT Server logs on to the network, the NetLogon service on the client computer creates a secure communications channel with the NetLogon service on the server. A secure communications channel exists when computers at each end of a connection are satisfied that the computer on the other end has correctly identified itself. Computers identify themselves using their computer accounts. When the secure communications channel has been established, a communications session can begin between the two computers.

To maintain security during the communications session, internal trust accounts are set up between the workstation and the server, between the primary and backup domain controllers, and between domain controllers in both domains of a trust relationship.

Computer accounts and the secure channels they provide enable administrators to remotely manage workstations and member servers. They also affect the relationships between a workstation and domain servers, and between primary and backup domain controllers.

The computer account is part of an implicit one-way trust relationship between the client computer and the controllers in its domain. Workstations request logon authentication for a user account from a domain server in the same way a server in a trusting domain requests validation from a server in a trusted domain. This trust relationship enables administrators to select a workstation or member server for administration in the same way they select a domain.

When the computer account is created, the Domain Admins global group is automatically added to the workstation or member server's Administrators local group. Domain administrators can then use Windows NT Server utilities to remotely manage the computer's user and group accounts, including adding global groups to the computer's local groups. Domain administrators can perform any functions on the computer itself that are allowed by the Administrators local group.

For Windows NT Server domain controllers, computer accounts link the BDCs with the PDCs and pair up trusting and trusted domains. Server trust accounts, created while setting up the secure communications channel, allow BDCs to copy the master directory database from the PDC. Interdomain trust accounts allow domain controllers in a trusted domain to pass through authentication of user accounts to the trusting domain.

Security in Mixed Operating System Environments

Windows NT Server has an open networking architecture that allows flexibility in communicating with other network products. Client computers running operating systems other than Windows NT Workstation or Windows NT Server can interact with computers in a Windows NT Server domain. However, they do not have domain computer accounts and, therefore, do not have Windows NT Workstation logon security. Users running other operating systems can have user accounts stored in the directory database, but the computer itself does not have logon security to restrict access to its own resources.

Computers running Windows NT Workstation or Windows NT Server can also interact with servers and clients running other operating systems. Various protocols and other software that allows interoperability are either included with Windows NT Server or are available separately.

Workgroup Clients

A workgroup is a collection of computers (not users) that form an administrative unit and do not belong to a domain. In a workgroup, each computer tracks its own user- and group-account information and — in contrast to domain controllers — does not share this information with other workgroup computers.

Workgroup members log on only to workstation accounts and can view directories of other workgroup members over the network.

Computers running Windows NT Workstation, Windows NT Server, Windows for Workgroups, or Windows 95 can be configured to participate in either a domain or a workgroup. When setting up one of these computers for networking, you specify a computer name and a workgroup name. If the workgroup name matches a domain name, the computer name appears in the browse list for that domain. The computer can browse computers running Windows NT Server and Windows NT Workstation that participate in either a domain or a workgroup. You can specify whether the computer will log on to a Windows NT Server domain or a workgroup when you set up Windows NT.

Windows 95 Clients

Access to Windows NT Server networking is built in to Windows 95. Users with domain accounts who run Windows 95 can log on to their accounts the same way users running Windows NT Workstation do. Windows 95 user-account logons can be validated by both Windows NT Server domain controllers and LAN Manager 2.x domain controllers.

MS-DOS Clients

MS-DOS client computers running one of the following components can use shared network resources on the respective servers:

Microsoft Network Client for MS-DOS version 3.0 enables computers running MS-DOS to interact with domain controllers running Windows NT Server and with computers running Windows NT Workstation or LAN Manager 2.x servers.

Microsoft LAN Manager for MS-DOS version 2.2 enables computers running MS-DOS to interact with LAN Manager 2.x servers and Windows NT Server domain controllers. 

Because computers running MS-DOS cannot store user accounts, they don't participate in domains the way Windows NT computers do. Each computer running MS-DOS usually has a default domain for browsing. An MS-DOS user with a domain account can be set up to browse any domain, not merely the domain containing the user's account.

LAN Manager 2.x Servers and Clients

Windows NT Server interoperates with Microsoft LAN Manager 2.x systems. Computers running LAN Manager workstation software on MS-DOS, Windows 3.1, or OS/2 can connect to servers running Windows NT Server. LAN Manager 2.x servers (on computers running either OS/2 or UNIX) can also work with servers running Windows NT Server — even in the same domain.

Microsoft LAN Manager for OS/2 version 2.2 is a component of Windows NT Server that enables computers running OS/2 version 1.3x to interact with LAN Manager 2.x servers and computers running Windows NT Workstation and Windows NT Server. If an OS/2 version 1.3x system is running these components, it can share network resources with the respective servers.

Novell NetWare Clients

You can connect computers running Windows NT Server to NetWare file and print resources by using NWLink protocol software and Gateway Service for NetWare. You can also enable a gateway to share NetWare file and print resources with Microsoft networking clients without NetWare client software.

NetWare client computers can also connect to file and print resources and server applications on computers running Windows NT Server.

Macintosh Clients

Microsoft Windows NT Server Services for Macintosh is a component of Windows NT Server that enables Windows clients and Apple Macintosh clients to share files and printers. With Services for Macintosh, one computer running Windows NT Server can act as a server for both types of computer, and Macintosh computers can share resources with any client supported by Windows NT Server, including MS-DOS and LAN Manager client computers.

Logon and Authentication Processes

Before doing anything on a Windows NT system, a user must log on to the system by supplying a username and password. Windows NT uses the username for identification and password for validation. Different processes at several levels protect resources, but logon security protects overall access to a domain or computer. The logon process requires users to identify themselves to the domain or the computer. The user name and password that the user types in the Logon Information dialog box are checked against either the computer directory database (if the user is logging on to a user account defined on the computer) or the domain directory database (if the user is logging on to a domain user account).

Once authenticated, an account is available for use with all Windows NT Server network services and compatible server applications, such as the Microsoft BackOffice™ suite of server products. Through directory services, authentication enables a user logging on to a single Windows NT Server domain to use other applications, such as Microsoft SQL Server and Microsoft Exchange Server, and network services, such as Services for Macintosh.

The initial logon process for Windows NT is interactive, meaning that the user must type information at the keyboard in response to a dialog box that appears on the screen. Windows NT grants or denies access based upon the information the user provides.

The steps included in the interactive logon and validation process are:

1.

The user presses CTRL+ALT+DEL. 

2.

When the user provides a username and a password, the logon process calls the LSA.

3.

The LSA runs the appropriate authentication package.

4.

The authentication package checks the user-accounts database to see if the account is local. If it is, the username and password are verified against those held in the user accounts database. If not, the requested logon is forwarded to an alternate authentication package.

5.

When the account is validated, SAM (which owns the user-accounts database) returns the user's security ID and the security IDs of any global groups to which the user belongs. 

6.

The authentication package creates a logon session and then passes the logon session and the security IDs associated with the user to LSA. 

7.

If the logon is rejected, the logon session is deleted, and an error is returned to the logon process. 

If the logon is not rejected, an access token, containing the user's security ID and the security IDs of Everyone and other groups, is created. It also contains the user rights (described in the next section) assigned to the collected security IDs. This access token is returned to the logon process with a Success status. 

8.

The logon session calls the Win32 subsystem to create a process and attach the access token to the process, thus creating a subject for the user account. (Subjects are described in the section called "Subjects and Impersonation," earlier in this chapter.) 

9.

For an interactive Windows NT session, the Win32 subsystem starts the desktop for the user. 

After the validation process, a user's shell process (that is, the process in which the desktop is started for the user) is given an access token. The information in this access token is reflected by anything the user does or any process that runs on the user's behalf.

Note Windows NT has the ability to support multiple authentication packages that are implemented as DLLs. This flexibility allows third-party software vendors the opportunity to integrate custom authentication packages with Windows NT. For example, a network vendor might augment the standard Windows NT authentication package by adding one that allows users to log on simultaneously to Windows NT and to the vendor's network.

Interactive and Remote Logon

Two logon processes can start logon authentication:

Interactive Logon 

Remote Logon 

Interactive Logon Authentication

Interactive logon occurs when the user types information in the Logon Information dialog box displayed by the computer's operating system. In Domain, the user selects either the name of a domain or the name of the computer being used for logon, depending on where the user account being logged on to is defined. If the computer is a member of a workgroup and not of a domain, the Logon Information dialog box does not have a place for typing in the domain name.

The following table compares the logon options for a user on a computer running Windows NT in a workgroup, in a domain, and in a domain with a trust relationship. The unique identifier used by Windows NT after logon depends on the location of the database used to log on the user. The third column in this table describes the unique identifier used in each case. Any network connection requests sent elsewhere on the network include this unique identifier.

Computer is inUser can logon atUnique identifier

Workgroup

Local database

Computername and username

Domain

Local database
Domain database

Computername and username
Domain name and username

Domain
with a trust relationship

Local database
Home domain database
Trusted domain database

Computername and username
Domain name and username
Trusted-domain name and username

Domain without a trust relationship

Local database

Computername and username
Untrusting-domain name and username

Remote Logon Authentication

Remote logon takes place when a user is already logged on to a user account and makes a network connection to another computer. For example, the user connects to another computer using the Map Network Drive dialog box or the net use command.

A security-access token created at interactive logon is assigned to the initial process created for the user. When the user tries to access a resource on another computer, the remote server authenticates the user again and creates a security-access token for the user. The security-access token is placed in a table stored on the remote server. The server creates a user identifier (UID) for the user and maps it to the user's security-access token. This UID is sent back to the client redirector and is used in all further server-message-block (SMB) communication between the server and client. Subsequently, whenever a request for any resource on that server (and not just in the same share)comes in from the client, the UID identifies the user to the server process. The server checks the table and uses the security-access token stored for the UID.

For example, if a user attempts to connect to \\Myserver\share, a table entry on \\Myserver is set up with the user's SID. This is mapped to the user's access token. Later, if the user attempts to access a share called \art on \\Myserver, the original table entry will be used. The server examines the user's SID, locates an existing table entry, and validates (or denies) access to the files by comparing the access-token information to the access rights of the user. The attempt is successful in this example because the user had already established read access with the connection to \\Myserver\share.

If the user attempts to update information on \\Myserver\art and does not have write access to the share, access is denied. Even if the user is added to a group with write permissions, access will be denied because the one table entry still contains static information about the user's SID. The user must log off and log on again to create a new table entry. Then, the user will be able take advantage of the group's write permissions.

The server process creates a SID for the user and maps it to the user's security-access token. This SID is sent back to the client redirector and is used in all further server message block (SMB) communication between the server and client. Whenever a resource request comes in from the client, the SID identifies the user to the server process. The security-access token that maps to the user ID identifies the user to the remote security subsystem.

 

Figure 2.2 Remote logon authentication 

The steps in a successful remote logon at a computer running Windows NT Workstation or Windows NT Server are:

1.

The client computer sends the username, password, and domain name (the data entered in the Begin Logon dialog box) of the user to the remote Windows NT server.

2.

The authenticating server compares the logon username and password with information in the user-accounts database. 

3.

If access is authorized, the server's LSA constructs an access token and passes it to the server process, which creates a user ID that refers to the access token. 

4.

The user ID is then returned to the client computer for use in all subsequent requests to the server. 

After the session has been created, the client computer sends requests marked with the user ID it received during session setup. The server matches the user ID with the access token in an internal table. This access token at the server is used for access authentication.

The steps in a successful, remote logon at a Workgroup computer connecting to a computer running Windows NT in a domain are:

1.

The local directory database performs interactive logon for the user at the workgroup computer (the client). 

2.

The client's username and a function of the password are passed to the specific server in the domain to which the client is trying to connect. This server checks the username and password with information in its local directory database. If there is a match, access to this server is allowed. 

The steps in a successful remote logon at a domain computer connecting to a computer running Windows NT in the same domain are:

1.

The domain's directory database performs interactive logon for the user at the client computer. 

2.

The client's domain name, username, and a function of the password are passed to the computer being accessed, which passes them to a computer running Windows NT Server in the domain.

3.

The computer running Windows NT Server verifies that the domain name for the client matches this domain. 

4.

The computer running Windows NT Server checks the username and password against the domain's directory database. If there is a match, access is allowed. 

The steps in a successful remote logon at a domain client in a trusted domain connecting to a Windows NT computer are:

1.

The domain's directory database performs interactive logon for the user at the client computer.

2.

The client's domain name, user name, and a function of the password are passed to the computer being accessed. That computer passes the logon information to a Windows NT Server in the domain.

3.

The computer running Windows NT Server verifies that the client's domain is a trusted domain and then passes the client's identification information to a computer running Windows NT Server in the trusted domain.

4.

A computer running Windows NT Server in the trusted domain (that is, in the same domain as the client computer) checks the user name and password against the domain's directory database. If there is a match, access is allowed. 

The NetLogon Service

The NetLogon service provides users with a single access point to a domain's PDC and all BDCs.

The NetLogon service also synchronizes changes to the directory database stored on the PDC to all domain controllers. The size of the directory database is limited only by the number of registry entries permitted and by the performance limits of the computer.

The Windows NT Server NetLogon service automatically synchronizes the directory database. Based on settings in the registry, the PDC sends timed notices, which signal the BDCs to request directory changes from the PDC. The notices are staggered so that not all BDCs request changes at the same time. When a BDC requests changes, it informs the PDC of the last change it received, so the PDC is always aware of which BDC needs changes. If a BDC is up-to-date, the Net Logon service on the BDC does not request changes.

The Change Log

Changes to the directory database consist of any new or changed passwords, new or changed user and group accounts, and any changes in the associated group memberships and user rights.

Changes to the domain-directory database are recorded in the change log. The size of the change log determines how long changes can be held. The default NetLogon-service setting for updates is every five minutes, and the change log holds about 2,000 changes. As a new change is added, the oldest change is deleted. When a BDC requests changes, the changes that occurred since the last synchronization are copied to the BDC.

The change log keeps only the most recent changes. If a BDC does not request changes in a timely way, the entire domain directory database must be copied to that BDC. For example, if a BDC is offline for a time, more changes could occur during that time than can be stored in the change log.

Partial and Full Synchronization

Partial synchronization is the automatic, timed replication to all domain BDCs of directory database changes that have occurred since the previous synchronization.

Full synchronization is copying the entire directory database to a BDC. Full synchronization is automatically performed when changes have been deleted from the change log before replication takes place or when a new BDC is added to a domain.

The default NetLogon-service setting for update timing (every five minutes) and the size of the change log (about 2000 changes) ensure that full synchronization will not be required under most operating conditions.

The NetLogon service accepts logon requests from any client and provides complete authentication information from the directory database.

The NetLogon service runs on any Windows NT computer that is a member of a domain and requires the Workstation service. It also requires the Access This Computer from Network right, which is set in User Manager on computers running Windows NT Workstation, or in User Manager for Domains on domain controllers. A domain controller also requires that the Server service be running.

User Authentication

On a computer running Windows NT Workstation or a computer that is not a domain controller running Windows NT Server, the NetLogon service processes logon requests for the local computer and passes through logon requests to a domain controller.

The NetLogon service processes authenticates a logon request in three steps:

1.

Discovery. 

2.

Secure channel setup. 

3.

Pass-through authentication (where necessary). 

Discovery

When the computer starts up, it must determine the location of a domain controller within the domain and in each trusted domain. (There is an implicit trust between the workstation and domain controllers in the workstation's own domain.)

Locating the domain controller is called discovery. If the computer is part of a workgroup, rather than of a domain, the NetLogon service terminates. (If the workstation is not connected to a network, Windows NT treats it like a member of a workgroup consisting of one member.) Once a domain controller is discovered, it is used for subsequent user-account authentication.

When a domain controller starts up, the NetLogon service attempts discovery with all trusted domains. Discovery is not necessary on the domain controller's own domain, because it has access to its own directory database. Each domain is called three times in intervals of five seconds before discovery fails. If a trusted domain does not respond to a discovery attempt, the domain controller attempts another discovery every 15 minutes until it locates a domain controller on the trusted domain.

If the domain controller receives another request for authorization before discovery is successfully completed, it immediately attempts another discovery, no matter when discovery was last attempted.

Secure Communication Channel

The Net Logon services from each computer issue challenges to and receive challenges from every other computer, to verify the existence of their valid computer accounts. When verification is complete, a communication session is set up between the computers and used to pass user-identification data.

The NetLogon service maintains security on these communication channels by using user-level security to create the channel. The following special internal-user accounts are created:

Workstation trust accounts, which allow a domain workstation to perform pass-through authentication for a computer running Windows NT Server in the domain, as described later in this chapter. 

Server trust accounts, which allow computers running Windows NT Server to get copies of the master-domain database from the domain controller. 

Interdomain trust accounts, which allow a computer running Windows NT Server to perform pass-through authentication to another domain. 

The NetLogon service attempts to set up a secure channel when it is started and discovery is complete. If it fails, NetLogon retries every 15 minutes or whenever an action requiring pass-through authentication occurs. To reduce network overhead for trusted domains, the NetLogon service on a domain controller creates a secure channel only when it is needed.

The first time a user logs on to a domain account from a given workstation, a domain controller downloads validated logon information (from the domain directory database) to the workstation. This information is cached on the workstation. If a domain controller is not available on subsequent logons, the user can log on to the domain account using the cached logon information.

Computers running Windows NT Workstation and Windows NT Server store the information authenticating the last several (the default number is ten) users who logged on interactively. The credentials for users who log on to the local computer are also stored in that computer's local directory database.

Pass-through Authentication

Pass-through authentication occurs in the following cases:

Case 1: An interactive logon in which a user logs on to a computer running Windows NT Workstation or to a computer running Windows NT Server as a member server, and the name in Domain in the Logon Information dialog box is not the computer name. 

Case 2: An interactive logon in which the computer being logged onto is a domain controller but the name in Domain is not the domain to which the controller belongs. 

Case 3: A remote logon (connecting to a computer over the network).

Note If the logon computer is not running Windows NT Workstation or Windows NT Server, domain controller authentication has no effect on the user's ability to use resources on the logon computer.

In case 1, the logon computer sends the logon request to a domain controller in the domain to which the computer account belongs. The controller first checks the domain name. If the domain names matches the controller's domain, the controller authenticates the logon credentials against its directory database and passes the account-identification information back to the logon computer, allowing the user to connect to resources on both the logon computer and the domain.

If the domain does not match the controller's domain, the controller checks whether the domain is a trusted domain. If it is, the domain controller passes the logon request through to a domain controller in the trusted domain. That domain controller authenticates the username and password against the domain directory database and passes the account-identification information back to the initial domain controller, which sends it back to the logon computer.

If the logon credentials supplied match the account-identification information, logon succeeds. If not, logon fails.

In case 2, the controller checks the domain name to see if it is a trusted domain. (The domain controller does not check for computer name because its directory database contains only domain accounts). If the domain is a trusted domain, the controller passes the logon information to a domain controller in the trusted domain for authentication. If the trusted domain controller authenticates the account, the logon information is passed back to the initial domain controller, and the user is logged on. If the account is not authenticated (is not defined in the trusted domain directory database), the logon fails.

If, in case 3, the user is logged on to a computer or domain account and then tries to make a network connection to another computer, pass-through authentication proceeds as in interactive logons. The credentials used at interactive logon are also used for pass-through authentication unless the user overrides those credentials by typing a different domain or computer name and user name in a dialog that appears under the following circumstances:

When the user types an entry in Connect As in the Map Network Drive dialog box.

When the user clicks Start, clicks Run, and types the UNC path at the prompt, using the syntax \\Servername\sharename. 

The figure below illustrates pass-through authentication. In this example, AnnM wants to access a computer in the London domain. Because the London domain trusts AnnM's home domain, Topeka, it asks the Topeka domain to authenticate AnnM's account information.

 

Figure 2.3 Pass-through authentication 

If the user tries to make a network connection to a remote computer in an untrusted domain, the logon proceeds as if the user were connecting to an account on the remote computer. That computer authenticates the logon credentials against its directory database. If the account is not defined in the directory database but the Guest account on the remote computer is enabled, and if the Guest account has no password set, the user will be logged on with guest privileges. If the Guest account is not enabled, the logon fails.

For information about the Guest account, see the Microsoft Windows NT Server 4.0 Concepts and Planning Guide, Chapter 2, "Managing User and Group Accounts."

If the computer being connected to is a BDC in the domain in which the user account is defined, but the BDC fails to authenticate the user's password, the BDC passes through the logon request to the PDC in the same domain. For example, this happens if authentication is attempted after the password changes but before the BDC synchronizes with the PDC.

 

Figure 2.4 Passthrough authentication in Windows NT 

Interdomain Trust Accounts

When one domain is permitted to trust another, User Manager for Domains creates an interdomain trust account in the directory database of the trusted domain. A trusted-domain object is created in the LSA of the trusting domain, and a secret object is created in the LSA of the trusting domain. This account is like any other global user account, except that the USER_INTERDOMAIN_TRUST_ACCOUNT bit in the control field for the account is set. The interdomain trust account is used only by the primary domain controller and is invisible in User Manager for Domains. The password is randomly generated and is maintained by User Manager for Domains.

When this trust relationship is established, the NetLogon service on the trusting domain attempts discovery on the trusted domain, and the interdomain trust account is authenticated by a domain controller on the trusted domain.

Similar accounts and procedures are used in the trust relationships between a PDC and a BDC, and between a domain controller running Windows NT and a computer running Windows NT Workstation in that domain.

In the following example, the trusted domain is referred to as Master and the trusting domain is referred to as Resource. The Master contains the user account information; the Resource trusts the Master to validate user access to its resources.

On each domain controller in RESOURCE, an LSA trusted-domain object represents the trust. This object contains the name of the trusted domain and the domain SID. The LSA trusted-domain object is replicated from the trusting domain PDC to each of the BDCs in the trusting domain.

On each domain controller in RESOURCE, a password is stored in an LSA secret object G$$<TrustedDomainName>, such as G$$MASTER. This object is stored in the registry key

HKEY_LOCAL_MACHINE \Security \Policy \Secrets 

The LSA secret object for the trusted-domain trust relationship is replicated from the PDC in the trusting-domain to each of the trusting-domain BDCs.

On each domain controller in MASTER, the password is stored in the directory database user account marked as INTERDOMAIN_TRUST_ACCOUNT, such as RESOURCE$. This can be viewed in the registry path \SAM\SAM\Domains\Account\Users\Names 

(HKEY_LOCAL_MACHINE subtree)

This account is replicated from the trusted-domain PDC to each of the trusted-domain BDCs.

These accounts are created when a trust is established. The administrator of the trusted domain, MASTER, permits RESOURCE to trust the MASTER accounts. When the domain is added in User Manager to the Trust Relationships dialog box, a hidden user account is created in the directory database for use by the trusting domain. The account contains the specified password, such as RESOURCE$.

For details on how to set up a trust relationship see "Managing Windows NT Server Domains" in Microsoft Windows NT Server 4.0 Concepts and Planning and online Help.

The administrator of the trusting domain establishes the trust. The administrator provides the password specified earlier, and User Manager creates the LSA secret object. The server in RESOURCE attempts to setup a session with the domain controller in MASTER, using the password RESOURCE$. The domain controller in MASTER responds with the error "0xc0000198, Status_Nologon_Interdomain_Trust_Account" because the special Interdomain Trust Account cannot be used in a normal session logon, and the session fails.

This error informs the domain controller in the RESOURCE domain that the trust account exists and a trust is possible. Upon receiving that response, it establishes a null session and then uses remote-procedure-call (RPC) transactions to call the remote APIs that establish the trusted domain relationship. A secure channel is set up later by the NetLogon service, using the trust information that was stored by the User Manager.

After the trust is established, the RESOURCE PDC changes the password for the trusted-domain object. All domain controllers in each domain receive the trust account objects through normal domain synchronization of the directory and the LSA databases. The domain controllers in RESOURCE receive the LSA secret object during the update of the LSA database, and the domain controllers in MASTER receive the account in the directory-database update. With these objects, any domain controller in the trusting domain can set up a secure channel to any domain controller in the trusted domain.

Maintenance of these accounts includes periodic password changes. Every seven days, the PDC of the trusting domain automatically changes the password of the trusted domain object by the following steps.

1.

Setting the OldPassword field of the LSA secret object to the previous NewPassword field. 

2.

Selecting a new password. 

3.

Setting the NewPassword field in the LSA secret object to the selected password.

This ensures that the domain controllers can always access a valid password in the event of a crash.

4.

Sending an I_NetServerPasswordSet RPC call to a domain controller of the trusted domain, asking it to set the password in the directory-database-user trust account to the value of the NewPassword field in the LSA secret object of the trusting domain. The trusting PDC sends the RPC call to the trusted domain controller with which it established the secure channel. That domain controller passes the request through to the trusted PDC. 

The password is now changed on both PDCs. Normal replication distributes the objects to the BDCs.

A domain controller of the trusted domain (MASTER) never initiates the password change. It is always initiated by the trusting domain PDC. Initiating the password change requires that the secure channel has been set up.

It is possible, but not likely, that the trusting domain controller will change the password without updating a domain controller in the trusted domain. For example, this might happen if the trusted domain controller failed during the process and did not received the updated password. As a safeguard, both the old and new passwords are kept in the LSA secret object on the trusting side. The PDC in the trusting domain never changes the new password unless it has successfully set up a secure channel using the current new password. If the secure-channel setup fails because the new password is invalid, the trusting PDC tries the old password. If a secure channel is established using the old password, it immediately (within 15 minutes) continues the password change algorithm with step 4 (above).

Planning Your Domain Design

The three domain models, single domain, single master domain, and multiple master domain, make use of trust relationships. The trust relationships provides flexibility. For detailed information about the three domain models, see "Managing Windows NT Server Domains" in the Microsoft Windows NT Server 4.0 Concepts and Planning Guide.

The domain model you select should match the way you want to manage your organization. The number of users in the organization, the topology, and the location will also influence how domains will be designed, implemented, and where the resources will be located. Because there are few limits imposed by Windows NT software, other aspects of the computing environment must be considered to provide guidelines for the decisions you make about your domain model.

The following assumptions are made:

Unlike the Windows NT Server software, server hardware imposes limits on the number of users or sessions it can support.

Unless otherwise noted, it is assumed that the Windows NT Server to be used as the PDC is a 486/33 machine (or higher) with 32 MB of physical RAM and a 1 GB hard disk. Test conditions at Microsoft included base Windows NT Server services, moderate file and print activity, Remote Access Service, SNA Server, and SQL Server. 

Real-life limits of the Windows NT Server system often go beyond the capacity of the server.

The process of design and selection is recursive.

Decisions made earlier in the process must be verified in light of information available later in the process. Therefore, you should anticipate making several passes through the process until all decisions at all steps match the available information. 

There are many ways to implement your domain model. The following examples illustrate some of the flexibility of domains. These examples are followed by a list of business and equipment considerations that can affect your domain design.

Multiple Independent Lines of Business

Corporation with independent lines of business, such as a consulting division, a real estate division, and a retail sales division, may have separate marketing, sales, and data-processing groups within each of those divisions. At the center of the firm is a small group focused on functional services, such as accounting, finance, and human resources. Usually, users in a division need to access only the resources in their own division. There are times when an employee needs access to resources in another division, which requires that the master domains connect to each other.

 

Figure 2.5 Multiple Independent Lines of Business domain model 

A multiple master-domain model is the best choice for this case because the organization lacks a data-processing staff in its central division. The domain model can be constructed to acknowledge the data-processing autonomy of divisions as they exist. Trust relationships can be created between the master domains, as necessary.

A Large Organization

A large firm (approximately 100,000 employees) may have multiple locations. By using master domains, the number of users per master domain can be as high as 40,000 because the machine accounts are kept in the resource domains. The company can create three master domains of approximately 33, 000 users each or, to accommodate growth of the user base, four master domains of approximately 25,000 users each.

 

Figure 2.6 Large Organization domain model 

The domain in which a user is defined can be based on any grouping or sequencing, such as alphabetical, divisional, departmental, or by location. Which domain is used in defining a particular user is unimportant because a trust relationship exists between each resource domain and each master domain.

Branch Offices

In a branch office, a single domain or single-master domain can usually be used. Companies with many small branch offices can group branch offices together into regional domains that will provide administration for the branches.

When the branch office is linked to the PDC by means of a communications link or modem, a BDC would be the on-site server. The BDC handles local authentication and local file and print services. A second BDC can be added for fault tolerance.

 

Figure 2.7 Branch Offices domain model 

Secure Domains

In the multiple master-domain model, all master domains are linked to each other by trust relationships. Users in all domains can then access resources in any domain. However, some records should not be available for all employees to access, such as confidential financial records and personnel files. The solution is to create domains that are exclusively for the departments with confidential records, such as Finance and Human Resources. Those domains are trusted by the master MIS domain, but they do not trust other domains. Finance and HR users can then access MIS resources, but their own resources remain secure.

 

Figure 2.8 Secure domain model 

Management and Administration Considerations

Windows NT enables you to manage user accounts either centrally or decentrally. With centralized management, there is usually one directory database and, therefore, one master domain, in which all user-account information is stored. Users are defined on the network only once and are given access permissions to resources based on their logon identity in the central user database. The single-domain model and single master-domain models are centrally managed. A multiple master-domain model can also be centrally managed by adding designated administrators to appropriate Admin groups.

With decentralized management, more than one directory database contains information about different user accounts in the organization. You can create trust relationships to enable domains to access resources in other domains. The multiple master-domain model and the single-domain models can use decentralized management.

In planning your domain model, you'll need to establish administrative policies and procedures for how you will:

Manage and monitor domains and accounts. 

Manage and monitor resources. 

Establish addressing and naming conventions. 

Location Considerations

The two most important location considerations are where to locate the BDCs that will act as account logon servers and how to plan account-synchronization traffic across wide area network (WAN) links. If your WAN speed or bandwidth is low, you will want users to log on at a local BDC.

The next consideration is whether your networked organization is in one site or in several sites, connected by WAN links. A site is a well-connected LAN and may communicate by fast links, such as bridges and routers, but not by asynchronous WAN links, such as T1, 56K, or ISDN. Sites generally correspond to physical locations, such as Seattle, Paris, and New York.

The physical distribution of BDCs is determined by several factors: line speed, link reliability, administrative access, protocol, user-authentication requirements, the number of users to be supported at a site, and locally available resources.

The diagram below shows part of a network topology that one of these domains services. The networked hub sites in London, Paris, and Warsaw, which all belong to a European domain.

 

Figure 2.9 Locating domain controllers 

The European PDC is in London, which is the network's main hub to Europe. The European PDC replicates to the BDCs at each site, including New York.

Synchronization over WAN and Remote Area Service

Consideration should be given to the amount of traffic that account synchronization places on WAN or Remote Access Service (RAS) dial-up lines. Avoid full synchronizations across WAN links. Full synchronizations are required when first setting up a new PDC or bringing a new location online. Full synchronizations are also initiated when more than 2,000 changes happen to users or groups within a short time (less than one hour). If you anticipate high change activity, you can increase the value for the size of the change log. If the above conditions do not exist, the synchronization process will include only the changes made in the directory database since the last time synchronization occurred.

BDC Over a RAS Link

A BDC can be connected to a remote domain using Windows NT, a modem, and the Windows NT Server RAS.

Using a RAS-connected BDC as a PDC

If a RAS-connected BDC is expected to be promoted to PDC at some time when it is remotely connected to the domain, this BDC should be set up as a dial-up networking client (RAS is not running on this computer). If you promote the dial-up networking client, NetLogon stops, changes roles, and restarts. RAS depends on NetLogon, so when NetLogon stops, you would lose your connection. By having the RAS client dial-out services on this remote BDC, it can function as a PDC because that functionality does not depend on NetLogon running constantly. If neither the RAS server (which could also be a BDC) nor the RAS-connected BDC are ever expected to serve as PDC, this is not an issue. A RAS-connected BDC that has been promoted to PDC will function as it should, but may respond more slowly, depending on line speed.

Partial Synchronization with a RAS-connected BDC

The default value for ChangeLogSize should be increased if either of the following conditions exist:

A remote site has a RAS-connected BDC that dials in nightly to do a partial synchronization of any changes. 

Daily changes to the SAM/LSA database sometimes exceed 2,000. 

Changing the default log size may also be necessary if many changes occur while a BDC is off-line. Otherwise, that BDC may be forced to do a full synchronization of the database.

If few changes occur during the time a BDC is not connected to the PDC, then the default size is sufficient. If an administrator notices a BDC doing full synchronizations, then it is probably a good idea to increase the ChangeLogSize. The default value for ChangeLogSize is 64K, which handles approximately 2,000 changes.

Calculating Replication Times

Managing the amount of network traffic so that response time remains acceptable is an important part of administration. When the PDC is located across a WAN or modem link, you can estimate the amount of traffic and time needed to replicate directory database changes to and from the PDC and then schedule this traffic to meet the needs of the site. The following chart helps you calculate the time needed for replication:

 Factors 

Password changes per month

Number of user accounts

A

 

Passwords expire in how many (calendar) days

B

 

Divide B by 30

C

 

User account changes A + C

D

Additional changes per month

If number not knows, use 5% of D

E

 

New user accounts

F

 

Group changes * 4

G

 

New machine accounts * 5

H

Amount of data to be replicated per month

D + E + F + G + H

I

Total monthly replication time

Compute throughput; modern/line speed in bps, If in KB, multiply by 1024 (i.e. 56KB = 57344 bps)

J1

 

J1 * 8 bits/bytes =

J2

 

J2 * 60 sec./min. =

J3

 

J3 * 60 min./hour = total throughput

J

 

I/J = total replication time (hours/month)

K

Figure 2.10 Job Aid to Calculate Monthly Replication Time 

Security Considerations and C2 Security Rating

The National Computer Security Center (NCSC) was formed to help businesses and home users protect proprietary and personal data. The first goal of the NCSC was to create a document containing the technical standards and criteria to be used in evaluating computer systems. The NCSC also established a process by which software venders such as Microsoft could submit their security-related products for evaluation.

NCSC Security ratings range from "A" to "D," in which "A" represents the highest security. The "C" rating is generally applied to business software. Each rating is further divided into classes. For example, in the "C" division, software may be rated either "C2" or "C1," with "C2" representing the higher security. The most important feature requirements for operating systems rated "C2" focus on the following features.

Discretionary access and control

Identification and authentication 

Auditing 

Object reuse 

An operating system must be able to define and control its users' access to objects (such as files and directories), provide a way for users to uniquely identify themselves, provide a way to audit security-related events and actions of individual users, and protect one process from accessing the data for another process.

For discretionary access and control, Windows NT enables an administrator or user to determine who can access files and how those files will be accessed. Other uses of Windows NT can be controlled, such as access to printers and network-server sharepoints.

Identification and authentication in Windows NT is achieved through the logon Secure Attention Sequence. All users must log on to start Windows NT. When a Windows NT users type their usernames and passwords to log on locally, they must first press CONTROL+ALT+DELETE to verify that no Trojan Horse programs are present. (A Trojan Horse is a program that can capture a user's logon information, thereby providing network access.) Because each user has a unique user name, domain name, and password combination, Windows NT can assure a user's unique identity.

Using Windows NT, a system administrator can audit all security events and user actions. The User Manager enables an administrator to specify which events (such as logon or file access) will be monitored. All audited information is stored in the Event Log, which can be viewed in Event Viewer.

One of the important issues in software security is object reuse. In a secure operating system, such as Windows NT, all allocation and deallocation of objects (such as files, directories, and memory) must be protected. Only users with proper access permissions should be allowed access. In Windows NT, this is achieved through a robust object manager that either initializes or zeros out objects before presenting them to a user.

The process of software evaluation is comprehensive. The NCSC evaluation is based on a series of standards published in the "Orange Book." Additional documents cover the evaluation process and are collectively referred to as the "Rainbow Series."

Microsoft Windows NT C2 Evaluation

The evaluation process begins when a software vendor presents a proposal to the NCSC, requesting the evaluation process. If approved, the software vendor must demonstrate to the NCSC that the product design and supporting documentation are complete. If satisfied, a team of NCSC evaluators are assigned to evaluate the new product. The most time-consuming part of the process is the evaluation itself. As part of the evaluation, the NCSC evaluators look at each aspect of the system to confirm that security has been properly implemented and to assess that security-testing of the system is complete. Once satisfied, the software is presented to the NCSC Technical Review Board for final approval. If approved, an entry is placed on the Evaluated Products List, indicating the success. The NCSC evaluation team releases a Final Evaluation Report, which covers all evaluated aspects of the software.

Microsoft began the process of the Windows NT Platform evaluation in 1991. In July 1995, Microsoft met its first milestone: a C2 Orange Book listing of the base operating system of the Windows NT Platform version 3.5 (with Service Pack 3).

The Windows NT operating system also received NCSC recognition for two B-level features: B2 Trusted Path and B2 Trusted Facility Management.

The Trusted Path functionality prevents Trojan-horse programs from intercepting username and password information during initial logging on.

The Trusted Facility Management functionality Windows NT supports separate account roles for operator and administrator functions.

For example, Windows NT provides separate administrative roles for Administrators, users tasked with backups, users tasked with administrating printers, privileged Power Users, and Users. 

Microsoft is currently involved in evaluating the Windows NT Platform version 4.0 to obtain the rating of C2 in a homogeneous networked environment. The NCSC publication "Trusted Network Interpretation," also called the "Red Book," serves as an interpretation of the Orange Book, as it applies to networking for this evaluation.

The typical NCSC security-evaluation cycle takes longer than the product release cycle of Windows NT. No significant changes have been made to the Windows NT security model from version 3.5 to versions 3.51 and 4.0.

The United Kingdom and Germany have an evaluation process similar to the one in the United States. This is the Information Technology Security Evaluation Criteria (ITSEC). In 1996, the Windows NT version 3.51 platform (in a homogeneous network environment) will complete its first ITSEC evaluation. Windows NT version 3.51 is seeking a C2 rating with an assurance rating of E3. In an ITSEC evaluation, the assurance rating given to a product indicates the level of analysis and supporting documentation used in developing the product. The greater the assurance rating, the higher the assurance. An E3 rating is typically mapped to the level of analysis performed in a "B" level evaluation.

In the Windows NT Final Evaluation Report, the NCSC security evaluators wrote, "One of the major initial design goals for Windows NT was to assure C2-level security through an integral, uniform protection mechanism. All system resources are treated as objects, and thus a single security 'gate' can be the protection component that all users must pass through to acquire system resources.

"This results in much greater assurance that the system meets the applicable security criteria, because a single security mechanism is easier to understand and to verify then multiple ad hoc mechanisms. When security is not an absolute requirement of the initial design, it is virtually impossible through later add-ons to provide the kind of uniform treatment to diverse system resources that Windows NT provides."

For more information on the security design of Windows NT, see Microsoft Windows NT 3.5 Guidelines for Security, Audit, and Control, published by Microsoft Press, and the Microsoft Web Server.

Domain-naming Conventions

When planning your domain, consideration needs to be given to the names of the domains. Once implemented, it is recommended that domain names not change. Changing domain names requires the reinstallation of every server that belongs to the renamed domain. For clarity, use domain names that reflect of the general business areas they serve.

Group-naming and Assignment Conventions

A corporation could create a global group for every resource domain. That group could include all those who use that domain as their primary resource base. Other global groups could be created for all departments or locations, and the members of each department could automatically be made members of their department groups. The group name should reflect the domain and the department For example, a Microsoft department in England might be named Mic-UK. Other groups may be created for job categories, such as Mic-UK-Managers.

Username Conventions

Ideally, one user ID and password would allow access to all of a user's resources. Microsoft Client Services for NetWare passes Windows NT usernames and passwords to NetWare. To take advantage of this, set up a user account on NetWare with the same account name and password as in Windows NT. Banyan VINES systems can also be configured in this way by setting the VINES username and password to match the ones in Windows NT and NetWare. Upon logging on, the user will also be logged on to VINES.

For details about configuring for Banyan VINES on a Windows NT network, see Chapter 5, "Network Services: Enterprise Level."

If the user's password cannot be sent to other systems, the next best thing is to have a consistent full-name property within each company organization.

Tools and Checklists for Domain Planning

For ease of administration, the preferred domain model is the single-domain model. If the single-domain model can not be used, the second choice should be the single master-domain model. If neither of these is acceptable, an administrator can use trust relationships to centralize all user administration into a single domain, eliminating the need to administer each domain separately.

The following sections contain tools and checklists to help you choose the proper domain model for your organization.

Domain Selection Matrix

It is useful to view the characteristics of the domain models side by side, to match the characteristics and benefits of each implementation model to the needs of your organization. If the needs of your organization change, you can review this matrix to determine the optimal implementation model.

If you have already established an implementation model, it is a good idea to review the following chart to see the benefits or trade-offs of other domain models.

Domain AttributeSingle DomainSingle Master DomainMultiple Master DomainIndependent Single Domains with Trust relationships

Fewer than 40,000 users per domain

X

X

X

 

More than 40,000 users per domain

 

 

X

 

Centralized account management

X

X

 

 

Centralized resource management

X

 

X

X

Decentralized account management

 

 

X

X

Decentralized resource management

 

X

X

 

Central MIS

X

X

 

 

No central MIS

 

 

 

X

*User account numbers are approximate. The exact SAM file size is dependent on the number of user accounts, computer accounts, and group accounts. 

Location Considerations Checklist

Determine the location of the user community using the following checklist.

Where will users log on?

Ensure adequate access to an authenticating BDC. 

Do users need to be able to log on from more than one location?

If so, their accounts cannot be tied to a location. Consider using a single master-domain or multiple master-domain model. 

What resource availability is required? 

Does a user need to be able to log on even when the WAN to the central location is down?

Or, is all data central, so that no local processing can be done without the WAN? 

How fast are the WAN links?

The speed of the links needed between locations should be determined by the resource usage across the links and by the frequency of changes to settings for users and groups. 

Hardware Requirements

When selecting a computer for use as a PDC or BDC, use the hardware guidelines in Table 2.7, below. The table assumes that the computers will function only as PDCs and that no other major Windows NT operations will occur, such as moderate file server, SQL server, SNA server, and remote access server. All numbers are in megabytes (MB) and it is assumed that the computer's pagefile size is at least 250 MB.

# of User AccountsSAM SizeRegistry SizePaged PoolMinimum CPU NeededPagefileRAM

Fewer than 3000

5

25 (default)

50 (default)

486dx/33

32

16

7500 (default)

10

25

50

486dx/33

64

32

10,000

15

25

50

Pentium, MIPS, Alpha AXP

96

48

15,000

20

30

75

Pentium, MIPS, Alpha AXP

128

64

20,000

30

50

100

Pentium, MIPS, Alpha AXP

256

128

30,000

45

75

128

Pentium, MIPS, Alpha AXP

332

166

40,000

60

102

128

SMP

394

197

50,000

75

102

128

SMP

512

256

For more information, refer to Large Domain Testing Overview, available from Microsoft Product Support Services.

Number of Domains Necessary

The number of users in a domain is a function of the size of the directory database. Figure 2.11 can help you determine the number of domains you need. The single-domain model and the single master-domain model can accommodate at least 26,000 user accounts if both user accounts and computer accounts are stored in the database.

Built-in local groups for a domain include Administrators, Domain Admins, Users, Domain Users, Guests, Domain Guests, Account Operators, Backup Operators, Print Operators, Server Operators, and Replicator.

 Factors 

Calculating SAM database size 

Number of users, multiply by 1KB

A
KB

 

Number of machines , multiply by 0.5KB
(workstations, servers, printers, etc.)

B
KB

 

Number of custom groups, multiply by 4 KB

C
KB

 

Built-in local groups

D
44KB

 

Total SAM size: A + B + C + D =

E
KB

 

Convert SAM size to MB, multiply E by .001024

F

 

Minimum # of domains = F / 40* (round up to the next whole number

 

* Maximum recommended SAM Database size is 40 MB. 

Figure 2.11 Job aide to calculate the number of master domains 

Number of Trusted Domains

In the multiple master-domain model, user accounts are stored in master domains, and resources (machine accounts) are stored in all other domains. In this model, each resource domain trusts all master domains with a one-way trust.

On each domain controller in the resource domain, the existence of the trust relationship is represented by an LSA trusted-domain object. The object contains the name of the trusted domain and the domain security identifier (SID). The password associated with the trust link is stored in a LSA secret object, which is stored in the following registry key.

HKEY_LOCAL_MACHINE \Security \Policy \Secrets 

In the Windows NT operating system, LSA secrets are used for other things and, until this version, the number of LSA secrets was fixed at 256. As a result, the recommended limit for trusted master domains was 128 per resource domain. This recommendation has been removed with the introduction of Windows NT 4.0 because the number of available LSA secrets has been significantly increased.

The second restriction limiting the number of master domains trusted by the resource domains is the nonpaged pool size of the domain controllers on which the resource domains are stored. When a domain controller starts, it attempts to discover domain controllers in each trusted domains by sending a message to each trusted domain. Each domain controller in the trusted domains responds with a message to the starting domain controller. The response is temporarily stored in the nonpaged pool until NetLogon can read it.

The RAM on your Windows NT computer is divided into two categories: nonpaged and paged. Nonpaged must stay in memory and cannot be written to or retrieved from peripherals. Peripherals include disks, the LAN, CD-ROMs, and other devices. Paged memory is RAM that the system can use and later reuse to hold different pages of memory from peripherals.

For more information on memory, see the Microsoft Windows NT Workstation Resource Guide, Chapter 12, "Detecting Memory Bottlenecks."

Windows NT Server 4.0 provides a default nonpaged pool size, which provides for a substantially higher number of trusted domains than earlier versions did. Table 2.8, below, lists the default nonpaged-pool size that is configured when Windows NT Server is installed on computers with different amounts of physical memory. The table also shows the recommended maximum number of trusted domains that will operate, based on the specified nonpaged pool size.

Nonpaged Pool Size# of Trusted DomainsTotal Physical Memory

1.2 MB

140

32 MB

2.125 MB

250

64 MB

4.125 MB

500

128 MB

Calculating Required Nonpaged and Paged Pool Sizes

Nonpaged and paged pool sizes are calculated from the physical memory on the computer when it starts up. Although the default nonpooled size is sufficient in most cases, you can approximate the values for an X86-based computer if you find it is necessary to change the nonpaged and paged pool size of your computer.

TermValue

Minimum Nonpaged Pool Size

256K

MinimumAdditionNonPagedPoolPerMb

32K

DefaultMaximumNonPagedPool

1MB

MaximumAdditionNonPagedPoolPerMb

400K

Pte_Per_Page

1024

Page_Size

4096

Calculating Nonpaged Pool Size

NonPagedPoolSize = MinimumNonpagedPoolSize + ((Physical MB-4) * MinAdditionNonPagedPoolPerMb) 

Example: On a 32 MB x86-based computer

MinimumNonPagedPoolSize = 256K
NonPagedPoolSize = 256K + ((32-4) * 32K) = 1.2 MB

MaximumNonPagedPoolSize = DefaultMaximumNonPagedPool; + ((Physical MB-4) * MaxAdditionNonPagedPoolPerMb 

IF: MaximumNonPagedPoolSize < (NonPagedPoolSize + Page_Size * 16)
THEN: MaximumNonPagedPoolSize = (NonPagedPoolSize + Page_Size * 16)
IF: NonPagedPoolSize >= 192 MB
THEN: NonPagedPoolSize = 192 MB

Example: On a 32 MB x86-based computer 

MaximumNonPagedPoolSize = 1 MB + ((32 - 4) * 400K) = 12.5 MB 

Calculating Paged Pool Size
Size = (2 * MaximumNonPagedPoolSize) / Page_Size
Size = (Size + Pte_Per_Page - 1)) / Pte_Per_Page
PagedPoolSize = Size * Page_Size * Pte_Per_Page
If PagedPoolSize >= 192 MB PagePoolSize = 192 MB

Example: On a 32 MB x86-based computer 

Size = (2 * 12.5 MB) / 4096 = 6400
Size = (6400 + (1024 - 1)) / 1024 = 7.25
Paged Pool Size = 7.25 * 4096 * 1024 = 30 MB

Note If both the nonpaged and paged pool values are set to zero in the registry, then the paged pool size will approximately equal the memory size.

Changing Nonpooled and Pooled Page Size

Nonpooled and pooled page values can be changed in the registry. The page pooled memory management parameters are located in the following registry key.

HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Control \Session \Memory Management Manager 

Warning Using the Registry Editor incorrectly can cause serious, system-wide problems that may require you to reinstall Windows NT to correct them. Microsoft cannot guarantee that any problems resulting from the use of the Registry Editor can be solved. Use this tool at your own risk.

Increasing the size of NonPaged pool consumes physical memory that cannot be used for any other purpose.

Increasing the number of trusted domains increases the datagram traffic from each domain controller in the trusting domain.

Number of BDCs Necessary

The ratio of workstations to servers in a domain is a way to maintain responsiveness during logging on. More BDCs (also called domain servers) permit more users to log on simultaneously. One BDC can support up to 2,000 user accounts. The server configuration in Table 2.10 is for a 486/66 computer with 32 MB of RAM, running Windows NT Server.

Number of workstationsNumber of BDC servers

10

1

100

1

500

1

1,000

1

2,000

1

5,000

2

10,000

5

20,000

10

30,000

15

It is a good idea to perform the initial setup of all BDCs on site or over high-speed links because each new BDC will need a full synchronization with the PDC. Many companies set up their BDCs at the same site as the PDC and then ship them to their intended locations. This is the most efficient method for sites that have only low-speed or RAS access.

Microsoft Corporation Worldwide Network Background

Microsoft currently has approximately 16,000 user accounts and 35,000 network nodes worldwide. The Microsoft staff is evenly divided: About half the employees are located at or near the Redmond, Washington campus, and the rest are distributed among approximately 150 sites in 52 countries. All sites require full access to information and electronic mail.

In order to fulfill the goals of worldwide access to corporate information and to demonstrate its commitment to Windows NT Server technology, Microsoft designed its worldwide network around the Windows NT domain structure. The Microsoft worldwide-domain strategy includes the following goals.

Optimum availability to all Microsoft sites 

Centralized support and administration 

The ability to recover from an extended WAN link interruption without requiring a full synchronization of the SAM to the PDC 

To meet these goals, the Microsoft Information Technology Group (ITG) implemented a multiple master-domain model. The plan uses a relatively small number of first-tier, master-account domains (which are administered by ITG) and strategically placed PDCs and BDCs, to provide optimum availability and performance.

Many sites are connected to the network by (slower) 64K links. These are not yet cost-effective to upgrade and upgrades are not available in some locations. When requested, ITG will provide administration of second-tier domains.

Microsoft ITG worked to keep the number of master account domains as small as possible in order to achieve the following objectives.

To keep administration centralized 

To make global groups feasible 

Microsoft ITG chose to limit the number of departmental, site, and developer server domains because it is easier to divide large domains than to combine many small ones into a larger domain when needed. For example, there is one ITG-NETWORKS domain. All servers for the Corporate Networks department are maintained in this domain.

Implementation

Because every user and global group account in the company exists in one of the master-account domains, and because all domains trust every master-account domain in the company, every user and global group account in the company is functional in all domains.

In all cases, ITG has full administrative permissions on all the domains in the model. All domain controllers can be backed up, restored, and updated with current builds and new system-configuration files.

There are some disadvantages to the multiple master-domain model. The most challenging issue is administration of individualized global groups. Managing global groups becomes impractical unless it can be based on a database, against which data can be compared. In this way, a group would automatically be updated if an individual no longer requires membership in that group. ITG provides global groups (based on department accounts) and updates membership (based on HR records). Other global groups are reviewed by case. Users are added to a master-account domain based on their current geographic location. If a user moves to a different site within Microsoft (such as from Redmond to Northern Europe), the user will be removed from and added to the appropriate master-account domains. When the user account is recreated in another domain, the account SID changes, so account permissions must be reapplied.

Windows for Workgroup systems belong to a second-tier domain to ensure that they have full access to the domain model. They use their account on the master account domain and use the second-tier domain as their workgroup. This allows access to domain servers that are using Windows NT security.

All Windows NT Server-based systems running RAS are located in a second-tier domain. Because there is a trust relationship between all domains in the corporate model, a user can dial into a RAS server anywhere in the model without additional administration.

Administration

ITG has sole authority to establish a trust relationship between the master domains and another domain on the Microsoft corporate network. ITG can administer all servers running Windows NT Server in a trust relationship within the Microsoft domains structure. Microsoft ITG uses the following criteria to establish a trust relationship with a second-tier domain.

Any product-development group is eligible to create one second-tier domain with trust relationships to the master account domains until every defined development business unit has a second-tier domain.

For example, Apps-Word, Apps-Excel, Sys-WFW, or Sys-WinNT are second-tier domains. 

Every site outside the Redmond campus is eligible to create one resource domain with trust relationships with the master account domains.

For example, USA-Atlanta, USA-Chicago, FRA-Paris, and GER-Munich are resources domains. 

ITG uses a standard administrative account that is part of the second-tier Domain Administrators group.

This enables ITG to perform administrative duties and assist the domain administrator when needed. It also enables ITG to perform backups of domain servers. 

The Microsoft Worldwide Domain Model

Master-user account domains contain all user accounts for the worldwide domain structure. Master-account-domain names represent the user's geographic location, to assist in distribution of BDCs.

 

Figure 2.12 Microsoft worldwide domain model 

The Microsoft network acknowledges two categories of administration. ITG is solely responsible for administration of some domains. Other domains are jointly administered by ITG and specific user groups, such as developers, sites, and others. Domain-administration permissions can be given to a group of users within their second-tier domain. ITG retains the option of allowing any of the departmental-server domains to have both their own domain administrators and ITG administration.

Domain Controller Locations

ITG provides master-account domains (first-tier), which are used by a specific set of sites. The name and size of these master-account domains are determined by geographic limitations, network topology, and the number of accounts to be supported. The PDC for the Redmond, NorthAmerica, and SouthAmerica master-account domains are located in Redmond. Others are located near the constituent users, where local data centers provide administrator resources. A BDC for the master-account domain is located at each remote site, for authentication of accounts at that site.

The European master account domain PDCs are in England, with a BDC for each European master account domain at each respective site.

Worldwide, a BDC for the global master account domain is also located at each network hub site.

Special Domain Considerations

Microsoft maintains two domains that, for security, have restricted access to and from the other domains. The groups using these special domains are the Microsoft Human Resources group and vendors who do business with Microsoft.

The Human Resources department maintains a secure network because of the confidential nature of its information. The HR master domain is isolated from the other domains on the network and is separately wired, so that it is not physically connected to the other network.

Vendors use the servers in the second restricted domain as a drop-off point. Microsoft employees can access the domain through a one-way trust relationship, but vendors are restricted to the vendor domain.

WAN Protocols

On the Microsoft corporate network, TCP/IP is used by Windows NT Server to forward authentication requests between domain controllers across a WAN. Every server in the master account domain can process logon requests from the domain user accounts.

Dynamic Host Configuration Protocol

Every server in the corporate domain runs TCP/IP. Adding Dynamic Host Configuration Protocol (DHCP) to the Microsoft network has significantly reduced administrative overhead for WAN management because individual machine TCP/IP addresses are configured automatically by DHCP.

Naming Conventions

Microsoft devised a naming convention for the corporate-domain structure to provide a consistent, worldwide interface to its users. The naming convention for second-tier domains is based on geographic location (USA-Atlanta), business (ITG-Networks), or development group (Apps-Word).

The following table shows some of the current domains. The rule is to use {division}-{department}. Another factor in establishing the domain name is to encompass the largest practical group.

Site domains are determined by {country code}-{city name}. Every site is permitted one resource domain in the corporate domain model.

Table 2.11 Microsoft first-tier and second-tier domain names 

REDMOND

FAREAST

NORTHERNEUROPE

SOUTHPACIFIC

AFRICA

MIDDLEEAST

SOUTHAMERICA

 

CENTRALEUROPE

NORTHAMERICA

SOUTHERNEUROPE

 

APPS-EXCEL

FRA-PARISEHQ

OPS-FACILITIES

SYS-BUSINESS

APPS-MULTIMEDIA

GER-BERLIN

OPS-MSPRESS

SYS-HARDWARE

APPS-POWERPOINT

GER-MUNICH

POL-WARSAW

SYS-MARKETING

APPS-WORD

ITG-APPS

PSS-BP

SYS-MSDOS-WIN

AT-RESEARCH

ITG-DEVELOPMENT

PSS-LP

SYS-WINNT

AUT-VIENNA

ITG-NETWORKS

PSS-RWG

USA-ATLANTA

FIN-ACCTSVRS

ITG-SQL

SWI-NYON

USA-DENVER

Troubleshooting Problems

This section discusses categories of typical problems users might face, such as the following situations.

Problems viewing a server's shared resources 

Problems accessing a shared resource 

BDC failure to authenticate a user's password 

Problems caused by multiple PDCs in a domain 

Problems created by special characters in the domain name 

Viewing a Server's Shared Resources

Suppose an employee named AnnM logs on to a Windows NT domain with her password, Yippee. She wants to view the shared resources on a server named \\Products, but her password there is Hooray. Ann will see the following message on screen:

Error 5: Access has been denied. 

AnnM asks the administrator of \\Products to change her password, but the administrator leaves the User Must Change Password At Next Logon check box selected. When AnnM tries again to view the server's shared resources, she will see the following message displayed on the screen:

Error 2242: The password of this user has expired. 

When the administrator of \\Products clears the User Must Change Password At Next Logon check box, AnnM will be able to see the server's shared resources.

Accessing a Server's Shared Resources

Two examples help explain some access issues.

Suppose another employee, JeffH, wants to access a shared directory on \\Products but has no account on that domain. He is allowed access to this resource through the Guest account for \\Products and receives the associated permissions. 

Suppose AnnM is logged on to a Windows NT domain with the password Yippee. She wants to connect to the shared directory on \\Products, where her password is Hooray. Because there is an account for AnnM, she is not allowed to gain access by using the Guest account. Instead, Windows NT prompts AnnM for the valid password on \\Products. 

BDC Failure to Authenticate the User's Password

If the computer being connected to is a BDC for the domain in which the user account is defined but the BDC fails to authenticate the user's password, this indicates that the password has changed but the BDC is not synchronized at the time the user logs on. In this case, the BDC passes the logon request through to the PDC in the same domain.

As a precaution, users who change their passwords should log on to all computers to which they have access within about 15 minutes of making the change. This ensures that the cached credentials are up-to-date on each machine and that the user will be able to log on with the cached credentials even if the PDC is unavailable during logon.

Avoiding Multiple PDCs in a Single Domain

Do not configure multiple PDCs on a single domain. The following scenario is an example of the problems involved.

Suppose a system administrator installs a computer running Windows NT Server. The computer is called \\Main_unit, which is designated during installation as the PDC of a domain called MyDomain.

Later, the system administrator shuts down \\Main_unit and turns off. Then, the system administrator installs another server, called \\Second_unit, which is also designated as the PDC for MyDomain. Because \\Main_unit is not currently on the network, the original MyDomain is not known, and the installation of \\Second_unit and creation of MyDomain proceeds without error. The two domains are not identical; they have different Security IDs.

When the system administrator turns \\Main_unit on again, the NetLogon service discovers another PDC on the network. NetLogon fails, and \\Main_unit can no longer participate in the domain.

The system administrator now has a serious problem. It is not possible to simply demote \\Main_unit from a PDC to a BDC and continue. The Security ID (SID) for \\Main_unit will not be recognized by the current PDC, \\Second_unit, and \\Main_unit cannot join MyDomain in any capacity.

This situation happens because a unique domain SID is created whenever a PDC is created. All BDCs and user accounts within the domain share this domain SID as a prefix to their own SIDs. When \\Second_unit is installed as a PDC, its SID prefix is different from the \\Main_unit prefix, and the two computers can never participate in the same domain.

The system administrator cannot change the name of \\Main_unit and rejoin MyDomain because the SID is fixed when Windows NT Server is installed. If \\Main_unit is to be the PDC of MyDomain, the system administrator must shut down both \\Main_unit and \\Second_unit, start up \\Main_unit, and then reinstall Windows NT Server on \\Second_unit, designating it as a BDC during setup.

To avoid this problem, \\Second_unit should be installed as a backup domain controller while \\Main_unit is running. Then, if \\Main_unit is taken offline, \\Second_unit can be promoted to PDC. When \\Main_unit is ready to go online again, \\Second_unit can be demoted to a BDC. The SID for \\Main_unit is recognized by \\Second_unit. When \\Main_unit is restarted, it becomes the PDC again.

(In general, it should not be necessary to designate a new PDC unless the original PDC is going to be down for a long time.)

Special Characters in Domain Names

The following special characters are illegal in domain names (in addition to * and space).

#define ILLEGAL_NAME_CHARS_STR TEXT ("\"/\\[]:|<>+=;,?") CTRL_CHARS_STR

Even though some special characters such as period (.) are valid, underscore (_) and dash (-) would be better choices as special characters in domain names.



© 2015 Microsoft Corporation. All rights reserved. Contact Us |Terms of Use |Trademarks |Privacy & Cookies