The ability to share an account database is a really nifty feature because it provides the ability to access networked resources as if you are a local member. But, it does have a minor or major problem, depending on your usage. To be specific, this feature can eat up a lot of network bandwidth. First, you must consider the pass-through authentication to the foreign domain that occurs whenever a user account is used on the trusting domain. This is for a one-way relationship. In a two-way trust relationship, all trusted domains pass the user authentication to each other. And that’s where the network bandwidth can be used up quite quickly if you have a lot of users accessing resources outside of their local domain.

Obviously, if you have all of your servers on a 100MB/sec. backbone, this is not much of a problem. But if you have domains located across routers, bridges, or RAS connections, the available bandwidth may not be sufficient to support your pass-through authentication and your network client data access simultaneously. So, how do you get around this limitation? Well, you have a couple of options. You could increase your network bandwidth on the slower network segments or you could create global groups with local accounts using User Manager For Domains. A local account is for an account from an untrusted domain—just the ticket for what you are looking for here.

Once you have added the global groups, you may then assign permissions to local resources based on the global group you created previously. When foreign users attempt to access the resources, they will be granted access. The local account essentially performs the same action as a one-way trust relationship, but without the overhead involved in pass-through authentication. If you want to create a two-way relationship, repeat the action on the foreign domain with User Manager For Domains. The only caveat here is that the users now have two separate accounts (one on each domain) and they have to manually update their passwords on the foreign domain whenever they change them on the local domain to keep them synchronized.

NT Server Modes Of Operation

You have three choices when installing Windows NT Server. Each basically defines a specific mode of operation, and each of these operating modes provides different functional abilities and performance options. The choices include:

•  Primary Domain Controller—The primary domain controller contains the master copy of the user database, which includes all your global groups, user accounts, and computer accounts. In addition to this, your primary domain controller is used to authenticate your users when they log on to the network or access a shared resource. Your primary domain controller also includes the tools you will use for centralized administration, such as User Manager For Domains, Server Manager For Domains, Dynamic Host Configuration Protocol server, Windows Internet Name Service server, and a host of additional tools.

•  Backup Domain Controller—A backup domain controller is similar functionally to a primary domain controller with one significant difference: It does not contain the master copy of the user database. Instead, the master database is replicated from the primary domain controller. This means you cannot make any account changes (global groups, user accounts, or computer accounts) if the primary domain controller is unavailable. The primary reason for using a backup domain controller is to balance the load for authenticating users on the network. In addition, if a primary domain controller goes down, either inadvertently due to a hardware fault or purposely, say for a hardware upgrade, you can promote a backup domain controller to a primary domain controller. This provides the ability to continue authenticating your users, as well as providing continued network administrative capabilities.

•  Server—A server’s primary purpose is to provide optimum resource sharing. Because a server does not authenticate users logging on to the network and does not participate in the user database replication, it can devote all of its resources to supporting your network clients. There is a trade-off for this increased performance because you lose the domain administration tools. For instance, only a domain controller includes the WINS Manager and DHCP Manager applications.

---

Another reason to use Windows NT Server operating in server mode is to bypass the Windows NT workstation limit of 10 simultaneous client user connections. Instead of using Windows NT Workstation, you can use Windows NT Server operating in server mode.

---

One major consideration is that, in order to create a domain, you must have at least a primary domain controller in your network. You can have one or more backup domain controllers if desired, although they are not required (but having at least one BDC is recommended). Keep in mind that a backup domain controller can be very useful if you have a primary domain controller failure. Remember, only a primary or backup controller can authenticate your Windows NT clients. Also, some of the BackOffice applications, like System Management Server, require that they be installed on a controller. These applications are very CPU intensive, so you should install them on different controllers. This may necessitate having three or more controllers on your network.

Domain Models

Microsoft has defined four basic domain models: single, master, multiple master, and complete trust. However, you should consider this as a starting point when it comes time to plan your network implementation. (We will discuss this in more detail a little later in this chapter.) You do not have to limit yourself to a specific domain implementation. Instead, you can stretch a basic domain model to fit your specific needs. So, let’s take a look at these models so you can plan the best network design possible for your network.