Some of the main topics in this chapter are
In Windows NT, the domain is a logical grouping of user accounts, user groups, servers, workstations, and printers. The domain is also the basic unit of administrative authority, and it defines the boundaries for what users can and cannot do. If you're planning on rolling out Windows NT Server to your enterprise--be it large or small--one of the first and most important decisions you will need to make is which domain model, or structure, to use. Making the correct choice up front has implications on security, network utilization, user experience, and support. Windows NT Server can be very unforgiving of changes to domain structure once installed. If you have to move domain controllers from one domain to another, for example, it's likely that you will have to reinstall Windows NT Server each time.
This chapter gives you the information you need to plan a Windows NT installation that gives you maximum flexibility while meeting your security, network, user, and support needs in an ever-changing technology environment. We'll review the domain models that Microsoft presents, as well as the many variations you have at your disposal. Then we'll review what criteria you should look at when planning your domains. Finally, we'll look at how best to place your domain controllers in your network to optimize for performance, cost, and fault tolerance.
NOTE: Windows NT also supports the concept of workgroups. A workgroup is used when you have a few workstations that need to share files and printers. A workgroup does not share a single administrative authority, and as such, each machine needs to maintain its own user and group account information.
To create a Windows NT domain, you need at least one server acting as a domain controller. The domain controller holds the information necessary to define the domain. Domain controllers come in two types: the Primary Domain Controller (PDC) and the Backup Domain Controller (BDC). The PDC is the first server created in a domain. It contains the Security Accounts Manager (SAM) database that defines the domain.
The SAM database residing on the PDC is the master copy for the domain. All changes to the SAM are done at the PDC. There can only be one PDC in a given domain. The PDC's principal role is to hold all information about the domain with respect to user accounts, user groups, and machine accounts. The PDC can also authenticate a user to the domain when that user chooses to log on from a Windows workstation. The domain that is defined by the PDC is identified by a unique Domain Security Identifier (Domain SID). After you build a PDC and create a domain, that domain, irrespective of name, is defined by its SID. This is why you cannot simply rename a PDC to move it to a new domain--it will still have the Domain SID of the old domain.
BDCs are read-only replicas of the PDC. The function of the BDC is to provide load sharing and backup of the SAM database. A BDC contains a copy of the SAM database, replicated from the PDC on a periodic basis. The BDC can be used to distribute the load of authenticating users to the domain. Because it contains a replica of the SAM database, it can also be "promoted," or manually converted to a PDC in the event that the PDC becomes unusable. You are not limited to the number of BDCs within your domain; however, there is a point of diminishing returns if you have too many BDCs within your network. That is, the more BDCs you have, the more time the PDC will spend keeping all of them updated. This can grow to consume a majority of available resources on the PDC. BDCs are useful for providing remote authentication of users in the event that your network is widely dispersed and uses lower-speed WAN links.
To discuss the selection of a domain model appropriate for your environment, we need to distinguish between the different types of domains. There are basically two types of domains defined by Microsoft. The two types differ only in function. There is no technical difference in the way you define these domains. Instead, they perform a logical function you assign to them, and the relationship they have with each other defines their roles. The first type is referred to as a Master Account Domain (MAD). The MAD's purpose is to keep user account and group information--it is the domain of authentication. Users log on to the MAD, even though they might be sitting at workstations residing in other domains. The other type of domain is referred to as a Resource Domain (RD). The RD is the domain that contains Windows NT workstation and server machine accounts. It is where the resources--such as applications or file and print services--reside.
Keep in mind that the functions provided by the MAD and the RD are only logical roles. Both these functions can actually exist in a single domain--you can have both accounts and resources within a single domain. Or, the role of MAD and RD can exist in multiple domains. (All these domain models are described in the following section, "Review of Available Domain Models.") The interaction between the MADs and the RDs is defined by the trust relationship. Trusts are defined by an administrator and allow for resources in one domain to be exposed to user accounts in another. In effect, the trust provides a pass-through authentication mechanism between domains. The word trust is key here, because in reality, user accounts in one domain--for example, the MAD--are trusted to use resources in another domain--the RD. Conversely, RDs are trusting of the users defined in the MADs to which the RD is bound.
Trust relationships are defined with the User Manager for Domains tool that is installed when you build a Windows NT Server as a domain controller. A trust between domains can be either one-way or two-way. A one-way trust is generally represented in Microsoft documentation by a single-headed arrow, and a two-way trust by a double-headed arrow. However, a two-way trust is simply two one-way trusts. An RD is trusting of the MAD if it has a one-way trust with that MAD (see Figure 6.1).
This figure shows an example of an RD with a one-way trust relationship to a MAD.
The MAD, which is represented in Figure 6.1 at the head of the arrow, is the trusted domain. That is, the MAD is trusted by the RD to allow MAD user accounts access to resources, and the RD is trusting of the user accounts that reside in the MAD.
The Windows NT Directory Services--also known as Windows NT's domain-based architecture--can be configured in a variety of ways to meet your technical and organizational needs. However, there are four basic models that you can use as starting points to creating a domain design:
All accounts and resources reside in one domain under the single domain model.
Accounts reside in the MAD and resources in the RD under the single master domain model.
Accounts reside in multiple MADs, and resources reside in multiple RDs under the multiple master domain model.
Hybrid ModelsThe four models previously illustrated represent the most common domain relationships. However, you are free within the bounds of Windows NT's architecture to create other domain models to meet your organization's needs. For example, one hybrid approach can be to add a level of hierarchy to a normal Single or Multiple Master model (see Figure 6.6). In this figure, the MAD called UserDom provides authentication services to the RDs called Accounting and Finance. The fourth domain called Corp Security has a one-way trust relationship with UserDom. Corp Security will be the only domain with authority to create user accounts in UserDom. Utilizing the one-way trust, users defined in Corp Security can be given access to resources in UserDom. In this case, the resources are user accounts. Corp Security can then ensure that no users defined in UserDom have administrative authority to create user accounts, but that users defined in Corp Security do have such authority.
This example illustrates only one of many possible variations on the four models previously listed. However, it's important to keep in mind that there is a limit to the value of tinkering with your domain model. Windows NT enables you to create as many abstract trust relationships as you can think of to accomplish your security or usability needs. At some point, though, you'll find that the administrative overhead of not only maintaining and supporting, but also understanding the need for, all the trust relationships will overwhelm any benefit they provide. Simplicity should not be undervalued when deciding on a domain model to meet your needs.
All MADs and RDs are two-way trusted with each other under the complete trust domain model.
Different combinations of the four standard domain models can be used to create a hybrid domain model.
Now that you know the basic domain models available, the next step is determining which one is right for you. Although you might be tempted to consider only the technical issues around choosing the right model, there are other "softer" considerations. For example, organizational structure and support philosophy are just as important. These considerations will ensure that the environment you build will meet the ultimate goal of providing your users with the tools they need to do their job in a robust and--no less important--supportable environment. Figure 6.7 illustrates the different influences on choosing a domain model.
Consider these factors when making your choice of domain model.
You will need to consider how your organization is structured before you decide which domain model will be the best fit. Specifically, is the organization aligned by function or by geography? Does each unit provide its own technical support, or is its support centrally maintained? Does each user group have its own distinct set of applications, or is there a core set available to all users? Does the organization change often, both in structure and in function? Here are some guidelines for choosing a domain model based on organizational considerations:
This domain model is designed to be organized by company function.
This domain model is designed to be organized by geography.
Your support structure might very likely be the biggest factor in the choice of a domain model. This is because Windows NT's administrative structure is by nature not very granular. The basic unit of administrative authority in Windows NT is the domain. A user defined as Domain Administrator or Account Operator for a domain has control over all users and resources in that domain. Windows NT does not support the concept of an administrator for a portion of the domain. It's very important, therefore, to look at how your support needs mesh with your domain model. For example, if you have a centralized support staff, then you will want to reduce the number of administrative domains you have to contend with. In this case, if your organization is small enough, the simplest model to administer would be the Single Domain. After that, the Single Master model provides a single point of user account administration, and some number of resources in very few RDs that would also have to be managed centrally.
If you have a highly decentralized support staff, or a mix of centrally maintained IT support and decentralized departmental support groups, you will need to consider a model that provides more granularity of administration. This means a greater number of domains. The Single and Multiple Master models provide centralized control at the user account level, while still enabling decentralized departments or support groups the capability to manage the servers and workstations residing in the RDs. At the extreme end of decentralization, the Complete Trust model provides the capability to make each domain completely autonomous--providing support of both user accounts and resources independent of any other domain. This model also makes it difficult to maintain consistency between domains, if any is desired, and requires close cooperation between the various support groups to ensure similar administrative practices.
After you have examined how your organizational structure and support practices
will impact your choice of domain models, you will need to mesh that against the
technical constraints of Windows NT and your environment. This is especially true
as you try to match your business requirements for the Windows NT environment against
real-world technical issues. Such issues include network bandwidth, limitations and
coordination of Windows NT security versus your business's security needs, and the
use of other Windows NT BackOffice services within your domain environment.
Your Network. Network bandwidth, or lack thereof, can
be the single biggest technical driving force in your selection of a domain model.
This is because Windows NT domain controllers require a reliable and sufficient amount
of network availability to perform such essential functions as replication of the
SAM between the PDC and all BDCs, workstation and user authentication, and logon
script processing. This becomes critical if you have BDCs and PDCs within a single
domain that are separated by many slow-speed links. The inherent delays in such a
network can prevent the domain controllers from ever completely synchronizing, especially
if many changes are made to the SAM at once.
For example, suppose that you need to add 3,000 new users to your domain at once. If you have BDCs connected to the network across slow or unreliable links, these changes might not be successfully sent to all BDCs. To make matters worse, if any BDC gets out of sync with the PDC by too much (approximately 2,000 changes), the BDC will require a new full synchronization of the entire SAM database, which in itself can be very network intensive.
If most of your corporate computing resources are located in remote branch offices, connected together via low-speed (for example, 64Kbps) WAN links, you will need to carefully consider which domain model you use to distribute those resources. For example, if you choose a Single Master, Multiple Master, or Complete Trust model, you will need to decide whether those remote office resources are part of a MAD or an RD. If they are a member of an RD, then by definition they need to authenticate to a MAD. If the domain controllers for that MAD are located across slow links, there might be significant performance issues for those users when they authenticate. You might need to co-locate a MAD BDC at a remote office to facilitate quicker authentication to the domain. Or, you might choose to employ a Single Domain model for the entire organization and locate BDCs for that single domain in every remote office. We'll discuss PDC/BDC deployment and networking issues in more detail later in this chapter in the section "Load Balancing and Optimization Authentication."
TIP: Here's a good rule of thumb to follow if you have Windows NT domain users located across slower (<64Kbps) WAN links. If you have more than five to ten users located on the remote end of those links, consider placing their authentication resource local to them. That is, put a BDC from the authentication domain in close network proximity to the remote workstations--either on the same physical segment or accessible via a high-speed medium such as Ethernet.
Security. Another important consideration when choosing a domain model is the level of security you require of your Windows NT resources. Your security needs should guide your choice of domain model, because each model provides a different level of control over users and resources. Trust relationships themselves enable you to extend the security parameters you've defined in one domain to any number of other domains. This can be both a benefit and a liability. If you implement good user account, resource, and file system security, then trusts enable you to extend the use of these resources to other domains. If your security measures are shoddy, or filled with holes and back doors, then trusts provide a way for more users in other domains to expose those flaws.
The first question you need to ask yourself is, "Which users need access to which resources?" For example, if all users need access to all resources and your network, and support and organizational requirements enable it, then the Single Domain model provides an easy solution. However, not all requirements can be met by this model, and that's when things start to get difficult.
Security experts will tell you that the more complexity you add to a system, the more unsecure that system is likely to become. This holds true for domains as well. The simplest and most manageable model from a security standpoint is the Single Domain model. This is because you have only one administrative authority to keep track of, only one set of domain account policies and audit rules, and only one user account database. This is fine if the Single Domain model meets your goals, but suppose that you need to implement RDs to provide your business users with some autonomy over their own servers. In this case, you need to establish a trust relationship between the two domains, and suddenly the complexity increases significantly. Not only are there now more places to enter the system, but you suddenly have two administrative authorities, potentially with two different sets of account policies, auditing rules, and user rights.
Now imagine that you have implemented a Multiple Master model with four MADs and hundreds of RDs. You suddenly have a multitude of different administrative authorities to contend with. And each of these can be administered by a different group. By virtue of the trust relationships, you are potentially exposing each of these domains to unauthorized access by another.
The bottom line is that trust relationships make managing a secure multidomain Windows NT environment a complex operation. The key to successfully managing such an environment was alluded to previously--you should always strive to simplify. If your business needs require you to support a large multidomain environment, then the next best thing you can do is to ensure that every domain that participates in your global model follows a set of minimum security standards that are implemented identically across the board. As with any technology implementation, consistency is the key to supportability. The difficult nature of trust relationships and domains make this point all the more critical.
NOTE: It's important to realize with this example that trust relationships provide a pass-through authentication function only. They are like a gateway between domains. They expose user accounts in one domain to the resources in another. It's up to you, the administrator, to use tools like User Manager for Domains to actually associate the appropriate policies and permissions to these foreign users and resources.
Until Windows NT supports a single distributed global directory service, as is planned with the Active Directory in the next major release of Windows NT Server, your best approach for ensuring security regardless of domain model is to choose the simplest model that meets your needs and maintains consistency throughout its implementation.
Incorporating Other BackOffice Services. The last area that might have an influence on your choice of domain model is your use of Windows NT BackOffice services, such as Systems Management Server (SMS) or Exchange. Because these services are tightly integrated into Windows NT Server, and particularly into Windows NT security, you need to be aware of the implications that your domain choice has on the correct functioning of these services. Principally, these products utilize service accounts to perform their tasks. A service account is a normal Windows NT user ID, generally with Domain Administrator privileges.
For example, in SMS this account is used by the services that run on a Windows NT Server as part of an SMS site. An SMS site is a hierarchical structure that is usually defined by a Primary Site Server and any number of Secondary Site Servers. Within a single hierarchy, all site servers need to use the same service account for them to communicate with each other. Now suppose that you have a number of domains that have trust relationships to a MAD, and others without. If those domains that are not trusting of the MAD want to participate in the SMS site hierarchy that you've established, they need access to the service account. For the service account to be available to all RDs, it needs to be exposed via a trust relationship. If those other domains want to participate in the SMS site hierarchy, they have to establish trusts with the MAD where the service account resides (see Figure 6.10).
Provide an SMS server access to the service account from an RD.
The same service account requirements in other BackOffice products such as Exchange require that you give consideration to your domain model when planning to roll out these products. You might find that a domain that previously wasn't trusting of a given MAD might have to be if you intend to provide users in that domain with BackOffice services.
After you've decided on a domain model, the next step is to decide how many domain controllers you will deploy--and where in your network--to support the model. This decision will be a function of the size of the domain, the costs of hardware and software, how much fault tolerance you need, and your network configuration. We'll also look at placing domain controllers for optimum authentication response, which can also affect how many domain controllers you plan on rolling out.
When you install Windows NT Server as a domain controller, you're asking it to perform a special task above and beyond basic file and print services. A domain controller is responsible for keeping a copy of the SAM database. A domain controller is required for a user to authenticate to a Windows NT domain. There are the special roles of the PDC--to maintain the master read-write copy of the SAM, provide synchronized updates to all BDCs within the domain, and perform changes to the SAM such as password resets, new user account creation, and account policy changes. To perform these tasks, you need to provide the domain controller with sufficient system resources. These resources include physical memory (RAM), processing power (CPU), and sufficient disk space to hold the SAM and related files. The amount of these resources required for your domain controller is a function of two main requirements:
The planned size of the domain is important to know because this drives how much RAM the server will need. For performance reasons, Windows NT Server needs to be able to keep as much of the SAM database in memory as possible. Each object that you define using User Manager for Domains or Server Manager requires an amount of memory. Table 6.1 shows how much RAM each object in the SAM requires.
| Object | Memory Used |
| User Account | 1K |
| User Group | ~4K |
| Machine Account | 500 bytes |
Using these numbers, you can determine how much memory will be required by the SAM. For example, if you anticipate a domain containing 4,000 users, 4,000 machine accounts, and 50 User Groups, this would require:
(4,000*1K)+(4,000*.5K)+(50*4K)= 6.2M of RAM
Microsoft recommends that the SAM database not grow larger than 75M. That constitutes a very large domain--some 12 times larger than what we calculated. If your domain requirements are such that the size of your SAM would be greater than 75M, you should definitely plan on adding domains and implementing one of the domain models that enables you to split user and machine accounts between multiple domains.
The 6.2M of RAM required for the SAM in the example is only part of the equation to determine how much RAM your domain controller will need. A PDC or BDC will also be performing user authentication or processing logon scripts, and can potentially be a file and print server, or application server for BackOffice or other services. Indeed, SMS Site Servers are required to be installed on a domain controller. Add to this the basic memory requirements of the Windows NT operating system itself, and you have a starting point for determining how much RAM your system needs.
Windows NT 4.0 Server running as a domain controller requires about 13M of physical memory just for operating system-related processes. So, for example, if you have a domain composed of the objects described previously, the SAM requires at least 6M of RAM. Add to that the 13M for the OS, and you're already at 19M. If you want to minimize the amount of paging Windows NT has to do, then you should consider no less than 32M for all domain controllers in this sample domain. This is because it's likely that you'll want to run other services on your domain controllers beyond the base operating system, such as RAS, IIS, WINS, or DHCP. In fact, even for smaller domains, it's probably a good idea to start at 32M of RAM and work upward. Given today's market for PC hardware, its commodity status, and the price of RAM, there is no reason to skimp on memory. Windows NT Server will only benefit from increased physical memory. When you do decide to have your server perform tasks other than domain-related ones, you'll be glad you didn't skimp.
In terms of scaling up your memory requirements for larger domains, when you get to about 10,000 users, you're going to want to have at least 64M of RAM on your domain controllers. Beyond that, a good rule is to double the RAM required each time you double the number of users. For example, with 20,000 users, you should have at least 128M of RAM.
If you plan on having your domain controllers perform other tasks like file and print serving or application serving, you will need to accommodate these needs as well. File services require RAM to cache recently used files for quicker access by the user. So if you plan to use your domain controller as a file server, you should add to your RAM estimates to accommodate the additional load. You should not consider running an application service that requires many system resources, such as SQL Server, on your domain controllers (especially on your PDC).
Related to RAM is Windows NT's use of page files for storing unused pages in physical memory. The minimum page file size should be twice the size of the amount of physical RAM you have on your server. On a system with 128M of RAM, this means that the minimum page file size should be no less than 256M. This leads to the issue of disk space.
There are no real requirements around the operation of a domain controller with respect to disk space, other than the need to have enough space to load the OS (about 150M) and enough space for the page file and the Registry (including the SAM). In fact, if your server will only perform domain controller functions, and nothing else, you can get away with a fairly small drive, perhaps even as small as 500M for a domain with few users. However, in today's market, it's uncommon to find servers configured with less than 2G SCSI-based hard drives. In smaller domains, your domain controllers are likely to be multifunction, so you can be sure that you'll find a use for that extra disk space sooner or later.
The last hardware element you will want to consider is CPU, or processing power. Windows NT Server 4.0 supports both single- and multiprocessor configuration of Intel, Alpha, MIPS, and Power-PC based systems. Domain controller functions, especially on the PDC, can be fairly processor-intensive. This is especially true if you are performing many frequent adds or changes to the SAM. Because the PDC has to process these changes as well as keep all BDCs synchronized every five minutes or so, processor load on a large domain can be quite significant.
Because the Intel platform is the most prevalent today, we'll examine processor requirements for these types of systems. In today's market, it really doesn't make sense to run a Windows NT domain controller on anything less than a Pentium processor. Significant performance enhancements were made in Windows NT 4.0 to take advantage of the Pentium architecture. These systems, as well as Pentium Pro models, are quite common and reasonably priced.
For domain controllers running in domains with greater than 25,000 users, consider a second processor to carry some of the domain controller functions. Additionally, if you plan on running file or application services on your domain controller, you will definitely want to consider additional processing power--in the form of either a faster processor such as the Pentium Pro, or multiple processors.
You might also want to consider installing "smart" I/O controllers to remove some of the load from busy servers. These smart disk controllers or NICs contain an on-board CPU that performs many of the tasks that the server's CPU normally would. These cards can significantly ease the load on the server's CPU. They can also increase performance on the various server subsystems by performing tasks without having to wait on the server's processor to service these cards' requests.
After you've decided on a domain model and sized your servers, you'll need to decide the appropriate number of domain controllers to deploy. Two factors will play into this decision. You will need to weigh the need for fault tolerance and performance against the cost of having many servers. This cost is quantified not only in terms of hardware costs, but also the support costs required to maintain additional servers. Remember that the initial cost for your hardware is small in comparison to the cost for maintenance and support over its lifetime.
The general rule is that you will need one domain controller for every 2,000 users. In practice, however, if your domain is smaller than 2,000 users, you still might want to have at least two domain controllers--a PDC and a BDC--so that you have at least one replica of the SAM database in case the PDC fails. The BDC provides fault tolerance by providing a second server for user authentication. However, you'll have to balance that against the cost of purchasing and maintaining the second server. For a domain of 50 users, it might not make sense to purchase that BDC. Instead, you might choose to accept downtime if the PDC fails and recover the SAM database from tape. After about 100 users, however, a BDC starts to make more sense than the lost time those users will experience while you recover the PDC.
Disaster recovery planning is not something that every organization requires, but if you're required to plan for a catastrophic event, you should take into account the role of the domain controller. Because Windows NT supports the concept of a replicated domain database via the BDC, you can leverage this in your disaster recovery strategy.
Most disaster recovery plans include an alternate site where some subset of production servers and workstations are located, with identical configuration to your normal systems. Because many servers in today's enterprises are located in "server farms"--highly concentrated numbers of servers in a raised-floor or secured environment--this can leave your domain susceptible to complete failure in the event of a fire or other catastrophe. To prevent this kind of total disaster, keep a BDC located at your recovery site and connected to your main network for domain synchronization. In the event that your primary site containing the PDC and other BDCs is destroyed, the BDC at the remote site can be promoted to PDC, and all normal domain operations related to the SAM database can continue.
Locating failover BDCs remote to the PDC is also a good approach to take if you have multiple domains that are geographically separated from each other. In this case, each location can keep a BDC from another location on its site. In the event that one location suffers a total failure, the BDC at a different site will still be able to service logon requests, or be promoted to PDC.
In the earlier section "Fault Tolerance versus Cost," we discussed a ratio of 1 domain controller to every 2,000 users. However, this assumes that from a network perspective, all these 2,000 users are located in close proximity to the domain controller. Generally, this is not the case, so you will need to consider your network topology in addition to factors such as fault tolerance when deciding how many domain controllers to roll out.
The goal is to keep authentication local to the user as much as possible. If you have 20 branch offices, each with one or two users who dial into the home network via RAS, it doesn't make much sense to locate a domain controller in each branch. If those offices grow to five or ten users, and they are connected to the rest of your network via slow WAN links, you might consider placing a domain controller in each office to ensure speedy authentication. Another alternative would be to increase the speed of your links to support the remote authentication of those five or ten users, but this solution can be cost prohibitive.
The networking protocols you use will also have an influence on where you locate your domain controllers. If you're using a broadcast-based protocol like NetBEUI in a highly segmented, routed network, you have two choices for providing domain services:
Although it's generally desirable to have a user authenticate with a domain controller on the same physical network segment, neither of the previous options is particularly attractive. Your best bet is to choose another routable protocol that enables directed requests to your domain controllers. TCP/IP support in Windows NT provides this service, and for good reason, is probably the most ubiquitous protocol in use on the Windows NT platform today. TCP/IP, in conjunction with a name service for locating Windows NT Servers by name, can enable you to locate domain controllers on any segment within your network and provide users with quick access regardless of where they are, without flooding the network with unnecessary broadcasts.
A final issue to consider is related to how Windows NT domain controllers provide authentication services. More precisely, it's important to understand how a Windows NT or Windows 95 workstation locates a suitable domain controller for authenticating to the domain. This is critical for planning the correct number and location of domain controllers. For this discussion, we'll assume that the networking protocol in use is Microsoft's NBT stack, which provides NetBIOS services over TCP/IP.
In a TCP/IP environment, you're likely to be providing NetBIOS to IP address name resolution via either the Windows Internet Name Service (WINS) or local LMHosts files. Windows NT and Windows 95 workstations use these services to translate server names into IP addresses. When a Windows NT or Windows 95 workstation, configured to use WINS, is booted, it makes two requests for authentication services. The first is a directed packet to the primary WINS server configured in its TCP/IP configuration dialog box. This packet asks the WINS server for a list of all domain controllers for the domain the user or machine is connecting to.
At roughly the same time, the workstation also sends a broadcast packet on its local physical segment, requesting the same "I need a domain controller" information. The WINS server responds with a list of domain controllers' IP addresses that can service the request. The workstation then sends a "request for logon services" packet to each of the servers listed in the WINS response.
Meanwhile, if any domain controllers are on the local segment with the workstation, they reply to the workstation with a response that they can service the logon request. Additionally, the other servers (provided by WINS) that the workstation requested logon services from will also respond if they can provide those services. The first server to respond to the workstation's request will be the one to handle the logon request. Generally, this is the response to the broadcast request by the local server.
Understanding this process, and the relatively nondeterministic way a workstation locates a domain controller, is critical when deploying BDCs. For example, you might have a remote office connected to your main network via a slow WAN link. You have decided to put a BDC in the branch office to service logon requests locally. Your workstations are running TCP/IP and referencing a WINS server in your central office. In your remote office, you have two Ethernet segments connected together via a router. One segment provides for several servers you have located in that office, and the other for user workstations. When your workstations start up, or your users log on to the domain, you would expect that the workstations would all use the local BDC to authenticate to the domain. Based on the previous explanation, however, that might not be the case.
The workstations will query WINS to get a list of available domain controllers, and they will also send out a broadcast on their local segment. WINS will return a list of domain controllers that can include servers located in the central office, or even other remote offices. Because the workstations are separated from the local BDC by a router, their broadcast request will never be heard. The request will be answered by a domain controller in another office, and the users will then be authenticating and processing logon scripts over a slow link. Even in the case where the workstations are located on the same physical segment as the local BDC, if that server is too busy performing other tasks, it might take a while to respond to the request, and another remote domain controller that happens to be available might actually reply sooner. However, this situation will likely be the exception rather than the rule.
When you're deciding how to deploy your domain controllers to provide load balancing and optimization of authentication requests, you'll need to consider this process and how it fits into your network. This response-time sensitive nature of domain authentication is another argument for making sure that all your domain controllers have enough memory and processing power to keep up with demands imposed by authentication.
Today, Windows NT domains, with the help of trust relationships, provide many of the services required for maintaining a robust enterprise-wide applications platform. Microsoft has recognized, however, that the inherent complexity of the domain model for large organizations can be a limiting factor in the usability of Windows NT. Maintaining trust relationships between tens or hundreds of domains can quickly become overwhelming.
As a result, the next major release of Windows NT is due to include a global directory service that will integrate with and eventually replace today's domains. Similar to Novell's NetWare Directory Services (NDS), the Active Directory will provide a framework for managing large numbers of resources in the Windows NT environment. The directory service will support today's existing objects, including user accounts, machine accounts, and groups, as well as numerous other object types and services that will benefit from being exposed through a global directory service. The Active Directory will be based on a subset of the X.500 standard for directory services. It will provide access for Lightweight Directory Access Protocol (LDAP)-enabled clients, as well as Web-based access, and will use the Internet-standard Domain Name Service (DNS) to provide name resolution services for clients accessing the directory. Trust relationships will still exist between domains but will be automatically enabled and will have the capability of being transitive--for example, A trusts B, and B trusts C, so A trusts C. Additionally, administrative authority will be much more granular, allowing for better delegation of administrative tasks. In the end, it promises to scale to millions of objects and will represent a new way to manage Windows NT resources in the enterprise.
© Copyright, Macmillan Computer Publishing. All rights reserved.