Domain Strategy
Version 2.0
Texas Instruments Incorporated
The purpose of this document is to provide the reader with a comprehensive understanding of the Microsoft® Windows NT® Server multiple master domain model being implemented on the Texas Instruments global client-server network, defined here as the NT Enterprise Network. Both basic and advanced NT Server concepts are covered.
Of the four possible Microsoft® Windows NT Server 3.51domain models, the single domain model, the master domain model, and the multiple master domain model are relevant to Texas Instruments. Each model will be described and an example in the Enterprise NT Network will be shown.
A single domain model is the simplest NT domain. It consists of one or more NT domain controllers sharing a common SAM (Security Account Manager) database that contains all user and group accounts.
Note: A domain controller contains the original (primary domain controller or PDC) or replicant copy (backup domain controller or BDC) of the SAM database. A third role—domain server—will be discussed later.
Figure 1. Single domain model
This model is the best choice for small organizations on one campus, or larger organizations that share a common administrative group. An example of this model is the JAPAN1 domain. It spans 5 sites across Japan, but shares a common administrative group. With this model, one site's administrators may administer another site's servers if needed.
A master domain model consists of two parts: the master domain and one or more resource domains. In the following figure the master domain DOMAIN1 contains the user accounts of itself and resource domains RES1 and RES2. One-way trust relationships between the resource domains and the master domain enable users to log on to DOMAIN1 and still access resources (files, printers, RAS, Notes, etc.) in the resource domains.
Note: A trust relationship is the link between two domains that enables a user with an account in one domain to have access to resources on another domain. (See NT 3.5 Resource Kit, Volume 2, p.59.)
Figure 2. Master domain model
This model is the best choice for companies that have two or more organizational units with different needs, yet require users to have only one account to access all NT resources in the network. EUROPE1 and APR1 master domains are examples of this model. They each have a master domain jointly administered by members of each resource domain. For example, the APR1 (Asia Pacific Region) master domain has resource domains for Singapore, Malaysia, Philippines, Hong Kong SAR, China, and Taiwan—all discrete organizational units for the Semiconductor Division. This model's principle drawback is that, by itself, it cannot support the number of users that TI requires.
A multiple master domain model is simply the addition of one or more master domains to the master domain model. Master domains become more difficult to support as they increase beyond about 15,000 users; adding carefully selected master domains increases capacity dramatically. Master domains must be kept to an absolute minimum for administrative reasons and future Cairo (NT's next major release) migration considerations.
In the following figure the master domain DOMAIN1 contains the user accounts of itself and resource domains RES1 and RES2. Master domain DOMAIN2 contains its own accounts and those resource domain RES3. (Resource domain accounts could reside in either master domain.) One-way trust relationships between the resource domains and the master domain enable users to log on to the master domain that contains their account and access resources (files, printers, RAS, Notes, etc.) in the resource domains.
Figure 3. Multiple master domain model
This model is the best choice for large corporations. When permission is granted, any account in any master domain can access resources in any other domain.
One of the big challenges in designing and deploying a multiple master domain model is striking a balance between flexible administration and limiting the number of trusts between domains.
As mentioned before, a trust is a link between two domains. In its actual implementation it's a session established between two NT computers in different domains that resides on the application layer of the OSI model. Since the trust relies on all layers below on both computers, and the physical network between them, if any of these layers fail the trust appears to fail. In reality the trust doesn't usually fail, something below (TCP/IP, a router, the physical network) fails—although the NT message "The trust relationship between the primary domain and the trusted domain failed" can cause one to jump to conclusions!
Users, now able to access cross-domain resources more easily than ever, begin to depend on trusts. They must be monitored and maintained as a network element every bit as important as the servers themselves. Wide area networks impose their own problems on trust relationships from NetBIOS name resolution and network traffic on slow links.
The number of trusts between master domains, tm, can be computed from the formula
where nm = number of master domains.
The number of trusts between master domains and resource domains, tr, can be computed from
where nm = number of master domains and nr = number of resource domains.
Total number of trusts in a multiple master domain model can then be calculated from
or
The number of trusts between domains can add up quickly, especially as the number master domains increases. In a multiple master domain network with 7 master domains and 15 resource domains, adding one more resource domain requires an additional 7 trusts, while adding another master domain requires 29 new trusts!
Rather than define production domains, IS&S has moved to defining their production servers. These servers meet the criteria of
All production NT servers will run Microsoft TCP/IP and NetBEUI (NBF) in that order. NBF will be used for compatibility until the TI network is fully routed.
All production NT servers use Compaq ProLiant or ProSignia hardware. Fault tolerance is built into the configuration; ProLiant-class servers use hardware RAID-5, while ProSignias us software mirroring of the OS partition.
Account, directory, and share creation is handled by IS&S Customer Service via the IMS menu "M SERVER". This group is the central focus for all customer accounts for USADA1, USADA2, and APR1 domains. USADA10 accounts are handled by Systems Group customer service.
The World Wide Command Center(WWCC) in Plano, Texas, is the focus point for IS&S production server-related problems at TI. Problem notification usually comes from either the Technical Support group or directly into the WWCC.
If WWCC personnel are unable to correct the problem, they contact IS&S Problem Management. Problem Management is a group consisting of several teams that specialize in different support areas such as NT Server, IBM S/390, and Unix. Microsoft Premier Support may get involved at this point.
If Problem Management is unable to resolve or it's determined that design/engineering changes are needed to resolve or prevent further occurrence of the problem, Workstation Client Server Operating Environment (a.k.a. Client/Server Engineering, NT Server Engineering, or just Client/Server Engineering) gets involved.
Problem followup and reporting on root cause analysis are done at the 8:30 AM Production Meeting every Monday through Friday. Support personnel from around the world call in to participate in the meeting.
A WINS server is a Windows NT Server computer running the Microsoft TCP/IP protocol and the Windows Internet Name Service (WINS) server software. WINS servers maintain a database that maps computer names to IP addresses, allowing users to easily communicate with other computers while gaining all of the benefits of using TCP/IP.
"Name Services with Microsoft Network Technologies" is an engineering document that details WINS as it applies to TI. It's located at \\DSKS2\NT\WINS\NAMESRV.DOC.
Several aspects should be considered when designing where to place PDCs, BDCs, domain servers, and workstations:
A Windows NT Server can be built as a primary domain controller, a backup domain controller, or in a non-domain controller role called confusingly a server by Microsoft. At TI this role is called a domain server (as compared to a domain controller) for clarity. A domain server does not have a copy of the SAM database that is shared by all domain controllers in the domain, so it does no replication and user authentication. Instead it has its own SAM database. A good analogy is that of a large NT Workstation with the 10-user connection limit removed.
Domain servers are used in the NT enterprise network on a limited basis. The main functions they perform are to provide a platform for resource-intensive applications like SQL Server and to allow small NT customer groups with a small number of servers to participate in the NT enterprise network.
As an applications platform, domain servers do not have the system overhead of domain controllers and have more system resources available for applications that demand them. These applications will be considered on a case-by-case base using performance history from existing servers when possible. Groups interested in IS&S provisioning this configuration can contact IS&S Change Management at MSGID "*CSSD" for details.
Small customer groups with a small number of NT server are usually interested in joining the NT enterprise network for several reasons. The two most often cited are to minimize NT userids/passwords while maximizing access to global NT resources, and to have an established, centralized group handle their user accounts and passwords. NT domain servers can minimize userids and passwords by keeping them in the master domain (which also gives them global connectivity). Information Systems & Services manages NT accounts in three master domains around the world; as part of the process of integrating a small customer group server(s) into an NT domain, the server's accounts will be recreated in a master domain. If the local system administrator still requires management over his group's accounts, and has 50 accounts or more, appropriate rights can be arranged. Potential customer groups can contact IS&S Change Management at MSGID "*CSSD" for details.
Under most circumstances, the best placement of an NT domain server is in the same domain as its users' accounts.
Network traffic analysis: Since a domain server doesn't have a copy of the domain's SAM database, it must gain access to one. It does this upon system startup by using a process called discovery. The server broadcasts a query for domain controllers (or, if WINS is implemented, a directed query to its primary WINS server for a list of domain controllers). A communication session is attempted between the domain server and the first domain controller that responds to the server's broadcast request. If this session setup is successful, a secure communication channel is then created between the two computers to pass network APIs, usernames, and encrypted passwords. The point is: A domain server must get domain account information from a domain controller across a secure channel—one more step than a domain controller.
If your domain server resides directly in the master domain, it need only go to the nearest domain controller for user authentication:
Figure 4. Domain server in master domain
If it resides in a resource domain, its secure channel will be set up with a domain controller, which in turn must set up a secure channel with a master domain controller—one more hop:
Figure 5. Domain server in resource domain
For more detail on this topic, see "Network Security and Administration" in the Windows NT Networking Guide of the Windows NT Resource Kit.
Security/Administration analysis: A domain server operates within a "virtual resource domain" because it has its own SAM database. Like a true resource domain, has its own authority scheme and it relies on pass-through authentication for validating its user accounts. The difference between the two is that a domain server has an implicit trust with its primary domain (created when the server joins the domain) that can't be easily seen, while a resource domain's trust is explicit (created by a two-step process in the "User Manager for Domains" tool) that can be monitored with a number of tools. Therefore, for the security/administration analysis, it's irrelevant which domain in which the domain server resides.
A remote BDC is a domain controller, usually of a master domain, separated from the main campus of a LAN by a slow link (anything less than 10 MBs).
The purpose of a remote BDC is to provide a network local method of authenticating user logons. This has several benefits:
Remote BDCs are required whenever a group of users is separated from the domain LAN by a slow link. These can be smaller machines than a standard file server; the current standard calls for a Compaq ProSignia to be used.
The most common configuration is a master domain BDC in the computer room of a remote site (configured as a resource domain), physically adjacent to the resource domain's servers. A remote BDC could also simply be a file/print server from the master domain located at a small site.
Remote BDCs are used between master domains for different reasons than their use for resource domains. Their uses are
This is done by putting a BDC from the user's domain nearby (network-wise) to the server they are trying to access. The USADA1 server will attempt to authenticate the Miho user by contacting the nearest JAPAN1 BDC. If a remote BDC is intentionally placed near USADA1 servers, it will alway be chosen for authentication. Otherwise, the authentication request must travel all the way to Japan and back - often timing out in the process.
Figure 6. User at Miho connects to server in Spring Creek
It's important to note that this type of BDC is not immediately required. They must be added on a case-by-case basis as dictated by business needs. This is more of a demographics issue—what domain users tend to access what other domains? For instance, it's a fact that the first of this type of remote BDC will need to be installed in the Dallas area from international master domains—because Dallas is the corporate headquarters and server network data access tends to be into Dallas rather than outbound from Dallas.
Summary: If a master domain's users are accessing a remote master domain frequently or traveling to that master domain, a remote BDC should be considered.
To fully participate in the NT enterprise network, all Windows NT workstations must join an NT enterprise network domain. NT workstations that join a workgroup cannot use domain accounts.
All Windows NT workstations or Windows NT Servers have a "machine account", a unique NetBIOS name up to 15 characters, by which the computer will be identified in its NT domain. This machine account must be added by domain administrators with the "Server Manager for Domains" application, usually before the system is built. What is displayed in the "From" pick list on the workstation's "Welcome" dialog box (which determines to which master domains the user can log on), depends on what domain the NT workstation's machine name has been added to.
To decide where NT workstations should be placed, consider the requirements in descending order of importance:
If the customers are locally administered (i.e., a resource domain), the local administrative staff should have administrative access to the workstations.
If there isn't any formal local administration, IS&S' Workstation Technical Support should have administrative access to the workstations.
The workstations should be placed to minimize network traffic on startup and daily operation, and grouped to avoid overloading the domain master browser.
Startup traffic should be minimal. TI computers are not powered down during non-business hours, and NT workstations are rebooted much less frequently than Windows workstations.
In remote resource domains, network traffic over slow links is minimized by requiring a BDC in the master domain on site.
Browser overloading can be avoided by adding NT workstations to a resource domain when the administrative requirement of 1) and 2) above are satisfied.
If the local administrative staff has administrative rights in a master domain, the workstations should be added to that master domain. (Both local administrators and IS&S WTS will have administrative access. Network traffic depends upon local network topology.)
Add NT workstations into the domain that is nearest network-wise to the users and is administered by the local administrative staff, usually a resource domain. The resource domain must have enough BDCs to support secure channels with all the NT workstations in that domain. (Only local administrators will have administrative access unless master domain administrator groups are explicitly added. Network traffic is minimized.)
If workstation troubleshooting is to be done by IS&S' Workstation Technical Support, the workstations should be in an IS&S administered domain. (Only IS&S WTS will have administrative access. Network traffic depends upon local network topology.)
Take for example a domain that contains both user accounts and server resources. Backup domain controllers are scattered throughout the sites, and a common group administers the domain and NT workstations. NT workstations would join this domain:
Figure 7. NT workstations in a master domain
Now suppose a resource domain existed in this same region. Its user accounts would reside in the domain mentioned in the last example, but its server resources would reside in the resource domain and the site's local administrators control these resources. In this case, since the local administrators have full administrator rights over the resource domain only, and its domain controllers are the closest to the user population, the NT workstation machine accounts should reside in the resource domain:
Figure 8. Passthrough authentication for an NT workstation
Why? Three reasons, in decreasing order of importance:
The "From" pick list of an NT Workstation or NT Server built as a domain server will contain:
For example, the From list of an NT workstation named BOB which has been registered in the RES1 resource domain with a one-way trust to the MASTERD master domain would contain:
Putting the NT workstation's machine name in the master domain ensures the workstation user will always be able to log on to their computer using an account from any of the NT enterprise master domains. The remote master domains may be available if the NT workstation is installed in a resource domain, but trusts are often not as closely monitored. In the larger domains like USADA1 and USADA10, however, the presence of many workstations will cause the browser to reach its limit and begin dropping servers (which are farther down the alphabetic browse list).
Note: The list of servers that the master browser maintains is limited to 64K of data. This limits the number of computers that can be in a browse list in a single workgroup or domain to 2000–3000 computers. (NT 3.5 Resource Kit, Volume 2, p.83)
Putting the NT workstation's machine name in the resource domain has the advantage of removing it from the browse list of the master domain, leaving more space for servers in the domain browse list. A drawback is the resource domain must have fully implemented the one-way trusts between all master domains before all master domain accounts can be reached from the workstation console. This isn't normally a problem until the workstation was likely to have visitors from another master domain to work on it (in which case a trust relationship between the master and this resource domain has probably already been set up). Another drawback is IS&S Workstation Technical Support will not be able to directly examine the workstation.
A third, and perhaps the most important reason, is that all NT workstation users in the resource domain (logged in to a master domain account) must go through one more hop for all user authentications in the same manner as a domain server:
Every master domain listed below shall have a two-way trust with every other master domain. Every production resource domain listed below shall have a one-way trust with every master domain. Note: this is not the master reference of all NT production domains; contact IS&S Change Management for a comprehensive list.
Status as of February 27, 1996:
NT master domains follow the naming convention
<Country or Region>(<PDC_sitecode>)<NN>
where
"Country or Region" |
is the country where the domain is located, or if the domain spans more than one country, the region. |
PDC_sitecode |
is the optional site code or country location of the PDC. |
NN |
is a unique identifier. |
NT resource domains follow the naming convention
<Country or Region>(<PDC_sitename>)<NN>
where
"Country or Region" |
is the country where the domain is located. |
PDC_sitename |
is the more narrowly defined site location or site code of the resource domain. |
NN |
is a unique identifier. |
On December 7th, 1995, a meeting was held to define a naming standard for all IS&S NT infrastructure servers. With the general consensus of everyone present, it was determined that a generic naming approach strategy would be used. The only exceptions to this rule are the Network type devices, i.e., Network Print Server (NPS) and Network Management Server (NMS).
All new NT enterprise network production servers are to have the NetBIOS name DxxSnnn—where D = Distributed, xx = Site Code (per T ISD.Location or T SiteCode), S = Server (or the exceptions NPS or NMS) and, nnn = Unique Server Number Identifier (assigned by C/S Change Management).
Example:
DSKS1 = Distributed - Spring Creek - NT Server - #1 (the USADA1 Primary Domain Controller (PDC))
The NT production server names are assigned by the C/S Change Management Group via MSGID: *CSSD. IPARM/Directory Services will be used as the official registration mechanism as it becomes available. Until then, the WWCC's Lotus Notes database (DSKLD047\WWCC\WWCCPROC.NSF under ProdServInfo View) will be used as the reference for identifying applications and operating systems that are currently running on a particular production server. This database is manually loaded to TIOLR where detailed server information can also be found under 'M CServer' or by inputting 'T3 (server name)'.
© 1996 Texas Instruments Incorporated. All rights reserved.