To implement directory services, a network designer will need to perform the following tasks:
As the slide indicates, the rest of the session provides the concepts, components, and hands-on experience to prepare network planners and administrators to use Windows NT Server Directory Services to meet these challenges.
At the end of this section, you will be able to:
Domains act as the building blocks for Windows NT Server Directory Services by supporting communications and administration across an enterprise network.
Because domains provide the foundation for directory services, it is essential for network planners to understand their functions in the directory services environment.
Windows NT Server Directory Services can be implemented in four different domain structures:
As the name implies, there is only one domain.
This involves one domain for accounts (the master) and any number of resource domains.
This model includes more than one master domain along with any number of resource domains.
Trusts connect every domain in this model with every other domain in the model.
This module discusses the details of each domain structure and the considerations involved in implementing the appropriate structure as part of Windows NT Server Directory Services installation.
The network planner should keep the following considerations in mind while planning a directory services domain structure:
Caution Remember, a user account should be defined only once in the network. If this rule is not followed, the same user account name will have two or more different SIDs. This can cause administrative inconsistencies when assigning permissions or user rights. It can also cause problems for users having to maintain duplicate accounts in order to access resources.
Note Module four, Planning Your Directory Services Structure, examines planning a Windows NT Server Directory Services installation in extensive detail.
In the single domain model, Windows NT Server Directory Services assure the "one user, one account" concept by bringing all the accounts and resources together into one administrative unit. Any user, logging on only once, will be able to access any resource for which he or she has appropriate permissions. Administrators that have the appropriate permissions will be able to manage any resource, no matter which resource it is or where in the domain it is located.
The single domain model consists of only one domain, with one primary domain controller and one or more backup domain controllers. A single domain model is most appropriate in the following situations:
In this implementation of directory services, the number of users and groups depends on the number of servers in the domain and the server hardware.
The single domain model does not use trust relationships; all users and groups reside in the one domain.
The following table summarizes the single domain model:
Advantages |
Disadvantages |
Best model for many companies. |
Poor performance if the domain has too many users and groups for the domain controller's hardware. |
Centralized management of user accounts. |
No groupings of users into departments. |
Centralized management of resources. |
No grouping of resources. |
No management of trust relationships necessary. |
Browsing is slow if domain has a large number of servers. |
In the master domain model, Windows NT Server Directory Services use trusts to implement seamless communication between domains, thereby making the "one user, one account" concept a reality even between domains.
The master domain model consists of at least two domains. Each domain has its own domain controllers, but all account information is kept on the master domain controllers. The master domain model offers the following benefits:
The master domain model would be appropriate in a situation where a company has developed a complex assortment of divisions and departments, each wanting its own separate resource management, but still requiring centralized account management.
The following table summarizes the master domain model:
Advantages | Disadvantages |
|---|---|
Best choice for companies that do not have too many users relative to the hardware and must have shared resources split into groups for management purposes. |
Poor performance if the domain has too many users and groups for the hardware. |
User accounts can be centrally located. |
Local groups must be defined in each domain where they are to be used. |
Resources are grouped logically in resource domains. |
Local administrators of trusting domains rely on master-domain administration to supply current and secure global groups. |
Resource domains can have their own administrators who manage the resources in the domain. |
|
Global groups need to be defined only once (in the master domain). |
The master domain is a trusted domain. All other domains are trusting domains linked to the master by one-way trust relationships.
The master domain model splits the network into two different areas of administration:
Only the domain controllers in the master domain have copies of the master domain account database. In addition to the primary domain controller, there should be at least one backup domain controller in case the primary domain controller goes off-line.
Windows NT Server Directory Services use groups in the master domain model for efficiency in communications between domains.
Local and global groups are part of the master domain model. Global groups are important in the master domain model because they are the only groups which can be accessed outside of the domain where they were created.
To simplify administration, a resource domain administrator can place global groups from the master domain into local groups in the trusting domains. When global groups have been added to local groups, the master domain administrator has to add a user to only the global group to give the user access to the local groups' domain resources.
To illustrate how global and local groups work together in the master domain model, suppose an SNA Server administrator wants to simplify the task of assigning permissions to SNA Server which is in a trusting domain. The Windows NT Server administrator can create a global group in the master domain called SNAUsers. Then, the administrator could add to this group all the users that need access to SNA Server.
The administrator can add the SNAUsers global group to a local group in each trusting domain and then grant the local group permissions to SNA Server.
Because SNAUsers is a global group, not only is it available across trusts, but all the accounts that need access to the SNA Server can be managed from one global group in a master domain rather than in multiple local groups in each trusting domain.
This example illustrates how the entire network and all its domains and groups can be managed from one computer.
Windows NT Server Directory Services are able to maintain one account for each user in the multiple master domain model by extending the concepts of the Master Domain model to several master domains. In this model, accounts are distributed among more than one master domain, and the directory services use trusts to support communications between them. If the trusts are implemented correctly, a user can log on from any domain because pass-through authentication will send the request to the user's home domain for validation.
For large companies that want centralized administration, the multiple master domain model might be the best choice because it is the most scalable.
Each network user account is created in one of the master domains. Other domains in the network are resource domains, which are typically created at the department level.
The multiple master domain model is the best choice for large companies that require multiple administration units spread across the company. With this model, each administrative unit has control of its own accounts. Administrators for each domain can create users and groups and manage those accounts within their own domain.
In a large corporation, for example, Marketing, Sales, Manufacturing, Finance, and other major departments, may want their own administrators to manage the users and groups in their own departments. A multiple master domain model will support this type of corporate structure.
The following table summarizes the multiple master domain model.
Advantages |
Disadvantages |
This might be the best choice for companies with many users and a centralized MIS department for accounts. |
Both local and global groups might have to be defined multiple times. |
Scaleable to networks with any number of users. |
More trust relationships to manage. |
Resources are grouped logically. |
Not all user accounts are located in one domain. |
Department domains can have their own administrators who manage the resources in the department. |
Each master domain is linked to every other master domain by two-way trusts. All of the resource domains trust each of the master domains, but they do not have to trust other resource domains. With this approach, a single administrator is still able to manage the entire network from one location.
As in the other models, each user account is defined only once. Because every user account in the model exists in only one of the master domains and all domains in the model trust every master domain, every user account in the model is available to all domains.
Users log on to the master domain that contains their account. Each master domain should contain two or more Windows NT Server domain controllers (for redundancy) to validate user logons. After logging on to their master domain, users can access any resource for which they have permissions. This extends to any domain in the network because all resource domains trust all master domains.
The following formula can be used to find the number of trusts in a multiple master domain model.
M*(M-1)+(R*M) where M is the number of master domains and R is the number of resource domains.
Using the network pictured in the slide as an example, with two master domains and three resource domains, the formula would be filled out as follows: 2*(2-1)+(3*2). This would equal 2*1+6 which would equal 8. This is the number of trusts in the network pictured in the slide when it is understood that the two-way trust connecting the two master domains is actually two one-way trusts.
The number of trusts can be a factor in determining an appropriate domain structure, because structures with the fewest number of trusts are generally considered to be the most efficient and easiest to maintain.
Global groups require more planning in this model than in the master domain model. For example, if a local group needs to contain groups from two or more master domains, a global group must be created in each master domain. These global groups are then made members of the local group.
To illustrate how global and local groups work together in the multiple master domain model, an SQL Server administrator will use groups to assign access to resources on an SQL Server in a trusting domain.
First, the domain administrator creates a global group for SQL in each master domain. The names of the global groups indicate their purpose and the master domain in which they were created, such as DomASQL, for the SQL group in Domain A. The administrator adds all the users from Domain A needing access to the SQL Servers to the DomASQL global group. Then, the administrator adds the DomASQL global group to the appropriate local group in the trusting domains. The administrator repeats the process for each master domain.
New accounts that need access to SQL Server can simply be added to the SQL global group in their home domain.
To simplify implementing a multiple master domain model:
The Complete Trust model makes more extensive use of Windows NT Server Directory Services than any other model because this model uses trusts to implement two-way communication among all the domains in the network.
If you want the management of users and resources to be distributed among different departments, rather than be centralized, you might want to use the complete trust model. With this model, every domain on the network trusts every other domain; no single domain exerts control over the others. The complete trust model distributes the administration of users, groups, domains, and resources among different departments rather than centralizing it.
The following table summarizes the complete trust model:
Advantages |
Disadvantages |
Best for companies with no central MIS group. |
Because there is no central management of users, this model is not practical for companies with central MIS departments. |
Scalable to networks with any number of users. |
Very large number of trust relationships to manage. |
Each department has full control over its user accounts and resources. |
Each department must trust that the other departments will not put inappropriate users into global groups. |
Both resources and user accounts are grouped into departmental units. |
In the complete trust model, every domain in the network trusts every other domain. Each department manages its own domain and defines its own users and global groups. These users and global groups can be used on all domains in the complete trust model. For example, a global group created in Domain D is available to Domains A, B and C when using complete trust model.
The following formula will produce the number of trust relationships required to implement a complete trust:
n * (n–1) Where n is the number of domains.
For example, 4 domains require 12 trust relationships (4 x [4 – 1]), and 10 domains require 90 trust relationships. Adding a new domain to an existing network of 10 domains requires establishing 20 new trust relationships.
As mentioned earlier, the number of trusts can be a factor in enterprise management, because structures with the fewest number of trusts are generally considered to be the most efficient and easiest to maintain.
Caution Because there is no central administration in the complete trust model, users from other domains with access to resources could pose a security risk. This model requires a high degree of confidence in global groups from other trusted domains. When you give permissions to a global group from another domain (or place that global group in a local group in your domain), you are trusting the administrator of the other domain not to add any unauthorized or inappropriate users to that global group.
By the end of this section, you will be able to:
Achieving efficient network operations requires more than simply installing Windows NT Server and indicating whether a server is going to be a domain's PDC or a BDC. The network designer must also consider communication between:
In order to achieve optimum communication among servers and users, the network designer needs to create a system with the following characteristics:
Characteristic |
Details |
The appropriate number of controllers |
If the network does not have enough controllers (PDCs and BDCs), it won't be able to accommodate its accounts properly. Too many controllers, on the other hand, simply wastes resources. |
The appropriate location of the servers |
Knowing where to put servers can make the difference between an efficient network that serves its users as an effective business tool or an inefficient, assemblage of servers and workstations that has the potential to hinder business rather than help. |
Efficient Synchronization |
Synchronization makes wide-area network operations possible, but it has the potential to interfere with network operations at inconvenient times. Therefore, knowing how to implement the network so synchronization can take place as efficiently as possible is essential if the network is going to support users properly. |
Efficient Pass-Through Authentication |
Because authentication requests generate network traffic, they must be validated as efficiently as possible so as not to interfere with business communication. |
This module explores each of these areas and draws on concepts already presented to prepare a network designer to implement servers properly. This phase of implementing Windows NT Server Directory Services will produce the most efficient network possible.
In domain planning, determining the proper number of controllers (PDCs and BDCs) is a major issue. Considerations and questions a network designer will have to address include:
How many accounts can a domain store efficiently?
How should the domain controllers be configured?
What is the optimum number of master domains and where should they be located? Will there be one master domain or multiple master domains?
What is the optimum number of resource domains, and where should they be located?
What contributes to validation traffic?
A domain's accounts include:
Note: Only NT-based machines are entered into the database.
Each account is stored in the SAM (Security Accounts Manager) file as an object. A domain can support 40,000 accounts. This is a major criteria in choosing a domain model because it is involved in determining how many domains the network will need.
The practical limit for the size of the directory database depends on:
A 486/33 can not process as many simultaneous logon requests as a Pentium or RISC processor.
A machine with 16 MB can not effectively support as many users as a machine with 128 MB or more memory.
Although SAM files larger than 40 MB have been tested, Microsoft recommends an upper limit of 40 MB because SAM files larger than 40 MB may take several minutes to load into memory.
As the slide shows, different types of objects require different amounts of space in the SAM file.
The slide contains some examples of how objects might be distributed in a single domain.
A network designer can use the tables in this and the previous slide to determine the approximate size of the directory database. This is extremely useful when planning the number of Master Domains. If the SAM file will exceed 40MB, the network will probably need a multiple master domain model.
Note: The numbers in the table can be applied to domains that comprise a single master and multiple master domain
Use the following job aid to determine the amount of space used by groups. Complete for all groups in a domain: Local, Global and Built In.
Factors that affect the number of users a PDC can support include:
For example, a 486/33 with 16MB of memory can not effectively support the number of users that a Pentium, MIPS, Alpha AXP, or PowerPC with 128 MB of memory can support.
When selecting a computer for a PDC or BDC, use the guidelines presented in the slide:
PDC/BDC Hardware Requirements
SAM file size |
Number of User accounts* |
Minimum CPU Needed |
Recommended RAM+ |
|||||
5 MB |
up to 3,000 |
486DX/33 |
32 MB |
|||||
10 MB |
7,500 |
486DX/66 |
32 MB |
|||||
15 MB |
10,000 |
Pentium, MIPS, Alpha AXP |
48 MB |
|||||
20 MB |
15,000 |
Pentium, MIPS, Alpha AXP |
64 MB |
|||||
30 MB |
20,000 - 30,000 |
Pentium, MIPS, Alpha AXP |
96 MB |
|||||
40 MB |
30,000 - 40,000 |
Pentium, MIPS, Alpha AXP |
128 MB |
|||||
*User account numbers are approximate. The exact SAM file size is dependent on the number of user accounts, computer accounts, and group accounts.
The number of Master Domains to configure for a network is based almost entirely on two items:
The total number of users impacts the number of master domains because domains are generally limited to 40,000 users. A network that must accommodate 50,000 users, for example, will need more than one master domain.
To illustrate how planning for master domains should focus on administrative units, suppose a company wants to implement a master domain model with administrative units located in the following areas:
The simplest design would incorporate three Master Domains, one for each administrative unit. This would give each administrative unit control of user accounts in a particular area unless one of the domains had more than 40,000 users, in which case the crowded domain could be split into two master domains.
The job aid in the slide will help determine the correct number of master domains for a network. Notice that the number of users in a domain is a function of the size of the SAM database.
Note 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. Only NT-based computers count in these calculations.
Illustrate how domains are created to reflect a company's organization: a large company might have domains for research, marketing, human resources. The key is the administrative structure of the organization.
The planning and implementation of Master Domains depends on the administrative structure of the organization being networked rather than physical locations.
In a large company, for example, the following departments, regardless of where they are physically located, might have their own domains:
Within a domain, the PDC should be situated in or near the heaviest network administrative and support activity so it can accommodate this traffic with the fewest delays.
In certain circumstances, you may choose to install the PDC on a smaller, less powerful computer than the BDCs. For example, your company's MIS department controls all user accounts. For management and backup purposes, MIS wants the PDCs to be located at headquarters in Europe.
The domain structure is based on geographical locations with master domains located in Asia, Europe, and North America. The BDCs located in Asia and North America will process almost all of the logon and validation requests from the resource domains. Because the BDCs in this environment do more work than the PDC, they should be faster, more powerful machines than the PDC.
The administrator will have to determine whether each department will be a separate resource domain. If a department has resources over which it wants to retain administrative control, then it may need its own domain. This approach, however, may create a network with a large number of resource domains. The alternative would be a network with a large master domain at the division or business unit level and fewer numbers of resource domains.
Each resource domain will require its own Primary Domain Controller. Additional servers within a resource domain may be configured as Backup Domain Controllers, but they can also be used as resource servers.
When a user accesses a resource domain, the PDC or a BDC in the resource domain contacts the master domain to validate the user. Therefore, placing Master Domain BDCs close to where users are located will decrease the amount of time it takes for the Master Domain to validate users accessing resource domains.
A BDC with the following configuration will support approximately 2,000 users:
The table in the slide is a guide to the number of BDCs required to provide logon validation of user accounts in Master Domains.
Note The table assumes there are no special demands on the BDCs which would require specifications other than those listed. In determining the number of BDCs a domain needs, the network designer should take into account the fact that BDCs can also be used as resource servers.
Some of the factors involved in determining the physical distribution of BDCs include:
A network designer should think of the networked organization in terms of sites. A site is a well-connected LAN—it may be divided into parts that are connected by fast links such as bridges and routers, but not asynchronous WAN links (slow links) such as T1, 56K, or ISDN.
Network sites often correspond to geographical locations such as London, Paris, or New York. As part of planning, a network designer should determine whether the networked organization is:
If different parts of the organization are connected by WAN links, the network designer will have to determine the effects of the links on network performance.
The speed and quality of WAN links may dictate the creation of domains and the placement of backup domain controllers.
When a WAN link is involved, a network planner needs to answer two questions to determine where to place a domain's BDCs.
A network designer's primary BDC planning considerations are:
Most users will need the fastest possible logon service and will also need efficient access to resources even if the resources are across a WAN link.
When links degrade network performance noticeably, the network planner should eliminate logon traffic across them by moving the BDCs to the location where most of the logons are taking place. A practical solution is for the network planner to place a BDC on each side of the WAN link so the pass through validation traffic is kept off the WAN link.
The network planner has to consider the cost of quick logons versus synchronization time across the WAN link. The planner needs to determine how much of the WAN link bandwidth is used for processing logon requests locally. If a BDC is placed at the remote site, how much of the bandwidth will be used by synchronizing the directory services database?
The communication that occurs between domains is governed by the NetLogon service. It is responsible for three functions which affect network performance:
Note Each Windows NT–based computer participating in the domain must be running the NetLogon and Workstation services.
A Microsoft Windows NT Server starts the NetLogon service by default. However, a network administrator can use the Server Manager or the Control Panel Services option to start or stop the NetLogon service.
Directory services database synchronization (replication) occurs when a PDC copies, or replicates, its directory database to the BDCs within a domain. The NetLogon Service controls the directory database synchronization process.
When synchronization occurs, the PDC announces that a change in the directory services database has taken place. A BDC then calls the PDC and requests the changes.
Full synchronization occurs when the PDC sends its entire directory services database to a BDC. Full synchronization occurs when bringing a new PDC online.
The change log controls whether a full or partial synchronization takes place. Each change entry is typically 32 bytes. The default size for the change log is 64K, which means it will hold approximately 2,000 changes. Each change will be represented by a version or serial number in the change log. When the change log becomes full, the change log wraps and overwrites existing version numbers. If the BDC sees that the last change it received has been overwritten, the BDC will initiate a full synchronization.
A partial synchronization occurs when the PDC sends only the changes in the directory services database that have occurred since the last synchronization. A full synchronization of the directory services database is not necessary when a PDC changes. The PDC keeps track of the synchronization level of each BDC, which allows the PDC to control the rate of partial synchronization.
The PDC sends a message announcing a change in the directory services database to only the domain's BDCs that need the changes instead of to all BDCs. These messages are sent to a subset of a domain's controllers in each pulse (the subset is defined by the PulseConcurrency parameter). This prevents all BDCs from responding simultaneously, which helps to reduce network traffic and also ensures that the PDC does not become overloaded by the BDCs.
Consideration should be given to the amount of traffic that account synchronization places on a WAN or RAS dial-up line. In particular, the network should avoid full synchronization across WAN links because the slow speed across the link will affect total network performance.
The network administrator can control different aspects of synchronization and, therefore, network performance, through several items in the Windows NT Server Registry.
Note The Registry items are summarized in Appendix A.
For more information on synchronization parameters, see Appendix B, "Registry Value Entries," in Volume 4 of the Microsoft Windows NT Resource Kit.
An important aspect of network administration is managing the amount of network traffic so that response time remains acceptable.
When the PDC is separated from BDCs by a WAN or modem link, the administrator can use the table to estimate the amount of data and time needed to replicate directory database changes.
A BDC uses the ReplicationGovernor parameter in the Windows NT Registry to increase the performance of domain synchronization over a slow WAN link. This requires both the BDC(s) and PDC to be running Windows NT Server 3.5x.
Adjusting the ReplicationGovernor is important because for each Windows NT Server 3.5x BDC, the ReplicationGovernor parameter defines:
Adjusting the ReplicationGovernor parameter has the following effects:
The ReplicationGovernor parameter can be added to the Registry of a BDC under the following key:
\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
To add this parameter, assign a type of REG_DWORD and a value from zero to 100 (the default is 100). This value defines a percentage for both the amount of the data transferred on each call to the PDC and the frequency of those calls. For instance, setting the ReplicationGovernor value to 50 will use a 64K buffer rather than the default 128K buffer. In addition, the BDC will have an outstanding synchronization call on the network for only a maximum of 50 percent of the time.
Caution Care must be taken in setting this value. If the ReplicationGovernor is set too low, synchronization might never complete. A value of zero will cause NetLogon never to synchronize, and the directory database can become completely out of synchronization. This parameter must be set individually on each BDC and should only be used when the PDC is a computer running Windows NT Server 3.5x.
It is theoretically possible to have different replication rates at different times throughout the day. A network administrator can implement this by adjusting the ReplicationGovernor parameter in the Registry and then restarting the NetLogon service from within a batch file that is scheduled by means of the AT command. Such a batch file could be created using the REGINI.EXE command from the Windows NT Resource Kit and would, for example, contain:
regini scriptfile
net stop netlogon
net start netlogon
The scriptfile would contain the full path in the Registry to the ReplicationGovernor parameter and the new value selected for it.
Note For more information, see the "Resource Kit Tools Help" (RKTOOLS.HLP) Help file of the Microsoft Windows NT Resource Kit regarding REGINI.EXE and creating script files for REGINI.EXE.
When a user attempts to access a resource in a trusting domain, one of the domain controllers from the trusting domain passes the request through a trust to the trusted domain to verify the user.
Because a validation request travels on the network cable, pass through authentication generates additional network traffic. If the domains are broken up geographically, and the validation request must cross links, the validation may also generate an increased number of time outs and retries. If the request must cross a slow link, network performance will suffer.
To reduce the amount of network traffic across WAN links, the administrator can place additional BDCs in strategic locations in the domains from which requests originate. This way, users can avoid links and be validated locally. Local validation is a good option for organizations that have large numbers of users who travel between the different locations.
Authentication can be modified to meet organizational needs. If most of the users will be accessing only one other domain on a regular basis, the network designer should consider placing BDCs in that domain only.
Synchronizing changes in the accounts database to BDCs will generate additional traffic across links. However, occasional synchronizing will not affect network performance as much as frequent log on and validation requests across the same links.